eap Mailing List: Review of draft-ietf-eap-netsel-problem-03

[Bernard Aboba (bernard_aboba]

Review of draft-ietf-eap-netsel-problem-03

Section 2

Finally, there is the the problem of "Payload routing" which

"the the" -> "the"

Section 2.1

  A number of enhancements have been proposed to the Beacon/Probe
  Response mechanism in order to improve scalability and roaming
  performance.  These include allowing APs to announce capabilities of
  neighbor APs as well as their own, as proposed in IEEE 802.11k;
  propagation of discovery information over IP, as handled in the CARD
  protocol developed within the IETF SEAMOBY WG, etc.

One of the recently proposed extensions that probably should be mentioned
here is the ability to support "hidden" SSIDs -- that is, SSIDs which
can be queried in a Probe Request, but are never announced in a Beacon.

Support for "hidden" SSIDs,  has already been widely implemented.  However, 
current support is problematic because a host does not know if an AP 
supports "hidden" SSIDs or not so that it will send unnecesary probes.  In 
proposals under consideration within IEEE 802.11 this issue is addressed.  
Overall, support for "hidden" SSIDs allows a single AP to support dozens or 
even hundreds of SSIDs.

"   Figure 1 illustrates a situation where the user does not know whether
  he is connected to access network 1, which only serves the ISP,
  access network 3, which only serves the company, or access network 2,
  which serves both."

I might add that "this situation is common with link layer protocols
which do not provide discovery facilities, such as IEEE 802 LANs."

"  Finally, some EAP implementations use the space after the NUL
  character in an EAP Identity Request to communicate some parameters
  relating to the network requesting EAP authentication.  While there
  is Standards Track RFC specifying the interpretation of the field
  beyond the NUL character, [I-D.adrangi-eap-network-discovery] is
  widely expected to be used."

I would change this to:

"  Finally, some EAP implementations use the space after the NUL
  character in an EAP Identity Request to communicate some parameters
  relating to the network requesting EAP authentication.  The use of
  this facility for the purpose of specifying supported NAI realms is
  specified in [I-D.adrangi-eap-network-discovery]."

Section 2.3

  Within the IETF ROAMOPS WG, a number of additional approaches were
  considered for this, including source routing techniques based on the
  NAI, and techniques relying on the AAA infrastructure.  Given the
  relative simplicity of the roaming implementations described in RFC
  2194 [RFC2194], static routing mechanisms appeared adequate for the
  task and it was not deemed necessary to develop dynamic routing
  protocols.

One of the effects of this which is just now becoming appreciated is that 
because it does not participate in any realm routing protocol, a local AAA 
proxy may not know what realms are supported by  downstream proxies with 
whom it communicates.  These local routers, like access routers, typically 
only hold a set of routes along with the default, and unlike core proxies or 
routers
do not have complete knowledge of the realm routing table.

Therefore, just as a "ping" will typically not return an  "ICMP network 
unreachable" error until it hits a core router, an Access-Request destined 
to an unroutable realm will often be forwarded until it encounters a 
"default free" proxy that  returns a realm hint as specified in 
draft-adrangi.

The implication of this is that there may be no easy way for a NAS to 
dynamically determine whether a given NAI realm is reachable or not.  The 
implication is that schemes which probe a NAS about its NAIRealms support 
(such as via a Probe Request) may require that the NAS send a "ping" 
Access-Request with a User-Name of "anonymous [at] realm" in order to determine 
if the realm is reachable.  This kind of request is explicitly called out as 
a bad idea in RFC 2865 Section 2.6 "Keepalives Considered Harmful."

I'd suggest that some discussion along these lines be included in  Section 
2.3.1.

Section 4.2

I'd rename this "IEEE 802"

Also, I believe there are a number of new proposals that deserve further
discussion here, such as the proposals for "hidden" SSIDs.

Section 5

     Work is already underway in IEEE 802.1, IEEE 802.21 and the IEEE
     802.11u to provide enhanced discovery functionality.  For example,
     IEEE 802.1ab enables network devices to announce themselves and
     provide information on their capabilities.

Unfortunately IEEE 802.1ab announcements are only allowed *after*
IEEE 802.1X authentication has been completed.  Therefore .1AB
is not relevant to the discovery problem.

7.1 Normative References

This is an Informational RFC -- should it have normative references?

7.2 Informative References

  [I-D.adrangi-eap-network-discovery]
             Adrangi, F., "Mediating Network Discovery in the
             Extensible Authentication Protocol  (EAP)",
             draft-adrangi-eap-network-discovery-14 (work in progress),
             August 2005.

  [I-D.adrangi-eap-network-discovery-and-selection]
             Adrangi, F., "Network Discovery and Selection within the
             EAP Framework",
             draft-adrangi-eap-network-discovery-and-selection-01 (work
             in progress), March 2004.

Do we need to reference both of these?