(As party to the discussion which produced this new text) I don't believe that this alters the current state of affairs significantly. If the ICMPv6 message is coming from the destination node it is (still) required by 2.2(a) to use the destination adddress of the original message as source. The new text just pulls together the three pre-existing cases where the ICMP message is generated at another node or refers to a message which has a destination which could be one of several nodes (multicast or anycast).
Egress filtering will still be as effective as it might have been because the message is coming from and has a source address of a node on the routing path to the destination. At least one of the intentions of the change was to ensure that the source address was a unicast address with a suitable scope to make it through all the relevant filters (in particular avoiding getting a link local address as source in response to a message which came from off link). However, we should maybe pause a moment and think about the anycast case in the light of recent proposals to change the restrictions on anycast addresses being used as the source address for packets. My view is that this does NOT affect the proposal here: Substituting a 'real' unicast address for the anycast address gives the best information to the originator of the offending message in line with the principle in the new text. Regards, Elwyn > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Fernando Gont > Sent: 08 April 2005 12:36 > To: [EMAIL PROTECTED]; [email protected] > Subject: Re: ICMPv6 draft: Source Address Determination > > At 10:53 09/03/2005 -0600, [EMAIL PROTECTED] wrote: > > >As discussed in the IPv6 WG meeting yesterday, I am planning to > >replace sub-sections (b), (c) and (d) of section 2.2 in the > >draft with the following text: > > > >======================================= > >(b) If the message is a response to a message sent to any other > > address, such as > > - a multicast group address, > > - an anycast address implemented by the node, or > > - a unicast address which does not belong to the node > > the Source Address of the ICMPv6 packet MUST be a unicast > > address belonging to the node. The address SHOULD be chosen > > according to the rules which would used to select the source > > address for any other packet originated by the node, given > > the destination address of the packet, but MAY be selected > > in an alternative way if this would lead to a more > > informative choice of address which is reachable from the > > destination of the ICMPv6 packet. > >======================================= > > Unless I'm missing something this change makes it more probably that the > source address of the ICMP be different than the destination IP address of > the packet that elicited it. > > Suppose an ICMP error refers to a TCP connection I have established with a > remote peer. With this modifications to the ICMPv6 draft, I could no > longer > require ICMP messages to have the same source address that is being used > for the TCP connection. > > As a result, an attacker would not need to forge the source address of > ICMPv6 messages for them to be passed to the corresponding transport > protocol instance, and thus simple egress-filtering would not server as a > counter-measure against ICMP-based attacks. > > Let me know if I am missing something. > > Thanks! > > > -- > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
