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

[Jari Arkko (jari.arkko]

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