Subject: [tcpm] comments on draft-ietf-tcpm-icmp-attacks-05

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 10 Jun 2009 23:25:15 -0500

As a WG participant (not co-chair), here are some
comments I have after reading the latest version
of the ICMP attacks draft:

1) (editorial) In Section 2.1, don't capitalize
"Architecture", as it makes "Internet Architecture"
look like some kind of specific proper noun, which
it definitely isn't.

2) (question) In Section 2.1, we have:
"When an intermediate router detects a network
problem while trying to forward an IP packet,
it will usually send an ICMP ..."  Do we
want "will usually" or "has the option to", or
something similar?  I'm not aware of the actual
statistics on this.

3) (editorial) In Section 3, first sentence,
"internet header" -> "IP header" ?

4) (technical) For the last paragraph in section
3, we focus on the lack of IKE usage as a reason
why IPsec can't generally be used to authenticate
ICMP messages, but I think the bigger problem is
that even if we all ran IPsec, we'd need to have
routers using certificates with paths compatible
for all other hosts on the network ... not too
feasible from what I can tell.  I think this is
more difficult than either the deployment or the
embedded devices issue that the draft mentions.

5) (general) Section 5.1, last paragraph, it
seems like we should be mentioning TCP-AO as
well here, though I don't think it changes any
part of the claim.

6) (editorial) Section 5.2, typo "preferebable"

7) (editorial) Section 6.2, "On the other hand,
TCP implements its own congestion control
mechanisms ..." ... I don't think this is
really an "on the other hand", I think it's
more of a "Furthermore".

8) (general) In Section 6.2, I think we can be
stronger and say that the 1122 requirement to
react to source quench is no longer pertinent,
as the Internet has moved well beyond needing
this.

9) (general) Wow, section 7 takes a much closer
look at PMTUD than I ever expected to find here;
roughly half the document sits in this topic
alone.  Is this *really* an attack that we're
that worried about in a general case?  

The modifications in this part of the document
seem too complex for what they buy, to me.  It
seems like in places where there's concern about
it, we can just say to ignore these ICMPs and use
the PLPMTUD (4821) instead.  I can understand
that what's in the draft has been implemented,
but how valuable is it really when we already
have a Proposed Standard in PLPMTUD that can
totally answer to this concern by just ignoring
the ICMPs in question?

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 10 Jun 2009 23:32:57 -0500

As both co-chair and TCPM participant, I'm not really
comfortable with Appendix B of this document which
reads a lot like an advertisement.  Even though I
know it's well-intentioned, it seems like we'd set
a bad precedent if we got into the habit of putting
sponsor-plugs into the appendices of our documents.
I don't think we lose anything by leaving that
appendix out completely.

What does the WG think?

To speed analysis, the text in question is:

Appendix B. Advice and guidance to vendors

   Vendors are urged to contact CPNI ([email-masked]) if they
   think they may be affected by the issues described in this document.
   As the lead coordination center for these issues, CPNI is well placed
   to give advice and guidance as required.

   CPNI works extensively with government departments and agencies,
   commercial organizations and the academic community to research
   vulnerabilities and potential threats to IT systems especially where
   they may have an impact on Critical National Infrastructure's (CNI).

   Other ways to contact CPNI, plus CPNI's PGP public key, are available
   at http://www.cpni.gov.uk .

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 10 Jun 2009 23:45:59 -0500

As both a WG-participant and co-chair, I think that the
Appendix A explanations of which ICMPs need to be paid
attention to because some of them say things that I'm
not sure are totally supported by prior RFCs.  For
instance, I'm not certain that setting the DF bit is
only possible for hosts that support PMTUD ... is there
a reference for that?  Further, it discusses ambiguity
in 1122, that we should be clarifying in the main text
rather than an appendix, I think ... what does the rest
of the WG think?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Jun 2009 05:22:46 -0300

Hello, Wesley,

Thanks so much for your feedback. Comments-inline...

> look like some kind of specific proper noun, which

I think this was capitalized in Dave's Clark paper. But have no problem
with the proposed change.

> something similar?  I'm not aware of the actual

The router will send an ICMP error message, unless rate-limiting
prevents it. That's my understanding. And this is what RFC 1812 states.

> "internet header" -> "IP header" ?

Will do. (Although the ICMP spec uses the term "internet header" rather
than "IP header").

> for all other hosts on the network ... 

