RE: Security considerations of the ICMPv6 draft
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Security considerations of the ICMPv6 draft
At 14:35 13/04/2005 -0500, Mukesh.K.Gupta at nokia.com 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: fernando at gont.com.ar || fgont at acm.org
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.