Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
draft-ietf-mip4-nemo-haaro-07

[Ballot comment]
Thank you for considering my DIscuss position regarding
the publication of this document as Experimental.

I've cleared based on the description of the experiment
and the conditions under which this document might be
re-published as a Standards Track document

[Ballot comment]
The Gen-ART Review by Roni Even on 29-Oct-2011 raises two editorial
  comments.  Please consider them.

  1. Typo in Section 3.1, first paragraph: “alredy”

  2. In Section 3.3.1: “only be when” change to “only when”; and
    “and and whose” delete one of the “and”.

[Ballot comment]
I didn't get all the way through this one, but I did notice the following:

Mention a random # and get a request to add a reference to RFC 4086 ;)  Please add one in s3.2.2.  Should probably also add a pointer in s3.2.1 because the keys generated need to be random too.

[Ballot comment]
Related to Russ' discuss (which I support):

IANA has unanswered questions (Authors - you received them directly and can also see them at the
line starting:
2011-10-31 06 Amanda Baber
IANA has several questions about draft-ietf-mip4-nemo-haaro-06.txt.

at

[Ballot comment]
I'm assuming that these questions just reflect my ignorance of nemo,
and since this is (currently) aimed at experimental, I'll not make them
a discuss. (If it were going for PS, I think these would be discuss-worthy.)

(1) I don't get how Kcr is setup as required in 3.2?  Is Kcr
supposed to be manually installed? Do all MR's need to have a
different Kcr for all other MRs or is Kcr shared between the MR and
HA?

(2) 3.2.1 says an MR MAY generate a new key at any time. How is that
distributed (securely)?

[Ballot comment]
I support Ralph's Discuss although I see that the reasoning is clear
from the charter. It should be simple to construct equivalent text to
go in the document.

---

I searched for a definition of "optimum" or "route optimizaton". I
found

  This document proposes a method to
  optimize routes between networks behind Mobile Routers, as defined by
  NEMO [RFC5177].

But RFC 5177 says;

  This document
  does not touch on aspects related to route optimization of this
  traffic.

Section 1 does include a number of statements that "route optimization
addresses this issue" for several issues. That is great, but I still
missed a succinct definition of "route optimization" and some
understanding of how I would recognize "optimum" if I saw it.

---

Section 3.2.2seems to have "should" and "may" that might benefit from
moving to RFC 2119 usage.

[Ballot discuss]
This seems to be the telechat for asking "why has this document been
submitted for publication as Experimental?"

draft-ietf-mip4-nemo-haaro-06 includes the following text, which
appears to be the only text referring to publication of the
specification as Experimental, at the end
of section 1:

  The specification in this document is meant to be experimental, with
  the primary design goal is to limit the load on the backend to
  minimum.

This text, in addition to containing a non sequitor, says nothing
about why the document is submitted for publication as Experimental,
what the experiment might be, how the experiment might be evaluated
and when the specification might be considered for publication as
Standards Track or moved to Historic status.

I have to say that I very much like the text at the end of the
Introduction of draft-ietf-pim-port, which explains why that
specification is Experimental - in this case, because it's doing some
new stuff that hasn't been tried before - how the results of
implementing the Experimental specification can be interpreted and
under what circumstances the specification should be considered for
Standards Track status.

So, to make this Discuss actionable, I'd like to hear from the mip4 WG
what aspects of this specification cause the request for Experimental
status, how the results of the experiment with implementation and
deployment should be reviewed and under what circumstance should this
specification be considered for publication on the Standards Track.

[Ballot comment]
The Gen-ART Review by Roni Even on 29-Oct-2011 raises two editorial
  comments.  Please consider them.

  1. Typo in Section 3.1, first paragraph: “alredy”

  2. In Section 3.3.1: “only be when” change to “only when”; and
    “and and whose” delete one of the “and”.

[Ballot discuss]
The Gen-ART Review by Roni Even on 29-Oct-2011 raises two concerns
  that deserve a response.

  1. The IANA Considerations section is not clear. It talks about three
    new tables but it was not clear to me which one they were and what
    is the extension policy for the tables.

  2. Section 4.2 talks about realm compression. Is it always used when
    using prefix compression or can you just do prefix compression if
    there is no benefit from using the realm compression?

IANA has several questions about draft-ietf-mip4-nemo-haaro-06.txt.

QUESTION: The second paragraph of the IANA Considerations section says,
"The rest of the new extensions are non-skippable, and grouped under two
new types as subtypes. Other type is for extensions in 'short' format
and other for single extension in 'long' extension format." Is this
referring to the "Mobile IP Message Types" and "Extensions to Mobile IP
Registration Messages" registrations requested in Tables 1 and 2, or
registrations that are being requested but not specified in the IANA
Considerations section?

QUESTION: The third paragraph says, "In addition, a new allocation
guideline for 'Correspondent Router reply codes' are needed." What is
this referring to? We can't find a Correspondent Router reply codes
registry in the document or on iana.org, the document doesn't seem to be
requesting one, and at any rate the document that creates the registry
is supposed to specify its registration procedure(s).

QUESTION: The document says, "Three new number spaces have been created
for the Values and Names for the Sub-Type for Route Optimization-related
Extensions. This number spaces are initially defined to hold the
following entries, allocated by this document:" and then provides a list
of registrations. Are we supposed to create three different registries
with the same entries? Or does this table include three different
registries in it?

QUESTIONS: What are the registration procedures for the "Route
Optimization-related Extensions" registry in Table 3, if it is one
registry? Is that the correct name? What are the maximum values? Is
value 0 or any other range of values reserved? What are the headings for
the registry? Would "Type," "Subtype," "Description," and "Reference" be
appropriate?

QUESTION: Do the "rejection" registration reply codes belong in the
range for "Registration denied by the foreign agent," "Registration
denied by the home agent," or "Registration denied by the gateway
foreign agent"?

ACTION 1:

Upon approval of this document, IANA will make the following
registrations in the "Mobile IP Message Types" registry at
http://www.iana.org/assignments/mobileip-numbers

TBD1 Home-Test Init message [RFC-to-be]
TBD2 Care-of-Test Init message [RFC-to-be]
TBD3 Home Test message [RFC-to-be]
TBD4 Care-of Test message [RFC-to-be]


ACTION 2:

Upon approval of this document, IANA will make the following
registrations in the "Extensions to Mobile IP Registration Messages"
registry at
http://www.iana.org/assignments/mobileip-numbers

TBD1 (range 1-127) Route Optimization Extensions [RFC-to-be]
TBD2 (range 1-127) Route Optimization data [RFC-to-be]
TBD3 (range 128-255) Mobile router Route optimization indication [RFC-to-be]


ACTION 3:

Upon approval of this document, IANA will create the following registry
at http://www.iana.org/assignments/mobileip-numbers

Registry Name: ??
Registration Procedures: ??
Reference: [RFC-to-be]

Type? Subtype? Description Reference
----- -------- ----------- ---------
1 1 Mobile router Route optimization capability [RFC-to-be]
2 1 Route optimization reply [RFC-to-be]
2 2 Mobile-Correspondent authentication extension
2 3 Care-of address Extension
3 1 Route optimization prefix advertisement6


ACTION 4:

Upon approval of this document, IANA will register the following Code
Values for Mobile IP Registration Reply Message at
http://www.iana.org/assignments/mobileip-numbers

TBD1 (range: ??) Expired Home nonce Index
TBD2 (range: ??) Expired Care-of nonce Index
TBD3 (range: ??) Expired nonces
TBD4 (range: 3-8) Concurrent registration, pre-accept

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Home Agent assisted Route Optimization between Mobile IPv4 Networks) to Experimental RFC


