TOC 
ANCP Working GroupH. Moustafa
Internet-DraftFrance Telecom
Intended status: InformationalH. Tschofenig
Expires: April 10, 2009Nokia Siemens Networks
 S. De Cnodder
 Alcatel-Lucent
 October 07, 2008


Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
draft-ietf-ancp-security-threats-06.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 10, 2009.

Abstract

The Access Node Control Protocol (ANCP) aims to communicate QoS-related, service-related 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 protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS.

The present 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.  Specification Requirements

2.  Introduction

3.  System Overview and Threat Model

4.  Objectives of Attackers

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

6.  Attack Forms

7.  Attacks Against ANCP
    7.1.  Dynamic Access Loop Attributes
    7.2.  Access Loop Configuration
    7.3.  Remote Connectivity Test
    7.4.  Multicast

8.  Security Requirements

9.  Security Considerations

10.  IANA Considerations

11.  Acknowledgments

12.  References
    12.1.  Normative References
    12.2.  Informative References

§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Specification Requirements

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.), 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 (System Overview and Threat Model).



 TOC 

2.  Introduction

The Access Node Control Protocol (ANCP) aims to communicate QoS-related, service-related 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] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” February 2010.) 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] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” February 2010.) as well as the guidelines for IETF protocols' security requirements given in [RFC3365] (Schiller, J., “Strong Security Requirements for Internet Engineering Task Force Standard Protocols,” August 2002.). 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 to both ANCP header and payloads.

Prevention against Impersonation:

It is important that protection be available against a device impersonating an ANCP node (i.e. an unauthorized device generating an ANCP message and pretending it was generated by a valid ANCP node).

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 great importance.



 TOC 

3.  System Overview and Threat Model

As described in [I‑D.ietf‑ancp‑framework] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” February 2010.) and schematically shown in Figure 1 (System Overview), 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 AAA 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 Equipments (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).

Aggregation Network:

The aggregation network provides traffic aggregation from multiple ANs towards the NAS. ATM or Ethernet transport technologies can be used.

For the threat analysis, this document focuses on the ANCP protocol communication between the Access Node and the NAS. However, communications with the other components, such as HGW, CPE, AAA server play a role in the understanding of the system architecture and of what triggers ANCP protocol communications. Note that the NAS and the AN might belong to two different administrative realms. The threat model and the security requirments in this draft consider this later case.



                                                          +--------+
                                                          | 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:

Attackers can be:

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

We assume the following threat model:



 TOC 

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:



 TOC 

5.  Potential Attacks

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

ANCP is mainly susceptible to the following types of attacks:



 TOC 

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 service 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.



 TOC 

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.



 TOC 

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 give the oppurtunity to 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.



 TOC 

5.4.  Traffic Analysis

An adversary can be placed at the NAS, or the AN, or any other network element capturing all traversing 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 and containing some information related to the connected client. This could be any form of information about the client and could also be an indicator whether the DSL subscriber is at home or not at a particular moment.



 TOC 

6.  Attack Forms

The attacks mentioned above in Section 5 (Potential Attacks) 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 a 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 achieved at the signaling protocol level, at the level of a specific signaling parameters (e.g., QoS information), or at the transport layer. 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. 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 failure.

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 working 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.



 TOC 

7.  Attacks Against ANCP

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 (System Overview and Threat Model) and the potential attacks presented in Section 5 (Potential Attacks), this section describes the possible attacks against ANCP, considering the four use cases defined in [I‑D.ietf‑ancp‑framework] (Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” February 2010.).

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. Consequently, this draft considers the attacks that are related to the ANCP operation associated with the communication between the NAS and the AAA/Policy server. In other words, the threat model and security requirements in this draft take into consideration the data transfer between the NAS and the AAA server, when this data is used within the ANCP operation.

Besides the attacks against the four ANCP use cases described in the following subsections, ANCP is susceptible to a number of attacks that can take place during the protocol establishment phase. These attacks are mainly on-path attacks, taking the form of DoS or man-in-the-middle attacks, which could be as follows:



 TOC 

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, on the AN or on the NAS during the access loop attributes transfer. These attacks may be:

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:



 TOC 

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:

Off-path attacks can take place as follows:



 TOC 

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 operation.

On-path active attacks can take place in the following forms:

Off-path active attacks can take place as follows:



 TOC 

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 and control replication performed by the AN. Four multicast uses cases are expected to take place, making use of ANCP protocol, these are typically: multicast conditional access, multicast admission control, multicast accounting, and multicast termination. This section gives a high-level description of the possible attacks that can take place in this case. Attacks that can occur are mostly active attacks.

On-path active attacks can be as follows:

An off-path active attack is as follows:



 TOC 

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:



 TOC 

9.  Security Considerations

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



 TOC 

10.  IANA Considerations

This document does not require actions by IANA.



 TOC 

11.  Acknowledgments

Many thanks go to Francois Le Faucher for reviewing this draft and for all his useful comments. The authors would also like to thank Philippe Niger, Curtis Sherbo and Michael Busser for reviewing this draft. Other thanks go to Bharat Joshi, Mark Townsley and Kim Hylgaard who have had valuable comments during the development of this work.



 TOC 

12.  References



 TOC 

12.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.


 TOC 

12.2. Informative References

[I-D.ietf-ancp-framework] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, “Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks,” draft-ietf-ancp-framework-13 (work in progress), February 2010 (TXT).


 TOC 

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
  Nokia Siemens Networks
  Linnoitustie 6
  Espoo 02600
  Finland
Phone:  +358 (50) 4871445
Email:  Hannes.Tschofenig@gmx.net
URI:  http://www.tschofenig.priv.at
  
  Stefaan De Cnodder
  Alcatel-Lucent
  Copernicuslaan 50
  B-2018 Antwerp,
  Belgium
Phone:  +32 3 240 85 15
Email:  stefaan.de_cnodder@alcatel-lucent.com


 TOC 

Full Copyright Statement

Intellectual Property