Subject: RE: Security considerations of the ICMPv6 draft

From: Fernando Gont <[email-masked]>
Date: Wed, 13 Apr 2005 03:38:02 -0300

At 13:57 11/04/2005 -0500, [email-masked] wrote:

>I agree that we should add some words to raise awareness
>about the ICMP-based attacks.  We could add the text that
>Pekka suggested in the security consideration section and
>provide an informative reference to your draft.

That'd be a good thing.

>I don't think the ICMP draft should go in details of how
>a transport protocol should protect itself against these
>attacks.  I think, it will be a good idea to write separate
>drafts for those details.

I didn't mean we should provide details on how transport protocols should 
react to ICMP errors. I just suggested that the ICMPv6 draft should 
recommend transport protocols to use the information contained in the 
payload to validate the ICMP messages (but don't say a word about the 
actual checks), and also that it would be great if it provided a few words 
about what the ICMP error types/codes mean.
If left "as is", people will extrapolate the RFC 1122 description to ICMPv6.
I just say that adding something like "these error codes do not necessarily 
indicate hard errors". That little sentence would mean the discussion of 
ICMP in RFC 1122 does not necessarily apply to ICMPv6.

BTW, (closely related to this thread), this was released yesterday:

* Cisco's vulnerability report
http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml

* CERT/CC's vulnerability report
http://www.kb.cert.org/vuls/id/222750

* NISCC's vulnerability report
http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Wed, 13 Apr 2005 14:35:16 -0500

Ok so we are pretty much decided on adding the 
awareness text.

What about we add the following text to cover your
second point also (i.e. recommending the upper layers to
use the payload for validation).

===
    6. As the ICMP messages are passed to the upper-layer 
       processes, it is possible to perform attacks on the 
       upper layer protocols (e.g., TCP) with ICMP [TCP-attack].
       Protecting the upper layer with IPsec mitigates this 
       problem.  If not protected by IPsec, it is recommended
       for the upper layers to perform some form of validation
       of ICMP messages (using the information contained in 
       the payload of the ICMP) before action upon them.  The
       actual validation checks are specific to the upper 
       layers and are out of the scope of this spec.
===

The third point that you raise about the hard and the soft
errors, I am not sure what to do.  Do we already have a
resolution for TCP that 
 - it should not consider any of the ICMP messages as 
   hard errors ?  Or 
 - it should perform some checks and then consider them
   as hard and soft according to RFC 1122 ? or
 - something else ?

Could you suggest what specific text we should add to
ICMPv6 to cover the issue of hard and soft errors ?

Regards
Mukesh

