Fernando, Sorry for replying late :)
After reading this mail, I am convinced that we should put the following text that you proposed in the ICMPv6 draft. === 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. === I will try to submit the draft after making all the due changes. Regards Mukesh > -----Original Message----- > From: ext Fernando Gont [mailto:[EMAIL PROTECTED] > Sent: Friday, April 22, 2005 2:49 PM > To: Gupta Mukesh.K (Nokia-NET/MtView); [EMAIL PROTECTED] > Cc: ipv6@ietf.org > Subject: RE: Security considerations of the ICMPv6 draft > > > At 13:41 20/04/2005 -0500, [EMAIL PROTECTED] wrote: > > > > * 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. > > Then this reinforces that of "Validating ICMP messages at the > upper layers > is a good thing, anyway", as using IPsec does not imply ICMP > messages will > be handled as expected. > Also, if you want to send packets that are larger than the > IPv6 minimum > MTU, you depend on PMTUD, and thus you cannot apply that > policy of "drop > those ICMP messages that are not authenticated", as that > would be sort of > shooting your own foot. > > > > > 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. > > Great! > > > > > === > > > 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 :( > > I think it is. ICMPv6 must define both the syntax and the > semantics of ICMP > messages. Currently, it defines only the syntax. So it > defines the syntax > of error messages, but provides no hints on what these error > mean (should I > assume they will remain in the near term? Should I assume > they will not? > Can I take them as a hint and assume anything?). What is > worse, there's RFC > 1122, which makes statements on ICMPv4. As the ICMPv6 spec > does not cover > those issues (hard and soft errors), most implementers will > just try to > extrapolate RFC 1122 to ICMPv6. > > > >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? > > I don't think so. RFC 1122's statements on this issue are > just filling > holes in the ICMP and the TCP specifications. Basically, RFC > 792 defined > only the syntax of ICMP messages, but did not define their > semantics. So > the upper layers did not have any hints on what to do with them. > RFC 1122 then said "these ICMP error types/codes indicate hard error > conditions; these other ones indicate soft error conditions", > thus filling > the hole in the ICMP spec. Having defined the semantics of > ICMP messages, > RFC 1122 then fills the hole in the TCP spec, stating "as > these ICMP error > types/codes indicate hard errors, TCP should abort the > connection; as these > other ones indicate soft errors, TCP should not abort the > corresponding > connection". > > So my point is that ICMPv6 should define the semantics of the > messages for > which it defines their syntax. Then upper layer protocols > could then decide > what to do with them. > > Actually, the text I proposed does not get too much into defining the > semantics. Just tries to relax RFC 1122 to mean that "soft > errors" and > "hard errors" are not a "black or white" thing, thus making > it possible for > upper layer protocols to do what they think is best. > > Two examples that show how this subtle text would be important: > > * You may be aware of draft-gont-tcpm-icmp-attacks. It > describes a number > of attacks that can be performed against TCP and other > similar protocols. > One of the attacks is a blind connection-reset attack that > can be performed > by means of the so-called ICMP "hard error" messages. As a > counter-measure > against this attack, my draft proposes to make TCP treat > "hard errors" as > "soft errors" if they are received for connections that are > in any of the > synchronized states. The arguments against this proposal have > so far been > that we would be changing not only TCP's reaction to these > errors, bu also > the semantics of ICMP messages themselves. > Making the mod (actually, "addition") I proposed would allow TCP to > implement this modification, without violating any existing > spec. As a > result, TCP over IPv6 wouldn't be vulnerable to this attack. > Given the > number of products of different vendors that were found > vulnerable when > NISCC released their vulnerability advisory, I think it would > be a good > thing for ICMPv6 to take action on this issue. > > * You may be aware of my draft draft-gont-tcpm-tcp-soft > errors, that was > triggered by draft-ietf-v6ops-v6onbydefault. Basically, we > wanted to avoid > long delays between connection-establishment attempts by > making TCP abort > connections upon receipt of an ICMP error message while in any of the > non-synchronized states (i.e., when the connection wasn't yet > ESTABLISHED). > The arguments against this proposal were, basically, that RFC > 1122 stated > that TCP should not abort a connection upon receipt of a > so-called ICMP > "soft error", and that as soft errors would likely be solved > in the near > term, the proposed behaviour was a bad idea. > Defining the semantics in ICMPv6 (or, as I'm proposing, at > least relaxing > those in RFC 1122) would have let somoother progress of this > proposal. At > least for IPv6, there wouldn't be arguments for not adopting > it. Not the > same, at least. > > 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 --------------------------------------------------------------------
