Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
draft-ietf-mipshop-4140bis-05

[Ballot discuss]
In general, I thought this was a good document.  However, there are
some problems that need to be remedied before publication.  Most of the
issues involve the Security Considerations section, but some changes
to the body might also be helfpul. (This is in part a follow-on to
Lakshminath Dondeti's secdir review and highlights the issues I consider
blocking.)

(1) The document introduces the Mobility Anchor Point (MAP) into the
mobile IPv6 architecture, but the requirements/assumptions regarding the
relationship between the mobile node and the MAP are not clear enough.
These assumptions/requirements have a number of implications for the
protocols that should be stated.  In particular, there is an implication
that the trust relationship is so limited that authentication as a group
member is generally sufficient.  For example, a MAP may authenticate a
mobile node based on a certificate issued by a known CA, rather than the
specific identity in the certificate. Similarly, the mobile node may
authenticate the MAP based on a cert from a known CA, even though the
specific MAP was previously unknown.  (Examples from 11.1)  I believe
this is okay, based on my understanding of the requirements, but I
would feel more confident if the trust relationship was fleshed
somewhere.

Note that this is confused somewhat by the discussion of "security
relationship" between the mobile node and the MAP in section 11.
"mutual authentication, integrity protection and protection against
replay attack" are necessary features, not a relationship.

(2) Authentication and authorization are conceptually related but
they are different.  Authentication is generally the precursor, where
we determine another party's identity, and authorization follows based
on that identitty.  Just because a party's identity has been
authenticated does not mean they are authorized to access anything.
The examples cited above blur the lines between these steps.  Hopefully,
this will be addressed as a side effect of addressing (1), but please
revise with an eye towards clarity on authentication vs. authorization.

(3) The security considerations section focuses on the expected
deployment architecture, but several alternatives are specified in the
document.  Tehse should be addressed in teh security considerations
as well - either to describe differences in teh security considerations
or to state that they are unchanged.

For example, It is noted in the introduction that the mobile node can operate in
a nomadic manner (no permanent home address).  Section 6.5 notes that
the RCoA address can be used as the source address without a Home Address
option.  In these kinds of cases, are there additional constraints or
limitations imposed on the trust relationship between the MAP
and the mobile node?

[Ballot discuss]
In general, I thought this was a good document.  However, there are
some problems that need to be remedied before publication.  Most of the
issues involve the Security Considerations section, but some changes
to the body might also be helfpul. (This is in part a follow-on to
Lakshminath Dondeti's secdir review and highlights the issues I consider
blocking.)

(1) The document introduces the Mobility Anchor Point (MAP) into the
mobile IPv6 architecture, but the requirements/assumptions regarding the
relationship between the mobile node and the MAP are not clear enough.
These assumptions/requirements have a number of implications for the
protocols that should be stated.  In particular, there is an implication
that the trust relationship is so limited that authentication as a group
member is generally sufficient.  For example, a MAP may authenticate a
mobile node based on a certificate issued by a known CA, rather than the
specific identity in the certificate. Similarly, the mobile node may
authenticate the MAP based on a cert from a known CA, even though the specific MAP was previously unknown.  (Examples from 11.1)  I believe
this is okay, based on my understanding of the requirements, but I
would feel more confident if the trust relationship was fleshed
somewhere.

Note that this is confused somewhat by the discussion of "security
relationship" between the mobile node and the MAP in section 11.
"mutual authentication, integrity protection and protection against
replay attack" are necessary features, not a relationship.

(2) Authentication and authorization are conceptually related but
they are different.  Authentication is generally the precursor, where
we determine another party's identity, and authorization follows based
on that identitty.  Just because a party's identity has been
authenticated does not mean they are authorized to access anything.
The examples cited above blur the lines between these steps.  Hopefully,
this will be addressed as a side effect of addressing (1), but please
revise with an eye towards clarity on authentication vs. authorization.

(3) The security considerations section focuses on the expected
deployment architecture, but several alternatives are specified in the
document.  Tehse should be addressed in teh security considerations
as well - either to describe differences in teh security considerations
or to state that they are unchanged.

For example, It is noted in the introduction that the mobile node can operate in
a nomadic manner (no permanent home address).  Section 6.5 notes that
the RCoA address can be used as the source address without a Home Address
option.  In these kinds of cases, are there additional constraints or
limitations imposed on the trust relationship between the MAP
and the mobile node?

[Ballot discuss]
In general, I thought this was a good document.  However, there are
some problems that need to be remedied before publication.  Most of the
issues involve the Security Considerations section, but some changes
to the body might also be helfpul. (This is in part a follow-on to
Lakshminath Dondeti's secdir review and highlights the issues I consider
blocking.)

(1) The document introduces the Mobility Anchor Point (MAP) into the
mobile IPv6 architecture, but the requirements/assumptions regarding the
relationship between the mobile node and the MAP are not clear enough.
These assumptions/requirements have a number of implications for the
protocols that should be stated.  In particular, there is an implication
that the trust relationship is so limited that authentication as a group
member is generally sufficient.  For example, a MAP may authenticate a
mobile node based on a certificate issued by a known CA, rather than the
specific identity in the certificate. Similarly, the mobile node may
authenticate the MAP based on a cert from a known CA, even though the specific MAP was previously unknown.  (Examples from 11.1)  I believe this is okay, based on my understanding of the requirements, but I
would feel more confident if the trust relationship was fleshed
somewhere.

Note that this is confused somewhat by the discussion of "security
relationship" between the mobile node and the MAP in section 11.
"mutual authentication, integrity protection and protection against
replay attack" are necessary features, not a relationship.

(2) Authentication and authorization are conceptually related but
they are different.  Authentication is generally the precursor, where
we determine another party's identity, and authorization follows based
on that identitty.  Just because a party's identity has been
authenticated does not mean they are authorized to access anything.
The examples cited above blur the lines between these steps.  Hopefully,
this will be addressed as a side effect of addressing (1), but please
revise with an eye towards clarity on authentication vs. authorization.

(3) The security considerations section focuses on the expected
deployment architecture, but several alternatives are specified in the
document.  Tehse should be addressed in teh security considerations
as well - either to describe differences in teh security considerations
or to state that they are unchanged.

For example, It is noted in the introduction that the mobile node can operate in
a nomadic manner (no permanent home address).  Section 6.5 notes that
the RCoA address can be used as the source address without a Home Address
option.  In these kinds of cases, are there additional constraints or
limitations imposed on the trust relationship between the MAP
and the mobile node?

[Ballot discuss]
Section 11 needs a better description of how IPsec works in this
context, including description of required SPD and PAD entries.  It
also seems that the current text proposes rather creative on-the-fly
modifications to PAD; probably these could be replaced by the dynamic
home address configuration mechanisms described in RFC 4877.

Section 7.1 says "If the R flag is set, the mobile node MUST use its
RCoA as the Home Address when performing the MAP registration.  RCoA
is then bound to the LCoA in the MAP's Binding Cache." I had some
difficulties in understanding this paragraph; some rephrasing or
additional text would clarify it.

Topics noted in Lakshminath Dondeti's SecDir review:

The draft should describe what assumptions it's making about the
network between MN and AR, or AR and MAP; without these, it's hard to
say whether, e.g., the recommendations that BUs don't need
confidentiality, or protecting payload traffic is optional, are in
fact correct.

The draft doesn't have any mandatory-to-implement security mechanisms
(even IKEv2 is given just as an example), which means there's no
interoperability.

There's no INVALID-ID-INFORMATION notification in IKEv2.

[Ballot discuss]
The introduction describes that without the mipshop optimization, MNs have on average 1.5 signaling round-trips when the node moves... Then makes a fairly wild leap of conclusion that:

  These round trip delays will
  disrupt active connections every time a handoff to a new AR is
  performed.  Eliminating this additional delay element from the time-
  critical handover period will significantly improve the performance
  of Mobile IPv6.

What connections are being disrupted for each and every AR? Also, I see no analysis here that shows that there will be a significant performance improvement to the Mobile IPv6 user.

There is language in this document stating the optional nature of this feature, but if the above claims are true then I cannot see how this could be optional. So, the document is rather inconsistent here.

I think that probably the right thing to do is to tone down some of the claims of what this optimization does and does not do.

[Ballot discuss]
Section 11 says:
  >
  > Confidentiality may be needed for payload traffic, but is not
  > required for binding updates to the MAP.
  >
  Under what circumstances is confidentiality desired?  When it is
  desired, is ESP used to provide it?

[Ballot discuss]
The tunneling between the MAP and the mobile node introduces an extra layer of tunneling that may effect (will unless the path between the MN and the MAP has a MTU that is at least tunnel overhead larger than the real MTU bottelnek) the path MTU between the CN and the MN. There needs to be some discussion of this impact on the traffic between the CN and the MN. Especially as this is dynamic and can change due to the choices of the MN or changing the used MAP.

[Ballot discuss]
In section 7.1 there is a mention of options (e.g. preference) that are associated with MAP IP addrs  but, there is a very limited encoding (e.g. no flags, or other attributes) in the MAP option. In addition, the definition of a Dist is limited to 4 bits. Is that enough? Is it reasonable to assume that no semantics are to be associated with distance?

Later, in the selection algorithm for distributed MAPs (9.1) it appears that DIST and PREF are directly comparable. Although DIST is used as a sorting (akin to hop count although earlier not required), the pref is then used to bias selection. The problem with no strict semantics for DIST to be hop count (e.g. it could be used as inverse hop count) then you'd get a non-optimal selection algorithm. In addition, the PREF variable alone only allows for a very weak application of operational policy (since all this has to be hand configured - no dynamic specified). Given what we know about policy selection requirements from other protocols, something should be mentioned what the RESV space is for or allow at this time greater operational options (via more attrs, flags, etc).

Bottomline, the definition of the options (DIST, PREF) appear to not have strict enough semantics to meet the requirements of the default selection algorithm.


Next, the section on failure detection and recovery from MAP failures is unfortunately not useful because it describes possible failure detection methods but, nothing to be standardized. Either something has to be specified, referenced or the section has to be removed as an implementor has nothing to specified to detect failures.

[Ballot comment]
Section 14., paragraph 0:
> 14.  References

  Document contains a six or so unused references, suggest to remove
  them.


Section 14.2., paragraph 3:
> [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
>            July 2005.

  I think this should cite draft-ietf-mipshop-fmipv6-rfc4068bis.

[Ballot discuss]
> Appendix A.  Appendix A - Fast Mobile IPv6 Handoers and HMIPv6

  DISCUSS: Has the experiment with RFC4140 covered Fast Hierarchical
  MIPv6 at all? There are zero technical changes between this appendix
  in RFC4140 and this document, and with the text below referring to
  SEAMOBY as if it was still around, I wonder if this appendix isn't
  outdated and should simply be removed for PS.


Appendix B., paragraph 5:
> RFC 4140 was implemented and interop tested by at least two different
> organisations.  A test suite including test cases for RFC 4140 was
> also developed by Ericsson and run against both implementations.  No
> major issues were found.  The scalability of Dynamic MAP discovery
> defined in RFC 4140 was seen as inappripriate for large scale
> deployments and prone to loops.  It was removed from this
> specification.

  DISCUSS-DISCUSS: This rationale for going from Experimental to PS is
  weak. OK, so two implementations interoperated, some minor things were
  removed, but the open question is whether the protocol actually works
  as advertised and is useful?

[Ballot discuss]
> Appendix A.  Appendix A - Fast Mobile IPv6 Handoers and HMIPv6

  DISCUSS: Has the experiment with RFC4140 covered Fast Hierarchical
  MIPv6 at all? There are zero technical changes between this appendix
  in RFC4140 and this document, and with the text below referring to
  SEAMOBY as if it was still around, I wonder if this appendix isn't
  outdated and should simply be removed for PS.


Appendix B., paragraph 5:
> RFC 4140 was implemented and interop tested by at least two different
> organisations.  A test suite including test cases for RFC 4140 was
> also developed by Ericsson and run against both implementations.  No
> major issues were found.  The scalability of Dynamic MAP discovery
> defined in RFC 4140 was seen as inappripriate for large scale
> deployments and prone to loops.  It was removed from this
> specification.

  DISCUSS-DISCUSS: This rationale for going from Experimental to PS is
  weak. OK, so two implementations interoperated, some minor things were
  removed, but the open question is whether the protocol actually works
  as advertised and is useful?

New AD review:

Part 1::

Before I forget: please ensure that changes that were introduced to RFC 4140 by the RFC Editor are also in the 4140bis. Sometimes authors start from their old source and miss this. See the diff URL below; I have not looked at if the changes in the current draft or not. Please check them before submitting a new version.

http://www.arkko.com/ietf/mipshop/rfc4140-from-draft-ietf-mipshop-hmipv6-04.diff.html

Part 2::

1) The history has to be there, i.e., what changed from 4140. Also, you need to include a paragraph or two about what kind of "experiment" has been going on with 4140. I.e., have people used it, implemented it, whether there was any testing, etc. You don't need to invent any fancy results, simply state what has or has not been done.

