< draft-ietf-ancp-security-threats-07.txt   draft-ietf-ancp-security-threats-08.txt >
ANCP Working Group H. Moustafa ANCP Working Group H. Moustafa
Internet-Draft France Telecom Internet-Draft France Telecom
Intended status: Informational H. Tschofenig Intended status: Informational H. Tschofenig
Expires: September 5, 2009 Nokia Siemens Networks Expires: January 10, 2010 Nokia Siemens Networks
S. De Cnodder S. De Cnodder
Alcatel-Lucent Alcatel-Lucent
March 4, 2009 July 9, 2009
Security Threats and Security Requirements for the Access Node Control Security Threats and Security Requirements for the Access Node Control
Protocol (ANCP) Protocol (ANCP)
draft-ietf-ancp-security-threats-07.txt draft-ietf-ancp-security-threats-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009. This Internet-Draft will expire on January 10, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3. System Overview and Threat Model . . . . . . . . . . . . . . . 5 3. System Overview and Threat Model . . . . . . . . . . . . . . . 5
4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 7 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 7
5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 8 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 8 5.1. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 8
5.2. Integrity Violation . . . . . . . . . . . . . . . . . . . 8 5.2. Integrity Violation . . . . . . . . . . . . . . . . . . . 8
5.3. Downgrading . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Downgrading . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9 5.4. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 9
5.5. Management Attacks . . . . . . . . . . . . . . . . . . . . 9
6. Attack Forms . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Attack Forms . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Attacks Against ANCP . . . . . . . . . . . . . . . . . . . . . 10 7. Attacks Against ANCP . . . . . . . . . . . . . . . . . . . . . 11
7.1. Dynamic Access Loop Attributes . . . . . . . . . . . . . . 11 7.1. Dynamic Access Loop Attributes . . . . . . . . . . . . . . 12
7.2. Access Loop Configuration . . . . . . . . . . . . . . . . 12 7.2. Access Loop Configuration . . . . . . . . . . . . . . . . 13
7.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 13 7.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 14
7.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14 7.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Requirements . . . . . . . . . . . . . . . . . . . . 15 8. Security Requirements . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Specification Requirements 1. Specification Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the document are to be interpreted as described in [RFC2119], with the
qualification that unless otherwise stated they apply to the design qualification that unless otherwise stated they apply to the design
of the Access Node Control Protocol (ANCP), not its implementation or of the Access Node Control Protocol (ANCP), not its implementation or
application. application.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
The Access Node Control Protocol (ANCP) aims to communicate QoS- The Access Node Control Protocol (ANCP) aims to communicate QoS-
related, service-related and subscriber-related configurations and related, service-related and subscriber-related configurations and
operations between a Network Access Server (NAS) and an Access Node operations between a Network Access Server (NAS) and an Access Node
(e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).
[I-D.ietf-ancp-framework] illustrates the framework, usage scenarios [I-D.ietf-ancp-framework] illustrates the framework, usage scenarios
and general requirements for ANCP. This document focuses on and general requirements for ANCP. This document focuses on
describing security threats and deriving security requirements for describing security threats and deriving security requirements for
the Access Node Control Protocol, considering the ANCP use cases the Access Node Control Protocol, considering the ANCP use cases
defined in [I-D.ietf-ancp-framework] as well as the guidelines for defined in [I-D.ietf-ancp-framework] as well as the guidelines for
IETF protocols' security requirements given in [RFC3365]. Security IETF protocols' security requirements given in [RFC3365]. Section 5
policy negotiation, including authentication and authorization to and Section 6 respectively describe the potential attacks and the
define the per-subscriber policy at the policy/AAA server, is out of different attack forms that are liable to take place within ANCP,
the scope of this work. As a high-level summary, the following while Section 7 applies the described potential attacks to ANCP and
aspects need to be considered: its different use cases. 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: Message Protection:
Signaling message content can be protected against eavesdropping, Signaling message content can be protected against eavesdropping,
modification, injection and replay while in transit. This applies modification, injection and replay while in transit. This applies
to both ANCP header and payloads. to both ANCP header and payloads.
Prevention against Impersonation: Prevention against Impersonation:
It is important that protection be available against a device It is important that protection be available against a device
skipping to change at page 6, line 18 skipping to change at page 6, line 20
ANs towards the NAS. ATM or Ethernet transport technologies can ANs towards the NAS. ATM or Ethernet transport technologies can
be used. be used.
For the threat analysis, this document focuses on the ANCP protocol For the threat analysis, this document focuses on the ANCP protocol
communication between the Access Node and the NAS. However, communication between the Access Node and the NAS. However,
communications with the other components, such as HGW, CPE, AAA communications with the other components, such as HGW, CPE, AAA
server play a role in the understanding of the system architecture server play a role in the understanding of the system architecture
and of what triggers ANCP protocol communications. Note that the NAS and of what triggers ANCP protocol communications. Note that the NAS
and the AN might belong to two different administrative realms. The and the AN might belong to two different administrative realms. The
threat model and the security requirments in this draft consider this threat model and the security requirments in this draft consider this
later case. latter case.
+--------+ +--------+
| AAA | | AAA |
| Server | | Server |
+--------+ +--------+
| |
| |
+---+ +---+ +------+ +-----------+ +-----+ +--------+ +---+ +---+ +------+ +-----------+ +-----+ +--------+
|CPE|---|HGW|---| | |Aggregation| | | | | |CPE|---|HGW|---| | |Aggregation| | | | |
+---+ +---+ |Access| | Network | | | |Internet| +---+ +---+ |Access| | Network | | | |Internet|
skipping to change at page 7, line 49 skipping to change at page 8, line 4
4. Objectives of Attackers 4. Objectives of Attackers
Attackers may direct their efforts either against an individual Attackers may direct their efforts either against an individual
entity or against a large portion of the access network. Attacks entity or against a large portion of the access network. Attacks
fall into three classes: fall into three classes:
o attacks to disrupt the communication for individual customers. o attacks to disrupt the communication for individual customers.
o attacks to disrupt the communication of a large fraction of o attacks to disrupt the communication of a large fraction of
customers in an access network. These also include attacks to the 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 itself or a portion of it such as attacks to disrupt the
network services or attacks to destruct the network functioning. 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 o attacks to gain profit for the attacker through modifying the QoS
settings. Also, through replaying old packets, of another
privileged client for instance, an attacker can attempt to privileged client for instance, an attacker can attempt to
configure a better QoS profile on its own DSL line increasing its configure a better QoS profile on its own DSL line increasing its
own benefit. own benefit.
5. Potential Attacks 5. Potential Attacks
This section discusses the different types of attacks against ANCP, This section discusses the different types of attacks against ANCP,
while Section 6 describes the possible means of their occurrence. while Section 6 describes the possible means of their occurrence.
ANCP is mainly susceptible to the following types of attacks: ANCP is mainly susceptible to the following types of attacks:
skipping to change at page 9, line 25 skipping to change at page 9, line 28
thus have unauthorized information access. As well, they can gather thus have unauthorized information access. As well, they can gather
information relevant to the network and then use this information in information relevant to the network and then use this information in
gaining later unauthorized access. This attack can also help gaining later unauthorized access. This attack can also help
adversaries in other malicious purposes, as for example capturing adversaries in other malicious purposes, as for example capturing
messages sent from the AN to the NAS announcing that a DSL line is up messages sent from the AN to the NAS announcing that a DSL line is up
and containing some information related to the connected client. and containing some information related to the connected client.
This could be any form of information about the client and could also 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 be an indicator whether the DSL subscriber is at home or not at a
particular moment. particular moment.
5.5. Management Attacks
Since the ANCP sessions are configured in the AN and not in the NAS
[I-D.ietf-ancp-framework], most configurations of ANCP is done in the
AN. Consequently, the management attacks to ANCP mainly concern the
AN configuration phase. In this context, the AN MIB module could
create disclosure and misconfiguration related attacks.
[I-D.ietf-ancp-mib-an] defines the vulnerabilities on the management
objects within the AN MIB module. These attacks mainly concern the
unauthorized changes of the management objects leading to a number of
attacks as session deletion, session using undesired/unsupported
protocol, disabling certain ANCP capabilities or enabling undesired
capabilities, ANCP packets being sent out to the wrong interface (and
thus received by an unintended receiver), harming the synchronization
between the AN and the NAS, and impacting other traffic in the
network than ANCP.
6. Attack Forms 6. Attack Forms
The attacks mentioned above in Section 5 can be carried out through The attacks mentioned above in Section 5 can be carried out through
the following means: the following means:
Message Replay: Message Replay:
This threat scenario covers the case in which an adversary This threat scenario covers the case in which an adversary
eavesdrops, collects signaling messages, and replays them at a eavesdrops, collects signaling messages, and replays them at a
later time (or at a different place or in a different way; e.g., later time (or at a different place or in a different way; e.g.,
skipping to change at page 16, line 4 skipping to change at page 16, line 26
o The protocol solution MUST offer replay protection. o The protocol solution MUST offer replay protection.
o The protocol solution MUST provide data origin authentication. o The protocol solution MUST provide data origin authentication.
o The protocol solution MUST be robust against denial of service o The protocol solution MUST be robust against denial of service
(DoS) attacks. In this context, the protocol solution MUST (DoS) attacks. In this context, the protocol solution MUST
consider a specific mechansim for the DoS that the user might consider a specific mechansim for the DoS that the user might
create by sending many IGMP messages. create by sending many IGMP messages.
o The protocol solution SHOULD offer confidentiality protection. o The protocol solution SHOULD offer confidentiality protection.
o The protocol solution SHOULD ensure that operations in default o The protocol solution SHOULD ensure that operations in default
configuration guarantees low level of AN/NAS protocol configuration guarantees low level of AN/NAS protocol
interactions. interactions.
o The protocol solution SHOULD ensure the access control of the
management objects and possibly encrypt the values of these
objects when sending them over the networks.
o The protocol solution SHOULD ensure the security of the management
channels.
9. Security Considerations 9. Security Considerations
This document focuses on security threats deriving a threat model for This document focuses on security threats deriving a threat model for
ANCP and presenting the security requirements to be considered for ANCP and presenting the security requirements to be considered for
the design of ANCP protocol. the design of ANCP protocol.
10. IANA Considerations 10. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
skipping to change at page 16, line 40 skipping to change at page 17, line 21
[RFC3365] Schiller, J., "Strong Security Requirements for Internet [RFC3365] Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", August 2002. Engineering Task Force Standard Protocols", August 2002.
12.2. Informative References 12.2. Informative References
[I-D.ietf-ancp-framework] [I-D.ietf-ancp-framework]
Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks", Control Mechanism in Broadband Multi-Service Networks",
draft-ietf-ancp-framework-08 (work in progress), draft-ietf-ancp-framework-10 (work in progress), May 2009.
February 2009.
[I-D.ietf-ancp-mib-an]
Cnodder, S. and M. Morgenstern, "Access Node Control
Protocol (ANCP) MIB module for Access Nodes",
draft-ietf-ancp-mib-an-03 (work in progress), June 2008.
Authors' Addresses Authors' Addresses
Hassnaa Moustafa Hassnaa Moustafa
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Les Moulineaux, 92794 Cedex 9 Issy Les Moulineaux, 92794 Cedex 9
France France
Email: hassnaa.moustafa@orange-ftgroup.com Email: hassnaa.moustafa@orange-ftgroup.com
 End of changes. 16 change blocks. 
24 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/