[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [eap] Review of the IEEE 802.11u Requirements Document
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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>