RE: [eap] Review of the IEEE 802.11u Requirements Document

["Bernard Aboba" <[e-mail]>]

During the review of 'EAP Network Selection' questions arose about the 
backend implications on protocols such as RADIUS, as well as the EAP side of 
things.  Since 'EAP Network Selection' was considered a short term solution, 
it was not considered to extend it to handle additional parameters such as 
'cost'.

Yet the requirements document seems to make an architectural assumption that 
solutions such as 'EAP Network Selection' are available, and can be used to 
allow the AP to discovery properties of downstream realms.   This is of 
concern since it would be basing the long term solution on what was 
originally considered to be a short-term fix.

Rather than making architectural assumptions that may or may not be 
required, it may make moe sense to focus on the requirements that are truly 
fundamental such as scalability.

For example, if a proposal could meet the scalability requirements, allowing 
a STA to connect to hundreds or even thousands of SSIDs, then it might be 
possible for each NAI realm to have its own SSID.  This considerably 
simplifies the architecture, and gets around some very thorny problems that 
are created by 'EAP Network Selection'.


>[Mike Moreton] When a problem is best solved by a multi-layer
>solution there's always going to be a chicken and egg type
>problem.  I don't believe 802.11u is trying to solve the complete
>problem - just to "do our bit".
>
>I think everyone in 802.11u is hoping that "someone else" will do
>the bits required at other layers - it's clearly not
>desirable for the AP to have the information to answer such a
>query (other than perhaps by caching).  But we can't start
>liaising with other organisations until we have accepted a
>proposal, and hence know what is needed. In case anyone
>reading this thinks that 802.11u will be useless without such a
>higher layer I guess I should say the following.  I would
>expect most proposed solutions to our requirements could work
>in limited scenarios by hard configuration of the APs, or by
>proprietary protocols.  So 802.11u is still useful in that case -
>but to gain its full utility we need someone else to develop
>open backend protocols.

I think the question arises as to how the "backend protocol" would be 
expected to work.  As mentioned earlier, NAS devices are not expected to 
participate in the realm routing mesh, so that there really is no effective 
way for them to obtain a full realm routing table from downstream proxies.  
This is a fundamental aspect of the architecture, not just a limitation of 
current technology.

During IETF 64, it was suggested that the AP could forge 
EAP-Response/Identity packets in order to obtain "realm hints" as specified 
by 
http://www.watersprings.org/pub/id/draft-adrangi-eap-network-discovery-14.txt.

This raised a number of concerns, such as the potential for unauthenticated 
users to do a DoS attack on the AAA infrastructure.  Some of the cautions 
included in RFC 2865 Section 2.6 may apply here:

2.6.  Keep-Alives Considered Harmful

   Some implementers have adopted the practice of sending test RADIUS
   requests to see if a server is alive.  This practice is strongly
   discouraged, since it adds to load and harms scalability without
   providing any additional useful information.  Since a RADIUS request
   is contained in a single datagram, in the time it would take you to
   send a ping you could just send the RADIUS request, and getting a
   reply tells you that the RADIUS server is up.  If you do not have a
   RADIUS request to send, it does not matter if the server is up or
   not, because you are not using it.

   If you want to monitor your RADIUS server, use SNMP.  That's what
   SNMP is for.

> > Much as an Internet host determines whether another host is
> > reachable by sending an IP packet to it, a network peer
> > determines whether it can authenticate to a realm by
> > attempting to communicate with it.  If a peer attempts to
> > authenticate to an unreachable realm, the problem may not be
> > diagnosed until the request has traversed a core proxy with
> > full knowledge of the realm routing table, much as a "ping"
> > may not generate an ICMP network unreachable message until
> > the request has reached a core router.
> >
> > As a result, it appears that much of the functionality
> > required by IEEE 802.11u cannot be provided in situations
> > where a single SSID is used to access an indetermine number
> > of NAI realms.  In such situations,
> > the AP cannot easily obtain the required information relating
> > to the availability and capabilities of reachable realms.
> >
> > The problem would be more tractable were IEEE 802.11u to
> > focus on development of a more scalable "Virtual AP" model
> > for IEEE 802.11.  In such a model, a determinate number of
> > NAI realms (perhaps only one) would correspond to an SSID,
> > enabling the AP to be preconfigured with the capabilities
> > associated with each configured SSID.  This would enable the
> > communication of available "Virtual APs" and capabilities to
> > the STA without relying on facilities which are difficult for
> > EAP or the AAA infrastructure to provide.
> >
>
>[Mike Moreton] One of the things there seems general agreement within
>802.11u over is that we have to avoid the multiple SSID situation
>- it just isn't scalable enough.
>I'm also not sure how having multiple SSIDs, each of which
>mapped to a single NAI would actually be any easier than just
>having multiple NAIs.

