Subject: [tcpm] WGLC on antispoof

From: Mark Allman <[email-masked]>
Date: Tue, 16 May 2006 23:43:49 -0400

Folks-

Per the discussion in Dallas, we are kicking off a WGLC on the anitspoof
document.  Joe has just posted a new rev of the document which is
available in the archives:

  ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt

As I understand them, there are no major changes from the last revision.
Please give it a read in the next couple of weeks and let us know what
you think.  On-list feedback is best.  Input to the author and chairs is
OK.  If you find the document just fine, a quick one sentence email to
that effect would be very useful.

We will have a 2 week last call period, ending on May/24.

Thanks,
allman

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 May 2006 22:06:37 -0700

> We will have a 2 week last call period, ending on May/24.

2 weeks would end on May 30, right? ;-)

Joe

---

From: Mark Allman <[email-masked]>
Date: Wed, 17 May 2006 07:22:29 -0400

> 2 weeks would end on May 30, right? ;-)

OK, fine, we'll go with your math on this one. :-)

So we're clear (or, is it too late for that?), the WGLC on antispoof:

will run through May/30.

Sorry for the confusion.

allman

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 May 2006 13:38:18 +0300 (EEST)

Hi,

>  ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt

I finally got around to checking my comments on -02, and the resulting 
text; I only looked at the comments I made then and the follow-up 
modifications.

Issues:

1) address filtering text is still technically incorrect or 
assumptive

2) the text about TTL checking and tunnels not decrementing the TTL is 
misleading or incorrect

3) the reason why ICMPs are filtered is speculative

I'll make separate posts about these to facilitate easier discussion 
(if any).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 May 2006 13:45:48 +0300 (EEST)

On Mon, 29 May 2006, Pekka Savola wrote:
> Issues:
>
> 1) address filtering text is still technically incorrect or assumptive

Specifically, the statement (and follow-up text):

"It cannot restrict traffic from edges lacking filtering through the 
core to a particular edge, i.e., from upstream sources."

is not correct.  In response to previous comments, the editor said:

"I disagree that "you can _yourself_ do the filting, without relying 
on anyone else", except in trivial multiconnected stub network cases."

The last part may or may not be key to understanding and resolving the 
disagreement.

I assert that an ISP can protect its own and its single-homed 
customers' sessions which are internal to the ISP by making sure its 
own borders are properly secure.  I also claim that multihomed sites 
can do this on their own borders to protect their internal sessions. 
Hence, "internal sessions" in an administrative domain that cares 
about setting up proper security can be protected from TCP RST 
attacks.  See the assumptions in Section 1 of 
draft-savola-rtgwg-backbone-attacks-00.txt for more on how this helps 
an ISP.

I'd estimate that over 95% of net users are single-homed by that 
definition, though the amount of traffic that's "internal" is arguably 
limited.  Hence, this is an important scenario especially if you 
consider *infrastructure* uses (which are typically internal, such as 
BGP) and needs to be properly addressed instead of just waived away as 
a trivial case.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 May 2006 14:14:11 +0300 (EEST)

> 2) the text about TTL checking and tunnels not decrementing the TTL is 

The text in section 3.2.1 about TTL checking is still misleading or 
incorrect.  Do you mean both you and your peer with "those nodes" in 
"or any traffic those nodes accept via tunnels - because tunnels need 
not decrement TTLs"?  Either way, this gets back to whether your peer 
is complying to RFC 791, i.e., decrementing the TTL for packets which 
it forwards.  There is no difference whether the link is physical or 
an IP tunnel.  Tunnel head-end decrements the TTL if it forwards a 
packet to the tunnel; tunnel tail-end decrements the TTL if it 
forwards a packet out of the tunnel.  TTL is unchanged for packets at 
the end which is originating or receiving packets. Exactly like 
physical interfaces.

Therefore I don't see why it makes sense to make such a big deal about 
tunnels.  Further, "only where all traffic from the other end of the 
tunnel is trusted" is misleading at best.  It makes it sound as if 
transiting traffic (from all over the Internet) at tunnel head-end 
would need to be trusted if the tunnel head-end is conforming to the 
specifications.  That's not the case; you only need to trust that the 
tunnel head-end isn't injecting inappropriate packets (which includes 
inappropriate modified copies of transited datagrams).  But if the 
only thing the tunnel head-end can do is to reset its *OWN* (BGP or 
whatever) link-local session, what's the point?

