Subject: [mobile-ip] Re: Mipv6 issue #100 (samita's comments on draft 18)

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 24 Oct 2002 11:05:34 -0700 (PDT)

Hi Jari,

Thanks for sending the text out. My response is below.

> See below for text:
> 
> 1. Section 4.1 new text:
> 
>     A mobile node is always expected to be addressable at its home
>     address, whether it is currently attached to its home link or is
>     away from home.  The "home address" is an IP address assigned to the
>     mobile node within its home subnet prefix on its home link.  While
>     a mobile node is at home, packets addressed to its home address are
>     routed to the mobile node's home link, using conventional Internet
>     routing mechanisms.
> 
>     While a mobile node is attached to some foreign link away from home,
>     it is also addressable at one or more care-of addresses.  A care-of
>     address is an IP address associated with a mobile node that has the
>     subnet prefix of a particular foreign link.  The mobile node can
>     acquire its care-of address through conventional IPv6 stateless or
>     stateful auto-configuration mechanisms.  As long as the mobile node
>     stays in this location, packets addressed to this care-of address
>     will be routed to the mobile node.  The mobile node may also accept
>     packets from several care-of addresses, such as when it is moving but
>     still reachable at the previous link.
> 
>     The association between a mobile node's home address and care-of
>     address is known as a "binding" for the mobile node.  While away
>     from home, a mobile node registers its primary care-of address with
>     a router on its home link, requesting this router to function as the
>     "home agent" for the mobile node.  The mobile node performs this
>     binding registration by sending a "Binding Update" message to the
>     home agent.  The home agent replies to the mobile node by returning a
>     "Binding Acknowledgement" message.  The operation of the mobile node
>     and the home agent is specified in Sections 11 and 10, respectively.
> 
>     Any node communicating with a mobile node is referred to in this
>     document as a "correspondent node" of the mobile node, and may itself
>     be either a stationary node or a mobile node.  Mobile nodes can
>     provide information about their current location to correspondent
>     nodes.  This happens through the correspondent binding procedure.  As
>     a part of this procedure, a return routability test is performed in
>     order to authorize the establishment of the binding.  The operation
>     of the correspondent node is specified in Section 9.
> 
>     There are two possible modes for communications between the mobile
>     node and a correspondent node.  The first mode, bidirectional
>     tunneling, does not require Mobile IPv6 support from the
>     correspondent node and is available even if the mobile node has not
>     registered its current binding with the correspondent node.  Packets
>     from the correspondent node are routed to the home agent and then
>     tunneled to the mobile node.  Packets to the correspondent node are
>     tunneled from the mobile node to the home agent ("reverse tunneled")
>     and then routed normally from the home network to the correspondent
>     node.  In this mode, the home agent uses proxy Neighbor Discovery
>     to intercept any IPv6 packets addressed to the mobile node's home
>     address (or home addresses) on the home link.  Each intercepted
>     packet is tunneled to the mobile node's primary care-of address.
>     This tunneling is performed using IPv6 encapsulation [15].
> 
>     The second mode, "route optimization", requires the mobile node to
>     register its current binding at the correspondent node.  Packets
>     from the correspondent node can be routed directly to the care-of
>     address of the mobile node.  When sending a packet to any IPv6
>     destination, the correspondent node checks its cached bindings for
>     an entry for the packet's destination address.  If a cached binding
>     for this destination address is found, the node uses a new type of
>     IPv6 Routing header [11] (see section 6.4) to route the packet to the
>     mobile node by way of the care-of address indicated in this binding.
> 
>     Routing packets directly to the mobile node's care-of address also
>     eliminates congestion at the mobile node's home agent and home link.
>     In addition, the impact of any possible failure of the home agent or
>     networks on the path to or from it is reduced.
> 
>     When routing packets directly to the mobile node, the correspondent
>     node sets the Destination Address in the IPv6 header to the care-of
>     address of the mobile node.  A new type of IPv6 Routing Header (see
>     Section 6.4) is also added to the packet to carry the desired home
>     address.  Similarly, the mobile node sets the Source Address in
>     the packet's IPv6 header to its current care-of addresses.  The
>     mobile node adds a new IPv6 "Home Address" destination option (see
>     Section ??)  to carry its home address.  The inclusion of home
>     addresses in these packets makes the use of the care-of address
>     transparent above the network layer (e.g., at the transport layer).
> 
>     Mobile IPv6 also provides support for multiple home agents, and the
>     reconfiguration of the home network.  In these cases, the mobile
>     node may not know the IP address of its own home agent, and even
>     the home subnet prefixes may change over time.  A mechanism, known
>     as "dynamic home agent address discovery" allows a mobile node to
>     dynamically discover the IP address of a home agent on its home
>     link, even when the mobile node is away from home.  Mobile nodes can
>     also learn new information about home subnet prefixes through the
>     "prefix discovery" mechanism.  These mechanisms are described in
>     Sections 10.10 and 11.4.1.
> 

