Subject: [HOKEY] Comments on HOKEY Problem Stmt

From: peyush agarwal <[email-masked]>
Date: Tue, 28 Apr 2009 21:39:59 -0700 (PDT)

Hello All,

I would like to share my comments on HOKEY problem statement draft. All comments are embedded in the draft document that is attached.
(Each comment starts with header - "[Comment]")

Thanks,
Peyush.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 29 Apr 2009 17:23:28 +0900

The means that you have chosen to make your comments, while undoubtedly easy
for you, makes it very difficult to respond to the comments individually.
In the interest of courtesy, please reframe your comment as email, not as an
edited version of the document.  Thank you.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
peyush agarwal
Sent: Wednesday, April 29, 2009 1:40 PM
To: [email-masked]
Subject: [HOKEY] Comments on HOKEY Problem Stmt

Hello All,

I would like to share my comments on HOKEY problem statement draft. All
comments are embedded in the draft document that is attached.
(Each comment starts with header - "[Comment]")

Thanks,
Peyush.

---

From: Qin Wu <[email-masked]>
Date: Thu, 30 Apr 2009 17:42:45 +0800

Hi, Peyush:
Thank for your valuable comments, I am working on the hokey problem statement draft and have not finished until now.
As regards your comments, I will think about it. please see my reply below. If your comments are adressed, please let me know.

Regards!
-Qin

----- Original Message ----- 
From: peyush agarwal 
To: [email-masked] 
Sent: Wednesday, April 29, 2009 12:39 PM
Subject: [HOKEY] Comments on HOKEY Problem Stmt

Hello All,

Thanks,
Peyush.
> 
> 
> 1.  Introduction
> 
>   When a mobile device during an active communication session moves
>   from one access network to another access network and changes its
>   point of attachment, it is subjected to disruption in the 
> continuity   of service because of the associated handover 
> operation.  
> 
> [Comment] My understanding is that the absence of handover 
> mechanism causes 
> disruption. Consider replacing "handover" with "authentication".

[Qin}; As described in the section 3 "Problem satement" in this draft, the handover operation consists of three steps produre, 
network access authentication and authorization is a part of the third step. On the other hand, disruption will not happen without handover operation.
So it is more appropirate to use handover than authentication here, am I right?

>   The
>   performance requirement of a real-time application will vary 
> based on
>   the type of application and its characteristics such as delay
>   tolerance and loss tolerance limit.  ITU-T G.114 [ITU] 
> recommends 150
>   ms as the upper limit for VoIP applications and 400 ms as generally
>   unacceptable delay.  
> 
> [Comment] This is kind of confusing statement. 150ms is the upper 
> limit 
> & 400 ms is unacceptable, but, what about values greater than 150 
> and 
> less than 400ms? Are those values acceptable? 
> Or does the sentence mean -
> "ITU-T G.114 [ITU] recommends 150ms as an upper limit for VoIP 
> applications 
> and 400 ms as an upper limit for other streaming applications. 

[Qin] My understanding is ITU-T G.114 only provides some reference values or experience values for delay tolerance.
These values can be used to compare between different application. In real deployment or practice, these values can be used to assess the effect of delays
I checked through the ITU-T G.114, it mentioned in section 4:
"Regardless of the type of application, it is recommended to not exceed a one-way delay of 400 ms for general network planning (i.e., UNI to UNI, as illustrated, for example, in ITU-T Rec. Y.1541 [13]), a value that allows flexibility in deploying global networks, without making an excessive number of user experiences unacceptable."

So here 400 ms is applicable for all type of application and is a upper limit that does not make an excessive number of user expeiences unacceptable. And on the other hand, 150ms can be understood as the upper limit for VOIP that achieves satisfactory delay from the user perspective. 

Also you can refer to the figure 1/G.114 - Determination of the effects of absolute delay by the E-model, you will see that:

The level of user acceptance can be divided into user very satisfied, user satisfied, some user dissatisfied, many user dissatisfied, nearly all user satisfied based on transmission rate an delay. So it is obvious that 150ms is a upper limit that makes all the user satisfied and 400 ms is upper limit of delay tolerance that make some of user dissatified. What do you think of it?

> 
>   Similarly, a streaming application has a
>   tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
>   the transfer delay of less than 300 ms.  
> 
>   Thus, any optimized handoff 
>   mechanism will need to take these factors into consideration in 
> order   to be able to support a heterogeneous handover that is 
> agnostic to
>   link-layer technologies.
> 
> [Comment] Re-writing for clarity: Thus, an optimized handoff 
> mechanism shall meet
> delay and loss tolerance requirements to support heterogeneous 
> handover 
> agnostic to link-layer technologies.

