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