Re: request to review draft in mobile IP wg

[Cheryl Madson <cmadson@cisco.com>]

At 08:35 AM 10/28/2002, Jari Arkko wrote:

>Hi,
>
>I'd like to ask the help of the IPsec WG to take a look at a draft
>which is being worked on in the Mobile IP working group.

<snip>

Jari,

[Speak up if the formatting comes out too weird; I think I stripped
all of the residual formatting from cut-and-paste, but it's hard to
tell...]

I've taken a quick pass through the draft. It's a great improvement
over previous drafts -- I can almost understand it now ;-).

I have several comments, split up into issues and comments. Some
of this may be simply because I don't fully understand MIP, but it
probably wouldn't hurt to have a bit more detail for those in the
IPsec-geek-but-MIP-novice camp (and who may find the main draft
more than a little intimidating...).

Issues:

a.  I'd understood that MobileIP supported its own tunnels between
      a MN and an HA. Is the intent that these IPsec tunnels (which
      don't simply represent a securing of MobileIP tunnels) are
      replacing the MobileIP tunnels?

b.  Sequence of events relative to changeover of addresses relative to
      changing IKE and/or IPsec endpoints. This issue is glossed over too
      much in this draft; this should be spelled out in much greater detail.
      [This is the area that makes me the most nervous, since there is so
      little detail; I can't convince myself that things will behave properly.]

     + When should new CoA be used? Immediately? Upon completion of the
        BU/BA exchange?

     + What happens if BU or BA is dropped?

     + May need recommendations as to how to handle address change
        during a rekey -- there is a potential for higher chance of lost 
packets,
        at least in the short term. If out-of-sequence events cause more
        retransmissions in a shorter period of time, this could become
        problematic for certain types of devices in this space.

     + May need recommendations as to how to handle address change for
        things like dead peer detection/keepalives.  [I'll ask (cringingly 
-- is that
        a word?) -- would NAT also be a possibility in this scenario?]

c.   What differences, if any, are there when a MN acts as a MR?

d.   Is it possible for a MN to have several simultaneous connections to
       different HAs? How does this scenario play out relative to this draft?

e.  There is no hiding of the home address-to-COA binding. It might not hurt
      to point this out. Is this acceptable?

f.  Relative to packet handling for BU/BA and PD/PA messages:
     are there other scenarios where the value in the Home Address Option/
     RH2 headers should not override the address in the v6 header? If so,
     how will a node be able to distinguish?


Comments

a. Buried amongst the discussion of manual keying, there is a
     comment about dealing with new prefixes. Why is this not
     mentioned at all until here -- why isn't this discussed earlier
     in the general processing discussions, or at least in the
     Requirements chapter? Also, it seems like the text in this section
     and the dynamic keying section could be better aligned.
          + Are all of these addresses active at once? What triggers their
             usage?

b. Very little is said of IKE in the requirements section. I'd like to see 
more
     of  an outline of the requirements of MNs and HAs relative to IKE in this
     section.

c. What is the granularity of a "user" relative to a MN? Can a MN support more
     than one user? (Do they get separate home addresses? Share a home
     address? ??) If so, how is that associated with traffic selectors 
(which traffic
     selectors are associated with which user)?

d.  Something that just came off the top of my head, so I've done no analysis
      whatsoever: has there been any analysis of a separate step for 
performing
      address mapping on IKE and IPsec packets (e.g. they do their processing
      based on home address, and something else maps between that and the
      CoA)? [I probably should be appalled at myself for that suggestion...]

      + IKE should already be selecting its SAs based on cookies.
      + ESP would have no affect. AH could be done with the home address
         in the outer IPv6 header.

I didn't have time to look at the base draft. And I don't think I'll have 
time to revisit
this draft in any detail anytime soon... but I'll try to keep an eye on 
this thread
when I get the time, or we can talk in Atlanta.

thx (Kiitos ;-) - C



====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
cmadson@cisco.com