[Mobike] More Comments on draft-ietf-mobike-design-01.txt

[Maureen.Stillman at nokia.com]

Thanks for your prompt response to my comments.  Again, most of my
comments are nits, although some are more substantial.  Take what you
think is helpful.  I didn't have time to review the whole document in
one sitting so more comments will come later.

3.3 Multihomed laptop scenario

... in order to sent IP packets...
1) Should be ...in order to send IP packets...

Some of these
   interfaces might connected to a network over the time depending on a
   number of reasons (e.g., cost, availability of certain link layer
   technologies, user convenience).  
2) A number of different
   interfaces can be activated over the time depending on
   policies, e.g., cost, availability of certain link layer
   technologies and user convenience.  Note that a policy for selecting
a network interface based on cost, etc. is out of scope for Mobike.

I'm concerned that some people might think that Mobike does some of this
policy management and network selection if we don't point out explicitly
that it does not.  Thus I have included the extra sentence above.

For example, the user can
   disconnect himself from the fixed Ethernet, and then use the office
   WLAN, and then later leave the office and start using GPRS during the
   trip to home.  At home he might again use again WLAN.

3) Just fixing nits here.
For example, the user can
   disconnect himself from the fixed Ethernet, use the office
   WLAN, and then later leave the office and start using GPRS during the
   trip home.  At home he might again use WLAN. 

4. Framework
4) I suggest that you put the last part of the section up front.  It
does a nice job of setting up the framework.  Then the framework is
explained.  Here is the last paragraphs in the framework with nits
fixed.  I took the last bullet that I thought was too long and split it
up and fixed nits.

4) 4. Framework
Although the interaction with other protocols to determine the preferred
address and preferred address set is important for MOBIKE
   to operate correctly the working group is chartered to consider this
   aspect out of scope.  The working group will develop a MOBIKE
   protocol with the following functionality:
   o  Ability to inform a peer about the peer address set
   o  Ability to inform a peer about the preferred address
   o  Ability to test connectivity along a path and thereby to detect an
      outage in order to fall back to another address, thereby making it
the           new preferred address
   o  Ability to change the peer address set
   o  Ability to deal with Network Address Translation devices

The technical details of these functions are discussed below.

5) Now comes the text that was the start of the framework section and I
have fixed some nits.  Here is the original text (2 paragraphs) followed
by my changes:

Initially, when a MOBIKE peer starts and executes the initial
   protocol exchange with its MOBIKE peer it needs to setup a peer
   address set based on the available addresses.  It might want to make
   this peer address set available to the other peer.  The Initiator
   does not need to explicitly indicate its preferred address since
   already using its preferred address.  The outgoing IKEv2 and MOBIKE
   messages use this preferred address as the source IP address and
   expects incoming signaling messages to be addressed to this address.

   Interaction with other protocols at the MOBIKE host is required to
   build the peer address set and the preferred address.  In some cases
   the peer address set is available before the initial protocol run and
   does not change during the lifetime of the IKE-SA.  The preferred
   address might change due to policy reasons.  In many other cases, as
   motivated in Section 3 the peer address set is modified (by adding or
   deleting addresses) and the preferred address needs to be changed as
   well.

------------- my suggested edits --------------------------------

When a MOBIKE peer initiates a 
   protocol exchange with its MOBIKE peer it needs to define a peer
   address set based on the available addresses.  Optionally, it can
make
   a peer address set available to the other peer.  The Initiator
   does not need to explicitly indicate its preferred address since it
is
   already using its preferred address.  The outgoing IKEv2 and MOBIKE
   messages use this preferred address as the source IP address and
   expects incoming signaling messages to be sent to this address.

   Interaction with other protocols at the MOBIKE host is required to
   build the peer address set and the preferred address.  In some cases
   the peer address set is available before the initial protocol
exchange and
   does not change during the lifetime of the IKE-SA.  The preferred
   address might change due to policy reasons.  Section 3 describes
three scenarios in which the peer address set is modified (by adding or
   deleting addresses).  In these scenarios the preferred address needs
to be changed as well.

6) Another nit just above the picture

Testing other paths might also be useful to notice when a disconnected
path is operational again.

How about:
Optionally, periodic testing of other paths might be useful to determine
when a disconnected path becomes operational.

7) This paragraph below needs to be moved to the security considerations
section.  It needs to be worded differently and solutions need to be
discussed, but I'll get to that when I send comments later on security
considerations.  Here is the paragraph to move:

In addition to the above-listed functionality security is important
   to the working group.  For example, the ability to prevent flooding
   attacks based on announcing someone else's address needs to be dealt
   with.

8) I would delete the paragraph below.  Comparing MOBIKE to other
protocols is a complex topic and this one sentence is neither
technically informative nor complete.  It will just raise a lot of
questions and cause a lot of confusion and argument.  I don't think it
belongs in a framework document.  If you are just trying to say that In
Mobike both the IKE-SA and IPsec SAs addresses are affected by the
change in address, then just say that only.  Here is the paragraph to
delete.

Note that MOBIKE is somewhat different compared to, for example, SCTP
   mobility since both the IKE-SA and the IPsec SA is affected by the
   change of addresses.

More later.  Thanks for your prompt response to my first set of
comments.

-- Maureen