eap Mailing List: RE: decisions from ietf-59: network selection

[Alper Yegin (alper.yegin]

Given the current constraints:

- 3GPP and IEEE want this be done yesterday
- But do not want to modify the IEEE 802.1X at this point
- And deal with its deployment on APs

I think going forward with #2 is the only choice.

Nevertheless, I'd recommend we don't drop the more appropriate solution
from the radar, that is handling this issue on the EAP lower layer. We
should capture this somewhere (too late for section 3 of rfc2284bis) and
provide guidance to new EAP lower layer designers. 

Alper


> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
> Behalf
Of
> Jari Arkko
> Sent: Thursday, March 11, 2004 7:32 AM
> To: eap [at] frascone.com
> Subject: [eap] decisions from ietf-59: network selection
> 
> 
> In Seoul, we had a discussion about network selection. I'd like to
> confirm the results of that discussion here on the mailing list.
> 
> We discussed the overall problem definition, what standards bodies are
> addressing which issues, and whether the IETF needs to do something in
> this space. In the problem definition draft, we divided the issue in a
> number of subproblems, only one of which is potentially in EAP WG
> space, the discovery of roaming intermediaries.
> 
> A discussion arose on what approach the group would prefer. The
> following alternatives were given:
> 
>    1. We could turn this entirely over to future layer 2 mechanisms.
> 
>    2. We could handle this within EAP, according to Farid's draft or
>       similar, eventually to be published as Informational RFC. (This
>       option would be constrained to only the specific roaming
>       intermediary discovery, and not a mechanism for discovering all
>       kinds of other information.)
> 
>    3. We could leave this up to individual vendors and proprietary
>       solutions. Some solutions already exist in this space.
> 
>    4. We could decide to do nothing.
> 
>    (Note that the options are not necessarily mutually exclusive. It
is
>    possible that future link layer mechanisms might later complement
or
>    even replace some other solution.)
> 
> Most of the people in Seoul preferred to go forward with option 2. If
> you weren't in Seoul and have an opinion, let us know what you think.
> In order to move forward, it would be helpful if you can post your
> opinion by noon (PST) Tuesday next week.
> 
> Raw (unedited) minutes from Seoul on this item are included below.
> Some material also available from
> http://www.arkko.com/publications/eap/ietf-59
> 
> --Jari
> 
> 6. Network selection, Farid Adrangi, Jari Arkko (25 min)
> 
>     Contents:
>        - Problem definition
>        - 3GPP priorities
>        - IEEE plans
>        - Solutions
> 
>     Drafts:
>        - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-
> problem-00.txt
>        -
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-
> discovery-and-selection-01.txt
>        - http://www.ietf.org/internet-drafts/draft-arkko-roamops-
> rfc2486bis-00.txt
> 
>     * Problem definition
>       Draft exists, see above.
>       - We need network selection. Well, what is this
>       - Tried to classify this:
> 
>         1. Acces network discovery
>         2. Identifier selection - which nai to use on this link
>         3. Selection of roaming intermediaries
>         4. Payload Routing
> 
>       - Another way to look at this is = there are 3 activities we
have
>         to do:
> 
>         * Discovery - what services were available
> 
>         * Decision - screen with manual net selection, or manual
> 
>         * Indicate choice to network - attach to one access point, or
>           send nai of certain value
> 
>       - Recommendations
>         * All 4 problems are relevant
>         * Potential need for new solutions
> 
>       - These problems are _really_ _really_ hard if
>         * there are a lot of networks
>         * you want to do it securely
>         * there are many different ways to do this
> 
>       - Given that the problem _is_ hard, it may be that we can't
solve
>         it all now.
> 
>     * IEEE and 3GPP responses
> 
>       - What do they want to do, what do they
> 
>         3gpp SA2 wlan group:
>       - problems 1 and 3 are relevant to 3gpp, but not the others.
>       - 3gpp eses existing l2 mechanisms for problem 1
>       - they expect an IETF solution to problem 3
> 
>         ieee 802.11 meeting summary
>          - alternatives are relevant for one of their stydy groups
>       - they don't know what kind of solutions they need now
>       - other groups also working on related problems
> 
>     * Solution space
> 
>       - Believe there is interest in problems 1 and 3
>       - Pretty clear problem 1 belongs to link layer
>       - Problem 3 belongs at least in part in IETF. There may be
>         mechanisms at lower layers that effectively advertise relevant
>         information also for higher levels than L2
>       - If there's an IETF intermedirary solution, it will probably be
>         relatively short-term
>       - We already today have configured databases on the client, and
>         advertised information; must be able to switch to other
source.
>       - in roamops draft
> 
>         Osok: SA2 ready to use EAP based solutions not only for
>         problem 3 but also for problem 1.
>         Agreed that ESSID cannot always be used to select access
>         point.
> 
>         Farid:        Problems 1 and 3 may be intertwined, may need to
do 1
>         based on result of 3
> 
>         Osok: Cannot use ESSID only, also in situations where we don't
>         want
> 
>         David Johnston, chair .21:
>         Ways of doing link-layer discovery, some good ways, and
>         may be better ways upcoming. .21 talks about providing
>         means of link-layer discovery and fast handover.
>         Critical item is you - need to get information, and that
>         information need to map into a wider information model
>         used by 3gpp, IEEE, etc.
> 
>         Glenn:        The only reason this needs to be in EAP is that
- We're
>         selecting from private networks here - commercial or
>         not - and have to select the path of the aaa packets
>         because providers won't carry other people's aaa packets.
> 
>         Serge Manning: Don't know if EAP solutions are the best, but
even
>         if .21 comes up with something, we'll have to be able
>         to work with existing .11 APs
> 
>         Pasi: Why is aaa routing difficult - all AccessAccept packets
>         forwarded indicates willingness to carry the traffic of
>         somebody, and may result in monetary pain if you do it
>         without getting paid
> 
>        Glenn: Forwarding of aaa packet is an implied contract? The
>        routing of aaa packets? How can that be?? That's crazy!
> 
>        Pasi:  When you
> 
>        Glenn: Have to pick what network to carry your traffic, that's
> ok.
>        And you have to have an agreement between providers.
>        But just _forwarding_ the aaa packets, to set up the
>        correct route for traffic should not be a problem.
> 
>        Jari:  Two problems, finding an access network and selecting
>        who is to carry the traffic.
> 
>        Glenn: The first part I understand, but not why the rest of the
>        stuff has to be done in EAP.
> 
>        Farid: This is operator requirements, that 1 and 3 are
> requirements.
> 
>     Farid's presentation:
>       * (See slides - graphics with text)
> 
>         1. MN finds home service network (HSN) advertised, OK
>         2. MN finds other operators, which has a relationship with
HSN,
>         OK.
>         3. MN finds no opeartor with known relationship with HSN -
need
>            to try each in turn, and discover if somebody has a
> relationship
>         with a preferred mediating network
> 
>         Alper:        Can there be several mediating networks in
series
> between
>         access network and HSN?
> 
>         Farid:        In 3gpp we are not considering more than 1
intermediary
>         mediating networks
> 
>         Lauri?: Is there any implicit assumption that client will
>         have to know paths through the net?
> 
>         Farid: No, looks up each intermediary network discovered in an
>         preconfigured database.
> 
>       * Solution proposed:
> 
>         - complies with 2284bis, uses 2486bis bang syntax
>         - may not require any changes to access points
>         - uses EAP Identity Rewquest to deliver identities from the
local
>           aaa server
> 
>        Osok:  Why "MAY" in point 2?
> 
>        Farid: You can deliver from AAA server, which doesn't require
any
>        AP change. But you could also configure APs to assist
selection.
> 
>     Jari:
>       * Need to decide how to advertise intermediary networks, could
>       * How should access discovery be performed.
> 
>         David: Don't think that a L2 solution will override an EAP
>         solution, both will be appropriate for a long time.
> 
>       * Need to decide what to do with Farid's draft
>       * Need to decide how to go forward in EAP:
> 
>         1. We could turn this entirely over to future Layer 2
mechanisms
>         2. We could handle this within EAP, according to Farid's draft
or
>         similar
>         3. We could leave this up to individual vendors and
proprietary
>            solutions
>         4. We could decide to do nothing.
> 
>       * Pros, Cons
> 
>         - Layer 2 approach is probably most efficient, but may require
AP
>        upgrdes, may take longer time to specify and implement
>         - Farid's draft doesn't need AP upgrades , but is not very
clean
>         - Could let vendors do each his own thing, which may result in
>        many competing and maybe broken ways
> 
>        Alper: Why....
> 
>        ..
> 
>        Alper: Could use PANA to do discovery at lower level..
> 
>        Glenn: Why does it matter if you get many?  We're selecting
>        private networs?
> 
>        Jari: France telecom may have their own scheme, but they won't
>        have their own Windows or their own phone.
> 
>        Glenn: Informational is not enough, Standard is going to be
>        required to make vendors pick it up.
> 
>        Jari: There are tradeoffs with the vendor-specific thing
> 
>        Steven Hayes: Timeframes for 3gpp:  Need to have a clear
>        indication of direction, as the goal is to finalize
specification,
>        stage two on coming meeting and stage 3 within 6 months.  Layer
2
>        hard to swallow, vendor-specific could work but
> 
>        Yoshi Ohba: Don't prefer any particular solution, but needs to
>        consider threats.  Farid's proposal has weaknesses.
> 
>        Jari: You have contracts, you don't go outside those
>        preconfigured, so isn't that much of a threat.
> 
>        ?? Cisco:  Steve, do you have any preference? Could you clarify
>        In 3gpp2 we have a design strategy to prefer things with zero
>        impact on Wireless Lans
> 
>        Steven: Farid's draft is the preferred way.
> 
>       * Consensus call:
> 
>         - Option 1: ~3
>         - Option 2: ~11
>         - Option 3: ~2
>         - Option 4: ~1
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap