Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6)
draft-ietf-mip6-whyauthdataoption-07

[Ballot comment]
First of all, I should say that after working on the DSMIPv6
document, I'm rather sympathetic to arguments that perhaps using
IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and
the authentication option can be valuable in some deployments.

However, much of the text in Sections 2/3/4 is written in way that
makes it difficult to distinguish when it's describing the history
(why RFC 4285 was originally done, before IKEv2 and RFC 4877 existed),
and when it's describing why it's still a good idea today. It seems
the energy needed to rewrite this text doesn't exist, however, and
I'm grudgingly changing this from discuss to comment.

Also, somewhat surprisingly for a document defending RFC 4285, the
document also doesn't mention what's IMHO the *main* advantage of RFC
4285 over IPsec: implementation complexity. Especially with new MIPv6
features like DSMIPv6, the interface between IPsec stack and MIPv6
stack is getting complex, and the IPsec stack needs more
MIPv6-specific functionality (so you can't necessarily use just any
off-the-shelf IPsec stack). However, it seems not everyone agrees
about this topic, so perhaps it can be omitted, too.

I'd be happier if the text discussing overhead of IPsec/IKE reminded
folks that IKE overhead is usually one time (e.g. once a day), not
something that happens when doing handover -- currently it does
give an impression that IPsec/IKE is a bandwidth hog, which isn't
really that accurate.

[Ballot discuss]
(updated discuss for version -07)

First of all, I should say that after working on the DSMIPv6
document, I'm rather sympathetic to arguments that perhaps using
IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and
the authentication option can be valuable in some deployments.

However, much of the text in Sections 2/3/4 is written in way that
was true when RFC 4285 was done, but isn't true anymore. Just
adding "BTW, IKEv2 and RFC 4877 means the previous text is now
incorrect" doesn't really make it good -- the incorrect text is still
written in present/future tense, giving advice for the future. Changing
it to past tense would perhaps make it clearer when it's just describing
the history behind RFC 4285.

Somewhat surprisingly for a document defending RFC 4285, the document
also doesn't mention what's IMHO the *main* advantage of RFC 4285
over IPsec: implementation complexity. Especially with new MIPv6
features like DSMIPv6, the interface between IPsec stack and MIPv6
stack is getting complex, and the IPsec stack needs more MIPv6-specific
functionality (so you can't necessarily use just any off-the-shelf IPsec
stack).

Minor clarifications/nits:
- Sections 4/5: text discussing overhead of IPsec/IKE should remind
that IKE overhead is usually one time (e.g. once a day), not something
that happens when doing handover.

Jari's interpretation is that the authors have implemented the bare minimum required in Pasi's Discuss. Not very happy with the document even now, but perhaps it should be approved and we should move to more constructive efforts.

[Ballot discuss]
[I've updated my discuss after receiving Vidya's SecDir review,
and talking with other ADs on the telechat]

First of all, I should say that after working on the DSMIPv6
document, I'm rather sympathetic to arguments that perhaps using
IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and
the authentication option can be valuable in some deployments.

Nevertheless, I think the document's discussion of pros and cons of
authentication option and IPsec is a bit too 3GPP2-centric, and
implicitly assumes some functionality of 3GPP2 networks that may
or may not be present in other networks.

To make the document more useful for a reader trying to understand the
pros and cons of authentication in other environments than 3GPP2, IMHO
it would be useful to make these assumptions more explicit.  Here's an
attempt (proposing text for Section 7) to clarify what I mean:

3. In 3GPP2 networks, link-layer security mechanisms, ingress
  filtering at the PDSN, and various network domain security
  mechanisms largely ensure that reverse tunneled packets received by
  the HA don't have spoofed source addresses, and their contents have
  not been modified.  This means the HA can determine which MN sent
  the packet simply by verifying the outer source IP address matches
  the currently registered care-of address. Authentication of
  payload packets can be necessary for e.g.

  - Authenticating other signalling messages than BU/BAck between
    the MN and HA, such as ICMPv6, MLD, and DHCPv6.
  - Enforcing access control to the network behind the HA.
  - Accounting or other flow-specific processing performed by the HA.

  This means the authentication option is of limited applicability in
  environments where the HA can received reverse tunneled packets
  with spoofed source IP addresses and/or modified contents.

4. As described in RFC 4285, the authentication option assumes that
  the MN-AAA shared key and security association (SA) are created by
  out-of-band mechanisms.  These mechanisms are specific to
  particular deployment environments. IKEv2, on the other hand,
  supports a wide range of authentication mechanisms, such as
  certificates and EAP methods, and is independent of the access
  network technology being used.  However, it would be possible to
  specify a similar authentication and key management protocol for
  the authentication option in the future.