Sorry. You meant that all the routers in the path should be using
certificates?

> not too

Agreed.

> well here, though I don't think it changes any

Agreed. Maybe this is also an indication that TCP-AO *should* change
something in this respect!

> 6) (editorial) Section 5.2, typo "preferebable"

Will do.

> really an "on the other hand", I think it's

Will do. ("english as a second language" here. :-( )

> as the Internet has moved well beyond needing

I fully agree with you. However, at some point in the past there was all
these discussions that the document was "going against the standards",
and that it was "too strong", being an "Informational" document. Hence
it's not as strong as I would have liked it to be.

That said, the internet has moved beyond reseting established
connections in response to hard errors, too. :-)

> alone.  

Yes. And it could have been worse. Because for the other two
vulnerabilities, it all boils down to "ignore source quenches" and
"process hard errors as soft errors if they are received for connections
in any of the synchronized states". But you cannot ignore "frag needed"
messages.

> Is this *really* an attack that we're

Yes. See the "Acknowledgement" section of the I-D -- it was reviewed by
people from Free', Net', and OpenBSD, Solaris and opensolaris, Cisco,
Extremenetworks, and others. Yes, that's not the world... but I'd argue
that a good sample.

Without the TCP seq check, is trivial (and with an advertised MTU of 0
it even crashed some implementations). With the TCP SEQ check, things
are not so bad... but the windows keep increasing.

That said, the document is informational, and documents what has been
done in the industry. And the stuff in Section 7 is implemented in a
number of systems and deployed already in the Internet.

> seem too complex for what they buy, to me.  

I did the patch myself for OpenBSD in a few hours (and it was probably
my first commit to the tree). Conceptually speaking, it's even simpler:
Before you know data has successfully been transferred to the remote
endpoint, just validate the ICMP error messages by checking the TCP SEQ.
Once you have successfully transferred data, check for progress on the
connection before honoring the ICMP error messages).

> It

I have already been told by a number of developers that they would not
implement the ICMP-free version of PLPMTUD, because of its convergence
time. They are more willing to implement it for icmp blackhole detection.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Jun 2009 05:30:11 -0300

Hello, Wes,

Comments in-line....

> not sure are totally supported by prior RFCs.  

Any specific issues?

> For
> a reference for that?  

What's the reason for setting the DF flag for IP packets carrying TCP
segments if you don't implement PMTUD?

Actually, if you don't implement PMTUD, "frag needed" becomes a hard
error. So setting the DF flag would be sort of dumb, as in the event one
of your segments needs to be fragmented, you'd received an ICMP "frag
needed" message, which would reset your connection.

> Further, it discusses ambiguity

The appendix was at some point part of the main text. I moved the text
into an appendix probably on request of somebody, but not because I
thought the text should be there. So I have no problem moving the
entirre appendix (or part of it) back into the main part of the document.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Jun 2009 13:41:03 -0700

Fernando Gont wrote:
...
> something in this respect!

TCP-AO already addresses ICMP attacks in the security considerations
section, and requires there to be a way to disable reaction to ICMPs.
Like IPsec, though, we don't make a-priori assessments as to whether
ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)
is used.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Jun 2009 13:44:58 -0700

Fernando Gont wrote:
...
> segments if you don't implement PMTUD?

There are systems that just don't want to implement reassembly, due to
the cost and potential for the attack at the receiver of receiving large
numbers of partial packets. small devices do this to save
compute/storage space - the Sony CLIE was one of these a few years ago,
even though PMTUD was common even at the time.

> needed" message, which would reset your connection.

That's what happened when running TCP from a CLIE over a tunnel. Not
desirable from the user's view, but definitely intended.

>> rather than an appendix, I think ... what does the rest

This doc should not be clarifying anything in 1122 - that, IMO, would be
for a standards-track doc, not an informational.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Sat, 13 Jun 2009 10:42:26 -0500

>-----Original Message-----
>From: Fernando Gont [mailto:[email-masked]] On
>Behalf Of Fernando Gont
>Sent: Thursday, June 11, 2009 4:30 AM
>Hello, Wes,
>

I'll go one-by-one through them and follow up with any in

>segments if you don't implement PMTUD?

I know of a number of embedded OS kernels and real-time systems
that either don't implement IP reassembly or disable it.  Some
of the stacks geared towards real-time will also set DF on the
packets that they send as the frag/reassembly is presumed to be
an impediment to guaranteeing their delay bounds.

>entirre appendix (or part of it) back into the main part of the

Oh, I didn't realize we'd already juggled it around :).
It makes sense to me to analyze the different message
types this way as motivation for the recommendations on
how to treat them, which is why I expected it to be in
the body, but if there was already consensus to have it
as an appendix, then that's fine too.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 13 Jun 2009 21:32:40 -0300

> an impediment to guaranteeing their delay bounds.

What do these systems do when they receive a "frag needed" ICMP error
message? If they adapt the segment size, they implement some form of PMTUD.
If frag was needed (As indicated in the ICMP error message), and they
keep sending at the same segment size, the connection would time-out
(not good). If they don't do any of these, and follow RFC1122 instead,
they should reset the connection (not good, either).

> as an appendix, then that's fine too.

No, I don't think there was consensus to move that stuff to an appendix.
It was probably the result of me honoring a suggestion I had received
from some folk.

Thanks,

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 15:35:05 +0200

> I don't think we lose anything by leaving that

I think it should go.

(Disclaimer: I don't like the way UNIRAS/CPNI handled some
disclosures, but I think this isn't important in this context.)

---

From: Florian Weimer <[email-masked]>
Date: Sun, 14 Jun 2009 15:37:49 +0200

* Fernando Gont:

>> For instance, I'm not certain that setting the DF bit is only
>> possible for hosts that support PMTUD ... is there a reference for
>> that?
>

You don't have to put randomness into the IP ID field (at least in
theory; in practice, DF=1 packets get fragmented, too).

---

From: Joe Touch <[email-masked]>
Date: Sun, 14 Jun 2009 07:56:51 -0700

> theory; in practice, DF=1 packets get fragmented, too).

Technically, you do regardless of whether the bit is set or not right
now. Hopefully that requirement will change, but only when we change the
standards.

See draft-touch-intarea-ipv4-unique-id-01

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 14 Jun 2009 08:01:27 -0700

> I don't think we lose anything by leaving that

I think it ought to be OK to say "this work supported by..." or other
disclaimers in the Ack's section.

The text in question is more than a plug; it's recommended action.
That's clearly out of scope for an informational doc; it would require
BCP status to have such guidance, and the WG would need to agree that
such guidance is appropriate.

In general, it's also far too specific -- i.e., such guidance is more
appropriately "contact the authorities and report...", and would then
give a list of appropriate entities, rather than endorsing or
recommending a single party.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Jun 2009 23:16:48 -0300

> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)

IIRC, the motivation for the TCP MD5 option was to mitigate RST-based
reset attacks. Does it make any sense to have the option and still even
consider reacting to ICMP error messages?

Reaction to ICMP "frag needed" is probably a little more difficult to
assess (for obvious reasons), but reaction to ICMP hard errors is, IMO,
a no-brainer, and I believe should default to "SHOULD NOT abort
connections".

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Jun 2009 23:23:56 -0300

> I don't think we lose anything by leaving that

Let me clarify this one a little bit: When I included this appendix, I
was not working for UK CPNI (formerly NISCC), and there were no plans of
doing so.

However, NISCC was carrying out the vendor coordination process wrt the
ICMP vulnerabilities. For instance, NISCC ended up publishing a
vulnerability advisory stating the vulnerability status of each of the
different vendors.

That was the reason for including that paragraph. -- as I mentioned,
neither NISCC nor CPNI sponsored any of my work on the ICMP attacks
draft (for instance, my affiliation for this I-D is with UTN/FRH, not
with CPNI).

That said, I have no problem with removing this appendix, and adding a
corresponding ack in the "Acknowledgements" section (i.e., different and
shorter text) to NISCC/CPNI for the vendor coordination process they
carried out.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 14 Jun 2009 23:28:26 -0300

> theory; in practice, DF=1 packets get fragmented, too).

Yes, in theory. For instance, IIRC Linux used to zero the IP ID field
when DF was set, but then backed-out this change.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sun, 14 Jun 2009 19:47:54 -0700

> consider reacting to ICMP error messages?

See Sec 6.1.1 of RFC4301. There are legitimate uses for these messages,
and turning them off should be up to the user.

> a no-brainer, and I believe should default to "SHOULD NOT abort

IPsec does not make that leap, nor is there a good reason to do so here.
 Like IPsec, we require that this be configurable, but don't specify a
default.

