Subject: [Mip4] Request to advance draft-ietf-mip4-rfc3344bis-09.txt to Proposed Standard

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 22 Feb 2010 13:44:26 -0500

>   (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 believe the document
is ready for forwarding to the IESG 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. 

No concerns or issues.  Well-known IPR exists on the Nonce option
that was described way back in RFC 2002 (IBM Patent #5,148,479).
The WG decided to publish that document anyway.  More recently,
IPR disclosures from Cisco and Nortel have arisen:

https://datatracker.ietf.org/ipr/709/
https://datatracker.ietf.org/ipr/850/

There has been little discussion of these two disclosures in the
WG, although the current consensus seems to be to publish anyway.

>   (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?   

The WG as a whole has been working with this document for quite some
time, and the improvements in this draft we well understood.

>   (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 appeals have been threatened.
 
>   (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? 

The document contains 2 minor boilerplate nits that I do not believe
are blocking.

>   (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]. 

References are split.  All Normative References are of adequate
maturity.

>   (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 requests allocation of only one new number from an
existing Mobile IPv4 registry.  This is called out explicitly
in the IANA considerations.  All other number spaces and assignments
were made previously by RFC 3344.

>   (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.

>   (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 
>         Relevant content can frequently be found in the abstract 
>         and/or introduction of the document. If not, this may be 
>         an indication that there are deficiencies in the abstract 
>         or introduction. 

This document is a revision of RFC3344, and makes changes in the
following areas:

* A new error reply code was added for the case when a Foreign
  Agent detects an invalid Home Agent address in a Registration Request.

* Language was changed to allow more than one authorization enabling
  extensions in a Registration Request (RFC3344 says "Exactly one").

* Clarified that the Foreign-Home Authentication Extension MUST NOT
  apply to de-registration messages.

* Added language to clarify that security associations can be
established
  dynamically.

* Added language to clarify that Authentication Extensions may be
  checked by an entity other than a Mobility Agent, such as a AAA
server.

* Clarified that the Care-of address offered by the Foreign Agent
  must also be the Source IP address of a relayed Registration Request.

* Clarified that the Foreign Agent MUST use the NAI extension to
distinguish
  among multiple overlapping Home Addresses from different Mobile Nodes.

* Clarified processing by the Home Agent when it receives a Registration
  Request with an invalid authentication extension.

>      Working Group Summary 
>         Was there anything in WG process that is worth noting? For 
>         example, was there controversy about particular points or 
>         were there decisions where the consensus was particularly 
>         rough? 

We had some contentious issues but I think the discussions and
subsequent resolutions have satisfied all parties.

>      Document Quality 
>         Are there existing implementations of the protocol? Have a 
>         significant number of vendors indicated their plan to 
>         implement the specification? Are there any reviewers that 
>         merit special mention as having done a thorough review, 
>         e.g., one that resulted in important changes or a 
>         conclusion that the document had no substantive issues? If 
>         there was a MIB Doctor, Media Type or other expert review, 
>         what was its course (briefly)? In the case of a Media Type 
>         review, on what date was the request posted? 

Mobile IPv4 is widely implemented and deployed, especially in
cdma2000 networks.  This update was influenced heavily by these
deployments, especially the allowed inclusion of multiple authorization-
enabling extensions that allow Mobile IP to be deployed with a AAA
back-end.

-Pete

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Feb 2010 10:13:53 +0200

I have reviewed this draft (or to be more exact, the changes with 
respect to RFC 3344). I have only the following comments:

The issue tracker URL in Appendix G is out of date.

Section G.2 should have a more descriptive name (e.g., "Changes from RFC 
2002 to RFC 3344").

Is Section G.4 really needed? What's the difference to G.1?

I understand the change with respect to not mandating FA-HA 
authentication on de-registration messages. But I do not understand the 
rationale, and I cannot find the relevant discussion from the mailing 
list or the issue tracker. Can someone shed light on why this change was 
necessary, and what its security implications are? Depending on the 
answer there may also be a need to add some of this information to the 
draft.

I am waiting for an answer to the last issue before starting the IETF 
Last Call. Otherwise the draft looks fine.

Jari

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 25 Feb 2010 11:25:44 -0500

Hi, Jari,

We had a lengthy discussion on this topic back in 2005.  One of
the e-mails summarizing the issues is here:

http://www.ietf.org/mail-archive/web/mip4/current/msg01264.html

There is some good discussion in the follow up messages.

The basic problem is that for a de-registration, the CoA is not
necessarily owned by the FA through which the MN is de-registering.
If an HA is indexing the FA-HA SA by the CoA in the message (as was 
proposed by 3519) then the registration would fail authentication
and the MN would still be registered (and possibly billed) even
though it didn't want the old registration and had a perfectly 
valid MN-HA SA.  So, we decided to deprecate the FA-HA AE for
de-registrations.  This meant adding text so that the FA wouldn't
add it, and adding text so that the HA wouldn't require it (and
wouldn't bother checking it if it was included by a legacy FA).

3519 tried to mandate that the HA should look up the SA based on
the CoA because a NAT box might modify the Source IP address.  I
think the outcome of our discussion was that this was actually
a mistake.  We will eventually need to do a 3519bis.

-Pete

Jari Arkko wrote:
> Section G.2 should have a more descriptive name (e.g., "Changes from
> RFC 2002 to RFC 3344").
> 
> authentication on de-registration messages. But I do not understand
> the rationale, and I cannot find the relevant discussion from the
> mailing list or the issue tracker. Can someone shed light on why this
> change was necessary, and what its security implications are?
> Depending on the answer there may also be a need to add some of this
> information to the draft.      
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 25 Feb 2010 11:35:21 -0800

Hello folks,

Perhaps more text is needed in the draft so that future
readers are not faced with the same problem that Jari
had with the existing text.

Let me know if another revision is needed.  Even better,
please send text that you think explains the situation
properly :-)

Regards,
Charlie P.

On 2/25/2010 8:25 AM, McCann Peter-A001034 wrote:
> --
> Mip4 mailing list: [email-masked]
>      Web interface: https://www.ietf.org/mailman/listinfo/mip4
>       Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Feb 2010 23:58:01 +0200

I am happy with this explanation. I have started IETF Last Call, but I
would really appreciate if a short paragraph about the below rationale
ended up somewhere in the draft in the next couple of days, for the
benefit of other reviewers. Please fix the other minor issues at the
same time. Thanks,

Jari

McCann Peter-A001034 kirjoitti:

Hi, Jari,

-Pete

Jari Arkko wrote:

Jari