[Mobopts] RFC5742 review of draft-irtf-mobopts-mpa-framework

[Jari Arkko <[e-mail]>]

I have performed the review that RFC 5742 specifies for this document. 
My recommendation is that the IESG concludes the following:

1. The IESG has concluded that there is no conflict between this 
document and IETF work.

The document will be formally handled in the next IESG telechat.

I have also attached some personal comments below. None of them requires 
any action and addressing them is not necessary for your document to 
advance.

Jari

Personal comments:

In general, I found the document very interesting and useful IRTF 
publication. It is mostly very well written, accurate, and to the point. 
There were only a few observations, noted below:

> There are several ongoing activities in the IETF
> to define mobility management protocols at layers higher than network
> layer. HIP (the Host Identity Protocol) [RFC5201] defines a new
> protocol layer between network layer and transport layer to provide
> terminal mobility in a way that is transparent to both network layer
> and transport layer. Also, SIP-based mobility is an extension to SIP
> to maintain the mobility binding of a SIP user agent [SIPMM].

This creates an impression that SIPMM is an active IETF effort. I don't 
think that's the case.

> MPA is more applicable where an accurate prediction of movement can
> be easily made. For other environments, special care must be taken
> to deal with issues such as pre-authentication to multiple CTNs
> (Candidate Target Networks) and failed switching and switching back
> as described in [mpa-wireless]. However, addressing those issues in
> actual deployments may not be easier.

Somehow, parsing this text was hard for me. Shouldn't you say "... is 
most applicable ..." and "... addressing those issues in actual 
deployments may be hard."?

The "more applicable" phrase appears elsewhere in the document, too.

> The mobile node finds a CTN
> through some discovery process such as IEEE 802.21

A reference would be nice.

> iv) obtaining an IP address from a DHCP or PPP server, 

DHCP server or PPP peer

Also, I hope you take into account IPv6 SLAAC as well. There we do not 
"obtain an IP address", we get some information from the router which 
helps us configure an address by ourselves. (And I see that you talk 
about it later. Good.)

> IEEE 802.11u is
> considering issues such as discovering neighborhood using information
> contained in link layer. 
A reference would be nice.

> In some wide area networking environment, the mobile uses PPP

environments

> Upon receiving a PANA message from the mobile node, the
> DHCP relay agent performs normal DHCP message exchanges to obtain the
> IP address from the DHCP server in the CTN. This address is piggy-
> backed in a PANA message and is delivered to the client.

Perhaps you are just being sloppy with words here, but relay agents do 
not normally create any DHCP messages. I think it would be useful to 
either clarify that the messaging is actually coming from the client (if 
it is), or that a new DHCP role for a "proxy DHCP" would be needed here.

> In case of
> MIPv6 with stateless autoconfiguration, the router advertisement from
> the new target network is passed to the client as part of PANA
> message. The mobile uses this prefix and its MAC address to
>

I'm not sure why you are bundling MIPv6 and stateless autoconfiguration. 
Presumably stateless autoconfiguration could be used even in other 
cases, e.g., with a MOBIKE client could get its local address from SLAAC.

In general, the document doesn't talk about DHCPv6 at all. A standard in 
this space would obviously have to cover DHCPv4, DHCPv6, and SLAAC. It 
may be fine for a research document, though.

> 7.3.2. IKEv2-assisted proactive IP address acquisition

This section only talks about DHCP and IKEv2. A full-blown solution 
would probably have to address IPv6 and various different forms of 
address requests within IKEv2.

> In order to prevent malicious nodes from obtaining an IP address from
> the DHCP server, DHCP authentication should be used 

Which, of course, is pretty unrealistic. DHCP authentication has not 
been deployed at all AFAIK, and deploying a current form of DHCP 
authentication would be a very unscalable exercise.

> In addition to previous techniques, the MN may also want to ensure
> reachability of the new point of attachment before switching from the
> old one. This can be done by exchanging link-layer management frames
> with the new point of attachment. This reachability check should be
> performed as quickly as possible. In order to prevent packet loss
> during this reachability check, transmission of packets over the link
> between the MN and old point of attachment should be suspended by
> buffering the packets at both ends of the link during the
> reachability check. How to perform this buffering is out of scope of
> this document. Some of the results using this buffering scheme are
> explained in the accompanying implementation document.

In practice, it would also be important to test for Internet 
reachability, to avoid getting behind a web-login WLAN, for instance.

> During the process of pre-configuration, the MAC address resolution
> mappings needed by the mobile node to communicate with nodes in the
> target network after attaching to the target network can also be
> known, where the communicating nodes maybe the access router,
> authentication agent, configuration agent and correspondent node.
> There are several possible ways of performing such proactive MAC
> address resolution.
>
> o Use an information service mechanism [802.21] to resolve the MAC
> addresses of the nodes. This might require each node in the
> target network to be involved in the information service so that
> the server of the information service can construct the database
> for proactive MAC address resolution.
>
> ...
>
> o One can also make use of DNS to map the MAC address of the
> specific interface associated with a specific IP address of the
> network element in the target network. One may define a new DNS
> resource record (RR) to proactively resolve the MAC addresses of
> the nodes in the target network. But this approach may have its
> own limitations since a MAC address is a resource that is bound to
> an IP address, not directly to a domain name.

These two approaches strike to me as bad ideas. I'm mostly reacting to 
the apparent layer violations, but I'm also wondering why a new 
request-response tool (like the DNS) would be useful when we already 
have an existing request-response tool (ARP). It would seem that a 
change would only be useful if you were to able change the 
communications approach so that the mobile node doesn't need to wait at all.