Subject: Re: [tcpm] Re: WGLC on antispoof -- ICMP filtering speculation

From: Joe Touch <[email-masked]>
Date: Wed, 31 May 2006 21:19:32 -0700

Fernando Gont wrote:
> At 22:21 30/05/2006, Joe Touch 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)
> 
> 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".

The doc is clear IMO that if accepting unauthenticated ICMPs is more of
an attack than dropping ICMPs, then drop.

PMTUD is a problem in that case; that's the purpose of the solutions
being discussed in the PMTUD WG which don't rely on ICMP.

> 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?

In some cases, it's the partial deployment of ingress filtering. It'd be
harder to spoof a TCP segment from a particular source than an ICMP from
an arbitrary node on the path. In other cases it's the presence of TCP
authentication data (e.g., TCP/MD5). Finally, the TCP checksum (see below).

> The TCP segments are not authenticated, either.

They can be.

> 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.

TCP specs are very clear - and we've gone over this too - that it's
inappropriate to parse the TCP header if the checksum isn't correct. For
ICMP messages with intact TCP segments, yes, in-window makes sense.

>> 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.
> 
> That's your assumption.

I gave the general citations that talk about firewalls blocking all
ICMPs - CAIDA, NLANR, and NANOG all mention it repeatedly enough that a
citation itself should not be necessary.

> 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".

The trouble with both NATs and firewalls is that you don't see what's
behind them. It's hard to count what you can't see.

>> 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?
> 
> 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.

The scenarios differ. TCP-antispoof is about TCP under attack. The doc
already shows that such attacks are likely only when both endpoint IP
addresses and the service address are known; that's not the case except
for routing protocols and some network services (proxy-proxy).

Yes, if those systems are under attack, they ought to run with very
small packet sizes (to minimize PMTU issues) and drop all ICMPs. That
behavior is consistent with existing specs - it takes a SHOULD down to
MUST NOT but only under very specific conditions.

No, the rest of us don't need to do that. That would take the SHOULD to
a MUST NOT for all, which would be a change to the standards. I don't
see a reason to change the standards on this point at this time.

As to hints, then you can't eat your cake and have it too. If you want
to parse the TCP header, then follow TCP rules - if the checksum isn't
valid, you shouldn't be parsing it, period. And as to the rest of the
hints, they're based on the assumption that everything you don't expect
is an attack - which is NOT what this doc is discussing. This doc is
discussing a system under attack.

Joe

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 1 Jun 2006 13:30:16 +0300 (EEST)

On Wed, 31 May 2006, Joe Touch wrote:
>> On Mon, 29 May 2006, Joe Touch wrote:
>>>>
>>>> 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.
>>>
>>> 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?
>>
>> 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)

Both will decrement TTL when forwarding, but encapsulator is of 
(security) interest here.

> 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.

That's an interesting interpretation.  Mine would be that it's just a 
choice of words to refer to forwarding.  BITW is similar to L2 
encapsulation of IP datagrams in this context in the sense that the 
encapsulator is invisible from the IP layer perspective.  I doubt RFC 
2003 was even intended to cover BITW implementations.

It'd probably make sense to continue this discussion on int-area list.

-- 
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: Fri, 2 Jun 2006 09:08:26 +0300 (EEST)

On Mon, 29 May 2006, Joe Touch wrote:
>>    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.
>
> I'll add a citation to RFC4301, which asserts these reasons (without
> citation, FWIW).

If you said "[RFC4301] speculates that" instead of "As a result," it 
would be better.  Any language that makes it clear that we're not 
talking about hard facts would be an improvement.

As for the other statement in the next messages of the thread:
>> Just for clarity, are you asserting that that recommendation is
>> articulated by 4301 or that "all right-thinking networkers" should see
>> it that way?
>
>I'm saying that the security folk saw it that way.

That's a big generalization.  "Security folks" is a much wider set of 
people who were actively involved with RFC 4301.  In many security 
people's minds, IPsec is not useful for much more than creating VPNs 
(the author of said specifications excluded).  Look no further than 
the recent discussion on SAAG for this.  Hence 4301's recommendations 
(or more correctly lack thereof) of ICMP processing are in real world 
only applicable in the context of VPNs.

Hence, while RFC 4301 does include some useful discussion on this, I 
don't think there are any conclusions there that would be useful in 
any way in determining TCP's ICMP processing approach.

>> 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).

The above text can be read to apply to either or both of inbound and 
outbound ICMP filtering.  The text does not make any sense for 
outbound ICMPs though, for many reasons [1].

I also do not agree with your observation that outgoing ICMPs are 
generally blocked. I might agree with that in some high-security 
environments, where typically also all the other outgoing traffic 
(excluding exceptions, proxies, etc.) is blocked.

[1] such as:
  - the only reason I can think of to block outgoing ICMPs at site edge 
is to prevent revealing information about the topology, hosts, etc. of 
the site.  That's not the reason you're citing.
  - why should the originator of ICMP errors care whether the recipient 