This is already noted in the Security Considerations section.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 14 Jun 2009 19:59:01 -0700

> when DF was set, but then backed-out this change.

This was/is also incorrectly done by some cellphones, to save state and
processing.

The trouble is that the IP ID is also used to detect (and discard)
duplicate segments. This is described in the draft I already cited, and
the best place to discuss it is the INT area mailing list.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 15 Jun 2009 00:01:33 -0300

> disclosures, but I think this isn't important in this context.)

FWIW, when it comes to these ICMP issues, I had reported them to both
NISCC and CERT/CC at the same time. And I sticked with NISCC/CPNI
because I got a much better response from them. IIRC, Paul Watson (TCP
reset attacks) has a very similar story.

If there are any specific issues you didn't like how UNIRAS/CPNI
handled, feel free to comment them off-list, and I will relay them to
CPNI. They are always open for suggestions and improvement.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 09:58:40 -0300

> ICMPs should be blocked or not on connections on which TCP-AO (or IPsec)

What's the point of enabling TCP-AO, if you are not going to disable (or
hard errors -> soft errors)?

I think that for the sake of the "principle of least surprise", ICMP
hard errors SHOULD NOT abort connections for which TCP AO has been enabled.

What to do with "frag needed" might vary. Although one could argue that
you SHOULD implement PLPMTUD.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 06:59:45 -0700

> hard errors -> soft errors)?

See the text in RFC4301.

> hard errors SHOULD NOT abort connections for which TCP AO has been enabled.

Please explain why you think that TCP-AO needs more strict advice in
this regard than IPsec.

> you SHOULD implement PLPMTUD.

- ---

We could add that TCP-AO, like IPsec (text copied from 4301):

   ...A compliant TCP-AO
   implementation MUST permit a local administrator to configure an
   IPsec implementation to accept or reject unauthenticated ICMP
   traffic.  This control MUST be at the granularity of ICMP type and
   MAY be at the granularity of ICMP type and code.  Additionally, an
   implementation SHOULD incorporate mechanisms and parameters for
   dealing with such traffic.  For example, there could be the ability
   to establish a minimum PMTU for traffic (on a per destination basis),
   to prevent receipt of an unauthenticated ICMP from setting the PMTU
   to a trivial size.

- ---

We can add a discussion of PLPMTUD, but rfc4821 doesn't have any
particular recommendations of implementation. We would need to be
careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO
deployment.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 14:31:40 -0300

> Please explain why you think that TCP-AO needs more strict advice in

Because TCP-AO is TCP-specific. IPsec is not. The term "TCP" is almost
not even mentioned in RFC 4301. So it wouldn't make sense for RFC 4301
to get into the details of how a specific transport protocol (TCP) would
react to specific ICMP error messages.

In the case of TCP-AO, it's TCP specific, and thus I believe it should
provide stricter advice wrt how TCP should react to ICMP error messages
when they are received for connections that employ TCP-AO.

> ---

Makes sense to me. Although, again, I believe there should be (safe)
defaults for this.

> careful to not tie TCP-AO to PLPMTUD in a way that impedes TCP-AO

I believe it could/should be suggested that PLPMTUD be implemented
without support for ICMP frag needed (i.e., ignore them). (FWIW, RFC4821
leaves it open as to whether PMTUD should only be implemented for
dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 11:29:40 -0700

> react to specific ICMP error messages.

It does, though, in detail.

> when they are received for connections that employ TCP-AO.

It's probably useful to split out the discussion of ICMP to a separate
section. However, the advice therein seems like it should still not
exceed what is in 4301 for the same reason for the same transport
protocol - there are pros and cons of either leaving open or closing
ICMP handling.

This document is not a place where the difference between hard and soft
ICMPs and TCP opening vs. established should be resolved, since it has
not been resolved for TCP without authentication, and authentication
does not apply to the ICMP messages.

> Makes sense to me. Although, again, I believe there should be (safe)

Defaults have generally been removed from the document for various reasons.

> dealing with ICMP blackholes, or as an ICMP-free version of PMTUD).

There are a few possibilities:

	- use DF=0
	- use DF=1 with PMTUD
		this requires ICMP frag-needed be passed
		which opens a vulnerability on that ICMP type
		however, the attack of additional frag-neededs
		could reduce efficiency but won't shut down TCP
	- use DF=1 with PLPMTUD
		this allows ICMP frag-needed to be dropped

