Subject: [eap] Review of draft-ietf-eap-netsel-problem-03

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 25 Oct 2005 18:51:54 -0700

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@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?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap