Fernando, 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.
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. We all seem to agree about adding some words and a reference to draft-gont-tcpm-icmp-attacks-03.txt. Right ? Regards Mukesh > -----Original Message----- > From: ext Fernando Gont [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 10, 2005 9:35 PM > To: Pekka Savola > Cc: ipv6@ietf.org; Gupta Mukesh.K (Nokia-NET/MtView) > Subject: Re: Security considerations of the ICMPv6 draft > > > At 02:24 09/04/2005 +0300, Pekka Savola wrote: > > >>I think the ICMPv6 draft should add some words to raise > awareness about > >>ICMP-based attacks that can be performed against transport > protocols. > > > >Any text suggestions -- just to have an idea how verbose and > explicit > >you're looking at; did you refer to the proposed text below, > or something > >more extensive? > > I referred to the text you had proposed. However, maybe a few > additional > words could be added. With the current specs, you either have > IPsec, or no > counter-measures at all. So I think the ICMP spec should say > something like > "transport protocols SHOULD use the information contained in the ICMP > payload to validate the received ICMP messages". Probably not in the > "Security Considerations section", but earlier in the spec. > > > > >>>By the way, one additional ICMP attack that could possibly > be included > >>>in 5.2: > >>> 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, though the upper > layers may > >>> also perform some form of validation of ICMPs on their own. > >>>Where [TCP-attack] is an informative reference to > >>>draft-gont-tcpm-icmp-attacks-03.txt. > > > >Yes, something like this should be added. I thought it > already was there, > >but apparently not... > > Yes, this text has not yet been added. > > > > >>Another issue that may be worth considering is suggesting that the > >>so-called "hard errors" should not necessarily be > considered "hard". > >>While there's no RFC 1122 for IPv6 (and thus you might say > there's no > >>such thing as "hard errors" and "soft errors" in v6), I > think everyone > >>will extrapolate RFC 1122's statements on soft and hard > errors to the > >>ICMPv6 specification. > > > >Even if I may agree with this sentiment, IMHO it seems to go > too much on > >the side of the transport protocols, and doesn't seem to be > appropriate in > >this document. The above already a provides a pointer. > > Note that I'm not saying the ICMPv6 should say whether > connections should > be aborted upon receipt of ICMP errors or not. I'm saying > that maybe the > spec could suggest what the errors being reported "mean". > E.g., is a "Port > unreachable" a soft or a hard error? > With this information, a transport-protocol designer could > elaborate the > policy of reaction to ICMP errors. > > I think that part of RFC 1122 that discusses which ICMP > errors are soft or > hard is a complement to the ICMPv4 spec. Then, when RFC 1122 > says "TCP > SHOULD abort...", *that* is the transport-protocol stuff. > > > -- > 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 --------------------------------------------------------------------
