Subject: [eap] -08 version of EAP-based network discovery

From: "Adrangi, Farid" <[email-masked]>
Date: Fri, 18 Feb 2005 18:10:03 -0800

Hi Jari, Glen, Joe, Eugene, Sam, all

Thank you for reviewing the draft and providing your feedback/comments.
We have revised the draft to provide resolution to issues that you
raised.  I just submitted version -08, so it does not yet appear on I-D
repository yet.  In the mean time, you can access the draft here:  
http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net
work-discovery-08.txt

Special thanks to Jari for proposing text to address some of the issues.
A summary of changes can be found below.

BR,
Farid

*** Abstract

- the following paragraph was added

"
   The mechanism defined in this document is primarily intended for
   advertising connectivity of access network to a limited number of
   roaming partners that find such advertisement of their presence
   useful.
"

*** Section 1

"
   Exactly how the identity hint information is used by the peer depends
   largely on the peer's local policy and configuration, and is outside
   the scope of this document.

   In many roaming situations, an access network can have several
   roaming relationships, either with several home networks, or with
   mediating networks such as roaming consortiums and brokers, or both.

   One possible application for this mechanism is to help in selecting
   what kind of NAI decoration [rfc2486bis] must be applied to allow
   proper routing of AAA messages to the home AAA server.  If there are
   several possible mediating networks, the peer can choose which one to
   use.  However, exactly how the selection is made is beyond the scope
   of this document.  See [netsel-problem] for more detailed discussion
   about this problem space.
"

Replaced/modified with

"
   One possible application for this mechanism is to help an EAP peer in
   selecting what kind of NAI decoration [rfc2486bis] must be applied to
   allow proper routing of AAA messages to the home AAA server.  If
   there are several possible mediating networks, the peer can choose
   which one to use.

   Exactly how the selection is made by the peer depends largely on the
   peer's local policy and configuration, and is outside the scope of
   this document.  For example, the peer could decide to use another
   identity it has, decide to switch to another access network, or
   attempt to reformat its NAI [rfc2486bis] to assist in proper AAA
   routing.

   This document is also related to the general network discovery and
   selection problem.  See [netsel-problem] for more detailed discussion
   about this problem space.
"

*** A new Section 1.1 (Applicability) was added

"
1.1  Applicability

   Basic roaming and AAA routing mechanisms are normally sufficient, and
   the identity hints are typically useful only when there's too much
   ambiquity to try all client identities and access network
   combinations efficiently, or when the scale of the roaming
   associations precludes full automatic connectivity from all access
   networks to all home networks.  This can happen, for instance, when
   access networks have contracts with multiple roaming consortiums but
   do not have a full list of home networks reachable through them.

   In the situations mentioned above, a limited number of identity hints
   can be provided by the mechanism described in this document.  Even in
   this case, for security reasons it is required that the networks that
   are listed in these hints consent to such advertisements.

   The immediate application of the proposed mechanism is in 3GPP
   systems inteworking with WLANs [TS.23.234] and [TS.24.234].  The
   roaming partner information provided via this mechanism is limited by
   the link layer MTU size.  For example, assuming an average of 20
   octets per roaming partner / home network information and the link
   layer MTU size of 1096, the approximate number of roaming partners
   that can be advertised would be 50.  The scalability limitation
   imposed by the link layer MTU size should be taken into consideration
   when deploying this solution.
"

*** Section 2

"
   The EAP authenticator MAY send an identity hint to the peer in the
   initial EAP-Request/Identity.  If the identity hint is not sent
   initially (such as when the authenticator does not support this
   specification), then if the EAP server receives an
   EAP-Response/Identity with an unacceptable NAI Realm, EAP servers
   implementing this specification SHOULD reply with an
   EAP-Request/Identity containing an identity hint.

   If after the EAP server sends an EAP-Request/Identity containing an
   identity hint, the peer responds with an EAP-Response/Identity
   containing an unacceptable NAI Realm, then the EAP server MAY respond
   immediately with an EAP Failure packet, or it MAY first send an
   EAP-Notification providing the reason for the failure.
"

Was replaced with 

