Subject: RE: [Mobike] about draft-ietf-mobike-protocol-01.txt (issue 40)

From: <[email-masked]>
Date: Thu, 8 Sep 2005 16:02:36 +0300

Francis Dupont wrote:

>    > - motivation 2nd paragraph: the "another example" is a very
>    > limited view of what multihoming support needs. I'd like to
>    > see the mobike protocol supporting simultaneous multiple peer
>    > addresses.  (I use the term "peer address" from pki4ipsec
>    > documents because it could not confused with addresses in
>    > traffic selectors).
>    
>    Since the first version of MOBIKE only deals with the outer
>    (tunnel header) addresses, using multiple addresses for an IPsec
>    SA simultaneously would probably mean either load balancing
>    (explicitly ruled out in the WG charter) or sending copies of a
>    single ESP packet over several paths (nobody has expressed any
>    interest in this so far).
>    
>    But this is probably not what you meant... ?
>    
> => no, I mean simultaneous multiple peer addresses for different
> IPsec SAs, something I've called the SCTP model for multihoming
> (note it is not only for SCTP, it was just accurately described
> in SCTP documents).

The current protocol already supports this functionality. There 
are several different ways how this functionality could be 
implemented in the protocol, and in issue 8 there was rough
consensus to choose one of them (if you want different addresses 
for different IPsec SAs, you can do so by creating IKE_SAs).

<snip>

>    > - the link between 2.2 and 2.3 is not explained because the
>    > new addresses are taken from the IP header. BTW I am afraid
>    > the main scenario is the only supported scenario as a
>    > consequence...
>    
>    Could you give a concrete example of a scenario that can't be
>    done currently?
>    
> => multihoming.

I do not agree. We just chose to implement multihoming support 
in a slightly different way than SCTP did.

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Sep 2005 16:16:05 +0300

>for different IPsec SAs, you can do so by creating IKE_SAs).
Right. But what I'm missing still is a statement somewhere
in the document that says we can have multiple IKE SAs
in parallel and that if there's MOBIKE-related changes
then those changes apply only to the IKE SA on which
those changes were communicated. This may be obvious,
but I think its good to write it down anyway.

>in a slightly different way than SCTP did.
Yes. And I believe what we are doing matches
well with our charter, too.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:23:34 +0200

=> so MOBIKE handles multihoming the same way than TCP when
we expect according to the WG charter more something like SCTP.

   
=> what is the real difference between MOBIKE multihoming support
and IKEv2 multihoming support, and, more important, is this difference
enough?

Regards

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Sep 2005 17:34:02 +0200

=> yes, if we'd like to kill multihoming it is better to dig a grave (:-).

   
=> I strongly object: only a part of the charter matches, and I am not
talking about the NAT traversal stuff which does match but a forbidden
part.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Mon, 12 Sep 2005 16:55:51 +0300

>and IKEv2 multihoming support, and, more important, is this difference
My understanding of this difference is that in our current
proposal, the peers can register their alternative addresses
and failover to the other addresses if there's a connectivity
problem in the currently used address. (I don't think you
can do this in basic IKEv2, and personally, I think its a good
tradeoff in terms of functionality vs. effort and configuration.)
This is what I call the "failover" multihoming model.

In the SCTP multihoming model we can choose more independently
where to send data, even if there's still the concept of a
primary (default) path.

In the load balancing multihoming model we can send even
the same stream over multiple paths, and still perform appropriate
load balancing, congestion avoidance, and acknowledgement
tasks.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Sep 2005 16:57:42 +0200

=> fine definition. My concern is the SCTP model and SCTP itself
is in the charter, so according to its own charter the WG doesn't
provide *yet* a good enough support to multihoming...

Regards

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 19 Sep 2005 21:30:52 -0700

>    where to send data, even if there's still the concept of a
AFAIK (things may have changed recently in SCTP), you try a new
path only if the primary path fails. But in SCTP, each side can take
the decision independently unlike what we have in MOBIKE today.
But the main reason we did it this way in MOBIKE is to make it
work with NATs.  Also, In MOBIKE, all the IPsec SAs get
updated at the same time. There is no such thing in SCTP - each
side has its own notion of what address set they can use. 
Is there any other difference ?

> provide *yet* a good enough support to multihoming...
I think we should be very careful about keeping the protocol simple.
When the charter was written, i don't think we understood all the details.
So, i don't think we should blindly follow the charter. 

-mohan

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Sep 2005 10:24:09 +0200

=> if the charter is bad we should fix it. BTW IMHO the load balancing
definition is not enough accurate:

    Load balancing. Multihoming is supported only in the sense of
    failing over to another interface; sending traffic over multiple
    addresses using the same SA is not supported.
   
There is a place between the failover (first part) and the load balancing
itself (second part). In the "host-based multihoming" used for IPv6,
one could play with source and destination addresses to get traffic
engineering / QoS mapping. This is stronger than the failover style
but this is not load balancing because one flow uses only one path
at one time. To neglect this multihoming style IMHO is to go against
the direction the Internet currently follows...

Regards