55 - scope and limitations (marcelo's issue)

Jari Arkko writes:
> Thanks again Marcelo for your comments. This is
> very useful. There was really a number of subissues:
> 
> 1) Are multiple address pairs allowed?
> 2) Are unidirectional address pairs allowed?
> 3) Multihoming for the establishment phase v.s only later?
> 3b) If MOBIKE retries in establishment phase, does it vary source address?
> 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR
> 5) Is simultaneous movement supported?
> 6) Are only local failures supported?

I think these are mostly questions for the design draft. I tried to
check that at least some of those are answered by the new version of
design draft, but you might want to check that I didn't miss something
(I was a bit hurry when making that draft to get it out before
deadline). 

> 1.1 Limitations
> 
>    This document focuses on the main scenario outlined above, and
>    supports only tunnel mode.
> 
>    The mobility support in MOBIKE allows either party to move,
>    but not both at the same time. This implies that MOBIKE is best
>    suited for client - gateway or gateway - gateway applications. Two
>    mobile clients would find it hard to use MOBIKE directly between
>    themselves, and for such applications a gateway is recommended
>    between the communicating clients.
> 
>    The multihoming support in MOBIKE allows either party to have
>    multiple addresses. This specification does not guarantee that
>    more than pair of such addresses can be used for payload traffic
>    at any one time, however. This implies that load-balancing applications
>    are out of scope in the base protocol. Similarly, due to the nature
>    of the IKEv2 protocol and NAT considerations, MOBIKE is only guaranteed
>    to work correctly over bidirectionally operational address pairs.
>    That is, the same pair of addresses is used in both directions. Indeed,
>    the protocol mechanisms used to determine reachability of the
>    peer ensure that such a pair is in use.
> 
>    The MOBIKE protocol can only be used once the IKE SAs have
>    been established. This implies that movements or additional
>    addresses for the peer can not be discovered until a working
>    connection to the peer has been established. This implies that
>    the IKE SA establishment phase has limitations with regards to
>    initial discovery of alternative addresses, unless those addresses
>    are known in the configuration and/or DNS. For details, see
>    Section 4.0.
> 
>    NATs introduce additional limitations beyond those listed above.
>    For details, refer to Section 3.3.
> 
>    The base version of the MOBIKE protocol may also not cover all potential
>    future use scenarios, such as transport mode, application to securing
>    SCTP, or optimizations desirable in specific circumstances.  Future
>    extensions may be defined later to support additional requirements.

Perhaps add pointer to the design draft also (to the point where it
explains more about these issues, i.e. section 5.1 for choosing
addresses, multihoming, unidirectional paths etc, and section 5.2. for
NAT, at least).

But that text is good summary of the limitations.

> And a new Section 4.0 between 4. and 4.1:
> 
>    4.0 Addresses for the Initial IKE Exchange
> 
>    The initiator is responsible for finding a working pair of
>    addresses so that the initial IKE exchange can be carried
>    out. Any information from MOBIKE extensions will only be
>    available later, when the exchange has progressed far enough.
> 
>    IKE initiator may retrieve the peer address(es) from various
>    sources, such as the outgoing packet that triggered the
>    IKE exchange, configuration, or DNS. Similarly, the initiator
>    knows its own address(es).
>  
>    If multiple peer addresses are known, the initiator SHOULD
>    vary the destination address in retranmissions, in case the
>    address used in the first attempt is inoperational. Similarly,
>    if these addresses do not appear to respond, the initiator
>    MAY vary the source address it uses for itself, in case there
>    is a problem in a particular address prefix or the failure is
>    due to an ingress filtering problem.

That is also good section to be added. 
-- 
[email protected]