[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

©À
EAP                                                          W. Groeting
Internet-Draft                                                   S. Berg
Expires: January 10, 2005                                        M. Ness
                                                           H. Tschofenig
                                                              Siemens AG
                                                           July 12, 2004


                Network Selection Implementation Results
               draft-groeting-eap-netselection-results-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document aims to highlight implementation results on network
   discovery as well as some new ideas for its extension.  The
   implementation is based on the draft on mediating network discovery,
   a mechanism that enables a mobile node to discover roaming partners
   of an access network via EAP.  The concept allows automatic network
   selection of end hosts, based on additional parameters, hence
   reducing interacting with the user.This document should also open a



Groeting, et al.        Expires January 10, 2005                [Page 1]


Internet-Draft    Network Selection Implementation Results     July 2004


   discussion on the need on network capability mechanisms.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Concept Aspects  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Why has EAP been proposed to exchange this type of
           information  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2   Information from the Access Network  . . . . . . . . . . .  6
       2.2.1   Roaming Agreements . . . . . . . . . . . . . . . . . .  6
       2.2.2   Cost of network resource usage . . . . . . . . . . . .  7
       2.2.3   Quality of Services  . . . . . . . . . . . . . . . . .  7
       2.2.4   Authorisation Information  . . . . . . . . . . . . . .  7
       2.2.5   Privacy Policy . . . . . . . . . . . . . . . . . . . .  8
       2.2.6   Middlebox Devices  . . . . . . . . . . . . . . . . . .  8
   3.  Implementation Aspects and Test Environment  . . . . . . . . .  9
     3.1   Design of Information transmitted  . . . . . . . . . . . . 10
     3.2   Implementation at the AAA-Server . . . . . . . . . . . . . 11
     3.3   Implementation at the Supplicant . . . . . . . . . . . . . 13
     3.4   Test Platform  . . . . . . . . . . . . . . . . . . . . . . 14
       3.4.1   FreeRADIUS . . . . . . . . . . . . . . . . . . . . . . 14
       3.4.2   Xsupplicant  . . . . . . . . . . . . . . . . . . . . . 15
       3.4.3   Challenges . . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 21
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 22
   7.2   Informative References . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
   A.  Cost Attribute . . . . . . . . . . . . . . . . . . . . . . . . 25
     A.1   Cost-Header Attribute  . . . . . . . . . . . . . . . . . . 25
     A.2   Cost-Unit SubAttribute . . . . . . . . . . . . . . . . . . 26
     A.3   Example  . . . . . . . . . . . . . . . . . . . . . . . . . 27
   B.  QoS Attribute  . . . . . . . . . . . . . . . . . . . . . . . . 29
     B.1   UMTS QoS-Classes . . . . . . . . . . . . . . . . . . . . . 29
     B.2   QoS-Header Attribute . . . . . . . . . . . . . . . . . . . 29
     B.3   Example  . . . . . . . . . . . . . . . . . . . . . . . . . 30
       Intellectual Property and Copyright Statements . . . . . . . . 31











Groeting, et al.        Expires January 10, 2005                [Page 2]


Internet-Draft    Network Selection Implementation Results     July 2004


1.  Introduction

   Wireless LANs (WLAN) are receiving more attention as a complementary
   technology to 3G and there is an ever increasing number of hotspot
   deployments in areas such as airports and hotels.  Currently, these
   hotspots are managed by Wireless ISP (WISP) operators that do not
   have an existing cellular subscriber base.  Soon, WISP will provide
   WLAN access to a multiple number of mobile network providers.

   To support the selection of a Roaming enabled WISP, the mechanism for
   mediating network discovery, as described in
   [I-D.adrangi-eap-network-discovery], can be used.  This document
   highlights some implementation aspects of this draft and discusses
   some extensions to it.  These parameters could be, e.g., cost and
   quality of service information.  These parameters allow the end host
   to make a more intelligent network selection decision.

   The objectives of the draft are to show the need for and the
   advantages of network discovery.  It is primarily intended to trigger
   a discussion on a scalable network discovery mechanism, which will
   support end hosts regarding appropriate network selection.

   As the discussion has already been started within different
   organizations like 3GPP and IEEE, a discussion on the information
   transmitted as well as the mechanism itself needs to take place.  The
   authors would like to forward the discussion within the IETF by
   presenting some implementation findings and some ideas on not yet
   solved open issues.

   The draft is based on results of an implementation that covers one of
   the three options for mediating network discovery.  Next to the
   mediating networks additional parameters have been defined and
   encoded as described within this document.

   This document is structured as follows.  Section 2 covers the
   conceptual aspects and considered network information elements,
   followed by the implementation results in section 3.  Section 4
   covers the security considerations and finally a conclusion is given
   in section 5.  In the annex, some additional information on pricing
   and QoS issues is given.

1.1  Terminology

   authenticator

   The end of the link initiating EAP authentication.  The term
   authenticator is used in [IEEE-802.1X], and has the same meaning in
   this document.



Groeting, et al.        Expires January 10, 2005                [Page 3]


Internet-Draft    Network Selection Implementation Results     July 2004


   peer

   The end of the link that responds to the authenticator.  In
   [IEEE-802.1X], this end is known as the Supplicant.

   Supplicant

   The end of the link that responds to the authenticator in
   [IEEE-802.1X].  In this document, this end of the link is called the
   peer.

   backend authentication server

   A backend authentication server is an entity that provides an
   authentication service to an authenticator.  When used, this server
   typically executes EAP methods for the authenticator.  This
   terminology is also used in [IEEE-802.1X].

   AAA

   Authentication, Authorization, and Accounting.  AAA protocols with
   EAP support include RADIUS and Diameter.





























Groeting, et al.        Expires January 10, 2005                [Page 4]


Internet-Draft    Network Selection Implementation Results     July 2004


2.  Concept Aspects

   As the number of IEEE 802.11 wireless access networks proliferates,
   the support of roaming functionalities and thus the efficient
   exchange of mediating network information becomes more and more
   important [I-D.adrangi-eap-network-discovery].  Local WISPs are
   interested in offering their access points to a large number of users
   from other providers, and at the same time mobile operators are
   anxious to integrate WLAN access even through intermediary networks
   into their packet switched system.

   To support more intelligent end host decisions, it seems to be
   beneficial to discover certain characteristics about the network up
   front during the association and authentication phase.  Such
   information could include authentication models, roaming information,
   quality of service (see Appendix B) and cost parameters (see Appendix
   A).

2.1  Why has EAP been proposed to exchange this type of information

   The IETF draft by Adrangi et al.  [I-D.adrangi-eap-network-discovery]
   proposes a solution to transport mediating network information within
   the EAP protocol and thus enables 3GPP/WLAN interworking and roaming.

   EAP is a generic container protocol that can - in theory - carry any
   information desired by the network (as long as both sides of the
   information exchange understand the information that they are
   receiving).  It is an obvious choice for Layer 2 information exchange
   about network capabilities since it is highly likely that EAP will be
   implemented in both, the end host and the network.  However, when EAP
   is used in this fashion (i.e., beyond its original intention) it is
   important to note that there are possible impacts on security,
   scalability and the EAP state machine.

   One idea is to extend this mechanism to include extra data within
   Identity-Messages, e.g., requiring a certain bit rate or a certain
   quality of service.  If information can be carried in identity
   messages, then the end host can make further decisions based on it,
   before the full authentication procedure has been completed (and
   hence probably before accounting has started).  This is particularly
   useful for the case of cost and service availability information.

   However, it needs to be taken into account that an EAP identity
   message, including any information carried within, is not protected.
   In addition, if the amount of exchanged information is too large then
   performance characteristics of EAP as an information transport
   protocol will become a limitation.




Groeting, et al.        Expires January 10, 2005                [Page 5]


Internet-Draft    Network Selection Implementation Results     July 2004


2.2  Information from the Access Network

   The end host can retrieve information about the access network
   dynamically when it moves into coverage of that network.  This
   information is retrieved via a link layer network capability
   discovery mechanism.  Each piece of information may or may not have
   an effect on whether or not the end host attaches to and
   authenticates with that network.

   As already proposed in [I-D.adrangi-eap-network-discovery] the
   discovery of roaming agreements and mediating networks is a valuable
   access network information.  This can be extended by other access
   network information elements like costs and charging, quality of
   service, authorization information, privacy policy and middlebox
   devices, which help the end host to make his attachment decision.

   The information required within multimode end hosts to support
   efficient interface selection and network capability discovery
   algorithms are classified according their importance.  Mandatory
   indicates that this should be included in near term implementations
   of the algorithms, optional indicates that the availability of this
   information improves the quality of the algorithm decisions, but is
   not vital to its operation.

   The time of information discovery is classified related to the moment
   of association, i.e.  the establishment of medium access control
   (MAC) transport services between access point/station (AP/STA), and
   authentication, the service used to establish the identity of one
   station as a member of the set of stations authorized to associate
   with another station [IEEE-SPEC-99].

   The expected lifetime of the information, i.e.  how frequently this
   information is updated and how persistent the information is within
   the end host, is characterized by the following categories:

      Duration of session: the information is only valid for the
      lifetime of the session of an application with which it is
      associated
      Duration of attach: the information is only valid for the lifetime
      of the interface attachment to that AN.
      Inter-attach: the information is stored between attachments to an
      AN, but will timeout after some defined period.

2.2.1  Roaming Agreements

   This information specifies what roaming agreements are in place in
   the network.  It allows the mobile node to determine whether it can
   authenticate with the network, and which subscription credentials to



Groeting, et al.        Expires January 10, 2005                [Page 6]


Internet-Draft    Network Selection Implementation Results     July 2004


   use.

      Importance: Mandatory for authentication purpose
      When discovered: Pre-authentication
      How dynamic: Inter-attach

2.2.2  Cost of network resource usage

   This information provides hints to the user device about the cost of
   using this network.  It is useful to support mobile nodes that base
   network selection services on more complex policies based on user
   preferences, such as always use the cheapest.  The cost information
   provided by the access network can be manifold.  It includes
   information on the access network itself, cost information of roaming
   partners, different charging modes (per data, per time, per service,
   flat) and other information like the amount, currency, number of
   units, etc.  The definition of an appropriate data format is subject
   of further investigation

      Importance: Optional
      When discovered: Preferably pre-authentication
      How dynamic: Inter-attach

2.2.3  Quality of Services

   Each network may support different levels of quality of service (e.g.
   there are four QoS classes in 3GPP) that can support different data
   rates.  The multimode end host may be required to make decisions
   about whether or not to attach to a network based on what QoS can
   offer.

      Importance: Optional, this is a useful hint, especially for
      handover scenarios
      When discovered: Pre-authentication
      How dynamic: Inter-attach

2.2.4  Authorisation Information

   The AN will receive information from the home network about what the
   user is authorized to access and for how long.  If this information
   can be transferred to the MT then it can be used to make informed
   decisions e.g.  about interface selection - there is no point
   choosing to use an interface if it is about to become idle because
   the time for which it is authorized is nearly finished.  It would
   also be useful for feedback to the user.  As this information might
   belong to a particular user, it needs further investigation on how to
   secure such kind of information.  A plain authorization information
   advertisement seems rather difficult to realize.



Groeting, et al.        Expires January 10, 2005                [Page 7]


Internet-Draft    Network Selection Implementation Results     July 2004


      Importance: Optional
      When discovered: Pre-authentication
      How dynamic: Duration of Session

   The functionality required to obtain this information is quite
   complex and does not yet exist so this information is considered to
   be optional at the moment.

2.2.5  Privacy Policy

   Access networks have the ability to monitor the users behaviors with
   regard to their application layer usage (e.g., HTTP or SIP) and to
   create user specific profiles.  Many network access authentication
   protocols allow networks to learn the user identity since
   authentication and key exchange protocols which support user identity
   confidentiality are rarely used.  The increasing deployment of
   location based services creates an additional privacy threat for end
   users.  Similarly to the privacy initiatives in the web environment
   additional information about the privacy policy of an access network
   can be communicated.  Such indication might reveal an end user that a
   particular network does not distribute location information to the
   user's home network during network access authentication, location
   information is not provided to third parties other than the network
   or that no application specific information is provided to third
   parties.

      Importance: Optional
      When discovered: Pre-authentication
      How dynamic: Duration of attach

2.2.6  Middlebox Devices

   There are several types of applications that do not operate well if
   there is a NAT or firewall between communicating hosts/servers.  Some
   examples of such applications are games, VoIP applications, H323/SIP,
   some instant message applications, and quality of service signaling
   protocols such as RSVP.

   Consequently, the end host may need to know whether there are any
   middlebox devices, e.g.  firewalls and NATs present in the AN in case
   the user wants to use applications that have a problem with them.  A
   network without a middlebox device would be preferable.

      Importance: Optional
      When discovered: Pre-authentication
      How dynamic: Duration of attach





Groeting, et al.        Expires January 10, 2005                [Page 8]


Internet-Draft    Network Selection Implementation Results     July 2004


3.  Implementation Aspects and Test Environment

   In Section 3 of [I-D.adrangi-eap-network-discovery] three options for
   delivering mediating network information with EAP are proposed.  Each
   of these options uses a Identity-Request to submit this information.
   Only option 3 can be implemented without any modification of the AP
   and with every AP which is IEEE 802.1x enabled.  Option 3 uses only
   the AAA server to transmit information to the end host (i.e.,
   supplicant) rather than a modified access point.  Hence, the authors
   think that this approach works for most existing systems.  Lower
   effort and costs of implementation and better backwards compatibility
   are the reasons to favor this option for an implementation.

   Figure 1 demonstrates the information exchange between supplicant, AP
   and AAA server when implementing the preferred solution:

       Wireless         AP            AN RADIUS
        Client                         server
          |     (1)      |                |
          | EAP Id. Req. |                |
          |< ------------|                |
          |              |                |
          |    (2)       |                |
          | EAP Id. Resp.|                |
          |------------ >|     (3)        |
          |              |Access Request  |
          |              |(EAP Id. Resp.) |
          |              |-------------- >|
          |              |                |
          |              |     (4)        |
          |              |Access Challenge|
          |              |(EAP Id. Req. + |
          |              | (Network Info) |
          |    (5)       |< --------------|
          | EAP Id. Req. |                |
          |(Network Info)|                |
          |< ------------|                |
          |              |                |
          |    (6)       |                |
          |EAP Id. Resp. |                |
          |              |                |
          |------------ >|    (7)         |
          |              |Access Request  |
          |              |(EAP Id. Resp.) |
          |              |-------------- >|
          |   ...        |     ...        |
          |< EAP Authentication Methods > |
          |   ...        |     ...        |



Groeting, et al.        Expires January 10, 2005                [Page 9]


Internet-Draft    Network Selection Implementation Results     July 2004


          |              |                |
          |    (8)       |                |
          | EAP Success  |                |
          |< ------------|                |


  Figure 1: Option 3: Use a subsequent EAP-Identity Request issued by
                    the access network RADIUS server

   Based on this model the following subchapters explain the
   implementation in a working test environment.

3.1  Design of Information transmitted

   Beneath the definition of a Netinfo-Packet, which offers the
   possibility to check if the Data field in an EAP packet is used for
   network information, the syntax for the network information has to be
   defined, too.

   In [I-D.adrangi-eap-network-discovery] the following syntax is
   proposed: network-info = attribute "=" value.  for just transmitting
   the names of the mediating networks, this syntax is useful.  When
   offering e.g.  six attributes about three mediating networks there
   occurs a problem with the space available in the EAP packet.  A
   solution to that problem is to send the network information in a
   defined order, seperated with a defined delimiter.  Figure 2 is a
   possible way to transmit information about: the name of the mediating
   network, the cost of the mediating network, roaming agreements,
   quality of service , middlebox information and authorisation
   information (in this exemplary for three mediating networks):





















Groeting, et al.        Expires January 10, 2005               [Page 10]


Internet-Draft    Network Selection Implementation Results     July 2004


           _______________________
          |       |       |       |
          |  MN1  |  MN2  |  MN3  |          MN: Mediating Network
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  C1   |  C2   |  C3   |          C:  Cost
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  RA1  |  RA2  |  RA3  |          RA: Roaming Agreements
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  QS1  |  QS2  |  QS3  |          QS: Quality of Service
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  MI1  |  MI2  |  MI3  |          MI: Middlebox Information
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  AI1  |  AI2  |  AI3  |          AI: Authorisation Information
          |       |       |       |
          |-------|-------|-------|
          |       |       |       |
          |  PP1  |  PP2  |  PP3  |          PP: Privacy Policy
          |       |       |       |
           -----------------------

                Figure 2: Matrix for Network Information

   Converted into a string this data looks like (used "," as delimeter
   between attributes and ";" as delimeter between values):
   network-information=MN1;MN2;MN3,Cost1;Cost2;Cost3,
   RA1;RA2;RA3,QS1;QS2;QS3,MI1;MI2;MI3,AI1;AI2;AI3,PP1;PP2;PP3

   Beneath the benefit of saving valuable space in the EAP packet this
   syntax has one disadvantage: to interpret the data on supplicant side
   correct, from all mediating networks all parameters have to be
   transmitted.  If none of the mediating networks offers a specific
   parameter, this parameter has to be transmitted as a NULL.

3.2  Implementation at the AAA-Server

   In an authentication process the AAA-Server normally receives an
   Access Request/Identity-Response which is sent by the supplicant and
   passed trough by AP.  As response to this message the AAA-Server has



Groeting, et al.        Expires January 10, 2005               [Page 11]


Internet-Draft    Network Selection Implementation Results     July 2004


   to react with an Access Challenge including the start sequence for
   the chosen EAP authentication method.  At this point we have to
   intervene and query which packet to send now.  Figure 3 shows the
   possible decisions:


                    -----------
                   | incoming  |
                   | Id. Resp. |
                   |___________|
                         |
                         |
                         V
                        ____
                       /    \
                      /realm \  yes
                     |       |-----------------------|
                      \known /                       |
                       \____/                        |
                         |                           |
                         | no                        |
                         V                           |
                        ____            ____         |
                       /    \          /    \        |
                      /decor.\  yes   / MN   \ yes   |
                     |       |------>|       |------>|
                      \ NAI  /        \known /       |
                       \____/          \____/        |
                         |               |           |
                         | no            | no        |
                         V               |           V
                    -----------          |      -----------
                   | send Id.  |         |     |   start   |
                   | Req. with |<--------|     | Authentic.|
                   |    NI     |               |   method  |
                   |___________|               |___________|



            Figure 3: Decision on incoming Identity-Response

   There are three queries to be done for knowing, how to react on an
   incoming Identity-Response:

   o  Check if the realm submitted with the username is known
   o  Check if the username includes a decorated-nai
   o  Check if the mediating network submitted with the decorated-nai is
      known



Groeting, et al.        Expires January 10, 2005               [Page 12]


Internet-Draft    Network Selection Implementation Results     July 2004


   If any of this queries can be answered with "yes" the normal
   authentication process can be started.  Otherwise an Access Challenge
   including an EAP Identity-Request which submits mediating network
   information has to be sent [I-D.adrangi-eap-network-discovery].

   One thing missing in this behaviour model is the reaction on an
   Identity-Response which arrives the second time - without having
   changed anything in username attribute.  For this reason a counter
   has to be inserted into FreeRADIUS-code which makes it possible to
   check for packets who are arriving more than one time.  As proposed
   in [I-D.adrangi-eap-network-discovery] the AAA-Server has to handle
   these packets based on the local routing policy.  In fact the
   AAA-Server SHOULD discard these packets and send an EAP Failure
   packet which stops the authentication process.

   This proceeding modifies the AAA-Server that way, that he is still
   able to handle authentication request from unmodified supplicants
   (they only have send a valid realm or mediating network).  Also
   supplicants which send an Identity-Response including a valid
   decorated-nai directly, do not have to receive an additional
   Identity-Request because they already chose the mediating network.

3.3  Implementation at the Supplicant

   At supplicant side there is also one point where it makes most sense
   to implement a query when to send a decorated-nai.  This is on every
   incoming Identity-Request.  For example all incoming
   Identity-Requests could be checked for their size, and then be
   interpreted or not.

   Next step is to validate the data which received.  Therefore header
   information which came with the possible network information should
   be interpreted.  Figure 4 shows the possible design of a
   Netinfo-Packet:

           1 byte       2 bytes      1 byte
         |------- |----------------|------- |
         |  Type  |   Length       |   NoM  |
         |--------|----------------|--------|
         |  Data                            |
         |----------------------------------|

                  Figure 4: Design of a Netinfo-Packet

   o  "Type" is a 1 byte long field which defines of which version the
      network information are (e.g.: Type 1 could only include
      information about the names of the mediating networks.  Whereas
      Type 2 includes informations like e.g.  costs, too).



Groeting, et al.        Expires January 10, 2005               [Page 13]


Internet-Draft    Network Selection Implementation Results     July 2004


   o  "Length" is 2 bytes long and contains the length of the string
      included in the Data-field
   o  "NoM" is also 1 byte long and defines the number of mediating
      networks, which are transmitted with that packet.
   o  "Data" contains a string with the network information

   After the correctness of the network information is confirmed, the
   data can be processed.  Which data is exactly interpreted depends on
   the preferences the user made, e.g.  the setting "Always cheapest
   connected" may only interpret "cost" and leave the rest unregarded.

   Of importance is only, that the algorithmus comes to a decision if to
   proceed authenticating to the access network and which mediating
   network to choose.

   If it decides not to continue with authenticating process, the
   supplicant SHOULD send an EAP logoff packet.  Else an
   Identity-Response has to be sent, which includes a decorated-nai as
   username.  Part of this decorated-nai is the chosen mediating
   network.

3.4  Test Platform

   To ensure that this approach described before is not only of
   theoretic nature it was necessary to build up a test system.  This
   test platform consists of an AAA-Server, an AP and a supplicant.  The
   following two subchapters give some hints on the installation,
   configuration and modification of these three network components.

   The aim of this implementation was not to develop a product ready for
   market, but to point out that it is possible to realize the proposal
   suggested by Adrangi and in this draft.  Hence the way for
   implementing was not to completly new develop all software, but to
   find the shortest way for realization.  This recommends to use
   existing software, which is published under the GPL and therefore can
   be modified.

3.4.1  FreeRADIUS

   FreeRADIUS is an AAA-Server which was former developed as Cistron
   RADIUS server and is now the leading AAA-Server developed for Linux
   under the GPL.  The sources are available for download at
   http://www.freeradius.org/.

   FreeRADIUS has a module for EAP authentication.  The sources for this
   module can be found in the directory src/modules/rlm_eap/.  All
   necessary modifications to FreeRADIUS has to be done in this
   directory.



Groeting, et al.        Expires January 10, 2005               [Page 14]


Internet-Draft    Network Selection Implementation Results     July 2004


3.4.2  Xsupplicant

   There are not many IEEE 802.1x implementations available for Linux
   right now.  Xsupplicant seems to be the most popular at the moment.
   Xsupplicant is available for download at http://www.open1x.org/.  It
   is also developed under GPL.  Xsupplicant is not a full
   RADIUS-client, it is only ready for EAP authentication.

3.4.3  Challenges

   While implementing one problem occured: the second Identity-Response
   from Supplicant (which is the one with the Decorated-NAI inside) does
   not arrive at the AAA-Server.  Because the packet leaves the
   Supplicant and cannot be discovered at the AAA-Server at all, the
   packet seems to get lost at the AP.

   Analysis on the AP (via Telnet a lot of debugging on the AP is
   possible) resulted, that the Identity value of the Identity-Response
   is not the one expected by the AP.  It looks like the AP does not
   store the Identity of the Identity-Request sent by the AAA-Server.
   When the Identity-Response to that request arrives at the AP the
   reaction is right: the message is blocked.

   The solution is to prevent the AAA-Server from increasing the
   Identity value in the EAP packet, when sending the second
   Identity-Request.  Hence it is sent with the same Identity like the
   original Identity-Request and the AP lets the Identity-Response to
   that packet pass.























Groeting, et al.        Expires January 10, 2005               [Page 15]


Internet-Draft    Network Selection Implementation Results     July 2004


4.  Security Considerations

   [I-D.ietf-eap-netsel-problem] tries to classify the problem space of
   network selection:

   Access Network discovery:

      Access Network discovery is concerned about the selection of a
      particular network (if multiple access networks are available)
      based on a number of parameters.  This section mainly focuses on
      the security implication of this particular aspect.

   Identifier selection:

      Identifier selection plays a role when an end user has more than
      one identifier to select from.  The selected identifier might
      impact the selected roaming partner of the attached network and
      thus might have cost and performance implications.  In some sense
      this is a policy-based routing mechanism with interesting impacts
      on the traditional Internet pricing where the edge pricing between
      neighboring networks was excercised.  In more sophisticated
      scenarios one might imagine that IP packets are routed by the
      access network through different ISPs depending on some
      classifiers in the packet (such as DiffServ codepoints or
      particular destination IP addresses).  The security properties are
      not well understood for these scenarios.  As an example, one might
      consider a moving network which has to change its roaming partners
      over time based on mobility.  How should the end host be notified
      about the possible implication on the cost? Should the user be
      re-authorized? How should the user be certain that such a provider
      change was actually necessary?

   AAA routing:

      After selecting a particular identifier, the NAI is used to route
      the AAA messages back to the home network (possibly via some
      intermediate brokers).  No dynamic routing protocols are available
      for AAA routing and the selection of a particular route might have
      impacts on the price.  This issue is mostly outside the scope of
      this document.

   Payload routing:

      As part of the authorization information provided by the home AAA
      server the routing and treatment of packets might be affected.
      The payload route binding problem refers to mismatch between the
      routing of IP packet and the hinted (or offered) route.  It needs
      to be studied whether this is truly a problem.  This issue is



Groeting, et al.        Expires January 10, 2005               [Page 16]


Internet-Draft    Network Selection Implementation Results     July 2004


      outside the scope of this document.

   There is a risk that a large number of service providers with complex
   roaming agreements create a non-transparent service and
   cost-structure.  In a traditional subscription-based scenario users
   are registered with their home networks and use this trust
   relationship to dynamically establishment a financial settlement
   between the home and the visited network and required security
   associations (for example to provide link layer security between the
   end host and an entity in the visited network such as the access
   point).  This is the typical AAA deployment scenario.  In such a
   scenarios users do not learn the identity of the access network as
   part of a regular authentication and key exchange protocol message
   exchange.  The usage of EAP the Extensible Authentication Protocol in
   IEEE 802.1x/IEEE 802.11i or also PANA never aimed to allow
   authentication of the access network to the end host.  As such, the
   identity of the access network is not revealed (in a secure fashion).
   The user is therefore only authenticated to the home network (and
   hopefully vice versa).  This design decision is also reflected in the
   choice of identifier space used in the WLAN IEEE 802.11 environment.
   The Service Set Identifier (SSID) does not mandate a structure and
   hence is not really suitable as an identifier to perform
   authentication and authorization.  Overloading the SSID as an
   identifier to indicate particular services is attractive, but fails
   in most cases.  In fact, most administrators of WLANs do not change
   the default SSID (see for example [Pri04] for a study about WLAN
   usage in London where approximately 40% of the access points are
   running their default SSID.) Such an approach makes the phone book
   (see [RFC3017]) approach (as an out-of-band mechanism to associate a
   particular service to an identifier) difficult to deploy.  The
   approach of assisting with the selection of the appropriate
   certificate based on a list of SSIDs as described in [RFC3770] will
   also fail.  Apart from this fact, the authentication and
   authorization message exchange between the end host and the home
   network is, for the subscription-based environment, required.  Public
   key based authentication between the end host and the access network
   cannot replace the exchange between the end host and the home network
   due to the need for a financial compensation.  Hence, authentication
   of the access network, if possible, could only aim to securely
   exchange parameters between the end host and the visited network.
   This draft discusses some of these parameters or objects (such as
   cost or QoS parameters).  Several approaches are possible to address
   the problem of protecting the distributed information.

   First, the access network might "broadcast" (or distribute)
   information about the offered service (price, QoS, etc.).  End hosts
   process this information automatically and make their decision.  The
   access network might lie about the offered price (to the user) since



Groeting, et al.        Expires January 10, 2005               [Page 17]


Internet-Draft    Network Selection Implementation Results     July 2004


   this information is not protected by any means.  The access network
   provide could charge the user more than "agreed".  It would be
   possible to verify the broadcasted information by utilizing the same
   mechanism as proposed with the 'lying NAS' problem.  This mechanism
   requires that the distributed information can be securely exchanged
   between the EAP peer (end host) and the EAP server (user's home
   network) within an EAP method.

   Second, the access network could be authenticated before user
   authentication takes place.  This would allow to securely exchange
   parameters between the access network and the user and to even allow
   the user to provide more information about the offered services to
   the user.  The following message exchange may be reasonable:

   Alice wants to attach to one of the access networks found.  She
   establishes a secure tunnel based on unilateral (network to user
   authentication).  Then she would like to know what services are
   offered by this network.  Subsequently, if she is happy about the
   offered price she decides to authenticate herself to the home network
   (by selecting a particular identifier and the corresponding
   credentials) to establish the necessary financial relationship
   between the home and the visited network.

   This type of service is provided by today's hotspots with web
   interfaces.  The usage of virtual access points or authentication at
   a highly layer (such as PANA) comes into mind when higher security
   other than packet filters are desired.  This mechanism, however,
   requires user interaction and is therefore slow and error-prone.
   This process can of course be provided by protocols.  Today there is
   no standardized protocol available which allows users to exchange
   information about offered and desired services, to communicate cost
   limits, to request cost information for network resources or to learn
   already accumulated costs.

   Authentication of the visited network requires some sort of
   server-side PKI which might not be available.  Additionally,
   providing public key based authentication and the subsequent protocol
   exchange requires some time which causes delays during the network
   access procedure.

   Even with the last approach it is still possible for the network to
   return incorrect charging information to the user's home network.
   Performing a higher number of re-authentication steps which are
   associated to a maximum amount each (similar to the idea proposed by
   micro-payment protocols) can help to give the user more control over
   his / her expenses.

   Especially in roaming environments where an end host is likely to



Groeting, et al.        Expires January 10, 2005               [Page 18]


Internet-Draft    Network Selection Implementation Results     July 2004


   have access to a large number of visited networks within a short time
   period cost control is even more complicated.  User interaction might
   not be highly desireable.  In fact these issues are a show-stopper
   for seamless mobility.

   It might be worth mentioning that the issues and problems of cost
   control has already been identified in the NSIS working group some
   time ago in the context of Quality of Service signaling where the
   problems go beyond those described in this document (and with network
   selection as well).

   As a summary, to provide a short-term solution the authors suggest to
   provide a mechanism to exchange information about the offered and the
   desired service between the end host and the access network.
   Subsequently, this information has to be repeated both in the EAP
   method and the AAA infrastructure to give the user and the home
   network the ability to detect fraud.  This proposal has not been
   verified by the current implementation and hence needs further
   assessment.
































Groeting, et al.        Expires January 10, 2005               [Page 19]


Internet-Draft    Network Selection Implementation Results     July 2004


5.  Conclusion

   This document presents some implementation results, which are
   considered to be suitable and useful for future implementations and
   extensions.  The authors think that the mechanism proposed by
   [I-D.adrangi-eap-network-discovery] is suitable as network discovery
   for mediating network discovery.  However, while implementing the
   proposed mechanism some irregularity towards the behavior of the
   Access point have been found and described.  An implementation
   specific solution has been presented.  Additional access network
   information elements like QoS and costs have been introduced,
   evaluated and implemented to prove the performance of the mechanism
   to convey network capablilities.  The set of information identified
   is not considered as a complete approach and is mainly intended to
   trigger further discussion.  The same holds for the exact data
   formats which are for further study.  The security evaluation on
   network selection discovered some fields, which are not well
   understood so far and hence need further assessment.  A proposal has
   been given for an increased security level for network discovery.

   The interoperability between unmodified and modified end hosts and
   AAA-Servers is given.  AAA-Servers that are not modified do not send
   an additional Identity-Request, but directly authenticate the user.
   End hosts have to sent a valid Decorated-NAI from the beginning.
   Then the AAA-Server authenticates the end host without any new
   Identity-Request.

























Groeting, et al.        Expires January 10, 2005               [Page 20]


Internet-Draft    Network Selection Implementation Results     July 2004


6.  Acknowledgement

   The authors would like to thank Eleanor Hepworth, Dirk Kroeselberg
   and Stephen McCann for their comments.















































Groeting, et al.        Expires January 10, 2005               [Page 21]


Internet-Draft    Network Selection Implementation Results     July 2004


7.  References

7.1  Normative References

   [I-D.adrangi-eap-network-discovery]
              Adrangi, F., Lortz, V., Bari, F., Eronen, P. and W.
              Watson, "Mediating Network Discovery in the Extensible
              Authentication Protocol (EAP)",
              draft-adrangi-eap-network-discovery-01 (work in progress),
              June 2004,
              <reference.I-D.adrangi-eap-network-discovery.xml>.

   [I-D.ietf-eap-netsel-problem]
              Arkko, J. and B. Aboba, "Network Discovery and Selection
              Problem", draft-ietf-eap-netsel-problem-00 (work in
              progress), January 2004,
              <reference.I-D.ietf-eap-netsel-problem.xml>.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", September 2001, <reference.IEEE-802.1X.xml>.

7.2  Informative References

   [3GPP TS23.107]
              3rd Generation Partnership Project, "3rd Generation
              Partnership Project; Technical Specification Group
              Services and System Aspects; Quality of Service (QoS)
              concept and architecture (Release 6)", Technical
              Specification 3GPP TS 23.107 V6.1.0 (2004-03), March 2004,
              <reference.3GPP TS23.107.xml>.

   [GRJK00]   Gerke, J., Ritter, H., Schiller, J. and K. Wehrle,
              "Elements of an open framework for pricing in the future
              internet, in Proceedings of the Conference on Quality of
              future Internet Services (QofIS 2000), pages 300--311,
              Berlin", 2000, <reference.Paper.GRJK00>.

   [I-D.arkko-eap-service-identity-auth]
              Arkko, J. and P. Eronen, "Authenticated Service Identities
              for the Extensible Authentication Protocol (EAP)",
              draft-arkko-eap-service-identity-auth-00 (work in
              progress), April 2004,
              <reference.I-D.arkko-eap-service-identity-auth.xml>.

   [I-D.caron-aaa-cost-advertisement]
              Caron, J., "AAA cost advertisement extensions",



Groeting, et al.        Expires January 10, 2005               [Page 22]


Internet-Draft    Network Selection Implementation Results     July 2004


              draft-caron-aaa-cost-advertisement-00 (work in progress),
              June 2002,
              <reference.I-D.caron-aaa-cost-advertisement.xml>.

   [I-D.heckmann-tdp]
              Heckmann, O., "Tariff Distribution Protocol (TDP)",
              draft-heckmann-tdp-00 (work in progress), March 2002,
              <reference.I-D.heckmann-tdp.xml>.

   [I-D.prasanna-bip]
              Prasanna, R., "BIP: Billing Information Protocol",
              draft-prasanna-bip-00 (work in progress), December 2002,
              <reference.I-D.prasanna-bip.xml>.

   [I-D.tschofenig-eap-ikev2]
              Tschofenig, H., Kroeselberg, D. and Y. Ohba, "EAP IKEv2
              Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-02 (work
              in progress), October 2003,
              <reference.I-D.tschofenig-eap-ikev2.xml>.

   [IEEE-SPEC-99]
              Institute for Electric Engineers, "IEEE802.11 Spec 1999
              Edition", Technical Specification IEEE802.11 Spec 1999
              Edition, 1999, <reference.IEEE-SPEC-99.xml>.

   [ISO4217]  International Organization for Standardization, "Codes for
              the representation of currencies and funds", ISO Standard
              4217, August 2001.

   [KSS98]    Karsten, M., Schmitt, J. and R. Steinmet, "An embedded
              charging approach for RSVP, in International Workshop on
              Quality of Service '98. Napa, California, USA", May 1998,
              <reference.Paper.KSS98>.

   [ORW00]    Oberle, V., Ritter, H. and K. Wehrle, "Bpp: A protocol for
              exchanging pricing information between autonomous systems,
              in Proceedings of HPSR 2001 (IEEE Workshop on
              High-Performance Switching and Routing), Dallas (USA)",
              May 2001, <reference.Paper.ORW00>.

   [Pri04]    Priest, J., "The State of Wireless London, available at
              'http://www.spacestudios.org.uk/content/articles/461.pdf'
              (July 2004)", March 2004.

   [RFC3017]  Riegel, M. and G. Zorn, "XML DTD for Roaming Access Phone
              Book", RFC 3017, December 2000, <reference.RFC.3017.xml>.

   [RFC3770]  Housley, R. and T. Moore, "Certificate Extensions and



Groeting, et al.        Expires January 10, 2005               [Page 23]


Internet-Draft    Network Selection Implementation Results     July 2004


              Attributes Supporting Authentication in Point-to-Point
              Protocol (PPP) and Wireless Local Area Networks (WLAN)",
              RFC 3770, May 2004.

   [RNAP]     Wang, X. and H. Schulzrinne, "Rnap: A resource negotiation
              and pricing protocol, in International Workshop on Network
              and Operating Systems Support for Digital Audio and Video
              (NOSSDAV'99), pages 77--93, Basking Ridge, New Jersey",
              1999, <reference.Paper.RNAP>.


Authors' Addresses

   Wolfgang Groeting
   Siemens AG, ICM MP PD TI 2
   Frankenstrasse 2
   46395 Bocholt
   Germany

   EMail: Wolfgang.Groeting@siemens.com


   Stefan Berg
   Siemens AG, ICM MP PD TI 2
   Frankenstrasse 2
   46395 Bocholt
   Germany

   EMail: Stefan.Berg@siemens.com


   Malte Ness
   Siemens AG, ICM MP PD TI 2
   Frankenstrasse 2
   46395 Bocholt
   Germany

   EMail: Malte.Ness@bch.siemens.de


   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany

   EMail: Hannes.Tschofenig@siemens.com




Groeting, et al.        Expires January 10, 2005               [Page 24]


Internet-Draft    Network Selection Implementation Results     July 2004


Appendix A.  Cost Attribute

   To be more specific about the proposed attributes in Section 2.2.2.
   In the past various drafts have proposed to include cost specific
   into protocols (such QoS signaling protocols, AAA protocols or SIP).
   The flexibility of the proposals varies a simple cost attribute, to
   complex formulas and even JAVA classes which allow sophisticated
   price calculation.  From the investigated proposals (including TDP
   [I-D.heckmann-tdp], RNAP [RNAP], BIP [I-D.prasanna-bip], BPP [GRJK00]
   and [ORW00], [KSS98] ) [I-D.caron-aaa-cost-advertisement] was simple
   enough to be reused for our purpose.

   We use the following attributes, Cost-Header attribute and one or
   more Cost-Unit subattribute for encoding this type of information.

A.1  Cost-Header Attribute


       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Type          | Length        | Decimals          |No-of-AVPs |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Currency-Code                                                ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


























Groeting, et al.        Expires January 10, 2005               [Page 25]


Internet-Draft    Network Selection Implementation Results     July 2004


     Type:

       To Be Assigned by IANA

     Length:

       Indicates the length of this header attribute in bytes.

     No-of-AVPs (6 bits):

       This field points to the number of Cost-Unit attributes
       following the header attribute.

     Decimals (10 bits)

       Indicates where to place the comment in all subsequent units.
       For example, if Decimals is set to 2 then a value of
       199 means 1.99. The value of '0' indicates that no decimal should
       set. The value should be read as it is.

     Currency-Code (3 - 6 Bytes):

       The value field of the Currency-Code attribute is of type "string"
       and indicates the currency to be applied to the Cost value as
       indicated by the Cost attribute. The string value for a single
       currency is defined in ISO 4217.


A.2  Cost-Unit SubAttribute

   The Cost-Header attribute, described in Appendix A.1, is followed by
   one or more Cost-Unit subattributes.


       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | SubType       | Quantity                      |  Repeat      ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Repeat       | Amount                                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+










Groeting, et al.        Expires January 10, 2005               [Page 26]


Internet-Draft    Network Selection Implementation Results     July 2004


     SubType:

       1  Time-based chargig: billing is based on duration in seconds
       2  Volume-based charging: billing is based on total bytes

     Quantity:

       Quantity is the number of seconds or bytes that this amount will
       cover. 0 means none, and all ones means unlimited.

     Repeat:

       Repeat is the number of times this unit will be repeated before
       moving on to the next one. 0 means unlimited.

     Amount:

       Amount is the amount of money that should be billed. The value
       stored here should be divided by 10^decimals to get the number of
       currency units.


A.3  Example

   To express the network cost for 10 EUR (independent of the time) the
   following payload has to be transmitted.

     Cost-Header AVP:

       Type = IANA assigned
       Length = 5
       Decimals = 0
       No-of-AVPs = 1
       Currency-Code = EUR (3 bytes)

     Cost-Unit:

       SubType = 1 (Time-based charging)
       Quantity = all ones (means unlimited)
       Repeat = 0 (unlimited)
       Amount = 10

   More complex, non-linear pricing schemes can also be expressed by
   listing several Cost-Unit attributes.  For example, to express a
   pricing policy where 2 EUR are charged for the first 30 minutes and
   then 0.02 EUR for every further minute.





Groeting, et al.        Expires January 10, 2005               [Page 27]


Internet-Draft    Network Selection Implementation Results     July 2004


     Cost-Header AVP:

       Type = IANA assigned
       Length = 5
       Decimals = 2
       No-of-AVPs = 2
       Currency-Code = EUR (3 bytes)

     Cost-Unit:

       SubType = 1 (Time-based charging)
       Quantity = 1800 (60 * 30 minutes)
       Repeat = 0 (no repeat)
       Amount = 200

     Cost-Unit:

       SubType = 1 (Time-based charging)
       Quantity = 60 (60 seconds)
       Repeat = 0 (unlimited)
       Amount = 2

   The transport of these attributes within RADIUS or Diameter and via
   an EAP protoocol (see an example in [I-D.tschofenig-eap-ikev2] and
   the generalized version in [I-D.arkko-eap-service-identity-auth]) are
   not described in this document.

























Groeting, et al.        Expires January 10, 2005               [Page 28]


Internet-Draft    Network Selection Implementation Results     July 2004


Appendix B.  QoS Attribute

   In Section 2.2.4.  it was proposed to indicate supported QoS classes.
   To be more specific, the UMTS classes, defined in [3GPP TS23.107],
   could be used.

B.1  UMTS QoS-Classes

   There are four different QoS classes defined in [3GPP TS23.107]:
      conversational class
      streaming class
      interactive class
      background class

   The main distinguishing factor between these QoS classes is how delay
   sensitive the traffic is: Conversational class is meant for traffic
   which is very delay sensitive while Background class is the most
   delay insensitive traffic class.

   Conversational and Streaming classes are mainly intended to be used
   to carry real-time traffic flows.  The main divider between them is
   how delay sensitive the traffic is.  Conversational real-time
   services, like video telephony, are the most delay sensitive
   applications and those data streams should be carried in
   Conversational class.

   Interactive class and Background are mainly meant to be used by
   traditional Internet applications like WWW, Email, Telnet, FTP and
   News.  Due to looser delay requirements, compare to conversational
   and streaming classes, both provide better error rate by means of
   channel coding and retransmission.  The main difference between
   Interactive and Background class is that Interactive class is mainly
   used by interactive applications, e.g.  interactive Email or
   interactive Web browsing, while Background class is meant for
   background traffic, e.g.  background download of Emails or background
   file downloading.  Responsiveness of the interactive applications is
   ensured by separating interactive and background applications.
   Traffic in the Interactive class has higher priority in scheduling
   than Background class traffic, so background applications use
   transmission resources only when interactive applications do not need
   them.  This is very important in wireless environment where the
   bandwidth is low compared to fixed networks.

B.2  QoS-Header Attribute







Groeting, et al.        Expires January 10, 2005               [Page 29]


Internet-Draft    Network Selection Implementation Results     July 2004


           0                   1                   2
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Type          | Length        | QoS              ...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     Type:

       To Be Assigned by IANA

     Length:

       Indicates the length of this header attribute in bytes.

     QoS:

       This field contains the supported QoS classes
       Bit1 - conversational
       Bit2 - streaming
       Bit3 - interactive
       Bit4 - background
       Bit5 (and following) - tbd


B.3  Example

   To express the network supports UMTS QoS classes À»interactiveÀ»
   and À»backgroundÀ» the following payload has to be transmitted:

          QoS-Header:

          Type = IANA assigned
          Length = 4
          QoS = 0011

   A network supports exclusively real time services and indicates only
   UMTS QoS class À»conversationalÀ»:

        QoS-Header:

          Type = IANA assigned
          Length = 1
          QoS = 1







Groeting, et al.        Expires January 10, 2005               [Page 30]


Internet-Draft    Network Selection Implementation Results     July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Groeting, et al.        Expires January 10, 2005               [Page 31]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/