Subject: Re: [MOBILE-IP] Appendix

From: "Kay, Rodney" <[email-masked]>
Date: Mon, 13 Nov 2000 15:52:49 -0600

Agreed!

Rodney H. Kay
Department of Veterans Affairs
Puget Sound Health Care System
Systems Manager
Seattle, Washington  98108

-----Original Message-----
From: Powell, Ken [mailto:[email-masked]]
Sent: Monday, November 13, 2000 1:37 PM
To: [email-masked]
Subject: Re: [MOBILE-IP] Appendix

Can we back up a bit? We are headed down a long
process to redefine how router advertisements
and solicitations are sent, adding binding support
for link-local addresses, and probably rethinking
the IPsec details for this exchange. This isn't a
trivial effort. It will take time and require
careful review. Do we really want to proceed
with this? If so, could we get an updated snapshot
of the spec before we proceed too far? I'm in the
mode of defining changes to changes now.

Thoughts?

> -----Original Message-----
> From: Mattias Pettersson [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 8:41 AM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] Appendix
>
>
> Hi all,
>
> Again Ken, thanks for doing this study.
>
> "Powell, Ken" wrote:
> >
> > Charlie,
> >
> > I must have miscommunicated something here. The
> > text you proposed for appendix A has elements of
> > two conflicting approaches to solve the problem
> > of needing a global home address to generate a
> > global home address:
> >
> >   A) The initial text for generating a temporary home
> >      address is only needed if we use the current
> >      technique of exchanging the router solicits
> >      and router advertisements.
> >
> >   B) Steps 5 and 6 show how to send router solicitations
> >      and router advertisements using tunnels in a way
> >      that does not need the initial home address.
> >
> > If we do B, we don't need to do A.
> >
> > I have some big problems with B still. It was just
> > a quick proposal to give a vague idea how we could
> > meet Mattias's objectives. It does this by redefining
> > how router solicitations and router advertisements
> > are tunneled. This seriously impacts many sections
> > throughout the spec and needs to be fully defined
> > if we are going to use it.
> >
> > Last night, I decided to run through the exercise of
> > finding the spec changes to support option B. I had a
> > gut feeling it was going to be difficult, and it
> > was. I'm including what I have so far with comments
> > sliced in showing the outstanding issues and giving
> > possible approaches to further changes. This is not
> > complete.
> >
> > I think we should drop tunneling (option B) and return
> > to the original proposal for appendix A. I went back
> > to see how we stand with Mattias's key objectives by
> > doing this.
> >
> > >> I would like the option to let the MN configure it's
> > >> home address as if it was at home, even if it is not
> > >> at home.
> >
> > In approach A, the initial steps that generate a
> > temporary home address during the bootstrap phase
> > is the only part that is different. It does revert
> > to the same methods and results as if the mobile
> > node were physically at home once we get over the
> > bootstrap phase. The initial temporary address gets
> > deleted through the time-out mechanism if it does
> > not get updated through stateless address
> > autoconfiguration or DHCPv6.
> >
> > >> What I want is to open up the possibility for the MN
> > >> to go through step 2-5 without neither having a home
> > >> address nor having been at home before.
> >
> > The mobile node does not have to be preconfigured with
> > any global address. It just needs a globally unique
> > interface id.
> >
> > >> Summary: we don't need a parallel address configuration
> > >> method for mobile nodes. A mobile node will be configured
> > >> exactly as if it was at home.
> >
> > This is the piece we can't satisfy with option A, but can
> > with option B. Option A requires the additional address
> > configuration method to bootstrap communications.
> >
> > Here are the detailed changes I came up with so far to
> > support option B. Side comments are bounded with "<>".
> > Are these changes really worth pursuing? Its going to
> > take much more effort to scrub it properly.
> >
> > If we are going to adopt option B, we should do it now
> > because it is not backward compatible.
> >
> > On page 70, replace the tunneling technique with:
> > =================================================
> >
> >    In tunneling each such Router Advertisement to the
> mobile node, the
> >    home agent MUST construct the packet using IPv6
> encapsulation [4] as
> >    follows:
> >
> >     -  The tunnel entry point is the home agent's IP address to
> >        which the mobile node addressed its current home
> >        registration. If the router advertisement is being sent
> >        in response to a router solicitation from a node with no
> >        current home registration, the tunnel entry point is set
> >        to the exit point of the tunnel thru which the original
> >        router solicitation was received.
> >
> >     -  The tunnel exit point is the primary care-of address. If the
> >        router advertisement is being sent in response to a router
> >        solicitation from a node with no current home registration,
> >        the tunnel exit point is set to the entry point of the tunnel
> >        thru which the original router solicitation was received.
> >
> >        < I think its possible to do this, but I suspect it will
> >          require serious changes to existing stacks to carry the
> >          tunnel source and destination address up and down the
> >          stack with decapsulated packets. A possible way to avoid
> >          tunnel implementation issues is to support bindings
> >          on the home agent for the mobile node's link local
> >          address. Once done, the kernel could use much the
> >          same mechanisms to route RA/RS with link local addresses
> >          as it would use for routing the mobile node's global
> >          home addresses. This of course would require another
> >          whole series of changes to the spec. >
>
> This idea of registering the link-local address is very
> interesting. The
> Mobile Node could carry out everything from RS/RA to DAD and DHCPv6
> itself, without proxy functions in the HA. But somehow the idea in the
> I-D is to not allow mobility for link-local addresses.
>
> There are both pros and cons of forwarding link-local packets
> to the MN.
> The MN gets more aware of what's happening on the home link,
> but at the
> same time a lot of unecessary traffic is tunneled to the MN.

I would recommend against forwarding any link-local traffic
between the home network and the mobile node. The overhead
traffic of a lower cost home network could become a major
problem on wireless links. I had intended to keep the proxy
functions in the home agent and use link-local bindings to
support traffic between the mobile node and the home agent
only.

>
> >
> >     -  The Source Address of the inner IPv6 header is set to the
> >        home agents link-local IP address on the home network.
> >
> >     -  The Destination Address of the inner IPv6 header is set to
> >        the mobile node's home subnet link-local address.
> >
> >        < I first intended to use the all-nodes multicast address,
> >          but didn't know if IPsec works well with multicast
> >          addresses. >
> >
> >     -  The inner IPv6 header must be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >        < I initially considered putting this in the tunnel header,
> >          but most tunneled packets from the home agent to the mobile
> >          node don't require IPsec, so this would probably require
> >          special logic in the tunnel code to handle. I expect
> >          applying IPsec to the inner header would be easier and
> >          will still achieve the intended security. >
> >
> >     -  The packet MUST include a Binding Request destination option
> >        after the IPsec Authorization or Encapsulation header.
> >
> >        < Putting the Binding Request here allows the mobile node
> >          to strip off the outer IPv6 headers the same as it would
> >          do for any other tunneled message. >
>
> I believe the HA should only include the BR when the RA is transmitted
> on HA initiative. If the RA is being sent in response to a RS from the
> MN, then the BR should be omitted.
>
> This wouldn't be an implementation issue, would it?

This would add special case in the algorithm to send router
advertisements that I don't think is needed.

>
> >
> >     -  The Binding Request destination option MUST include a Unique
> >        Identifier Sub-Option (Section 5.5), with the unique
> identifier
> >        in the sub-option data set to a value different than that in
> >        any other Binding Request sent recently by this
> node.  The word
> >        "recently" here means within the maximum likely lifetime of a
> >        packet, including transit time from source to destination and
> >        time spent awaiting reassembly with other fragments
> of the same
> >        packet, if fragmented.  However, it is not required
> that a source
> >        node know the maximum packet lifetime.  Rather, it is assumed
> >        that the requirement can be met by maintaining a
> simple 16-bit
> >        "wrap-around" counter to generate unique identifiers
> for Binding
> >        Requests that contain a Unique Identifier
> Sub-Option, incremented
> >        each time a Binding Request containing a Unique Identifier
> >        Sub-Option is sent.
> >
> >        < Its going to be difficult to track the status of this
> >          binding request when the mobile node has no home address
> >          and has not yet created a binding. Once again, creating a
> >          binding for the mobile node's link-local address
> would help. >
>
> So, if we skip BR in this case, we don't have this matching problem.
>
> On the other hand, I kind of like the idea of first registering the
> link-local address, carry out the RS/RA, and then configure the home
> addresses and send a BU for them. Link-local address
> registration could
> be left to expire, after that.

Thats just what I was thinking, except that I believe
it would be better to make the link-local addresses
be permanent and always use link-locals only for RS/RA
exchange. This would allow the RS/RA addresses map
more closely to what is used on the home subnet.

>
> >
> > On page 92, replace the rules for validating
> > received router advertisements on the mobile node:
> > ==================================================
> >
> >    When a mobile node receives a tunneled Router
> Advertisement, it MUST
> >    validate it according to the following tests:
> >
> >     -  The Router Advertisement was received over a tunnel whose
> >        entry point was the same as the home agent address
> to which the
> >        mobile node last sent an accepted "home registration" Binding
> >        Update to register its primary care-of address. If no home
> >        registration exists yet, the tunnel entry point must be the
> >        same as the exist point of a tunnel through which a
> >        Router Solicitation was recently transmitted.
> >
> >     -  The inner IPv6 packet MUST be protected by IPsec [13, 11, 12]
> >        to guard against malicious Router Advertisements.  The IPsec
> >        protection MUST provide sender authentication, data integrity
> >        protection, and replay protection, covering the Router
> >        Advertisement.
> >
> >     -  The inner packet contains a Binding Request
> destination option.
> >
> >     -  The Binding Request option contains a Unique Identifier
> >        Sub-Option.
> >
> > Modify my previous proposal for sending Router
> > Solicits from the mobile node to the home agent:
> > ================================================
> >
> > The mobile node must construct and tunnel such a Router Solicitation
> > packet using IPv6 encapsulation [4] as follows:
> >
> >  -  The tunnel entry point is the mobile node's primary care-of
> >     address.
> >
> >  -  The tunnel destination is the home agent's global IP address.
> >
> >  -  The Source Address of the inner IPv6 header is set to the
> >     unspecified IP address (0::0).
> >
> >  -  The Destination Address of the inner IPv6 header is set to
> >     the all routers multicast address.
> >
> >  -  The tunnel header MUST be protected by IPsec [13, 11,
> 12] to guard
> >     against malicious Router Solicitations.  The IPsec protection
> >     MUST provide sender authentication, data integrity protection,
> >     and replay protection, covering the Router Solicitation.
> >
> >     < I think we should keep this requirement if responding to
> >       unauthorized probes for address information could be a bad
> >       thing at some sites. >
>
> Ok. Since the RA in return anyway requires this SA, it
> doesn't matter if
> we create it at this stage.
>
> >
> >     < If we decide link-layer address bindings are a good thing,
> >       we could send a binding update in the inner IP packet
> >       for the link-layer address, and specify an Alternate Care-Of
> >       suboption containing the mobile node's primary care-of
> >       address. >
>
> Yeah!

Another catch, How does one return a binding ack for a failed link
local binding atempt?

