Subject: [mobile-ip] Mobile IPv6 draft 15

From: Charlie Perkins <[email-masked]>
Date: Sat, 17 Nov 2001 17:01:38 -0800

Hello folks,

A new revision of Mobile IPv6 has been prepared.  It is currently
available at the following URL:
    http://people.nokia.net/~charliep/txt/mobilev6/mobilev6.txt
This new draft repairs minor problems which have been noticed
with draft ...-14.  The biggest change was to remove all the previous
support for mobile routers, since it has been agreed that will be a
different protocol specification.  After removing it, I had to put
in a bit to turn off and on the home agent behavior of configuring
multiple Binding Cache entries after receiving a Binding Update
for only a single care-of address.  Details are in the draft.

Please note that the issuance of this draft does NOT amount to
any statement about convergence on recent discussion items
related to security matters, or including Destination Options with
payload.  It is expected that another draft will be issued whenever
current discussion topic areas are better able to be resolved.

Included with this message is appendix A.1, which itemizes the
main changes to the draft.

Regards,
Charlie P.

A.1. Changes from Draft Version ...-14

    -  Strengthented mandates for mobile nodes so that now a mobile node

       MUST support decapsulation and processing for routing headers
       (section 10.3).

    -  Enabled ESP to be a valid way to secure reverse tunneled packets
       (section 9.5).

    -  Removed mandate that mobile node select a default router,
       and instead described it as typical behavior (section 10.4).
       Also made it clear that picking a new default router does not
       automatically mean picking a new primary care-of address.

    -  Added provisional ICMP numbers for the new message types, which
       may be reassigned by IANA, but which will be useful for testing
       purposes.

    -  Removed the Mobile Router Prefix Length Sub-Option

    -  Removed the Prefix Length field from the Binding Update, and
       references to error number 136.

    -  Added the `S' bit so that the home agent can be instructed to
       *override* its default behavior.  That is, with the `S' bit
       set, the home agent will not attempt to be helpful by changing
       multiple Binding Cache entries, for multiple routing prefixes,
       after receiving only one Binding Update.

    -  Reworded the specification so that the Home Agent now has to
       perform Duplicate Address Detection for the mobile node's address

       on all the prefixes for which the router is performing home agent

       service.

    -  Removed the section about Mobile Routers

    -  Added the Authentication Data Sub-option; reorganized the section

       about computing authentication data.

    -  Specified that the Home Agent lifetime is by default the same as
       the Router lifetime, in a Router Advertisement.

    -  Specified that Binding Updates with zero lifetime and the 'A' bit

       set should cause a Binding Acknowledgement to be sent back to the

       Source IP address of the Binding Update.

    -  Qualified the allowable times when a mobile node can send a
       Binding Update to a correspondent node

    -  Added text allowing the correspondent node to extend an existing
       Routing Header by also including the care-of address as the entry

       of a routing header to be visited immediately before the home
       address.  In this way, for instance, the mobile node can be an
       intermediate node of a path along the way to some other node.

    -  Removed the Home Address field from the Home Agent Address
       Discovery Request Message.

    -  Noted that ICMP Unreachable forms a potential mechanism by which
       a malicious node can cause a correspondent node to delete a valid

       entry from its Binding Cache.

    -  Specified that, when a router stops offering home agent services
       by turning off the 'H' flag, the mobile node has to delete the
       corresponding entry from its Home Agent list.

---

From: Brian Haley USG <[email-masked]>
Date: Mon, 26 Nov 2001 12:01:42 -0500

Francis Dupont wrote:
>    Of course it was dropped since during Binding Update processing we
>    noticed we didn't have a Home Address (ala Section 8.2)...
>    
> => you had it but you didn't already processed it. This is more
> a proof that BU should not be destination options (:-), at least
> you should agree that to support this case BUs should be processed
> only when the terminal header is reached.

I am worried about the scaling problems inherent in (basically) processing
a received packet twice, which is why we follow the 2460 recommendation
I cited:

>    I believe this ordering is invalid according to Section 4.2 of RFC 2460:
>    
>      The sequence of options within a header must be processed strictly in
>      the order they appear in the header; a receiver must not, for
>      example, scan through the header looking for a particular kind of
>      option and process that option prior to processing all preceding
>      ones.
>    
> => I disagree, the meaning of the Section 4.2 is not what you suggest.

I'll agree to disagree on this.

>    [5.4]
>     The Home Address option MUST be placed as follows:
>    
>      - After the Routing Header, if that header is present
>      - Before the Fragment Header, if that header is present
>      - Before the AH or ESP Header, if either one of those
>        headers is present
> 
> => note this clause is a good reason to put the home address option
> in a destination option before the one with the BU. And as there can
> be an IPsec header a lot of implementations will apply this in all cases.

But your test didn't :)  I do realize that using IPsec "fixes" this.

>      - Before any headers or options that require Home Address
>        option information, such as a Binding Update option
>    
>    While one might think I just don't want to do more work since there is
>    one implementation that handles this case, I can't believe the Home
>    Address option was intended to be used in this way.
>    
> => I disagree: this case (BU then HA) is so funny (and takes less bytes)!

What is it, 8 bytes?  That doesn't seem like much to me, but I'm not
on the wireless end of things.

> PS: as this issue is in mobile IPv6 drafts since years, I believe
> we should wait for security problem resolution before revisiting
> this point.

I would have liked to see other comments on this as well...

-Brian