In practice, TTL checking for link-local control messaging may be
inadequate if:

  1) you don't trust the link layer (see 
draft-savola-rtgwg-backbone-attacks-00.txt section 2.1 why this isn't 
necessarily a big deal for control protocols such as BGP),

  2) the link includes a large number of neighbors (e.g., an internet 
exchange Ethernet fabric) and other authentication is not used, or

  3) GTSM implementation processes TCP RSTs for GTSM-enabled sessions 
which have TTL != 255.  The behavior is currently unspecified, but 
GTSM revision will be looking at this.

The text in the document right now is:

    A more recent variant of address filtering checks the IP TTL field,
    relying on the TTL set by the other end of the connection [15].  This
    technique has been used to provide filtering for BGP.  It assumes the
    connection source TTL is set to 255; packets at the receiver are
    checked for TTL=255, and others are dropped.  This restricts traffic
    to one hop upstream of the receiver (i.e., a BGP router), but those
    hops could include other user programs at those nodes (e.g., the BGP
    router's peer) or any traffic those nodes accept via tunnels -
    because tunnels need not decrement TTLs [30] (see Sec. 5.1 of [15]).
    This method works only where all traffic from the other end of the
    tunnel is trusted, i.e., where it does not originate or transit
    spoofed traffic. The use of TTL rather than link or network security
    also assumes an untampered point-to-point link, where no other
    traffic can be spoofed onto a link.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 29 May 2006 14:21:22 +0300 (EEST)

> 3) the reason why ICMPs are filtered is speculative

The new text says:

    Unfortunately, [ICMP errors] also can originate at other places
    in the network. As a result,
    many networks filter all ICMP packets because validation may not be
    possible, especially because they can be injected from anywhere in a
    network, and so cannot be selectively address filtered.

.. it seems that "As a result" is speculative.  I don't know why 
people filter ICMPs; because there is no reference, I suspect you 
don't know either.  You make it seem that filtering ICMPs is a result 
of certain bad ICMP packets, in particular ICMPs which reset sessions. 
I personally suspect that reasons are very different and have evolved 
much earlier on, like "we don't want to allow ping scanning to see 
which hosts are up".

But that seems irrelevant to this particular document, as there is no 
way to know what the current or original motivations for filtering 
ICMPs were.  Hence, I'd reword the latter sentence or remove it 
completely.  If rewording, I'd be careful not to imply that the IETF 
thinks filtering all ICMP messages is a valid configuration...

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 09:41:11 -0700

>> 1) address filtering text is still technically incorrect or assumptive

It would be useful to provide candidate substitute text.

> is not correct.

Assume you provide filtering from upstream sources that do not
themselves filter (the opposite). Any traffic that appears sourced from
 upstream could have been spoofed.

Can you explain how to provide filtering in this case?

>  In response to previous comments, the editor said:
> 
> "I disagree that "you can _yourself_ do the filting, without relying on
> anyone else", except in trivial multiconnected stub network cases."
> 
> I assert that an ISP can protect its own and its single-homed customers'
> sessions which are internal to the ISP by making sure its own borders
> are properly secure.

What percent of connections are internal to the ISP? Protecting only
that small fraction of connections is not sufficient.

> I also claim that multihomed sites can do this on
> their own borders to protect their internal sessions.

That's essentially a restatement of the exception I provided (internal
sessions treat the net as a stub).

> Hence, "internal
> sessions" in an administrative domain that cares about setting up proper
> security can be protected from TCP RST attacks.  See the assumptions in
> Section 1 of draft-savola-rtgwg-backbone-attacks-00.txt for more on how
> this helps an ISP.
> 
> BGP) and needs to be properly addressed instead of just waived away as a
> trivial case.

This text is self-contradictory; I agree that a large percentage (though
95% seems arbitrary, and would need a reference to include) of users are
single-homed, but the larger issue is the percent of internal traffic.

One would hope that BGP would not be internal (it wouldn't be very
effective). Once it originates outside your border, you're trusting the
party one stream up to filter - even for BGP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 09:44:29 -0700

