Subject: RE: [Mobike] Protocol Drafts - What's different.

From: <[email-masked]>
Date: Wed, 28 Jul 2004 18:58:06 +0300

James Kempf wrote:
> 
> I read through the protocol drafts and I can't see much 
> difference in the technical content. Would the authors like 
> to articulate what the differences are?

I hope this kind of stuff will be included in protocol
presentations at San Diego. But here's a short list
of some differences (which is sort of biased, and probably 
contains several errors due to my misunderstanding of 
various protocol details).

Window size requirements
  
   mopo-ike, smobike: Work with window size 1, even if something 
   else, such as an information exchange for dead peer detection 
   or rekeying a child SA was going on when mobility occured.

   addrmgmt: Probably does not work with window size 1, since 
   return routability is verified using a separate informational 
   exchange before updating SAs.

   mobike-protocol: Seems to work with window size 1, since the
   informational exchange to verify return routability is done 
   after the SAs have been updated.

NAT behavior

   mopo-ike: Works in many situations: moving behind NAT enables 
   NAT traversal (UDP encapsulation, automatic address updates 
   and keepalives) and moving back to clear disables them.

   smobike: Works in many sitations, but differently. Moving 
   behind NAT enables UDP encapsulation and keepalives; moving 
   back disables them. Automatic address updates are always used.

   mobike-protocol, addrmgmt: Do not work with NATs.

When A changes its address, and B has several addresses:
  
   addrmgmt: Seems to assume that B's address stays the same?

   mopo-ike: Provides a way to find out which of B's addresses 
   work with the new address of A.

   mobike-protocol, smobike: Seem to assume that A already knows 
   which of B's addresses is the right one to use?
  
If there is no response to an IKE request, and both parties have
several addresses (so it is not clear which end is having problems):

   mopo-ike: Provides a way for the parties to locate the problem.

   addrmgmt, smobike: Seem to assume the information is obtained 
   in some other, unspecified way?

   mobike-protocol: There is some support for testing addresses,
   but it cannot always locate the problem without additional
   information obtained in some unspecified way?

Scope of address updates:

   mopo-ike/smobike/mobike-protocol: All child SAs are updated 
   at the same time. 

   addrmgmt: Updating individual child SAs is possible.

(In some cases, it is not totally clear to me what the situation
is, since the drafts are not very detailed --- but that's quite 
understandable, since most of them are -00 versions.)

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Jul 2004 10:51:38 +0200

In your previous mail you wrote:

   Window size requirements
     
=> if you speak about the IKE message window, there are two windows,
one for each way (i.e., one for each peer as the initiator of
the exchange). Without two windows simultaneous exchanges could
give deadlocks and/or spurious retransmissions.

=> the optional RR check uses the other way...

   NAT behavior

=> and nothing will be done to change this if the WG still believes
interoperability with NATs is not useful.

   
=> the answer is simple: B is supposed to manage its addresses.
Note that the addrmgmt provides a way for A to change the B address too
but it is not the standard way.

   
=> yes, this is supposed to be done by the generic mobility/multi-homing/etc
control mechanism.

   
=> IMHO this is the main difference: the idea is to manage all the IPsec
SAs between two multi-homed peers using different peer addresses from
one IKE SA.

Regards

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 29 Jul 2004 09:45:59 -0700

> interoperability with NATs is not useful.

Is that really what the WG believes? Given that the base IKEv2 protocol
includes NAT support, it seems a little strange to exclude it in MOBIKE.
(Please, no comments about the immorality of NATs. Living in America, I have
to suffer enough of that kind of stuff from the current USG.).

> SAs between two multi-homed peers using different peer addresses from

Actually, I like this. It might be very useful for multihoming. The only
issue is if updating individual child SAs is always necessary, or if they
can be updated en masse.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jul 2004 20:37:58 +0300

> to suffer enough of that kind of stuff from the current USG.).

Francis said "_if_ the WG still believes".

Anyway, I think our meeting in Seoul plus discussions on
the list seem to say that people *do* care about NATs.

But the issue may be more about what we can do than what we
want to do. I'm not sure we fully understand the interaction
between mobike and nat-t yet. Or at least I do not personally
feel that understand it well enough. I hope that Tero and
Francis can talk about this in the meeting.

--Jari

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 29 Jul 2004 12:24:21 -0700

>the list seem to say that people *do* care about NATs.

Agree.

>between mobike and nat-t yet.

Agree.

>  Or at least I do not personally

That would be great.

--Paul Hoffman, Director
--VPN Consortium