Received changes through RFC Editor sync (changed abstract to 'This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.

This document is a product of the IP Mobility Optimizations (MOBOPTS) Research Group. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot comment]
I strongly suggest that the following comments are addressed
before publication:

In section 7.3.1, a DHCP relay agent does not have the capability to
operate independently and perform a DHCP message exchange with a DHCP
server in anticipation of an eventual DHCP message exchange initiated
by a client.  The mecahnism described in this section would require
the definition of a new DHCP proxy function.

In the case of IPv6, it's probably required to forward the RA to the
mobile node regardless of the address assignment model, to
pre-configure the mobile node with all the requisite information about
prefixes, etc.

In section 7.3.3, there is a conflict with the DHCPv6 specification,
which requires that a DHCPv6 client send any messages to the DHCPv6
servers/relays multicast address, rather than unicast to a server.

There may also be a problem with all of these methods using DHCP: how
does the CTN DHCP server know what address to assign to the client?

Other comments:

Perhaps a nit, but I was somewhat mislead by the title, " A Framework
of Media-Independent Pre-Authentication (MPA) for Inter-domain
Handover Optimization" to believe that I was going to read about a
protocol that focused on authentication and secure communication.  In
my opinion, this document describes a complete framework for
media-independent inter-domain handover optimization that goes beyond
authentication and security.

In Appendix A, wouldn't DAD be performed by the NAR rather than the
PAR?

From the Intro:

  In this document
  we discuss a framework to support terminal mobility that provides
  seamless handovers with low latency and low loss.

Are there other components to terminal mobility aside from MPA?

Section 1.2:

  A trade-off between one-way-delay and
  packet loss is desired based on the type of application.

Unclear to me - a trade-off should be available through tuning or
one-way-delay should be improved relative to packet loss?

Section 3: Define "inter-subnet handover"?

Section 6.1:

  MPA provides three basic procedures to provide this functionality.
  The first procedure is referred to as "pre-authentication", the
  second procedure is referred to as "pre-configuration", the
  combination of the third and fourth procedures are referred to as
  "secure proactive handover".

"three basic procedures" and "third and fourth procedures" is
confusing; where did that fourth procedure come from?

Section 6.1:

  Especially, the third procedure described above (i.e., binding update
  procedure)

Change "third procedure described above" to "step (iii) in the
previous paragraph" to avoid confusion with the use of "procedures in
the earlier paragraph in section 6.1.

Section 6.2:

  The authentication
  protocol MUST be able to derive a key between the mobile node and the
  authentication agent and SHOULD be able to provide mutual
  authentication.

Is "derive a key between ..." a term of art or can the requirement be
described more accurately as "establish a shared key between..."?

  The authentication protocol SHOULD be able to
  interact with a AAA protocol such as RADIUS and Diameter to carry
  authentication credentials to an appropriate authentication server in
  the AAA infrastructure.

Does the authentication protocol interact directly with the AAA
protocol, or does the interaction happen through the AA?

[Ballot comment]
From the Intro:

  In this document
  we discuss a framework to support terminal mobility that provides
  seamless handovers with low latency and low loss.

Are there other components to terminal mobility aside from MPA?

Section 1.2:

  A trade-off between one-way-delay and
  packet loss is desired based on the type of application.

Unclear to me - a trade-off should be available through tuning or
one-way-delay should be improved relative to packet loss?

Section 3: Define "inter-subnet handover"?

Section 6.1:

  MPA provides three basic procedures to provide this functionality.
  The first procedure is referred to as "pre-authentication", the
  second procedure is referred to as "pre-configuration", the
  combination of the third and fourth procedures are referred to as
  "secure proactive handover".

"three basic procedures" and "third and fourth procedures" is
confusing; where did that fourth procedure come from?

Section 6.1:

  Especially, the third procedure described above (i.e., binding update
  procedure)

Change "third procedure described above" to "step (iii) in the
previous paragraph" to avoid confusion with the use of "procedures in
the earlier paragraph in section 6.1.

Section 6.2:

  The authentication
  protocol MUST be able to derive a key between the mobile node and the
  authentication agent and SHOULD be able to provide mutual
  authentication.

Is "derive a key between ..." a term of art or can the requirement be
described more accurately as "establish a shared key between..."?

  The authentication protocol SHOULD be able to
  interact with a AAA protocol such as RADIUS and Diameter to carry
  authentication credentials to an appropriate authentication server in
  the AAA infrastructure.

Does the authentication protocol interact directly with the AAA
protocol, or does the interaction happen through the AA?

[Ballot discuss]
Perhaps a nit, but I was somewhat mislead by the title, " A Framework
of Media-Independent Pre-Authentication (MPA) for Inter-domain
Handover Optimization" to believe that I was going to read about a
protocol that focused on authentication and secure communication.  In
my opinion, this document describes a complete framework for
media-independent inter-domain handover optimization that goes beyond
authentication and security.

In section 7.3.1, a DHCP relay agent does not have the capability to
operate independently and perform a DHCP message exchange with a DHCP
server in anticipation of an eventual DHCP message exchange initiated
by a client.  The mecahnism described in this section would require
the definition of a new DHCP proxy function.

In the case of IPv6, it's probably required to forward the RA to the
mobile node regardless of the address assignment model, to
pre-configure the mobile node with all the requisite information about
prefixes, etc.

In section 7.3.3, there is a conflict with the DHCPv6 specification,
which requires that a DHCPv6 client send any messages to the DHCPv6
servers/relays multicast address, rather than unicast to a server.

There may also be a problem with all of these methods using DHCP: how
does the CTN DHCP server know what address to assign to the client?

In Appendix A, wouldn't DAD be performed by the NAR rather than the
PAR?

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.

This is a request for the IESG to perform a RFC5742 review of draft-irtf-mobopts-mpa-framework-08.txt [1] to be published an an Informational IRTF RFC. The document has been approved for publication by the IRSG. See [2] for details on prior reviews. Please copy all correspondence to the document shepherd, Rajeev Koodli <rkoodli@cisco.com>.

--aaron
IRTF Chair

[1] http://www.ietf.org/id/draft-irtf-mobopts-mpa-framework-08.txt
[2] http://trac.tools.ietf.org/group/irtf/trac/ticket/27