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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 26 May 2009 09:56:38 -0700

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."

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.

---

From: Brian Haley <[email-masked]>
Date: Tue, 26 May 2009 23:15:14 -0400

Hi Charlie,

> discussion about the first of the three points.

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

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Fabian Mauchle <[email-masked]>
Date: Thu, 28 May 2009 09:47:12 +0200

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Brian Haley
Gesendet: Mittwoch, 27. Mai 2009 05:15
An: Charles E. Perkins
Cc: mext
Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
errors"], part 1 of 3: "Receiving Home Address Destination Option"

Hi Charlie,

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
---------------------------------

Would be interesting how this looks like. Maybe you could post some (pseudo)
code which shows the processing and drop decision of the Home Address
Option?

Fabian

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 May 2009 11:09:23 -0400

> previously - if not the packet could be silently dropped.

Since this was done on a proprietary Unix, I'll just try and paraphrase:

1. When processing the HAO, you need to do a binding cache lookup to validate
it.  You can "remember" whether you found an entry, and whether you swapped the
address.  You need to continue to process it...

2. When processing the MH, you can consult the saved saved information from step
#1 - did I see a HAO?

You know, I might have just not read the proposal correctly.  I think the:

 "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..."

text is fine.  I don't think any other next header types would be valid.

Sorry about any confusion.

-Brian