ANCP Working Group                                           H. Moustafa
Internet-Draft                                            France Telecom
Intended status: Informational                             H. Tschofenig
Expires: June 21, 2007                                           Siemens
                                                           S. De Cnodder
                                                          Alcatel-Lucent
                                                       December 18, 2006


 Security Threats and Security Requirements for the Access Node Control
                            Protocol (ANCP)
                draft-ietf-ancp-security-threats-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 June 21, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   The Access Node Control Protocol (ANCP) aims to communicate QoS-,
   service- and subscriber-related configurations and operations between
   a Network Access Server (NAS) and an Access Node (e.g., a Digital
   Subscriber Line Access Multiplexer (DSLAM)).  The main goal of this



Moustafa, et al.          Expires June 21, 2007                 [Page 1]


Internet-Draft                ANCP Threats                 December 2006


   protocol is to configure and manage access equipments and allow them
   to report information to the NAS in order to enable and optimize
   configuration.

   This document investigates security threats that all ANCP nodes could
   encounter.  This document develops a threat model for ANCP security
   aiming to decide which security functions are required.  Based on
   this, security requirements regarding the Access Node Control
   Protocol are defined.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  System Overview and Threat Model . . . . . . . . . . . . . . .  4

   4.  Objectives of Attackers  . . . . . . . . . . . . . . . . . . .  6

   5.  Potential Attacks  . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Denial of Service (DoS)  . . . . . . . . . . . . . . . . .  6
     5.2.  Integrity Violation  . . . . . . . . . . . . . . . . . . .  7
     5.3.  Downgrading  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Traffic Analysis . . . . . . . . . . . . . . . . . . . . .  7

   6.  Attacks Forms  . . . . . . . . . . . . . . . . . . . . . . . .  7

   7.  Attacks Against ANCP Defined Use Cases . . . . . . . . . . . .  9
     7.1.  Dynamic Access Loop Attributes . . . . . . . . . . . . . .  9
     7.2.  Access Loop Configuration  . . . . . . . . . . . . . . . . 10
     7.3.  Remote Connectivity Test . . . . . . . . . . . . . . . . . 11
     7.4.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 12

   8.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 12

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     11.2. Informative References . . . . . . . . . . . . . . . . . . 13

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14




Moustafa, et al.          Expires June 21, 2007                 [Page 2]


Internet-Draft                ANCP Threats                 December 2006


1.  Introduction

   The Access Node Control Protocol (ANCP) aims to communicate QoS-,
   service- and subscriber-related configurations and operations between
   a Network Access Server (NAS) and an Access Node (e.g., a Digital
   Subscriber Line Access Multiplexer (DSLAM)).

   [I-D.ietf-ancp-framework] illustrates the framework, usage scenarios
   and general requirements for ANCP.  This document focuses on
   description of security threats and derives security requirements for
   the Access Node Control Protocol.  Security policy negotiation,
   including authentication and authorization to define the per-
   subscriber policy at the policy/AAA server, is out of the scope of
   this work.  As a high-level summary, the following aspects need to be
   considered:

   Message Protection:

      Signaling message content can be protected against eavesdropping,
      modification, injection and replay while in transit.  This applies
      both to ANCP header and payloads, and ANCP should also provide
      such protection as a service to the different service parameters
      between the two peers.

   Prevention against Impersonation:

      It is important that signaling messages are delivered to the
      correct nodes, and nowhere else.

   Prevention of Denial of Service Attacks:

      ANCP nodes and the network have finite resources (state storage,
      processing power, bandwidth).  Exhaustion attacks against these
      resources and not allowing ANCP nodes to be used to launch attacks
      on other network elements is of importance.


2.  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], with the
   qualification that unless otherwise stated they apply to the design
   of the Access Node Control Protocol (ANCP), not its implementation or
   application.

   The relevant components are described in Section 3.




Moustafa, et al.          Expires June 21, 2007                 [Page 3]


Internet-Draft                ANCP Threats                 December 2006


3.  System Overview and Threat Model

   As described in [I-D.ietf-ancp-framework] and schematically shown in
   Figure 1, the Access Node Control system consists of the following
   components:

   Network Access Server (NAS):

      A NAS provides access to a service (e.g., network access) and
      operates as a client of the AAA protocol.  The client is
      responsible for passing authentication information to designated
      AAA servers and then acting on the response that is returned.

   Authentication, Authorization and Accounting (AAA) server:

      A AAA server is responsible for authenticating users, for
      authorizing access to services, and for returning authorization
      information including configuration parameters back to the AAA
      client to deliver service to the user.  As a consequence of
      service usage accounting might be enabled and information about
      the user's resource usage will be sent to the AAA server.

   Access Node (AN):

      The AN is a network device, usually located at a service provider
      central office or street cabinet, that terminates Access Loop
      connections from subscribers.  In case the Access Loop is a
      Digital Subscriber Line (DSL), this is often referred to as a DSL
      Access Multiplexer (DSLAM).

   Customer Premises Equipment (CPE):

      A CPE is a device located inside a subscriber's premise that is
      connected at the LAN side of the HGW.

   Home Gateway (HGW):

      The HGW connects the different Customer Premises Equipment (CPE)
      to the Access Node and the access network.  In case of DSL, the
      HGW is a DSL Network Termination (NT) that could either operate as
      a layer 2 bridge or as a layer 3 router.  In the latter case, such
      a device is also referred to as a Routing Gateway (RG).

   For the threat analysis the protocol communication between the Access
   Node and the NAS is important whereas the other component, such as
   HGW, CPE, AAA server only play a role in the understanding of the
   system architecture.  Note that the NAS and the AN might belong to
   two different administrative realms.



Moustafa, et al.          Expires June 21, 2007                 [Page 4]


Internet-Draft                ANCP Threats                 December 2006


                                                +--------+
                                                | AAA    |
                                                | Server |
                                                +--------+
                                                     |
                                                     |
   +-----+   +-----+   +--------+                 +-----+   +----------+
   | CPE |---| HGW |---|        |                 |     |   |          |
   +-----+   +-----+   | Access |                 |     |   | Internet |
                       | Node   |-----------------| NAS |---|          |
   +-----+   +-----+   | (AN)   |                 |     |   |          |
   | CPE |---| HGW |---|        |                 |     |   |          |
   +-----+   +-----+   +--------+                 +-----+   +----------+

                         Figure 1: System Overview

   In the absence of an attack, the NAS receives configuration
   information from the AAA server related to a CPE attempting to access
   the network.  A number of parameters, including Quality of Service
   information, need to be conveyed to the Access Node in order to
   become effective.  The Access Node Control Protocol is executed
   between the NAS and the AN to initiate control requests.  The AN
   returns responses to these control requests and provides information
   reports.

   For this to happen, the following individual steps must occur:
   o  The AN discovers the NAS.
   o  The AN needs to start the protocol communication with the NAS to
      announce its presence.
   o  The AN and the NAS perform a capability exchange.
   o  The NAS sends requests to the AN.
   o  The AN processes these requests, authorizes the actions and
      responds with the appropriate answer.  In order to fulfill the
      commands it might be necessary for the AN to communicate with the
      HGW or other nodes, for example as part of a keep alive mechanism.
   o  The AN provides status reports to the NAS.

   Attackers can be:

   o  off-path, i.e., it cannot see packets between the AN and the NAS;
   o  on-path, i.e., they can see the message exchange between the AN
      and the NAS.

   Both off-path and on-path attackers can be:

   o  passive, i.e., they do not participate in the network but rather
      listen to all transfer to obtain the maximum possible information;




Moustafa, et al.          Expires June 21, 2007                 [Page 5]


Internet-Draft                ANCP Threats                 December 2006


   o  active, i.e., they participate to the network and can inject
      falsify packets.

   We assume the following threat model:
   o  An off-path adversary located at the CPE or the HGW.
   o  An off-path adversary located on the Internet or a regional
      network that connects one or more NAS and associated Access
      Networks to Network Service Providers (NSPs) and Application
      Service Providers (ASPs).
   o  An on-path adversary located at network elements between the AN
      and the NAS.
   o  An adversary that took control over the NAS.
   o  An adversary that took control over the AN.


4.  Objectives of Attackers

   Attackers may direct their efforts either against an individual
   entity or against a large portion of the access network.  Attacks
   fall into three classes:
   o  attacks to disrupt the communication for individual customers.
   o  attacks to disrupt the communication of a large fraction of
      customers in an access network.  This also include attacks to the
      network itself or a portion of it such as attacks to disrupt the
      network services or attacks to destruct the network functioning.
   o  attacks to gain profit for the attacker (e.g., by modifying the
      QoS settings).  Also, through replaying old packets, of another
      privileged client for instance, an attacker can configure a better
      QoS profile on its own DSL line increasing its own benefit.


5.  Potential Attacks

   This section discusses the different types of attacks against ANCP
   protocol, while Section 6 describes the possible means of their
   occurrence.

   ANCP is mainly susceptible to the following types of attacks:

5.1.  Denial of Service (DoS)

   A number of denial of service (DoS) attacks can cause ANCP nodes to
   malfunction.  When state is established or certain functions are
   performed without requiring prior authorization there is a chance to
   mount denial of services attacks.  An adversary can utilize this fact
   to transmit a large number of signaling messages to allocate state at
   nodes and to cause resources' consumption.




Moustafa, et al.          Expires June 21, 2007                 [Page 6]


Internet-Draft                ANCP Threats                 December 2006


5.2.  Integrity Violation

   Adversaries gaining illegitimate access on the transferred messages
   can act on these messages causing integrity violation.  Integrity
   violation can cause unexpected network behavior causing a disturbance
   of the network services as well as the network functioning.

5.3.  Downgrading

   Protocols may be useful in a variety of scenarios with different
   security and functional requirements.  Different parts of a network
   (e.g., within a building, across a public carrier's network, or over
   a private microwave link) may need different levels of protection.
   It is often difficult to meet these (sometimes conflicting)
   requirements with a single mechanism or fixed set of parameters, so
   often a selection of mechanisms and parameters is offered.  A
   protocol is required to agree on certain (security) mechanisms and
   parameters.  An insecure parameter exchange or security negotiation
   protocol can help an adversary to mount a downgrading attack to force
   selection of mechanisms weaker than those mutually desired.  Thus,
   without binding the negotiation process to the legitimate parties and
   protecting it, ANCP might only be as secure as the weakest mechanism
   provided (e.g., weak authentication) and the benefits of defining
   configuration parameters and a negotiation protocol are lost.

5.4.  Traffic Analysis

   An adversary can be placed at the NAS, or the AN, or any other
   network element capturing all traversed packets.  Adversaries can
   thus have unauthorized information access.  As well, they can gather
   information relevant to the network and then use this information in
   gaining unauthorized access.  This attack can also help adversaries
   in other malicious purposes, as for example capturing messages sent
   from the AN to the NAS announcing that a DSL line is up and
   containing some information related to the connected client,
   indicating the client's existing at home.


6.  Attacks Forms

   The attacks mentioned above in Section 5 can be carried out through
   the following means:

   Message Replay:

      This threat scenario covers the case in which an adversary
      eavesdrops, collects signaling messages, and replays them at a
      later time (or at a different place or in a different way; e.g.,



Moustafa, et al.          Expires June 21, 2007                 [Page 7]


Internet-Draft                ANCP Threats                 December 2006


      cut-and-paste attacks).  Through replaying of signaling messages,
      an adversary might mount a denial of service and theft of service
      attacks.

   Faked Message Injection:

      An adversary may be able to inject false error or response
      messages causing unexpected protocol behavior and succeeding with
      a DoS attack.  This could be at the signaling protocol level, at
      the level of a specific signaling parameters (e.g., QoS
      information), or the transport layer.  An adversary might, for
      example, inject signaling message to request allocation of QoS
      resources.  As a consequence, other user's traffic might be
      impacted.  The discovery protocol, especially, exhibits
      vulnerabilities with regard to this threat scenario.

   Messages Modification:

      This involves integrity violation, where an adversary can modify
      signaling messages in order to cause unexpected network behavior.
      Possible related actions an adversary might consider for its
      attack are reordering and delaying of messages causing a
      protocol's process failures.

   Man-in-the-Middle:

      An adversary might claim to be a NAS or an AN acting as a man-in-
      the-middle to later cause communication and services disruption.
      The consequence can range from DoS to fraud.  An adversary acting
      as a man-in-the-middle could modify the intercepted messages
      causing integrity violation, or could drop or truncate the
      intercepted messages causing DoS and a protocol's process failure.
      In addition, a man-in-the-middle adversary can signal information
      to an illegitimate entity in place of the right destination.  In
      this case the protocol could appear to continue correctly.  This
      may result in an AN contacting a wrong NAS.  For the AN, this
      could mean that the protocol failed for unknown reasons.  A man-
      in-the-middle adversary can also cause downgrading attacks through
      initiating faked configuration parameters and through forcing
      selection of weak security parameters or mechanisms.

   Eavesdropping:

      This is related to adversaries that are able to eavesdrop on
      transferred messages.  The collection of the transferred packets
      by an adversary may allow traffic analysis or be used later to
      mount replay attacks.  The eavesdropper might learn QoS
      parameters, communication patterns, policy rules for firewall



Moustafa, et al.          Expires June 21, 2007                 [Page 8]


Internet-Draft                ANCP Threats                 December 2006


      traversal, policy information, application identifiers, user
      identities, NAT bindings, authorization objects, network
      configuration and performance information, and more.



