Subject: [eap] Issue 401: More NITs

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 19 Mar 2007 22:21:57 -0700

Issue 401: More NITs
Submitter name: Bernard Aboba
Submitter email address: mailto:aboba [at] internaut.com
Date first submitted: March 20, 2007
Reference:
Document: NETSEL-06
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

Abstract & Section 1

   When multiple access network are available, users may have difficulty
[BA]  s/access network/access networks/

Section 1

   and divided into subproblems, and some potential solution constraints
[BA] s/subproblems, and some potential/subproblems.  Some solution/

Section 1.1

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

[BA] Since this document is informational and does not use normative
language, you can delete the above paragraph.

   Decorated NAI

      A NAI specifying a source route.  See RFC4282 [RFC4282] Section
s/RFC4282/RFC 4282/

      Selection occurs prior to network access authentication.
[BA]  s/Selection/selection/

      The selection of the realm (and corresponding NAI) used to access
      the network.
[BA]  Please add "A realm can be reachable from more than one access network 
type
      and selection of a realm may not enable network capabilities."

   Bearer Selection

      For some access technologies (e.g.  UMTS), there can be a
      possibility for delivery of a service (e.g. voice) by using either
      a circuit switched or a packet switched bearer.  The Bearer
[BA] s/The Bearer/Bearer/
      selection refers to selecting one of the bearer types for service
      delivery.  The decision can be based on support of the bearer type
      by the device and the network as well as user subscription and
      operator preferences.

[BA] Meta-question: this term doesn't appear to be referenced anywhere.  
Should it be?

   Within the context of network selection and discovery the term
   'network' is sometimes used interchangeably with the term 'realm'.
   It should be noted that a realm can be reachable from more than one
   access network types and selection of a realm may not imply certain
   network capabilities.

[BA] Suggest deleting this paragraph, since this draft no longer uses the 
terms interchangeably, and the last sentence has been moved into a 
terminology definition.

Section 2

      the situation wh ere mechanisms more advanced than destination-
[BA]  s/wh ere/where/

       services are reachable through the access network and type of
      charging policy.
[BA] s/and type of/and the/

   Alternatively, the problem can be divided to the discovery, decision,
[BA] "to the" -> "into"

   discovery (which mediating networks are
   available?), decision (choose the "best" one), and selection (client
   tells the network which mediating network it has decided to choose)
   components.

[BA] Rewrite to:

"discovery (which mediating networks are available), decision (choosing
the "best" one), and selection (selecting which mediating network to use)
components."

Section 2.1

2.1.  Discovery of the Point of Attachment to the Network

[BA] Rewrite to "Discovery of Points of Attachment"

   Traditionally, discovery of points of attachment has been handled by
   link layer or out-of-band mechanisms.  For example, the IEEE 802.11
   specification [IEEE.802.11-2003] provides support for both passive
   (Beacon) and active (Probe Request/Response) discovery mechanisms;
   [Fixingapsel] studied the effectiveness of these mechanisms.  The GSM
   specifications also provide for discovery of points of attachment, as
   does the CARD [RFC4066] protocol developed by the IETF SEAMOBY WG.

[BA] Since capabilities were included in the definition of discovery of
points of attachment you need to mention that aspect.  Please add:

"  Along with discovery of points of attachment, capabilities of access
   networks are also typically discovered.  These may include:

   o  Access network name (e.g.  IEEE 802.11 SSID)

   o  Lower layer security mechanisms (e.g. IEEE 802.11 WEP vs. WPA2)

   o  Quality of Service capabilities (e.g. IEEE 802.11e support)
"

   with a particular POP.  The RFC supports dial-in and X.25 access, but
[BA]  s/The RFC/The XML DTD/

   may not have the same set of services available.

[BA] change to "may not receive the same set of authorizations from
the home AAA server and therefore may not have the same set of
services available."

Section 2.2

   Typically, the user will choose an identity and corresponding
   credential set based on the network chooses to connect to, perhaps
[BA] s/network chooses/network it chooses/

   authentication utilizing a set realms, selection of an access network
[BA]  s/a set realms/a set of realms/

   Of course, it may not be possible to determine the available access
   networks prior to authentication.  For example, in 802.11, not all
   SSIDs are broadcast, so that the station may need to probe to locate
   a "hidden" SSID.  Also, within IKEv2 [RFC4306], the responder
   identity (typically the security gateway) is provided as a part of
   the IKEv2 exchange.

[BA] This paragraph does not support the first sentence since "hidden" SSIDs
need to be determined prior to authentication, and before IKEv2 can be 
initiated,
the VPN server needs to be located.  Recommend rewriting to:

"In some cases it may not be possible to determine the available access
networks prior to authentication.  For example,  [IEEE 802.1X-2004]
does not support network discovery on IEEE 802 wired networks, so
that the peer cannot determine which access network it has connected
to prior to the initiation of the EAP exchange."

Section 2.3

   most roaming implementations are relatively simple, relying on static
[BA]  s/static/a static/
   realm routing table which determine the next based on the NAI realm
[BA] s/next/next hop/
   included within the User-Name attribute.  Within RADIUS, the IP
[BA]   s/within the User-Name attribute/in the User-Name attribute within 
the Access-Request/

   service discovery including support for DNS as well as service
[BA]  s/discovery/discovery,/

Section 2.3.1

   an Internet host to determine whether it an reach a destination on
[BA] s/an reach/can reach/

Section 2.3.2

  originating a given proxy).
[BA] s/originating a given proxy/originating at a given proxy/

   NAI with a realm of"a.example.com".  However, the only way to obtain
[BA]  s/of"a/of "a/

   realm routing table is small and entries are static, Where the list
[BA]  s/Where/where/

   to this problem was readily available, then it could be applied to
[BA] s/was/were/

Section 2.4

   o  Access network identifier (e.g.  IEEE 802.11 SSID)

   o  Roaming relationships between the access network provider and
      other network providers and associated costs

   o  Authentication mechanisms

   o  Quality of Service capability

   o  Cost

   o  Service parameters, such as the existence of middleboxes

[BA] several of these items are not "characteristics... beyond those of
individual points of attachment".  For example, the access network
identifier, access network QoS are often learned from the advertisements
of the points of attachment.  Suggest rewriting to:

"  o  Roaming relationships between the access network provider and
      other network providers and associated costs

   o  EAP Authentication mechanisms

   o  Provisioned Quality of Service

   o  Cost

   o  Service parameters, such as the existence of middleboxes"

and moving the other ones to the points of attachment section (previously 
suggested)

   Network discovery focuses on the discovery of the services offered by
[BA] s/on the/on/

Section 3

   evaluating solutions for problem of network selection and discovery:
[BA]  s/for problem/to the problem/

Section 3.3

   Mechanisms that require depend on multicast frames need to be
[BA]   s/require//

Section 4

      the document become much harder to solve, in an automated way,
[BA]  s/solve,/solve/

      interoperable solutions may be deployed, resulting in
      fragmentation.

[BA] s/,resulting in fragmentation// (this doesn't seem to add much 
additional clarity)

   o  New link layer designs should include the efficient distribution
      of network and realm information as a design requirement.
[BA] s/include the efficient/include efficient/

      complete solution requiring support for extensions.
[BA] s/support for extensions/link layer extensions/

   o  Work is underway in IEEE 802.1, IEEE 802.21 and the IEEE 802.11u
[BA] s/and the/and/

      Solution to this problem would appear to require coordination
[BA] s/Solution/A solution/

      In addition, the ability of EAP to
      carry Quality of Service information
      [I-D.groeting-eap-netselection-results] appears limited.  As a
      result, we believe that use of EAP as described in [RFC4284] is
      not a sound long-term approach for solution of the realm discovery
      problem for mobile users where the information is needed for
      handoff purposes.

[BA] Suggest rewriting to:

"In addition, the extension of the realm advertisement mechanism
defined in [RFC4284] to handle advertisement of realm capability information 
(such as
QoS provisioning) is not recommended due to semantic and packet
size limitations [I-D.groeting-eap-netselection-results].  As a result,
we believe that extending the mechanism described in [RFC4284] for
discovery of realm capabilities is inappropriate."

Section 5

5.  IANA Considerations

   This document does not define any new name spaces to be managed by
   IANA.  This document does not either reserve any new numbers or names
   under any existing name space managed by IANA.

[BA] Change to "This document has no actions for IANA."

Section 6

   New EAP methods
   are doing it [I-D.josefsson-pppext-eap-tls-eap]
   [I-D.tschofenig-eap-ikev2], however, and there is even an attempt to

[BA] In fact, channel bindings are not supported in these methods, though 
they
could be.  Suggest changing to:

"EAP methods such as PEAP [I-D.josefsson-pppext-eap-tls-eap] and EAP-IKEv2
[I-D.tschofenig-eap-ikev2] may make this possible, however.  There is even
an attempt to"

   considered as a command or a hint.  For instance, the
   selection that the user provided may be ignored if it relates to AAA
   routing and the access network can route the AAA traffic to the
   correct home network using other means in any case.

[BA] I'd suggest that we be more specific here.  Suggest changing to:

"considered a mandate or a hint.  For example, realm hints may be ignored
by an EAP peer if they are incompatible with the security policy
corresponding to a selected access network."

8.1.  Normative References

[BA] All references should be informative.

8.2

              Resource Management", IEEE IEEE 802.11k, D4.1, July 2006.

[BA] This should be "IEEE 802.11k, D7.0, January 2007."

"IEEE IEEE" is used in multiple citations.  Suggest:

s/IEEE IEEE/IEEE/

Author's addresses

  Email: [email-masked]

s/[email-masked]/[email-masked]/

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bari, Farooq" <[email-masked]>
Date: Tue, 20 Mar 2007 10:35:31 -0700

Hi Bernard,

Regarding your Meta -question on Bearer Selection, I agree it was an
oversight that it was not specifically mentioned in the access network
capabilities. I propose to add an extra bullet to your proposed for that
section and thus change it from 

  "Along with discovery of points of attachment, capabilities of access
   networks are also typically discovered.  These may include:

   o  Quality of Service capabilities (e.g. IEEE 802.11e support)"

to the following text

  "Along with discovery of points of attachment, capabilities of access
   networks are also typically discovered.  These may include:

   o  Bearer capabilities (e.g. circuit switched, packet switched or
both)"

The remaining changes and editorial corrections are OK with me (thanks
for providing the cleanup of text in several places).

BR,

Farooq Bari
[email-masked]
+1 425 580 5526

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Monday, March 19, 2007 10:22 PM
> To: [email-masked]
> Subject: [eap] Issue 401: More NITs
> 
> Issue 401: More NITs

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 20 Mar 2007 16:11:00 -0700

Sounds good.

>From: "Bari, Farooq" <[email-masked]>
>To: "Bernard Aboba" <[email-masked]>,<[email-masked]>
>Subject: RE: [eap] Issue 401: More NITs
>Date: Tue, 20 Mar 2007 10:35:31 -0700
>
>Hi Bernard,
>