Subject: [eap] decisions from ietf-59: network selection

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Mar 2004 17:31:57 +0200

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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Fri, 12 Mar 2004 18:42:07 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jari Arkko
> Sent: Thursday, March 11, 2004 7:32 AM
> To: [email-masked]
> Subject: [eap] decisions from ietf-59: network selection
> 
> 
>        -
http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-
> discovery-and-selection-01.txt
> 	  Alper:	Can there be several mediating networks in
series
> between

---

From: Jari Arkko <[email-masked]>
Date: Sun, 14 Mar 2004 14:01:54 +0200

Alper Yegin wrote:

> from the radar, that is handling this issue on the EAP lower layer.

I agree. I do believe there is actually quite a lot of work in progress
in this area, and the matter will not be forgotten. The primary driver
appears to be faster movements, which makes it necessary to have better
information distribution from the link layer to higher layers. When such
mechanisms are available, they can be used for various other purposes
as well.

Note that much of this work happens outside the IETF (e.g. 802.21)
or at least outside the EAP WG.

> We should capture this somewhere (too late for section 3 of rfc2284bis) and

Well, we do have the problem definition document... it has also been
sent as input to the IEEE efforts, for instance.

It would probably be useful to think about these issues also in the
context of PANA. Or does PANA assume link layer under it provides
assistance? But at least some of the limited discovery & selection
functions in the current PANA base protocol are on the IP layer, so
maybe more extensive mechanisms would go there as well. Has there been
any thoughts on where link layer hints fit in the PANA model, for
instance?

--Jari

---

From: Alper Yegin <[email-masked]>
Date: Mon, 15 Mar 2004 02:48:05 -0800

Hi Jari,

> or at least outside the EAP WG.

There is some relation here, but I cannot really say that 802.21
solution would also handle network (ISP) discovery and selection. This
might be a by-product of their solution, but I guess not a targeted
deliverable. 

I really don't know where directly related work is happening in IEEE
(.1ae??)

> > We should capture this somewhere (too late for section 3 of
rfc2284bis)
> and

This is a good start, but if EAP WG has a recommendation to EAP
lower-layer designers, I think this requires another vehicle (unless we
expand the scope of the problem definition draft).

> any thoughts on where link layer hints fit in the PANA model, for

In PANA, the ISP discovery and selection is already provided by:
- PAA advertising list of ISPs
- PaC stating the chosen ISP

I'm not sure what else we need in the context of PANA.

Actually, this whole selection problem is two fold:
a- how to discover and select the network attachment point.
b- how to discover and select the ISP.

At any given point in time, there may be several distinct attachment
points which serve differing sets of ISPs available to my host. A host
should perform (a) and (b). 

(a) and (b) might be integrated in some designs. For example if 802.11
AP could advertise ISPs with the beacons. A STA could select the AP
based on its ultimate choice of ISP, and later indicate its ISP choice
to the AP in later stages (e.g., during EAP).

On the other hand, for example, in DSL networks (a) does not happen
dynamically. Network attachment is dictated by the physical connection
of your residence. (b) takes place over that pre-configured network
attachment.

The network discovery and selection facility in PANA enables (b),
assuming (a) has already taken place. This is because PANA runs after
the link-layer is connected. (a) requires link-layer facilities. Is that
what you mean by "link-layer assistance?"

Alper