2) Typo: 1.  eceive and parse all MAP options.

3) This still needs a change:
  OLD:
  Note that a mobile node may send a BU containing its LCoA (instead of
  its RCoA) to correspondent nodes, which are connected to its same
  link.  Packets will then be routed directly without going through the
  MAP.
  NEW:
  Note that a mobile node may send a BU containing its LCoA (instead of
  its RCoA) to correspondent nodes. If these nodes are connected to the same
  link, packets will then be routed directly without going through the
  MAP.

4) Delete this because its inconsistent with later text that actually defines an
    distance-based algorithm:

  This specification does not provide an algorithm
  for the distance-based MAP selection.  However, such an algorithm may
  be introduced in future extensions utilising information about the
  speed of mobility from lower layers.

5) Typo: KEv2 allows the

I'm expecting a revised ID. The above changes should be easy to do, when can we see the new revision?

I have made my AD review of this document. Please find detailed comments below.

Overall, I was pleasantly surprised by this specification. It is in relatively good shape and while there are issues, there are generally minor and mostly solvable by removing the offending parts. I was happy with the security parts. The main issues that I have are the flooding scheme and the error recovery parts.

I expect some discussion and a new draft revision. After that we can go to IETF Last Call.

Technical:

>    This specification allows a mobile node to use more than one RCoA if
>    it received more than one MAP option.  In this case, the mobile node
>    MUST perform the binding update procedure for each RCoA.

This MUST seems overly strong. Why would the mobile node be forced to use more than one MAP, if it only wanted to use one? See also further below where some inconsistencies with the above have been detected.

>    Note that a mobile node may send a BU containing its LCoA (instead of
>    its RCoA) to correspondent nodes, which are connected to its same
>    link.  Packets will then be routed directly without going through the
>    MAP.
How does this happen? If two nodes sit on the same link and employ MAP(s) and home agent(s), they will only see each other's RCoAs and/or HoAs. They would see each other's care-of addresses when route optimization is attempted. But per your specification above you may not attempt it with your local address unless you already know the other node is on the same link. Chicken and egg...

Suggestion: do not restrict the type of address the nodes may use in route optimization.

>    Upon reception of a router advertisement with the MAP option, the
>    receiving router MUST copy the option and re-send it after
>    incrementing the Distance field by one. 
I hope you do not mean re-sending every RA again on another interface, triggered by the reception. This would disturb the router's own timing and processing of RAs. Please clarify the text to indicate that the received RAs are only used for learning the information, and then the information is used in the router's own independent RA sending process.

>    The MAP option is propagated towards ARs in its domain.
I'm not convinced that the dynamic distribution of MAP information is useful. First of all, its a very small configuration task compared to some of the other things you would have to have in this environment (e.g., security policies and key material allowing each mobile node to talk to each MAP securely).