5. RFC 4285 does not specify a mechanism for creating the MN-HA
  shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4
  mechanisms defined in [RFC3957]), and thus rely on deployment
  specific mechanisms not standardized in IETF.

6. Sending the long-term user identity (NAI) in clear raises privacy
  concerns. These concerns are addressed by access network and network
  domain security mechanisms in 3GPP2 networks, but do limit the
  applicability in networks where sniffing other users' traffic
  is possible.

7. The authentication option does not support negotiation of
  cryptographic algorithms.

8. The replay protection mechanisms in RFC 4285 rely on timestamps,
  and thus requires reasonably synchronized clocks (by default, +/-
  7 seconds). This assumes the MN implements, and is configured to
  use, some mechanism for synchronizing its clock.

Any thoughts on these, and/or proposals on how to better write this
text?

(Note that these concerns are largely addressed by other mechanisms
than IPsec in 3GPP2 networks, so the conclusions of the document
stay valid.)

Another concern is that much of the text in Sections 2/3/4 is written
in way that was true when RFC 4285 was done, but isn't true anymore.
Just adding "BTW, IKEv2 and RFC 4877 means the previous text is now
incorrect" doesn't really make it good -- the incorrect text is still
written in present/future tense, giving advice for the future. Changing
it to past tense would perhaps make it clearer when it's just describing
the history behind RFC 4285.

Somewhat surprisingly for a document defending RFC 4285, the document
also doesn't mention what's IMHO the *main* advantage of RFC 4285
over IPsec: implementation complexity. Especially with new MIPv6
features like DSMIPv6, the interface between IPsec stack and MIPv6
stack is getting complex, and the IPsec stack needs more MIPv6-specific
functionality (so you can't necessarily use just any off-the-shelf IPsec
stack).

Minor clarifications/nits:
- Sections 4/5: text discussing overhead of IPsec/IKE should remind
that IKE overhead is usually one time (e.g. once a day), not something
that happens when doing handover.
- Section 5.1 says "The same backend subscriber profile database,
security keys etc. are intended to be used for both Mobile IPv4 and,
Mobile IPv6" -- it should also note that re-using same key with
multiple algorithms/protocols is usually a bad idea.
- Section 6: It would be useful to have some pointers here (to 3GPP2
specs where the details of these procedures are specified).
- Section 10: The sentence "Mobile IPv6 has been standardized only
recently" was accurate when version -00 of this draft was published in
2005, but it isn't that recent now.

[Ballot discuss]
The document claims that IPsec is not integrated with the AAA
  architecture.  Wasn't this the whole point in adding support for
  EAP to IKEv2?  If the authors disagee, then the document needs to
  do a better job explaining this situation.  If the authors agree,
  then this document needs to be updated to reflect this agreement.

[Ballot comment]
I understand (more or less) the history of this document, and its goals, but I wish this
document had evolved into a more even treatment of the applicability of RFC 4285 and
RFC 4877.  The document reads more as a defense of 3gpp than was necessary imho.
Documenting the process more generically, then using 3gpp as an example would have
made the document easier for future system architects to apply the information
when architecting their own solutions.

Addressing this comment directly would require major surgery that is probably
innapropriate at this stage of the document lifecycle, but I think implementing Pasi's
proposals or something similar would certainly be helpful.

[Ballot discuss]
First of all, I should say that after working on the DSMIPv6
document, I'm rather sympathetic to arguments that perhaps using
IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and
the authentication option can be valuable in some deployments.

Nevertheless, I think the document's discussion of pros and cons of
authentication option and IPsec is a bit too 3GPP2-centric, and
implicitly assumes some functionality of 3GPP2 networks that may
or may not be present in other networks.

To make the document more useful for a reader trying to understand the
pros and cons of authentication in other environments than 3GPP2, IMHO
it would be useful to make these assumptions more explicit.  Here's an
attempt (proposing text for Section 7) to clarify what I mean:

