IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4555

Note: This ballot was opened for revision 08 and is now closed.

(Russ Housley) (was Discuss, Yes) Yes

(Brian Carpenter) No Objection

Comment (2006-01-17 for -)
No email
send info
Comments from Gen-ART review by Elwyn Davies:

General: There is no discussion of how the Critical bit should be set in the various Notifications.

s1.1, para 1: IKEv2 doesn't just create SAs for use with tunnel mode.

s3.5: Might be good to say explicitly before this point that additional info is needed in the SA (presumably in the SAD) including pending_update flag and the additional addresses.

 'If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
  notification in response to its INFORMATIONAL request, it SHOULD
  retry the operation several times using new INFORMATIONAL requests.
  Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
  IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
  times, starting from a new IKE_SA_INIT request.'
Do we have any advice on the value of several here?

s3.12: Would it not be the case that the IPsec packets would fail validation against the SA database (i.e. the  SPI wouldn't match with the addresses and verification would fail)?  Or are there cases (null encryption/auth maybe) when more verification is needed? I wonder if this can be made more specific?

s1.1: Maybe should explain why only IKEv2 is considered.
s1.1, para 1: Need a reference for IKEv2 here (now RFC4306).

s2.1, para 5: s/common with the use/common to the use/

s2.2, title: ? s/Runs/Exchanges/

s2.2: This needs an explanation of the notation including a copy of the notation table from RFC4306 s1.2 and what is the meaning of N(...), plus the meaning of (IPx:4500 -> IPy:4500) etc.
s2.2: I don't think the meaning of the braces pair {} in the packet exchanges is defined.


s3.6, Next to last para: Might be good to add the reason why the additional addresses are not needed, i.e., the same one as in parentheses at the end of the next para.

(Margaret Cullen) (was Discuss, No Objection) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2006-01-19 for -)
No email
send info
Another capability for the Internet's multi-address architecture.
This took a lot of care, and in a few hours read of a one week
review, it looked sound.

Sometime we should do strong survey from the user/application
view. Are the multi-addressing capabilities coherent?  

And we should put applications/transports over these
varied capabilities in simulators and ensure we aren't missing

(Jon Peterson) No Objection

(Mark Townsley) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection