Subject: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-whyauthdataoption-03.txt

From: Basavaraj Patil <[email-masked]>
Date: Mon, 20 Aug 2007 12:44:17 -0500

Hello Jari,

The WG I-D: Why Authentication Data suboption is needed for MIP6 <
draft-ietf-mip6-whyauthdataoption-03.txt> has completed WG last call
and is ready to be progressed.

Intended status for publication: Informational

Below is the IESG writeup for progressing this I-D.

-Raj

==========================

   (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 <TO BE ADDED BY THE AD>.'

Document shepherd: Basavaraj Patil
Responsible AD: Jari Arkko

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 14:36:36 +0200

> Below is the IESG writeup for progressing this I-D.

Some comments on the draft...
> The authentication option specified in the Authentication Protocol 
> for MIP6 [RFC4285] is applicable in certain types of networks that 
> have the following characteristics:
[...]
> 3.  Networks in which the home agent and home address needs to be 
> assigned on a dynamic basis.

Not sure how authopt is better than IPsec concerning the dynamic
assignment of HA address and/or home address?  Any authentication
mechanism has tough issues when the endpoints are to be discovered.

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

I think there may be some confusion here?

Authenticating messages with AH  vs authopt is not very different in 
terms of bandwidth consumption.  Both include additional authentication 
data to each MIP6 signalling message (BU/BAck, BRR, BErretc.)

IKE may take longer than not using IKE, but MIP6 can work without IKE
and with pre-established SAs.

> cdma2000 networks deployed and operational today use Mobile IPv4 for
>  IP mobility.  Operators have gained a significant amount of 
> operational experience in the process of deploying and operating 
> these networks. 3GPP2 is now in the process of specifying Mobile IPv6
>  in Revision D of the 3GPP2 X.S0011-D [3GPP2 X.S0011-D] specification
>  (which specifies the packet data architecture).  The following are 
> the deployment constraints that existing CDMA networks have to deal 
> with when deploying Mobility service based on IPv6:
> 
> o  Operators intend to leverage the Mobile IPv4 deployment and 
> operational experience by ensuring that Mobile IPv6 has a similar 
> deployment and operating model.

I agree, yes, fully.

> o  Operators will have two parallel networks, one that offers IPv4 
> mobility with MIP4 and another providing IPv6 mobility using MIP6.

I think however it is nonsense to say that an operator has two parallel
networks whenever a new technology comes up.  Usually they keep the
modifications very much localized in order to _not_ having to maintain
several parallel networks.

Imagine an operator will have to deploy a third and fourth such network
in parallel for PMIPv6 and PMIPv4?

> o  The same backend subscriber profile database, security keys etc. 
> are intended to be used for both Mobile IPv4 and, Mobile IPv6 
> service.

I agree, mostly.

> o  The same user configuration information, i.e the identity and keys
>  associated with a user will be used for IP mobility service in IPv4 
> and/or IPv6 networks.  The only security association that is 
> preconfigured is a shared secret between the mobile node and the 
> home-AAA server.

I don't agree.  An operator can't share the same key with all his/her
customers.

Besides, you use the term "security association"???  If there's a
preconfigured SA between MN and HAAA then BU/BAck can be authenticated
with AH and that key; simply the operator has to copy that same key on
the HA from HAAA.

> o  The current Mobile IPv6 specification does not support the dynamic
>  assignment of home agent and home address.

PReviously you said it does for HA (not HoA) and indeed it does: DHAAD.

> The mechanism defined in Authentication protocol for Mobile IPv6 
> [RFC4285] is capable of handling authentication even in the case of 
> dynamic assignments (and is similar to what is used in current MIPv4
>  deployments).

This is very much speculation.

Authopt is and can not  be any more stronger than IKE/IPsec with respect
to discovery mechanisms.

The first degree of this speculation is that it previously says that
discovery mechanisms are under development, so we don't know yet what
they are.  The second degree of the speculation is that it assumes they
can be easier secured with authopt than IPsec/IKE.

_If_ the HA discovery mechanism relies on DNS discovery then we need a
secure DNS discovery mechanism, and that is based on IPsec not authopt.
    Similar for DHCP.

> o  The identity of a user in MIP4-based cdma2000 networks is an MN 
> Identifier Option for MIP6 [RFC4283].

I agree, but the "for MIP6" text seems redundant; but I get the sense.

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

I'm not sure what you mean here.  Authenticating a message exchange with
AH vs with authopt is about the same size.  Or do you mean _IKE_ may
take too many messages?

In this way, do you actually compare IKE vs some other unknown key
distribution system? and not authopt vs IPsec?

> Deployment of Mobile IPv6 on a large scale is possible only when the 
> protocol is flexible for being adapted to various scenarios.

Do you call cdma2000 "Large Scale"?... sorry I couldn't abstain.

I consider "Large Scale" more like Internet scale where different
operators talk to each other, open systems, IPv6 address to a grain, etc.

> Typically, the Mobile Node shares a security association with the 
> AAA-Home entity.

This is great.

> This is the preferred mode of operation over having a shared secret 
> between the MN and HA because the AAA-Home entity provides a central
>  location for provisioning and administering the shared secrets for a
>  large number of mobiles (millions).

I think IKE can do more than just millions of mobiles.

> This mode of operation also makes dynamic home address and dynamic 
> home agent assignment easier.

Provided that it all happens in a closed system, not across Internet.
It won't scale for Internet.

>    cdma2000 network operators are extremely conscious in terms of the
>    number of messages sent and received over the air-interface for
>    signaling.

This is good, but authopt doesn't exchange less messages than IPsec HA, 
it's the same actually.

>   Another downside of IKE for setting up the IPsec SA between the MN
>    and HA is that IKE does not integrate very well with the Radius based
>    AAA back-end.  Since operators rely on the AAA infrastrucure to
>    provision subscribers as well as define profiles, keys etc. in the
>    AAA-Home, there is no getting away from the use of AAA in cdma2000
>    networks.  IKEv2 does address this problem.  However from a timeline
>    perspective the availability of IKEv2 specifications for Mobile IPv6
>    Operation with IKEv2 and the revised IPsec Architecture [RFC4877] and
>    implementations did not meet the need of operators that are currently
>    relying on 3GPP2 specifications.

I really am not sure that 3GPP2 timelines should prevail.  There are 
other timelines as well.

Overall, I do agree with many of the points in this draft, and with the 
deployment necessity aspects.  But I don't see it as a standards track 
alternative to IPsec for MIPv6.  Just imagine the confusion this may 
bring to implementations.

Nits:
> It should be noted that some of the challenges of deploying MIP6 in 
> certain types of networks arise from the dependence on IKE which does
>  not integrate will with a AAA backend infrastructure.
                 well

Alex

> 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.
> 
> 
> 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?
> 
> needs more review from a particular or broader perspective, e.g., 
> security, operational complexity, someone familiar with AAA, 
> internationalization, or XML?
> 
> No.
> 
> 
> 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.
> 
> 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).
> 
> represent the strong concurrence of a few individuals, with others 
> being silent, or does the WG as a whole understand and agree with it?
> 
> 
> 
> 
> 
> 
> 
> 
> 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.
> 
> 
> 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.
> 
> 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].
> 
> 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?
> 
> document that are written in a formal language, such as XML code, BNF
>  rules, MIB definitions, etc., validate correctly in an automated 
> checker?
> 
> 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
> 
> 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
> 
> 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
> experts(s), insert 'The IANA Expert(s) for the registries in this 
> document are <TO BE ADDED BY THE AD>.'
> 
> Document shepherd: Basavaraj Patil Responsible AD: Jari Arkko
> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 15:01:26 +0200

