RE: Protocol Drafts - What's different.

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