[Qin] The original text says the optimized handoff mechanism should meet  the performance
requirements for real time application. The factors in the original text can be viewed as the performance requirements for real time application.
And the delay or loss tolerance requirements is just part of performance requirements. Anyway, your comment is appreciated here.

> 
>   As a mobile device goes through a handover process, it is subjected
>   to delay because of the rebinding of its association at or across
>   several layers of the protocol stack and higer number of round 
> trips   for EAP exchange.  
> 
>   Delays incurred within each of these layers affect
>   the ongoing multimedia application and data traffic within the 
> client   [WCM].
> 
> [Comment]Re-writing: Delays caused due to EAP exchange, and due to 
> layer processing cause disrupted inbound and outbound data traffic.

[Qin]: I am confused with the text you proposed. 
I would like to keep as it does unless you can give a concrete reason. Thanks.

>   During the handover process, it often requires authentication and
>   authorization for acquisition or modification of resources assigned
>   to a mobile device and the authentication and authorization needs
>   interaction with a central authority in a domain in most cases. 
> In
>   some cases the central authority may be placed far away from the
>   mobile device.  The delay introduced due to such an authentication
>   and authorization procedure adds to the handover latency and
>   consequently affects ongoing application sessions [MQ7].  As
>   regarding this kind of delay, we focus our discussion highlighting
>   the factors that affect the performance due to network access
>   authentication and authorization where EAP [RFC3748] is used for
>   network access authentication.
> 
> [Comment] Re-writing the whole paragraph above: The handover 
> process often requires 
> the mobile client to be autheticated and authorized with an AAA 
> server. The scope of 
> this document is to highlight factors affecting handover 
> performance due to authentication 
> and authorization using EAP [RFC 3748].

[Qin]: I have no problem with the original paragraph, Can you tell why we need to re-write this paragraph?

> 
>   This draft discusses EAP pre-authentication problems in detail 
> where   EAP pre-authentication is defined as the utilization of 
> EAP to pre-
>   establish EAP keying material on an EAP authenticator prior to
>   arrival of the mobile device that acts as an EAP peer, at the 
> access   network served by that authenticator.
> 
> [Comment] Re-write: This draft discusses issues involved with EAP 
> pre-authentication, 
> where EAP pre-authentication is a mechanism to pre-establish EAP 
> keying material
> on target EAP authenticator prior to a mobile client requesting 
> authentication with it.

[Qin]: I prefer not to do such change. Because this draft focuses on problem satement of pre-authentication.
What's more, the pre-authentication will be renamed as early authentication which has been consented in the maillist.

>   Access Point (AP)
> 
>      A network point of attachment in IEEE 802.11 wireless LAN
>      [802.11].
> 
> [Comment] Re-writing as per 802.11: Any entity that has station 
> functionality and 
> provides access to the distribution services, via the wireless 
> medium for associated stations.

[Qin] :As regarding the defintion change,  it is better not to introduce more
new sematics or terminologies which are not a major concern in this draft.

e.g., what is the distribution service? Shall we re-define the defintion of distribution service.
on the other hand, the network point of attachment is more concise and simple to describe the Access Point.
What do you think of it?

> 
>   Basic Service Set (BSS)
> 
>      The basic building block of an IEEE 802.11 wireless LAN 
> [802.11].      The BSS consists of a group of any number of 802.11 
> stations.
> [Comment] This definition doesn't seem right, re-writing as per 
> 802.11: A set of 
> wireless stations controlled by a single coordination function.

[Qin]: See the comments above.
Futhermore, it seems more explanation text is required to describe coordination function.

> 
>   Extended Service Set (ESS)
> 
>      A set of infrastructure BSSs in IEEE 802.11 wireless LAN 
> [802.11],      where the access points communicate amongst 
> themselves to forward
>      traffic from one BSS to another to facilitate movement of 
> stations      between BSSs.
> 
> [Comment] This definition doesn't seem right, re-writing as per 
> 802.11: 
> A set of one or more interconnected basic service sets (BSSs) and 
> integrated 
> local area networks (LANs) that appears as a single BSS to the 
> logical link 
> control (LLC) layer at any station associated with one of those BSSs.

[Qin]: See the comments above.

> 
> 3.  Problem Statement
> 
>   The basic mechanism of handover is a three-step procedure involving
>   i) discovery of candidate network points of attachment and their
>   authenticators, 
> 
> [Comment] What is the difference between "points of attachment" 
> and "authenticators"?
> I thought they imply the same device (e.g in 802.11 the point of 
> attachment 
> and authenticator is an AP). Isn't that right?

[Qin]: Partly you are right. Actually Point of attachment can be understood as the transport node in the data plane while the authenticator is a entity in the authentication system that grants access to the network. The authenticator can separate from point of attchment or be integated into point of attachment.

> ii) network selection procedure to determine the
>   appropriate candidate network point of attachment and iii) handover
>   or setting up L2 and L3 connectivity to the target network 
> point of
>   attachment.  
> 
> Currently, as part of the third step, network access
>   authentication and authorization are performed directly with the
>   target network.  For example, in IEEE 802.11 wireless LANs 
> [802.11],   the network access authentication and authorization 
> involves   performing a new IEEE 802.1X message exchange with the 
> authenticator   in the target AP to initiate an EAP exchange to 
> the authentication
>   server [WPA].  Following a successful EAP authentication, a secure
>   association procedure is performed between the peer and the target
>   authenticator to derive a new set of link-layer ciphering keys from
>   EAP keying material such as the MSK.  The third step may 
> require full
>   EAP authentication in the absence of any particular 
> optimization for
>   handover key management.  The handover latency introduced by 
> full EAP
>   authentication has proven to be larger than that is acceptable for
>   real-time applications scenarios as described in [MQ7].  Hence,
>   improvement in the handover latency performance due to EAP is a
>   necessary objective for such scenarios.
> 
> [Comment] Re-write: A mobile client Using legacy mechanisms for 
> authentication 
>   and authorization may require full EAP exchange with the target 
> attachment point. 
>   For example, IEEE 802.11 mobile client (STA) requires 
> performing IEEE 802.1X 
>   authentication with the target AP (Autheticator). Such full EAP 
> authentication 
>   process introduces handover delays and/or loss of data, and the 
> handover penality 
>   caused is unacceptable for real time network applications - 
> scenarios as described in [MQ7]. 

[Qin]: The original text is more generic and concise  than the text you proposed,
I wonder what is missing in the original text? Can you explain in more detail?
 
>   There is relevant work undertaken by various standards 
> organizations,   but these efforts are scoped to a specific link 
> layer technology.
>   IEEE 802.11F [802.11f], a trial use document has defined context
>   transfer and caching mechanism to transfer some IEEE 802.11 keying
>   material between the neighboring APs.  However, it has been
>   administratively withdrawn since 2006.  IEEE 802.11 [802.11] 
> defines   a pre-authentication mechanism for use in 802.11 
> wireless networks.
>   This mechanism allows peers to pre-authenticate to one or more
>   candidate authenticators over the wired medium, by way of the 
> serving   authenticator.  IEEE 802.11r [802.11r] defines Fast BSS 
> transition   mechanisms involving a definition of a key management 
> hierarchy and
>   setup of session keys before the re-association to the target 
> AP in
> [Comment] Re-write for clarity: Even though there has been 
> relevant work 
>   undertaken by various link layer standard organizations, but -
> 
>   i) The link layer handover procedure has been limited:
>      - IEEE 802.11r defines BSS transition within an ESS / 
> mobility domain (Intra-ESS)
>      - IEEE 802.11 pre-authentication technique assumes wired 
> connection between the 
>       current AP and the target AP
> 
>   ii) EAP authentication handover between two different type of 
> link layers (Inter technology) 
>       is not addressed, e.g., movement between WiFi and 3G 
> cellular network.
> 
>   And hence an improved mechanism for EAP authentication during 
> handover process is desired.

[Qin] Some texts you proposed here  is a little redundant with the original text in the same paragraph.
Also some transition text is required to smooth the whole text you proposed, anyway, it is a good summary, I can make some change in the draft.

> 
> 4.1.  The pre-authentication model(Peer-CA-AAA)
> 
>   In this type of pre-authentication model shown in Figure 2,
> 
>              Peer            Candidate              AAA Server
>                              Authenticator
>                              (CA)
> 
>            +---------+   +---------------------+    +---------+
>            |         |   |     EAP Auth-       |    | EAP     |
>            |EAP Peer |   |     enticator       |    | Server  |
>            |         |   |                     |    |         |
>            +---------+   +---------------------+    +---------+
>            |Peer-SA  |   |Peer-CA  | |CA-AAA   |    |CA-AAA   |
>            |Signaling<-->|Signaling| |Signaling|<--->Signaling|
>            |Layer    |   |Layer    | |Layer    |    |Layer    |
>            +---------+   +---------+ +---------+    +---------+
> 
>              Figure 2: Pre-authentication Model(Peer-CA-AAA)
> 
>   the serving authenticator does not involve in EAP exchange and only
>   forwards the EAP pre-authentication traffic as it would any other
>   data traffic or there may be no serving authenticator at all in the
>   serving access network.  The candidate authenticator and the 
> serving   authenticator may belong to the different AAA domain.  An
>   intermediary AAA node such as a AAA proxy may also involve in 
> the AAA
>   signaling between the candidate Authenticator and AAA/EAP server.
> 
> [Comment] If there is no serving authenticator but there is a 
> target authenticator,
> I am not sure whether we would need EAP preauthentication because 
> of the fact 
> that absence of serving authenticator implies that the peer does 
> not use EAP 
> exchange. However this model is true when peer device 
> authenticates for the first 
> time, but in that case there is no need for pre-auth anyways. 

 [Qin]: Just for information, the model(Peer-CA-AAA) has already achieve consensus when this draft becomes a WG draft.
As regarding the model (Peer-CA-AAA), I think the basic idea is to carry EAP message in the other Layer 3 protocol,
e.g., PANA as described in [I-D.ietf-pana-preauth] .
 
>   The pre-authentication signaling for the model (Peer-CA-AAA) is 
> shown   in Figure 3.
> 
>     Peer              Serving              Candidate            
> AAA/EAP                    Authenticator         Authenticator     
>     Server
>                        (SA)                 (CA)
>      |                   |                    |                   |
>      |                   |                    |                   |
>      |         Peer-CA Signaling (L3)         |       AAA         |
>      |<------------------+------------------->|<----------------->|
>      |                   |                    |                   |
>      |                   |                    |                   |
> 
>          Figure 3: Pre-authentication for the model(Peer,CA,AAA)
> 
>   [I-D.ietf-pana-preauth] is identified as a protocol to realize 
> direct   pre-authentication.
> 
> 4.2.  The Pre-authentication model(Peer-SA-CA-AAA)
> 
>   The Pre-authentication model(Peer-SA-CA-AAA) is illustrated in
>   Figure 4.
> 
>   In this pre-authentication model(Peer-SA-CA-AAA), it is assumed 
> that   a trust relationship exists between the serving network (or 
> serving   AAA domain) and candidate network (or candidate AAA 
> domain).  The
>   candidate authenticator and the serving authenticator may 
> belong to
>   the different AAA domain.  An intermediary AAA node such as a AAA
>   proxy may also involve in the AAA signaling between the candidate
>   Authenticator and AAA/EAP server.  The serving authenticator is
>   involved in EAP pre-authentication signaling.  This pre-
>   authentication model is needed if the peer cannot discover the
>   candidate authenticator's IP address or if IP communication is not
>   available due to security or network topology reasons.
> 
> [Comment]Replace the above para with: 
>   The Peer-SA-CA-AAA preauthentication model is required when peer
>   device cannot discover target canadidate authenticator's IP 
> address.   The model addresses Inter-domain and Intra-domain 
> preauthentication models, 
>   and assumes - 
>   i) Communication between Serving Authenticator and Candidate 
> Autheticator 
>      is possible.
>   ii) Trust relationship exists between the serving network (or 
> serving      AAA domain) and candidate network (or candidate AAA 
> domain). 
>   iii) Serving Authenticator, Candidate Authenticator, and AAA 
> Server support
>       preauthentication signalling.
>   iv) For Intra-Domain model, both serving AAA and target AAA 
> support EAP method 
>       that peer is currently authenticated with the serving AAA.

[Qin]: It seems the texts you proposed has already been covered by the original text except the last bullet
As regarding the last bullet, this draft focuses on the problem statement, not solution, I suggest to leave it to the solution scope.

> [Comment] QN: Based on the description, this model is required 
> when peer cannot 
> discover IP address of the target authenticator with an assumption 
> that 
> the communication between SA and CA is always possible. So, the 
> question is -
> Isn't Peer and SA on the same network, and so, if communication 
> between Peer 
> and CA is not possible, communication between SA and CA may not be 
> possible either?