Pekka Savola wrote:
> incorrect.  Do you mean both you and your peer with "those nodes" in "or
> any traffic those nodes accept via tunnels - because tunnels need not
> decrement TTLs"?  Either way, this gets back to whether your peer is
> complying to RFC 791, i.e., decrementing the TTL for packets which it
> forwards.  There is no difference whether the link is physical or an IP
> tunnel.  Tunnel head-end decrements the TTL if it forwards a packet to
> the tunnel; tunnel tail-end decrements the TTL if it forwards a packet
> out of the tunnel. TTL is unchanged for packets at the end which is
> originating or receiving packets. Exactly like physical interfaces.

See section 3.1 of RFC2003; whether the TTL is decremented depends on
whether forwarding is considered part of the operation, and this is a
choice, not fixed.

Can you evaluate the remainder of this note in the context of RFC2003
and let us know if there is still an inconsistency?

> transiting traffic (from all over the Internet) at tunnel head-end would
> need to be trusted if the tunnel head-end is conforming to the
> inappropriate modified copies of transited datagrams).  But if the only
> thing the tunnel head-end can do is to reset its *OWN* (BGP or whatever)
> link-local session, what's the point?
> 
> which have TTL != 255.  The behavior is currently unspecified, but GTSM
> revision will be looking at this.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 09:48:39 -0700

Pekka Savola wrote:
> .. it seems that "As a result" is speculative.  I don't know why people
> filter ICMPs; because there is no reference, I suspect you don't know
> either. 

I'll add a citation to RFC4301, which asserts these reasons (without
citation, FWIW).

> You make it seem that filtering ICMPs is a result of certain
> bad ICMP packets, in particular ICMPs which reset sessions. I personally
> suspect that reasons are very different and have evolved much earlier
> on, like "we don't want to allow ping scanning to see which hosts are up".

Those are outgoing ICMPs; those are filtered for other reasons,
including router load as well as address scanning. Incoming ICMPs are
either information about the external world (which is good) or attacks
(which is bad).

> way to know what the current or original motivations for filtering ICMPs
> were.  Hence, I'd reword the latter sentence or remove it completely. 
> If rewording, I'd be careful not to imply that the IETF thinks filtering
> all ICMP messages is a valid configuration...

Can you recheck this suggestion in light of RFC4301 and repost?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 10:36:50 -0700

> Pekka Savola wrote:
...
> Those are outgoing ICMPs;

I should have noted some assumptions I was making:
	- ping ICMPs can be incoming
	- anyone doing port scanning can fairly trivially
	do so with non-ICMP sources which rely on ICMP
	replies for rapid operation (i.e., to hit any service,
	not just available ones, or - more easily - to try to
	connect to a typically nonavailable service, e.g., to port 0)

Also, traceroute is useful for mapping enterprises, and these rely on
ICMP replies but not sources as well.

FWIW, I checked a simple case - my Westell DSL modem. When in 'medium or
low secure mode', it drops:

	OUTGOING and INCOMING netbios

	INCOMING source 0.0.0.0

	INCOMING ICMP

(in high-secure it drops everything in both direction that isn't
explicitly allowed; low filters out known attacks and medium allows only
known ports - neither med nor low affect the ICMP rules)

Note - it does NOT drop outgoing ICMPs except in high-security mode.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 29 May 2006 19:54:59 +0100

At Monday 29/05/2006 14:14 +0300, Pekka Savola wrote:
>>2) the text about TTL checking and tunnels not decrementing the TTL 
>>is misleading or incorrect
>
>"or any traffic those nodes accept via tunnels - because tunnels 
>need not decrement TTLs"?  Either way, this gets back to whether 
>your peer is complying to RFC 791, i.e., decrementing the TTL for 
>packets which it forwards.  There is no difference whether the link 
>is physical or an IP tunnel.  Tunnel head-end decrements the TTL if 
>it forwards a packet to the tunnel; tunnel tail-end decrements the 
>TTL if it forwards a packet out of the tunnel.

You don't decrement TTL on packets you forward, you decrement TTL on 
packets you receive. (In RFC791 parlance, receiving the packet begins 
the act of processing it.) It's often viewed as a subtle distinction 
(or just a play on words) until you've written tunnel or endhost 
code, where this distinction does matter.

