Subject: [eap] review of netsel-05

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Feb 2007 16:49:10 +0200

First, there are some open issues in the issue tracker. I consider
issues 330-336 now mostly closed, based on the revisions in the new
drafts. Thanks. For issue 333 there is one small remaining thing,
noted below.

What is the situation with the other issues? They have
been made for previous revisions, have they been resolved
in -05?

I also re-read the document and noticed two small editorial
issues, also noted below.

But otherwise I think the document is ready. Ship it!

Parts remaining from issue 333:

>    Section 4 gives the conclusions
>    and some suggestions on how to proceed for the rest.
This should be: "Section 4 presents our conclusions."

Editorial:

>    discussion of the limitations of certain classes of solution,

s/solution/solutions/

> The solution ...

Multiple occurrences of this. I think the draft should
not assume that we have a single solution in this space.
Therefore, we should typically write "Solutions should
satisfy ... " as opposed to "The solution should satisfy ..."

_________________________________________________________________
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: Wed, 21 Feb 2007 09:47:07 -0800

I have resolved issues 330, 331, 332, 334, 335 and 336 as fixed in  
NETSEL-05.  I am assuming that 333 will be resolved in -06.

That still leaves Issues 374, 375, 376, 377, and 378 open.

Can the submitters of those issues look over the document and post whether 
their concerns have been resolved?

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-05.txt

>Jari Arkko said:

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Feb 2007 21:03:49 +0200

Bernard,
> their concerns have been resolved?

For 374, everything else is addressed except this:

- Page 15: "APs must support 802.1X pre-authentication (optional
in IEEE 802.11i) ". The year of this standard should be specified,
just like it is earlier in that sentence. What is meant here is
probably IEEE 802.11i-2004.
- Page 20: "solutions for problem of network selection" -- insert "the"
before "problem".
-Page 20: "more than one points" -- replace "points" with "point"

For 375, the ISP selection functionality no longer
appears to be in the PANA WG documents, so I
would suggest removing the relevant text from
this document.

376 through 378 are yours, Bernard.

Jari

---

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 21 Feb 2007 14:04:39 -0800

Regarding 375, I am attaching Ohba san's email on eap reflector from
last year that requested to disregard his previous email. So this issue
seems to be resolved.

Farooq Bari
 
[email-masked]
+1 425 580 5526

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, February 21, 2007 9:47 AM
> To: [email-masked]
> Subject: Re: [eap] review of netsel-05
> 
> I have resolved issues 330, 331, 332, 334, 335 and 336 as 
> fixed in NETSEL-05.  I am assuming that 333 will be resolved in -06.
> 
> Can the submitters of those issues look over the document and 
> post whether their concerns have been resolved?
> 
> >drafts. Thanks. For issue 333 there is one small remaining 
> thing, noted 
> >below.
> >
> >What is the situation with the other issues? They have been made for 
> >previous revisions, have they been resolved in -05?
> >
> >I also re-read the document and noticed two small editorial issues, 
> >also noted below.
> >
> >Multiple occurrences of this. I think the draft should not 
> assume that 
> >we have a single solution in this space.
> satisfy ... " as 
> >opposed to "The solution should satisfy ..."
> 
> 

Subject: Re: [eap] WGLC on EAP Network Selection Document
From: "Yoshihiro Ohba" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 20 Jul 2006 13:21:35 -0800

Please disregard my minor comment in my previous email.  I was
referring that NAP and ISP separate authentication to be removed from
PANA basic specification.  There was no discussion to remove the ISP
selection functionality in the PANA basic specification.
Sorry for my confusion.

Yoshihiro Ohba

On Thu, Jul 20, 2006 at 04:58:39PM -0400, Yoshihiro Ohba wrote:
> Hi,
> 
> The document looks good to me.
> 
> One minor comment on Section 3.1:
> 
> "
>    The PANA protocol [17] has a mechanism to advertise and select "ISPs"
>    through the exchange of the ISP-Information AVP in its initial
>    exchange.
> "
> 
> "
>    The use of
>    other network identifiers than domain names is also possible, for
>    instance the PANA protocol uses an a free form string and an SMI
>    Network Management Private Enterprise Code [17], or Mobile Network
>    Codes embedded in NAIs as specified in 3GPP.
> "
> 
> The description is true for the current version of PANA specification.
> However, the latest discussion in the PANA WG will make the network
> selection functionality be specified in a separate document other than
> specifying it in the PANA base specification.  
> 
> Best regards,
> Yoshihiro Ohba
> 
> 
> On Fri, Jul 14, 2006 at 07:04:28AM -0700, Bernard Aboba wrote:
> > No comments were received on the EAP Network Selection document during EAP 
> > WG last call.
> > 
> > This makes it difficult to tell whether this is because lots of people read 
> > it and could not find fault with it, or because few people read it.
> > 
> > Therefore in order to move the document forward, we are going to request 
> > that individuals who have read the document post to the list to indicate 
> > that they approve its publication.   If you have read it and have comments, 
> > please post these to the list as well.   In order to move forward, we will 
> > need at least 5 people (other than the authors and WG chairs) to indicate 
> > approval.
> > 
> > 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 21 Feb 2007 14:10:01 -0800