The IESG has received a request from the Mobility for IPv4 WG (mip4) to
consider the following document:
- 'Home Agent assisted Route Optimization between Mobile IPv4 Networks'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes a Home Agent assisted Route Optimization
  functionality to IPv4 Network Mobility Protocol.  The function is
  designed to facilitate optimal routing in cases where all nodes are
  connected to a single Home Agent, thus the use case is Route
  Optimization within single organization or similar entity.  The
  functionality adds the possibility to discover eligible peer nodes
  based on information received from Home Agent, Network Prefixes they
  represent, and how to establish a direct tunnel between such nodes.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mip4-nemo-haaro/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mip4-nemo-haaro/


No IPR declarations have been submitted directly on this I-D.

Continuing my review.

I think the document is in pretty good shape, but there were a few issues that I would like you to resolve before moving forward. The biggest issues are that I think you could do a better job in the introduction describing what kind of NAT scenarios this technology can work with, and adding a description of areas of uncertainty/problems that would be worthwhile to get more experience on (since the doc is going to be published as Experimental RFC).

> When a Mobile Router wishes to join its home link, it SHOULD, in
> addition to sending the registration request to the Home Agent with
> lifetime set to zero, also send such a request to all known
> Correspondent Routers.

I think it would be useful to clarify that you send the request to the home address, not care-of address of the CRs. Right? Otherwise they may have moved.

