Re: about draft-ietf-mobike-protocol-01.txt (issue 40)

[email protected] wrote:

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

>>   > - 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.
>  
>
Yes. And I believe what we are doing matches
well with our charter, too.

--Jari