Re: [HOKEY] ERX-12 -- Please review changes

[Lakshminath Dondeti <[e-mail]>]

On 2/26/2008 3:35 AM, Rafa Marin Lopez wrote:
> Hi Lakshminath,
> 
> Lakshminath Dondeti wrote:
>> Hi Bernard,
>>
>> I have reviewed draft-ohba-eap-kde-01 before and it does not meet fast 
>> reauthentication goals. 
> Please see my comments inline.
> 
>>  Please see below:
>>
>> On 2/25/2008 3:24 PM, Bernard Aboba wrote:
>>> [BA] I've recently seen a draft (from Yoshi, submitted today) that  
>>> seems
>>> to provide similar functionality with no changes to RFC 3748.  Although
>>> I haven't reviewed the document in depth, it did seem to provide
>>> method-independent re-authentication without multiple round-trips
>>> (at least for case of a local ERX server, which is the most important
>>> one from a performance point of view). 
>>
>> The number of roundtrips on the access link is 3,
>>  if we take connection open or an equivalent into account.  With ERP, 
>> the peer can start sending authenticated data after 1 RT.
>>
>>> This document will probably be discussed in IEEE 802, which could adopt
>>> it as their approach to EAP re-authentication going forward.
>>
>> In other access technologies, the handover latency requirements are 
>> more stringent and they have already adopted ERP and waiting for 
>> publication of the ERP RFC.  Without further optimizations, 802.11 
>> with 3 RTs or more for connection setup and EAP-KDE and 2 more for the 
>> 4-way exchange has little to no hope of really achieving low handover 
>> latency.
> 
> The reality is EAP-KDE is only adding a roundtrip in the ACCESS LINK 
> (between peer and authenticator) with respect to ERP,
> and NOT between authenticator and server, which is actually the bottleneck.

Hi Rafa,

Not according to people who design fast handover schemes.  I understand 
the issues with the backhaul, but in addition to that if the idea is to 
provide voice call continuity and if we want to budget for less than 
favorable radio conditions, cell density etc., we don't have the luxury 
of as many round trips as we want even in the access link.


> 
> EAP-KDE:
> 
> <-- EAP-Request/KDE{KDE0}
> --> EAP-Response/KDE{KDE1}   --> AAA{KDE2}
> <-- EAP-Request/KDE{KDE4}    <-- AAA{KDE3, authorization data}
> --> EAP-Response/KDE{}
> <-- EAP-Success
> 
> ERP:
> 
> <-- EAP Initiate/Re-auth-Start
> --> EAP Initiate/Re-auth --> AAA{EAP Initiate/Re-auth}
> <-- EAP Finish/Re-auth <-- AAA{EAP Finish/Re-auth}
> 
> 
> As you may observe, this additional roundtrip is exchanged between peer 
> and authenticator. Furthermore, EAP-Response/KDE{} and EAP Success are 
> very simple messages, so i would expect a really low processing time. So 
> my question is how many ms do you expect in that exchange in order to 
> affirm it does not meet a fast re-authentication goal?.

Simple is good, but not sufficient; how soon can the data packets be 
transmitted after handover is the issue.  It helps me to think about 
voice call continuity.

> 
> Furthermore, as Yoshi mentioned pre-authentication is also possible 
> (e.g. based on EAP-KDE) and that time would not affect at all.
> 
> In any case, the situation is that ERP would require modifications in 
> EAP-layer and existing EAP lower-layers to operate, but EAP-KDE avoids 
> those modifications (at the cost of an additional single roundtrip in 
> the access link which, to me, it should not be a major problem).

It turns out modifications to authenticators was the issue and EAP-KDE 
would also require modifications to the authenticators.  As I noted 
elsewhere, any modifications to lower layers are quite minimal.

Finally, if a link layer is to provide fast reauthentication, they need 
to do some work; EAP is just one aspect.  So, the idea that somehow we 
can drop in a new IETF protocol would be everything that needs to be 
done for fast reauthentication is somewhat sophomoric.  Last I checked, 
the 11r specification has more than 100 pages.

regards,
Lakshminath

> 
> 
>> -- 
>> ------------------------------------------------------
>> Rafael Marin Lopez
>> Dept. Information and Communications Engineering (DIIC)
>> Faculty of Computer Science-University of Murcia
>> 30100 Murcia - Spain
>> Telf: [phone]    e-mail: [e-mail]
>> ------------------------------------------------------
>>   
> 
_______________________________________________
HOKEY mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/hokey