[BA] I'd suggest that scalability be considered as one of the requirements.  
As I understand it, there are proposals on the table (including support for 
'hidden SSIDs', multiple SSIDs/Beacon, etc.) that would improve scalability.

>[Stephen McCann] Looking ahead to carrier grade 802.11 access networks,
>I don't see how the mapping of SSIDs and NAIs can be managed, especially
>if 'virtual realms' are introduced.

Question:  What is a 'virtual realm'?

> > R8E1 - Required
> >
> > "Define functionality by which the STA is able to determine
> > what online enrolment (also called online subscription)
> > methods are supported by the network"
> >
> > In large scale roaming deployments, an AP will typically not
> > have knowledge of all the potential roaming realms which
> > customers may be able to authenticate to.  For example, an AP
> > typically is not configured with a realm routing table, but
> > just a "default route" to the local AAA proxy or server.  The
> > local AAA proxy in turn may also be configured with a "default route".
> >
> > As a result, the AP may not know what realms are available,
> > nor may it have information on the services (such as
> > enrollment) provided by those realms.  The AP may not be able
> > to inform the STA whether online enrollment is supported by a
> > realm, or even if a realm is reachable by the STA.
> >
> > Note that this problem cannot be solved by introduction of a
> > "realm routing" protocol, since it would be unlikely that
> > such a protocol would
> >
> > be supported by an AP, or even a local AAA proxy.  Due to the
> > memory and
> >
> > CPU requirements, it would be likely to only be supported
> > on "core proxies", much as BGP is only run on core routers.
> >
> > As a result, an AP can only be presumed to have knowledge of
> > a realm if that realm is configured into the AP, potentially
> > as a "Virtual AP".
>
>[Mike Moreton] I think the core assumption within
>802.11u is that the user device knows the identity (NAI etc) of
>the network it wants to connect to.  When considering
>enrolment, it's easy enough for the device to discover the
>identity of the local network, so enrolment with the local
>network should not be a problem.  As you say, enrolment with
>remote networks would be challenging, but I'm not sure anyone
>was imagining that case when the requirement was written.

There is an important distinction between a 'network' and a 'realm'.  An NAI 
realm is used to identify the home AAA server that the user authenticates 
to.  As a result of that authentication and subsequent authentication, the 
user offered access.  The parameters of that service may include tunneling 
(RFC 2868), VLAN tagging (RFC 3580), or more advanced VLAN processing 
(VLAN/Priority attributes draft).  However, users in different realms may 
receive the same service, and thereby may be able to access the same 
network.  So 'network' and 'realm' are really orthogonal concepts.

> > Where a single physical or virtual AP is configured to enable
> > access to multiple realms, the only way a STA can determine
> > whether the realm supports an enrolment method is via an EAP
> > exchange with that realm.
> >
> > While a partial solution is provided within "Identity
> > selection hints for EAP"
> > http://www.watersprings.org/pub/id/draft-adrangi-eap-network-d
> > iscovery-14.txt
> > this solution requires the STA to associate with an AP prior
> > to discovering the supported realms.
> >
> > As a result, where an indetermine number of realms are
> > reachable via a single "Virtual AP", the requirement
> > specified in R8E1 may not be satisfiable by an exchange
> > occurring solely within IEEE 802.11.
> >
> > R8E2 - Optional
> >
> > "Define functionality for online enrolment"
> >
> > During the recent EMU BOF, there was discussion of enrolment
> > support within EAP.  Rohan Mahy has submitted a draft on this
> > subject:
> > http://www.watersprings.org/pub/id/draft-mahy-eap-enrolment-00.txt
> >
> > This would support the document's assertion that "a solution
> > may be outside the scope of this task group".
> >
> > However the current EMU WG Charter does not include a work
> > item on enrolment.
>
>[Stephen McCann] Rohan previously has presented some interesting
>material in 802.11u and I suggest that 802.11u reviews this draft, to 
>identify
>any useful ideas.

Since EMU is not being chartered to handle this work, if 802.11u has 
identified a need for this, then it would be appropriate to communicate that 
need.

> > R8E4 - Optional
> >
> > "Functionality shall be provided by which APs can advertise (before
> > connection) the charges that will be made for use of the
> > network if a user enrolls with it."
> >
> > The charges associated with access to a realm may vary not
> > only with the realm but also with the path by which the realm is 
>accessed
> > -- the "decorated NAI". Since charges may also vary by time
> > of day or day of the week, the information required to fully
> > inform the STA may be quite complex.
> >
> > For the reasons described in R8E1, an AP may not know the
> > realms accessible from within a given "Virtual AP", or the
> > charges associated with access to that realm via any path, at
> > any time.
> >
> > Since neither EAP nor AAA provides a mechanism for
> > communication of charges, it is not clear how this
> > requirement can be satisfied other than by manual
> > configuration of an AP.
> >
> > We concur with the document characterization of this
> > requirement as "optional".
> >
> > R8N1 - Required
> >
> > "Define functionality by which a STA can determine whether
> > its subscription to an SSPN would allow it to access a
> > particular 802.11AN before actually joining a BSS within that
> > 802.11 AN. Proposals must describe their consideration of
> > scalability."
> >
> > As described in the analysis of R8E1, where a single
> > physical/virtual AP
> >
> > provides access to an indetermine number of realms an AP may
> > not know what realms are accessible from a given "virtual
> > AP".  As a result, the AP may not have the information
> > available to satisfy this requirement.
>
>[Mike Moreton] My assumption is that this information would either
>be hard configured into the AP (not desirable) or that the
>query would be passed on to some other device using some
>protocol designed by another standards organisation (much more
>desirable).

As noted above, at IETF 64, there was concern expressed about the security 
aspects of proposals for the 'other protocol'.

> > R8N2 - Required
> >
> > "The mechanism described in requirement R8N1 must allow a STA
> > that has multiple credentials with an SSPN to select the
> > correct credentials when authenticating with a Local Network."
> >
> > For a STA to select the correct credentials, it needs to be
> > aware of the realms available to it, as well as the EAP method to be 
>used
> > with the desired realm. Once a STA has enrolled in a realm,
> > it presumably is configured with the EAP method to be used
> > for that realm, so that the problem comes down to determining
> > which realms are available.
> >
> > Therefore the issues inherent in realm discovery (see R8E1)
> > are applicable to this requirement as well.
>
>[Mike Moreton] I've never quiet understood this requirement, but my
>assumption is that the response to a "Do you provide connection
>to this NAI?" question would also include an optional field
>that could be used to indicate the realm within the network
>indicated by that NAI.  How that information gets to the AP
>is again out of our scope.
>
> > R8N3 - Required
> >
> > "Define functionality to support authentication with multiple
> > SSPNs through a single AP."
> >
> > That document indicates that "Its not acceptable to require a
> > separate "virtual" AP for each SSPN", but does not provide
> > more detail on how this statement was arrived at.  Certainly,
> > existing "Virtual AP" mechanisms do not scale much beyond a
> > dozen "Virtual APs" per physical AP.  However, recent
> > submissions within IEEE 802.11 appear to be aimed at removing
> > those limitations, by enabling multiple "Virtual APs" to be
> > supported within a
> >
> > single Beacon/Probe Response, as well as by enabling support
> > of "hidden virtual APs" that are not advertised.
> >
> > It would therefore appear that in the long term it may be
> > possible to remove many of the "virtual AP" scaling limitations.
> >
> > It is suggested that IEEE 802.11u re-examine whether R8N3 is
> > really required.
>
>[Mike Moreton] I think the consensus within 802.11u has
>always been that we're willing to consider any proposal that
>solves the problem, even if that proposal is "Don't do
>anything - it's already solved elsewhere".  The notes are
>meant to be explanatory of the requirement and are not
>limiting. But some of the 802.11u contributors are keen to
>support architectures where 100s of different home networks
>can be accessed - this is way beyond what can be achieved by
>putting multiple SSIDs in the same beacon (and would in any
>case have the sort of configuration issues you describe earlier).
>
>[Stephen McCann] Again Mike is referring to 'carrier grade'
>installations, which some members of 802.11u are very concerned about.
>
> >
> >
> > R8N5,  R8N6 - Optional
> >
> > The issues described with respect to R8E4 apply here as well.
> > We concur with the characterization of this requirement as "optional".
> >
> > R8N7 - Not Required
> >
> > "It should be possible to inform a STA about unbroadcasted
> > SSIDs without
> >
> > causing the STA to probe for each preferred SSID."
> >
> > Unbroadcasted or "hidden" SSIDs are one mechanism by which
> > the scalability of 802.11 advertisement mechanisms may be
> > improved.  In a large scale roaming deployment, presumably
> > many of the SSIDs would be "hidden", since even support for
> > multiple "virtual AP" advertisements per Beacon might not be
> > sufficient.
> >
> > Since a "hidden" SSID is by definition not advertised, a
> > Probe Request/Response exchange is typically necessary to
> > determine whether it
> >
> > is supported.  If a STA has multiple SSIDs in its preference
> > list which could conceivably be "hidden" then it is not clear
> > how it can determine whether they are present without probing
> > for them.
> >
> > We concur with the document characterization of this
> > requirement as "not required".
>
>[Stephen McCann] For readers not familiar with 802.11u, Bernard
>correctly states that this requirement is now out of scope of 802.11u.
>However, for historical reasons we have kept it in our requirements
>document.