The security benefits of PLPMTUD are more significant when ICMPs are
dropped more than when they are spoofed, but it can be noted.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 16:09:32 -0300

> It does, though, in detail.

Can you quote the text you are referring to, or provide a citation to
the specific Section you are referring to?

> protocol - there are pros and cons of either leaving open or closing

As I mentioned, IPsec is by far more general. And thus it sort of makes
sense to avoid being specific about any protocol that it could possibly
encapsulate.

TCP-AO is TCP-specific. And IMHO it would thus make sense for the
document to be as specific/detailed as necessary.

I guess you could come up with some scenario in which it makes sense to
process ICMP messages for connections that employ TCP-AO. However,
principle of least surprise: one of the main drivers for TCP MD5 was to
mitigate connection-reset attacks. Thus, by default, you should close
the avenue of ICMP-based attacks, too. IMO, that is the safe default.

> does not apply to the ICMP messages.

Agreed. Easier: ignore ICMP error messages, or "do not abort connections
in response to ICMP error messages".

> There are a few possibilities:

Could be an option. However, considering that the IP ID field is 16-bits
long, I don't think that relying on IP fragmentation should not be
considered a viable option nowadays.

> dropped more than when they are spoofed, but it can be noted.

FWIW, if you implement the PMTUD counter-measure described in the ICMP
attacks I-D, you get the benefits of ICMP-enabled PMTUD, without the
security drawback of the traditional PMTUD (check for progress on the
connection before honoring the ICMP error message).

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 13:58:55 -0700

> the specific Section you are referring to?

Section 6.

It discusses PMTU and unreachables, neither of which have much impact on
protocols that don't establish connections. UDP passes ICMPs up, and
generates them when the port isn't listening, but otherwise does not
interact with ICMP.

> sense to avoid being specific about any protocol that it could possibly

As I said above, IPsec is fairly specific about the handling of ICMPs
and reasons thereof. Those reasons apply primarily to TCP - including
when to both ignore ICMPs and when they should not be ignored.

> the avenue of ICMP-based attacks, too. IMO, that is the safe default.

Principle of least surprise also means not making a TCP-AO connection
need to wait for a full timeout even when an endpoint cannot be reached,
whether during a connection or during establishment. It also means not
turning a functioning PMTUD mechanism into a black hole.

As 4301 notes, there are good reasons for either way of configuring an
endpoint - endpoints it is intended to protect from replays and
connection interruption as well.

> in response to ICMP error messages".

Ignore disables valid PMTUD and valid connection termination
indications. Do not abort ignores the latter. Again, there is no reason
to *default* to this case.

I believe letting the user configure whether specific ICMPs are passed
or ignored covers the needed functionality.

> considered a viable option nowadays.

It is both viable and currently in widespread use. Discussion of that
field should happen on the INTAREA list, not here, but as I noted the
proposed update to 791 makes that ID field useful so long as DF=0 or the
packet has already been fragmented, and the ID is unique over some
multiple of the expected reordering - not just unique within 2MSL as is
the current requirement.

> connection before honoring the ICMP error message).

That's an *if*. We're not modifying TCP functionality as part of TCP-AO;
we're extending it to support security. Changes of the nature you
propose may be useful in conjunction once standardized, but until we
make that case for TCP we can't add it to TCP-AO, IMO.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 19:13:49 -0300

> generates them when the port isn't listening, but otherwise does not

That's your assessment. And while I may agree with it, that's not what
the spec says. The only ICMP unreachable about which the spec talks with
some level of detail is "frag needed". For instance, it never mentions
the possibility of ICMP unreachables of being used for connection reset
attacks.

> when to both ignore ICMPs and when they should not be ignored.

Joe, I've just read Section 6, and there's no such a thing. Please quote
text from that section which assesses ICMP hard errors, and prove me wrong.

> whether during a connection or during establishment. 

We have debated RFC 5461 for years (literally), and you know care about
long delays in connection establishment attempts? That said, if you were
able to establish the connection in the first place, chances are that
you will receive soft errors, not hard errors. Therefore you wouldn't be
aborting the connection, anyway. For connection establishment, you may
be right... but RFC 5461 seemed controversial for connections that
didn't employ authentication, and you now consider it acceptable for
"authenticated" connections?