TTL decrement is specified as always on ingress to the box in the 
RFCs; a packet to be tunnelled has its TTL decremented on ingress to 
the box before being passed to the local tunnel head for encap, and 
that packet then has another decrement after tunnel decap, only after 
it has 'entered' the receiving tail-end as a decapped packet.

In forwarding implementations, many implementations do decrement TTL 
(and fixes the IPv4 checksum) very last thing before the packet is 
forwarded from the box, for performance reasons (the packet may be 
dropped inside the box, so why waste computing effort on a packet 
that will be dropped?). This only works where it is logically 
equivalent to TTL on ingress to the box to match the rfcs and 
interoperate properly with other boxes for traceroute etc. -- and, in 
my experience, the performance-oriented 
decrement-last-wherever-you-leave-the-box code is generally far more 
complex than a simple ingress-on-entry-at-the-chokepoint decrement 
implementation would be.

(Your description also neglects the decrement of TTL in the 
encapsulating tunnel IP header that must also happen when the 
tunnelled packet is received, before decap of the tunnelled packet 
takes place. That's equivalent to an endhost receiving the packet at 
last hop; no further forwarding, but the decrement of TTL must still 
take place. Fixing ICMP reports so that both ends of the tunnel are 
visible and reported in traceroute, rather than the physical 
interfaces on the same box, is also a good idea.)

On the quoted document text below from
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-04.txt

tunnels must decrement TTLs. I hope the note above makes that clear. 
If a packet is received with TTL set to 255 by the previous box, then 
treating decrement-on-ingress and checking once you reach the BGP 
code would really mean you would be checking against TTL 254 -- 
otherwise the original packet must have a TTL of zero that has looped 
around  (and a TTL of zero is not permitted per RFC2003).

In RFC 2003, charlie says:

    When encapsulating a datagram, the TTL in the inner IP header is
    decremented by one if the tunneling is being done as part of
    forwarding the datagram; otherwise, the inner header TTL is not
    changed during encapsulation.

When is tunnelling not a part of forwarding? A hop over a tunnel is 
still a hop, even if you're localhost tunnelling and port forwarding 
to yourself.

>TTL is unchanged for packets at the end which is originating or 
>receiving packets. Exactly like physical interfaces.

if only physical interfaces worked like that, eh?

L.

>Therefore I don't see why it makes sense to make such a big deal 
>about tunnels.  Further, "only where all traffic from the other end 
>of the tunnel is trusted" is misleading at best.  It makes it sound 
>as if transiting traffic (from all over the Internet) at tunnel 
>head-end would need to be trusted if the tunnel head-end is 
>conforming to the specifications.  That's not the case; you only 
>need to trust that the tunnel head-end isn't injecting inappropriate 
>packets (which includes inappropriate modified copies of transited 
>datagrams).  But if the only thing the tunnel head-end can do is to 
>reset its *OWN* (BGP or whatever) link-local session, what's the point?
>
> draft-savola-rtgwg-backbone-attacks-00.txt section 2.1 why this 
> isn't necessarily a big deal for control protocols such as BGP),
>
>  2) the link includes a large number of neighbors (e.g., an 
> internet exchange Ethernet fabric) and other authentication is not used, or
>
>  3) GTSM implementation processes TCP RSTs for GTSM-enabled 
> sessions which have TTL != 255.  The behavior is currently 
> unspecified, but GTSM revision will be looking at this.
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 May 2006 18:40:23 -0700

Lloyd Wood wrote:
>> forwards a packet out of the tunnel.
> 
> the act of processing it.) It's often viewed as a subtle distinction (or
> just a play on words) until you've written tunnel or endhost code, where
> this distinction does matter.

RFC1122 does not specify decrementing the TTL. Only RFC1812 does.

Packets sent host-host do not decrement the TTL, for example.

Host-router-host decrements the TTL by 1.

> TTL decrement is specified as always on ingress to the box in the RFCs;

Which RFCs?

As to tunnels, they are their own animal. They can decrement at the
head, tail, or both; they can also decrement by more than one (to
emulate some of the properties of the path underneath, or to encourage
certain routes). When the packet terminates at the tunnel, it is not
decremented.

