RFC 5796
Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages
RFC 5796 💖 Authentication and Confidentiality in PIM-SM Link-Local Messages
okay bestie, this one is the spec for locking down PIM-SM's link-local messages 🔐✨ it's from March 2010 and it's a Standards Track doc from the IETF (Internet Engineering Task Force) 🌸 the authors are W. Atwood (Concordia University/CSE), S. Islam (IRS-EMT), and M. Siami (Concordia University/CIISE) 🫶 it has ISSN 2070-1721, and it updates RFC 4601 🦋 the header doesn't list anything it obsoletes, so nothing gets retired here 💅
Abstract ✨
okay so RFC 4601 says you MUST use IPsec to authenticate the link-local messages in PIM-SM (Protocol Independent Multicast - Sparse Mode) 🔐 this doc is the how-to. it covers authenticating those messages with the IP security (IPsec) Encapsulating Security Payload (ESP) or, optionally, the Authentication Header (AH) 🎀 it also has optional confidentiality using ESP 🙈
manual keying is the mandatory, default group key management solution 🗝️ but manual keying has scalability and security issues, so automated group key management is optional support on top 🌈 the procedures for the automated version are left to other docs 📚 and yes, this document updates RFC 4601 💜
Status of This Memo 🧚
this is an Internet Standards Track document 🌸
it's a product of the 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) 👑 for more on Internet Standards, check Section 2 of RFC 5741 🦋
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5796 💻
Copyright Notice 💅
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved ✨
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date 📜 read them carefully, because they spell out your rights and restrictions 🙈 code components pulled from this doc 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 ....................................................4
1.1. Goals and Non-Goals ........................................4
2. Terminology .....................................................5
3. Transport Mode versus Tunnel Mode ...............................5
4. Authentication ..................................................5
5. Confidentiality .................................................6
6. IPsec Requirements ..............................................6
7. Key Management ..................................................8
7.1. Manual Key Management ......................................8
7.2. Automated Key Management ...................................8
7.3. Communications Patterns ....................................9
7.4. Neighbor Relationships ....................................10
8. Number of Security Associations ................................11
9. Rekeying .......................................................12
9.1. Manual Rekeying Procedure .................................13
9.2. KeyRolloverInterval .......................................14
9.3. Rekeying Interval .........................................14
10. IPsec Protection Barrier and SPD/GSPD .........................14
10.1. Manual Keying ............................................14
10.1.1. SAD Entries .......................................14
10.1.2. SPD Entries .......................................14
10.2. Automatic Keying .........................................15
10.2.1. SAD Entries .......................................15
10.2.2. GSPD Entries ......................................15
10.2.3. PAD Entries .......................................15
11. Security Association Lookup ...................................16
12. Activating the Anti-Replay Mechanism ..........................16
13. Implementing a Security Policy Database per Interface .........17
14. Extended Sequence Number ......................................17
15. Security Considerations .......................................18
16. Acknowledgements ..............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................191. Introduction 🌸
all the PIM-SM [RFC4601] control messages use IP protocol number 103 🔢 some are unicast and the rest are multicast with Time to Live (TTL) = 1 ⏱️ for unicast, the source address is a domain-wide reachable address 🌍 for multicast, the source is a link-local address of the interface sending the message, and the destination is the special multicast address ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) 📡 these are called link-local messages, and Hello, Join/Prune, and Assert messages all live in this category 🦋
a forged link-local message can be sent to ALL_PIM_ROUTERS by an attacker 😭 that messes with how the distribution tree gets built [RFC4601] 🌳 the effects are outlined in Section 6.1 of [RFC4601], and some are super severe while others are pretty minor 💀
PIM-SM version 2 was first specified in RFC 2117 [RFC2117], then revised in RFC 2362 [RFC2362] and RFC 4601 ✨ RFC 4601 obsoletes RFC 2362 and fixes a bunch of deficiencies 🛠️ its "Security Considerations" section is mostly based on the Authentication Header (AH) spec in RFC 4302 [RFC4302] 🎀
securing unicast messages is easy peasy: use a normal unicast IPsec Security Association (SA) between the two communicants 🫶
this doc is all about link-local messages 🔐 it gives guidance on using the newly permitted AH functionality in RFC 4302 and the newly permitted ESP functionality in RFC 4303 [RFC4303], and it lines up the PIM-SM spec with the new AH and ESP specs 💅 in line with RFC 4301, ESP is now mandatory and AH is optional 👑 this doc makes manual key management mandatory to implement, meaning all implementations MUST support it 🗝️ and it sets up the structure for an automated key management protocol that PIM routers may use 🌈
1.1. Goals and Non-Goals 🎯
the primary goal for link-local security is data origin authentication for each link-local message 🔐 the secondary goal is making sure communication only happens between legitimate peers (i.e., adjacent routers) 🧚 and the optional goal is data confidentiality for link-local messages 🙈
the first goal means each router needs a unique identity 🪪 it's possible (but not mandatory) for that identity to be based on the router's unicast identity 💜 (the unicast identity could be based on something individually configured on the router, or be part of a region-wide public key infrastructure) 🌸 this spec assumes that unique identity already exists, but how you establish it is out of scope for this doc 🙅♀️
the second goal implies some kind of "adjacency matrix" that controls setting up Security Associations among adjacent multicast routers 🦋 for manual keying, the router Administrator(s) run this control by setting initialization parameters 🛠️ for automated keying, the control shows up in the Peer Authorization Database (PAD) (see RFC 4301 [RFC4301]) or the Group Security Policy Database (GSPD) (see RFC 5374 [RFC5374]) on each router 🍓 how to control adjacency and build the PAD and GSPD is out of scope here 💅
2. Terminology 📖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🎀 they show the requirement levels for compliant PIM-SM implementations 🫶
3. Transport Mode versus Tunnel Mode 🚇
all implementations conforming to this spec MUST support SA in transport mode to give PIM-SM link-local messages the IPsec security they require 🔐 they MAY also support SA in tunnel mode for that same required IPsec security 🌈 if tunnel mode is used, both destination address preservation and source address preservation MUST be used, as described in Section 3.1 of RFC 5374 [RFC5374] ✨
4. Authentication 🔑
implementations conforming to this spec MUST support authentication for PIM-SM link-local messages 💖 they MUST also support HMAC-SHA1 [RFC2404] 🧁
to authenticate PIM-SM link-local messages, implementations MUST support ESP [RFC4303] and MAY support AH [RFC4302] 💜
if ESP in transport mode is used, it only authenticates PIM-SM protocol packets, and it leaves out the IP header, extension headers, and options 🙈
if AH in transport mode is used, it authenticates PIM-SM protocol packets, selected portions of the IP header, extension headers, and options 🦋
heads up, bestie 🚨 when authentication for PIM-SM link-local messages is turned on:
- PIM-SM link-local packets that are not protected with AH or ESP will be silently discarded by IPsec, although the IPsec implementation may keep a counter of such packets 💀
- PIM-SM link-local packets that fail the authentication checks will be silently discarded by IPsec, although the IPsec implementation may keep a counter of such packets 😭
5. Confidentiality ✨
okay bestie, confidentiality is a SHOULD 🫶 so conforming implementations SHOULD support it for PIM-SM. but if you DO support it, you MUST support AES-CBC [RFC3602] with a 128-bit key 🔐
if confidentiality is provided, ESP MUST be used 💅
authentication is a MUST for a conforming implementation, so an implementation MUST NOT generate NON-NULL Encryption together with NULL Authentication. no cap, that combo is a no-go 🙅♀️
Note: when confidentiality for PIM-SM link-local packets is enabled,
- PIM-SM packets that are not protected with ESP will be silently discarded by IPsec, although the implementation of IPsec may maintain a counter of such packets. 👀
6. IPsec Requirements 🎀
to implement this spec, these IPsec capabilities are required 📋
Transport mode IPsec in transport mode MUST be supported. 🚀
Multiple Security Policy Databases (SPDs) the implementation MUST support multiple SPDs, with an SPD selection function that lets you choose a specific SPD based on interface. so many databases, so much control 🗂️
Selectors the implementation MUST be able to use source address, destination address, protocol, and direction as selectors in the SPD. ✨
Interface ID tagging the implementation MUST be able to tag inbound packets with the ID of the interface (physical or virtual) they arrived on. 🏷️
Manual key support it MUST be possible to use manually configured keys to secure the specified traffic. 🔑
Encryption and authentication algorithms the encryption and authentication algorithm requirements in RFC 4835 [RFC4835] apply when ESP and AH are used to protect PIM-SM. implementations MUST support ESP-NULL, and if they provide confidentiality, they MUST support the ESP transforms providing confidentiality required by [RFC4835]. but in any case, implementations MUST NOT let the user choose a stream cipher or block mode cipher in counter mode for use with manual keys. that's a hard nope 🙅♀️💀
Encapsulation of ESP packets IP encapsulation of ESP packets MUST be supported. for simplicity, UDP encapsulation of ESP packets SHOULD NOT be used. 🌸
if the automatic keying features of this spec are implemented, these extra IPsec capabilities are required too 🧚
Group Security Policy Database (GSPD) the implementation MUST support the GSPD described in RFC 5374 [RFC5374]. 🗝️
Multiple Group Security Policy Databases the implementation MUST support multiple GSPDs, with a GSPD selection function that lets you choose a specific GSPD based on interface. 💜
Selectors the implementation MUST be able to use source address, destination address, protocol and direction as selectors in the GSPD. 🦋
7. Key Management 🔐
all the implementations MUST support manual configuration of the Security Associations (SAs) that will be used to authenticate PIM-SM link-local messages. that doesn't rule out a negotiation protocol like the Group Domain Of Interpretation (GDOI) [RFC3547] or Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] for setting up these SAs, though 🫶
7.1. Manual Key Management 🛠️
to set up the SAs at PIM-SM routers, manual key configuration is feasible when the number of peers (directly connected routers) is small. the Network Administrator configures a router manually. at that point, the authentication method and the choice of keys SHOULD be configured. the parameters for the Security Association Database (SAD) get entered, and the Network Administrator also configures the Security Policy Database of a router so the right SA gets used while sending a link-local message. it's giving careful admin energy 📝
7.2. Automated Key Management 🤖
all the link-local messages of the PIM-SM protocol go to the destination address ALL_PIM_ROUTERS, which is a multicast address. by using the sender address together with the destination address for the SA lookup, link-local communication turns into a Source-Specific Multicast (SSM) or "one-to-many" communication. iconic 🌈
the procedures for automated key management are not specified in this document. 🙈
one option is GDOI [RFC3547]. it lets a group of users or devices exchange encrypted data using IPsec data encryption. GDOI was built for multicast apps, where the number of end users or devices may be large and they can dynamically join and leave a multicast group. but a PIM router isn't expected to join or leave very often, and there are far fewer routers than possible users of a multicast app. plus, most PIM routers live inside the same administrative domain and are considered trusted parties. so a subset of GDOI functionalities may be enough 💅
another option is GSAKMP [RFC4535] ✨
7.3. Communications Patterns 🗺️
before we talk about the set of Security Associations needed to manage a multicast region under the control of a single administration, we have to understand the communication patterns among the routers in this region. from a speaking router's perspective, its info gets sent (multicast) to all of its neighbors. from a listening router's perspective, the info coming from each of its neighbors is distinct from the info coming from every other router it's directly connected to. so one administrative region has lots of (small) distinct groups, all using the same multicast destination address (e.g., ALL_PIM_ROUTERS, see Section 11), and each one is centered on its speaking router. main character energy for every router 👑
consider the example configuration in Figure 1:
R2 R3 R4 R5 R6
| | | | |
| | | | |
--------- ---------------
| |
| |
\ /
R1
/ \
| |
| |
--------- --------------------
| | | | |
| | | | |
R7 R8 R9 R10 R11
| | | | |
|
|
-------------
| | |
| | |
R12 R13 R14
Figure 1: Set of router interconnectionsin this setup, R1 has four interfaces and is the speaking router for a group whose listening routers are R2 through R11. R9 is the speaking router for a group whose listening routers are R1, R8, and R10-R14. 🦋
from R1 as a speaking router: if a Security Association SA1 is assigned to protect R1's outgoing packets, then the key for that association has to be distributed to each of R2 through R11. similarly, from R9 as a speaking router: if an SA is assigned to protect R9's outgoing packets, its key has to be distributed to each of R1, R8, and R10 through R14. so much key distribution, bestie 😭
from R1 as a listening router: all packets arriving from R2 through R11 need to be told apart, so the right SA gets picked from the SAD. (packets from each peer router, R2 through R11, come from a different speaker with its own sequence-number space, even though they all use the same destination address.) for a multicast SA, RFC 4301 lets you use the source address in the selection function. if the source addresses used by R2 through R11 are globally unique, then the peers' source addresses are enough to tell them apart. but if the sending routers use link-local addresses, those are only unique per interface, so you need the Interface ID tag as an extra selector. either the selection function takes the Interface ID tag as one of its inputs, or you keep separate SADs for each interface. 🔍
if we can assume connectivity to the key server (which is true in the PIM-SM case), then the Group Controller/Key Server (GC/KS) used to manage the keys can be located centrally (and duplicated for reliability). if that assumption can't be made (like with adjacencies for a unicast router), then some form of "local" key server must be available for each group. since listening routers are never more than one hop away from the speaking router, the speaking router is the obvious place for that "local" key server. so this might be useful even in the PIM-SM case ✨. it also has the extra perk that there's no need to duplicate the local key server for reliability, since if the key server goes down, the speaking router is very likely down too 💀
7.4. Neighbor Relationships 🫧
each distinct group consists of one speaker and the set of directly connected listeners. if the decision is made to maintain one Security Association per speaker (see Section 8), then the key server will need to know the adjacencies of each speaker. procedures for managing and distributing these adjacencies are out of scope for this document. 🌸
8. Number of Security Associations ✨
Okay so the number of Security Associations a PIM router has to maintain depends on how secure you need things to be and which key management you're using 🔐. This SHOULD be decided by the Network Administrator. Figures 2 and 3 show two different ways to set it up. Picture three PIM routers, A, B, and C, where B and C are both directly connected to A, but B and C have no direct link to each other 🦋.
|
+++++ |
+ B + SAb ------------>|
+ + SAa <------------|
+++++ |
|
+++++ SAb <------------|
+ + ---->|
+ + /
+ A + SAa -------
+ + \
+ + ---->|
+++++ SAc <------------|
|
+++++ |
+ C + SAc ------------>|
+ + SAa <------------|
+++++ |
|
Directly connected network
Figure 2: Activate unique Security Association for each peerThe first method, shown in Figure 2, SHOULD be supported by every implementation 💖. Here, each node uses its own unique SA for outbound traffic. A, B, and C use SAa, SAb, and SAc, respectively, for sending any traffic. Each node includes the source address when searching the SAD for a match. Router A uses SAb and SAc for packets received from B and C, respectively. The number of SAs a PIM router has to activate and maintain equals the number of directly connected routers, plus one for sending its own traffic. Also, adding a PIM router to the network means adding another SA on every directly connected PIM router. This solution is scalable and practically feasible with an automated key management protocol 🚀. It MAY be used with manual key management too, if the number of directly connected routers is small.
|
+++++ |
+ B + SAo ------------>|
+ + SAi <------------|
+++++ |
|
+++++ SAi <------------|
+ + ---->|
+ + /
+ A + SAo -------
+ + \
+ + ---->|
+++++ SAi <------------|
|
+++++ |
+ C + SAo ------------>|
+ + SAi <------------|
+++++ |
|
Directly connected network
Figure 3: Activate two Security AssociationsThe second method, shown in Figure 3, MUST be supported by every implementation 🌸. This one is simple: every node uses two SAs, one for sending (SAo) and one for receiving (SAi). So the number of SAs is always two, and adding a PIM router doesn't change that. Even though SAo and SAi are two different SAs, their SA parameters (keys, Security Parameter Index (SPI), etc.) are identical. In other words, the same information is shared among all the routers in an administrative region 🫶. This document RECOMMENDS this second method for manual key configuration. It MAY also be used with automated key configuration.
9. Rekeying 🔑
An analysis of the considerations for key management is provided in RFC 4107 [RFC4107].
In PIM-SM deployments, secure sessions are expected to be relatively long-lived 🕰️. Keys are not expected to get significantly exposed through normal operations. Manual keying is judged acceptable because the rate of change needed is relatively low.
To keep a link secure, the authentication and encryption key values SHOULD be changed periodically, so the risk of undetected key disclosure stays low 🔒. Keys SHOULD also be changed whenever there is a change of trusted personnel.
Manual keying lets you change keys in a coordinated way, but it has several drawbacks in PIM-SM systems 😬. Some of these are listed in Section 15 ("Security Considerations") of this document.
According to an analysis in line with RFC 4107 [RFC4107], PIM-SM would benefit from automated key management and rollover, because that would eliminate all the disadvantages of manual keys listed in Section 15 ✨. However, suitable techniques for automated key management don't exist yet. The IETF is working on suitable solutions. In the meantime, implementations MUST support manual rekeying as described below. Implementers and deployers need to be aware that they will have to upgrade to support automated key management as soon as suitable techniques become available 👀.
9.1. Manual Rekeying Procedure
In line with the requirements of RFC 4107 [RFC4107], the following three-step procedure is one possible way to rekey the routers on a link. It does this without dropping PIM-SM protocol packets or disrupting the adjacency, and it always keeps it clear which key is in use 🧩.
- For every router on the link, create an additional inbound SA for the interface being rekeyed, using a new SPI and the new key.
- For every router on the link, replace the original outbound SA with one that uses the new SPI and key values. The SA replacement operation MUST be atomic with respect to sending PIM-SM packets on the link, so that no PIM-SM packets are sent without authentication/encryption 🚫.
- For every router on the link, remove the original inbound SA.
Note that all routers on the link MUST complete step 1 before any begin step 2. Likewise, all the routers on the link MUST complete step 2 before any begin step 3 ⏳.
One way to control the move from one step to the next is for each router to have a configurable time constant, KeyRolloverInterval. After a router begins step 1 on a given link, it waits for this interval and then moves to step 2. Likewise, after moving to step 2, it waits for this interval and then moves to step 3.
For a smooth key transition, all routers on a link MUST use the same value for KeyRolloverInterval and MUST start the key rollover process within this time period 💅.
By the end of this time period, all the routers on the link will have a single inbound and outbound SA for PIM-SM, using the new SPI and key values 🎉.
9.2. KeyRolloverInterval
The configured value of KeyRolloverInterval needs to be long enough for the Administrator to change keys on all the PIM-SM routers 🕒. This value can vary a lot depending on the implementation and the deployment, so it's left up to the Administrator to choose an appropriate value.
9.3. Rekeying Interval
To keep key exposure low, the encryption and authentication keys SHOULD be changed at least every 90 days 📅.
10. IPsec Protection Barrier and SPD/GSPD 🛡️
10.1. Manual Keying
10.1.1. SAD Entries
The Administrator must configure the necessary Security Associations 📝. Each SA entry has the source address of an authorized peer and a Destination Address of ALL_PIM_ROUTERS. Unique SPI values for the manually configured SAs MUST be assigned by the Administrator, so the SPI doesn't conflict with existing SPI values in the SAD 🙅♀️.
10.1.2. SPD Entries
The Administrator must configure the necessary SPD entries. The SPD entry must ensure that any outbound IP traffic packet crossing the IPsec boundary, with PIM as its next layer protocol and sent to the Destination Address of ALL_PIM_ROUTERS, is protected by ESP or AH 🔐. Note that this covers all the link-local messages (Hello, Join/Prune, Bootstrap, Assert) 💜.
10.2. Automatic Keying
With automatic keying, SA creation happens dynamically using a group key management protocol 🤖. The GSPD and PAD tables are configured by the Administrator. The PAD table is the link between the IPsec subsystem and the group key management protocol.
For automatic keying, the implementation MUST support the multicast extensions described in [RFC5374] 🌈.
10.2.1. SAD Entries
All PIM routers take part in an authentication scheme that identifies permitted neighbors and achieves peer authentication during SA negotiation. This leads to child SAs being established and saved in the SAD ✨.
10.2.2. GSPD Entries
The Administrator must configure the necessary GSPD entries for "sender only" directionality. This rule MUST trigger the group key management protocol for a registration exchange. That exchange sets up the outbound SAD entry that encrypts the multicast PIM control message 🎀. Since this rule is "sender only", no inbound SA is created in the reverse direction.
On top of that, the registration exchange triggers the installation of GSPD entries for each legitimate peer router, with direction "receiver only" 🧚. Procedures for the registration exchange are out of scope for this document.
A router SHOULD NOT dynamically detect new neighbors as a result of receiving an unauthenticated PIM-SM link-local message, or an IPsec packet that fails an SAD lookup 🙈. An automated key management protocol SHOULD provide a way to notify a router of new, legitimate neighbors.
10.2.3. PAD Entries
The PAD will be configured with information that lets it identify legitimate group members and senders, so it can control the adjacency 🧃. Procedures for doing this are out of scope for this document.
11. Security Association Lookup ✨
okay so for a unicast SA, the inbound lookup uses three things: the SPI, the destination address, and the security protocol type (AH or ESP) 🦋 The SPI alone is enough to pin down an SA, but an implementation MAY, if it wants to, pair the SPI with the IPsec protocol type (AH or ESP) during the lookup. 💅
Now for multicast, [RFC4301] says that, along with the SPI, you can also use the destination address, or the destination address plus the sender address. This works for both ESP and AH, and the security protocol field is not used for a multicast SA lookup. Lowkey a lot of rules, but they're all very specific! 🌸
Here's the main drama. From a receiving router's perspective, every peer router is its own independent sender, and the destination address is the same for all of them. So the receiving router MUST use the SPI plus the destination address plus the sender address when it does the SA lookup. Honestly, link-local communication is basically SSM (Source-Specific Multicast) that just happens to use an Any-Source Multicast (ASM) address, which every router shares. It's giving "same address, different people" 👑
Since it's always possible to tell an IPsec connection apart from a non-IPsec one, it is recommended that the address ALL_PIM_ROUTERS be used, so we stay consistent with what's already done in practice. ✨
And one more thing: a sender address on an incoming packet might only be locally unique, because link-local addresses are involved. That means the receiver NEEDS the interface ID tag to figure out which SA belongs to which sender. So this document mandates that the interface ID tag, the SPI, and the sender address MUST be used in the SA lookup process. Non-negotiable, bestie 🫶
12. Activating the Anti-Replay Mechanism
Okay, so link-level messages on a link are technically a group with multiple senders and multiple receivers 🧚 But using the interface ID tag and the sender address for the SA lookup basically splits everything into a separate SA for each sender/destination pair. That's true even when only two SAs (with identical SA parameters) are used across the whole administrative region. So the AH RFC's statement (Section 2.5 of [RFC4302]) that "for a multi-sender SA, the anti-replay features are not available" stops mattering for PIM-SM link-local message exchange. Iconic! 💖
To turn on anti-replay in a unicast communication, the receiver uses the sliding window protocol and keeps a sequence number for it. That sequence number starts at zero. 🌈
Every time the sender sends a new packet, it bumps this number up by one. In a multi-sender multicast group, though, one single sequence number for the entire group just wouldn't be enough 🙈
PIM link-local messages are a whole different vibe. They're sent to local links with TTL = 1, so a link-local message never gets forwarded from one router to another. Using the sender address and the interface ID tag for the SA lookup turns a multiple-sender group into multiple single-sender associations. Main character energy for the anti-replay logic, fr fr ✨
This specification RECOMMENDS turning on the anti-replay mechanism only when the SAs are assigned through an automated key management procedure. If manual key management is being used, anti-replay SHOULD NOT be activated. ⭐
Now, if an existing router has to restart, then in accordance with [RFC4303], the sequence-number counter at the sender MUST be correctly maintained across local reboots and so on, until the key is replaced. No resetting it mid-key, bestie 😭
13. Implementing a Security Policy Database per Interface
[RFC4601] suggests that it may be a good idea to implement a separate Security Policy Database (SPD) for each router interface 🍓 The link-local addresses used in certain situations mean that telling apart ambiguous speaker addresses requires the interface ID tag in the SA lookup. One way to handle that is with multiple SPDs. The other option is making the interface ID tag a specific part of the selector algorithm. This fits [RFC4301], which explicitly drops the requirement for separate SPDs that was in [RFC2401] [RFC2401]. Honestly, it's giving growth 🌸
14. Extended Sequence Number
So [RFC4302] has this 64-bit Extended Sequence Number (ESN) that acts as the counter for the sliding window in the anti-replay protocol 🔥 Both the sender and the receiver keep a 64-bit counter, but only the lower-order 32 bits actually get sent over the wire. That means the AH header format doesn't change at all, which is so clean 🧚
With ESN in use, a sender router can send 2^64 -1 packets before needing any intervention. That number is absolutely massive. From a PIM router's point of view, it'll never reach that number in its entire lifetime 💀 So it's reasonable to allow manual configuration for a small number of PIM routers, since the sequence number is never going to roll over.
Because of that, when manual configuration is used, ESN SHOULD be deployed as the sequence number for the sliding window protocol. Also, if ESN is used with a manually keyed SA, it MUST be saved over a reboot, along with an indication of which sequence numbers have already been used. Save your progress, babe 💾
15. Security Considerations
Real talk: this whole document looks at the security issues of PIM link-local messages and proposes a mechanism to protect them. It's serious business, so let's go through the warnings properly 😤
Limitations of manual keys:
The following are some of the known limitations of using manual keys 💜
- If replay protection cannot be provided, the PIM routers will not be secured against all the attacks that can be carried out by replaying PIM packets. 🚨
- Manual keys are usually long lived, and changing them often is a tedious task. This gives an attacker enough time to discover the keys. 😰
- Since the Administrator is manually configuring the keys, there's a chance the configured keys are weak. There are known weak keys for DES/3DES at least. 🙈
Impersonation attacks:
Using the same key on all the PIM routers connected to a link leaves every one of them open to impersonation attacks if any single PIM router is compromised, malfunctioning, or misconfigured. One bad router, and suddenly everyone is exposed. Not the vibe 💀
Detailed analysis of the various vulnerabilities of routing protocols is provided in [RFC4593]. For more on PIM-SM and multicast security, check out [RFC5294], [RFC4609], and the Security Considerations section of [RFC4601]. Go read them, bestie 📚
16. Acknowledgements
The structure and text of this document draw heavily from [RFC4552]. The authors thank M. Gupta and N. Melam for permission to do this. Thank you, legends 🫶
The quality of this document was substantially improved after SECDIR pre-review by Brian Weis, and after AD review by Adrian Farrel. Shoutout to them for the glow-up ✨
17. References
17.1. Normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, November 2008.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.17.2. Informative References
[RFC2117] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification", RFC 2117, June 1997.
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., and V. Jacobson, "Protocol Independent
Multicast-Sparse Mode (PIM-SM): Protocol Specification",
RFC 2362, June 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
[RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol
Independent Multicast (PIM)", RFC 5294, August 2008.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609,
October 2006.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.Authors' Addresses
J. William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd. West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
EMail: bill@cse.concordia.ca
URI: http://users.encs.concordia.ca/~bill
Salekul Islam
INRS Energie, Materiaux et Telecommunications
800 de La Gauchetiere, Suite 800
Montreal, QC H5A 1K6
Canada
EMail: Salekul.Islam@emt.inrs.ca
URI: http://users.encs.concordia.ca/~salek_is
Maziar Siami
Concordia University/CIISE
1455 de Maisonneuve Blvd. West
Montreal, QC H3G 1M8
Canada
EMail: mzrsm@yahoo.caThat's the whole thing, bestie! 🌈💖 You made it through RFC 5796 ✨
📦 where this page comes from
- ietf: rfc5796 2010-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms