RE: stds-802-handoff: Addressing Security

["Johnston, Dj" <dj.johnston@intel.com>]

Clint,
I feel that 802.11i's fast roaming problem is belongs in 802.11 and not
in 802 Handoff. Further to Ajay's points, there is the issue that
roaming (aka handoff) in 802.11 is a different thing to what would be
normal for an 802 handoff standard to address.

In 802.11i, 'fast roaming' is really 'fast re-authentication to avoid
slowing down existing intra-ESS reassociation'. This is necessary in
part because in 802.11 there specific rules about only being associated
to one AP at a time and the reassociation process is a well defined
thing.

The primary scenarios driving the 802 Handoff effort are multi
interfaces devices needing to handoff between interfaces, where no
procedures for handing off exist, and handoff within a technology type
(say 802.11) but between networks and administrative domains, where
handoff is not supported within the base standards (E.G. inter-ESS
handoff in 802.11).

These scenarious present a different set of constraints to those in
802.11. Few assumptions can be made about the type of handoff that might
be required (make-before-break, soft, hard, between two interfaces,
using one interface etc). So the goal is in part to make the tools and
information available to devices so they can handoff in the manner that
suits them.

Another difference is the idea of what is being handed off. In 802.11 it
is the association, or the participation in an ethernet. In a more
generalized 802 handoff, we would need to cover the case of handing off
between networks, not just within a network. So what are being handed
off are upper layer things such as mobile IP sessions or SIP style voice
calls.

So I think I support the idea of a TG to address fast roaming within
802.11 and I don't see a whole lot of overlap with 802 handoff. There is
a specific problem to solve that is specific to 802.11. TGi has bitten
of a lot (a legacy WEP fix, stronger crypto, key management, replacing
the authentication mechanism etc.) and breaking the problem into smaller
pieces is likely to get parts of the solution out and into products
earlier and better than one big standard. If I had had my way, TKIP,
CCMP and key management would all have been separate amendments.

DJ

David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG

Email : dj.johnston@intel.com
Tel   : 503 380 5578 (Mobile)
Tel   : 503 264 3855 (Office)

> -----Original Message-----
> From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] 
> Sent: Wednesday, June 25, 2003 8:32 AM
> To: ajayrajkumar@lucent.com; Clint Chaplin
> Cc: stds-802-handoff@ieee.org; Johnston, Dj; 
> ieee-802-11-tgi@majordomo.rsasecurity.com
> Subject: Re: stds-802-handoff: Addressing Security, was 
> :ThursdayHandoff meeting time.
> 
> 
> I have an agenda item at the July 802.11 opening plenary for 
> a Call for Interest for a fast roaming/fast handoff TG within 802.11.
> 
> I am also working on a preliminary PAR and 5 criteria for a 
> possible 802.11 TG for fast roaming/fast handoff, but I've 
> missed the deadline for submitting same at this plenary.
> 
> It seems that the sentiment within this SG is that two 
> complementary groups is necessary; however, I'm not sure how 
> to communicate this to 802.11 or REVCOM.  I someone willing 
> to help me at the Call for Interest and the writing of the 
> five criteria to justify the existance of a new TG within 802.11?
> 
> Clint (JOATMON) Chaplin
> >>> Ajay Rajkumar <ajayrajkumar@lucent.com> 06/25/03 07:02 AM >>>
> It may be worth pointing out that the 802 Handoff SG was 
> mandated to look at handoff across 802 and not be restricted 
> to 802.11 per se, which is what 802.11 TGi may be looking at. 
> For example, we spent a lot of time in May discussing this 
> very issue of handoff between 802.11 and 802.20.
> 
> So even though fast handoff/fast roaming within 802.11 may 
> come under the purview of this SG, there may still be a 
> difference in the narrow vs. wider focus.
> 
> At the same time it would definitely be prudent to keep these 
> issues in mind at the time of developing the PAR.
> 
> BTW, are there any plans of writing a PAR prior to July 
> meeting or would it be one of the agenda items for the July meeting?
> 
> -ajay
>