Subject: [eap] FW: [Fwd: Re: Issue 376: Proposed Resolution (Section 1.1)]

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 28 Feb 2007 02:57:18 -0800

For some reason Jouni's emails did not get posted to the reflector. I am
attaching them here.

BR,

Farooq Bari
[email-masked]
+1 425 580 5526
 
-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 10:47 PM
To: Bari, Farooq
Subject: [Fwd: Re: [eap] Issue 376: Proposed Resolution (Section 1.1)]

Subject: Re: [eap] Issue 376: Proposed Resolution (Section 1.1)
From: "Jouni Korhonen" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 26 Feb 2007 13:55:00 -0800

Hi Bernand,

Thanks a lot for proposing these corrections/enhancements. I have few 
comments inline.

Bernard Aboba kirjoitti:
>    Decorated NAI
> 
>       A NAI specifying a source route.  See RFC4282 [RFC4282] Section
>       2.7 for more information.
> 
> [BA] "RFC4282" -> "RFC 4282"
> 
>    Realm
> 
>       Realm portion of an NAI [RFC4282].
> 
> [BA] Change to "The realm portion of..."
> 
>    Network Selection
> 
>       This refers to selection of an operator/ISP in order to access the
>       network.  The process of network 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 selection
>       of realm for the operator, 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.
> 
> [BA] I don't understand how network selection can occur at the beginning
> of a session -- doesn't it need to occur before the session begins?

I think the above original text should mean "before the session begins".

> Also, I don't understand how network selection can occur during an L2

I think the intention was to say that once the mobile is about the make
a L2 handoff it may search for new potential networks where to attach 
to. The handoff process basically has started prior the L2 handoff
has been initiated. But yes, it is not 'during' the handoff.

 > handoff.  The "realm" of an operator doesn't make sense -- isn't a
> realm is a characteristic of the home AAA server? Suggest rewriting to:

Depending on the actual access technology or roaming arrangement the 
realm encodings/formats of the NAI might be different even if they 
eventually point to the same operator and to the same AAA. We already 
have seen this kind of deployments.

>       Selection of an operator/ISP for network access.  Network Selection
>       occurs prior to network access authentication.

The new proposed text is actually enough imho.

>    Network Discovery
> 
>       This refers to a mechanisms that a node uses to discover available
>       networks prior the realm selection takes place.  The discovery
>       process may be passive or active from a node point of view.
>       Typically the discovery mechanism varies depending on the access
>       technology.  It is also possible that there are multiple discovery
>       mechanisms within one access technology depending on the network
>       deployment.
> 
> [BA] Suggest rewriting to:
> 
>       The mechanism used to discover available networks. The discovery
>       mechanism may be passive or active, and depends on the access
>       technology.  In passive network discovery, the node listens for
>       network announcements; in active network discovery the node
>       solicits network announcements.  It is possible for an access
>       technology to utilize both passive and active network discovery
>       mechanisms.
> 
>    Realm Selection
> 
>       This refers to selection of the realm of the operator/ISP used to
>       access the network.
> 
> [BA] This doesn't make sense to me -- the realm is a characteristic of
> the home AAA server.  Suggest rewriting to:

Hmmm... right.

> The selection of the realm (and corresponding NAI) used to access the
> network.

Ok.

>    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.
> 
> [BA] I would change to:
> 
>    Network Access Server
> 
>       The device that peers connect to in order to obtain 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.

Cheers,
	Jouni

Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2)
From: "Jouni Korhonen" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 26 Feb 2007 14:13:30 -0800

Hi Bernand,

Few comments inline.

Bernard Aboba kirjoitti:
> Section 2
> 
>    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.  There are a set of somewhat
>    orthogonal problems being discussed under the rubric of "network
>    discovery and selection".
> 
> [BA]  Suggest changing to:
> 
> The network discovery and selection problem can be broken down into
> multiple sub-problems.  These include:

Ok.

>    o  The problem of "discovery of points of attachment".  This is the
>       problem of discovering points of attachment available in the
>       vicinity, and the capabilities associated with these points of
>       attachment.
> 
>    o  The problem of "Identifier selection".  This is the problem of
>       selecting which identity (and credentials) to use to authenticate
>       in a given point of attachment to the network.
> 
>    o  The problem of "AAA routing" which involves figuring out how to
>       route the authentication conversation originating from the
>       selected identity back to the home realm.
> 
>    o  The problem of "Payload routing" which involves figuring how the
>       payload packets are routed, where more advanced mechanisms than
>       destination-based routing is needed.  However, while being an
>       interesting problem, this document does not attempt to do any
>       analysis or suggestions on it.
> 
> [BA] Suggest changing to:
> 
> o Discovery of points of attachment.  This involves the discovery
> of points of attachment in the vicinity, as well as their
> capabilities.