>
> >
> >  - The Router Solicitation's source link-layer address
> >    option MUST be omitted.
> >
> >     < We may wish to change this given home subnet link layer
> >       address in the inner IP header and a possibility of a
> >       binding for the link layer address. >
> >
> > Modify my previous proposal for how the Home Agent
> > receives Router Solicitations from Mobile Nodes
> > =================================================
> >
> > The Router Solicitation may include a Binding Update
> > destination option. The processing requirements described
> > here for the Router Solicitation assume the Binding Update
> > destination option was processed first. The home agent MAY
> > return a single packet containing both the resulting Binding
> > Acknowledgment destination option and a Router Advertisement.
> >
> >  < Remove paragraph on how to handle binding
> >    updates included with the router solicitation
> >    unless we implement bindings for a link-layer
> >    addresses >
> >
> > When a home agent receives a tunneled Router Solicitation from
> > a mobile node on a remote network, it MUST validate it according
> > to the following tests:
> >
> >  - The inner packet is protected by IPsec [13, 11, 12] to guard
> >    against unauthorized probes for home subnet information.  The
> >    IPsec protection provides sender authentication, data integrity
> >    protection, and replay protection, covering the Router
> >    Solicitation.
> >
> >     < All the other tests are unnecessary with tunnels
> >       unless we implement bindings for link-local
> >       addresses. >
> >
> > > -----Original Message-----
> > > From: Charles E. Perkins [mailto:[email-masked]]
> > > Sent: Thursday, November 09, 2000 4:38 PM
> > > To: Mattias Pettersson; Powell, Ken
> > > Cc: Mobile IP Mailing List
> > > Subject: Appendix
> > >
> > >
> > >
> > > Hello folks,
> > >
> > > Here is a stab at an appendix.  It needs proofreading, but
> > > I have to go for now and I thought it would be better to
> > > send something defective for now and touch it up more later.
> > >
> > > My opinion is that a Binding Update is needed, and if it takes
> > > another few hundred milliseconds, that's O.K.  So, I retained
> > > that step for the part after the Router Advertisement was
> > > received by the mobile node.  However, this is of course up
> > > for discussion.
> > >
> > > I reckon the hard part will be to manage the identification
> > > for the mobile node.  As Hesham mentions, NAI could be used
> > > for this.  However, I am sure that everyone agrees that right
> > > now is not the time for trying to complete that discussion.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > >
> =====================================================================
> > >
> > >
> > > A. Remote Home Address Configuration
> > >
> > >    The method for initializing a mobile node's home addresses on
> > >    power-up or after an extended period of being disconnected from
> > >    the network is beyond the scope of this specification.
>  Whatever
> > >    procedure is used should result in the mobile node
> having the same
> > >    stateless or stateful (e.g., DHCPv6) home address
> autoconfiguration
> > >    information it would have if it were attached to the
> home network.
> > >    Due to the possibility that the home network could be
> renumbered
> > >    while the mobile node is disconnected, a robust mobile
> > > node would not
> > >    rely solely on storing these addresses locally.
> > >
> > >    A mobile node MAY generate a temporary home address using the
> > >    following information:
> > >
> > >     -  the subnet prefix from the home network's mobile
> agent anycast
> > >        address, and
> > >
> > >     -  the globally unique interface identifier that
> would have been
> > >        used to generate the link local address if the
> mobile node were
> > >        attached directly to the home network.
> > >
> > >    Such a temporary address could be used to establish a
> binding with
> > >    a home agent in the absence of any other known home
> addresses.  It
> > >    could be created with short valid lifetime and a
> preferred lifetime
> > >    of zero to ensure a quick transition to other
> addresses generated
> > >    when stateless or stateful (DHCPv6) address
> autoconfiguration runs.
> > >
> > >    Such a mobile node could initialize by using the following
> > > procedure:
> > >
> > >     1. Query DNS for the home network's mobile agent
> anycast address.
> > >
> > >     2. Generate a care-of address using stateless or stateful
> > >        autoconfiguration.
> > >
> > >     3. Send a Home Agent Address Discovery Request
> message to the home
> > >        network.
> > >
> > >     4. Receive Home Agent Address Discovery Reply message.
> > >
> > >     5. MN picks one Home Agent and tunnels an Router
> > > Solicitation to it.
> > >
> > >           Outer src = care-of address
> > >           Outer dst = Home Agent's global address
> > >           Inner src = 0:0:0:0:0:0:0:0 (unspecified address)
> > >           Inner dst = Home Agent's global address
> > >
> > >
> > >     6. Home Agent returns a Router Advertisement, covered
> by AH. An SA
> > >        has to be set up between MN's CoA and the HA. How
> this is done
> > >        is out of scope, but MN and HA have some shared secret
> > > or can be
> > >        verified by some agent.
> > >
> > >        The Router Advertisement is returned by tunneling,
> as follows:
> > >
> > >           Outer src = HA's global address
> > >           Outer dst = care-of address
> > >           Outer src = HA's home subnet link-local address
> > >           Inner dst = all-nodes multicast address
> > >
> > >
> > >     7. Mobile node parses Router Advertisement and configures all
> > >        prefixes and addresses according to the method stated
> > > there.  If
> > >        the the M or O flags are set in the router
> > > advertisement, follow
> > >        the stateful (DHCPv6) configuration procedures.
> > >
> > >     8. Send binding update option(s) to establish
> bindings for the new
> > >        home addresses.
> > >
>