3. In 3GPP2 networks, link-layer security mechanisms, ingress
  filtering at the PDSN, and various network domain security
  mechanisms largely ensure that reverse tunneled packets received by
  the HA don't have spoofed source addresses, and their contents have
  not been modified.  This means the HA can determine which MN sent
  the packet simply by verifying the outer source IP address matches
  the currently registered care-of address. Authentication of
  payload packets can be necessary for e.g.

  - Authenticating other signalling messages than BU/BAck between
    the MN and HA, such as ICMPv6, MLD, and DHCPv6.
  - Enforcing access control to the network behind the HA.
  - Accounting or other flow-specific processing performed by the HA.

  This means the authentication option is of limited applicability in
  environments where the HA can received reverse tunneled packets
  with spoofed source IP addresses and/or modified contents.

4. As described in RFC 4285, the authentication option assumes that
  the MN-AAA shared key and security association are created by
  out-of-band mechanisms.  These mechanisms are specific to
  particular deployment environments. IKEv2, on the other hand,
  supports a wide range of authentication mechanisms, such as
  certificates and EAP methods, and is independent of the access
  network technology being used.  However, it would be possible to
  specify a similar authentication and key management protocol for
  the authentication option in the future.

5. Sending the long-term user identity (NAI) in clear raises privacy
  concerns. These concerns are addressed by access network and network
  domain security mechanisms in 3GPP2 networks, but do limit the
  applicability in networks where sniffing other users' traffic
  is possible.

Any thoughts on these, and/or proposals on how to better write this
text?

(Note that these concerns are largely addressed by other mechanisms
than IPsec in 3GPP2 networks, so the conclusions of the document
stay valid.)


Minor clarifications/nits:
- Section 6: It would be useful to have some pointers here (to 3GPP2
specs where the details of these procedures are specified).
- Section 10: The sentence "Mobile IPv6 has been standardized only
recently" was accurate when version -00 of this draft was published in
2005, but it isn't that recent now.

I have re-reviewed this document, after a new version appeared to address my earlier AD review comments.

Another revision will be needed. The new version is much better than the previous one, but some issues still remain. I would also recommend doing an additional editorial pass on the document.

Technical:

> Other networks which have similar deployment
>    requirements are IEEE 802.16e based Mobile WiMAX networks and
>    potentially 3GPP based HSPA (High speed Packet access) type of
>    networks.
The 3GPP2 case that you explained before had a use for this. Do we have official specs from the other two (Wimax and 3GPP) that actually use the authentication option? If not, I would suggest deleting the above text.

Also, if the situation in 3GPP2 has changed afterwards, stating this would also be beneficial.

> This is in contrast with the currently specified
>      Mobile IPv6 model which requires an IPsec SA between the MN and
>      HA.  At the time of this writing the IKEV2 based solution for
>      establishing an IPsec SA [RFC4877] was not available.  IKEv2 does
>      enable integration with a a AAA backend.

s/is in contrast with the currently specified/was in contrast with an earlier version of the/

>    Hence, with the MIP6 specifications and architecture that relies on
>    IPsec as the sole means for securing the signaling between the MN and
>    HA, it is not possible to accomplish a deployment that mirrors that
>    of MIP4 for cdma deployments.
This seems false, given IKEv2's integration to AAA. Delete or rewrite as "Before the publication RFC NNNN that allows integration of IKEv2 and AAA with Mobile IPv6 home registrations, ..."

>    The use of IPsec for performing Registration with a home agent is not
>    always an optimal solution.  While it is true that IPsec is an
>    integral part of the IPv6 stack, it is still a considerable overhead
>    from a deployment perspective of using IPsec as the security
>    mechanism for the signaling messages between the MN and HA.  This
>    statement is a result of experience gained from deployment of Mobile
>    IPv4.  MIP4 does not rely on IPsec for securing the Registration
>    signaling messages.
This really says very little. Every new protocol bit in Mobile IPv6 is going to be extra overhead if we start employing the above argument. Delete paragraph.

> IKE does not integrate very well with the Radius
does not work at all with the Radius

(at least if we talk about standardized protocols)

> As a result the use of IKE for
>    Mobile IPv6 deployment is detrimental to the operators bottom line.

I do not think this statement is of proper style for an RFC. The previous text in the same paragraph should be sufficient to make the point. In any case, you are making a value judgment that says very little about the actual size of the impact (when you have to do this etc).

> 6. Solution Proposal

The title and first paragraphs of this section should be changed. The section should indicate how 3GPP2 is actually using Mobile IPv6 rather than suggesting any new solutions. Indeed, RFC 4285 already exists so its not clear that we need anything new.

Suggested new text is:

6. Application of Mobile IP in CDMA Networks

  Sections 6.1 and 6.2 describe the IPv4 based mobility architecture in cdma networks and IPv6 based
  mobility architecture in cdma Net- works respectively.