In BITW IPsec, the TTL would probably not be decremented at all, nor in
other 'transparent' tunnels.

...
> tunnels must decrement TTLs.

Tunnels do not decrement TTLs; as you noted, that happens after the
decapsulation IF the node is forwarding. If the node terminates the
packet, or if the node is considered a BITW device, it would not
decrement the TTL.

...
> When is tunnelling not a part of forwarding?

A BITW (bump in the wire) isn't forwarding, i.e., when a device has one
input and one output and no forwarding decision is being made.
Encryption devices work this wa.

> A hop over a tunnel is
> still a hop, even if you're localhost tunnelling and port forwarding to
> yourself.

Agreed, but TTL counts forwarding steps, not links, not hops.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 May 2006 22:56:02 -0300

>I'll add a citation to RFC4301, which asserts these reasons (without

That's in the context of IPSec. How much of the traffic in the 
Internet corresponds to IPSec'ed traffic?

Also, from that perspective, the antispoof draft should be one-page 
long, and would just mention something "if you are concerned about 
in-window attacks, use IPSec".

>Can you recheck this suggestion in light of RFC4301 and repost?

IIRC, from the last time I looked at the IPSec specs, there's no 
recommendation on whether to filter or not to filter. The specs just 
state there should be a system toggle to decide what to do, and do 
not even specify what the default should be.

Thus, I don't understand how can you take that as a recommendation 
for ICMP filtering.

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 May 2006 11:34:40 -0700

Fernando Gont wrote:
> That's in the context of IPSec. How much of the traffic in the Internet
> corresponds to IPSec'ed traffic?

IPsec explains security reasons for discarding ICMPs. That's what you're
doing as well.

> in-window attacks, use IPSec".

To the extent that it makes recommendations, it probably is. The rest
explains the attack and other solutions and properties thereof.

>> ICMPs
> state there should be a system toggle to decide what to do, and do not
> even specify what the default should be.

That's correct.

> Thus, I don't understand how can you take that as a recommendation for
> ICMP filtering.

The recommendation is that if you don't trust ICMP, filter it out
entirely. The recommendation comes with the caveat that if you want to
be responsive, you need to accept unauthenticated ICMPs since there is
no way to authenticate them sufficiently. It's a choice that's up to you
- but if you don't trust ICMP, the choice is very clear.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 30 May 2006 13:16:22 -0700

Joe,

>> Thus, I don't understand how can you take that as a recommendation
for
> - but if you don't trust ICMP, the choice is very clear.

My only comment here is that things in our imperfect world
are very rarely black-and-white; they are almost always
shades of gray...

Fred
[email-masked]

---

From: Ted Faber <[email-masked]>
Date: Tue, 30 May 2006 13:27:13 -0700

> - but if you don't trust ICMP, the choice is very clear.

Just for clarity, are you asserting that that recommendation is
articulated by 4301 or that "all right-thinking networkers" should see
it that way?

The as anti-spoof is a TCPM document, recommedations like this are what
we're looking for rough consensus on.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 May 2006 17:15:05 -0700

> articulated by 4301 or that "all right-thinking networkers" should see

I'm saying that the security folk saw it that way.

> we're looking for rough consensus on.

Rough consensus (and running code) are for specs. The doc makes no
recommendations as to how to handle ICMP attacks anyway, so it isn't
clear how that issue applies.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 May 2006 17:27:01 -0700

> are very rarely black-and-white; they are almost always

In IPsec, they're black-and-white on a per-type (MUST) and possibly also
per code (MAY) basis. There are also provisions for dealing with them on
a per-address basis, e.g., to discriminate between addresses inside
trusted domains with presumably trusted paths to the local domain, vs.
others.

However, my commercial DSL box basically just shuts them all off (in
high security mode). This is my understanding of how many firewalls
treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer to
this).

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 30 May 2006 17:45:04 -0700

> I'm saying that the security folk saw it that way.

You're saying that RFC 4301 recommends filtering ICMP if the
administrative domain that controls the filters does not trust ICMP?

You're saying that your sense of the security community is that they
recommend filtering ICMP if the administrative domain that controls the
filters does not trust ICMP?

Or you're saying something else?

> clear how that issue applies.

Rough consensus of the WG is for WG documents; that's why there's a
WGLC.  Rough consensus of the IETF is for standards; that's not required
for (all) Informationals/BCPs.

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 May 2006 18:21:23 -0700

Ted Faber wrote:
...
> Or you're saying something else?

4301 says, basically, that ICMPs present a conundrum:

- accepting them presents a way to degrade service (an attack)

- dropping them degrades service (sort of like you're attacking yourself)

It suggests that dropping ICMPs is also needed inside from 'trusted
domains', since one compromised node can affect others. I.e., there
still needs to be a way to drop the ICMPs, but still dropping is itself
a service issue.

It lets you pick. If the trust of ICMP is the issue, then drop them. If
dropping them is more of an attack, then don't.

---

The key question here is whether there is any real disagreement that
dropping all ICMPs is the first and most prevalent line of defense from
attack. The doc isn't recommending it, but it is stating that. Is that
something we need to have 'rough consensus' on? If so, can some others
please start reading the CAIDA/NLANR/NANOG docs and meeting notes, so we
can proceed?

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 30 May 2006 19:47:08 -0700

> dropping them is more of an attack, then don't.

That's a nice description of the tradeoff that an administrative
domain's administrator could make their decisions from, IMHO.

> attack. The doc isn't recommending it, but it is stating that.

Well, it seems to be a bone of some contention, or I'd be back at the
WG chairs' palace indulging in all sorts of IETF-financed debauchery
instead of typing an e-mail by fading daylight in an ISI oubliette,
trying to clarify the issue.

It seems logical to me that blocking ICMP would be the first thing to do
if you distrusted those messages, but I can also imagine mitigating
circumstances that would lead admins to make their borders more porous.
The world is weirder than I'd like it to be.

It seems certain that some admins will block all ICMP to deal with
concerns about ICMP.  Is this a key issue in the document?  Is it
important to make the stronger case that this is the prevalent
condition?  What happens if that changes tomorrow?  Do the document's
claims change fundamentally?  If not, why not omit the prevalence claim
and describe ICMP blocking as a common (or logical) defense having the
drawbacks you describe clearly above?

If it matters, lets get at the truth.  If it doesn't, we have no
shortage of arguments in this group.

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 May 2006 21:34:07 -0700

> drawbacks you describe clearly above?

That's what I would suggest. Mitigated blocking - by opening up on type,
type+code, or making it TCP-connection context-dependent are all
variants of opening things up that should be noted there.

> shortage of arguments in this group.

Agreed.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 May 2006 09:40:33 +0300 (EEST)

> and let us know if there is still an inconsistency?

In my opinion, RFC 2003 section 3.1 (specifically the third-to-last 
and second-to-last paragraphs) says exactly the same thing as I say. 
The TTL is decremented if tunneling is a step in forwarding a 
datagram, not otherwise.  Just like with a physical interface.  The 
bottom line is that a compliant RFC 2003 encapsulator will decrement 
TTL for packets which it forwards.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 May 2006 10:13:32 +0300 (EEST)

> It would be useful to provide candidate substitute text.

In fact, I already did in my last round of comments, so I didn't 
re-post it.  For convenience, I'll put that at the end of this note.

> Can you explain how to provide filtering in this case?

In the interfaces towards upstream, in input filter, block your own or 
your singlehomed customers' IP addresses from being used as source 
addresses.

This does not provide spoofing filtering for sources which are 
legitimately upstream, but it does prevent from TCP-RST attacks from 
upstream for sessions which are internal your network, which is what 
I've been saying.  We've been doing this (and a lot of other 
filtering) for years.

> that small fraction of connections is not sufficient.

100% of iBGP, (non-discovery) LDP, telnet/SSH to the routers, or 
various other infrastructure uses are internal by that definition. 
Which is my point -- in some cases, it's an invaluable tool.

I don't know that percentage, I'd assume it varies greatly depending 
on the region you're in, the size of the ISP, the application you're 
using (e.g., peer-to-peer has much higher rate), etc.

(In practice, the practical non-spoofing boundary might be even wider, 
because at least some countries even have regulations which require 
spoofing prevention, so even all the internal traffic could end up 
being protected.)

> sessions treat the net as a stub).

Certainly.  ISP case above is just a generalization of that.

However, my point is that while that might not protect from sessions 
from the site to www.google.com, it could protect from various 
internal communications from outsider interference, or even spoofing 
inside the site if ingress filtering is applied on every link inside 
the site.

> single-homed, but the larger issue is the percent of internal traffic.

The actual amount is not important, it's sufficient that we agree that 
most users are single-homed.  I also agree that the much larger issue 
is the percentage of internal traffic.  As I said, it varies a LOT. 
But it's indisputable that there are very important (e.g., 
infrastructure, server-to-server or router-to-router communications, 
etc.) uses that ARE in fact strictly internal.  The presence of these 
alone is IMHO sufficient justification of properly discussing address 
filtering.

> party one stream up to filter - even for BGP.

BGP has at least two things to secure: the transport protocol (e.g., 
TCP layer) and the routing data itself.  The TCP layer of internal BGP 
sessions can be completely protected with address filtering.  The TCP 
layer of external BGP sessions can be almost completely protected by 
address/TTL filtering.

The routing data protection is out of scope of this WG, but in fact, 
the same basic route hijacking prevention techniques apply.  For more 
general BGP routing data protection, RPSL and friedns have been used 
in some parts of the world, but there is not SIDR WG which is looking 
at this from certificate point of view.

[*] -- copy from the comments on -02 which suggested text:

"
...  In order to try to converge on the text faster, let me try to suggest
text which I think should be more accurate and I'd find acceptable.

================
3.2. Network Layer (IP) Solutions

    There are two primary variants of network layer solutions to
    spoofing: address filtering and IPsec. Address filtering provides
    protection from spoofing for sessions which are internal to the set
    of domains where address filtering is applied.  IPsec requires
    cooperation between the
    endpoints wanting to avoid attack on their connection, which
    currently involves pre-existing shared knowledge of either a shared
    key or shared certificate authority.

3.2.1. Address and TTL filtering

    Address filtering is often proposed as an alternative to protocol
    mechanisms to defeat IP source address spoofing [2][12].

    Address filtering is deployed both at the downstream interfaces and at
    the upstream/peer interfaces.  The former prevents all spoofing from the
    downstream direction; the latter prevents only upstream sources from
    spoofing your (or your downstreams') source addresses.
    Each border router should perform the appropriate filtering for overall
    protection to result; failure of any border router to filter opens a
    hole inside that border.

    Address filtering at the border can protect those inside it
    from some kinds of spoofing, because only interior addresses should
    originate inside the border. It cannot, however, protect connections
    originating outside the border except to restrict where the traffic
    enters from, e.g., if it expected from one AS and not another.

    As a result, address filtering can be deployed locally but it only
    protects communications where both parties are local.  Therefore, the
    larger the address filtering border is, the more extensive the protection
    is.  This is a particularly useful means of protection for specific kinds
    of sessions which are known to be local.  However, as address filtering
    is performed in the network by trusted gateways, the users not know
    whether the filtering exists or not.  Hence, the users cannot rely on it
    in general and other mechanisms for protection must be used as well.
    Still, address filtering is very useful to protect specific kinds of
    communications (e.g., network management, most router-to-router
    communication, etc.).

    relying on the TTL set by the other end of the connection [14]. This
    router's peer).

    This method of filtering works best where traffic originates one hop
    away, so that the address filtering is based on the trust of only
    directly-connected (tunneled or otherwise) nodes. Like conventional
    address filtering, this light-weight mechanism reduces spoofing
    traffic in general and provides a reliable security mechanism if peer
    can be trusted to operate correctly (see Section 5.1 of [14]).  On the
    other hand, if the peer does not operate correctly, it is just shooting
    itself in the foot by allowing its sessios to be reset.
================
"

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 May 2006 07:28:20 -0700

Pekka Savola wrote:
> In my opinion, RFC 2003 section 3.1 (specifically the third-to-last and
> second-to-last paragraphs) says exactly the same thing as I say. The TTL
> is decremented if tunneling is a step in forwarding a datagram, not
> otherwise.  Just like with a physical interface.  The bottom line is
> that a compliant RFC 2003 encapsulator will decrement TTL for packets
> which it forwards.

(presumably you mean decapsulator, not the encapsulator)

RFC2003, sec 3.1, third-to-last (emphasis mine):

   When encapsulating a datagram, the TTL in the inner IP header is
   decremented by one **if the tunneling is being done as part of
   forwarding the datagram**; **otherwise, the inner header TTL is not
   changed during encapsulation**.  If the resulting TTL in the inner IP
   header is 0, the datagram is discarded and an ICMP Time Exceeded
   message SHOULD be returned to the sender.  An encapsulator MUST NOT
   encapsulate a datagram with TTL = 0.

If that packet is generated at that node, or if the packet is sent to
the tunnel in a non-forwarding (BITW) step, that decrement would not happen.

   The TTL in the inner IP header is **not changed when decapsulating**.
   If, after decapsulation, the inner datagram has TTL = 0, the
   decapsulator MUST discard the datagram. If, after decapsulation, the
   decapsulator forwards the datagram to one of its network interfaces,
   **it will decrement the TTL as a result of doing normal IP forwarding**.
   See also Section 4.4.

The decapsulator decrements only if forwarding - again, if the packet
stops at the destination or if the device isn't a forwarder (BITW), that
wouldn't happen.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 May 2006 08:16:55 -0700

Joe,

> treat ICMPs (CAIDA papers, NLANR papers, NANOG discussions all refer
to

To clarify then, does this mean that RFC1191 PMTUD is basically
broken for nodes that sit behind commercial DSL boxes and many
firewalls? I know that RFC2923 documents operational issues for
PMTUD for some middleboxes that filter ICMPs, but I did not
understand that the problems were so wide-spread.

Should we basically consider that RFC1191 is broken for
practical purposes?

Fred

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 May 2006 08:34:41 -0700

Templin, Fred L wrote:
> firewalls?

Yes - that's what the more recent PMTUD WG is trying to fix using
postive feedback rather than the lack of negative feedback.

> I know that RFC2923 documents operational issues for

See the PMTUD WG docs ;-)

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 31 May 2006 08:44:38 -0700

Joe,

I know very well about the PMTUD WG documents, but that spec
also talks about judicious treatment of ICMPs. I still say
that we don't live in a black-and-white world and feedback
should be considered before it is summarily ignored. (This
is after having argued for ignoring all ICMPs in the past.)

Fred

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2006 8:35 AM
To: Templin, Fred L
Cc: Fernando Gont; [email-masked]
Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 31 May 2006 08:51:16 -0700

> is after having argued for ignoring all ICMPs in the past.)