can process them (or not)?  It's the recipient's problem to decide 
whether the error message is to be accepted.
  - if your site is originating ICMP errors, especially if the site 
employs ingress filtering, it can perform address filtering (source 
address) on those errors.

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Jun 2006 07:15:14 -0700

> talking about hard facts would be an improvement.

Sure.

> people who were actively involved with RFC 4301. 

Yes. The security folks involved in 4301 saw that the broader set of
security folks are doing things this way.

There are numerous references in CAIDA and NLANR docs regarding ICMP
blocking, the same for NANOG proceedings. 4301's discussion of ICMP
processing reflects that community consensus.

Further, whether some people believe that IPsec is only for VPNs, that
is not what IPsec is designed for. IPsec is designed precisely for some
of the uses that we're talking about - securing host-host transmission
(which isn't a VPN); that's what transport mode is all about.

..
> don't think there are any conclusions there that would be useful in any
> way in determining TCP's ICMP processing approach.

If we make security recommendations about ICMP, we need to either cite
what SAAG has issued on this topic or consult them IMO.

Otherwise we're asserting that we know better. Your note above is
equivalent to SAAG members saying that what we decide in TSVWG about
transport protocols should be dismissed ikn their groups because it
focuses only on the limited uses of TCP - since there's plenty of people
in TSVWG who don't think that TCP is sufficient for many applications
(SCTP, DCCP, RTP).

> outbound ICMP filtering.  The text does not make any sense for outbound
> ICMPs though, for many reasons [1].
> 

That should be noted in the doc, and is the reason I cited in an earlier
reply.

> whether the error message is to be accepted.

Liability. ISPs and enterprises don't want stuff they can't validate
leaking out.

> address) on those errors.

It needs to perform that filtering on the contents, not just the ICMP
headers. That's possible, but not how things typically work now - the
switch is more likely be set to 'block all'.

My firewall box drops ICMPs out in low protection mode, but drops all in
medium and high mode (I had thought it was only in high mode; the rule
that made it happen was obscure).

Home firewall boxes aren't ultra-high security devices, and yet in 2 of
3 modes it blocks incoming and outgoing ICMPs. In one case all suspect
ports are blocked, in the other only a fixed subset of ports is allowed.
That's not different from the way things are blocked at enterprise
networks either.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Sat, 3 Jun 2006 12:45:35 +0300 (EEST)

Hi,

Maybe we should try to end this thread soon, as the issue seemed to be 
only about one sentence implying what the reasons for some peoples' 
ICMP filtering to be.  I don't see how those are relevant to this 
document, so the easiest way to avoid controversy could probably be to 
avoid such statements..

Inline,

> processing reflects that community consensus.

It's well known that there's a lot (though still in the vast minority 
I think) of ICMP blocking out there, but I'd be very careful before 
making any conclusions as to why people (or vendors) have done that.

I think you may be over-generalizing.  4301's discussion of ICMP 
processing is in the context of 4301.  Making conclusions based what 
IPsec folks chose to do (basically just provide a toggle, without 
indicating a default) for IPsec-protected sessions probably does not 
apply to TCP, or anything that doesn't relate to IPsec for that 
matter.

> (which isn't a VPN); that's what transport mode is all about.

Though such uses have seen little (or spotty at best) deployment 
(AFAICS), and in fact I think the main use of transport mode nowadays 
is to security gateways and between security gateways (e.g., to 
protect GRE tunnels).

> in TSVWG who don't think that TCP is sufficient for many applications

I hope you know that getting a consensus statement out of SAAG would 
take 6 months (minimum), if we'd even be able to obtain one. :-)

But I agree that wider review could be useful if folks are realistic 
and agree that we aren't going to get a consunsus statement on this.
I'd suggest one or multiple of the following:

  - when requesting publication of the document, ask the AD to issue 
IETF LC for this document
  - after requesting publication of the document or after the next 
revision, solicit explicit feedback from the security ADs and the 
security directorate.
  - send an open query to SAAG list (IMHO which I doubt is very useful)

> Liability. ISPs and enterprises don't want stuff they can't validate

I don't understand this from the practical point of view, and 
certainly not for ISPs.  Are you referring to financial liability if 
said outgoing ICMPs were an attack?  This doesn't seem to be a very 
common concern, but nonetheless this is somewhat understandable if and 
only if the enterprise also blocks all the other (modulo few 
exceptions) outgoing traffic.  And in that case, this issue is in no 
way ICMP-specific, so we can't make conclusions about such ICMP 
blocking.

> switch is more likely be set to 'block all'.

I guess this gets back to the liability point above.  Otherwise 
validating the contents of _outgoing_ ICMPs doesn't make any sense at 
all.

On the other hand, I'd say there are a lot reasons to block incoming 
ICMPs, or possibly validate their contexts.  I suspect the motivations 
are very different.