Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt

From: "David Frascone" <[email-masked]>
Date: Wed, 21 Nov 2007 13:41:48 -0500

This message marks the issuance of a working group last call (WGLC) on
DIME's Internet Draft entitled "Diameter Mobile IPv6: Support for Home Agent
to Diameter Server Interaction" (draft-ietf-dime-mip6-split-06.txt). You may
view this document at
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt

Please post comments and questions to the DIME mailing list (or to the
authors) no later than 18 December 2007 (4 weeks because of the upcoming
IETF meeting and the involvement of other SDOs).

Best regards,
Hannes Tschofenig
David Frascone
(IETF DIME Working Group Chairs)

-- 
David Frascone

Oxymoron: Safe Sex.
_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 29 Nov 2007 01:24:03 -0600

Hi All,
 
I had reviewed this document and please find my detailed comments below.
 
As a quick note, I believe this document needs a little more attention
to improve readability.

Best Regards,
Ahmad

++++++++++++++++++++++++++ Detailed Comments ++++++++++++++
 
Abstract

[Ahmad-1-START]

   Mobile IPv6 deployments may want to bootstrap their operations
   dynamically based on an interaction between the Home Agent and the
   Diameter server of the Mobile Service Provider (MSP).  This document
   specifies the interaction between a Mobile IP Home Agent and that
   Diameter server.

   Several different mechanisms for authenticating a Mobile Node are
   supported.  The usage of the Internet Key Exchange v2 (IKEv2)
   protocol allows different mechanisms, such as the Extensible
   Authentication Protocol (EAP), certificates and pre-shared secrets to
   be used.  Furthermore, another method makes use of the Mobile IPv6
   Authentication protocol.  In addition to authentication
   authorization, the configuration of Mobile IPv6 specific parameters
   and accounting is specified in this document.

   [Ahmad-1] I Propose the below text for Abstract:
   ------------------------------------------------

   This document specify a new Diameter application, Diameter MIPv6
   Application, that enables the interaction between Home Agent and
   Diameter server of the Mobile Service Provider (MSP) to support
   Mobile IPv6 authentication, authorization and bootstrapping of Mobile
   IPv6 configuration parameters.  The new application defines the
   required Mobile IPv6 AVPs that carry Mobile IPv6 parameters as part
   of the Diameter EAP and Diameter NASREQ applications messages during
   the IKEv2 with EAP authentication mechanism and IKEv2 with
   certificates and pre-shared secrets authentication mechanism,
   respectively.

   Additionally, two new Diameter messages are being defined as part of
   the Diameter MIPv6 application to support Mobile IPv6 authentication,
   authorization and bootstrapping of Mobile IPv6 configuration
   parameters based on the Auth protocol [3].  The collection of Mobile
   IPv6 services accounting information is also defined.
[Ahmad-1-END]

[Ahmad-2-Start]
   1.  Introduction

   Performing the Mobile IPv6 protocol [1], requires the Mobile Node
   (MN) to own a Home Address (HoA) and to have an assigned Home Agent
   (HA) to the MN.  The MN needs to register with the HA in order enable
   its reachability and mobility, when away from home.  The registration
   process itself requires establishment of IPsec security associations
   (SA) and cryptographic material between the MN and HA.  Providing the
   collection of home address, HA address and keying material is
   generally referred to as the Mobile IPv6 bootstrapping problem [13].
   The purpose of this specification is to provide Diameter support for
   the interaction between the HA and the AAA server required to solve
   the bootstrapping problem in the split scenario [2] in a manner that
   satisfies the requirements defined in [14].

   [Ahmad-2] Can we rephrase the above paragraph as below:
   -------------------------------------------------------

   Mobile IPv6 protocol [1] requires the Mobile Node (MN) to be assigned
   a Home Address (HoA) and a Home Agent (HA).  The MN registers with
   its HA to receive Mobile IPv6 service and reachability while it is
   away from home.  Before the Mobile Node starts the Mobile IPv6
   registration process, the mobile node is required to establish an
   IPsec security associations (IPsec SA) and have access to all
   cryptographic material that are needed for its relationship with the
   HA.  The process of delivering the collection of the home address, HA
   address and keying material is generally referred to as the Mobile
   IPv6 bootstrapping mechanism [13].

   The purpose of this specification is to define the Diameter details
   for the interaction between the HA and the AAA server that is
   required for the support of Mobile IPv6 bootstrapping mechanism in
   the split scenario [2] inline with the requirements defined in [14].
