Subject: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 12 Feb 2010 21:27:49 -0500

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

ICMP is one of those IP layer protocols that we all have some idea
exist even if only the network level people understand what they do.
This document is designed to describe security issues arising from the
ICMP protocol and commonly implemented counter-measures.

The principal security risks considered are service risks. ICMP may be
used to perform certain denial of service and performance downgrade
attacks. As such it probably needs rather more justification than 'we
have always done this' when building critical infrastructures.

Overall,

Given that TCP streams will eventually time-out, I have something of a
hard time seeing why we would be using a non-authenticated control
protocol at all. Yes, I know the legacy reasons etc. etc. But this is
not the way we would approach this problem today. This argument is
almost made on page 15. Some statement giving the case for taking
notice of ICMP messages at all is in order. It might well be that an
appropriate control in certain cases would be to turn off ICMP hard
errors and rely on timeouts, I am thinking here of critical
infrastructure applications and communications between hosts running
BGP functions.

In particular I note that the draft says "It is interesting to note
that, as ICMP error messages are transmitted unreliably, transport
protocols should not depend on them for correct functioning."

Given the extreme approach to security of starting from nothing and
only adding systems that are essential, this would seem to suggest
ICMP is not necessary and could be eliminated. There may be a case to
the contrary but it needs to be made before page 15.

Page 15/16

The following phrase repeats in a way that suggests an editing oversight:
aborting the
   connection would be to ignore the valuable feature of the Internet
   that for many internal failures it reconstructs its function without
   any disruption of the end points

Page 24-26

A more general way of describing the mitigation strategy would be to
point out the general principle that error messages may be ignored
whenever a packet indicating success is received within the timeout
window. In other words no final processing decisions should be made on
an unauthenticated ICMP packet until after the timeout window expires.

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Feb 2010 10:18:34 +0200

Hi, authors/WG,

please discuss the secdir review. I'll leave the document on the IESG agenda for Thursday for now.

Lars

On 2010-2-13, at 4:27, Phillip Hallam-Baker wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2010 16:49:32 -0300

Hello, Phillip,

Thanks so much for your feedback! See my comments inline....

> have always done this' when building critical infrastructures.

I fully agree. This I-D has been debated in tcpm form... 6 years now. It
was originally meant for Std track, but somehow ended up heading for
Informational. What's in the I-D is what most implementation (all the
mainstream ones, at least) do.

So if *I* had to answer why we don't stress that ICMP should be
disregarded in many scenarios, etc., I can just say that this is what
the WG has converged to.

> not the way we would approach this problem today. 

I fully agree.

> This argument is
> notice of ICMP messages at all is in order. 

I guess the "statement" that you could get here (tcpm) is
"responsiveness". -- with which I'd disagree, for many of the reasons
stated in the draft, and because in many other cases it has been argued
in this very wg that "tcp is supposed to be robust, it's not optimized
for any scenario, etc.".

Should I craft some text along the lines of "responsiveness"?

> It might well be that an

Most (if not all) real-world implementations already do this. We have
lived with this behaviour that you describe for the last..mm.. 20 years
(or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco,
or whoever are going to change back their implementations to e.g.
"resetting connections in response to ICMP hard errors". For instance,
they have issued vulnerability advisories in this respect...

> ICMP is not necessary and could be eliminated. 

Yes...except for ICMP "frag needed but DF bit set", which is needed for
PMTUD.

> There may be a case to

My take is "responsiveness". But I'll let the wg chime in. :-)

>    any disruption of the end points

Sorry... I wasn't able to catch the "oversight" you refer to...  :-(

> an unauthenticated ICMP packet until after the timeout window expires.

Section 7.2 already states:
"  The
   described mechanism basically disregards ICMP messages when a
   connection makes progress, without violating any of the requirements
   stated in [RFC1191] and [RFC1981]."

Please let me know if this text addresses your comment, or whether you
think I should craft another paragraph mentioning that of "ignore
messages whenever a packet indicating progress is received".

Thanks!

Kind 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: Mon, 15 Feb 2010 12:08:26 -0800

Fernando Gont wrote:
> Informational.

That implies the decision was either accidental or unintentional, and
neither is the case, FWIW.

> What's in the I-D is what most implementation (all the

This is what the WG *decided*. "Converged to" similarly implies lack of
deliberate decision, which was not the case.

>> not the way we would approach this problem today. 

Not all TCP state times out. Connections that don't use keepalives will
retain stale state until the state is explicitly flushed by a RST. If
the other end never comes back up, the state *never* gets flushed if not
for ICMPs.

It'd be an interesting question to ask whether we could do without ICMPs
altogether, but that is not addressed sufficiently in this doc to make
such a conclusion, IMO.

> Should I craft some text along the lines of "responsiveness"?

This doc, by WG agreement, focuses on "what is". It is not intended to
make broader recommendations or conclusions.

> they have issued vulnerability advisories in this respect...

KARP is addressing some of these issues. TCP-AO also addresses these
issues in the context of BGP.

It's difficult to argue for broader controls of ICMPs in the absence of
authentication at the IP or TCP level, since RSTs have just as injurious
an impact.

> Yes...except for ICMP "frag needed but DF bit set", which is needed for

Well, if we're going to pick, PMTUD based on ICMP should be replaced
with PLPMTUD. However, again, this level of recommendation is out of
scope for this doc, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2010 17:30:00 -0300

> neither is the case, FWIW.

Well, if you track the decision, you'll probably go back to an IETF
meeting in 2005 (Vancouver), in which, while we were heading for Std.
Track, somebody asked "Why not Informational?", and that's what we ended
up doing. So...

> deliberate decision, which was not the case.

FWIW, this is what was decided (IIRC) at the IETF Vancouver in 2005. And
as a result of what I already considered at the time an excessive
expenditure of energy :-), didn't fight that much.

