RE: Security considerations of the ICMPv6 draft

[Fernando Gont]

At 14:35 13/04/2005 -0500, [EMAIL PROTECTED] wrote:
===
    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.
===
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.
===

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 ?
There's no resolution on this issue. However, the discussion on soft and 
hard errors should not be TCP-specific.


Could you suggest what specific text we should add to
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,
--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------