I have to pick on a few selected items:

> terms of bandwidth consumption.  Both include additional 
> authentication data to each MIP6 signalling message (BU/BAck, BRR, 
> BErretc.)
>
The actual protection of the signaling traffic does not differ too much 
from a bandwidth point of view.
However, if you compare the number of messages that are exchanged for 
IKEv2 and for the Auth Protocol then there is obviously a big difference.

> with AH and that key; simply the operator has to copy that same key on

The text does not say that the operator shares the same key with all its 
customers. Instead, it says that the keys are established between the MN 
and the home AAA server.

> distribution system? and not authopt vs IPsec?
You need to compare the complete system, which is IPsec + IKEv2 + AAA 
interaction vs. Auth Protocol + AAA interaction.
 From a performance point of view the latter is much better.

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 15:23:51 +0200

> IKEv2 and for the Auth Protocol then there is obviously a big difference.

Sorry, authopt doesn't establish any key, right?

The number of messages exchanged is the same MIP6 messages, be it with 
AH authentication or with authopt authentication, right?

Do I miss any big thing here.

> customers. Instead, it says that the keys are established between the MN 

Ok.

>  From a performance point of view the latter is much better.

I mostly agree it can offer a higher performance in a small closed 
system... but that doesn't scale to large open systems.

Alex

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 17:04:34 +0200

