Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4621

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

(Lisa Dusseault) Yes

Comment (2006-05-10)
No email
send info
This is a useful introductory document to MOBIKE.  If there is sufficient energy to expand on a couple things, then I hope these suggestions will be helpful in pinpointing what an introductory-level reader can get confused by :)

The acronym MN is never expanded, nor is NAT-T (neither are those expanded in RFC 4301 or 4306)
The acronym SPI is not expanded in this doc though it is in IKEv2.

I found the first mention of Notify as a negative comparison "... a more efficient format than the Notify payload is needed..." to be confusing, since before this Notify is not mentioned.

The return routability section is hard to understand.  Is it really about authorizing peer address changes or only about return routability checks? (I think the former so the title is misleading).  Some sentences are incomplete ("In this case A protection against an internal attacker, i.e. the authenticated peer forwarding its traffic to the new address, would not provided. ").  Some paragraphs ask questions and don't answer them.

(Russ Housley) Yes

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-05-11)
No email
send info
Observation from Erik Nordmark:

> FWIW draft-ietf-mobike-design-08.txt section 5.6 seems to imply that 
> MOBIKE can be extended to deal with transport mode. That claim was 
> removed from mobike-protocol (since the combination PAD and inner IP 
> address authorization doesn't exist for transport mode), so presumably 
> it makes sense to fix that text in mobike-design as well.

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Cullen Jennings) No Objection

Comment (2006-05-10)
No email
send info
First of all, I'm not sure if this is a WG document or not because the WG seems to be closed. I'm wondering how we will deal with the changes that may come up in review. Given the protocol document has already been approved, I think this is all "not critical" and don't care if any of the following items are addressed or if anyone ever sends me an email on any of them. I did try and read this carefully but it is a lot to grock and it may be that all the things I bring up below are answered in the document and I just missed it. 

The term address confuses me in the document - I am never sure if it means an ip address or the pair of ip address and port. For example, imagine I have a notebook computer in an enterprise that is behind a NAT and it has a wired and an 802.11 connection. The port will change but the IP address will not. Does all of this work in this case?

The discussion about return route-ability and uses of certificates with multiple IPs is interesting. However, in 5.5.3 I don't actually understand the approach taken. I don't understand how the random cookie works - is this something both sides know before the address change then use to validate the new address? Or is this something sent back and forth on the new address after than change? Why is the cookie needed given an ike transaction takes place? I don't understand why this would be made optional. The argument that we are no worse that NAT-T is, well, pretty sad given we could be better than that. I'm not claiming there is a problem in the final protocol here - I'm just not understanding what is probably one of the key parts of this document. Jari explained this to me  so I do get it now but I'm not sure someone reading the document would. 

I think this document needs a normative reference to NAT-T RFC 3947. I could not make sense of it without reading this.

In section 5.2.2 I think the term symmetric NAT is pretty vague and could be much more specifically described as "Address or Port Depended Filtering" as defined in the behave stuff.

A boxes and arrows style message flow of a transition from one address to another would have helped make this understandable.

In section 6.2, I'm concerned about if it is possible to get the full address list. Say I had a notebook computer with wired address 10.0.0.1 behind nat 1.1.1.1 and the notebook computer also had a wireless interface with address 192.168.0.2 behind nat 2.2.2.2. Clearly I have 4 addresses - however the far end is going to at frist think I have three, 10.0.0.1, 192.168.0.2, and 1.1.1.1. Then when switching to wireless, it will get updated to 10.0.0.1, 192.268.0.2 and 2.2.2.2. The 1.1.1.1 which is the current one in use gets dropped from the list. Is this right? Will this cause any harm? What does this list get used for?

The term "bombing" get introduced with no definition - I understand it but I don't know how common a term it is.

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Jari Arkko) Recuse