eap Mailing List: Re: Issue 378: Network Selection Comments

[Bari, Farooq (farooq.bari]

See responses inline.

BR,

Farooq

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> Sent: Tuesday, August 08, 2006 7:48 PM
> To: eap [at] frascone.com
> Subject: [eap] Issue 378: Network Selection Comments
> 
> Issue 378: NetSel Comments
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.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."
> 
[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 "joe [at] c.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?
> 
> 
[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