Hi Alex,

a few quick comments below:

Alexandru Petrescu wrote:
>>>> wireless networks) and there exists a need to minimize the number 
>>>> of signaling messages sent over such interfaces.
>>>
>> The actual protection of the signaling traffic does not differ too 
>> much from a bandwidth point of view.
The Auth. Protocol document does not talk about generation of new 
MN<-->AAAH keying material changes and the IETF has not developed a 
"bootstrapping" mechanism for it either. Note, however, that some other 
SDOs produce solutions that use the network access authentication 
procedure to generate new keying material. That is pretty close to what 
is done with the integrated scenario expect that the keying material is 
not used for IKEv2/EAP.

> AH authentication or with authopt authentication, right?
You need to differentiate (a) pure message protection from the (b) 
authentication and key exchange.
For (a) both methods to the same. IPsec is more difficult to implement 
than the MIP6 auth protocol but that's another story. For (b) there are 
obviously the differences and Raj is talking about (b) rather than (a).

>>>>  associated with a user will be used for IP mobility service in 
>>>> IPv4 and/or IPv6 networks.  The only security association that is 
>> The text does not say that the operator shares the same key with all 
>> its customers. Instead, it says that the keys are established between 
>> the MN and the home AAA server.
>
> Ok.
>
I am not sure why you say "small closed system" vs. "large open system". 
The mobile node does not run the exchange with an arbitrary node. It 
runs the exchange with its home agent (that further relays the messages 
to the home AAA server using RADIUS or Diameter).

I can understand that some guys don't want to use IKEv2 to protect the 
MIPv6 signaling traffic between the MN and the HA since the mechanism to 
secure the actual MIPv6 signaling turns out to be far more complex than 
the MIPv6 signaling itself. I can also understand why some guys 
"develop" a mechanism for MIP6 that is essentially the same as the one 
for MIPv4.

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 17:27:27 +0200

Hannes Tschofenig wrote:
>>>>> 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.
>>>> 
>>>> Authenticating messages with AH  vs authopt is not very 
>>>> different in terms of bandwidth consumption.  Both include 
>>>> additional authentication data to each MIP6 signalling message 
>>>> (BU/BAck, BRR, BErretc.)
>>>> 
>>>> IKE may take longer than not using IKE, but MIP6 can work 
>>>> without IKE and with pre-established SAs.
>>>> 
>>> The actual protection of the signaling traffic does not differ 
>>> too much from a bandwidth point of view. However, if you compare 
>>> the number of messages that are exchanged for IKEv2 and for the 
>>> Auth Protocol then there is obviously a big difference.
>> 
> "bootstrapping" mechanism for it either. Note, however, that some 
> other SDOs produce solutions that use the network access 
> authentication procedure to generate new keying material.