Looks good.

> 2. Lifetime value 0xffffffff has been changed to 0xffff.
> 
Ok. 

> 3. Error code 137. The current text in 9.4.1. requires
>     us to silently discard BUs that have other basic
>     validation problems than old nonce indexes or
>     sequence numbers. This seems right, and hence
>     137 can not be sent in any case. This code
>     will be removed.
>

If we consider binding authenticator being similar to checksum checks,
then it seems reasonable to drop those packets which don't match the
MAC value. 

> 4. The status code 1 (Home Address destination option used without
>     a binding) has been renamed to "Unknown binding for Home Address
>     destination option", and given our earlier agreement on not
>     using solely IPsec-protected HAOs this seems now correct.
> 

Ok.

> 5. As Charlie noted, we already had text for sending the BE
>     upon illegal HAO. Anyway, Section 9.2.2 contents are now:
> 
>     Packets containing a Home Address option MUST be dropped if the
>     given home address is not a unicast routable address.
> 
>     Packets containing a Home Address option MUST also be dropped if
>     there is no corresponding Binding Cache entry for the given home
>     address.  A corresponding Binding Cache entry MUST have the currently
>     registered care-of address equal to the source address of the packet.
>     A packet that contains a Binding Update message and a Home Address
>     option is considered to pass the above tests if the Binding Update
>     successfully creates or updates a Binding Cache entry.
> 

Sorry to mention that the last sentence above is still not very clear to me.
I thought I understood before, but now it seems confusing again.

Does the sentence "
>     A packet that contains a Binding Update message and a Home Address
>     option is considered to pass the above tests if the Binding Update
>     successfully creates or updates a Binding Cache entry."

mean that the first time BUs (before bce creation) will be exempted
from the above check ? For BCE updates, there will be existing BCE
for the corresponding home-address, so it should pass the above checks for
successful updates. However, this particular check does not apply during
BCE creation, unless I am misinterpreting the language here. 

In general, in any IPv6 system, HAO should not be accepted without a mobility 
header validation or unless there is an existing valid BCE for the corresponding 
home-addr as per the base mobility draft. 

>     If the packet is dropped due the above tests, the correspondent node
>     SHOULD send the Binding Error message as described in Section 9.4.6.
>     The Status field in this message should be set to 1 (unknown binding
>     for Home Address destination option).
> 
> 6. Section 9.4.6 contents:
> 
>     Sections 9.2.1 and 9.2.2 describe error conditions that lead to a
>     need to send a Binding Error message.
> 
>     A Binding Error message is sent to the address that appeared in the
>     IPv6 Source address field of the offending packet.
> 
>     The Home Address field in the Binding Error message MUST be copied
>     from the Home Address field in the Home Address destination option of
>     the offending packet, or set to the unspecified address if no such
>     option appeared in the packet.
> 
>     Binding Error messages are subject to rate limiting in the same
>     manner as is done for ICMPv6 messages [ref].
> 

Ok.

> 7. Section 10.3 text
> 
>     -  The Refresh field MUST be set to zero.
> 
>     has been changed to
> 
>      -  The Binding Refresh Advice mobility option MUST be omitted.
> 
Ok.

> 8. We have added a term for registration
> 
>        registration
>                  The process during which a mobile node sends a
>                  Binding Update to its home agent, causing the home agent
>                  to take the actions which will enable packets to be
>                  forwarded from the mobile node's home network to the
>                  mobile node's care-of address.
> 
Ok.

-Samita

---

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Oct 2002 23:46:25 +0300

> BCE creation, unless I am misinterpreting the language here. 

Remember that we can't test the packet before the binding update
is done. This applies both to creation as well as updating because
the care-of address might be old.

So, what the text tries to capture is that for BUs the "regular"
test is not applied at all. Instead, if BUs are passed through
the stack and processed normally, and as a part of the BU processing
we have other means for preventing reflection attacks, such as the
rules on where BAs are sent.

Perhaps writing the text as follows would make it clearer:

    These tests MUST NOT be done for packets that contain a
    Binding Update and a Home Address option.

This text would also be better in the sense that the original
text left you wondering about what to do if the BU failed.

Jari