[Ahmad-2-END]

[Ahmad-3-Start]
   From a mobility service provider (MSP) perspective, it is important
   to verify that the MN is authenticated and authorized to utilize
   Mobile IPv6 service and that such services are accounted for.  Only
   when the MN is authenticated and authorized, the MSP allows the
   bootstrapping of Mobile IPv6 parameters.  Thus, prior to processing
   the Mobile IPv6 registrations, the HA, participates in the
   authentication of the MN to verify the MN's identity.  The HA also
   participates in the Mobile IPv6 authorization process involving the
   Diameter infrastructure.  The HA, due to its role in traffic
   forwarding, may also perform accounting for the Mobile IPv6 service
   provided to the MN.

   [Ahmad-3] Can we combine the third and 4th sentences above as below:
   --------------------------------------------------------------------

   Thus, prior to processing the Mobile IPv6 registration, the HA
   participates in the verification of the MN identity, the
   authentication of the MN, and the authorization of the Mobile IPv6
   services through the help of the Diameter infrastructure.
[Ahmad-3-END]

[Ahmad-4-START]

   Authentication: Asserting or helping with assertion of the
   ...........  Although the authentication is performed by the AAA
   server there is an impact for the HA as different set of command
   codes are needed for the respective authentication procedures.

   [Ahmad-4] /s/for the HA/on the HA/

   Authorization: The HA must verify that the user is authorized to use
   the Mobile IPv6 service using the assistance of the MSP Diameter
   servers.  This is accomplished through the use of new Diameter
   commands specifically designed for performing Mobile IPv6
   authorization decisions.  This document defines these commands and
   requires the HA to support them and to participate in this
   authorization signaling.

   [Ahmad-4] Can we rephrase the Authorization as follows:
   -----------------------------------------------------------

   Authorization: The Home Agent must verify that the user is authorized
   to receive Mobile IPv6 service via the MSP Diameter servers.  In
   order for the HA to verify the user Mobile IPv6 service
   authorization, the HA is required to support the new Diameter
   application specified in this document.
[Ahmad-4-END]

[Ahmad-5-START]

   Mobile IPv6 signaling between the MN and the HA can protected using
   two different mechanisms, namely using IPsec and via the MIPv6
   Authentication Protocol [3].

   [Ahmad-5] replace can protected by "can be protected"

   The important aspect is, however, that for these two approaches
   several different authentication and key exchange solutions are
   available.

   [Ahmad-5] What is meant by the above sentence?

   To establish IPsec security associations, protecting of Mobile IPv6
   signaling messages IKEv2 is used [4].  IKEv2 supports EAP-based
   authentication, certificates and pre-shared secrets.  For protecting
   using the MIPv6 Authentication Protocol [3] a mechanism has been
   designed that is very similar to the one used by Mobile IPv4.

   [Ahmad-5] Can we rephrase the above 3 sentences as follows:
   -----------------------------------------------------------
   Internet Key Exchange IKEv2 [4] is used for the establishment of
   IPsec security association and the protection of Mobile IPv6
   signaling.  Additionally, IKEv2 supports the use of EAP-based
   authentication, certificates and pre-shared secrets.  On the other
   hand, Mobile IPv6 Authentication Protocol [3] has been designed to
   protect Mobile IPv6 signaling in a way similar to the authentication
   extensions mechanism that is part of Mobile IPv4 [RFC-3344].
[Ahmad-5-END]