"
   The EAP authenticator MAY send an identity hint to the peer in the
   initial EAP-Request/Identity.  If the identity hint is not sent
   initially (such as when the authenticator does not support this
   specification), then if the local AAA proxy implementing this
   specification receives an EAP-Response/Identity with an unknown
   realm, it SHOULD reply with an EAP-Request/Identity containing an
   identity hint.

   If after the local AAA proxy sends an EAP-Request/Identity containing
   an identity hint, the peer responds with an EAP-Response/Identity
   containing an unknown realm, then the local AAA proxy MAY respond
   immediately with an EAP Failure packet, or it MAY first send an
   EAP-Notification providing the reason for the failure.

"

*** Section 4 (Security)

- The following paragraph was added

"
   Any information revealed either from the network or client sides
   before authentication has occurred can be seen as a security risk.
   For instance, revealing the existence of network that uses a poor
   authentication method can make it easier for attackers to discover
   that such network can be accessed.  As a result, the consent of the
   network being advertised in the hints is required before such hints
   can be sent.
"
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Sun, 20 Feb 2005 19:25:21 -0800

Hi Glen,
Thanks for your review. Please see my comments in line.
- Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Sunday, February 20, 2005 4:48 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]; 'Jari Arkko'; 
> [email-masked]
> Subject: RE: -08 version of EAP-based network discovery
> 
> 
> Adrangi, Farid <mailto:[email-masked]> supposedly
> scribbled:
> 
> > Hi all,
> > A quick update!  I just submitted -09 version to address the
> recent
> > issue 290 (submitted by Bernard).  You can find the draft here:
> >
> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap
> -network-discovery-09.txt
> > 
> 
> A couple of quick comments: the grammar & syntax needs some serious
> work.  
> 
> The second paragraph of the introduction says "The mechanism defined
> in this document is primarily intended for advertising connectivity
> of access network to a limited number of roaming partners that find
> such advertisement of their presence useful.", which is barely
> parseable to me.  I _think_ that it means "The mechanism defined in
> this document is primarily intended for advertising the connectivity
> of an access network to a limited number of roaming partners that
> find such advertisement useful."  
> 

Your suggested text is more clear - will fix it as per your
recommendation.  Are there any other paragraphs that need editoral
fixing?  If so, can you point us to those paragraphs. 

> Although the authors attempt to punt on the question of client
> network (excuse me, identity) selection, nevertheless they clearly
> have some model of client participation in mind.  For example, if
> "access networks have contracts with multiple roaming consortiums
> but do not have a full list of home networks reachable through them"
> (section 1.1, first paragraph, second sentence) then it would appear
> that the client must carry with it a list of routes to its home
> network through all the roaming consortia of which it is aware.  It
> would be helpful if the model of client behavior assumed was
> explained.
> 

I agree with you on the point that the client needs to be preprovisioned
with his/her home network's roaming partner information.  However, the
authors did not want to suggest any specific client behavior model in
this document.  TS.24.234 (Release 6) specifies two client behavior
models: manual and automatic selection.  In automatic selection, the
client is preprovioned with network information by the home network to
help the client in roaming partner selection. If the list or IESG want
us to elaborate on some client behavior models, well I guess we can do
it. But, in the meant time, TS.24.234 is listed as a reference in the
document.

> The Appendix (why is it "Appendix A" if there is only one?) is
> marked as "Informative".  Assuming that this is intended to be an
> Informational RFC (I can't imagine it as Standards Track unless our
> standards have seriously eroded), this marking is redundant.

Ok. I will remove "informative" and replace "Appendix A" with
"Appendix".

