RE: FW: [LinkSec] updated handoff presentation
I think you have made a correct assesment. My suspicion is that we need
something in between a minimal PDU dump and a full blown reliable
transport.
Some of the information we MIGHT choose to pass around in the handoff
group includes..
QoS capabilities
Channel recommendations/assesments
Authentication services
Roaming agreements supported
Upper layer services available (IPv4? IPv6? FmIP? ATM? Etc)
Advertisments
Pricing information
Location Information
Subnet boundary crossings
Some way of assesing whether a DHCP lease is present on the VLAN
you're going to get if you connect
Neighbour lists (encapsulating all of the above for neighbours)
There are probably many more that people could think up. The point is to
be extensible and let people find what is genuinely useful out in the
real world. I have no intention of the standard defining more than a
minimal information set, vendor proprietary regions and playpen regions
in the first instance.
Some level of sophistication might be required in being able to ask for
stuff. 'Dump all your data to me' is probably a bit coarse. 'Give me
data of this class' might be better. 'Preauthenticate me and here is my
credential' is getting quite daring. 'Would you accept my VoIP session
with the follow QoS constraints if I handed off to you' sounds scary to
me. There is obviously a line of inquiry to follow here to determine
what the semantics of the messaging should be, but certainly it should
be lightweight to fit in with my idea of a tasteful protocol and it
probably wants to be able to deal with messages that cross MPDU
boundaries.
My plane is boarding now...
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: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com]
> Sent: Friday, August 29, 2003 3:57 PM
> To: 'Bernard Aboba'; Johnston, Dj; CONGDON,PAUL
> (HP-Roseville,ex1); mick_seaman@ieee.org; stds-802-linksec@ieee.org
> Subject: RE: FW: [LinkSec] updated handoff presentation
>
>
>
> So, a couple of things I'm hearing are needed in this discovery
>
> - Must allow both query and advertise modes (needs to be quick)
> - Must run prior to authentication so we know who to
> authenticate
> with and using what ID/credential
> - Ideally supports large segments of information (more
> than would
> fit in a single PDU)
>
> Since the purpose of *this* discovery is only to determine
> what network is
> out there so we know how to authenticate to it, I'm still
> thinking it could
> be part of the initial 802.1X exchange. The only real
> problem I see with
> that is the final item above (large segments). I don't
> understand the scope
> of the information that is needed here that requires a full
> blown reliable
> transport to enabled information exchange.
>
> Paul
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > Sent: Thursday, August 28, 2003 3:56 PM
> > To: dj.johnston@intel.com; paul.congdon@hp.com;
> > mick_seaman@ieee.org; stds-802-linksec@ieee.org
> > Subject: RE: FW: [LinkSec] updated handoff presentation
> >
> >
> > EAP WG has so far declined to add network discovery to RFC
> > 2284bis, and
> > would probably prefer this be done somewhere else if
> > possible. Network
> > discovery is often used in order to figure out which network
> > to attempt to
> > associate (and authenticate) to, so doing this in EAP is
> > often inconvenient.
> > There are some APs that include network info now in the
> > EAP-Request/Identity, but it is not universally implemented
> > at this point.
> >
> > In terms of the interactions between Discovery and 802.1X, I
> > think we need
> > to look at how we want Discovery to interact with the
> > controlled/uncontrolled port model. It seems to me that we'd
> > need to be
> > able to send Discovery packets prior to 802.1X
> > authentication, since the
> > purpose is in part to discover which network to authenticate
> > to. That would
> > imply that Discovery traffic would have to be processed on
> > the uncontrolled
> > port, not the controlled port (as LLDP is). This doesn't
> > necessarily imply
> > that Discovery has to have the same Ethertype as 802.1X, I
> > don't think. In
> > PPPOE, the Discovery packets do use a different Ethertype
> > than either Data
> > or Authentication, and so I'd say that's probably the default
> > way to go at
> > this point.
> >
> > In terms of MTU, we do have an IETF proposal for DDP which is
> > justified in
> > part because of the perceived usefulness of IP fragmentation.
> > However, IP
> > fragmentation can cause incorrect reassembly to occur if
> > datagrams are sent
> > before an IP address is assigned -- which can be quite likely
> > in IEEE 802.1X
> > situations. As a result, it doesn't appear to me that DDP
> > really does
> > address the fragmentation issue.
> >
> >
> > >Paul,
> > >Some reasons I can think of right now.
> > >
> > >1) Semantics. EAPoL is just as its name suggests, a
> > transport for EAP,
> > >not a network discovery component. Mixing the semantics of
> protocols
> > >can lead to unintended consequences.
> > >2) Scheduling. Limiting detection time to a particular point
> > in the EAP
> > >or EAPoL message sequence will run counter to the goal of making
> > >detection swift and lightweight that serves the needs of wireless
> > >devices seeking low power operation and low duration handoffs.
> > >3) MTUs. Individual frames have limitations on size. The scope of
> > >handoff and network discovery related information is
> > potentially large.
> > >A standalone disovery protocol could address the proper
> > encapsulation
> > >of this in a straightforward way.
> > >4) Overlap with EAP. EAP is looking to add this feature into the
> > >semantics of the request-identity data field and this is
> > arguably the
> > >better place to do that sort of thing.
> > >5) Pragmatic. There is a motivated handoff group chomping at
> > the bit to
> > >write this spec. Doing it in 802.1aa would introduce
> > interdependencies
> > >with all the other 802.1aa work going on.
> > >
> > >LLDP is one of those mystery specs. I've never read it and
> > don't know
> > >if it's a good thing or not. My reading list is getting longer.
> >
> > _________________________________________________________________
> > Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or
> > Mary J Blige
> > using MSN Messenger http://entertainment.msn.com/imastar
> >
>