I think we shouldn't compare SDO's network auth procedure to IKE and
then conclude that we don't need IKE.  I think that SDO's choice rests
that SDO's choice.

> That is pretty close to what is done with the integrated scenario
> expect that the keying material is not used for IKEv2/EAP.
> 
>> The number of messages exchanged is the same MIP6 messages, be it 
>> with AH authentication or with authopt authentication, right?
> authentication and key exchange. For (a) both methods to the same. 
> IPsec is more difficult to implement than the MIP6 auth protocol but 
> that's another story. For (b) there are obviously the differences and
>  Raj is talking about (b) rather than (a).
>> 
>>>>> o  The same user configuration information, i.e the identity 
>>>>> and keys associated with a user will be used for IP mobility 
>>>>> service in IPv4 and/or IPv6 networks.  The only security 
>>>>> association that is preconfigured is a shared secret between 
>>>>> the mobile node and the home-AAA server.
>>>> 
>>>> I don't agree.  An operator can't share the same key with all 
>>>> his/her customers.
>>>> 
>>>> Besides, you use the term "security association"???  If there's
>>>>  a preconfigured SA between MN and HAAA then BU/BAck can be 
>>>> authenticated with AH and that key; simply the operator has to 
>>>> copy that same key on the HA from HAAA.
>>> 
>>> The text does not say that the operator shares the same key with 
>>> all its customers. Instead, it says that the keys are established
>>>  between the MN and the home AAA server.
>> 
>> Ok.
>> 
>>>>> 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.
>>>> 
>>>> I'm not sure what you mean here.  Authenticating a message 
>>>> exchange with AH vs with authopt is about the same size.  Or do
>>>>  you mean _IKE_ may take too many messages?
>>>> 
>>>> In this way, do you actually compare IKE vs some other unknown 
>>>> key distribution system? and not authopt vs IPsec?
>>>> 
>>> You need to compare the complete system, which is IPsec + IKEv2 +
>>>  AAA interaction vs. Auth Protocol + AAA interaction. From a 
>>> performance point of view the latter is much better.
>> 
> I am not sure why you say "small closed system" vs. "large open 
> system". The mobile node does not run the exchange with an arbitrary 
> node. It runs the exchange with its home agent (that further relays 
> the messages to the home AAA server using RADIUS or Diameter).

Ok.

> I can understand that some guys don't want to use IKEv2 to protect 
> the MIPv6 signaling traffic between the MN and the HA since the 
> mechanism to secure the actual MIPv6 signaling turns out to be far 
> more complex than the MIPv6 signaling itself.

Actually I don't find the mechanism to protect the MIP6 signalling to be
complex.  Only the use of IKEv2 is heavy and complex (and MIP6 can work
with shared-keys, no need of IKE) and the SAdb has to be tweaked with
respect to the position of HoA.

AuthOpt doesn't bring any faster MIP6 whatsoever, it's the same
authentication data pasted on cleartext BU/BAck.

AuthOpt doesn't provide confidentiality either (no ESP), but maybe those
deployments don't need it anyways.

> I can also understand why some guys "develop" a mechanism for MIP6 
> that is essentially the same as the one for MIPv4.

I understand that too, yes, for implementing appears conceptually to be
easier to port a MIP4 auth feature to MIP6.  But it's going to be
reimplementing anyways, because the MIP4 auth feature doesn't work with
IPv6 bits and fields.

Alex

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 27 Aug 2007 17:57:16 +0200

Hi Alex,