7.  Attacks Against ANCP Defined Use Cases

   ANCP is susceptible to security threats, causing disruption/
   unauthorized access to network services, manipulation of the
   transferred data, and interference with network functions.  Based on
   the threat model given in Section 3 and the potential attacks
   presented in Section 5, this section describes the possible attacks
   for the four ANCP use cases defined in [I-D.ietf-ancp-framework].

   Although ANCP protocol is not involved in the communication between
   the NAS and the AAA/policy server, the secure communication between
   the NAS and the AAA/policy server is important for ANCP security.
   The process of users' authentication, concerning how the user gets
   authenticated and how the AAA server gets the authorization data is
   not related to the ANCP operation and is thus out-of-scope of this
   draft.  However, once the AAA server has the authorization data then
   it is given to the NAS, which is more in the scope of this work.
   Consequently, this draft considers the attacks that are related to
   the ANCP operation and are concerning the communication between the
   NAS and the AAA/Policy server.

7.1.  Dynamic Access Loop Attributes

   This use case concerns the communication of Access Loop attributes
   for dynamic access line topology discovery.  Since the Access Loop
   rate may change overtime, advertisement is beneficial to the NAS to
   gain knowledge about the topology of the access network for QoS
   scheduling.  Besides data rates and Access Loop links identification,
   other information may also be transferred from the AN to the NAS
   (examples in case of DSL Access Loop are: DSL Type, Maximum
   achievable data rate, and maximum data rate configured for the Access
   Loop).  This use case is thus vulnerable to a number of on-path and
   off-path attacks that can be either active or passive.

   On-path attacks can take place between the AN and the NAS or on the
   NAS during the Access Loop attributes transfer.  These attacks may
   be:
   o  Active, acting on the transferred attributes and injecting falsify
      packets.  The main attacks here are:
      *  Man-in-the-middle attack can cause Access Loop attributes
         transfer between a forged AN or a forged NAS which can directly
         cause faked attributes and message modification or truncation.



Moustafa, et al.          Expires June 21, 2007                 [Page 9]


Internet-Draft                ANCP Threats                 December 2006


      *  Signaling replay, by an attacker between the AN and the NAS or
         on the NAS itself, causing DoS.
      *  An adversary acting as man-in-the-middle can cause downgrading
         through changing the Access Loop actual data rate, which
         impacts the downstream shaping from the NAS.
   o  Passive, only learning these attributes.  The main attacks here
      are caused by:
      *  Eavesdropping through learning information about the
         clients'connection state and thus impacting their privacy
         protection.
      *  Traffic analysis allowing unauthorized information access.

   Off-path attacks can take place on the Internet affecting the Access
   Loop attributes sharing between the NAS and the policy server.  These
   attacks may be:
   o  Active attacks, which are mainly concerning:
      *  DoS through flooding the communication links to the policy
         server causing service disruption.
      *  Man-in-the-middle, causing Access Loop configuration retrieval
         by an illegitimate NAS.
   o  Passive gaining information of the Access Loop attributes.  The
      main attacks in this case are:
      *  Eavesdropping learning Access Loop attributes and learning
         information about the clients'connection state.
      *  Traffic analysis that can allow later unauthorized access to
         the NAS or the policy server.

7.2.  Access Loop Configuration

   This use case concerns the dynamic local loop line configuration
   through allowing the NAS to change the access loop parameters (e.g.
   rate) in a dynamic fashion.  This allows for centralized subcriber-
   related service data.  This dynamic configuration can be achieved for
   instance through profiles that are pre-configured on ANs.  This use
   case is vulnerable to a number of on-path and off-path attacks.

   On-path attacks can take place, where the attacker is between the AN
   and the NAS, is on the AN, or is on the NAS.  These can be as
   follows:
   o  Active attacks, taking the following forms:
      *  DoS attacks can take place by an attacker, through replaying of
         the Configure Request messages.
      *  Damaging clients' profiles at ANs can take place by hackers
         that gained control on the network through discovery of users
         information from a previous Traffic Analysis.
      *  An adversary can replay old packets, modify messages, or inject
         faked messages.  Such adversary can also be a man-in-the-
         middle.  These attacks forms can be related to a privileged



Moustafa, et al.          Expires June 21, 2007                [Page 10]