Ok.

> o  Identifier selection.  This involves selection of the
> NAI (and credentials) used to authenticate to the selected
> ponit of attachment.

Ok.

> o  AAA routing. This involves routing of the AAA
> conversation back to the home AAA server, based on the realm
> of the selected NAI.

Ok.

> o  Payload routing.  This involves the routing of data packets, in
> the situation wh ere mechanisms more advanced than destination-based
> routing are required.  While this problem is interesting, it is not
> discussed further in this document.

Ok.

>    o  The problem of "network capability discovery".  This is the
>       problem of discovering the capabilities of a particular
>       destination network.  For example, it may be important to know
>       whether a given network supports enrollment, what the charges are,
>       etc.
> 
> [BA] I'm not sure what "network capability discovery" means.  Is this
> about discovery the capabilities of the access network, or of the
> home realm?  On the assumption that this is about the home realm,
> I suggest that the text be changed to the following:

The original text is somewhat bad at best.. From the services point of 
view the roaming user knows its home realm capabilities, or at least it 
should. Imo the above text refers to capabilities of the access network.

> o Realm capability discovery.  This involves discovering the
> capabilities of a home AAA server, such as whether the
> home AAA server supports enrollment.

How about something like:

   o Network capability discovery.  This involves discovering the
     capabilities of an access network, such as whether certain
     services are reachable through the access network and type of
     charging policy.

Cheers,
	Jouni

> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 

Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2.4)
From: "Jouni Korhonen" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 26 Feb 2007 14:39:56 -0800

Hi,

Again some comments inline.

Bernard Aboba kirjoitti:
> 2.4.  Capability Discovery
> 
>    Network Capabilities can provide information useful in the selection
>    process [I-D.groeting-eap-netselection-results].  For instance,
>    access network discovery may benefit from getting knowledge about the
>    quality of service available from a particular access network or
>    node, and AAA routing may require knowledge of roaming agreements.
>    References [I-D.groeting-eap-netselection-results] and
>    [IEEE.11-04-0624] describe the following categories of information
>    which can be discovered:
> 
> [BA] Suggest changing to:
> 
>    Network capabilities can provide information useful in the selection
>    of an access network.  These include characteristics of the network
>    beyond those of individual points of attachment.  Network capabilities
>    which can be discovered include:

Ok.

> 
>    o  Access network identification
> 
> [BA] Suggest changing to "Access network identifier (e.g. IEEE 802.11 SSID)"

Ok.

>    o  Roaming agreements
> 
> [BA] Suggest changing to "Roaming relationships between the access network
> provider and other network providers and associated costs"

Ok.

>    o  Authentication mechanisms
> 
> [BA] Not sure what is meant here.  Are we talking about discovering
> capabilities of individual points of attachment (e.g. support for WEP,
> WPA, WPA2, etc.) or are we talking about discovery of EAP authentication
> mechanisms?  The latter is really a characteristic of the home AAA server,
> no?  Not sure why item is included in the list.

Hmmm.. a good question. I think this is supposed to mean discovering the 
capabilities of individual points of attachment. For example from an 
operator point of view they might provide support for multiple auth 
methods in their provided connectivity products and in there might be 
some kind of prioritization on discovered networks based on the 
supported auth mechanism.

>    o  Quality of Service
> 
> [BA] Again, I'm not sure whether this is talking about QoS capabilities or
> QoS metrics (which would be relevant to selecting a point of attachment),
> or something different.  While maximum bandwidth or perhaps generic QoS
> capabilities (which might or might not be available on all points of
> attachment) might be relevant for selecting an access network, QoS metrics
> relating to a particular point of attachment seem too specific for that
> purpose.

Hmm.. agree. How about adding the capability there:

   o Quality of Service capability

>    o  Cost
> 
> [BA] Since this is a property of the roaming relationship path, should we
> lump this in with roaming information?

Ok with me.

>    o  Authorization policy
> 
> [BA] Not sure what this is referring to.  If we are talking about
> access restrictions, then this is a property of the home AAA server
> and should be included in "realm discovery".

I have no idea. This bullet has always been there in some form ;)

>    o  Privacy policy
> 
> [BA] Not sure what this is referring to.  If we are talking about EAP
> method privacy, then this is a property of the home AAA server, and
> should be included in "realm discovery".

