Subject: [Dime] RE: Diameter Mobile IPv6: HA<->AAA Draft Reviewers

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 3 Sep 2007 19:35:22 -0500

Hi Hannes,

My apologies for not doing this on time. I have not read the comments by
Jouni or others, but please find my comments inline. I actually cut and
pasted the whole (almost) draft and inserted my comments which clearly
identified.

Best Regards,
Ahmad Muhanna

++++++++++++++++++++++++++++++++++++++++++++++++++++++

Abstract

   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 the
   Diameter server.  Two different mechanisms for authentication of a MN
   to the HA are supported.  The first method consists of performing the
   Internet Key Exchange v2 (IKEv2) protocol along with the Extensible
   Authentication Protocol (EAP) with the Diameter server, while the
   second method utilizes the Mobile IPv6 Authentication option, as
   defined in RFC 4285.  For Internet Key Exchange v2 with EAP-based
   authentication, the Diameter Mobile IPv6 application, defined in this
   document, reuses the commands defined in the Diameter EAP
   application, while for supporting the RFC 4285-style MIPv6
   Authentication Options, a new Diameter application and new command
   codes are defined.

[Ahmad-START-1]
May be the text of the last sentence needs to be fixed. It gives the
impression as if there are two different MIPv6 applications defined. The
new one for addressing RFC4285 authentication mechanism.

[Ahmad-END-1]

1.  Introduction

   Performing the Mobile IPv6 protocol [1], requires the Mobile Node
   (MN) to own a Home Address (HoA) and assignment of a Home Agent (HA)
   to MN.  The MN needs to register its Mobile IPv6 session with the HA
   in order facilitate 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 to establish the IP SA is generaally referred to

[Ahmad-START-2]
replace IP with IPsec. and generaally is missspeled.

[Ahmad-END-2]

   as the Mobile IPv6 bootstrapping problem [reference to RFC4640].  The
   purpose of this specification is to provide Diameter support for such
   bootstrapping in a split scenario [2] in a manner that satisfies the
   requirements defined in [13].

   From an operator (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
   boostrapping of Mobile IPv6 parameters at the MN and HA.  Thus, prior
   to processing the Mobile IPv6 service requests, 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 infrastrucure.  The HA due to its role in traffic
   forwarding, also performs accounting for the Mobile IPv6 service
   provided to the MN.

   Mobile IPv6 specifications allow two different methods for MN
   authentication, one based on IKEv2 and EAP [3], and another based on
   the Mobile IPv6 Authentication Option [4].  The goal of this document
   is to specify the Diameter procedures associated with the Mobile IPv6
   bootstrapping between the HA and the Diameter server for these two
   Mobile IP authentication approaches.

   For that reason the Diameter Mobile IPv6 application provides two
   different sets of commands.  The first set of commands reuse the
   command already define in Diameter EAP application (though using the
   Diameter Mobile IPv6 Application-Id), 

[Ahmad-START-3]
Basically any node which supports the new MIPv6 Application MUST support
Diameter EAP application, MIP6 Application using EAP commands, and MIPv6
Application using RFC4285 mechanism. Right?

[Ahmad-END-3]

   while the second set of
   commands are new for Diameter and provide support the Mobile IPv6
   Authentication Option, defined in RFC 4285.

   For authorization signaling and management of Mobile IPv6 session for
   the MN, this specification will use the existing procedures from base
   Diameter specification [5].

[Ahmad-START-4]
This is not clear to me. May be I am missing something. Do we need
further explanation and details here?
When this authentication is invoked?

[Ahmad-END-4]

   For accounting of Mobile IPv6 services provided to the MN, this
   specification uses the accounting application defined in [5].

4.  Overview

   One task of the Mobile IPv6 bootstrapping procedure is to assign an
   appropriate HA to the MN.  Furthermore, authorization and successful
   delivery of Mobile IPv6 to a MN through a HA, requires the HA to act
   as a client to the Diameter infrastructure interconnecting it to the
   MSP.  As a Diameter client, the HA needs to perform the following
   operations:

   Authentication:  Asserting or helping in assertion of the correctness
      of the MN identity.  As a Diameter client supporting the new
      Diameter Mobile IPv6 application, the HA may need to support two
      different types of authentication by supporting the different
      command sets that are required for each authentication method.

   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 accomplised through use of new Diameter commands
      specifically designed for performing Mobile IPv6 authorization
      decisions.  This document defines these commands and requires the
      HA to support use of these authorization commands and to
      participate in this authorization signaling.

[Ahmad-START-5]

We discussed before that AUTHORIZATION for ROUTE OPTIMIZATION is needed.
I did not see it included here?! As we discussed last time, operators do
care about having control over the willingness of the MN to have route
optimization. If that the case, then there should be a process to enable
that kind of authorization. No?

[Ahmad-END-5]

   Accounting:  For billing purposes and capacity planning, it is
      required of the HA to provide accounting report to the Diameter
      infrastructure and thus to support the related Diameter accounting
      procedures.

   Figure 1 depicts the architecture.

        +---------------------------+  +-----------------+
        |Visited MSP                |  | Home MSP/MSA    |
        |                           |  |                 |
        |                           |  |                 |
        | +--------+                |  |    +--------+   |
        | |Local   |      Diameter  |  |    |Home    |   |
        | |Diameter|<---------------------->|Diameter|   |
        | |Proxy   |                |  |    |Server  |   |
        | +--------+                |  |    +--------+   |
        |     ^                     |  |        ^        |
        |     |                     |  |        |        |
        |     | Diameter            |  |Diameter|        |
        |     v                     |  |        v        |
        | +-------+                 |  |     +-------+   |
        | |Home   |                 |  |     |Home   |   |
        | |Agent  |                 |  |     |Agent  |   |
        | +-------+                 |  |     +-------+   |
        |     ^                     |  |        ^        |
        +-----|---------------------+  +--------|--------+
              |                                 |
              |                                 |
              |          +---------+            |
              |          | Mobile  |            |
              +--------->| Node    |<-----------+
       IKEv2 or RFC 4285 +---------+ IKEv2 or RFC 4285

                      Figure 1: Architecture Overview

   [Editor's Note: A description of the relationship with the front-end
   protocols is needed.]

5.  Protocol Description

5.1.  Support for Mobile IPv6 with IKEv2 and IPsec

   The use of IKEv2 between the MN and the HA allows the HA to
   authenticate the MN.  When EAP is used with IKEv2, the Diameter EAP
   application, as defined in [8], is re-used.  AVPs specific to Mobile
   IPv6 bootstrapping are added to this command.

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

     Mobile                  Home                    Diameter
     Node                    Agent                   Server
     ------                  -----                   --------
            IKE_SA_INIT     (1,2)
   <------------------------------>

   HDR, SK{IDi,[CERTREQ,] [IDr,]
           [CP(CFG_REQUEST),]
            SAi2, TSi, TSr}  (3)
   ------------------------------->
                                    DER (EAP-Response) (4)
                                    ------------------------>
                                       DEA (EAP-Request) (5)
                                    <------------------------
    HDR, SK {IDr, [CERT,] AUTH,
             EAP }
   <-------------------------------
    HDR, SK {EAP}
   -------------------------------->
                                    DER (EAP-Response)
                                    ------------------------>
                                       DEA (EAP-Request)
                                    <------------------------
    HDR, SK{EAP-Request}
   <-------------------------------
    HDR, SK{EAP-Response}
   -------------------------------->
                                       DER (EAP-Response)
                                    ------------------------>
             ...                           ...

                                       DEA (EAP-Success)
                                    <------------------------
    HDR, SK{EAP-Success}
   <-------------------------------
    HDR, SK{AUTH}
   ------------------------------->
    HDR, SK {AUTH, [CP(CFG_REPLY,] SAr2, TSi, TSr }
   <-------------------------------

                 Figure 2: IKEv2 Diameter EAP Message Flow

   The MN and the HA start the interaction with an IKE_SA_INIT exchange.
   In this phase cryptographic algorithms are negotiated, nonces and
   Diffie-Hellman parameters are exchanged.  Message (3) starts the
   IKE_AUTH phase.  This second phase authenticates the previous
   messages, exchanges identities and certificates and establishes the
   first CHILD_SA.  It is used to mutually authenticate the MN (acting
   as an IKEv2 Initiator) and the HA (acting as an IKEv2 Responder).
   The identity of the user/MN is provided in the IDi field.  The MN
   indicates its willingness to be authenticated via EAP by omitting the
   AUTH field in message 3 (see [9]).

   As part of the authentication process, the MN MAY request a Home-
   Address, a Home Prefix or suggests one, see [2], using a CFG_REQUEST
   payload in the message 3.

[Ahmad-START-6]
Does this sentence mean that the MN MAY request a HoA and A HNP or only
one?

[Ahmad-END-6]

   The HA extracts the IDi field from the message 3 and sends a
   Diameter-EAP-Request (DER) message towards the authenticating
   Diameter server.

   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.

   At the end of the EAP authentication phase, the Diameter server
   indicates the result of the authentication in the Result-Code AVP and
   provides the corresponding EAP packet (EAP Success or EAP Failure).
   The last IKEv2 message sent by the HA contains the Home Address or
   the Home Prefix.  

[Ahmad-START-7]
Here it is clear, that the end result is either the assignment of HoA or
HNP. NOT both. May be we need to fix the sentence under comment 6.

[Ahmad-END-7]
 
   In the latter case, a CREATE_CHILD_SA exchange is
   necessary to setup IPsec SAs for Mobile IPv6 signalling.

   In some deployment scenario, the HA may also acts as a IKEv2
   Responder for IPsec VPN access.  A problem in this case is that the
   IKEv2 responder may not know if IK Ev2 is used for MIP6 service or
   for IPsec VPN access.  A network operator needs to be aware of this
   limitation.

5.2.  Support for the Mobile IPv6 Authentication Protocol

   Figure 3 describes the sequence of messages sent and received between
   the MN, the HA and the Diameter server during the registration when
   RFC 4285 is used.  Binding Update (BU) and Binding Acknowledgement
   (BA) messages are used in the registration process.  This exchange
   triggers the Diameter interaction.

   According to [4] the MN uses the Mobile Node Identifier Option,
   specifically the MN-NAI mobility option as defined in [14] to
   identify itself while authenticating with the HA.

   The MN may use the Message Identifier option for additional replay
   protection.  
   
[Ahmad-START-8]
1. Why we are calling it Message Identifier Option, Should not we refer
to it as Mobility Message Replay Protection Option as per RFC4285.

2. RFC4285 DID NOT mandate the use of this option for replay protection
assuming that Sequence Number is good enough for offering replay
protection. I believe sequence number as per RFC3775 is lacking a
complete replay protection and it relies on IPsec with IKEv2 to provide
a reliable replay protection mechanism. Since RFC4285 is similar to
RFC3344 of Mobile IPv4, then I would recommend mandating the use of this
option for replay protection whenever RFC4285 is used as an
authentication protocol.
[Ahmad-END-8]

   The authentication option may be used by the MN to
   transfer authentication data when the MN and the HA are utilizing a
   mobility SPI.

[Ahmad-START-9]
This needs more details. What does the MN and the HA are utilizing a
mobility SPI. Where is that SPI is coming from. i.e. Is it already
configured, or do we mean the MN-AAA Authentication option reserved SPI
value?

Some more clarification is needed.
[Ahmad-END-9]

   The BU initiates a MIP6-Request-Message to the Diameter server and
   the corresponding response is carried in a MIP6-Answer-Message.

[Ahmad-START-10]
Why Diameter is not part of the message name? I suggest the following
naming:
Diameter-MIP6-Request message and Diameter-MIP6-Answer message.

[Ahmad-END-10]

     Mobile                                Home                   AAA
     Node                                  Agent                 Server
       |                                     |                     |
       |                                     |                     |
       |       Binding Update                |MIP6-Request-Message |
    (a)|------------------------------------>|-------------------->|
       | (including MN-ID option,            |                     |
       |  Message ID option [optional],      |                     |
       |  authentication option)             |                     |
       |                                     |                     |
       |                                     |                     |
       |       Binding Acknowledgement       |MIP6-Answer-Message  |
    (b)|<------------------------------------|<--------------------|
       | (including MN-ID option,            |  (MN-HA key)        |
       |  Message ID option [optional],      |                     |
       |  authentication option)             |                     |

               Figure 3: MIPv6 Bootstrapping using RFC 4285

[Ahmad-START-11]
what are all the remaining information that is received from the
Diameter Server. This only highlight MN-HA key. is that all what is
returned?

This Figure needs to be updated with proper naming of the authentication
option and all other parameters, or a detailed explanation of these
steps is required.

[Ahmad-END-11]

5.3.  Mobile IPv6 Session Management

   The Diameter server may maintain state or may be stateless.  This is
   indicated in the Auth-Session-State AVP (or its absence).  The HA
   MUST support the Authorization Session State Machine defined in [5].
   Moreover the following 4 commands may be exchanged between the HA and
   the Diameter server.

5.3.1.  Session-Termination-Request Command

   The Session-Termination-Request (STR) message [5] is sent by the HA
   to inform the Diameter server that an authorized session is being
   terminated.

5.3.2.  Session-Termination-Answer Command

   The Session-Termination-Answer (STA) message [5] is sent by the
   Diameter server to acknowledge the notification that the session has
   been terminated.

5.3.3.  Abort-Session-Request Command

   The Abort-Session-Request (ASR) message [5] is sent by the Diameter
   server to terminates the session.  This fulfills one of the
   requirement described in [13].

5.3.4.  Abort-Session-Answer Command

   The Abort-Session-Answer (ASA) message [5] is sent by the Home Agent
   in response to an ASR message.

5.4.  Accounting for Mobile IPv6 services

   The HA MUST be able act as a Diameter client collecting accounting
   records needed for service control and charging.  The HA MUST support
   the accounting procedures (specifically the command codes mentioned
   below) and the Accounting Session State Machine as defined in [5].
   The command codes, exchanged between the HA and Diameter server for
   accounting purposes, are provided in the following subsections.

   The Diameter application design guideline [15] defines two separate
   model for accounting:

   Split accounting model:

      According to this model, the accounting messages use the Diameter
      base accounting application ID (value of 3).  Since accounting is
      treated as an independent application, accounting commands may be
      routed separately from the rest of application messages and thus
      the accounting messages generally end up in a central accounting
      server.  Since Diameter Mobile IPv6 application does not define
      its own unique accounting commands, this is the prefered choice,
      since it permits use of centralized accounting for several
      applications.

   Coupled accounting model:

      In this model, the accounting messages will use the application ID
      of the Mobile IPv6 application.  This means that accounting
      messages will be routed like any other Mobile IPv6 application
      messages.  This requires the Diameter server in charge of Mobile
      IPv6 application to handle the accounting records (e.g., sends
      them to a proper accounting server)..

   As mentioned above, the prefered choice is to use the split
   accounting model and thus choose Diameter base accounting application
   ID (value of 3) for accounting messages.

5.4.1.  Accounting-Request Command

   The Accounting-Request command [5] is sent by the HA to the Diameter
   server to exchange accounting information regarding the MN with the
   Diameter server.

5.4.2.  Accounting-Answer Command

   The Accounting-Answer command [5] is sent by the Diameter server to
   the HA to acknowledge receiving an Accounting-Request.

6.  Command-Code and AVP Values

   The following commands are defined in this section:

  Command-Name                 Abbrev.   Code     Reference  Application
  ----------------------------------------------------------------------
  MIP6-Request-Message         MRM       XXX      TBD        MIP6
  MIP6-Answer-Message          MAM       XXX      TBD        MIP6

                        Figure 4: New Command Codes

   The following defines the command codes used by the Diameter Mobile
   IPv6 application:

  Command-Name                 Abbrev.   Code     Reference  Application
  ----------------------------------------------------------------------
  Diameter-EAP-Request         DER       268      RFC 4072   EAP
  Diameter-EAP-Answer          DEA       268      RFC 4072   EAP
  MIP6-Request-Message         MRM       XXX      TBD        MIP6
  MIP6-Answer-Message          MAM       XXX      TBD        MIP6
  Session-Termination-Request  STR       275      RFC 3588   BASE
  Session-Termination-Answer   STA       275      RFC 3588   BASE
  Abort-Session-Request        ASR       275      RFC 3588   BASE
  Abort-Session-Answer         ASA       275      RFC 3588   BASE
  Accounting-Request           ACR       271      RFC 3588   BASE
  Accounting-Answer            ACA       271      RFC 3588   BASE

                          Figure 5: Command Codes

6.1.  Command Code for EAP-based Authentication

   This document re-uses the Diameter EAP application commands.  The
   following commands are used to carry MIPv6 related bootstrapping
   AVPs:

   Command-Name             Abbrev.   Code     Reference  Application
   ------------------------------------------------------------------
   Diameter-EAP-Request      DER       268      RFC 4072   EAP
   Diameter-EAP-Answer       DEA       268      RFC 4072   EAP

   Figure 6: Diameter EAP command codes used for MIPv6 Bootstrapping HA
                             to HAAA Interface

6.1.1.  Diameter-EAP-Request (DER)

   The Diameter-EAP-Request (DER) message [8], indicated by the Command-
   Code field set to 268 and the 'R' bit set in the Command Flags field,
   is sent by the HA to the Diameter server to initiate a Mobile IPv6
   service authentication and authorization procedure.  The DER message
   format is the same as defined in [8].  The Application-ID field of
   the Diameter Header MUST be set to the Diameter Mobile IPv6
   Application ID [TO BE ASSIGNED TO IANA].

     <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
                                < Session-Id >
                                { Auth-Application-Id }
                                { Origin-Host }
                                { Origin-Realm }
                                { Destination-Realm }
                                { Auth-Request-Type }
                                [ Destination-Host ]
                                [ NAS-Identifier ]
                                [ NAS-IP-Address ]
                                [ NAS-IPv6-Address ]
                                [ NAS-Port-Type ]
                                [ User-Name ]
                                { EAP-Payload }

                                [ MIP6-Feature-Vector ]
                                [ MIP-Mobile-Node-Address ]

                                ...
                              * [ AVP ]

6.1.2.  Diameter-EAP-Answer (DEA)

   The Diameter-EAP-Answer (DEA) message defined in [8], indicated by
   the Command-Code field set to 268 and 'R' bit cleared in the Command
   Flags field, is sent in response to the Diameter-EAP-Request message
   (DER).  If the Mobile IPv6 authentication procedure was successful
   then the response MAY include any set of bootstrapping AVPs.

   The DEA message format is the same as defined in [8].  The
   Application-Id field in the Diameter header MUST be set to the
   Diameter Mobile IPv6 Application-Id [TO BE ASSIGNED BY IANA].

     <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
                               < Session-Id >
                               { Auth-Application-Id }
                               { Auth-Request-Type }
                               { Result-Code }
                               { Origin-Host }
                               { Origin-Realm }

                               [ User-Name ]
                               { EAP-Payload }
                               [ Authorization-Lifetime ]

                               [ MIP-Mobile-Node-Address ]
                               [ MIP6-Feature-Vector ]

                               ...
                             * [ AVP ]

6.2.  Command Codes for RFC 4285 Support

   This section defines Command-Code [5] values that MUST be supported
   by all Diameter implementations conforming to this specification.
   The following Command Codes are defined in this specification.

      Command-Name             Abbreviation    Code           Section
      ------------------------------------------------------------------
      MIP6-Request-Message         MRM         TBD         Section 6.2.1
      MIP6-Answer-Message          MAM         TBD         Section 6.2.2

6.2.1.  MIP6-Request-Message

   The MIP6-Request-Message (MRM), indicated by the Command-Code field
   set to TBD and the 'R' bit set in the Command Flags field, is sent by
   the HA, acting as a Diameter client, in order to request the
   authentication and authorization of a MN.  The HA uses information
   found in the Binding Update to construct the following AVPs, to be
   included as part of the MRM:

   o  Home Address (MIP-Mobile-Node-Address AVP)

   o  Mobile Node NAI (User-Name AVP [5])

   o  MN-AAA Authentication Extension (MIP-MN-AAA-Auth AVP)

[Ahmad-START-12]
Should not we call it MN-AAA Message Mobility Authentication Option? Or
at least reference that in an explicit text.

[Ahmad-END-12]

   If the MN's home address is zero, the HA MUST NOT include a MIP-
   Mobile-Node-Address AVP.

   If the MN's home address is all ones, the HA MUST include a MIP-
   Mobile-Node-Address AVP, set to all ones.

[Ahmad-START-13]

As per this draft it says:
"   The BU initiates a MIP6-Request-Message to the Diameter server and
   the corresponding response is carried in a MIP6-Answer-Message.
"

What is in the BU as per RFC4285 which indicates to the HA which value
to use inside Mobile-Node-Address AVP as listed above?

[Ahmad-END-13]

   The message format is shown below:

           <MIP6-Request-Message> ::= < Diameter Header: XXX, REQ, PXY >
             < Session-ID >
             { Auth-Application-Id }
             { User-Name }
             { Destination-Realm }
             { Origin-Host }
             { Origin-Realm }
             [ Acct-Multi-Session-Id ]
             [ Destination-Host ]
             [ Origin-State-Id ]
             [ NAS-Identifier ]
             [ NAS-IP-Address ]
             [ NAS-IPv6-Address ]
             [NAS-Port-Type]

             [ MIP6-Feature-Vector ]
             [ MIP-MN-AAA-Auth ]
             [ MIP-Mobile-Node-Address ]

             [ Authorization-Lifetime ]
             [ Auth-Session-State ]
             * [ Proxy-Info ]
             * [ Route-Record ]
             * [ AVP ]

6.2.2.  MIP6-Answer-Message

   The MIP6-Answer-Message (MAM) message, indicated by the Command-Code
   field set to TBD and the 'R' bit cleared in the Command Flags field,
   is sent by the Diameter server in response to the MIP6-Request-
   Message message.  The User-Name MAY be included in the MAM if it is
   present in the MRM.  The Result-Code AVP MAY contain one of the
   values defined in Section 6.2.3.2, in addition to the values defined
   in RFC 3588 [5].

   An MAM message with the Result-Code AVP set to DIAMETER_SUCCESS MUST
   include the MIP-Mobile-Node-Address AVP.  The MIP-Home-Agent-Address

   AVP contains the HA assigned to the MN, 

[Ahmad-START-14]

What is the MIP-Home-Agent-Address has to do here? Is that supposed to
be inside the MAM?

[Ahmad-END-14]

while the MIP-Mobile-Node-
   Address AVP contains the home address that was assigned.

   The message format is shown below:

      <MIP6-Answer-Message> ::= < Diameter Header: XXX, PXY >
               < Session-Id >
               { Auth-Application-Id }
               { Result-Code }
               { Origin-Host }
               { Origin-Realm }
               [ Acct-Multi-Session-Id ]
               [ User-Name ]
               [ Authorization-Lifetime ]
               [ Auth-Session-State ]
               [ Error-Message ]
               [ Error-Reporting-Host ]
               [ Re-Auth-Request-Type ]

               [ MIP6-Feature-Vector ]
               [ MIP-MN-to-HA-MSA ]
               [ MIP-HA-to-MN-MSA ]
               [ MIP-MSA-Lifetime ]
               [ MIP-Session-Key]
               [ MIP-Mobile-Node-Address ]
             * [ MIP-Filter-Rule ]

[Ahmad-START-15]
Why do we need to have two different MSAs? MN-HA and HA-MN MSA?
Are we using these AVP as per RFC4004? which was designed for MIPv4
Application?
How the information is communicated back to the MN?

What this MIP-Session-Key is used for? Is it needed here?

[Ahmad-END-15]

               [ Origin-State-Id ]
               * [ Proxy-Info ]
               * [ AVP ]

   [Editor's Note: The MIP-Filter-Rule is based on IPFiltrRule, which is
   currently being revised.  Hence, this document should refer to the
   updated functionality.  Furthermore, the requirements document
   indicates that QoS parameters may need to conveyed to the HA.  Hence,
   the revised version of the QoS-Filter-Rule / QoSFilterRule being
   developed with [10] has to be used.]

6.2.3.  Diameter AVPs

   The Diameter client uses AVPs dependent on the usage of RFC 4285 [4]
   or RFC 4877 [3].

   To provide support for RFC 4285 [4] the following AVPs defined in
   [11] are reused in this application:

   o  MIP-HA-to-MN-MSA AVP,
   o  MIP-MN-to-HA-MSA AVP,
   o  MIP-Session-Key AVP
   o  MIP-Algorithm-Type AVP
   o  MIP-Replay-Mode AVP

[Ahmad-START-16]

What are the supported replay protection modes in MIPv6 Application?
What kind of mode reference the sequence number?, for example.

[Ahmad-END-16]

   o  MIP-MN-AAA-Auth AVP
   o  MIP-MN-AAA-SPI AVP
   o  MIP-Auth-Input-Data-Length AVP
   o  MIP-Authenticator-Length AVP
   o  MIP-Authenticator-Offset AVP
   o  MIP-MSA-Lifetime AVP
   o  MIP-Mobile-Node-Address (with an IPv6 address)

[Ahmad-START-17]

I have not seen how some of these AVPS are used in Diameter MIPv6
Application which is supposedly defined in this document?

Do we expect those AVPs to be used exactly as per RFC4004? If that the
case, should that be specified wherever applicable in this application?

[Ahmad-END-17]

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Wednesday, August 01, 2007 4:02 AM
> To: [email-masked]
> Cc: Muhanna, Ahmad (RICH1:2H10); Jouni Korhonen
> Subject: Diameter Mobile IPv6: HA<->AAA Draft Reviewers
> 
> I would like to thank
> 
> * Jouni Korhonen
> * Ahmad Muhanna
> 
> for their willingness to review the Diameter Mobile IPv6: 
> HA<->AAA draft within the next 2 weeks.
> 
> Ciao
> Hannes
> 
> 
> 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 16:24:58 +0200

Hi Ahmad,

thanks for your review. Please find a few comments below:

> pasted the whole (almost) draft and inserted my comments which clearly
Ok.

> replace IP with IPsec. and generaally is missspeled.
Ok.

> Application using RFC4285 mechanism. Right?
You need to differentiate between the different entities. Let us do that 
for a second:

* Requirements for the AAA Server

If the AAA server has to serve clients that use various different forms 
of authentication then the AAA server needs to support all mechanisms 
provided in the document.

* Requirements for the Home Agent

If the Home Agent expects only messages that are authenticated in a 
particular fashion then it only needs to support the respective subset 
of the document.

Does this make sense?

> When this authentication is invoked?
I guess it would not hurt to replace this sentence since the text about 
authorization and session management is later in the text anyway.

> that kind of authorization. No?

Hmmm. Let me send a mail to the group specifically about this issue.

>    Figure 1 depicts the architecture.
I replaced the sentence with a "may" rather than a "MAY" since this is 
anyway out-side the scope of this document. This is the front-end story.

> HNP. NOT both. May be we need to fix the sentence under comment 6.

I believe we should reduce this text to a minimum since this text talks 
about the content of this document:
http://www.ietf.org/rfc/rfc4877.txt

To answer your question: I believe both can be configured; not either or.

> to it as Mobility Message Replay Protection Option as per RFC4285.

I naively copied it from 
http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 in the 
expectation that the figure there would be correct.
I was wrong :-)

> option for replay protection whenever RFC4285 is used as an

I agree with you since there is a piece missing compared to the MIPv4 
solution when sequence numbers are used, namely the resynchronization part.

> Some more clarification is needed.

I deleted this sentence. Problem solved.

> Diameter-MIP6-Request message and Diameter-MIP6-Answer message.
There is no required to put Diameter into the name of a Command. We can, 
however, do it.
It just makes the name longer.
> Diameter Server. This only highlight MN-HA key. is that all what is
There is much more returned. We just didn't want to overload the figure 
since there are a number of AVPs that need to be exchanged.

> option and all other parameters, or a detailed explanation of these
Done. Please also do it in the revision of the Authentication Protocol 
draft.

>   Command-Name                 Abbrev.   Code     Reference  Application

As I indicated in my mail to the group about the next steps we need to 
change the content of this AVP and hence it would be much better to 
replace it entirely.
It will obviously get a new name as well.

> to use inside Mobile-Node-Address AVP as listed above?
Good point. I think this aspect is undefined, if I recall it correctly.

> What is the MIP-Home-Agent-Address has to do here? Is that supposed to

I deleted this sentence since the HA is not distributed in the MAM given 
that the MN has to interact with the Home Agent in the first place.

> Are we using these AVP as per RFC4004? which was designed for MIPv4
Yes. We re-use these AVPs and these guys just used two different AVPs.

> How the information is communicated back to the MN?
The key is not transported -- a key derivation technique is used.

> What kind of mode reference the sequence number?, for example.

To me it seems that the timestamp based replay protection technique is 
the only one that can be used at the moment. But there is a chance that 
people come up with something new in the future.

> case, should that be specified wherever applicable in this application?
These AVPs are extracted from RFC 4004. I suggested to copy the 
corresponding text from RFC 4004 (with a few modifications where 
necessary).

Ciao
Hannes

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 10:01:08 -0500

Thanks Hannes,
Minor comments inline.

Regards,
Ahmad

> >
> > [Ahmad-START-3]
> > Basically any node which supports the new MIPv6 Application MUST 
> > support Diameter EAP application, MIP6 Application using 
> EAP commands, 
> > and MIPv6 Application using RFC4285 mechanism. Right?
> >
> > [Ahmad-END-3]
> >   
> You need to differentiate between the different entities. Let 
> us do that for a second:
> 
> If the AAA server has to serve clients that use various 
> different forms of authentication then the AAA server needs 
> to support all mechanisms provided in the document.
> 
> If the Home Agent expects only messages that are 
> authenticated in a particular fashion then it only needs to 
> support the respective subset of the document.
> 
> 
> Does this make sense?

{Ahmad]
I agree. I should have identified which entity I am talking about, I
meant the AAA server. 
But probably it is a good idea to capture some text in the draft.

> I guess it would not hurt to replace this sentence since the 
> text about authorization and session management is later in 
> the text anyway.
> 
> 

[Ahmad]
Thanks!

> anyway out-side the scope of this document. This is the 

[Ahmad]
Ok.
> I deleted this sentence. Problem solved.

[Ahmad]
Ok.

> The key is not transported -- a key derivation technique is used.

[Ahmad]
Is that derivation already defined any where?
Also, what about the SPI values, are they also derived?

> people come up with something new in the future.

[Ahmad]
If that the case, let us make sure that we define that too. 
I am sure this is pending approval of comments on MIP6 rgarding
RFC4285bis.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Sep 2007 17:17:33 +0200

Hi Ahmad,

> Is that derivation already defined any where?
A couple of SDOs did some work on it. The key derivation to some extend 
depends on the available credentials that are being used in a particular 
environment.
> Also, what about the SPI values, are they also derived?
There are two SPIs: For the inbound direction at the HA side the HA or 
the AAA server needs to pick it.  -- they don't need to be derived.

>>>    [Editor's Note: The MIP-Filter-Rule is based on 
>>>       
>> IPFiltrRule, which is
>>     
>>>    currently being revised.  Hence, this document should 
>>>       
>> refer to the
>>     
>>>    indicates that QoS parameters may need to conveyed to 
>>>       
>> the HA.  Hence,
>>     
>>>    The Diameter client uses AVPs dependent on the usage of 
>>>       
>> RFC 4285 [4]
>>     
>>>    or RFC 4877 [3].
>>>
RFC 4285 already specifies this timestamp but the backend infrastructure 
need to carry it as well.

Ciao
Hannes

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 10:37:28 -0500

Hi Hannes,

> A couple of SDOs did some work on it. The key derivation to 
> some extend depends on the available credentials that are 
> being used in a particular environment.
> There are two SPIs: For the inbound direction at the HA side 
> the HA or the AAA server needs to pick it.  -- they don't 
> need to be derived.

[Ahmad]
What about the MN side? In other words, How these SPIs are communicated
back to the MN?

> RFC 4285 already specifies this timestamp but the backend 
> infrastructure need to carry it as well.
> 
> Ciao
> Hannes
> 
>