Subject: [Mobike] 55 - scope and limitations (marcelo's issue)

From: Jari Arkko <[email-masked]>
Date: Sun, 23 Oct 2005 18:51:40 +0300

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.

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2005 11:15:07 +0300

> 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). 

>    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.

>    due to an ingress filtering problem.

That is also good section to be added. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 24 Oct 2005 11:33:46 +0300

Tero Kivinen wrote:

>Perhaps add pointer to the design draft also 
>  
>
Yes.

--Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 25 Oct 2005 17:09:35 +0200

Hi Jari,

i think that the proposed text looks good.

just a couple of clarifications, not really expecting to change the 
text, but just to explain some points...

>  in IP communication (IKE DPD vs. SHIM6 reachability packets

my point here is that the only tool that seems to be available to 
mobike is to change the address used for the communication.
This is clearly enough to address local failures but it is not clear 
that this is good enough to deal with other failure modes.
In shim, changing the source address is assumed to result in exploring 
different exit paths (from the multihomed site)
this is the case when the source address affects somehow the exit path, 
which is coherent with the existance of some form of ingress filtering 
capability in the multihomed site.
So, either you  assume some form of source address dependent routing so 
that changing the source address result in different exit paths or the 
host don't really have the capability of forcing the exit path, so it 
is probably that it won't be able to cope with remote failures in 
general (in particular in failures in the egress paths)

> what used to be 3.4 Limitations:

this text looks good

>   MAY vary the source address it uses for itself, in case there

i would suggest a SHOULD here

regards, marcelo