[Qin] Since Peer-CA signaling can be divided into Peer-SA signaling and SA-CA signaling, I think you are right.
> 
>   The role of the serving authenticator in this pre-authentication
>   model is to forward EAP pre-authentication signaling between 
> the peer
>   and the candidate authenticator and not to act as an authenticator,
>   while it acts as an authenticator for normal authentication
>   signaling.
> 
>   The pre-authentication signaling for this model is shown in 
> Figure 5
>   .
> 
> 4.3.  The Pre-authentication model(Peer-SA-AAA-CA)
> 
>   The Pre-authentication model(Peer-SA-AAA-CA) is illustrated in
>   Figure 6.
> 
>      Peer            Serving                AAA Server      Candidate
>                      Authenticator                          
> Authenticator                      (SA)                            
>       (CA)
> 
>   +---------+  +--------------------+  +--------------------+ + --
> -------+
>   |         |  |                    |  |                    | |   
>       |
>   |EAP Peer |  |    EAP Auth-       |  |     EAP            | | 
> EAP Auth-|
>   |         |  |    enticator       |  |     Server         | | 
> enticator|   +---------+  +--------------------+  +----------------
> ----+ + ---------+
>   |Peer-SA  |  |Peer-SA  ||SA-AAA   |  |SA-AAA   ||CA-AAA   | | 
> CA-AAA   |
>   |Signaling<->|Signaling||Signaling<->|Signaling||Signaling<-> 
> Signaling|   |Layer    |  |Layer    ||Layer    |  |Layer    
> ||Layer    | | Layer    |
>   +---------+  +---------++---------+  +---------++---------+ + --
> -------+
> 
>            Figure 6: Pre-authentication Model(Peer-SA-AAA-CA)
> 
>   In this pre-authentication model(Peer-SA-AAA-CA), it is assumed 
> that   there is no trust relationship between the serving 
> authenticator (or
>   serving AAA domain) and the candidate authenticator (or 
> candidate AAA
>   domain).  The serving authenticator is involved in EAP pre-
>   authentication signaling.  The candidate authenticator and the
> 
>   serving authenticator may belong to the different AAA domain.  An
>   intermediary AAA node such as a AAA proxy may also involve in 
> the AAA
>   signaling between the candidate Authenticator and AAA/EAP server.
> 
>   The role of the serving authenticator in this pre-authentication
>   model is to perform the pre-authentication signaling between 
> the peer
>   and EAP server on behalf of the candidate authenticator and act 
> as an
>   authenticator.  The pre-authentication signaling is different from
>   the normal authentication signaling associated with the serving
>   authenticator.  The Peer-SA signaling is performed over L2 or L3.
> 
> 
> [Comment] I suggest handling a case where home AAA supports a 
> different 
> EAP method that the target AAA (assuming peer supports both)? 

[Qin] I am not sure whether it is in the scope of this draft. Actually I suggest to talk about these details in the solution draft.
What do you think of it?

> 
> 6.  AAA Issues
> 
>   Completion of network attachment:   Once the peer has successfully
>      attached to the new point of attachment, it needs to convert its
>      authentication state from pre-authenticated to fully 
> attached and
>      authorized.  There may need to be a mechanism within the AAA
>      protocol to provide this indication to the AAA server if the AAA
>      server needs to differentiate between pre-authentication and
>      normal authentication.  This is important from billing 
> perspective      where the billing policy does not charge for a 
> pre-authenticated
>      peer until the peer is fully attached to the target 
> authenticator.
> 
> [Comment] My understanding of AAA accounting is that NAS can 
> dictate AAA when 
> to start and stop accounting using Accounting-Request (Start) and 
> Accounting-Request (Stop) respectively. And so, NAS may request 
> AAA to 
> start accounting when the client is fully autheticated & 
> associated 
> rather than making AAA aware of preauthentication for accounting 
> purposes.

[Qin] I think you point has already been reflected in the paragraph."Completion of network attachment"
In this paragraph "Completion of network attachment", it said 
"     There may need to be a mechanism within the AAA
      protocol to provide this indication to the AAA server "
So the NAS can provide indication to the AAA server, and then AAA server needs to interpret this indication.

> 
>   Session Resumption:   In case the peer cycles between a network N1
>      with which it has a normal authentication state to another 
> network      N2 and then back to N1, it should be possible to 
> simply convert
>      the full authentication state to a pre-authenticated state.  The
>      problems around handling session lifetime and keying material
>      caching need to be dealt with.
> 
> [Comment] Or, we could just leave it to the peer when it wants to 
> deauthenticate with N1.

[Qin]:You need not worry about that. This paragraph does not restrict who deal with session resumption.