That said, TCP-AO/MD5 are meant for security, not performance. If you
enable it, you expect security, not performance. Having TCP-AO and then
being spec-wise vulnerable (by default) to trivial ICMP attacks would be
non-sensical.

> It also means not

Agreed. That's why I said "frag needed" are a different issue.

> indications. 

I was meaning any ICMP error messages other than "frag needed" in this case.

> Do not abort ignores the latter. Again, there is no reason

Yes. I enable TCP-AO to protect my connections against reset attacks.
Why would I bother doing it if you don't close the even-easier ICMP
vector????

> or ignored covers the needed functionality.

You expect the user to know too much. Pick a safe default, and then let
the knowledgeable user override that default (if needed).

> multiple of the expected reordering - not just unique within 2MSL as is

I had read your proposal in the past, but do not recall the details
right now. However, the problems of fragmentation has been beaten to
death. (e.g., the Matthis/Heffner RFC).

> make that case for TCP we can't add it to TCP-AO, IMO.

Ignoring ICMP errors is sort of the same thing: you're not complying
with the specs. At that point (i.e., once you have decided not to comply
with the standard), whether you simply ignore the ICMP errors or you
ignore them based on connection progress, is a minor detail.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 16:01:28 -0700

> the possibility of ICMP unreachables of being used for connection reset

6.  ICMP Processing

   ...There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.

then further...

6.1.1.  ICMP Error Messages Received on the Unprotected Side of the
        Boundary

   Figure 3 in Section 5.2 shows a distinct ICMP processing module on
   the unprotected side of the IPsec boundary, for processing ICMP
   messages (error or otherwise) that are addressed to the IPsec device
   and that are not protected via AH or ESP.  An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.

How do you interpret denial or degradation w.r.t. destination unreachables?

> text from that section which assesses ICMP hard errors, and prove me wrong.

6.0 says that this section is exclusively about error messages of type
dest unreachable:

   ... There are two
   categories of ICMP traffic: error messages (e.g., type = destination
   unreachable) and non-error messages (e.g., type = echo).  This
   section applies exclusively to error messages.

Sec 6.1.1. says that these can result in denial of service:

   ...An ICMP message of this
   sort is unauthenticated, and its processing may result in denial or
   degradation of service.  This suggests that, in general, it would be
   desirable to ignore such messages.

TCP and other connection oriented protocols are a primary user of such
error messages; UDP sends port unreachable, but otherwise does not
itself react to ICMPs.

   ...However, many ICMP messages will
   be received by hosts or security gateways from unauthenticated
   sources, e.g., routers in the public Internet.  Ignoring these ICMP
   messages can degrade service, e.g., because of a failure to process
   PMTU message and redirection messages.  Thus, there is also a
   motivation for accepting and acting upon unauthenticated ICMP
   messages.

TCP and other connection oriented protocols are the primary users of
PMTU messages.

> "authenticated" connections?

I am NOT in favor of changing TCPs reaction to ICMPs in TCP-AO, any more
than I was in RFC5461.

> being spec-wise vulnerable (by default) to trivial ICMP attacks would be

IPsec has exactly the same tradeoff, yet fails to come to the same
conclusion. It is just as sensible to make the same recommendation here
as IPsec does - let the user decide.

> Agreed. That's why I said "frag needed" are a different issue.

The same thing happens when redirects are ignored - black hole.

> I was meaning any ICMP error messages other than "frag needed" in this case.

See above; it's more than just frag needed.

> Why would I bother doing it if you don't close the even-easier ICMP

There are cases where, e.g., replays are possible but it is much more
difficult to generate packets. There are also cases where some IP
addresses can be spoofed but not others (e.g., where reverse path
validation is done).

Regardless, it's up to the user to decide. I'm not saying they would
never decide to block ICMPs, but I don't agree that we can disable ICMP
by default.

> the knowledgeable user override that default (if needed).

