RFC 4081
Security Threats for Next Steps in Signaling (NSIS)
Part 1 of 7 💖
Title Block 🎀
Okay so this one is an Informational RFC from the Network Working Group, which is the IETF's neat little club for protocol docs. It's RFC 4081, titled "Security Threats for Next Steps in Signaling (NSIS)" 🦋. The authors are H. Tschofenig and D. Kroeselberg, both from Siemens, and it's dated June 2005. The title block doesn't list anything it obsoletes or updates, so no drama there ✨
Status of This Memo 🌸
This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind, so it's more of a "here's what to watch out for" doc than a rulebook 📖 Distribution is unlimited, so share it with your whole group chat 💅
Copyright Notice 🌈
Copyright (C) The Internet Society (2005) 💜
Abstract ⭐
This is a threats doc, which means it digs deep into the security risks that matter for the Next Steps in Signaling (NSIS) protocol suite 🔥 It points out and explains various security considerations found in the NSIS Requirements, Framework, and Protocol proposals. It's not calling out vulnerabilities in specific parts of the NSIS suite though, so don't go looking for those here 🙈
Table of Contents 🧚
1. Introduction ....................................................2
2. Communications Models ...........................................3
3. Generic Threats .................................................7
3.1. Man-in-the-Middle Attacks ..................................8
3.2. Replay of Signaling Messages ..............................11
3.3. Injecting or Modifying Messages ...........................11
3.4. Insecure Parameter Exchange and Negotiation ...............12
4. NSIS-Specific Threat Scenarios .................................12
4.1. Threats during NSIS SA Usage ..............................13
4.2. Flooding ..................................................13
4.3. Eavesdropping and Traffic Analysis ........................15
4.4. Identity Spoofing .........................................15
4.5. Unprotected Authorization Information .....................17
4.6. Missing Non-Repudiation ...................................18
4.7. Malicious NSIS Entity .....................................19
4.8. Denial of Service Attacks .................................20
4.9. Disclosing the Network Topology ...........................21
4.10. Unprotected Session or Reservation Ownership .............21
4.11. Attacks against the NTLP .................................23
5. Security Considerations ........................................23
6. Contributors ...................................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................251. Introduction ✨
Okay so whenever someone builds a new protocol or changes an existing one, the security threats should be evaluated 🫶 That's the whole vibe. To get security sorted in the NSIS working group, a bunch of steps have already happened:
- NSIS Analysis Activities (see [RSVP-SEC] and [SIG-ANAL])
- Security Threats for NSIS
- NSIS Requirements (see [RFC3726])
- NSIS Framework (see [RFC4080])
- NSIS Protocol Suite (see GIMPS [GIMPS], NAT/Firewall NSLP [NATFW-NSLP] and QoS NSLP [QOS-NSLP])
This document is where the basic security threats get identified, and they need to be addressed while the NSIS protocol suite is being designed 🔥 Even when the base protocol is secure, certain extensions can cause trouble once they're used in a particular environment. Plot twist, right? 😭
This document can't cover detailed threats for every possible NSIS Signaling Layer Protocol (NSLP) though 💀 QoS [QOS-NSLP], NAT/Firewall [NATFW-NSLP], and other NSLP documents need to describe their trust models and do a threat assessment for their own application domain. This doc is here to help with the later design of the NSIS protocol suite 🌸 Looking into security threats in one specific architecture or context is outside its scope, so that's a different story.
We use the NSIS terms defined in [RFC3726] and in [RFC4080] 🎀
2. Communications Models 🦋✨
okay so bestie, NSIS is this whole family of protocols built to set up and tweak state at nodes along the data path 🛤️. That means a bunch of different entities have to talk to each other, so this section is basically the group chat roster: who's talking to who, and how much they trust each other 💅. This section gives us the vocab for the communication models that matter when we're trying to lock down NSIS security 🔒.
The network picture is in Figure 1, and Figure 2 shows how the NSIS entities relate to each other along the path 🗺️. It's only showing end-to-end NSIS signaling for clarity, but it could be used in other ways too. Signaling can start anywhere and end anywhere in the network 🌐. And depending on how much trust the NSIS entities have in each other and in the parts of the network the message crosses, different security problems pop up 😬.
+------------------+ +---------------+ +------------------+
| | | | | |
| Administrative | | Intermediate | | Administrative |
| Domain A | | Domains | | Domain B |
| | | | | |
| (Inter-domain Communication) |
| +-------->+---+<------------->+---+<--------+ |
| (Intra-domain | | | | (Intra-domain |
| Communication) | | | | Communication) |
| | | | | | | |
| v | | | | v |
+--------+---------+ +---------------+ +---------+--------+
^ ^
| |
First Peer Communication Last Peer Communication
| |
v v
+-----+-----+ +-----+-----+
| NSIS | | NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Figure 1: Communication patterns in NSISHere's the trust thing, which is the heart of it 💖. The word "trust" in this doc is kinda informal, and the real definition lives in Section 1.1 of [RFC3756] 📖. For completeness, a trust relationship is a mutual a priori relationship between the involved organizations or parties, where each party believes the others will keep behaving correctly even in the future 🤝.
Now the big deal: intermediate NSIS nodes between an NSIS Initiator and an NSIS Responder need a certain degree of trust, specifically so they can process messages and take the actions they need to 🫶. If there's a complete lack of trust between any of the participating entities, NSIS signaling is going to fail 💀.
It's also impossible to describe a trust model properly without looking at the NTLP, the NSLP (like the QoS NSLP), and the deployment environment too 🧩. For example, securing the link between an end host (the NSIS Initiator) and the first NSIS node is affected by the trust between those two, and that first node might be in the attached network or several networks away 🛰️. In a corporate network there's usually a stronger degree of trust than in an unmanaged network 🏢.
Intra-Domain and Inter-Domain Communication
Figure 1 gives us handy shorthand for network parts with similar properties: first-peer, last-peer, intra-domain, or inter-domain 🏷️.
First-Peer/Last-Peer Communication
So the end-to-end scenario in Figure 1 includes the chat between end hosts and their closest NSIS hops 💬. "First-peer communications" means the peer-to-peer interaction between the signaling message originator, the NSIS Initiator (NI), and the first NSIS-aware entity on the path 🚀. This kind of communication often comes with specific security requirements, especially for the security issues between the end host (and its user) and the network it's attached to 🔐.
Here's the vibe check: in roaming environments, you can't really assume a pre-established security association is ready to go for NSIS peers in first-peer communications, because those peers probably have no existing relationship at all 🧳. Enterprise networks are the opposite, since there's usually a pretty strong, pre-established trust relationship between the peers 💼. Enterprise admins also usually have some freedom to pick the right security protection and enforce it 👑. So the infrastructure that's already there often shapes which security mechanism gets chosen, and negotiating security mechanisms per session often isn't required 🙌. (In a roaming environment, though, it is required, so no skipping that one 🌍.)
Last-Peer communication is basically First-Peer communication with the roles flipped 🔄.
Intra-Domain Communication
After the NSIS signaling message gets verified at the border of an administrative domain, it travels through the network inside that same domain that the first peer belongs to 🏰. It might not be necessary to redo the NSIS initiator's authorization at every NSIS node in this domain, and key management inside the domain might be simpler too 🔑.
Security protection is still required though, to stop threats from non-NSIS nodes in this network 🛡️. No shortcuts here, bestie 🙅♀️.
Inter-Domain Communication
Inter-domain communication is all about the interaction between administrative domains 🌉. For some NSLPs (like the QoS NSLP), this is likely to happen between neighboring domains. For other NSLPs (like the NAT/Firewall NSLP), the core network usually isn't involved at all 🧱.
If signaling messages pass transparently through the core network (meaning they're neither intercepted nor processed there), then the signaling effectively happens between access networks 🛣️. That could put a burden on authorization handling and on the key management infrastructure between these access networks, which might not know about each other ahead of time 😵💫.
To get more specific about the network parts NSIS signaling might cross, we look at the relationships between the entities involved 🔍. A bunch of NSIS nodes might actively join a single protocol exchange, so there are more possible relationships to analyze than in other protocols 🌀. Figure 2 shows the possible relationships between the entities in the NSIS protocol suite 🎨.
****************************************
* *
+----+-----+ +----------+ +----+-----+
+-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+
| | Node 1 | | Node 2 | | Node 3 | |
| +----------+ +----+-----+ +----------+ |
| ~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~ |
+--+--+-----+ +---------+-+
| NSIS +//////////////////////////////////////////+ NSIS |
| Initiator | | Responder |
+-----------+ +-----------+
Legend:
-----: Peer-to-Peer Relationship
/////: End-to-End Relationship
*****: Middle-to-Middle Relationship
~~~~~: End-to-Middle Relationship
Figure 2: Possible NSIS RelationshipsEnd-to-Middle Communications
This is when one NSIS entity is an end-entity (Initiator or Responder) and the other is any intermediate hop that isn't the immediately adjacent peer. It's typically called the end-to-middle scenario (see Figure 2) 🎯. You can find a motivation for including this scenario in SIP [RFC3261] 📞.
An example would be an explicit authorization from the NSIS Initiator to some intermediate node 🤳. Threats specific to this scenario may come from intermediate NSIS hops that aren't allowed to eavesdrop on or modify certain objects 👀.
Middle-to-Middle Communications
Middle-to-middle communication is the exchange of information between two non-neighboring NSIS nodes along the path 🧑🤝🧑. Intermediate NSIS hops may have to handle specific security threats that don't directly involve the NSIS Initiator or the NSIS Responder 🕸️.
End-to-End Communications
NSIS wants to signal information from an Initiator to some NSIS nodes along the path toward a data receiver 📨. In end-to-end NSIS signaling, the last node is the NSIS Responder, because it's the data receiver 🏁. The NSIS protocol suite is NOT an end-to-end protocol for exchanging information purely between end hosts, though 🙅♀️. (Okay, that one's written in caps for dramatic effect, but it's not a BCP 14 key word in the original, so keep it in mind as plain text: the suite is not an end-to-end protocol just for end hosts 💅.)
Typically, it is not required to protect NSIS messages cryptographically between the NSIS Initiator and the NSIS Responder 🔓. Protecting the whole signaling message end-to-end might not be feasible, since intermediate NSIS nodes need to add, inspect, modify, or delete objects from the signaling message 🧩✨.
3. Generic Threats ✨
okay so this section is literally a rundown of threat scenarios that apply to signaling protocols in general 🫶 some of the scenarios say "user" instead of "NSIS Initiator", and that's on purpose 💅 security protocols can tell apart entities that are hosts and entities that are users, based on the identifiers they use 🎀
For the subsections below, we split the attacks into two cases, based on the separate steps (or phases) you normally run into when you apply protocol security, like with IPsec, TLS, Kerberos, or SSH 🦋 so first, a quick explainer on why we even split it up 👀
Security protection is often done in two steps 🌸 The first step mainly handles entity authentication and key establishment, and that leaves behind a persistent state often called a security association. The second step handles message protection, which is some mix of data origin authentication, data integrity, confidentiality, and replay protection, and it uses the security association from step one ✨ Step one tends to be more expensive than step two, and that's the main reason for the split 💰 if messages are sent only now and then, the two steps can be squished into one usually pretty costly step, like e-mail protection via S/MIME 📧 the two steps can also be tightly bound into a single protocol (like TLS), or defined as separate protocols (like IKE and IPsec) 🧚 we use this separation to dig into the different threats in more detail 💖
3.1. Man-in-the-Middle Attacks
this part covers two kinds of security threats 🕵️♀️ the first is what happens if two peers don't already share a security association, or don't use security mechanisms at all 🙈 the second is the threats that still apply once a security association is already set up 💜
Attacks during NSIS SA Establishment
while a security association is being set up, an adversary tricks the signaling message Initiator about which entity it's supposed to authenticate to 😭 the Initiator ends up authenticating to the man-in-the-middle adversary, who can then change signaling messages to mount DoS attacks or to steal services that get billed to the Initiator 💀 the adversary might also be able to kill the Initiator's NSIS messages and inject messages to a peer itself, so it acts like the peer toward the Initiator and like the Initiator toward the peer 👑 the result is that the Initiator honestly thinks it's talking to the "real" network, when it's actually attached to an adversary 🫠 for this attack to work, the pre-conditions in the following three cases all have to hold 🎀
Missing Authentication
in the first case, this threat works because there's no authentication between neighboring peers 🍓 without authentication, an NI, NR, or NF can't detect an adversary 👀 but in some real-world cases, authentication can be hard to pull off, because the next peer might be unknown, because there are trust relationships in parts of the network that people wrongly believe in, or because proper security protection just can't be set up (like for inter-domain signaling messages, or dynamic establishment of a security association, and so on) 🌈 if one of the communicating endpoints is unknown, then for some security mechanisms, applying proper security protection is either impossible or impractical 😤 sometimes network administrators run intra-domain signaling messages without proper security, and that setup lets an adversary sitting on a compromised non-NSIS-aware node mess with nodes running an NSIS signaling protocol 🚨 heads up: this type of threat goes beyond the ones caused by malicious NSIS nodes (which are described in Section 4.7) ✨
Unilateral Authentication
with unilateral authentication, the NSIS entity that doesn't authenticate its peer has no way to discover a man-in-the-middle adversary 😬 mutual authentication of signaling messages should happen between each peer taking part in the protocol operation, but we're giving special attention here to first-peer communications 🫶 unilateral authentication between an end host and the first peer (where only the end host gets authenticated) is still super common today, and it opens the door to a lot of man-in-the-middle attackers who can impersonate either the end host or the first peer (or the administrative domain the first peer represents) 🙃
missing or unilateral authentication, like we just described, is part of a bigger problem of network access with inadequate authentication 🧩 so it shouldn't be treated as something unique to the NSIS signaling protocol 💅 obviously there's a strong need to address this correctly in a future NSIS protocol suite 🔥 the signaling protocols that NSIS covers are different from other protocols where only two entities are involved 🦋 and first-peer authentication is especially important, because a security breach there could affect nodes beyond the entities directly involved (or even beyond a local network) 😱
finally, the signaling protocol should be thought of as a peer-to-peer protocol, where the Initiator and Responder roles can flip at any time 🔄 so unilateral authentication isn't really useful for that kind of protocol 🙅♀️ still, some form of asymmetry might be needed in the authentication process, where one entity uses a different authentication mechanism from the other one ✨ for example, combining symmetric and asymmetric cryptography is worth a mention 🌸
Weak Authentication
in the case of weak authentication, this threat works because the information sent during the NSIS SA establishment process might leak passwords or allow offline dictionary attacks 🔓 this threat applies to NSIS when it comes to selecting certain security mechanisms 🫠
Man-in-the-Middle Attacks during Discovery
finally, we wrap up with a man-in-the-middle (MITM) attack during the discovery phase 🕸️ this attack takes advantage of the fact that NSIS nodes are likely to be unaware of the network topology 🗺️ on top of that, an authorization problem might pop up if an NSIS QoS NSLP node pretends to be an NSIS NAT/Firewall-specific node, or the other way around 😳
an adversary might inject a bogus reply message, which forces the discovery message initiator to start a messaging association establishment with either the adversary or some other NSIS node that isn't along the path 🙀 Figure 3 shows this attack in more detail for peer-to-peer addressed messages with a discovery mechanism 🔍 for end-to-end addressed messages, the attack also applies, especially if the adversary is located along the path and can intercept the discovery message that passes through it 🛤️ the man-in-the-middle adversary might also redirect to another legitimate NSIS node 🔁 a malicious NSIS node can be detected with the corresponding security mechanisms, but a legitimate NSIS node that isn't the next NSIS node along the path can't be detected without topology knowledge 🫣
+-----------+ Messaging Association
Message | Adversary | Establishment
Association +--->+ +<----------------+
Establish- | +----+------+ |(4)
ment | IPx | |
(3)| |Discovery Reply v
| | (IPx) +---+-------+
v | (2) | NSIS |
+------+-----+ | /----------->+ Node B +--------
| NSIS +<--+ / Discovery +-----------+
| Node A +---------/ Request IPr
+------------+ (1)
IPiFigure 3: MITM Attack during the Discovery Exchange
this attack assumes that the adversary can eavesdrop on the initial discovery message that the sender of the discovery message sends out 👂 we also assume that the discovery reply message from the adversary gets back to the discovery message initiator faster than the real response does ⚡ this creates a race condition when the next NSIS node is really close to the initiator (in IP-hop terms) 🏃♀️ the good news is the problem heals itself, since the discovery process gets repeated on a regular basis 🩹 if the adversary can't pull this off with every discovery message, then the correct next NSIS node along the path will be discovered again 🙌 the result might be a ping-pong behavior 🏓
in step (2) of Figure 3, the adversary sends back a discovery reply message with its own IP address listed as the next NSIS-aware node along the path 🎭 without any extra information, the discovery message initiator has to trust that info 🥺 then a messaging association gets set up in step (3) with whatever entity is sitting at IP address IPx (which is the adversary) 💔 the adversary then sets up a messaging association with another NSIS node and forwards the signaling message along 📨 the adversary might also just modify the Discovery Reply message to force NSIS Node A to set up a messaging association with another NSIS node that isn't on the path 🪤 and the adversary can exploit that 😈 interworking with NSIS-unaware NATs in particular might cause extra unexpected problems 🌪️
there's also a variant of this attack 🎀 an adversary that can't eavesdrop on transmitted discovery requests could flood a node with bogus discovery reply messages instead 🌊 if the discovery message sender accidentally accepts one of those bogus messages, then a MITM attack like the one in Figure 3 becomes possible 😬
3.2. Replay of Signaling Messages
this threat scenario covers the case where an adversary eavesdrops, collects signaling messages, and replays them later (or somewhere else, or uses parts of them in a different place or a different way, like cut-and-paste attacks) 🔁 without proper replay protection, an adversary might mount man-in-the-middle attacks, denial of service attacks, and theft of service attacks 🥀
an even trickier attack (one that can still cause problems even if there is replay protection) requires the adversary to crash an NSIS-aware node, so it loses state information (like sequence numbers, security associations, and so on), and then replays old signaling messages 💥 this attack takes advantage of re-synchronization deficiencies 🧠✨
3.3. Injecting or Modifying Messages ✨
okay so this one is about messing with the signaling messages themselves 😤 it's an integrity violation, meaning the adversary changes stuff in transit (think man-in-the-middle, the classic villain move 🦹♀️) so the network starts doing weird unexpected things. no cap, that's giving chaos. the adversary can reorder, delay, drop, inject, truncate, or otherwise modify messages, basically whatever helps the attack 💅
an adversary can inject a signaling message that asks for a huge pile of resources, and it might even do it using a different user's identity 🙈 then other legit resource requests get rejected, which is so not fair bestie. and if they pair that with identity spoofing, that's how fraud happens 💀 this attack only works when there's no authentication and no signaling message protection. lowkey the whole thing falls apart if those are in place 🛡️
some threats that are directly related to this one are covered in Sections 4.4, 4.7, and 4.8, so go check those out 🎀
3.4. Insecure Parameter Exchange and Negotiation 🌸
okay so, first, protocols get used in a bunch of different scenarios, and each one has its own security needs 🦋 second, different users (like a university, a hospital, a company, or a government ministry) have totally different security requirements too 🏫🏥 third, different parts of a network (like inside a building, over a public carrier's network, or across a private microwave link) might need different levels of protection 📡
the thing is, these needs can be kinda contradictory, so it's really hard to meet them all with one security mechanism or one fixed set of parameters. so usually you get a menu of mechanisms and parameters to pick from 🍓 that means a protocol is required to agree on certain security mechanisms and parameters. but here's the tea: an insecure parameter exchange or security negotiation protocol can let an adversary pull a downgrading attack, forcing everyone to pick weaker mechanisms than they actually want 😭
so without tying the negotiation process to the legit parties and protecting it, an NSIS protocol suite might only be as secure as its weakest mechanism (like weak authentication) 💔 and then all the benefit of defining configuration parameters and a negotiation protocol just goes poof ✨
4. NSIS-Specific Threat Scenarios 👑
this section walks through eleven threat scenarios, all about attacks on, and security weaknesses in, the NSIS signaling protocol 🔥 a bunch of security deficiencies can enable an attack. fraud is a great example of an attack that can be enabled by missing replay protection, missing protection of authorization tokens, identity spoofing, missing authentication, and other gaps that help an adversary steal resources 💅 this section addresses the different threat scenarios that come from those deficiencies.
the threat scenarios aren't totally independent of each other, bestie 🫶 some of them (like denial of service) are well-established security terms, so they need to be addressed on their own. but they're often enabled by one or more of the deficiencies described under other scenarios 🧚
4.1. Threats during NSIS SA Usage 🔐
once a security association is set up (and being used) to protect signaling messages, a lot of the basic attacks are blocked ✨ however, a malicious NSIS node can still do various attacks, as described in Section 4.7. replay attacks may be possible when an NSIS node crashes, restarts, and goes through state re-establishment 😬 so proper re-synchronization of the security mechanism must be provided to deal with this problem.
4.2. Flooding 🌊
this section is about attacks where an adversary floods an NSIS node with bogus signaling messages to cause a denial of service attack 😩 we're going to look at this threat at different layers of the NSIS protocol suite, so let's dive in 🦋
Processing of Router Alert Options:
the processing of Router Alert Option (RAO) requires that a router do some extra work by intercepting packets with IP options 🫠 that can add delay for legit requests, or even get some of them rejected. a router that's being flooded with tons of bogus messages has to spend resources before it finds out those messages need to be dropped 💀
if the protocol uses interception for message delivery, this threat can't be completely eliminated 😔 but the protocol design should try to limit the processing done on the RAO-bearing packet, so it's as similar as possible to the processing for an arbitrary packet addressed directly to one of the router interfaces 🎀
Attacks against the Transport Layer Protocol:
certain attacks can be launched against transport protocols by flooding a node with bogus requests, or even by finishing the handshake phase to set up a transport layer association 🙃 these types of threats are also addressed in Section 4.11 🫶
Force NTLP to Do More Processing:
some protocol fields might let an adversary force an NTLP node to do more processing 👀 it might also be possible to interfere with the flow control or the congestion control procedure. these types of threats are also addressed in Section 4.11.
furthermore, it might be possible to force the NTLP node to do some computations or signaling message exchanges by injecting "trigger" events, which are unprotected 🚨
Force NSLP to Do More Processing:
an adversary might benefit from flooding an NSLP node with messages that must be stored (for example, because of fragmentation handling) before the correctness of the signaling messages is verified 📦
causing memory allocation and computational effort might also let an adversary harm NSIS entities 🥺 if a signaling message contains a digital signature, for example, some additional processing is needed for cryptographic verification. an adversary can easily create a random bit sequence instead of a digital signature to force an NSIS node into heavy computation 🔥
idempotent signaling messages are especially vulnerable to this type of attack 💜 the term "idempotent" refers to messages that contain the same amount of information as the original message. an example would be a refresh message that's equivalent to a create message. this property lets a refresh message create state along a new path, where no previous state is available ✨ for this to work, specific classes of cryptographic mechanisms that support this behavior are needed. one example is a scheme based on digital signatures, which, however, should be used with care due to possible denial of service attacks ⚠️
problems with using public-key-based cryptosystems in protocols are described in [AN97] and in [ALN00] 📚
in addition to the threat scenario described above, an incoming signaling message might trigger communication with third-party nodes such as policy servers, LDAP servers, or AAA servers 🏢 if an adversary can send a large number of signaling messages (for example, with QoS reservation requests) using invalid credentials, the verifying node may not be able to process other reservation messages from legit users. that's a whole mess, bestie 😭
4.3. Eavesdropping and Traffic Analysis 👀
this section covers threats where an adversary is able to eavesdrop on signaling messages 🕵️♀️ the collected signaling packets may allow traffic analysis, or be used later to mount replay attacks, as described in Section 3.2. 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 😳
an adversary's ability to eavesdrop on signaling messages might violate a user's preference for privacy, especially if unprotected authentication or authorization information (including policies and profile information) is exchanged 🙈
because the NSIS protocol signals messages through a number of nodes, it's possible to tell apart the nodes that are actively taking part in the NSIS protocol from the ones that aren't 🧐 for certain objects or messages, it might be desirable to let actively participating intermediate NSIS nodes eavesdrop. on the other hand, it might be desirable that only the intended end points (the NSIS Initiator and NSIS Responder) can read certain other objects 🎀
4.4. Identity Spoofing 🎀
okay so identity spoofing in NSIS shows up in three different forms 💅 first, it can happen while a security association is being set up, if the authentication is weak. second, an adversary can mess with the flow identifier sitting inside a signaling message. third, they can spoof actual data traffic 😭
for the first one, say Eve pretends to be the registered user Alice 🙈 now the network charges Alice for resources Eve used. this works if authentication is just a plain username (so no cryptographic authentication), or if authentication only happens at the host level and a bunch of users share one host. this could also count as theft of service, which is so not cute 💀
the second one is about flow identifiers, which QoS and NAT/FW NSLP both need to work 🦋 these include IP addresses, the transport protocol type (UDP, TCP), port numbers, and flow labels (see [RFC1809] and [RFC3697]). if an adversary changes these, they can either exploit a QoS reservation or policy rule at a middlebox, or make it stop working entirely. the attack is basically the adversary modifying the flow identifier of a signaling message 🔥
the third one is where Eve spoofs data traffic. NSIS signaling messages carry some kind of flow identifier tied to a specific behavior (like a particular flow getting QoS treatment, or being allowed through a firewall) 🌸 so an adversary could use IP spoofing and inject data packets to get the benefit of flow identifiers that were already installed.
okay here's the example, bestie 🧚 after the NSIS nodes between the NSIS initiator and the NSIS receiver process a properly protected reservation request from the legit user Alice, a QoS reservation gets installed on the matching NSIS nodes (for example, the edge router). the flow identifier is what lets data traffic from a given source get assigned to that reservation. now Eve spoofs Alice's IP address ✨ meanwhile, Alice's host might get knocked out by a denial of service attack, or lose connectivity (for example, because of mobility). if Eve can do address spoofing, she can send and receive data (like RTP traffic) that gets preferential QoS treatment because of the earlier reservation. depending on how granular the installed flow identifier is, Eve might have even more ways to exploit the QoS reservation or a pinholed firewall 👑 with the soft state paradigm, periodic refresh messages are needed, so Alice's absence doesn't get noticed until a refresh is due, and that forces Eve to answer with a protected signaling message. and again, this isn't just a QoS problem, it also applies to a firewall control protocol, just with different consequences ⭐
an adversary injecting data traffic that matches a flow identifier Alice set up usually also needs to be able to receive that traffic, or get its correspondent to receive it, to actually benefit 💖 for example, an adversary on an unmanaged network watches a NAT/Firewall signaling message heading toward a corporate network. once that signaling exchange succeeds, Alice can get through the company firewall via the established packet filter so she can reach her internal mail server. Eve, who was watching the exchange, can now build a data packet aimed at this mail server that gets past the firewall 🙈 the packet hits the mail server, causes some actions, and the mail server sends responses. depending on where the adversary sits and how asymmetric the routing is, Eve might even see those responses. and lowkey the wildest part: for this to work, Alice doesn't have to take part in the signaling messages at all 😭
we could also imagine flow identifiers that don't use source and destination addresses at all 🍓 for instance, a flow identifier that only uses the 21-bit Flow ID (no source or destination IP address). spoofing identities and injecting traffic gets way easier in that case, since a packet only has to be marked, and an adversary can use nearly any endpoint identifier to get what they want. still, the endpoint identifiers aren't irrelevant, because the messages still have to reach the nodes in the network where NSIS signaling installed state (in the example above, they'd have to hit that same firewall) 🎀
data traffic marking based on DiffServ is one example of this 🦋 whenever an ingress router uses only marked incoming data traffic for admission control, a bunch of attacks become possible. the DiffServ community has known about these problems for ages, and they're documented in lots of DiffServ-related docs. the IPsec protection of DiffServ Code Points is covered in Section 6.2 of [RFC2745], and related security issues (like denial of service attacks) are covered in Section 6.1 of that same document 💜
4.5. Unprotected Authorization Information 🔐
authorization is a big deal when it comes to giving out resources like QoS reservations, NAT bindings, and pinholes through firewalls ✨ authorization info can reach the NSIS-participating entities in several different ways.
usually, the authenticated identity is used to help out during the authorization procedure (as described in [RFC3182], for example). depending on which authentication protocol you pick, certain threats might show up 👀 Section 3 talks about a bunch of issues with this approach when the authentication and key exchange protocol is used to set up session keys for protecting signaling messages.
another approach is to use some kind of authorization token 🫶 the way such a token works and is structured for RSVP is described in [RFC3520] and [RFC3521].
getting secure interaction between different protocols that use authorization tokens does take some care, though 💅 using a token like this lets you link state information between different protocols. if an unprotected authorization token gets sent back to the end host, an adversary (like an eavesdropper) might be able to steal resources 😭 they could also use the token to watch communication patterns. and finally, an untrustworthy end host might modify the token contents 💀
the Session/Reservation Ownership problem can also be thought of as an authorization problem, and it's covered in Section 4.10 🌈 in enterprise networks, authorization is often tied to membership in a particular class of users or groups. this kind of info either comes along with the authentication and key agreement procedure, or has to be fetched from other entities through separate protocols. if an adversary manages to change the info that determines authorization, or the outcome of the authorization process itself, theft of service might be possible 🙈
4.6. Missing Non-Repudiation 🧾
signaling for QoS usually involves three parties 👑 there's the user, a network that offers QoS reservations (called the "service provider"), and a third party that guarantees the party making the reservation actually gets financial compensation (called the "trusted third party").
in this context, "repudiation" is when either the user or the service provider later denies that a QoS reservation existed, or denies some of its parameters (like volume or price), when talking to the trusted third party 🫣 lack of non-repudiation causes problems in two forms:
- Service provider's point-of-view: a user might deny having made a reservation request they got charged for. the service provider might then want to be able to prove that this particular user did issue that reservation request ✨
- User's point-of-view: a service provider might claim the user made a bunch of reservation requests. the user might want to show that those requests were never issued, and might want to see correct service usage records for a given set of QoS parameters 🥺
in today's networks, non-repudiation just isn't provided 💀 so it could be hard to add it to NSIS signaling. the user has to trust the network operator to meter traffic correctly, collect and merge accounting data, and make sure no unforeseen problems happen. if you want a signaling protocol with the non-repudiation property for setting up QoS reservations, it definitely affects the protocol design 🔥
non-repudiation functionality also puts extra requirements on the security mechanisms, so a solution would normally add overhead to a security solution 😤 threats from missing non-repudiation only count as relevant in certain specific scenarios and for specific NSLPs 🌸
4.7. Malicious NSIS Entity 😈
okay so network elements inside a domain (intra-domain) have a different trust vibe than the edge NSIS entities. The edge ones are assumed to handle all the crypto for signaling messages coming in from the outside: authentication, integrity and replay protection, authorization, and accounting. 🔐 That's what keeps unprotected signaling messages from showing up inside the internal network. ✨
BUT, and this is a big but 😭, if an adversary manages to take over an edge router, the security of the entire network is cooked. They can launch a bunch of attacks, including denial of service, integrity violations, replay and reordering of objects and messages, bundling of messages, deleting data packets, and more. 💀 A rogue firewall can also mess with other firewalls by changing their policy rules. 🙈
The chain-of-trust principle used in peer-to-peer security protection can't protect you from a malicious NSIS node. An adversary with access to an NSIS router can also get into security associations and send secured signaling messages. Even non-peer-to-peer security protection might not fully fix this problem, fr fr. 🫠 And since an NSIS node might issue signaling messages on behalf of someone else (by acting as a proxy), there are extra problems to think about. 🎀
An NSIS-aware edge router is a critical component that absolutely needs strong security protection. 💅 A strong security policy at the edge does not mean that other routers inside the intra-domain network can skip cryptographic verification of signaling messages. 🙅♀️ If the chain-of-trust principle is deployed, the security of the whole path (here, within a single administrative domain) is only as strong as the weakest link. 🔗 In this case the edge router is the most critical piece of the network, and it may also act as a security gateway or firewall for incoming and outgoing traffic. 🛡️ For outgoing traffic, this device has to implement the security policy of the local domain and apply the appropriate security protection. 💖
For an adversary to pull this off, either an existing NSIS-aware node along the path has to be successfully attacked, or the adversary has to convince another NSIS node to make it the next NSIS peer (a man-in-the-middle attack). 👀
4.8. Denial of Service Attacks 🚨
A bunch of denial of service (DoS) attacks can make NSIS nodes malfunction. Other attacks that could lead to DoS, like man-in-the-middle attacks, replay attacks, injection or modification of signaling messages, and so on, are mentioned throughout this document. 🧚
Path Finding:
Some signaling protocols set up state (for example, routing state) and perform some actions (for example, querying resources) at a number of NSIS nodes without requiring authorization (or even proper authentication), based on a single message (for example, a PATH message in RSVP). 😬
An adversary can use this to send a huge number of signaling messages to allocate state at nodes along the path and cause resource consumption. 📈
An NSIS responder might not be able to figure out who the NSIS initiator is, and might even tend to answer such a signaling message with a corresponding reservation message. 🙃
Discovery Phase:
Sending signaling information to a large number of entities along a data path requires some sort of discovery. 🗺️ This discovery process is vulnerable to a number of attacks because it's hard to secure. An adversary can use the discovery mechanisms to trick one entity into signaling information to another entity that is not along the data path, or to make the discovery process fail. 😤 In the first case, the signaling protocol could seem to keep working correctly, except that policy rules end up installed at the wrong firewalls or QoS resource reservations happen at the wrong entities. 🤡 For an end host, this just means 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 happen at the signaling message protocol layer (NTLP), at the layer of each client layer protocol (for example, QoS NSLP or NAT/Firewall NSLP), or at the transport protocol layer. An adversary might cause unexpected protocol behavior or might succeed with a DoS attack. The discovery protocol, especially, has vulnerabilities for this threat scenario (see the above discussion on discovery). 🫣 If no separate discovery protocol is used and signaling messages are addressed to end hosts only (with a Router Alert Option to intercept messages as NSIS-aware nodes), an error message might be used to indicate a path change. Such a design combines a discovery protocol with a signaling message exchange protocol. 🧩
4.9. Disclosing the Network Topology 🗺️
Some organizations or enterprises really don't want to reveal their internal network structure (or other related info) outside a closed community. 🤫 An adversary might be able to use NSIS messages for network mapping, like discovering which nodes exist, which ones use NSIS, what version they run, what resources are allocated, and what capabilities the nodes along a path have. 👀 Discovery messages, traceroute, diagnostic messages (see [RFC2745] for a description of diagnostic message functionality for RSVP), and query messages, plus record route and route objects, all give an adversary potential help. 🎁 So the requirement of not disclosing a network topology might clash with other requirements, like providing ways to discover NSIS-aware nodes automatically or providing diagnostic facilities (used for network monitoring and administration). 😩
4.10. Unprotected Session or Reservation Ownership 👑
Figure 4 shows an NSIS Initiator that has set up state information at NSIS nodes along a path as part of the signaling procedure. ✨ As a result, Access Router 1, Router 3, and Router 4 (and other nodes) have stored session-state information, including the Session Identifier SID-x.
Session ID(SID-x)
+--------+
+-----------------+ Router +------------>
Session ID(SID-x)| | 4 |
+---+----+ +--------+
| Router |
+------+ 3 +*******
| +---+----+ *
| *
| Session ID(SID-x) * Session ID(SID-x)
+---+----+ +---+----+
| Access | | Access |
| Router | | Router |
| 1 | | 2 |
+---+----+ +---+----+
| *
| Session ID(SID-x) * Session ID(SID-x)
+----+------+ +----+------+
| NSIS | | Adversary |
| Initiator | | |
+-----------+ +-----------+
Figure 4: Session or Reservation OwnershipThe Session Identifier gets included in signaling messages to reference the established state. 🏷️
If an adversary could get the Session Identifier (for example, by eavesdropping on signaling messages), they could add the same Session Identifier SID-x to a new signaling message. 😈 When that new message hits Router 3 (as shown in Figure 4), the existing state information can be modified. The adversary can then modify or delete the established reservation and cause unexpected behavior for the legit user. 💔
The root of the problem is that Router 3 (a cross-over router) can't tell whether the new signaling message came from the owner of the session or reservation. 🤷♀️
Also, nodes other than the original signaling message originator are allowed to signal information during the lifetime of an established session. As part of the protocol, any NSIS-aware node along the path (and the path might change over time) could start a signaling message exchange. 🔄 For example, it might be necessary to support mobility or to trigger a local repair procedure. If only the original signaling message originator were allowed to trigger signaling exchanges, some protocol behavior just wouldn't be possible. 🙌
If this threat scenario isn't addressed, an adversary can launch DoS attacks, theft of service, and various other attacks. 🚫
4.11. Attacks against the NTLP 🎯
In [2LEVEL], a two-level architecture is proposed that would split an NSIS protocol into layers: a signaling message transport-specific layer and an application-specific layer. 🍰 This is further developed in the NSIS Framework [RFC4080]. Most of the threats in this threat analysis apply to the NSLP application-specific part (for example, QoS NSLP). There are, however, some threats that apply to the NTLP. 🧠
Network and transport layer protocols without protection mechanisms are vulnerable to certain attacks, like header manipulation, DoS, spoofing of identities, session hijacking, unexpected aborts, and so on. 😵 Malicious nodes can attack the congestion control mechanism to force NSIS nodes into a congestion avoidance state. 🚦
Threats that address parts of the NTLP not related to attacks on the use of transport layer protocols are covered in various sections throughout this document, such as Section 4.2. 📚
If existing transport layer protocols are used to exchange NSIS signaling messages, the security vulnerabilities known for those protocols need to be considered. 🔍 A detailed threat description of these protocols is outside the scope of this document. 🫶
5. Security Considerations 🔐✨
okay bestie, this whole memo is about security for NSIS protocol design 💅 It starts by naming the parts of an NSIS network (the Initiator, the Responder, and the different Administrative Domains between them) 🧚 Then it looks at five cases where those parts talk to each other and checks what trust is assumed in each one:
- First-Peer Communications
- End-to-Middle Communications
- Intra-Domain Communications
- Inter-Domain Communications
- End-to-End Communications
Doing this helps figure out how much security each case needs and how serious each threat is in each one 🫶
The doc also points out the protocol security measures NSIS needs: authentication, key exchange, message integrity, replay protection, confidentiality, authorization, and some precautions against denial of service 🛡️ The threats are split into generic ones (man-in-the-middle attacks, replay attacks, tampering and forgery, and attacks on security negotiation protocols) and eleven threat scenarios that fit NSIS especially well 👑 Denial of service gets its own NSIS section, not because it can't happen to other protocols, but because the way you pull off a DoS attack tends to depend on the protocol 💀 There are also loads of illustrative examples showing what happens if these threats aren't handled 🙈
The memo keeps saying that not every threat is equally serious in every context. It does try to point out where a security failure would hit hardest. But honestly, the protocol designer can't predict every way NSIS will get used or every security worry its users will have. So the designer needs to offer a full range of security capabilities, and give users ways to negotiate and pick what they need on a case-by-case basis 💜 The security requirements to counter these threats are listed in [RFC3726].
6. Contributors 🎀
We're especially grateful to Richard Graveman, who wrote the text for the security considerations section and did a detailed review of the whole document 🙌
7. Acknowledgements 🫶
Huge thanks (listed alphabetically 📝) to Marcus Brunner, Jorge Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their comments on an early version of this document. Jorge and Robert sent a massive list of comments and also shared info on extra threats 😭
Thanks also to Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia Kappler, Ted Wiederhold, Vishal Sankhla, Mohan Parthasarathy, and Andrew McDonald for commenting on newer versions. Their input made the content better ✨ Roland Bless, Michael Thomas, Joachim Kross, and Cornelia Kappler especially helped with ideas for regrouping and restructuring the material 🌈
Finally, Michael Richardson gave the document a final review, and we're thanking him for his detailed comments 🍓
8. References 📚
8.1. Normative References 💖
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. van
den Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC3726] Brunner, M., "Requirements for Signaling Protocols",
RFC 3726, April 2004.8.2. Informative References 🦋
[ALN00] Aura, T., Leiwo, J., and P. Nikander, "Towards Network
Denial of Service Resistant Protocols, In Proceedings
of the 15th International Information Security
Conference (IFIP/SEC 2000), Beijing, China",
August 2000.
[AN97] Aura, T. and P. Nikander, "Stateless Connections", In
Proceedings of the International Conference on
Information and Communications Security (ICICS'97),
Lecture Notes in Computer Science 1334, Springer",
1997.
[2LEVEL] Braden, R. and B. Lindell, "A Two-Level Architecture
for Internet Signaling", Work in Progress,
November 2002.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
Deering, "IPv6 Flow Label Specification", RFC 3697,
March 2004.
[NATFW-NSLP] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", Work in Progress, February 2005.
[GIMPS] Schulzrinne, H., "GIMPS: General Internet Messaging
Protocol for Signaling", Work in Progress,
February 2005.
[QOS-NSLP] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", Work in Progress,
February 2005.
[RSVP-SEC] Tschofenig, H., "RSVP Security Properties", Work in
Progress, February 2005.
[SIG-ANAL] Manner, J. and X. Fu, "Analysis of Existing Quality-
of-Service Signaling Protocols", RFC 4094, May 2005.
[RFC1809] Partridge, C., "Using the Flow Label Field in IPv6",
RFC 1809, June 1995.
[RFC2745] Terzis, A., Braden, B., Vincent, S., and L. Zhang,
"RSVP Diagnostic Messages", RFC 2745, January 2000.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., and R. Hess, "Identity Representation
for RSVP", RFC 3182, October 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"Session Authorization Policy Element", RFC 3520,
April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Session Set-up with Media Authorization", RFC 3521,
April 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, May 2004.Authors' Addresses 🏡
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Dirk Kroeselberg
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Dirk.Kroeselberg@siemens.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2005). 🌸
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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't say it has made any independent effort to find such rights. Info about how rights work for RFC documents is in BCP 78 and BCP 79 📖
Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔗
The IETF invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀
📦 where this page comes from
- ietf: rfc4081 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms