ANCP Working Group H. Moustafa
Internet-Draft France Telecom
Intended status: Informational H. Tschofenig
Expires: December 22, 2007 Siemens
S. De Cnodder
Alcatel-Lucent
June 20, 2007
Security Threats and Security Requirements for the Access Node Control
Protocol (ANCP)
draft-ietf-ancp-security-threats-01.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 December 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 December 22, 2007 [Page 1]
Internet-Draft ANCP Threats June 2007
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) . . . . . . . . . . . . . . . . . 7
5.2. Integrity Violation . . . . . . . . . . . . . . . . . . . 7
5.3. Downgrading . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 7
6. Attacks Forms . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Moustafa, et al. Expires December 22, 2007 [Page 2]
Internet-Draft ANCP Threats June 2007
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
describing security threats and deriving security requirements for
the Access Node Control Protocol, considering the ANCP use cases
defined in [I-D.ietf-ancp-framework] as well as the guidelines for
IETF protocols' security requirements given in [RFC3365]. 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.
Moustafa, et al. Expires December 22, 2007 [Page 3]
Internet-Draft ANCP Threats June 2007
The relevant components are described in Section 3.
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, 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).
Moustafa, et al. Expires December 22, 2007 [Page 4]
Internet-Draft ANCP Threats June 2007
Aggregation Network:
The aggregation network provides traffic aggregation from multiple
ANs towards the NAS. ATM or Ethernet technologies can be used.
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.
+--------+
| AAA |
| Server |
+--------+
|
|
+---+ +---+ +------+ +-----------+ +-----+ +--------+
|CPE|---|HGW|---| | |Aggregation| | | | |
+---+ +---+ |Access| | Network | | | |Internet|
| Node |----| |----| NAS |---| / |
+---+ +---+ | (AN) | | | | | |Regional|
|CPE|---|HGW|---| | | | | | |Network |
+---+ +---+ +------+ +-----------+ +-----+ +--------+
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.
Moustafa, et al. Expires December 22, 2007 [Page 5]
Internet-Draft ANCP Threats June 2007
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;
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 NASes 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 on-path adversary taking control over the NAS.
o An on-path adversary taking 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. These 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,
while Section 6 describes the possible means of their occurrence.
Moustafa, et al. Expires December 22, 2007 [Page 6]
Internet-Draft ANCP Threats June 2007
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. Also, an adversary,
through DoS, can prevent certain subscribers to access certain
services.
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 leading to a
disturbance in 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 later 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
Moustafa, et al. Expires December 22, 2007 [Page 7]
Internet-Draft ANCP Threats June 2007
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.,
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
Moustafa, et al. Expires December 22, 2007 [Page 8]
Internet-Draft ANCP Threats June 2007
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
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
against 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
document. 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 document 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,
Moustafa, et al. Expires December 22, 2007 [Page 9]
Internet-Draft ANCP Threats June 2007
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, on the AN
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 the AN and a forged NAS or a forged AN and the
NAS which can directly cause faked attributes and message
modification or truncation.
* Signaling replay, by an attacker between the AN and the NAS, on
the AN 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 access loop attributes and
learning information about the clients' connection state and
thus impacting their privacy protection.
* Traffic analysis allowing unauthorized information access, that
could allow later unauthorized access to the NAS.
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 through learning access loop attributes and
learning information about the clients'connection state and
thus impacting their privacy protection.
* Traffic analysis allowing unauthorized information access, that
could allow later unauthorized access to the NAS.
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.
Moustafa, et al. Expires December 22, 2007 [Page 10]
Internet-Draft ANCP Threats June 2007
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
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 for a privileged client.
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 profit to
see the configuration that someone else gets (e.g. one ISP
might be interested to know 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.
Moustafa, et al. Expires December 22, 2007 [Page 11]
Internet-Draft ANCP Threats June 2007
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
or 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.
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 subscribers' multicast (source, group)
membership. This section gives a high-level description of the
possible attacks that can take place in this case. Attacks that can
occur are mostly on-path active attacks, which can be as follows:
o DoS attacks, causing certain subscribers inability to access
particular multicast streams, or only access the multicast stream
at a reduced bandwidth impacting the quality of the possible video
stream. This can take place through messages replay by an
attacker between the AN and the NAS, on the AN or on the NAS.
o Man-in-the-middle causing messages' exchange between the AN and a
forged NAS or a forged AN and the NAS. This can lead to the
following:
* Messages' modification, which can cause services' downgrading
for legitimate subscriber, as for instance, an illegitimate
change of a subscriber's policy.
* Messages truncation between the AN and the NAS, which can
result in service's non continuity.
* Messages replay between the AN and the NAS, on the AN or on the
NAS leading to a DoS or services' fraud.
8. Security Requirements
This section presents a number of requirements motivated by the
different types of attacks defined in the previous section. These
requirements are as follows:
Moustafa, et al. Expires December 22, 2007 [Page 12]
Internet-Draft ANCP Threats June 2007
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.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", August 2002.
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-01 (work in progress),
February 2007.
Moustafa, et al. Expires December 22, 2007 [Page 13]
Internet-Draft ANCP Threats June 2007
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 December 22, 2007 [Page 14]
Internet-Draft ANCP Threats June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 December 22, 2007 [Page 15]
