RE: FW: [LinkSec] updated handoff presentation
Bernard,
Yes, yes and yes.
The working model for 802 handoff is another entity on the uncontrolled
port and one on the controlled if there's a policy in place to
differentiate services available through the entities based on port
status. So discovery can happen before EAPoL. This sounds like another
ethertype to me but I'll defer to 802.1 on what the options are there.
We had much the same discussion on the last linksec conference call.
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: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> Sent: Thursday, August 28, 2003 3:56 PM
> To: Johnston, Dj; 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
>
>