6.1. ...

> Some of them are:
>
>    1.  Route optimization is not supported.  Since route optimization
>        signaling messages between the MN and HA are secured by IPsec ESP
>        an equivalent solution will have to be specfied or the deployment
>        will have to rely on link-layer security mechanisms.
>    2.  Bootstrapping of the MN home address is possible when using
>        IKEv2.  DHCPv6 or other mechanisms will have to be relied on in
>        the absence of IKEv2 with IPsec for MIP6 signaling.
Several problems with this. "Some" is not what I was looking for -- I'd like to see the set of known issues, not some subset thereof.

Point 1 is incorrect. It should rephrased as route optimization having to rely on link layer security mechanisms, or having to be turned off if no such mechanisms exist. I believe route optimization is completely OK in networks such as CDMA from the security perspective, because all of these networks do have link layer security.

Point 2 does not seem to be a problem in RFC 4285 itself. As the document has stated previously, many of these things can now be done with bootstrapping and IKEv2 schemes. Suggest removing this.

You are missing security problems with RFC 4285 that Section 6 start hinted at. Talk about that here. Please be specific.

> Howver route optimization is not supported
>    in the current specification of the authentication protocol in
>    [RFC4285].

See above.

> It should be noted that the key length
>    proposed in RFC 4285 was 16 octets in length.  This was considered as
>    being weak.  The issue is being corrected by increasing the key
>    length to 20 octets at a minimum in Authentication Protocol for
>    Mobile IPv6 [I-D.ietf-mip6-rfc4285bis].
This does not belong in the conclusion section. It belongs either in the limitations or security considerations section.

> 10. Conclusions

I find it odd that the conclusions only argue for RFC 4285, but make no mention of recommending new deployments to consider bootstrapping and IKEv2 mechanisms developed in the WG.

Editorial:

>    In summary the model of Mobile IPv6 deployment which mandated the

the original model

> The only con- sideration is that the alternative
>    solution should not be vulner- able to attacks that are otherwise
>    prevented by the use of IPsec.

extra dashes

> minmize
Typo

> of using IPsec
to use IPsec

> Operators may consider the number of messages between the MN and
>        HA that are required to establish the IPsec SA as too many.

Reads funny

> However at the time of discussion on the need for the
>    authentication protocol, the specification for using Mobile IPv6
>    Operation with IKEv2 and the revised IPsec Architecture [RFC4877] was
>    still work in progress at the time of this writing and as a result an
>    alternative solution needed.
s/at the time of this writing and as a result an alternative solution needed//

s/discussion/discussion (2003?)/

> IKEV2
IKEv2


> with out
without

> Howver route optimization is not supported
>    in the current specification of the authentication protocol in
>    [RFC4285].
However

>    Mobile IPv6 has been standardized only recently. 
This statement shows the age of the text.... its not so recently any more. Remove this.

AD review results:

I have reviewed this draft. Before I get to the results of my
review, let me state that I support publishing the rationale
for RFC 4285 and that I believe that RFC was necessary back
then for Mobile IPv6 (and may still be).

But unfortunately, this document has significant problems and
requires a fairly major rewrite, at least as far as Sections 4,
5 and 7 go. I liked Section 6. Fortunately, given the size
of the document and the relative simplicity of the topic,
I do not expect the rewrite to take a lot of time. But you have
to have a new approach to writing this document.

The first problem is that there a number of statements
in the document of the form "X is not supported in
Mobile IPv6" which are untrue. This may be in part
because of the desire to report the historical thinking.
This is a valid goal for the document, but at the same
time we are not publishing an RFC in 2007 that
makes incorrect statements. I would recommend
structuring these statements and perhaps even
the whole document more along the lines of
"At the time RFC 4285 was designed, X was not
supported. This has later changed when feature
Y was defined, and this is no longer a problem /
the remaining issues are ..."

I do not want to turn this document into a
description what to do instead of RFC 4285, but
it is currently too silent on how to use the
existing components (such as IKEv2 or EAP) to
achieve similar results.

There are a number of arguments in the document
that do not appear to have implications for the
selection of the authentication mechanism, some
that are weak, and as noted above, some that
are no longer true. I believe there are good
reasons, and I would suggest sticking to those
rather than try to argue the case with a large
number of arguments.

The document is almost completely silent on
the possible limitations and downsides of
the authentication option. You must mention
the downsides as well, be it lack of
encryption support for RO, the introduction
of additional modes which may affect
interoperability, etc. Again, being honest
about the arguments and limitations
not only helps people understand this
technology better, but will also aid you
in getting your document approved.

