Fernando, > 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 new IPsec Security Architecture document (section 6) discusses this and requires the implementation to provide to knob to control this. > * 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. > === 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. > > > >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. 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