> -----Original Message-----
> From: ext Fernando Gont [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2005 11:38 PM
> To: Gupta Mukesh.K (Nokia-NET/MtView); [email-masked]
> Cc: [email-masked]
> Subject: RE: Security considerations of the ICMPv6 draft
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Apr 2005 17:06:17 -0300

>        layers and are out of the scope of this spec.

This is great.

A few comments on this text:

* I have not read the latsts update of the IPsec specs. Do they know state 
it clearly that if you're using IPsec, you should drop those ICMP messages 
that arrive without IPsec authentication? (If not, IPsec won't help).

* The text says
"      If not protected by IPsec, it is recommended
        for the upper layers to perform some form of validation
        of ICMP messages (using the information contained in
        the payload of the ICMP) before action upon them"

I'd remove "If not protected by IPsec", an leave it as "It is recommended 
for the upper layers..."
That is, regardless of whether you're using IPsec or not, validating the 
ICMP messages by means of the ICMP payload is a good thing.

* s/action/acting/

* s/of the ICMP/of the ICMP message/

If you agree with these changes, the text would look like:
===
    6. As the ICMP messages are passed to the upper-layer
       processes, it is possible to perform attacks on the
       upper layer protocols (e.g., TCP) with ICMP [TCP-attack].
       It is recommended for the upper layers to perform some
       form of validation of ICMP messages (using the
       information contained in the payload of the ICMP message)
       before acting upon them.  The actual validation checks
       are specific to the upper layers and are out of the scope
       of this spec. Protecting the upper layer with IPsec
       mitigates these attacks.
===

>    as hard and soft according to RFC 1122 ? or

There's no resolution on this issue. However, the discussion on soft and 
hard errors should not be TCP-specific.

>ICMPv6 to cover the issue of hard and soft errors ?

Yea. How about this:

===
ICMP error messages signal network error conditions that were encountered 
while processing an internet datagram. Depending on the particular 
scenario, the error conditions being reported might or might not get solved 
in the near term.
Therefore, reaction to ICMP error messages may depend not only on the error 
type and code, but also on other factors such as the time the error 
messages are received, previous knowledge of the network error conditions 
being reported, and knowledge of the network scenario in which the 
receiving host is operating.
===

Note that the text does not say what a transport protocol should do, but 
rather relaxes the requirements stated in RFC 1122.

Kindest regards,

---

From: [email-masked]
Date: Wed, 20 Apr 2005 13:41:34 -0500

Fernando,

> that arrive without IPsec authentication? (If not, IPsec won't help).

The new IPsec Security Architecture document (section 6) discusses
this and requires the implementation to provide to knob to control
this.

>        of this spec. Protecting the upper layer with IPsec

This looks ok to me.

> There's no resolution on this issue. However, the discussion 
> on soft and hard errors should not be TCP-specific.
> 
> 
> Note that the text does not say what a transport protocol 
> should do, but rather relaxes the requirements stated in 
> RFC 1122.

I agree that this problem (relaxing/changing the hard/soft errors
and the actions associated with them) needs to be addressed but
I am not still sure if ICMPv6 draft is the right place to do it :(

ICMP is just providing the messages to convey the error conditions.
As it is RFC 1122 (Requirements for internet hosts) and NOT the ICMP
RFC, which is describing the soft/hard errors and their associated 
action, shouldn't it be the update to RFC 1122 or TCP or something 
else that updates that text?

Regards
Mukesh

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Apr 2005 18:49:07 -0300

>this and requires the implementation to provide to knob to control

Then this reinforces that of "Validating ICMP messages at the upper layers 
is a good thing, anyway", as using IPsec does not imply ICMP messages will 
be handled as expected.
Also, if you want to send packets that are larger than the IPv6 minimum 
MTU, you depend on PMTUD, and thus you cannot apply that policy of "drop 
those ICMP messages that are not authenticated", as that would be sort of 
shooting your own foot.

> >        of this spec. Protecting the upper layer with IPsec

Great!

>I am not still sure if ICMPv6 draft is the right place to do it :(

I think it is. ICMPv6 must define both the syntax and the semantics of ICMP 
messages. Currently, it defines only the syntax. So it defines the syntax 
of error messages, but provides no hints on what these error mean (should I 
assume they will remain in the near term? Should I assume they will not? 
Can I take them as a hint and assume anything?). What is worse, there's RFC 
1122, which makes statements on ICMPv4. As the ICMPv6 spec does not cover 
those issues (hard and soft errors), most implementers will just try to 
extrapolate RFC 1122 to ICMPv6.

>else that updates that text?

I don't think so. RFC 1122's statements on this issue are just filling 
holes in the ICMP and the TCP specifications. Basically, RFC 792 defined 
only the syntax of ICMP messages, but did not define their semantics. So 
the upper layers did not have any hints on what to do with them.
RFC 1122 then said "these ICMP error types/codes indicate hard error 
conditions; these other ones indicate soft error conditions", thus filling 
the hole in the ICMP spec. Having defined the semantics of ICMP messages, 
RFC 1122 then fills the hole in the TCP spec, stating "as these ICMP error 
types/codes indicate hard errors, TCP should abort the connection; as these 
other ones indicate soft errors, TCP should not abort the corresponding 
connection".

So my point is that ICMPv6 should define the semantics of the messages for 
which it defines their syntax. Then upper layer protocols could then decide 
what to do with them.

Actually, the text I proposed does not get too much into defining the 
semantics. Just tries to relax RFC 1122 to mean that "soft errors" and 
"hard errors" are not a "black or white" thing, thus making it possible for 
upper layer protocols to do what they think is best.

Two examples that show how this subtle text would be important:

* You may be aware of draft-gont-tcpm-icmp-attacks. It describes a number 
of attacks that can be performed against TCP and other similar protocols. 
One of the attacks is a blind connection-reset attack that can be performed 
by means of the so-called ICMP "hard error" messages. As a counter-measure 
against this attack, my draft proposes to make TCP treat "hard errors" as 
"soft errors" if they are received for connections that are in any of the 
synchronized states. The arguments against this proposal have so far been 
that we would be changing not only TCP's reaction to these errors, bu also 
the semantics of ICMP messages themselves.
Making the mod (actually, "addition") I proposed would allow TCP to 
implement this modification, without violating any existing spec. As a 
result, TCP over IPv6 wouldn't be vulnerable to this attack. Given the 
number of products of different vendors that were found vulnerable when 
NISCC released their vulnerability advisory, I think it would be a good 
thing for ICMPv6 to take action on this issue.

* You may be aware of my draft draft-gont-tcpm-tcp-soft errors, that was 
triggered by draft-ietf-v6ops-v6onbydefault. Basically, we wanted to avoid 
long delays between connection-establishment attempts by making TCP abort 
connections upon receipt of an ICMP error message while in any of the 
non-synchronized states (i.e., when the connection wasn't yet ESTABLISHED). 
The arguments against this proposal were, basically, that RFC 1122 stated 
that TCP should not abort a connection upon receipt of a so-called ICMP 
"soft error", and that as soft errors would likely be solved in the near 
term, the proposed behaviour was a bad idea.
Defining the semantics in ICMPv6 (or, as I'm proposing, at least relaxing 
those in RFC 1122) would have let somoother progress of this proposal. At 
least for IPv6, there wouldn't be arguments for not adopting it. Not the 
same, at least.

Kindest regards,