Alexandru Petrescu wrote:
>>>>> Authenticating messages with AH  vs authopt is not very different 
>>>>> in terms of bandwidth consumption.  Both include additional 
>>>>> IKE may take longer than not using IKE, but MIP6 can work without 
>>>>> IKE and with pre-established SAs.
>>>>>
>>>> much from a bandwidth point of view. However, if you compare the 
>>>> number of messages that are exchanged for IKEv2 and for the Auth 
>>>> Protocol then there is obviously a big difference.
>>>
I am not sure what you are complaining about. You have to compare 
similar things since otherwise the comparison is mood. In this 
particular space the bootstrapping solution for MIPv6 with IKEv2 may 
either use (a) network access authentication (see 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integrated-dhc-05.txt) 
or (b) a separate protocol run (see 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split-07.txt). 

Here is the corresponding Diameter work:
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-04.txt

The former document is in WGLC.

The RADIUS work can be found here:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt

>>>>>> o  The same user configuration information, i.e the identity and 
>>>>>> keys associated with a user will be used for IP mobility service 
>>>>>> in IPv4 and/or IPv6 networks.  The only security association that 
>>>>>> is preconfigured is a shared secret between the mobile node and 
>>>>>> the home-AAA server.
>>>>>
>>>>>> 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.
>>>>>
But the IPsec solution just uses IKEv2.

> authentication data pasted on cleartext BU/BAck.
I wasn't able to convince you, as it seems.

> deployments don't need it anyways.
This is certainly a drawback (and also the reason for the applicability 
statement in the MIPv6 Auth Protocol document, if I recall it 
correctly). I personally would have provided confidentiality support to 
it as well.

> reimplementing anyways, because the MIP4 auth feature doesn't work with
When you consider the AAA infrastructure then it is a lot easier to just 
re-use things.

Anyway, I am not quite sure where your comments are heading. It seems 
that you like IKEv2 for MIPv6 security. That's great and there are specs 
available. A few guys have also expressed interest to work on something 
that is a bit different (ignoring all the reasons for a moment). Do you 
think it will be of any value to re-hash the discussion? Do you think 
that anyone will change their mind based on this discussion? Or are you 
suggesting that something tries to optimize the IPsec/IKEv2 
bootstrapping approach?

Ciao
Hannes

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 18:27:45 +0200

Hannes Tschofenig wrote:
>>>>>> additional authentication data to each MIP6 signalling
>>>>>> message (BU/BAck, BRR, BErretc.)
>>>>>> 
>>>>> The actual protection of the signaling traffic does not
>>>>> differ too much from a bandwidth point of view. However, if
>>>>> you compare the number of messages that are exchanged for
>>>  MN<-->AAAH keying material changes and the IETF has not
>>> developed a "bootstrapping" mechanism for it either. Note,
>>> however, that some other SDOs produce solutions that use the
>>> network access authentication procedure to generate new keying
>>> material.
>> 
>> I think we shouldn't compare SDO's network auth procedure to IKE
>> and then conclude that we don't need IKE.  I think that SDO's
>> choice rests that SDO's choice.
>> 

How about authenticating the access with a link-layer method and using
the obtained key to generate the IPsec AH authenticators?  That's what
I'm complaining about.

> http://www.ietf.org/internet-drafts/draft-ietf-mip6-radius-02.txt

Thanks but I don't see the relationship between these docs and the claim 
that authopt is any faster than IPsec-AH-based MIP6 authentication.