What we should do and what is done are two different things. I'm not
arguing in this doc that dropping all ICMPs is a preferred, but rather
more prevalent solution.

Until we have a more protected infrastructure and signalling protocols,
that's not likely to change.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 31 May 2006 20:28:33 -0300

>- dropping them degrades service (sort of like you're attacking yourself)

The issue is that if you're securing a connection with IPSec, you 
require authentication for the packets that correspond to the 
connection, but you cannot enforce the same for the ICMP error 
messages that refer to that connection. In *that* case, you *may* 
choose either to drop ICMPs.

RFC 4301 leaves it up to the administrator.

And it makes it clear that in the case of PMTUD, you're in trouble. 
IIRC, it sort of suggest to honor the "frag needed" messages but 
enforce a lower limit for the Path-MTU.

I'd not take that as a recommendation to "drop all ICMPs".

Now, in the case on non IPSec'ed connections, what's it that makes 
you trust a TCP segment, but not an ICMP error message?
The TCP segments are not authenticated, either.

Yes, there are issues in the ICMP specs that need to be fixed.
Clearly, the specs should have always required ICMP error messages to 
be in-window.

>attack. The doc isn't recommending it, but it is stating that.

That's your assumption.

The most prevalent defense against ICMP-based connection-reset 
attacks is simply to take the hard errors as a hint, for example.

Again, run traceroute or ping. That will give you a hint to what 
extent there's a prevalence of "drop all ICMPs".

>Is that

I cannot understand why you oppose so much to performing checks on 
ICMP messages and taking the error messages as "hints", and at the 
same time encourage (one way or the other) people to drop all ICMPs.

If you like have you system abort connection upon receipt of ICMP 
error messages, just hack your kernel code, and you're done.
If such filtering gets widely deployed, then it would be almost 
impossible to go back on one's steps.

Kindest regards,