Secondly, you seem to be assuming that the MAP is placed in the router hierarchy. I would actually expect that a local domain's MAP would be placed in the same network as other servers and services exists, not necessarily in the aggregated router hierarchy that leads to the Internet. This would imply that a MAP RA would have to be distributed not just "down" but also "sideways" or even "up" if you draw the router placement in the network in a hierarchical manner. Of course, you can configure the routers to do this. But at the end of the day, you've created a complicated flooding scheme to achieve very little. And there may be error modes that we have not thought of.

I would suggest removing the support for dynamic distribution, and simply requiring ARs to be configured with this information.

>    A mobile node MUST store the received option(s) in order to choose at
>    least one MAP to register with.  Storing the options is essential, as
>    they will be compared to other options received later for the purpose
>    of the movement detection algorithm.

The "at least one" part is right, in my opinion. But it is inconsistent with what I quoted earlier: "MUST perform the binding update procedure for each RCoA"

>    If no MAP options are found in the router advertisement, the mobile
>    node MUST use the Mobile IPv6 protocol, as specified in [1].

Hmm. I think MUST NOT use HMIP would be more appropriate within the specification of how to deal with MAP options. You are assuming that whoever implements your spec will also implement and be able to use Mobile IPv6 (including, for instance, having a home agent).

> 10. Detection and Recovery from MAP Failures

Paragraph 1 is good, but the rest seems suspect.  For instance, on a large domain having every AR send this many pings to the MAP would by itself create a problem. And I am not sure this document should be dictating a specific mechanisms where service provider infrastructure keeps aware of what's up and what's not. I would suggest removing everything else except the ability of mobile nodes to react to zero lifetime. Or perhaps even that could be removed, if you simply recommended that if routers become aware of inability to reach the MAP, the MAP option is deleted from RAs.

Editorial:

Please correct the issues from
  http://tools.ietf.org/wg/mipshop/draft-ietf-mipshop-4140bis/draft-ietf-mipshop-4140bis-01.nits.txt

>    It is pertinent to note that the use of the MAP does not reply or
>    assume that a permanent Home Agent is present.

s/reply/rely/

>    The mobile node can communicate with a correspondent node through the
>    HA, or in a route-optimised manner, as described in [1].  When
>    communicating through the HA, the message formats in [1] can be re-
>    used.
s/can be re-used/are used/

> This specification does not provide an algorithm
>    for the distance-based MAP selection.  However, such an algorithm may
>    be introduced in future extensions utilising information about the
>    speed of mobility from lower layers.
>
>    ... The following algorithm is simply based on selecting the
>    MAP that is most distant, provided that its preference value did not
>    reach a value of zero.  The mobile node operation is shown below:
>
>    1.  Receive and parse all MAP options
An apparent inconsistency. Do you provide a distance-based algorithm or not? Note that there might be different algorithms, better/perfect, etc., but that was not what the text was claiming.

>    This is achieved by using the RCoA as the identity in IKE Phase 2
>    negotiation.  This step is identical to the use of the home address
>    in IKE phase 2.
I think you mean child SA creation, not phase 2. Phase 2 was an IKEv1 concept. I see that Vijay noted this as well in his review.

PROTO Write-up

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

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it 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?

This document has been adequately reviewed.

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

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

There is WG consensus in advancing this document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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
http://www.ietf.org/ID-Checklist.html 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? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Idnits found a few minor issues. There was boiler plate issues
related to the IPR statement and the validity of internet drafts.
However, the relevant sections are there in the document. There
were a couple of references defined, but not referenced anywhere
in the document. The intended status "Proposed Standard" is
missing in the document. The document also needs to say that it
obsoletes RFC 4140. These will be fixed in the next revision.

(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 splits the references into normative and Informative
references. There are no downward references.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations 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 [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The document makes no request from IANA.

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

Does not apply.

(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 introduces extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling. Hierarchical
mobility management for Mobile IPv6 is designed to reduce the amount
of signalling between the Mobile Node, its Correspondent Nodes, and
its Home Agent. The Mobility Anchor Point (MAP) described in this
document can also be used to improve the performance of Mobile IPv6
in terms of handover speed.

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

No.

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?

There are at least two implementations of HMIPv6. Nothing is known
about vendor plans. This document revises RFC 4140, which was an
Informational document.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko/Mark Townsley