>>>> The number of messages exchanged is the same MIP6 messages, be
>>>> it with AH authentication or with authopt authentication,
>>>> right?
>>> You need to differentiate (a) pure message protection from the
>>> (b) authentication and key exchange. For (a) both methods to the
>>> same. IPsec is more difficult to implement than the MIP6 auth
>>> protocol but that's another story. For (b) there are obviously
>>> the differences and Raj is talking about (b) rather than (a).
>>>> 
>>>>>>> o  The same user configuration information, i.e the
>>>>>>> identity and keys associated with a user will be used for
>>>>>>> IP mobility service in IPv4 and/or IPv6 networks.  The
>>>>>>> only security association that is preconfigured is a
>>>>>>> shared secret between the mobile node and the home-AAA
>>>>>>> server.
>>>>>> 
>>>>>> I don't agree.  An operator can't share the same key with
>>>>>> all his/her customers.
>>>>>> 
>>>>>> Besides, you use the term "security association"???  If
>>>>>> there's a preconfigured SA between MN and HAAA then BU/BAck
>>>>>> can be authenticated with AH and that key; simply the
>>>>>> operator has to copy that same key on the HA from HAAA.
>>>>> 
>>>>> The text does not say that the operator shares the same key
>>>>> with all its customers. Instead, it says that the keys are
>>>>> established between the MN and the home AAA server.
>>>> 
>>>> Ok.
>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>>  exchange with AH vs with authopt is about the same size.
>>>>>> Or do you mean _IKE_ may take too many messages?
>>>>>> 
>>>>>> In this way, do you actually compare IKE vs some other
>>>>>> unknown key distribution system? and not authopt vs IPsec?
>>>>>> 
>>>>> You need to compare the complete system, which is IPsec +
>>>>> IKEv2 + AAA interaction vs. Auth Protocol + AAA interaction.
>>>> I mostly agree it can offer a higher performance in a small
>>>> closed system... but that doesn't scale to large open systems.
>>> system". The mobile node does not run the exchange with an
>>> arbitrary node. It runs the exchange with its home agent (that
>>> further relays the messages to the home AAA server using RADIUS
>>> or Diameter).
>> 
>> Ok.
>> 
>>> I can understand that some guys don't want to use IKEv2 to
>>> protect the MIPv6 signaling traffic between the MN and the HA
>>> since the mechanism to secure the actual MIPv6 signaling turns
>>> out to be far more complex than the MIPv6 signaling itself.
>> 
>> Actually I don't find the mechanism to protect the MIP6 signalling
>> to be complex.  Only the use of IKEv2 is heavy and complex (and
>> MIP6 can work with shared-keys, no need of IKE) and the SAdb has to
>> be tweaked with respect to the position of HoA.

MIP6 can use IPsec AH authentication without using IKEv2.

> I wasn't able to convince you, as it seems.

You can't convince anybody that authopt-based authentication brings any
speed to MIP6 authentication (compared to IPsec authentication), that's
clear.

If you compare IKEv2 to link-layer/radius/eap/diameter authentication
then it's a whole different problem and I think I agree with you that
the latter is quicker.

>> AuthOpt doesn't provide confidentiality either (no ESP), but maybe
>> those deployments don't need it anyways.
> This is certainly a drawback (and also the reason for the
> applicability statement in the MIPv6 Auth Protocol document, if I
> recall it correctly). I personally would have provided
> confidentiality support to it as well.

There's no such statement about confidentiality in authopt document, or
I don't see it.  Maybe there should be one.

>>> I can also understand why some guys "develop" a mechanism for
>>> MIP6 that is essentially the same as the one for MIPv4.
>> 
>> I understand that too, yes, for implementing appears conceptually
>> to be easier to port a MIP4 auth feature to MIP6.  But it's going
>> to be reimplementing anyways, because the MIP4 auth feature doesn't
>> work with IPv6 bits and fields.
> When you consider the AAA infrastructure then it is a lot easier to
> just re-use things.
> 
>  that you like IKEv2 for MIPv6 security.

I don't mean that, I know IKEv2 exchanges take time, but I'm saying if
we have a means to share keys then IPsec authentication of MIPv6
messages is not any heavier than authopt authentication... not sure I'm
clear.

> That's great and there are specs available. A few guys have also
> expressed interest to work on something that is a bit different
> (ignoring all the reasons for a moment). Do you think it will be of
> any value to re-hash the discussion? Do you think that anyone will
> change their mind based on this discussion? Or are you suggesting
> that something tries to optimize the IPsec/IKEv2 bootstrapping
> approach?

I'm not suggesting new work to optimize the IKEv2 bootstrapping for MIP6.

I'm saying the argument made by whyauthoption is not very udnerstandable 
by me.

Alex