eap Mailing List: Re: Issue 401: More NITs

[Bernard Aboba (bernard_aboba]

Sounds good.


> From: "Bari, Farooq" <farooq.bari [at] cingular.com>
> To: "Bernard Aboba" <bernard_aboba [at] hotmail.com>,<eap [at] frascone.com>
> Subject: RE: [eap] Issue 401: More NITs
> 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  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)"
>
> to the following text
>
>   "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)
>
>    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
> farooq.bari [at] att.com
> +1 425 580 5526
>
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> > Sent: Monday, March 19, 2007 10:22 PM
> > To: eap [at] frascone.com
> > Subject: [eap] Issue 401: More NITs
> >
> > 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: aboba [at] internaut.com
> >
> > s/aboba [at] internaut.com/bernarda [at] microsoft.com/
> >
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.frascone.com/pipermail/eap