eap Mailing List: Re: review of netsel-05

[Bari, Farooq (farooq.bari]

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
 
farooq.bari [at] att.com
+1 425 580 5526
 
 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Wednesday, February 21, 2007 9:47 AM
> To: eap [at] frascone.com
> 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.
> 
> 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-prob
> lem-05.txt
> 
> >Jari Arkko said:
> 
> >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
> 
> --- Begin Message ---
> See responses inline.
>
> BR,
>
> Farooq
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:Bernard_Aboba [at] hotmail.com]
> > Sent: Thursday, September 07, 2006 9:40 PM
> > To: Bari, Farooq; eap [at] frascone.com
> > Cc: 'Jari Arkko'; jouni.korhonen [at] teliasonera.com
> > 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.
>
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap
>
> --- End Message ---
> --- Begin Message ---
>  [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. 
>
>
>
>
> --- End Message ---
> --- Begin Message ---
> 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
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
>
> Arhives: http://lists.frascone.com/pipermail/eap
>
> --- End Message ---
> --- Begin Message ---
> 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."
>
> 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 "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?
>
>
> 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
>
> --- End Message ---