Details below:

Substantial:

>    1.  Networks in which the access authentication is separate from the
>        authentication of the mobile node to the home agent.  There
>        exists a security association between the mobile node and some
>        backend authentication server (eg.  AAA Home server) which is
>        used for access authentication.
>    2.  Networks in which the establishment of the security association
>        between the mobile node and the authentication server (AAA Home)
>        is established using an out-of-band mechanism and not by any key
>        exchange protocol.  Such networks will also rely on out-of-band
>        mechanisms to renew the security association (between MN and AAA
>        Home) when needed.
>    3.  Networks in which the home agent and home address needs to be
>        assigned on a dynamic basis.
>    4.  Networks which are bandwidth constrained (such as cellular
>        wireless networks) and there exists a need to minimize the number
>        of signaling messages sent over such interfaces.
This is not a very good list to differentiate the situations
where the auth option is needed. For some of the points
it is not clear why they imply anything for the selection
of the authentication mechanism. For instance, if item
1 condition about separate access / mobility auth
would not hold, there wouldn't be a Mobile IPv6
authentication mechanism at all. Item 2 appears to
merely a scoping question, i.e., whether we want to
talk about the keying or not. In some of the
other points, all currently defined Mobile IPv6
mechanisms are capable of satisfying the requirement,
e.g., 3 or 4. But maybe not both at the same time.

The list should be reformulated. E.g, something
along the following lines.

1. Authentication credentials already exist for some other
    purpose in a AAA server for the node.
2. Dynamic assignment of home agents is used and at the
    same time it is desired to avoid negotiating new IPsec
    SAs on every assignment.
3. Mobile nodes only move within networks that
    have sufficient link-layer encryption support
    to prevent problems with revealing RO-related
    signaling.

(But this isn't all that satisfactory either, presumably
dynamic HA assignment occurs rather infrequently,
not on every movement.)

> It can be argued that IKEv2 does provide the capability to be
>      integrated with a AAA backend.  However IKEv2 is not an option
>      that can be considered because of the deployment timelines of
>      operators relying on 3GPP2 standards.
This should be rewritten to make it clearer what the situation
was back in RFC 4285 timeframe vs. now.

>    o  The current Mobile IPv6 specification does not support the dynamic
>      assignment of home agent and home address.  Although there is on-
>      going work in the MIP6 WG to address this, the work is not yet
>      ready.
The latter limitation (home address) is untrue, see RFC 4877.

For the former limitation (home agent assignment), it is true
that the WG is still working on this. However, it is unclear why
this has anything to do with the selection of authentication
method. It seems that an operator or L2 SDO can define
their network access mechanisms so that proper home
agent address can be delivered to the mobile node. This needs
to be done anyway (RFC 4285 or something else), and from
that point onwards it does not matter what the authentication
mechanism does, as long as it is capable of authenticating
to a dynamically changing home agent.

> The identity of a user in MIP4-based cdma2000 networks is an MN
>      Identifier Option for MIP6 [RFC4283].  Mobile IPv6 as per RFC3775
>      specifies the IPv6 home address as the identity of the mobile
>      node.  Morever, the home address cannot be dynamically assigned in
>      such cases.
Again, untrue at the time of writing this, given RFC 4877.
NAIs are a perfectly fine identification option for both
IKEv2 and EAP (if run within IKEv2).

>    Consequently, MIP6 as specified today does not satisfy necessary
>    requirements.

Back then -- yes. Now, its still a question mark for me. Please
make the distinction between the back-then and now in the
document.

Regarding the situation now, at the very least your list
of issues has been significantly shortened. Whether
there are items left depends a little bit on details that
I'm not fully aware of. For instance, an existing deployment
may use just MIP4 based AAA messaging that cannot
work with IKEv2's EAP-based AAA messaging. Or some
deployments might be; its these kinds of arguments that
are more substantial than the ones that I see above.

Suggest rewriting the list in Section 5.1 based on the
above comments.

>  There is no practical mechanism to
>  use IPsec directly with the AAA infrastructure with out the use of
>  IKE or some other mechanism that enables the establishment of the
>  IPsec SA between the MN and HA.
Again, untrue at the this is being written.


> Establishing an IPsec SA between the
>    MN and HA using AAA infrastrucure is not specified for Mobile IPv6
>    today.  RFC3776 explains how IKE is used for establishing the SA
>    between the MN and HA.  And even in this case, the MN has a
>    designated home address.
See above.