> the other end never comes back up, the state *never* gets flushed if not

The TCP spec says that "ICMP hard errors should be processes as RSTs",
but never describe a case in which a TCP would send an ICMP hard error
instead of a RST.

If you ever get an ICMP hard error, it's probably because of a firewall.
And many of these devices do not even check the TCP checksum. So you may
end up resetting a connection in response to an ICMP hard error elicited
by a corrupted TCP segment. That is, honoring ICMPs makes TCP less robust.

That said, at this point in time all this has already been discussed. So
I just want to finish the I-D. So at this point in time, whatever
addresses the raised issues would do for me.

And, if you really depend on anything to flush stale connections, you're
vulnerable to a bunch of other attacks (Sockstress, and the rest of the
stuff that is already discussed in the CPNI TCP security paper).

> make broader recommendations or conclusions.

This doc has probably been one of the best examples for the recent flood
of messages on the WG.

> authentication at the IP or TCP level, since RSTs have just as injurious

C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've
been here before. So the ICMP attack vector is the low hanging fruit.

> with PLPMTUD. However, again, this level of recommendation is out of

I already tried this one, and e.g., Linux developers already refused to
do so, as a result of "convergence time" reasons.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Feb 2010 12:45:36 -0800

> Track, somebody asked "Why not Informational?", and that's what we ended

That decision was discussed at length at multiple IETFs. It didn't
happen as an accident or by the direct consequence of a single
off-handed suggestion.

...
> but never describe a case in which a TCP would send an ICMP hard error

If frag is needed, you can't get a RST since the packet never gets
there. If the port is blocked upstream of the end device, the same thing
happens. Your next sentence appears to assert that the latter is the
common case.

> If you ever get an ICMP hard error, it's probably because of a firewall.

If it's after a connection is established, it's likely because of a
change in path that has different firewall policy or MTU.

> And many of these devices do not even check the TCP checksum.

Nor should they. The ICMP packet isn't required to include the entire
TCP segment, and when it doesn't it *can't* verify the checksum anyway.
...
> stuff that is already discussed in the CPNI TCP security paper).

My point was simply that TCP doesn't always clean itself up via
timeouts. That could be changed, but requires a change to the TCP spec
to, e.g., require all TCP connections to default to "keepalive", and
that hasn't been discussed.

> been here before. So the ICMP attack vector is the low hanging fruit.

There are numerous ways to upset a TCP connection by injecting bad data,
causing it to emit extra ACKs, etc. And the difference between in and
not-in window has become much less relevant.

(e.g., if "in window" was sufficient, then you should be arguing to stop
work on TCP-SECURE).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Feb 2010 18:08:41 -0300

> happen as an accident or by the direct consequence of a single

I disagree. But at this point in time, this is off-topic.

>> but never describe a case in which a TCP would send an ICMP hard error

I already argued that the only ICMPs that you really need are the "frag
needed" ones.

> happens. Your next sentence appears to assert that the latter is the

If the packet had elicited an RST if it had been received at the
intended destination, the connection will probably time-out (i.e., it
was a data segment... unless you're implying that a simple ACK does not
fit into the PMTU).

> change in path that has different firewall policy or MTU.

Exactly. In which case that should be a *soft* error (who said the path
is not going to change back to the old one?).