> 
> > A summary of the changes:
> > 
> > - The following paragraph was added to section 2, after the third
> > paragraph 
> > 
> > "
> >    When an Identity hint is sent by a AAA proxy/server, the AAA
> >    proxy/server MUST be able to determine if an identity hint had
> >    previously been sent by it to the EAP peer.  When RADIUS is
> used,
> >    State(24) attribute can be used to achieve this.
> > "
> > 
> > - The following paragraph was removed from the appendix
> > 
> > "
> >    When an Identity hint is sent by a RADIUS proxy/server, a
> RADIUS
> >    State (24) attribute can be used to help the RADIUS
> proxy/server
> >    determine if an identity hint had previously been sent by it to
> the
> >    EAP peer.
> > "
> > 
> > BR,
> > Farid
> > 
> > 
> >> -----Original Message-----
> >> From: Adrangi, Farid
> >> Sent: Friday, February 18, 2005 6:10 PM
> >> To: Jari Arkko; [email-masked]'; [email-masked]'; Eugene
> Chang;
> >> [email-masked]' Cc: [email-masked]; [email-masked]'
> >> Subject: -08 version of EAP-based network discovery
> >> 
> >> 
> >> 
> >> Thank you for reviewing the draft and providing your
> >> feedback/comments.  We have revised the draft to provide
> resolution
> >> to issues that you raised.  I just submitted version -08, so it
> does
> >> not yet appear on I-D repository yet.
> >>  In the mean time, you can access the draft here:
> >> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adran
> >> gi-eap-network-discovery-08.txt
> >> 
> >> Special thanks to Jari for proposing text to address some of the
> >> issues.  A summary of changes can be found below.
> >> 
> >> BR,
> >> Farid
> >> 
> >> 
> >> 
> >> 
> >> *** Abstract
> >> 
> >> useful. "
> >>    Exactly how the identity hint information is used by the peer
> >>    depends largely on the peer's local policy and configuration,
> and
> >>    is outside the scope of this document.
> >> 
> >>    One possible application for this mechanism is to help in
> >>    selecting what kind of NAI decoration [rfc2486bis] must be
> >>    applied to allow proper routing of AAA messages to the home
> AAA
> >>    server.  If there are several possible mediating networks, the
> >>    peer can choose which one to use.  However, exactly how the
> >>    selection is made is beyond the scope of this document.  See
> >>    [netsel-problem] for more detailed discussion about this
> problem
> >> space. "
> >> 
> >> Replaced/modified with
> >> 
> >> "
> >>    One possible application for this mechanism is to help an EAP
> >>    peer in selecting what kind of NAI decoration [rfc2486bis]
> must
> >>    be applied to allow proper routing of AAA messages to the home
> >>    AAA server.  If there are several possible mediating networks,
> >> the peer can choose    which one to use. 
> >> 
> >>    Exactly how the selection is made by the peer depends largely
> on
> >>    the peer's local policy and configuration, and is outside the
> >>    scope of this document.  For example, the peer could decide to
> >>    use another identity it has, decide to switch to another
> access
> >>    network, or attempt to reformat its NAI [rfc2486bis] to assist
> in
> >> proper AAA    routing. 
> >> 
> >>    selection problem.  See [netsel-problem] for more detailed
> >>    discussion about this problem space.
> >> "
> >> 
> >>    Basic roaming and AAA routing mechanisms are normally
> sufficient,
> >>    and the identity hints are typically useful only when there's
> too
> >>    much ambiquity to try all client identities and access network
> >>    networks to all home networks.  This can happen, for instance,
> >>    when access networks have contracts with multiple roaming
> >>    consortiums but do not have a full list of home networks
> >> reachable through them. 
> >> 
> >>    In the situations mentioned above, a limited number of
> identity
> >>    hints can be provided by the mechanism described in this
> >>    document.  Even in this case, for security reasons it is
> required
> >>    that the networks that are listed in these hints consent to
> such
> >> advertisements. 
> >> 
> >>    roaming partner information provided via this mechanism is
> >>    limited by the link layer MTU size.  For example, assuming an
> >>    average of 20 octets per roaming partner / home network
> >>    information and the link layer MTU size of 1096, the
> approximate
> >>    number of roaming partners that can be advertised would be 50.
> 
> >>    The scalability limitation imposed by the link layer MTU size
> >>    should be taken into consideration when deploying this
> solution.
> >> "
> >> 
> >> 
> >> *** Section 2
> >> 
> >> "
> >>    If after the EAP server sends an EAP-Request/Identity
> containing
> >>    containing an unacceptable NAI Realm, then the EAP server MAY
> >>    respond immediately with an EAP Failure packet, or it MAY
> first
> >>    send an EAP-Notification providing the reason for the failure.
> "
> >> 
> >> Was replaced with
> >> 
> >> 
> >> "
> >>    If after the local AAA proxy sends an EAP-Request/Identity
> >>    containing an identity hint, the peer responds with an
> >>    EAP-Response/Identity containing an unknown realm, then the
> local
> >>    AAA proxy MAY respond immediately with an EAP Failure packet,
> or
> >>    it MAY first send an EAP-Notification providing the reason for
> >> the failure. 
> >> 
> >> "
> >> 
> >> *** Section 4 (Security)
> >> 
> >>    that such network can be accessed.  As a result, the consent
> of
> >>    the network being advertised in the hints is required before
> such
> >> hints    can be sent. "
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel
>