Subject: [eap] Issue 378: Network Selection Comments

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 08 Aug 2006 19:47:48 -0700

Issue 378: NetSel Comments
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date Submitted: August 8, 2006
Reference:
Document: NETSEL-04
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

Section 1

"  The realm discovery and selection problem affects network access and
   wireless access networks in particular.  This problem spans multiple
   protocol layers and has been the subject of discussions in IETF,
   3GPP, and IEEE.  This document summarizes the discussion held about
   this problem in the Extensible Authentication Protocol working group
   at IETF."

   The realm discovery and selection problem becomes relevant when any
   of the following conditions are true:"

The second and third sentences are more appropriate for the problem 
definition
section.  In this paragraph you need to set the stage.
Suggest this be changed to:

"  The realm discovery and selection problem affects network access and
   wireless access networks in particular.  Aspects of the problem will
   appear when any of the following situations arises:"

   o  There is more than one available network attachment point, and the
      different attachment points may have different characteristics or
      belong to different operators.  In the case of virtual operators,
      access network infrastructure including e.g. the access points can
      be shared by multiple operators.

[BA] I think you need to describe what issue will arise.
For example: "In order to choose between the network attachment points,
it may be helpful to determine which realms are supported and what the
capabilities of those realms are."

   o  The user has multiple sets of credentials.  For instance, the user
      could have one set of credentials from a public service provider
      and set from the user's employer.

[BA] I think you want to describe the issue that will arise.  For
example: "In this case it may be helpful to provide additional
information to enable the correct credential set to be determined."

Section 1.1

Realm Selection

      This refers to selection of the operator/ISP in order to access
      the network.  The process of realm selection can occur either at
      the beginning of a new session or during a handoff in case the
      user is mobile.  The selection is dependent upon for example the
      authentication credentials for the user / device and the roaming
      agreements.  The realm Selection can in turn also depend upon
      Access Technology Selection and/or Bearer Selection.

I am confused by this definition of "Realm Selection".  The realm used
in the NAI seems more related to "Identity Selection" as defined in
RFC 4284, rather than selection of the operator/ISP to connect to.
Do you mean "Identity Selection" here, or are we talking about choosing
which operator to connect to?

Section 2.1

          Typically different enrollment methods and organizational 
locations
          within ESSes advertise or respond to different SSIDs.

This does not make sense.  An ESS is compromised of a single SSID.  
Enrollment
methods are properties of the home realm, not the SSID.

Section 2.2

   Figure 1 illustrates a situation where the user does not know whether
   the access network he or she is attached to supports the realms he or
   she is attemping to authenticate with.  The access network 1
   interworks only with the ISP and the access network 3 interworks with
   the corporate network whereas the access network 2 interworks with
   both.

I think you are trying to say that realm reachability may vary by network.
I'd suggest you change this to:

   "Figure 1 illustrates a situation where the user realm may not be
   reachable from each potential access network.  Access Network 1
   only enables access to the realm "isp.example1.com" whereas
   Access Network 3 enables access to the realm "corp.example2.com"
   whereas Access Network 2 enables access to both realms."

   Perhaps the most typical case is a link layer that provides some
   information about the realms that are reachable before EAP or some
   other enrollment method is initiated.  For instance, in IEEE 802.11
   provides the SSID, though in some cases the client may not learn
   about all the SSIDs supported by the given access point without
   actively probing for additional SSIDs.  In IKEv2 [14], the identity
   of the responder (typically the security gateway) is provided as a
   part of the usual IKEv2 exchange.

   In order to use this information in deciding the right identity to
   use, the provided information has to either match with one of the
   client's home realms, or the client has to have some other knowledge
   that enables to link the advertised access network name and the home
   realm.  For instance, the client may be aware that his home realm has
   a roaming contract with a given access network.

This is confusing because link layers typically don't provide information
about realm reachability.  Suggest you rewrite to:

   "Where a fixed set of realms are always reachable from a given
   network, access network names can be used to infer realm
   reachability.  For example, IEEE 802.11 Access Points provide
   the SSID, though in some cases the station may not learn
   all the SSIDs supported by the given access point without
   probing for them.  In IKEv2 [14], the identity of the responder
   (typically the security gateway) is provided as a
   part of the IKEv2 exchange.

   To use this information for identity selection, the client has
   to match the access network name with the realm portion of a
   valid client identity.  For example, the client may be configured
   with the network access names that have roaming contracts with
   each of the client's home realms."

Section 2.3

This section lacks coherence.  I think what it needs to do is to provide
a discussion of source routing versus network routing, as well as the
inherent difficulties involved in determining realm reachability.

2.3.1  The Incomplete Routing Table Problem

   No dynamic routing protocols are in use in AAA infrastructure today.
   This implies that there has to be a device (such as a proxy) within
   the access network that knows how to route to different domains, even
   if they are further than one hop away, as shown in Figure 2.  In this
   figure, the user "[email-masked]" has to be authenticated through
   ISP 2, since the domain "c.example.com" is served by it.

Where is the rest of this section?

Section 2.4

I was expecting a discussion of the "Payload Routing" problem here, based
on the list of problems described in Section 2.  I think this section 
belongs
in a new section (a replacement section 3?)

Section 2.5

I was expecting a discussion of the "realm capability discovery" problem 
here.
This is quite an important problem, because realm capabilities can change at
any time and a NAS cannot know what they are before completing a AAA 
exchange
to determine them.

I think this material belongs in a new section (also in a replacement 
section 3?)

Section 2.6

I think you need to add a section on scalability issues.  For example, there 
is the issue of whether reachable realms are advertised to the client as in 
RFC 4284 or whether they are only furnished on request, as suggested by Glen 
Zorn.

Section 3

I would recommend moving all of Section 3-3.4 to an Appendix.

Also, terms such as "network discovery process", "network selection" and
"access network selection" are used repeatedly in this section without
being defined.

Section 3.2

"although if SSIDs are used, the maximum length of 32 octets per SSId may
provide somewhat better scaling."

Not sure I understand the point here; RFC 4284 does not support
SSID advertisements, only realm advertisements.

Section 3.3

The current network advertisement and selection is based in [12].

Do you mean [13] here?  RFC 4282 doesn't define network advertisement or
selection.

   Furthermore, the WLAN UE may manually trigger the network
   advertisement by using Alternative NAI in EAP Request/ Identity.  The
   Alternative NAI is guaranteed to be an unknown NAI realm throughout
   all 3GPP networks.

Suggest changing to the following:

   Furthermore, the station may manually trigger the network
   advertisement by using Alternative NAI in the EAP-Response/Identity.  The
   Alternative NAI is guaranteed to be an unknown NAI realm throughout
   all 3GPP networks.

4.1

"such as link-state AAA" -> "such as AAA"  (might or might not be a protocol
based on link-state advertisements)

5

      For example,
      IEEE 802.1ab enables network devices to announce themselves and
      provide information on their capabilities.

Not sure why this is any better than EAP identity selection since 802.1AB
only is accessible after authentication has completed.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap