RFC 5713
Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
RFC 5713 🎀 is an IETF Request for Comments from January 2010, and it's Informational, so it's not a Standards Track spec 🦋. The authors are H. Moustafa (France Telecom), H. Tschofenig (Nokia Siemens Networks), and S. De Cnodder (Alcatel-Lucent). The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates ✨
Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) 💜
Abstract
okay so ANCP 🧚 is the Access Node Control Protocol, and it's all about sharing QoS-related, service-related, and subscriber-related configs and operations between a Network Access Server (NAS) and an Access Node (think a Digital Subscriber Line Access Multiplexer (DSLAM)) 📡. The big goal is letting the NAS configure, manage, and control access equipment, and letting Access Nodes report info back to the NAS 💅
This doc looks at the security threats every ANCP node could run into 😭 It builds a threat model for ANCP security so we can figure out which security functions are needed, and then it sets out the security requirements for the protocol 🔥
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🙈
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc5713 ✨
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅
Table of Contents
1. Introduction ....................................................3
2. Specification Requirements ......................................3
3. System Overview and Threat Model ................................4
4. Objectives of Attackers .........................................7
5. Potential Attacks ...............................................7
5.1. Denial of Service (DoS) ....................................7
5.2. Integrity Violation ........................................8
5.3. Downgrading ................................................8
5.4. Traffic Analysis ...........................................8
5.5. Management Attacks .........................................8
6. Attack Forms ....................................................9
7. Attacks against ANCP ...........................................10
7.1. Dynamic Access-Loop Attributes ............................11
7.2. Access-Loop Configuration .................................12
7.3. Remote Connectivity Test ..................................14
7.4. Multicast .................................................14
8. Security Requirements ..........................................16
9. Security Considerations ........................................16
10. Acknowledgments ...............................................17
11. References ....................................................17
11.1. Normative References .....................................17
11.2. Informative References ...................................171. Introduction 🦋
Okay so ANCP is the Access Node Control Protocol, and it handles 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)) ✨
[ANCP-FRAME] lays out the framework, the usage scenarios, and the general requirements for ANCP 📚 This document is all about the security threats and deriving the security requirements for the protocol 🔒 It takes the ANCP use cases from [ANCP-FRAME] and also follows the guidelines for IETF protocol security requirements in [RFC3365] 💅 Section 5 covers the potential attacks and Section 6 covers the different attack forms that could happen within ANCP. Section 7 then applies those attacks to ANCP and its different use cases 🎀
One thing that's out of scope 🙅 is security policy negotiation, including authentication and authorization for defining the per-subscriber policy at the policy/AAA (Authentication, Authorization, and Accounting) server 😤
Here's the high-level summary of what we need to think about:
Message Protection:
Signaling message content can be protected against eavesdropping, modification, injection, and replay while it's in transit 🛡️ This applies to both ANCP headers and payloads 💖
Prevention against Impersonation:
It's super important to have protection against a device impersonating an ANCP node. That means an unauthorized device generating an ANCP message and pretending it came from a valid ANCP node 👀
Prevention of Denial-of-Service Attacks:
ANCP nodes and the network have finite resources (state storage, processing power, bandwidth) 🥺 We need to protect against exhaustion attacks on these resources, and stop ANCP nodes from being used to launch attacks on other network elements 🚫
2. 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]. The qualification is 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 🧚
3. System Overview and Threat Model ✨
okay so let's set the scene 🎀 As described in [ANCP-FRAME] and shown in Figure 1, the Access Node Control system is made up of a few main pieces, and I'm obsessed with how they all fit together 🧚
Network Access Server (NAS) 💅:
A NAS provides access to a service (think network access) and acts as a client of the AAA protocol. The AAA client is in charge of passing along authentication info to designated AAA servers, and then acting on whatever response comes back. literally the middleman energy 🫶
Authentication, Authorization, and Accounting (AAA) server 👑:
An AAA server handles authenticating users, authorizing access to services, and sending authorization info (including configuration parameters) back to the AAA client so service can get delivered to the user. Because of that, service usage accounting might be turned on, and info about the user's resource usage gets sent to the AAA server. the paper trail is real 📝
Access Node (AN) 🌸:
The AN is a network device, usually sitting at a service provider central office or street cabinet, that terminates access-loop connections from subscribers. If the access loop is a Digital Subscriber Line (DSL), people often call it a DSL Access Multiplexer (DSLAM). it's giving gatekeeper 🚪
Customer Premises Equipment (CPE) 🍓:
A CPE is a device inside a subscriber's premises that's connected on the LAN side of the Home Gateway (HGW). cozy home vibes 🏡
Home Gateway (HGW) 🦋:
The HGW connects the different CPEs to the Access Node and the access network. For DSL, the HGW is a DSL Network Termination (NT) that can work either as a layer 2 bridge or as a layer 3 router. In the latter case, the device is also called a Routing Gateway (RG). two modes, one icon 😎
Aggregation Network 💜:
The aggregation network brings together traffic from multiple ANs towards the NAS. ATM or Ethernet transport technologies can be used. the bundling era 🌈
For the threat analysis, this document focuses on the ANCP communication between the Access Node and the NAS. Other components (like HGW, CPE, and the AAA server) still matter, though, because they help you understand the system architecture and what triggers ANCP communications. Note that the NAS and the AN might belong to two different administrative realms. The threat model and the security requirements in this document consider this latter case. ngl this is the plot twist 👀
+--------+
| AAA |
| Server |
+--------+
|
|
+---+ +---+ +------+ +-----------+ +-----+ +--------+
|CPE|---|HGW|---| | |Aggregation| | | | |
+---+ +---+ |Access| | Network | | | |Internet|
| Node |----| |----| NAS |---| / |
+---+ +---+ | (AN) | | | | | |Regional|
|CPE|---|HGW|---| | | | | | |Network |
+---+ +---+ +------+ +-----------+ +-----+ +--------+
Figure 1: System OverviewIn the absence of an attack, the NAS gets configuration info from the AAA server about a CPE that's trying to access the network. A bunch of parameters, including Quality of Service information, need to be conveyed to the Access Node so they can take effect. The Access Node Control Protocol runs between the NAS and the AN to start control requests. The AN sends back responses to these control requests and also provides information reports. it's a whole conversation 💬
For this to happen, the following individual steps must occur:
- The AN discovers the NAS. 🔍
- The AN needs to start the protocol communication with the NAS to announce its presence. 📣
- The AN and the NAS perform a capability exchange. 🤝
- The NAS sends requests to the AN. 📨
- 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. 🫧
- The AN provides status reports to the NAS. 📊
Attackers can be:
- off-path, i.e., they cannot see the messages exchanged between the AN and the NAS; 🙈
- on-path, i.e., they can see the messages exchanged between the AN and the NAS. 👀
Both off-path and on-path attackers can be:
- passive, i.e., they do not participate in the network operation but rather listen to all transfers to obtain the maximum possible information; 🕵️
- active, i.e., they participate in the network operation and can inject falsified packets. 💀
We assume the following threat model:
- An off-path adversary located at the CPE or the HGW. 🎭
- 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). 🌐
- An on-path adversary located at network elements between the AN and the NAS. 🧷
- An on-path adversary taking control over the NAS. 🚨
- An on-path adversary taking control over the AN. 🚨
4. Objectives of Attackers 🎯
Attackers can aim at one individual entity or at a big chunk of the access network. Attacks fall into three classes:
- Attacks to disrupt the communication for individual customers. 😤
- 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. 🌪️
- 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 configure a better QoS profile on its own DSL line, increasing its own benefit. 💸
5. Potential Attacks ⚔️
This section talks about the different types of attacks against ANCP, while Section 6 covers the possible ways they could happen. 🗺️
ANCP is mainly susceptible to the following types of attacks:
5.1. Denial of Service (DoS) 🙅♀️
A bunch of denial-of-service (DoS) attacks can make ANCP nodes malfunction. When state is established or certain functions run without needing prior authorization, there's a chance to mount denial-of-service attacks. An adversary can use this to send a huge number of signaling messages to allocate state at nodes and eat up resources. Also, an adversary, through DoS, can stop certain subscribers from accessing certain services. DoS can even happen at the AN or the NAS themselves, where one of them can intentionally ignore requests from the other by just not replying. This makes the sender retransmit the request, which might allocate extra state at the sender side to process the reply. Allocating more state may end in memory depletion. 🧠💥
5.2. Integrity Violation 🧩
Adversaries who gain illegitimate access to the transferred messages can act on them and cause an integrity violation. Integrity violation can cause unexpected network behavior, which leads to disruption in network services as well as in network functioning. 🫠
5.3. Downgrading 📉
Protocols can be useful in lots of different scenarios with different security and functional requirements. Different parts of a network (for example, within a building, across a public carrier's network, or over a private microwave link) may need different levels of protection. It's often hard to meet these (sometimes conflicting) requirements with a single mechanism or fixed set of parameters, so a selection of mechanisms and parameters is usually offered. A protocol is required to agree on certain (security) mechanisms and parameters. An insecure parameter exchange or security negotiation protocol can give an adversary the chance to mount a downgrading attack and force selection of mechanisms weaker than those the parties actually want. So, without binding the negotiation process to the legitimate parties and protecting it, ANCP might only be as secure as the weakest mechanism on offer (for example, weak authentication), and the benefits of defining configuration parameters and a negotiation protocol are lost. this is the classic "we negotiated down to the weakest option" trap 🚩
5.4. Traffic Analysis 🔎
An adversary can sit at the NAS, the AN, or any other network element capturing all traversing packets. That means adversaries can get unauthorized information access. They can also gather info relevant to the network and then use it to gain unauthorized access later. This attack can also help adversaries with other shady goals -- for example, capturing messages sent from the AN to the NAS announcing that a DSL line is up and containing some info about the connected client. That could be any form of info about the client, and it could even indicate whether or not the DSL subscriber is at home at a particular moment. 🏠👀
5.5. Management Attacks 🛠️
Since the ANCP sessions are configured in the AN and not in the NAS [ANCP-FRAME], most ANCP configuration happens in the AN. As a result, the management attacks on ANCP mainly concern the AN configuration phase. In this context, the AN MIB module could create disclosure- and misconfiguration-related attacks. [ANCP-MIB] defines the vulnerabilities on the management objects within the AN MIB module. These attacks mainly concern unauthorized changes to the management objects, which can lead to a bunch of problems: session deletion, a session using an undesired or unsupported protocol, disabling certain ANCP capabilities or enabling undesired ones, ANCP packets being sent out to the wrong interface (and so being received by an unintended receiver), harming the synchronization between the AN and the NAS, and impacting traffic in the network other than ANCP. 😱
6. Attack Forms ✨
okay so Section 5 covered the attacks, and this part is about the ways an attacker actually pulls them off 🕵️♀️ The attacks from Section 5 can be carried out through the following means:
Message Replay 🔁
this is when an adversary eavesdrops, collects signaling messages, and then replays them later on, or at a different place, or in a different way (think cut-and-paste attacks) 💀 Through replaying signaling messages, an adversary might mount denial-of-service and theft-of-service attacks.
Faked Message Injection 💉
an adversary may be able to inject false error or response messages, which makes the protocol act unexpectedly and can end in a DoS attack 😭 This could happen at the signaling-protocol level, at the level of specific signaling parameters (e.g., QoS information), or at the transport layer. For example, an adversary might inject a signaling message to request allocation of QoS resources, and then other users' traffic might get impacted 🙈 The discovery protocol is especially vulnerable to this one, no cap.
Messages Modification ✏️
this one is an integrity violation, where an adversary changes signaling messages to cause unexpected network behavior 😤 Related moves an adversary might consider include reordering and delaying messages, which can cause a protocol's process to fail.
Man-in-the-Middle 🕴️
an adversary might claim to be a NAS or an AN and sit in the middle to disrupt communication and services later on 🚨 The fallout can range from DoS all the way to fraud. A man-in-the-middle adversary could modify the intercepted messages (integrity violation), or drop or truncate them (DoS and a protocol's process failure) 💔 It can also signal information to an illegitimate entity instead of the right destination. In that case the protocol could appear to keep working correctly, which may result in an AN contacting a wrong NAS. For the AN, this could mean the protocol failed for unknown reasons 🤷♀️ A man-in-the-middle adversary can also cause downgrading attacks by initiating faked configuration parameters and by forcing selection of weak security parameters or mechanisms.
Eavesdropping 👀
this is about adversaries who can eavesdrop on transferred messages. Collecting the transferred packets 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, performance information, and more. Iconic behavior for a villain, honestly 🎭
7. Attacks against ANCP 🎀
ANCP is susceptible to security threats, and they can cause disruption or 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 ANCP, considering the four use cases defined in [ANCP-FRAME] 📋
Okay, plot twist: ANCP isn't involved in the communication between the NAS and the AAA/policy server, but that link still matters a lot for ANCP security 🫶 So this document also considers the attacks related to the ANCP operation tied to the communication between the NAS and the AAA/Policy server. In other words, the threat model and security requirements here take into account the data transfer between the NAS and the AAA server, whenever that data is used within the ANCP operation.
Beyond the attacks against the four ANCP use cases (covered in the following subsections), ANCP is also open to a bunch of attacks during the protocol-establishment phase 🚧 These are mainly on-path attacks, taking the form of DoS or man-in-the-middle attacks, and they could look like this:
- Attacks during the session initiation from the AN to the NAS: DoS attacks could take place and affect the session-establishment process. Man-in-the-middle attacks could also happen, causing message truncation or message modification and leading to session-establishment failure 😵
- Attacks during the peering establishment: DoS attacks could take place during state synchronization between the AN and the NAS. Man-in-the-middle attacks could also take place through message modification during identity discovery, which may lead to loss of contact between the AN and the NAS 📵
- Attacks during capabilities negotiation: Message replay could take place, leading to DoS. Man-in-the-middle attacks could also take place, leading to message modification, message truncation, or downgrading through advertising lesser capabilities 📉
7.1. Dynamic Access-Loop Attributes 📡
this use case is all about communicating access-loop attributes for dynamic, access-line topology discovery 🗺️ Since the access-loop rate may change over time, advertising it helps the NAS learn about the topology of the access network for QoS scheduling. Besides data rates and access-loop link identification, other information may also be sent from the AN to the NAS (for a DSL access loop, examples are DSL type, maximum achievable data rate, and maximum data rate configured for the access loop) 💅 So this use case is vulnerable to a number of on-path and off-path attacks, which 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:
- Active, acting on the transferred attributes and injecting falsified packets. The main attacks here are:
- Man-in-the-middle attacks can cause access-loop attributes transfer between the AN and a forged NAS, or between a forged AN and the NAS. This 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 by changing the actual data rate of the access loop, which impacts the downstream shaping from the NAS 📉
- Passive, only learning these attributes. The main attacks here are caused by:
- Eavesdropping, through learning access-loop attributes and information about the clients' connection state, which impacts their privacy protection 👁️
- Traffic analysis, allowing unauthorized information access, which could allow later unauthorized access to the NAS 🕵️♀️
Off-path attacks can take place on the Internet and affect the access-loop attribute sharing between the NAS and the AAA/policy server 🌐 These attacks may be:
- Active attacks, which mainly concern:
- DoS through flooding the communication links to the AAA/policy server, causing service disruption 🌊
- Man-in-the-middle, causing access-loop configuration retrieval by an illegitimate NAS 🙅♀️
- Passive attacks, gaining information on the access-loop attributes. The main attacks in this case are:
- Eavesdropping, through learning access-loop attributes and information about the clients' connection states, which impacts their privacy protection 🫣
- Traffic analysis, allowing unauthorized information access, which could allow later unauthorized access to the NAS 🔍
7.2. Access-Loop Configuration 🛠️
this use case is about dynamic, local-loop line configuration, where the NAS is allowed to change access-loop parameters (e.g., rate) on the fly 🏎️ This allows for centralized, subscriber-related service data. The 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:
- Active attacks, taking the following forms:
- DoS attacks on the AN can take place when an attacker replays the Configure Request messages 📨
- An attacker on the AN can stop the AN from reacting to the NAS request for the access-loop configuration. This leads to the NAS continually sending the Configure Request message and, hence, allocating additional states 🌀
- Damaging clients' profiles at ANs can take place when adversaries have gained control of 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 an adversary can also be a man-in-the-middle. These attack forms can be related to a privileged client profile (one with more services), in order to configure this profile on the adversary's own DSL line, which is less privileged. So the attacker doesn't expose its identity, they may also use these attack forms related to the privileged client profile to configure a number of illegitimate DSL lines 🥷 The adversary can also force configuration parameters other than the selected ones, leading to, for instance, downgrading the service for a privileged client 📉
- 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 by seeing the configuration that someone else gets. For example, one ISP might be interested to know what the customers of another ISP get, and therefore might break into the AN to see this 👀
Off-path attacks can take place as follows:
- An off-path passive adversary on the Internet can exert eavesdropping during the access-loop configuration retrieval by the NAS from the AAA/policy server 🎧
- An off-path active adversary on the Internet can threaten the centralized subscribers-related service data in the AAA/policy server, for instance by making subscribers' records inaccessible 🔒
7.3. Remote Connectivity Test ✨
okay so in this use case the NAS can run a Remote Connectivity Test 🧪 by using ANCP to kick off an access-loop test between the AN and the HGW. which means multiple access-loop technologies can be supported 🌈 but ngl this one is super exposed to a bunch of active attacks 😭 and most of them mess with how the network operates 💀
on-path active attacks can happen in these ways:
- a man-in-the-middle attack during the NAS's triggering to the AN to carry out the test 🙈 where an adversary can inject falsified signals or can truncate the triggering
- message modification can happen during the Subscriber Response message transfer from the AN to the NAS that announces the test results 💅 which causes the test operation to fail
- an adversary on the AN can stop the AN from sending the Subscriber Response message to the NAS that announces the test results 😤 so the NAS keeps triggering the AN to carry out the test, and that means more state gets allocated at the NAS 🥲 this may result in unavailability of the NAS to the ANs
off-path active attacks can happen like this:
- an adversary can cause DoS during the access-loop test 🚨 in the case of an ATM-based access loop, when the AN generates loopback cells. this can happen through signal replaying
- message truncating by an adversary during the access-loop test can lead to service disruption because the test is assumed to have failed 💔
7.4. Multicast 🎶
okay this one is so cute 🥹 ANCP could be used to exchange information between the AN and the NAS, which lets the AN do replication inline with the policy and configuration of the subscriber 🧚 and it also lets the NAS follow the subscribers' multicast (source, group) membership and control the replication the AN does. four multicast use cases are expected to happen with ANCP 👑 these are typically multicast conditional access, multicast admission control, multicast accounting, and spontaneous admission response. this section gives a high-level tour of the possible attacks in these cases, and the attacks that can happen are mostly active attacks 🔥
on-path active attacks can look like this:
- DoS attacks 😩 that leave certain subscribers unable to access particular multicast streams, or only able to access the multicast stream at a reduced bandwidth, which hits the quality of the video stream 📺 this can happen through message replay by an attacker between the AN and the NAS, on the AN or on the NAS. these DoS attacks can also be done by tempering, for instance, with white/black list configuration, or by attacking the bandwidth-admission-control mechanism
- an adversary on the NAS can stop the NAS from reacting to the AN's requests for white/black/grey lists or for admission control for the access line 🫠 the AN then wouldn't get a reply and would keep sending its requests, which means more states get allocated at the AN. a similar case happens for admission control when the NAS can also send requests to the AN. when the NAS doesn't receive a response, it could also retransmit requests, which means more state gets allocated at the NAS side to process responses. this may result in the unavailability of the NAS to the ANs
- man-in-the-middle attacks, where the exchange of messages between the AN and a forged NAS, or between a forged AN and the NAS, gets hijacked 🕵️♀️ this can lead to the following:
- message modification, which can cause service downgrading for legitimate subscribers, for instance an illegitimate change of a subscriber's policy
- message truncation between the AN and the NAS, which can result in the non-continuity of services
- message replay between the AN and the NAS, on the AN or on the NAS, leading to a DoS or services fraud
- message modification to tamper with accounting information, for example to avoid service charges or, the other way around, to artificially increase service charges on other users 💸
an off-path active attack looks like this:
- DoS could happen through message replay of join/leave requests by the HGW or CPE, which frequently triggers ANCP activity between the AN and the NAS. DoS could also result from the HGW or CPE generating heaps of IGMP join/leaves, which leads to a very high rate of ANCP query/response 🌪️
8. Security Requirements 🛡️
this section presents a bunch of requirements that are motivated by the different types of attacks from the previous section. so here they are, bestie 🫶 these requirements are as follows:
- The protocol solution MUST offer authentication of the AN to the NAS. 🔐
- The protocol solution MUST offer authentication of the NAS to the AN. 🔐
- The protocol solution MUST allow authorization to take place at the NAS and the AN. ✅
- The protocol solution MUST offer replay protection. 🔁
- The protocol solution MUST provide data-origin authentication. 🧾
- The protocol solution MUST be robust against denial-of-service (DoS) attacks. In this context, the protocol solution MUST consider a specific mechanism for the DoS that the user might create by sending many IGMP messages. 🚫
- The protocol solution SHOULD offer confidentiality protection. 🤫
- The protocol solution SHOULD ensure that operations in default configuration guarantee a low number of AN/NAS protocol interactions. 🌿
- 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. 🔒
9. Security Considerations 💜
this document is all about security threats 😤 it derives a threat model for ANCP and presents the security requirements that should be considered for the design of ANCP. this is the whole point, periodt 💅
10. Acknowledgments 🫶
huge thanks to Francois Le Faucher for reviewing this document and for all his useful comments 🌸 the authors would also like to thank Philippe Niger, Curtis Sherbo, and Michael Busser for reviewing this document too. other thanks go to Bharat Joshi, Mark Townsley, Wojciech Dec, and Kim Hylgaard, who had valuable comments during the development of this work 🦋
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3365] Schiller, J., "Strong Security Requirements for
Internet Engineering Task Force Standard Protocols",
BCP 61, RFC 3365, August 2002.11.2. Informative References
[ANCP-FRAME] 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", Work in Progress, October 2009.
[ANCP-MIB] De Cnodder, S. and M. Morgenstern, "Access Node Control
Protocol (ANCP) MIB module for Access Nodes", Work
in Progress, July 2009.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.comthat's the whole spec, bestie 🌈✨ you did it 💖
📦 where this page comes from
- ietf: rfc5713 2010-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms