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 [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