>    In the case of a handover, the Correspondent Router simply needs to
>    update the tunnel's destination to the Mobile Router's new Care-of
>    Address.  Mobile Router SHOULD keep accepting packets from both old
>    and new care-of Addresses for a short grace period, typically on the
>    order of ten seconds.  In the case of UDP encapsulation, the port
>    numbers SHOULD be reused if possible.
>

Its not as simple as that when NATs and firewalls are involved. If the MR is behind a NAT now, it needs to send a packet first. But will it send a packet to the care-of address or home address of the CR or both? If care-of address, the CR may just have moved. If home address, there will be no pinhole opened in the NAT.

RR may open the pinholes (but is it running on top of the same UDP ports as tunnels? I'm not sure.)

>      0              1              2              3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Type      |    Sub-type  |            Length            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      1..n times the following information structure
>

It was unclear to me what the relationship of "n" and "Length" are. Please clarify.

> In
>    the case of one or both of the routers is known to be behind NAT or
>    similarly impaired (not being able to accept incoming connections),
>    the tunnel establishment procedure SHOULD take this into account.

This is not an implementable requirement. What follows after this text is better, and that's the beef of what implementations must actually do. I would change the above text with s/SHOULD/need to/.

Since this specification is experimental, your Section 1 should describe the areas which are uncertain and which would benefit from experience with implementations and deployment. For instance, Section 7 lists scalability to a large number of prefixes as an area where further experience is needed.

Section 3.3 an 8.3 seem to disagree. The former says Krm is invalidated if care-of address changes, yet the 8.3 example does not appear to rerun RR (or the care-of address test part of RR).

Jari

I am reviewing this draft. So far I have progressed to the end of Section 3.3.3, and I have no major complaints. A couple of comments, however:

Section 1 should highlight that any route optimization between the MRs would only affect traffic between them. That is, traffic to somewhere else in the Internet in the multihoming case of figure 1 would still go through the virtual home agent operator, not directly.

Section 3.3.1 should highlight that if there is only one realm that can be communicated with one prefix, this may not be sufficient to communicate many real-world situations (such as one prefix mapping to multiple organizations, e.g., nomadiclab.com and ericsson.com)

The document should make it clear what types of NATs it can operate with. (And maybe it already does, in some part that I have not yet read :-)

>    If the check passes, the Correspondent Router MUST check whether the
>    Mobile Router already exists in its Route Optimization Cache and is
>    associated with the prefixes included in the request (Prefixes are
>    present and Flag HA is true for each prefix).
>

Can you make it clearer that checking whether an MR exists in the cache means checking whether an MR with the given care-of address exists in the cache? (If you didn't check the care-of address, any authorized router could claim any authorized prefix.)

Jari

This is a request for the IESG to consider publication of
draft-ietf-mip4-nemo-haaro-05 as an Experimental RFC.
Answers to the questionnaire are below.

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

The document shepherd is Pete McCann. Yes, I have reviewed
this version of the document and I believe it is ready for publication.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

Yes, and no.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

The document contains a novel compression scheme for realm names
that perhaps could have instead borrowed from existing practice in the
DNS protocol. However, the authors claim greater efficiency.
No IPR claims were filed against this draft.

> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

Consensus is solid.

> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See the Internet-Drafts Checklist
> and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?

Nits checker reveals 4 lines that are slightly too long, two slightly outdated
references. These can be fixed as part of the RFC editor process.

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

The document contains a split references section. None of the normative
references are downward. One informative reference is to a draft in progress.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?

The document has a properly labeled IANA considerations section
which requests several actions from IANA, including new Mobile IP
message types, reply codes, and extension codes. These are from
existing number spaces with well defined allocation policies. Three
new number spaces are allocated and the assignment policies are
currently unspecified; I would suggest Expert Review with specification
required.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

No such formal languages are used in the document.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
>
> Technical Summary

This document describes a Home Agent assisted Route Optimization
functionality to IPv4 Network Mobility Protocol. The function is
designed to facilitate optimal routing in cases where all nodes are
connected to a single Home Agent, thus the use case is Route
Optimization within single organization or similar entity. The
functionality adds the possibility to discover eligible peer nodes
based on information received from Home Agent, Network Prefixes they
represent, and how to establish a direct tunnel between such nodes.

> Working Group Summary

The draft has strong consensus within the working group.

> Document Quality

Document quality is good.