[Ahmad-6-START]

   The ability to use different credentials has an impact on the
   interaction between the HA (acting as a Diameter client) and the
   Diameter Server.  For that reason this document illustrates the usage
   of these authentication mechanisms with different subsections for:

   o  IKEv2 usage with EAP.

   o  IKEv2 usage with certificates and pre-shared secrets.

   o  MIPv6 Authentication Protocol.

   [Ahmad-6]
   I am not sure I understand what is meant by the above paragraph and
   the three bullets.

[Ahmad-6-END]

[Ahmad-7-START]
   AVPs specific to Mobile IPv6 bootstrapping are added to the EAP
   application commands.

   [Ahmad-7] EAP application commands is replaced by Diameter EAP.
   ---------------------------------------------------------------
 ..... are added to the Diameter EAP Application commands.

   Figure 2 shows the message flow involved during the authentication
   phase when EAP is used.

   [Ahmad-7] Make the above sentence more specific as below.
   ---------------------------------------------------------

   Figure 2 shows the message flow involved during the authentication
   phase when IKEv2 with EAP is used.
[Ahmad-7-END]

[Ahmad-8-START]
   This message is routed to the MNs Diameter server/EAP server.  The
   Diameter server selects the EAP method and replies with the DEA
   Message.  Depending on the type of EAP method chosen, a number of DER
   and DEA messages carry the method specific exchanges between the MN
   and the Diameter server/EAP server.

   [Ahmad-8] The first time DEA is mentioned, let us follow the same as
   DER and state what it stands for, please add Diameter-EAP-Answer
   before DEA.

   [Ahmad-8] Depending on the type of EAP method chosen, a number.....
   replace with Depending on the type of the chosen EAP method, a number
   ...

   [Ahmad-8]

   What does the last sentence under section 4.1. "below" means?  "The
   IKEv2 responder may A network operator needs to be aware of this
   limitation."
[Ahmad-8-END]

[Ahmad-9-START]

   General Comments: 
   ----------------

   1.  In the case of using IKEv2 with EAP, Certificates, or pre-shared
       keys, Do we achieve both Authentication and authorization at the
       same time?  That is my understanding.  If that is true, then we
       need to be consistent when we refer to these IKEv2 mechanisms and
       mention that what they exactly do.

   2.  Let us use the same naming for authentication options as per
       RFC4285bis, i.e.  MN-HA Authentication mobility option and MN-AAA
       Authentication mobility option.

   In the case of using IKEv2 with EAP, Certificates, or pre-shared
   keys, Do we achieve both Authentication and authorization at the same
   time?  That is my understanding.  If that is true, then we need to be
   consistent when we refer to these IKEv2 mechanisms and mention that
   what they exactly do.

[Ahmad-9-END]

[Ahmad-10-START]

   Under section 5.2.2, It says: "If the Mobile IPv6 authentication
   procedure was successful then the response MAY include any set of
   bootstrapping AVPs."
   
   [Ahmad-10]
   What does the above mean, SHOULD not we be more specific to what to
   expect, what any means, can we receive no HoA IP address for
   example!?
[Ahmad-10-END]

[Ahmad-11-START]
   Under section 5.3.1, It states that Mobility message replay
   protection option using timestamp is included in MIPv6 Request
   Message.  Why?

   As far as RFC4285bis, it says that the HA is the entity which
   verifies the replay protection if the authentication is successful.

   On the other hand, If we would like to make the AAA to verify the
   replay protection, we may need to include the HA timestamp too.  NO?
[Ahmad-11-END]

[Ahmad-12-START]
   In the case of the collocation of LMA and HA and the possibility of a
   mobile node to access the HA via Client MIPv6 and then roam into an
   area with PMIPv6 support, the MN may be then provided PMIPv6 support,
   this means that the MN will be assigned a whole HNP rather a HoA.  In
   that kind of deployment: SHOULD not we allow the possibility for
   bootstrapping a HNP and/or a HoA even in the case of Client MIPv6?
[Ahmad-12-END]

