Subject: Re: [eap] Issue 378: Network Selection Comments

From: "Bari, Farooq" <[email-masked]>
Date: Thu, 7 Sep 2006 14:51:31 -0700

See responses inline.

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, August 08, 2006 7:48 PM
> To: [email-masked]
> Subject: [eap] Issue 378: Network Selection Comments
> 
> 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."
> 
[Bari, Farooq] Agree to changes in the first para. Agree to changes in
the first two bullets (already covered in issue 376).

> 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?
> 
> 
[Bari, Farooq] Propose to change the first sentence as follows

This refers to selection of the realm of an operator/ISP in order to
access the network.

> 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.
> 
[Bari, Farooq] Propose deleting the sentence.

> 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."
> 
[Bari, Farooq] Agree to the change. Agree to fix example per Jari's
comment as well.

>    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."
> 
[Bari, Farooq] Agree to the proposed change.

> 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?
> 
> 
[Bari, Farooq] This section has been commented on in issue 376 as well.
Will get back to you on it (or pls post any proposed text on it).

> 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?)
> 
[Bari, Farooq] Pls see my comments on "payload routing" and about
proposal to delete section 2.4 in issue 376 response.

> 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?)
> 
[Bari, Farooq] Agree to change the title of the section to "realm
capability discovery" although the term realm does not seem right and
network might be better (any preferences?).

> 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.
[Bari, Farooq] In issue 376 response we agreed to add a new section on
scalability in current section 4. I am not sure if this needs to be
added in section 2. The comment about RFC 4284 behavior does not seem to
be correct - my understanding is that the realms are not always
advertised to the client.

> 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.
> 
[Bari, Farooq] Agree to the proposed Annex  I think with the proposed
addition of a sentence in section 1 about realm and network discovery
(as indicated in response for issue 376), the current terminology in
proposed appendix can be kept.

> 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.
> 
[Bari, Farooq] Jari also had comment on it. Pls response to his issue
that proposes to delete this sentence.

> 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.
[Bari, Farooq] Agree to the correction.

>    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.
>
[Bari, Farooq] agree to the change
 
> 4.1
> 
> "such as link-state AAA" -> "such as AAA"  (might or might not be a
protocol
> based on link-state advertisements)
> 
[Bari, Farooq] agree

> 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.
> 
> 
[Bari, Farooq] Propose to delete the sentence.
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 7 Sep 2006 21:40:03 -0700

[BA] The problem is that the realm need not necessarily be provided by the
operator/ISP.  It could be a corporate realm, for example.   So you might
just say either "selection of the realm used to access the network" or
"selection of the operator/ISP used for network access".  The problem is
that I don't know which is meant here -- and they are different. 

[BA] Right -- realms may not always be advertised.  But the issue occurs
when they need to be.  Glen's point was that RFC 4284 dumps the realm table,
most of which the client won't be able to use.  In contrast, a
request/response protocol would only return those realms that the client
indicates that it can access.  This is not only more efficient, but also
potentially addresses security concerns about exposing the realm table to
non-authorized users.