> 6. Solution Proposal

This section was very good.

> 7. Security Considerations
>
>
>    The security requirements for the signaling messages between the MN
>    and HA when using the authentication option mechanism are the same as
>    those when using IPsec to secure them.

This is not true, e.g., lack of ESP support means you have to
rely on link layer encryption to protect route optimization
packets.

>    It should be noted that the key length
>    proposed in RFC 4285 was 16 octets in length.  This was considered as
>    being weak.  The issue is being corrected by increasing the key
>    length to 20 octets in Authentication Protocol for Mobile IPv6
>    [I-D.ietf-mip6-rfc4285bis].

My recollection was that the issue was not so much the number
of bits and their lack of strength, but the actually delivering the
right number of bits for an algorithm. I may be wrong, please
check.

>    The use of IPsec for performing Registration with a home agent is not
>    always an optimal solution.  While it is true that IPsec is an
>    integral part of the IPv6 stack, it is still a considerable overhead
>    from a deployment perspective of using IPsec as the security
>    mechanism for the signaling messages between the MN and HA.  This
>    statement is a result of experience gained from deployment of Mobile
>    IPv4.  MIP4 does not rely on IPsec for securing the Registration
>    signaling messages.

I have a lot of sympathy for this statement, having attempted
to use IPsec for various purposes in different networks, and
often running into various problems of both technical and
other kinds.

However, this paragraph is not very descriptive. You have
to decide whether you want to make a technical argument,
but this requires a better argument than stating "X is overhead
if we want to do Y." There are technical arguments, but
frankly I'm not sure those are the compelling ones for
this particular part of the problem.

You might simply state that the operators are unwilling
to change anything (or change as little as possible) from
MIPv4. But you have this text earlier, already.

Editorial:

> So the alternate solution would be in
>    addition to the IPsec based mechanism specified in the base RFCs, RFC
>    3775 [RFC3775] and RFC 3776 [RFC3776].
Please include RFC 4877 here,too.

>    Mobile IPv6 as specified in RFC3775 and RFC3776 implies a very
>    specific model for deployment.  It anticipates the Mobile nodes
>    having a static home IPv6 address and a designated home agent.  An
>    IPsec SA is expected to be created, either via manual keying or
>    established dynamically by using IKE.  These assumptions do not
>    necessarily fit in very well for the deployment model envisioned in
>    cdma2000 networks.
This paragraph does not seem to add a lot of value over the
other statements in Section 5. Remove.

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?

Document shepherd: Basavaraj Patil
I am also the author of this document and hence the question of review
does not arise. However it has been reviewed by other WG members.
The I-D is ready for for forwarding to the IESG and 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?

Adequate review has been done by WG members and non-WG members. No
concerns about the depth or breadth of reviews exist.


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

This I-D was basically written as a means to justify the need for an
alternative mechanism for securing the MIP6 signaling. It is necessary
to publish this I-D for historical reasons and to ensure there is a
document explaining the arguments made for the authentication protocol
which has been published as an Informational RFC (RFC 4285).

(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. This I-D has been discussed in the WG a couple
of years ago. The justification for the authentication protocol
subsequently passed and RFC4285 has been published. This I-D is
required as a means to capture the intent.


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

The I-D has been run through the nits checker and all issues
corrected.

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

Yes. The references are split into normative and informative sections.


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

IANA considerations section exists. However this document does not
need any IANA action.


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

Not applicable to this I-D.

(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

Mobile IPv6 defines a set of messages that enable the mobile node
(MN) to authenticate and perform registration with its home agent
(HA). These authentication signaling messages between the mobile
node and home agent are secured by an IPsec SA that is established
between the MN and HA. The MIP6 working group has proposed a
mechanism to secure the binding update and binding acknowledgement
messages using an authentication option, similar to the
authentication option in Mobile IPv4, carried within the messages
that are exchanged between the MN and HA to establish a binding.
This document provides the justifications as to why the
authentication option mechanism is needed for Mobile IPv6 deployment
in certain deployment environments.

Working Group Summary

This document was written to consolidate the arguments and
justifications for an alternative to the IPsec based default mechanism
specified for MIP6 signaling security. RFC4285 has been subsequently
published which specifies the authentication protocol. The intent is
to capture for historical purposes the reasoning behind the
publication of the authentication protocol.

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?

This I-D is Informational and hence the question about implementations
is N/A. Reviewers have been acked. The document does not specify any
MIB or media types.


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: Basavaraj Patil
Responsible AD: Jari Arkko