ANCP Working Group H. Moustafa
Internet-Draft France Telecom
Intended status: Informational H. Tschofenig
Expires: April 16, 2007 Siemens
S. De Cnodder
Alcatel
October 13, 2006
Security Threats and Security Requirements for the Access Node Control
Protocol (ANCP)
draft-moustafa-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 April 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Access Node Control Protocol (ANCP) aims to communicate QoS-,
service- and subscriber-related 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 protocol is to
Moustafa, et al. Expires April 16, 2007 [Page 1]
Internet-Draft ANCP Threats October 2006
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, developing a threat model for ANCP security aiming to
decide which security functions are required at the ANCP level.
Based on this, security requirements regarding the Access Node
Control Protocol are defined.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. System Overview and Threat Model . . . . . . . . . . . . . . . 5
4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 7
5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Message Modification . . . . . . . . . . . . . . . . . . . 7
5.2. Replay of Signaling Messages . . . . . . . . . . . . . . . 8
5.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 8
5.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
5.5. Downgrading Attack . . . . . . . . . . . . . . . . . . . . 9
5.6. Man-in-the-Middle Attack . . . . . . . . . . . . . . . . . 9
5.7. Network Snooping . . . . . . . . . . . . . . . . . . . . . 9
6. Attacks Against ANCP Defined Use Cases . . . . . . . . . . . . 10
6.1. Dynamic Access Loop Attributes . . . . . . . . . . . . . . 10
6.2. Access Loop Configuration . . . . . . . . . . . . . . . . 11
6.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 11
6.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Requirements . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Moustafa, et al. Expires April 16, 2007 [Page 2]
Internet-Draft ANCP Threats October 2006
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Moustafa, et al. Expires April 16, 2007 [Page 3]
Internet-Draft ANCP Threats October 2006
1. Introduction
The Access Node Control Protocol (ANCP) aims to communicate QoS-,
service- and subscriber-related operations between a Network Access
Server (NAS) and an Access Node (e.g., a Digital Subscriber Line
Access Multiplexer (DSLAM)).
[I-D.ooghe-ancp-framework] illustrates the framework, usage scenarios
and general requirements. This document focuses on description of
security threats and derives security requirements from 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 payloads, and ANCP should also provide such
protection as a service to the different service parameters
between the two peers.
Prevention again 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 allow 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 April 16, 2007 [Page 4]
Internet-Draft ANCP Threats October 2006
3. System Overview and Threat Model
As described in [I-D.ooghe-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 authentication 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 and associated equipment located inside a
subscriber's premise and connected with a carrier's
telecommunication channel(s) at the demarcation point ("demarc").
The demarc is a point established in a building or complex to
separate customer equipment from the equipment of the access
network provider (e.g., a telephone company).
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
Moustafa, et al. Expires April 16, 2007 [Page 5]
Internet-Draft ANCP Threats October 2006
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 |---| | | | | |
+-----+ +-----+ | 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.
Moustafa, et al. Expires April 16, 2007 [Page 6]
Internet-Draft ANCP Threats October 2006
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 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
against an individual entity 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
o attacks to grain profit for the attacker (e.g., by modifying the
QoS settings)
Attackers against the access network or a portion of it fall into
three classes:
o attacks to disrupt the network services
o attacks to destruct the network functioning
o attacks to intercept subscribers-related data to increase the QoS
of a subscriber(e.g., by replaying old packets, an attacker can
configure a better QoS profile on its own DSL line increasing its
own benefit)
5. Potential Attacks
5.1. Message Modification
This type of threat involves integrity violations, whereby an
adversary modifies signaling messages (e.g., by acting as a man-in-
the-middle) in order to cause unexpected network behavior. Possible
actions an adversary might consider for its attack are reordering,
Moustafa, et al. Expires April 16, 2007 [Page 7]
Internet-Draft ANCP Threats October 2006
delaying, dropping, injecting, truncating, and otherwise modifying
messages. An adversary might, for example, inject a signaling
message to request allocation of QoS resources. As a consequence,
other user's traffic might be impacted.
5.2. Replay of Signaling Messages
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 uses parts of them at a different
place or in a different way; e.g., cut-and-paste attacks). Doing
this an adversary might mount man-in-the-middle, denial of service,
and theft of service attacks.
5.3. Denial of Service Attacks
A number of denial of service (DoS) attacks can cause ANCP nodes to
malfunction. Other attacks that could lead to DoS, such as man-in-
the-middle attacks, replay attacks, and injection or modification of
signaling messages, etc., are mentioned throughout this document.
When state is established or certain functions are performed without
requiring prior authorization there is a chance to mount denial of
service attacks. An adversary can utilize this fact to transmit a
large number of signaling messages to allocate state at nodes and to
cause resource consumption.
When the ANCP allows the AN to dynamically discovery the NAS then a
man-in-the-middle vulnerablity is introduced. An adversary can use
the discovery mechanisms to convince one entity to signal information
to another entity, or to cause the discovery process to fail. In the
first case, the signaling protocol could appear to continue
correctly, except that a number of ANs might contact a single NAS or
a wrong NAS. For the AN this could mean that the protocol failed for
unknown reasons.
Faked Error or Response Messages: An adversary may be able to inject
false error or response messages as part of a DoS attack. This could
be at the signaling protocol level, at the level of the specific
service parameters (e.g., QoS information), or the transport layer.
An adversary might cause unexpected protocol behavior or might
succeed with a DoS attack. The discovery protocol, especially,
exhibits vulnerabilities with regard to this threat scenario (see the
above discussion on discovery).
Moustafa, et al. Expires April 16, 2007 [Page 8]
Internet-Draft ANCP Threats October 2006
5.4. Traffic Analysis
This section covers threats whereby an adversary is able to eavesdrop
on signaling messages. The signaling packets collected 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.
5.5. Downgrading Attack
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.
Therefore, 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.6. Man-in-the-Middle Attack
An adversary might claims to be an NAS or a AN to acts a man-in-the-
middle to later initiate faked configuration parameters and to flood
other nodes with signaling messages. The consequence can range from
DoS to fraud.
5.7. Network Snooping
An adversary, a sniffer, can be placed at the NAS or the AN or any
other network element between the AN and the NAS capturing all
traversed packets in this network portion. This can be an effective
way for Traffic Analysis mentioned in Section 5.4. Adversaries can
carryout Network Snooping to gather information relevant to the
network and then use this information in gaining unauthorized access.
This attack is also called Sniffing and it can help adversaries in
other malicious purposes, as for example capturing control messages
sent from the AN to the NAS announcing that a DSL line is up and
containing some information related to the connected client,
Moustafa, et al. Expires April 16, 2007 [Page 9]
Internet-Draft ANCP Threats October 2006
indicating the client's existence at home.
6. 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 4 ANCP use cases defined in [I-D.ooghe-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.
Since this point is out-of-scope of ANCP, it is not discussed in this
document.
6.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 as follows:
o Between the AN and the NAS during the Access Loop attributes
transfer.
These attacks may be: i) Passive, only learning these attributes.
The main attacks here are caused by network snooping through
capturing information about the clients'connection state and thus
impacting their privacy protection, or traffic analysis that can be
used in later unauthorized access. ii) Active, acting on the
transferred attributes and/or injecting falsify packets. Man-in-the-
middle attack is a possible major attack in such case causing Access
Loop attributes transfer between a forged AN or a forged NAS which
can directly cause faked attributes, message modification, and DoS
through signaling replay.
Off-path attacks can take place as follows:
Moustafa, et al. Expires April 16, 2007 [Page 10]
Internet-Draft ANCP Threats October 2006
o On the Internet affecting the Access Loop attributes sharing
between the NAS and the policy server.
Those attacks may be: i) Passive as eavesdropping, traffic analysis,
and network snooping gaining information of the access loop
attributes that can be used later in initiating replay attacks or
unauthorized access to the NAS or the policy server. ii) Active as
DoS through flooding the communication links to the policy server
causing service disruption, and man-in-the-middle attack causing
access loop configuration data retrieval from the policy server by an
illegitimate NAS.
6.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 the following attacks:
o Downgrading attack is possible during the update of the Access
Loop configuration, where an on-path adversary on the NAS, the AN
or between them can actively force other parameters than the
selected ones.
o DoS attacks can take place by an on-path active attacker, through
replaying of the Configure Request messages.
o Damaging clients' profiles at ANs can take place by on-path active
hackers that gained control on the network through discovery of
users information from a previously network snooping.
o On-path active adversary can replay old packets related to a
privileged client profile (having more services), so that to
configure this profile on its own DSL line which is less
privileged. In order that the attacker do not expose its
identity, it may also replay packets related to the privileged
client profile to configure a number of illegitimate DSL lines.
o Off-path passive adversaries on the Internet can exert eaves-
dropping 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.
6.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 the following attacks, where most of the
Moustafa, et al. Expires April 16, 2007 [Page 11]
Internet-Draft ANCP Threats October 2006
attacks in this use case concern the network functionality:
o On-path Man-in-the-middle attack can occur during the NAS
triggering to the AN to carryout the test. An active adversary
can inject falsify signals instead or can truncate the triggering.
o On-path Man-in-the-middle attack can take place during the
Subscriber Response message transfer from the AN to the NAS
announcing the test results.
o Off-path DoS attack can take place, in case of ATM based Access
Loop, when the AN generates loopback cells during the Access Loop
test, by an active adversary replaying these generated cells.
Message truncating can also occur by an off-path active adversary,
leading to service disruption due to test failures assumption.
6.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).
7. 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 SHOULD offer confidentiality protection.
o The protocol solution MUST be robust against denial of service
attacks.
Moustafa, et al. Expires April 16, 2007 [Page 12]
Internet-Draft ANCP Threats October 2006
o The protocol solution SHOULD provide mutual authentication between
different communicating entities.
o The protocol solution SHOULD distinguish the control messages from
the data.
o The protocol solution SHOULD provide privacy protection.
8. Security Considerations
This document focuses on security threats deriving a threat model for
ANCP and presenting the security requirements to be considered.
9. IANA Considerations
This document does not require actions by IANA.
10. Acknowledgment
The authors would like to thank Antoine Delafoy and Philippe Niger
for their useful comments.
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.ooghe-ancp-framework]
Ooghe, S., "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
draft-ooghe-ancp-framework-00 (work in progress),
June 2006.
Moustafa, et al. Expires April 16, 2007 [Page 13]
Internet-Draft ANCP Threats 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
Copernicuslaan 50
B-2018 Antwerp,
Belgium
Phone: +32 3 240 85 15
Email: stefaan.de_cnodder@alcatel.be
Moustafa, et al. Expires April 16, 2007 [Page 14]
Internet-Draft ANCP Threats October 2006
Full Copyright Statement
Copyright (C) The Internet Society (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 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 April 16, 2007 [Page 15]