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
>