Same as above..

>    o  Service parameters, such as the existence of middleboxes
> 
>    The nature of the discovered information can be static, such as the
>    fastest available transmission speed on a given piece of equipment.
>    Or it can be dynamic, such as the current load on this equipment.
> 
> [BA] Are dynamic considerations really part of network selection? It
> seems to me that those kind of dynamic considerations are too specific
> and transient for that purpose, and belong under selection of a
> point of attachment.

Agree.

>    The information can describe something about the network access nodes
>    themselves, or it can be something that they simply advertise on
>    behalf of other parts of the network, such as roaming agreements
>    further in the AAA network.
> 
>    Typically, it would be desirable to acquire all this information
>    prior to the authentication process.  In some cases it is in fact
>    necessary, if the authentication process can not complete without the
>    information.  Reference [IEEE.11-04-0624] classifies the possible
>    steps at which IEEE 802.11 networks can acquire this information:
> 
> [BA] If network discovery is to be distinct from discovery of points
> of attachment and associated capabilities, then it needs to deal with
> different aspects.  It seems to me that capabilities of individual
> network access servers belong with discovery of points of attachment;
> in network discovery we are talking about discovery of characteristics
> of networks as a whole.
> 
> Suggest changing to:
> 
> Network discovery focuses on the discovery of the services offered
> by networks, not just the capabilities of individual points of
> attachment.  Typically it is desirable to acquire information on
> access networks prior to authentication, particularly in situations
> where successful authentication depends on that information.

Ok.

>    Reference [IEEE.11-04-0624] classifies the possible
>    steps at which IEEE 802.11 networks can acquire this information:
> 
>    o  Pre-association
>    o  Post-association (or pre-authentication)
>    o  Post-authentication
> 
>    Note that some EAP methods (such as those defined in
>    [I-D.josefsson-pppext-eap-tls-eap] [I-D.tschofenig-eap-ikev2]
>    [I-D.arkko-eap-service-identity-auth]) have an ability to agree about
>    additional parameters during an authentication process.  While such
>    parameters are useful for many purposes, their use for access network
>    selection suffers from an obvious chicken-and-egg problem.  Or at
>    least it seems costly to run a relatively heavy authentication
>    process to decide whether the client wants to attach to this access
>    network.
> 
> [BA] EAP methods only become relevant once the realm has been selected, so
> I'd suggest that this be changed to the following:
> 
>    In the interest of minimizing connectivity delays, the
>    information required for network selection needs to be provided
>    prior to authentication.  By the time authentication occurs,
>    the node has typically selected the access network, the NAI
>    to be used to authenticate, as well as the point of attachment.
>    Should it learn information during the authentication process
>    that would cause it to revise one or more of those decisions,
>    the node will need to select a new network, point of attachment,
>    and/or identity, and then go through the authentication process
>    all over again.  Such a process is likely to be both time
>    consuming and unreliable.

Ok.

Cheers,
	Jouni

Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2.4)
From: "Jouni Korhonen" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Date: Mon, 26 Feb 2007 14:41:40 -0800

Bernard Aboba kirjoitti:
> BTW, I think this section should be renamed "Network Discovery".

Fine with me.

Cheers,
	Jouni

