55 - scope and limitations (marcelo's issue)

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 the consensus has been that we don't want to go
too much in to the reasons of why something is the way
it is in this document (that's the job of the design document).
However, we do need to describe the limitations.

I'll first go through Marcelo's items from above and try
to explain what I think the situation is. At the end I'll
have suggested text for a new limitations section.

1) Are multiple address pairs allowed?

   Yes. Multiple pairs are allowed. Their simultaneous use for
   payload traffic is, however, outside the scope of the document,
   and would probably need extra mechanisms (e.g. ensure its different
   TCP streams) to work well.

2) Are unidirectional address pairs allowed?

   No. Explicit design decision to make things easy.

3) Multihoming for the establishment phase v.s only later?

   MOBIKE is for later phases only, but we can provide some
   guidance on what (limited) things can be done in the
   establishment phase.

3b) If MOBIKE retries in establishment phase, does it vary source address?

  It should. I'm a bit scared here to step on the area that your
  future enhanced RFC 3484 version will say, though. Technically,
  these are components; when 3484bis is available things sudddenly
  start working better.

  But I'll suggest something vague about this.

4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR

  This isn't an issue, really, but rather a misunderstanding of
  the text. There's no problem when the initiator (behind NAT) decides 
to use
  new addresses. The problem is when the responder moves; some
  NAT types don't allow this, and it may even be that the addresses
  provided for this emergency in ADDITIONAL_*_ADDRESS are
  internal, and not reachable by peer.

  I'd say no text changes.

5) Is simultaneous movement supported?

  No. Needs to be documented.

6) Are only local failures supported?

  No. MOBIKE, like SHIM6, supports both lower layers telling
  you that the link went away as well as experienced failures
  in IP communication (IKE DPD vs. SHIM6 reachability packets
  not getting through).

Ok. So here's an attempt at some new text for Section 1.1,
what used to be 3.4 Limitations:

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.

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.