Issue 378: Network Selection Comments

Issue 378: NetSel Comments
Submitter name: Bernard Aboba
Submitter email address: abobainternaut.com
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 "joec.example.com" 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

Issue 378: Network Selection Comments

Thread: Issue 378: Network Selection Comments