I do think that the topic of 'hidden SSIDs' is worth investigating though, 
because this does address many of the Beacon scalability issues that lead to 
the development of draft-adrangi-eap-network-discovery.  That document was 
understood at the time to be an interim solution that would be superceded by 
a better solution developed within IEEE 802.11u.

Because it was supposed to be an 'interim solution', draft-adrangi did not 
deal with issues such as caching/TTL, addition of parameters such as cost, 
etc.  During the discussion of draft-adrangi, there was concern about going 
down that road. So if the 'long term' solution will now rely on 
draft-adrangi, and attempt to introduce extensions that were considered out 
of scope (cost, TTL, etc.), then I think that would be a cause for concern, 
along with allowing 'realm discovery' to be triggered by an unauthenticated 
Probe Request.

> > R8P2 - Required
> >
> > "Define functionality to prevent hijack of MAC addresses."
> >
> > RFC 4017 requires EAP methods supporting "mutual
> > authentication" and "key derivation" so that a STA supporting
> > IEEE 802.11i can determine whether an AP to which it has
> > associated has been authorized by the AAA server.
> >
> > RFC 4017 also includes "Channel Binding" as an optional
> > security claim. Among other things, support for channel
> > bindings enables a STA to check with the AAA server whether
> > an AP is impersonating another AP to the STA.
> >
> > More recently, IEEE 802.1ar "Secure Identity" has been
> > chartered in order to enable verification of ownership of MAC
> > addresses.
> >
> > Therefore there appears to be work in progress relevant to
> > this requirement.
>
>[Mike Moreton] Good!  If we can reference other
>people's work then I'm all in favour of it.  We need to keep
>it as a requirement even if that will end up being the case.
>Note that there are also traffic segmentation solutions to
>this problem that may be equally beyond our scope.
>
> >
> > R8A1 - Required
> >
> > "A STA shall be able to authenticate with different SSPNs
> > simultaneously, in order to gain simultaneous access to
> > multiple Destination Networks."
> >
> > Simultaneous access to multiple wireless networks has been
> > demonstrated using existing standards:
> > http://research.microsoft.com/~bahl/MS_Projects/MultiNet/default.htm
> >
> > As a result, new functionality may not be required to satisfy
> > this requirement, if a scalable "Virtual AP" model is
> > available.
>
>[Mike Moreton] And if we come up with a proper solution to
>the MAC address anonymity problem it may be impossible to
>prevent the STAs doing this.  Note that some operators have a
>big issue with this requirement.
>
> > R8I1 -  Required
> >
> > "Define IEEE 802.11TM functionality which would be required
> > to support an Emergency Call (e.g. E911) service as part of
> > an overall, multi-layer solution. Specifically: Capability
> > Advertisement Authentication issues"
> >
> > Multiple IEEE 802 groups have already become involved in the
> > specification of Emergency Service capability -- IEEE
> > 802.11k, 802.11v, 802.1AB (via TIA LLDP MED), raising
> > questions about the overall coherence of the
> >
> > effort, let alone compatibility with the work of IETF WGs
> > such as ECRIT and GEOPRIV.
> >
> > IEEE 802.11u may therefore wish to consider whether addition
> > of another group will help or hinder the effort to develop a
> > coherent Emergency Services architecture.
>
>[Mike Moreton] 802.11 WG is
>co-ordinating the work of the various 802.11 task groups
>interested in the Emergency Call Service.  A final decision
>has not yet been taken whether to place the bulk of this work
>within 802.11u or 802.11v but I can assure you that the
>intention is definitely not to have competing solutions.  The
>802.11k contribution is likely to be limited to provision of
>location information, and hence will be part of the overall
>solution rather than an alternative solution.
>
>[Stephen McCann] Specifically 802.11u feels that it should address
>the network advertisement of emergency call capability and
>subsequent admission control issues, as these are essentially
>interworking issues. It will not consider any location requirements.



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>