> TCP segment, and when it doesn't it *can't* verify the checksum anyway.

Exactly. And this hurts the precious TCP robustness you have always been
defending.

> that hasn't been discussed.

Keepalives are not even part of the spec.

> not-in window has become much less relevant.

ICMP's are one of the only two vectors that can reset connections
without being required a matching SEQ. -- the other one being the ToS
and Precedence level, as discussed in the CPNI document.

IMO, in-window vs. oo-window does make a difference. For instance, the
whole press that these issues got back in 2004 is because people had got
the numbers wrong in their calculations of "number of packets needed".
This is essentially the "new thing" that Paul Watson pointed out back in
2004.

Anyway: For the most part I'm wondering if there's any additional text
needed to address Phillip's comments. Thoughts? This should be our focus
at this point in time.

Thanks,

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 15 Feb 2010 14:32:17 -0800

Some general comments on this discussion inline...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fernando Gont
> Sent: Monday, February 15, 2010 11:50 AM
> To: Phillip Hallam-Baker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcpm] SECDIR REVIEW of 
> draft-ietf-tcpm-icmp-attacks-10.txt
> 
> Hello, Phillip,
> 
> I fully agree. This I-D has been debated in tcpm form... 6 
> years now. It was originally meant for Std track, but somehow 
> ended up heading for Informational. What's in the I-D is what 
> most implementation (all the mainstream ones, at least) do.

That is true. Many implementations already do what is being said in this
ID. 

> 
> So if *I* had to answer why we don't stress that ICMP should 
> be disregarded in many scenarios, etc., I can just say that 
> this is what the WG has converged to.

I think you should put some text to this effect. IMO, we don't have an
overwhelming consensus on whether this document should be informational
or standard. To me, I have no issues making this head towards the PS,
one of the main reasons being it has been well adopted in the internet
today. I also agree that "just being popular" doesn't imply that it
needs to become a standard. In this case it is not only popular, these
mitigations have more pros than cons.

<snip>

> "responsiveness". -- with which I'd disagree, for many of the 
> reasons stated in the draft, and because in many other cases 
> it has been argued in this very wg that "tcp is supposed to 
> be robust, it's not optimized for any scenario, etc.".
> 

That may be a good idea.

> Most (if not all) real-world implementations already do this. 
> We have lived with this behaviour that you describe for the 
> last..mm.. 20 years (or so) with BSDs... and there's no way 
> that BSDs, or Linux, or Cisco, or whoever are going to change 
> back their implementations to e.g.
> "resetting connections in response to ICMP hard errors". For 
> instance, they have issued vulnerability advisories in this respect...

Correct.

Thanks,
-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Feb 2010 08:44:24 -0800

Fernando Gont wrote:
...
> needed to address Phillip's comments. Thoughts? This should be our focus

There were two separate points raised, IMO:

- clarification of the role of this doc's recommendations
	The WG was aware of this issue, and there was
	a lot of effort in creating the existing text that
	already considered this perspective. No change needed.

- addressing the larger issue of the role/need of ICMPs
	This is out of scope for this doc. No change needed.

Overall, I think there isn't a need for a change.

Joe

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 16 Feb 2010 09:47:02 -0800

> Behalf Of Joe Touch
> Sent: Tuesday, February 16, 2010 8:44 AM
> To: Fernando Gont
> Cc: [email-masked]; Phillip Hallam-Baker; [email-masked]
> > needed to address Phillip's comments. Thoughts? This should be our 
> > focus at this point in time.
> 

I would still think there is some text needed which explains (in a
sentence or two) the role of this documents recommendations. Atleast
explain why the target was chosen to be "informational" at this point of
time. Would help a lot of readers/implementers down the line since this
question would keep coming. But that's just me, if the consensus is to
not add anything I am fine too.

-Anantha

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Feb 2010 09:51:58 -0800

> not add anything I am fine too.

The role is basically limited to 'documenting what is deployed', which
is summarized fairly directly in the abstract.

The specific recommendation made towards the end of the intro reiterates
that.

I.e., this is not a new issue, and it's something for which there is
specific text already.

I think it answers the mail on that point.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2010 12:52:59 -0500

When a document becomes an RFC it is read as a stand alone document
and not in the context of the working group discussions that may have
ended years ago.

If a particular security issue has not been discussed because it was
out of scope, that should be given as the reason that it is not
discussed.

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Feb 2010 09:59:41 -0800

> out of scope, that should be given as the reason that it is not

That seems worthwhile to include IMO, esp. as a response to SECDIR review.

Joe