RE: FW: [LinkSec] updated handoff presentation
We have examples of previous protocols that have solved this problem (e.g.
802.11 Beacon/Probe Response, PPPOE Discovery) without the need for reliable
transport, or even exceeding the MTU of a single packet, and so I'd argue
that we start from the presumption that this should not be necessary.
Exercising some level of restraint is particularly dangerous since when
neighbor capabilities are included in advertisements, the size of the packet
can scale with the *square* of the capabilities added to it.
That said, the case for some of the capabilities included below is good--
most are already present in IEEE 802.11 or are being proposed. For example,
authentication/crypto services and QoS capabilities are already included by
IEEE 802.11i and IEEE 802.11e so there is some justification to including
these -- provided that we don't go overboard.
Channel recommendations are of some value because they can reduce the scan
time, particularly if the recommendations reflect operational
authenticators, allowing the station to avoid rogues.
Neighbor lists are of some value. They increase the effectiveness of
pre-authentication. However, they also potentially increase the size of the
advertisement, particularly if neighbor capabilities are also included, as
they need to be if the intention is to inform a pre-auth decision.
I see some value in including subnet information -- to a point. Since VLAN
assignment can be dynamic, the actual VLAN assigned may not be known until
after authentication. Therefore an advertisement can only hint at what
prefixes might be available -- but cannot actually guarantee availabilty to
the host, even if it successfully authenticates. So there is some value in
prefix advertisement in network discovery, but only as a "strong hint" for
subsequent Detection of Network Attachment.
I'm neutral on Location Information.
I'd argue against several of the capabilities on the list.
I don't think it's appropriate to use network discovery for the purpose of
advertising products or services. The focus should be on informing the
roaming decision.
It is up to the host to determine the validity of IP addresses that it
obtains on visited networks. Some hosts will retain leases that they
acquired until they expire; others discard those leases when they change
subnets. There is no way for the AP/Authenticator to know what choice a
given host has made. Since the host either knows or has discarded
information on the leases it has, there is no need for this information to
be sent in a discovery announcement or response.
I'd also argue that pricing information is not relevant in a network
discovery advertisement. In order to provide security some kind of signup
process is required in which credentials are established and the host can be
authenticated in the future. At that time, the user can peruse the charging
information in some depth and agree to the service terms. Attempting to
stuff all of this information (could be a substantial license agreement)
into a network discovery advertisement is neither necessary nor appropriate.
I'd also argue that exhaustive information on "roaming agreements" is
unnecessary. Given that the host has a pre-existing relationship with a set
of providers, those providers can provide the host with a list of roaming
agreements. All that is necessary is that the Authenticator advertise the
basic set of networks (first tier) that it supports.
>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)
_________________________________________________________________
Help protect your PC: Get a free online virus scan at McAfee.com.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963