Internet-Draft                ANCP Threats                 December 2006


         client profile (having more services), so that to configure
         this profile on the adversary's own DSL line which is less
         privileged.  In order that the attacker does not expose its
         identity, he may also use these attacks forms related to the
         privileged client profile to configure a number of illegitimate
         DSL lines.  The adversary can also force other configuration
         parameters than the selected ones leading to for instance
         downgrading the service.
   o  Passive attacks, where the attacker listens to the ANCP messages.
      This can take place as follows:
      *  Learning configuration attributes is possible during the update
         of the Access Loop configuration.  An adversary might look to
         the configuraton to see the configuration that someone else
         gets (e.g. one ISP might be interested what the customers of
         another ISP gets and therefore might break into the AN to see
         this).

   Off-path attacks can take place as follows:
   o  Off-path passive adversary on the Internet can exert eavesdropping
      during the Access Loop configuration retrieval by the NAS from the
      policy server.
   o  Off-path active adversary on the Internet can threaten the
      centralized subscribers-related service data in the policy server,
      through for instance making subscribers records inaccessible.

7.3.  Remote Connectivity Test

   In this use case, the NAS can carryout Remote Connectivity Test using
   ANCP to initiate an Access Loop test between the AN and the HGW.
   Thus, multiple Access Loop technologies can be supported.  This use
   case is vulnerable to a number of active attacks.  Most of the
   attacks in this use case concern the network functionality.

   On-path active attacks can take place in the following forms:
   o  Man-in-the-middle attack during the NAS triggering to the AN to
      carryout the test, where an adversary can inject falsify signals
      and can truncate the triggering.
   o  Message modification can take place during the Subscriber Response
      message transfer from the AN to the NAS announcing the test
      results, causing failure of the test operation.

   Off-path active attacks can take place as follows:
   o  An adversary can cause DoS during the Access Loop test, in case of
      ATM based Access Loop, when the AN generates loopback cells.  This
      can take place through signal replaying.
   o  Message truncating can take place by an adversary during the
      Access Loop test, which can lead to service disruption due to test
      failures assumption.



Moustafa, et al.          Expires June 21, 2007                [Page 11]


Internet-Draft                ANCP Threats                 December 2006


7.4.  Multicast

   In this use case, ANCP could be used in exchanging information
   between the AN and the NAS allowing the AN to perform replication
   inline with the policy and configuration of the subscriber.  Also,
   this allows the NAS to follow each subscriber's multicast group
   memebership.  Attacks that can occur in this case are mostly on-path
   active attacks, which are as follows:
   o  Damaging proxy functionality in the AN, aggregation node(s) or the
      NAS through DoS or through signaling truncating.
   o  DoS during the information exchange between the NAS and the AN on
      the subscriber's policy and multicast traffic configuration.
   o  Man-in-the-middle attack during the multicast replication process
      at the AN, aggregation node(s) and the NAS that can cause
      modification of the multicast group memebership either for service
      disruption or for adversary benefit (e.g. subscriber's policy
      illegitimate change).


8.  Security Requirements

   The following list represents a list of requirements motivated by the
   threats in Section 5:
   o  The protocol solution MUST offer authentication of the AN to the
      NAS.
   o  The protocol solution MUST offer authentication of the NAS to the
      AN.
   o  The protocol solution MUST allow authorization to take place at
      the NAS and the AN.
   o  The protocol solution MUST offer replay protection.
   o  The protocol solution MUST provide data origin authentication.
   o  The protocol solution MUST be robust against denial of service
      attacks.
   o  The protocol solution SHOULD offer confidentiality protection.
   o  The protocol solution SHOULD distinguish the control messages from
      the data.


9.  Security Considerations

   This document focuses on security threats deriving a threat model for
   ANCP and presenting the security requirements to be considered.


10.  IANA Considerations

   This document does not require actions by IANA.




Moustafa, et al.          Expires June 21, 2007                [Page 12]


Internet-Draft                ANCP Threats                 December 2006


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

11.2.  Informative References

   [I-D.ietf-ancp-framework]
              Ooghe, S., "Framework and Requirements for an Access Node
              Control Mechanism in Broadband  Multi-Service Networks",
              draft-ietf-ancp-framework-00 (work in progress),
              October 2006.


Authors' Addresses

   Hassnaa Moustafa
   France Telecom
   38-40 rue du General Leclerc
   Issy Les Moulineaux,   92794 Cedex 9
   France

   Email: hassnaa.moustafa@orange-ftgroup.com


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com


   Stefaan De Cnodder
   Alcatel-Lucent
   Copernicuslaan 50
   B-2018 Antwerp,
   Belgium

   Phone: +32 3 240 85 15
   Email: stefaan.de_cnodder@alcatel-lucent.be






Moustafa, et al.          Expires June 21, 2007                [Page 13]


Internet-Draft                ANCP Threats                 December 2006


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Moustafa, et al.          Expires June 21, 2007                [Page 14]