TCP-AO isn't enabled by default either. And systems that have
unpredictable behavior (e.g., won't work - not just won't be fast -
because valid ICMPs won't get through) get turned OFF.

I expect a user to either disable or enable ICMPs. An implementation can
do what it wants regarding defaults.

> death. (e.g., the Matthis/Heffner RFC).

Matthis/Heffner describes some problems. My draft proposes a change to
the standard, and was written with Mathis FWIW. If you want to discuss
it further, again, please do so on the INTAREA list.

> ignore them based on connection progress, is a minor detail.

The WG did not think so, which is why 5461 was limited to describing
what had been implemented and is Informational rather than making a
recommendation and being BCP or Standards Track (BTW, any idea who did
the implementation you were documenting?)

Joe

joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 20:26:00 -0300

Joe Touch wrote:

[talking about RFC 4301]
> How do you interpret denial or degradation w.r.t. destination unreachables?

Again, that's your personal assessment, not what the spec says.
What service does TCP provide? - Data transfer. Is it degraded for not
reacting to ICMP errors? No. For instance, nobody resets established
connections in response to ICMP error messages. So if you consider that
a "degraded service", we all use scuh a degraded service.

And, btw, in this quoted para, it's "its *processing*" (i.e., *honoring*
the ICMPs) that may lead to denial or degradation of service.

> error messages; UDP sends port unreachable, but otherwise does not

But the spec is not talking about the transport protocol reacting to
these messages, but about the processing of them. In the case of UDP,
that would be the processing of ICMP errors by the app layer.

> TCP and other connection oriented protocols are the primary users of

In the case of UDP, the app would be the user of those messages.
Actually, in the case of TCP the app could also be a user of those
messages (RFC 1122 about relaying ICMP errors to apps).

> I am NOT in favor of changing TCPs reaction to ICMPs in TCP-AO, any more

You are concerned that ignoring ICMPs may lead to long timeouts. What's
the difference?

> conclusion. 

We're not here to rehash the past for the sake of it. The fact that some
spec does something doesn't mean that we have to repeat the same thing
in new work.

FWIW, from that perspective, you could have ignored the ICMP attacks
issue altogether, as RFC 2385 does not even talk about it. -- No need to
say that I'm happy that the TCP-AO I-D is different in this respect.

> The same thing happens when redirects are ignored - black hole.

No. Redirects are an optimization. honoring redirects without something
like GTSM (which you cannot really enforce) would be dumb nowadays.

>From the Intro of RFC 2385:

"   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets."

Again, I believe TCP-AO should default to ignoring ICMP hard errors, at
least for the established states.

> never decide to block ICMPs, but I don't agree that we can disable ICMP

Does the *user* really need to know about TCP internals such as how TCP
reacts to those error messages?

> do what it wants regarding defaults.

Do you really expect the user to go and play with the switches for each
message type/code? I don't, and wouldn't want the general TCP-AO user to
do so.

> it further, again, please do so on the INTAREA list.

FWIW, I'm not against your proposal. Actually, IIRC, I was in general
agreement with it.

> The WG did not think so, 

I was talking about the PMTUD mitigation in the ICMP attacks I-D, and
not about RFC 5461.

> which is why 5461 was limited to describing

The soft errors implementation? I don't know which developer, but it was
implemented in Linux and a number of other systems, well before I
started working on RFC 5461.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 17:13:45 -0700

I think we both agree that the text on ICMP handling should be moved out
of the security considerations section and put it its own section. The
question is what to put there.

You prefer defaults, and are recommending ICMP handling similar to that
in documents the WG has decided not to recommend for TCP not running AO.

I want to leave TCP-AO's handling of ICMPs the same as IPsec's - up to
the user.

Can others please weigh in?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Jun 2009 21:48:04 -0300

Joe,

> of the security considerations section and put it its own section.

Agreed.

> in documents the WG has decided not to recommend for TCP not running AO.

Yes. Note that virtually all real implementations already do this for
connections that do not use TCP-AO. Nobody is going to change this for
non-TCP-AO, or even less abort TCP-AO connections in response to ICMP
error messages.

> I want to leave TCP-AO's handling of ICMPs the same as IPsec's - up to

Just making my point clear: I think leaving unspecified what to do with
ICMP errore messages would be a bad decision. It might end up with
implementations honoring these error messages, which would mean that
TCP-AO would be (by default) useless for protecting TCP against
ICMP-based reset attacks.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 16 Jun 2009 18:27:54 -0700

> non-TCP-AO, or even less abort TCP-AO connections in response to ICMP

This document is standards track, and is not intended to validate the
behavior of those implementations. It also doesn't invalidate them.

Note that I am NOT saying that the default is "ICMPs pass" - I said
NOTHING about a default, just like IPsec says nothing.

> ICMP-based reset attacks.

TCP-AO does not have a default for connections without keys either.
IPsec does - they're blocked. If we're not having a default for new
connections, we shouldn't have a default for ICMP.

Joe