Working out the details of SA updates

Hi everyone,

I've put together a new draft about a possible MOBIKE protocol.  
This is not a revision of the SMOBIKE draft, but takes a rather 
different approach, more resembling Francis's and Tero's drafts.
A temporary copy of the draft (which will be removed when the 
draft appears on ietf.org) is available from:

http://www.vpnc.org/ietf-mobike/TEMP-draft-eronen-mobike-mopo-00.txt

The main "beef" of this draft is actually working out the details 
of how updating the various Security Associations could work.

In particular, supporting window size 1 properly was somewhat
tricky (and I'm not sure I got all the details right yet).
The basic problem was that if you don't update any addresses
before RR succeeds, and you can't send the message verifying RR 
before there is room in the window, and existing requests cannot
get out of the window before you update something, you have a 
deadlock.

Another complicated issue was that some situations require
simultaneous update of both parties' addresses. For instance,
if your own address changes, you also have to pick the right 
destination address for the address update message. (And this
is not the same problem that is usually handled by normal IP 
source address selection.)

This draft also makes "IP address integrity protection" (or 
"NAT prevention") an orthogonal feature, so it can protect 
the addresses also when the SA is created (and can be optional
if NAT support is needed).

Comments are most welcome! (I'm mostly out of office 
during the next three weeks, so I won't read my emails
very often. But see you in San Diego!)

Best regards,
Pasi