[Ahmad-13-START]
   Under section 5.3.1: I do not see where the HA request the MN-HA
   secret or MIP-MN-to-HA-MSA and MIP-HA-to-MN-MSA.  They are supposed
   to be flags inside MIP6-feature-vector but is it defined somewhere
   else?

   Also, Why in the MAM I see only MIP-MN-to-HA-MSA is returned from the
   HAAA server?  Are we assuming that MN-HA SA is symmetric?

   Also, why I see MIP-Session-Key AVP by itself in the MAM message.
   Should not this AVP be part of the MIP-MN-to-HA-MSA AVP?
[Ahmad-13-END]

[Ahmad-14-START]

   Under section6.2.  MIP-MN-AAA-SPI AVP, we need to use the correct
   name of the MN-AAA Auth. option as per RFC4285bis, i.e.

   .... contains an SPI code extracted from the MN-AAA Authentication
   message option included in the received BU message.

[Ahmad-14-END]

[Ahmad-15-START]
   Why are we using MIP-nonce and what is its value in this context?  Is
   it transmitted back to the MN?

   Also, is not replay protection identified based on the
   presence of replay protection message option? or I am missing
   something. why do we need it here?

   In other words, either SQN is supported or not.  If it is, then HA
   would accept BU with SQN only, if it is not, HA will not accept BU
   without the timestamp.  No?
[Ahmad-15-END]

[Ahmad-16-START]
   Under section 7.1, it says: MIP6-TIMESTAMP-MISMATCH (Status Code TBD)

   This error code is used by the home agent to indicate to the HA that
   the timestamp value provided as part of the MN-AAA option has an
   unacceptable clock-drift. s/indicate to the HA/indicate to the MN/

   Also, timestamp was not provided as part of the MN-AAA option. what
   you are trying to say here?
[Ahmad-16-END]

[Ahmad-17-START]
   Finally: Is it possible to change the names of the Diameter MIPv6
Application
   messages?:

   1.  Diameter-MIP6-Request (DMR)

   2.  Diameter-MIP6-Answer (DMA)

   Just a suggestion!  
[Ahmad-17-END] 

Regards, 
Ahmad 

________________________________

	From: David Frascone [mailto:[email-masked]] 
	Sent: Wednesday, November 21, 2007 12:42 PM
	To: [email-masked]
	Subject: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt

	This message marks the issuance of a working group last call
(WGLC) on DIME's Internet Draft entitled "Diameter Mobile IPv6: Support
for Home Agent to Diameter Server Interaction"
(draft-ietf-dime-mip6-split-06.txt). You may view this document at
	
http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt
<http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-06.txt> 
	
	Please post comments and questions to the DIME mailing list (or
to the authors) no later than 18 December 2007 (4 weeks because of the
upcoming IETF meeting and the involvement of other SDOs).
	
	Best regards,
	Hannes Tschofenig
	David Frascone
	
	-- 
	David Frascone
	
	Oxymoron: Safe Sex.

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 19:35:59 +0100

Hi Ahmad,

Thanks for a very extensive review. I'll have some initial comments
for your comments inline.

[snip]

>    I am not sure I understand what is meant by the above paragraph and

It is meant to state which cases are covered by this I-D. Each
of them is slightly different from the AAA point of view.

[snap]   

>    IKEv2 responder may A network operator needs to be aware of this

D'oh. It should only read
"A network operator needs to be aware of this limitation."

>    General Comments: 

That's correct.

>        mention that what they exactly do.

OK.

>        Authentication mobility option.

OK.

[snipetisnip]

>    expect, what any means, can we receive no HoA IP address for

Hmm.. MIP6-Feature-Vector in optional. The AAA does not need to return
one especially if the HA did not do so either in the request. Also AAA
does not need return HoA if the HA did not ask one. Also QoS AVPs are
optional and depend obviously on subscription profile.

Now that I wrote some of this here, it could definitely be written also
to draft ;)

>    protection option using timestamp is included in MIPv6 Request

The AVP is optinal in the ABNF. If the BU contains replay protection
option with timestamp that is then conveyed to the AAA.

>    verifies the replay protection if the authentication is successful.

Afair 3GPP2 needs it in AAA for their auth option processing... not
that they would ever use this spec for that, though.

>    replay protection, we may need to include the HA timestamp 

Don't think so. At least the existing documented use in 3GPP2 does
not do that.

>    bootstrapping a HNP and/or a HoA even in the case of Client MIPv6?

See section 6.4.

  ".. In case the Diameter server assigns only a Home Network Prefix
   to the Mobile Node the lower 64 bits of the MIP-Mobile-Node-Address
   AVP provided address MUST be set to zero."

Anyway, the combined PMIP & CMIP case is a bit mess atm. If the
proposed *-dime-pmip6-* draft gets adopted we need to sync these a bit
more. 

>    to be flags inside MIP6-feature-vector but is it defined somewhere

Hmmm.. The assumption has been that AAA always returns MN-HA secret
when this application is used.

>    HAAA server?  Are we assuming that MN-HA SA is symmetric?

Yes. This is something that always bothers me whether that should
be asymmetric. Every time I ask opinions about it, no one seems to
care about anything else that symmetric SA.

>    Should not this AVP be part of the MIP-MN-to-HA-MSA AVP?

That is an editing error. It is part of MIP-MN-to-HA-MSA and should
only be in there.

[chop]

>    something. why do we need it here?

I need to poke Hannes about nonces.

>    you are trying to say here?

     "This error code is used by the home agent to indicate to the MN
      that the timestamp value provided in the BU has an unacceptable
      clock-drift."

> [Ahmad-16-END]
> 
>    
> [Ahmad-17-START]
>    Finally: Is it possible to change the names of the 
> Diameter MIPv6 Application
>    messages?:
> 

Cheers,
	Jouni

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 Nov 2007 00:23:08 -0600

Hi Jouni,
Please see comments inline.

Regards,
Ahmad
 
> Subject: RE: [Dime] WGLC for draft-ietf-dime-mip6-split-06.txt
> 
> Hi Ahmad,
> 
> Thanks for a very extensive review. I'll have some initial 
> comments for your comments inline.
> 
> 
> [snip]
> 
> > [Ahmad-6-START]
> > 
> It is meant to state which cases are covered by this I-D. 
> Each of them is slightly different from the AAA point of view.

[Ahmad]
Can we rephrase the paragraph as follows or something like that:

In order to provide the proper details of the different authentication
mechanisms, the following three authentication mechanisms will be
addressed under separate subsections.

   o  IKEv2 usage with EAP.

> The AVP is optinal in the ABNF. If the BU contains replay 
> protection option with timestamp that is then conveyed to the AAA.

[Ahmad]
I am not against including the timestamp received in BU, I just want to
know the purpose of it. According to what you just said, it is included
based on 3GPP2 requirements and need. On the other hand and under
section 6.16 it says:

"  The support for replay protection is an optional feature in [3].
   When the Diameter server checks the timestamp provided by the MN via
   the HA and recognizes a clock-drift (outside a locally defined replay
   protection window) then it MUST initiate the re-synchronization
   procedure by returning a MIP6-Answer-Message with Result-Code set to
   MIP6-TIMESTAMP-MISMATCH and attaches the MIP-Timestamp AVP including
   it's current time back to the HA.
"

Apparently, it says that the Diameter server is the one making the
replay protection check. That is in conflict with RFC4285bis?

Now, what is the justification and the logic of the above text and why
Diameter Server does the replay protection and against which clock?

> Afair 3GPP2 needs it in AAA for their auth option 
> processing... not that they would ever use this spec for that, though.
> 
> Don't think so. At least the existing documented use in 3GPP2 
> does not do that.

[Ahmad]
Please see the above comment.

> 
> > [Ahmad-11-END]
> > 
> > 
> > [Ahmad-12-START]
> >    In the case of the collocation of LMA and HA and the 
> possibility of 
> > a
> >    this means that the MN will be assigned a whole HNP 
> rather a HoA.  
> > In

[Ahmad]
Thanks for the pointer! Now I remember that I read it before:)

> 
> Anyway, the combined PMIP & CMIP case is a bit mess atm. If 
> the proposed *-dime-pmip6-* draft gets adopted we need to 
> sync these a bit more. 
> 
> > [Ahmad-13-START]
> Hmmm.. The assumption has been that AAA always returns MN-HA 
> secret when this application is used.

[Ahmad]
It would be nice to have an explicit indication just like RFC4004.
I believe that is cleaner. Also, that assumption is not documented any
where; at least I did not see it.

> Yes. This is something that always bothers me whether that 
> should be asymmetric. Every time I ask opinions about it, no 
> one seems to care about anything else that symmetric SA.

[Ahmad]
IMO, I do not believe that there is any justification for having
asymmetric SA in the case of MIPv6 Auth protocol, for the very simple
reason: 

1. Replay protection is guaranteed by timestamp or SQN. I like timestamp
though. SQN in RFC3775 is not used for replay protection, it is used for
sequencing. We have beaten this to death during PMIPv6 discussion. And
at the same time the MN-HA SA is between the MN and the HA ONLY.

2. Reflection attack is impossible, since HA can not receive BA and MN
can not receive BU.

At any rate, if we would like to use symmetric MN-HA MSA, then we need
to change the AVP name from: MIP-MN-to-HA-MSA to MIP-MN-HA-MSA (new AVP)
because the MIP-MN-to-HA-MSA [RFC4004] assumes asymmetric MSA. We also
need to clearly document that choice.

> That is an editing error. It is part of MIP-MN-to-HA-MSA and 
> should only be in there.
> 
> [chop]
> 
> > [Ahmad-15-START]
> >    Why are we using MIP-nonce and what is its value in this 
> context?  
> > Is

[Ahmad]
At least we need to update the following text:

6.14.  MIP-nonce AVP

   The AVP (AVP Code 335) is of type OctetString and contains the nonce
   sent to the Mobile Node.  This AVP is re-used from [12].

To be changed as follows or something similar:
----------------------------------------------

6.14.  MIP-nonce AVP

The AVP (AVP Code 335) is of type OctetString and contains the nonce
that to be sent to the Mobile Node. If this AVP is returned in the MAM
message, the nonce MUST be sent to the Mobile Node to be used in
deriving the MN-HA session secret key. The mechanism that the AAA and
the Mobile Node use to derive the MN-HA session secret key is out of
scope.

>       that the timestamp value provided in the BU has an unacceptable

[Ahmad]
Ok.

---

From: <[email-masked]>
Date: Fri, 30 Nov 2007 11:41:40 +0100

Hi Ahmad,

Thanks again. Very constructive comments!
Please see inline.

[snip]

> protection 
> I am not against including the timestamp received in BU, I 
> just want to know the purpose of it. According to what you 
> just said, it is included based on 3GPP2 requirements and 
> need. On the other hand and under section 6.16 it says:
> 
> Apparently, it says that the Diameter server is the one 
> making the replay protection check. That is in conflict with 
> RFC4285bis?

In the current draft it is the AAA server that does the
replay protectection... which is not inline with RFC4385bis,
as you noted.

> Now, what is the justification and the logic of the above 
> text and why Diameter Server does the replay protection and 
> against which clock?

See my following comment.

> > >    replay protection, we may need to include the HA 
> timestamp too.  
> > > NO?
> > 
> > Don't think so. At least the existing documented use in 
> 3GPP2 does not 
> > do that.
> 
> [Ahmad]

I re-checked the pp2 stuff. Even if the AAA wants to know the
timestamp for its IK computation, the replay protection is
still preformed by the HA (after a successfull auth/authz).
The same would work for wimax also.

Thanks for pointing at the timestamp text & logic here! It is
clearly messed up and must be fixed.

Cheers,
	Jouni