For 377, I am attaching email from myself where we agreed to make all
the changes requested in issue 377. To my recollection all of them were
implemented in ver 5 of the draft.
 
Farooq Bari
 
[email-masked]
+1 425 580 5526

> >opposed to "The solution should satisfy ..."

Subject: Re: [eap] Issue 377: Netsel NITs
From: "Bari, Farooq" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 7 Sep 2006 13:10:35 -0800

Agree to make all the changes listed in the issue.

BR,

Farooq

> Sent: Tuesday, August 08, 2006 7:45 PM
> To: [email-masked]
> Subject: [eap] Issue 377: Netsel NITs
> 
> Issue 377: Netsel NITs
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date Submitted: August 8, 2006
> Reference:
> Document: NETSEL-04
> Comment type: Editorial
> Priority: 1
> Section: Various
> Rationale/Explanation of issue:
> 
> Section 1
> 
> "which particular roaming relationship variation is used"
> 
> suggest changing this to:
> "the roaming relationship path in use."
> 
> Section 1.1
> 
> I think you need to add some definitions from RFC 4284:
> 
>    NAI             Network Access Identifier [RFC4282].
> 
>    Decorated NAI   An NAI specifying a source route.  See [RFC4282]
>                    Section 2.7 for more information.
> 
>    Realm       Realm portion of an NAI [RFC4282].
> 
> And some from RFC 4282:
> 
>    Network Access Identifier
> 
>       The Network Access Identifier (NAI) is the user identity
submitted
>       by the client during network access authentication.  In roaming,
>       the purpose of the NAI is to identify the user as well as to
>       assist in the routing of the authentication request.  Please
note
>       that the NAI may not necessarily be the same as the user's
e-mail
>       address or the user identity submitted in an application layer
>       authentication.
> 
>    Network Access Server
> 
>       The Network Access Server (NAS) is the device that clients
connect
>       to in order to get access to the network.  In PPTP terminology,
>       this is referred to as the PPTP Access Concentrator (PAC), and
in
>       L2TP terminology, it is referred to as the L2TP Access
>       Concentrator (LAC).  In IEEE 802.11, it is referred to as an
>       Access Point.
> 
>    Roaming Capability
> 
>       Roaming capability can be loosely defined as the ability to use
>       any one of multiple Internet Service Providers (ISPs), while
>       maintaining a formal, customer-vendor relationship with only
one.
>       Examples of cases where roaming capability might be required
>       include ISP "confederations" and ISP-provided corporate network
>       access support.
> 
> And some more from 802.11 terminology:
> 
>    Station (STA): A device that contains an IEEE 802.11 conformant
>    medium access control (MAC) and physical layer (PHY) interface to
the
>    wireless medium (WM).
> 
>    Access Point (AP): An entity that has station functionality and
>    provides access to distribution services via the wireless medium
(WM)
>    for associated stations.
> 
>    Basic Service Set (BSS): A set of stations controlled by a single
>    coordination function.
> 
>    Extended Service Set (ESS): A set of one or more interconnected
basic
>    service sets (BSSs) with the same Service Set Identifier (SSID) and
>    integrated local area networks (LANs), which appears as a single
BSS
>    to the logical link control layer at any station associated with
one
>    of those BSSs.
> 
>       This refers to a mechanisms that a node uses to discover
available
>       realms prior the realm selection takes place.
> 
> I can't parse the last half of the sentence.  Can we shorten this to:
> 
> "      This refers to a mechanisms that a node uses to discover the
realms
>        that are reachable from a given network."
> 
>       The selection will be dependent upon for
>       example the support for an access technology by the device and
>       availability of such access technology based networks.
> 
> Recommend we change this to:
> 
> "     The selection will be dependent upon the access technologies
supported
>       by the device and the availability of networks supporting those
>       technologies."
> 
> bearer type -> bearer types
> 
> Section 2.1
> 
> as proposed in IEEE 802.11k
> 
> Please include a reference:
> 
> [IEEE802.11k]
>           Institute of Electrical and Electronics Engineers, "Draft
>           Ammendment to Standard for Telecommunications and
Information
>           Exchange Between Systems - LAN/MAN Specific Requirements -
>           Part 11: Wireless LAN Medium Access Control (MAC) and
Physical
>           Layer (PHY) Specifications: Radio Resource Management", IEEE
>           802.11k, D4.1, July 2006.
> 
>           UAM
> 
> Please expand this (Universal Access Method).
> 
> Section 2.3
> 
>    Within the past IETF ROAMOPS WG, a number of additional approaches
> 
> Suggest changing to:
> 
>    Within the IETF ROAMOPS WG, additional approaches
> 
> Section 3.1
> 
> "The effects to handoff" -> "The effects on handoff"
> 
> Section 3.2
> 
> Recommend changing the title to "IEEE 802"
> 
> Section 3.3
> 
> "lets the user to choose the desired PLMN" -> "lets the user choose
the
> desired PLMN"
> 
> "or a Visited PLMN (VPLMN) is a roaming case" -> "or a Visited PLMN
(VPLMN)
> in the roaming case"
> 
> "both SSID- and EAP-based" -> "both SSID and EAP-based"
> 
> Section 4.1
> 
> "phone book approach hard." -> "phone book approach difficult."
> 
> Section 5
> 
> "seems hard given" -> "seems difficult given"
> 
> References
> 
>    [11]  Housley, R. and T. Moore, "Certificate Extensions and
>          Attributes Supporting Authentication in Point-to-Point
Protocol
>          (PPP) and Wireless Local Area Networks (WLAN)", RFC 3770,
>          May 2004.
> 
> this has been obsoleted by RFC 4334:
> 
>          Housley, R. and T. Moore, "Certificate Extensions and
>          Attributes Supporting Authentication in Point-to-Point
Protocol
>          (PPP) and Wireless Local Area Networks (WLAN)", RFC 4334,
>          February 2006.
> 
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 21 Feb 2007 14:19:31 -0800

