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

[Yoshihiro Ohba <[e-mail]>]

We might want to compare "luxury" to allow an additional single
roundtrip within access network vs. "luxury" to require changes to
existing lower layers and eliminate the additional single roundtrip
within access network.

The motivation of EAP-KDE is mostly based on the concern on the latter
luxury.

Yoshihiro Ohba

On Tue, Feb 26, 2008 at 10:15:22AM -0800, Lakshminath Dondeti wrote:
> 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
> 
_______________________________________________
HOKEY mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/hokey