Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 1 of 3: "Receiving Home Address Destination Option"

[Brian Haley <brian.haley at hp.com>]

Hi Charlie,

Charles E. Perkins wrote:
> 
> Hello folks,
> 
> Last month, issue #18 showed up without any fanfare on the
> issues tracker list:
>    http://trac.tools.ietf.org/wg/mext/trac/ticket/18
> I'd like to initiate discussion on the points raised as part
> of issue #18.  There are three main points, which can be
> discussed separately.  In this note, I transcribe the
> discussion about the first of the three points.
> 
> =============================================
> 
> Receiving Home Address Destination Option
> 
> In Section 9.3.1. Receiving Packets with Home Address Option:
> "Packets containing a Home Address option MUST be dropped if
> there is no corresponding Binding Cache entry. (...) These
> tests MUST NOT be done for packets that contain a Home Address
> option and a Binding Update."
> 
> The second part of this statement (packets that contain a Home
> Address option and a Binding Update) requires looking ahead in
> the packet for a Mobility Header with a respective type. This
> action is stricly forbidden by IPv6 (RFC 2460, Section 4):
> "The contents and semantics of each extension header determine
> whether or not to proceed to the next header. Therefore, extension
> headers must be processed strictly in the order they appear in
> the packet; a receiver must not, for example, scan through a
> packet looking for a particular kind of extension header and
> process that header prior to processing all preceding ones."

The assumption about looking ahead in the packet is not correct, I've
implemented this without doing it :)  Since a HAO isn't mandatory in all BU's
(deletion for example), that processing code just needs to know if one was seen
previously - if not the packet could be silently dropped.

-Brian


> Especially when using IPsec with a non-null encryption for
> communication with the Home Agent, it would be required to
> process the ESP header to find out, if the packet contains
> a Binding Update.
> 
> Proposal: Use the value in the Next Header field to determine,
> if a corresponding Binding Cache entry is required. That is,
> if the Next Header value is one of {50 (ESP), 51 (AH), 135
> (Mobility Header)} normal processing of the next header should
> be done, else, it MUST be dropped, if there is no corresponding
> Binding Cache entry. The first two occur in Binding Updates to
> the Home Agent and are secured by IPSec, the third in Binding
> Updates to Correspondent Nodes which are secured by the Binding
> Key. Changes to the second paragraph in 9.3.1:
> 
> Mobile nodes can include a Home Address destination option in a
> packet if they believe the correspondent node has a Binding Cache
> entry for the home address of a mobile node. If the Next Header
> value of the Destination Option is one of the following: {50 (ESP),
> 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
> normally. Else, the packet MUST be dropped if there is no
> corresponding Binding Cache entry. A corresponding Binding Cache
> entry MUST have the same home address as appears in the Home Address
> destination option, and the currently registered care-of address
> MUST be equal to the source address of the packet.
> 
> =============================================
> 
> Please submit comments on the above proposal.  If consensus is
> reached soon, I will incorporate the consensus text in a revision
> of rfc3775bis to be released before the next IETF.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>