on 378 we had some discussion on the reflector a while back and I am
attaching here the emails form that discussion. I think most of the
comments were addressed with only a couple of the areas where Bernard
needs to indicate if he is OK with our explanation.

Farooq Bari
 
[email-masked]
+1 425 580 5526

> >opposed to "The solution should satisfy ..."

Subject: Re: [eap] Issue 378: Network Selection Comments
From: "Bari, Farooq" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 8 Sep 2006 06:58:45 -0800

See responses inline.

BR,

Farooq

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 9:40 PM
> To: Bari, Farooq; [email-masked]
> Cc: 'Jari Arkko'; [email-masked]
> Subject: RE: [eap] Issue 378: Network Selection Comments
> 
>  [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.
> 
> [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.
> 
> 
[Bari, Farooq] I meant the first of the two. If others have the same
understanding we can change it to "selection of the realm used to access
the network".

> [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.
> 
> [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.
[Bari, Farooq] I do not think RFC 4284 mandated a behavior on the part
of the network that would imply that the client always gets the entire
list of roaming partners of the e.g. the hotspot operator. For example
it is possible that hotspot operator decides to advertise only top three
roaming partners etc. But such logic is not something that gets
standardized.

Subject: RE: [eap] Issue 378: Network Selection Comments
From: "Bernard Aboba" <[email-masked]>
To: "Bari, Farooq" <[email-masked]>, <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>, <[email-masked]>
Date: Thu, 7 Sep 2006 20:40:03 -0800

 [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.

[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. 

[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.

[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. 

Subject: Re: [eap] Issue 378: Network Selection Comments
From: "Bari, Farooq" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 7 Sep 2006 13:51:31 -0800

See responses inline.

BR,

Farooq

> Sent: Tuesday, August 08, 2006 7:48 PM
> To: [email-masked]
> Subject: [eap] Issue 378: Network Selection Comments
> 
> Issue 378: NetSel Comments
> Comment type: Technical
> Priority: S
> "  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.

Subject: [eap] Issue 378: Network Selection Comments
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Date: Tue, 8 Aug 2006 18:47:48 -0800

Issue 378: NetSel Comments
Comment type: Technical
Priority: S

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.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Feb 2007 15:26:38 +0200

But latest PANA document (ietf-pana-pana) no longer
has ISP-Information or NAP-Information, so I think
further developments have changed the situation
again. Here's the edit:

Remove text:

   The PANA protocol [I-D.ietf-pana-pana] has a mechanism to advertise
   and select "ISPs" through the exchange of the ISP-Information AVP in
   its initial exchange.

Change text

   The use of other network identifiers
   than domain names is also possible, for instance the PANA protocol
   uses an a free form string and an SMI Network Management Private
   Enterprise Code [I-D.ietf-pana-pana], or Mobile Network Codes
   embedded in NAIs as specified in 3GPP.

=>

   The use of other network identifiers
   than domain names is also possible.

And remove the reference too.

Jari

>> ------------------------------------------------------------------------
>>

---

From: "Bari, Farooq" <[email-masked]>
Date: Fri, 23 Feb 2007 13:10:33 -0800

Proposed resolution is OK for me.

Farooq Bari
 
[email-masked]
+1 425 580 5526

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, February 23, 2007 5:27 AM
> To: Bari, Farooq
> Cc: Bernard Aboba; [email-masked]
> Subject: issue 375 (Was: Re: [eap] review of netsel-05)
> 
> But latest PANA document (ietf-pana-pana) no longer has 
> ISP-Information or NAP-Information, so I think further 
> developments have changed the situation again. Here's the edit:
> 
> Remove text:
> 
> > last year that requested to disregard his previous email. So this 
> > issue seems to be resolved.
> >
> >  
> > Farooq Bari
> >  
> > [email-masked]
> > +1 425 580 5526
> >  
> >  
> >   
> 
> >   
> >> Can the submitters of those issues look over the document and post 
> >> whether their concerns have been resolved?
> >>
> been made for