AW: intermediate mobike design draft update

hi pasi, 

thanks for your feedback. let me give you some comments below: 

> Hi,
> 
> I have some comments and suggestions about the terminology about
> addresses/pairs/paths in mobike-design-02.
> 
> 1)
> 
> Currently the definition of "preferred address pair" is quite
> imprecise, since it unnecessarily mixes what is preferred with
> what is actually happening. Also, it's not quite clear what's
> the difference between "preferred address pair" and "primary
> path".
> 
> I'd suggest we replace both of them with a new term, say
> "current path" (or "current address pair"), that means the
> addresses that are currently used by the peer as the tunnel
> header addresses of IPsec packets (of IPsec SAs associated
> with this IKE SA).

i tried to prevent reinventing new terms here and used the term 'preferred
address' from 
<draft-ietf-hip-mm-00.txt>

it is true that the definition of preferred address pair and primary path
point to the same concept. 

i have replaced the term "preferred address pair" with "primary path". 

> 
> I think we had rough consensus on issue 8 (scope of SA changes);
> thus, each peer has only a single "current path", and in stable
> situations (when nothing MOBIKE-related has been happening
> recently), the "current path" is equal to the path used for
> sending IKEv2 requests (for e.g. rekeying).

true. 

> 
> Both peers A and B have their own current path, and they're not
> always equal (they are never equal if NATs are involved, and
> even if no NATs are involved, they are different for at least
> short periods of time when something MOBIKE-related is
> happening).

it is true that each peer has it's own view of the world and there might be
an inconsistency of the established state information. ideally, the state of
the two peers should be synchronized. 

based on <draft-arkko-multi6dt-failure-detection-00.txt> i would, however,
argue that we both peers try to have the same 
primary path. this means, for example, if peer 1 has a preferred address
ip_a and peer 2 has a preferred address ip_b then the path is between ip_a
<-> ip_b for both peers. 

we could also utilize something like an undirectionally operational address
pair (definition from <draft-arkko-multi6dt-failure-detection-00.txt>). this
would mean (with the above example) that peer 1 would send messages to ip_b
at peer 2 and peer 2 would return messages to an address ip_a2 (although the
source address of the mesgs hitting peer 2 use ip_a1). 

this approach would, however, cause problems with nat handling. 

> 
> It's a separate question whether the current paths should be
> equal in stable situations (where NATs are not present). In
> MOPO-IKE, they are (the responder uses the path selected by the
> initiator).  In SCTP, they're not (each peer makes its selection
> independently).  I'm not sure which is the case for
> draft-dupont-ikev2-addrmgmt (Francis, could you clarify this?)
> 
regarding sctp there is very little text on how addresses are selected (at
least i haven't found the text paragraphs). 
it is just a policy issue. since we are concerned about nat handling we
should talk about bidirectionally operational address pairs. 

> 2)
> 
> Most of the time, RFC2960 uses the word "path" to mean a 
> combination of source and destination address (and mostly
> avoids the term "address pair"). I much prefer the word "path",
> and I'd suggest we use that one (but whichever we use, it
> should be consistent throughout the whole document).
> 

i agree with you. 


> 3) 
> 
> The definition of "Available address" says that "Where IPv4 is
> considered, it is not an RFC 1918 [RFC1918] address." Why? For
> instance, if the peers are connected to some private network
> that happens to use RFC 1918 addresses, and there are no NATs
> involved, why they're not allowed to use MOBIKE?  (I'd suggest
> removing this bullet.)

i fully agree with you. i asked myself the same question when i read 
but then i forgot it again when i copied the text from jari's draft to this
draft. 

> 
thanks for your feedback. 

ciao
hannes
> 
> Best regards,
> Pasi
>