Re: 55 - scope and limitations (marcelo's issue)

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

El 23/10/2005, a las 17:51, Jari Arkko escribió:

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

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)

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

this text looks good

> 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

i would suggest a SHOULD here

regards, marcelo


>   is a problem in a particular address prefix or the failure is
>   due to an ingress filtering problem.
>