> 
> 
>> From: "Bernard Aboba" <[email-masked]>
>> To: [email-masked]
>> Subject: Re: [eap] Issue 376: Proposed Resolution (Section 2.4)
>> Date: Mon, 26 Feb 2007 07:14:43 -0800
>>
>> 2.4.  Capability Discovery
>>
>>    Network Capabilities can provide information useful in the selection
>>    process [I-D.groeting-eap-netselection-results].  For instance,
>>    access network discovery may benefit from getting knowledge about the
>>    quality of service available from a particular access network or
>>    node, and AAA routing may require knowledge of roaming agreements.
>>    References [I-D.groeting-eap-netselection-results] and
>>    [IEEE.11-04-0624] describe the following categories of information
>>    which can be discovered:
>>
>> [BA] Suggest changing to:
>>
>>    Network capabilities can provide information useful in the selection
>>    of an access network.  These include characteristics of the network
>>    beyond those of individual points of attachment.  Network capabilities
>>    which can be discovered include:
>>
>>    o  Access network identification
>>
>> [BA] Suggest changing to "Access network identifier (e.g. IEEE 802.11 
>> SSID)"
>>
>>    o  Roaming agreements
>>
>> [BA] Suggest changing to "Roaming relationships between the access network
>> provider and other network providers and associated costs"
>>
>>    o  Authentication mechanisms
>>
>> [BA] Not sure what is meant here.  Are we talking about discovering
>> capabilities of individual points of attachment (e.g. support for WEP,
>> WPA, WPA2, etc.) or are we talking about discovery of EAP authentication
>> mechanisms?  The latter is really a characteristic of the home AAA server,
>> no?  Not sure why item is included in the list.
>>
>>    o  Quality of Service
>>
>> [BA] Again, I'm not sure whether this is talking about QoS capabilities or
>> QoS metrics (which would be relevant to selecting a point of attachment),
>> or something different.  While maximum bandwidth or perhaps generic QoS
>> capabilities (which might or might not be available on all points of
>> attachment) might be relevant for selecting an access network, QoS metrics
>> relating to a particular point of attachment seem too specific for that
>> purpose.
>>
>>    o  Cost
>>
>> [BA] Since this is a property of the roaming relationship path, should we
>> lump this in with roaming information?
>>
>>    o  Authorization policy
>>
>> [BA] Not sure what this is referring to.  If we are talking about
>> access restrictions, then this is a property of the home AAA server
>> and should be included in "realm discovery".
>>
>>    o  Privacy policy
>>
>> [BA] Not sure what this is referring to.  If we are talking about EAP
>> method privacy, then this is a property of the home AAA server, and
>> should be included in "realm discovery".
>>
>>    o  Service parameters, such as the existence of middleboxes
>>
>>    The nature of the discovered information can be static, such as the
>>    fastest available transmission speed on a given piece of equipment.
>>    Or it can be dynamic, such as the current load on this equipment.
>>
>> [BA] Are dynamic considerations really part of network selection? It
>> seems to me that those kind of dynamic considerations are too specific
>> and transient for that purpose, and belong under selection of a
>> point of attachment.
>>
>>    The information can describe something about the network access nodes
>>    themselves, or it can be something that they simply advertise on
>>    behalf of other parts of the network, such as roaming agreements
>>    further in the AAA network.
>>
>>    Typically, it would be desirable to acquire all this information
>>    prior to the authentication process.  In some cases it is in fact
>>    necessary, if the authentication process can not complete without the
>>    information.  Reference [IEEE.11-04-0624] classifies the possible
>>    steps at which IEEE 802.11 networks can acquire this information:
>>
>> [BA] If network discovery is to be distinct from discovery of points
>> of attachment and associated capabilities, then it needs to deal with
>> different aspects.  It seems to me that capabilities of individual
>> network access servers belong with discovery of points of attachment;
>> in network discovery we are talking about discovery of characteristics
>> of networks as a whole.
>>
>> Suggest changing to:
>>
>> Network discovery focuses on the discovery of the services offered
>> by networks, not just the capabilities of individual points of
>> attachment.  Typically it is desirable to acquire information on
>> access networks prior to authentication, particularly in situations
>> where successful authentication depends on that information.
>>
>>    Reference [IEEE.11-04-0624] classifies the possible
>>    steps at which IEEE 802.11 networks can acquire this information:
>>
>>    o  Pre-association
>>    o  Post-association (or pre-authentication)
>>    o  Post-authentication
>>
>>    Note that some EAP methods (such as those defined in
>>    [I-D.josefsson-pppext-eap-tls-eap] [I-D.tschofenig-eap-ikev2]
>>    [I-D.arkko-eap-service-identity-auth]) have an ability to agree about
>>    additional parameters during an authentication process.  While such
>>    parameters are useful for many purposes, their use for access network
>>    selection suffers from an obvious chicken-and-egg problem.  Or at
>>    least it seems costly to run a relatively heavy authentication
>>    process to decide whether the client wants to attach to this access
>>    network.
>>
>> [BA] EAP methods only become relevant once the realm has been selected, so
>> I'd suggest that this be changed to the following:
>>
>>    In the interest of minimizing connectivity delays, the
>>    information required for network selection needs to be provided
>>    prior to authentication.  By the time authentication occurs,
>>    the node has typically selected the access network, the NAI
>>    to be used to authenticate, as well as the point of attachment.
>>    Should it learn information during the authentication process
>>    that would cause it to revise one or more of those decisions,
>>    the node will need to select a new network, point of attachment,
>>    and/or identity, and then go through the authentication process
>>    all over again.  Such a process is likely to be both time
>>    consuming and unreliable.
>>
>>
>> _________________________________________________________________
>> 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
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

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