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

From: "Adrangi, Farid" <[email-masked]>
Date: Sun, 20 Feb 2005 13:56:39 -0800

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-net
work-discovery-09.txt

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
> 
> 
> 
> 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-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
> 
> - 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: "Glen Zorn (gwz)" <[email-masked]>
Date: Sun, 20 Feb 2005 16:48:22 -0800

Adrangi, Farid <mailto:[email-masked]> supposedly

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

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.

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.

>> To: Jari Arkko; [email-masked]'; [email-masked]'; Eugene
Chang;
>> [email-masked]' Cc: [email-masked]; [email-masked]'
resolution
>> to issues that you raised.  I just submitted version -08, so it
does
>> not yet appear on I-D repository yet.
>> 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.
>> 
>>    mediating networks such as roaming consortiums and brokers, or
>> both. 
>> 
>>    One possible application for this mechanism is to help in
>>    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. 
>>    discussion about this problem space.
>> "
>> 
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. 
>> 
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. 
>>    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.
>>    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.
"
>>    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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Sun, 20 Feb 2005 17:12:02 -0800

BTW, draft-arkko-roamops-rfc2486bis-02.txt (a normative reference)
appears to have expired.  Perhaps it could be refreshed before the
deadline tomorrow?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Feb 2005 07:06:09 +0200

> appears to have expired.  Perhaps it could be refreshed before the

Its expired because the current draft name is
draft-ietf-radext-rfc2486bis-03.txt.

Also, draft-ietf-eap-netsel-problem is now at -02,
not -01.

--Jari