RFC 5458
Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol
RFC 5458: Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol 🦋
Okay bestie, this is RFC 5458, titled Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol ✨ It's an Informational document from the Network Working Group, dated March 2009. The authors are H. Cruickshank (University of Surrey), P. Pillai (University of Bradford), M. Noisternig (University of Salzburg), and S. Iyengar (Logica) 👑 The title block doesn't list anything this RFC obsoletes or updates, so it's standing on its own 💅
Status of This Memo 📜
This memo gives information to the Internet community. It does not specify an Internet standard of any kind 🫶 Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice ©️
Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📖
Abstract 🌸
Okay, so the MPEG-2 standard from ISO 13818-1 supports a whole bunch of transmission methods for different services 📺 This document is a threat analysis, and it works out the security requirements for using the Transport Stream (TS) to carry an Internet network layer with Unidirectional Lightweight Encapsulation (ULE), which is defined in RFC 4326 🔥 It also explains why a ULE Stream needs link-layer security. A ULE Stream can carry IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers, using unicast and/or multicast transmission 🧚
The analysis also covers how this applies to the Generic Stream Encapsulation (GSE), which is defined by the Digital Video Broadcasting (DVB) Project 💅
Table of Contents 🗂️
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Threat Analysis .................................................7
3.1. System Components ..........................................7
3.2. Threats ....................................................9
3.3. Threat Cases ..............................................10
4. Security Requirements for IP over MPEG-2 TS ....................11
5. Design Recommendations for ULE Security Extension Header .......14
6. Compatibility with Generic Stream Encapsulation ................15
7. Summary ........................................................15
8. Security Considerations ........................................15
9. Acknowledgments ................................................16
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................17
Appendix A. ULE Security Framework ................................19
A.1. Building Block ............................................19
A.2. Interface Definition ......................................22
Appendix B. Motivation for ULE Link-Layer Security ................23
B.1. Security at the IP Layer (Using IPsec) ....................23
B.2. Link Security below the Encapsulation Layer ...............24
B.3. Link Security as a Part of the Encapsulation Layer ........251. Introduction 🎀
The MPEG-2 Transport Stream (TS) is hugely popular, not just for digital TV but also as a subnetwork technology for building IP networks 🌟 RFC 4326 [RFC4326] describes the Unidirectional Lightweight Encapsulation (ULE) mechanism for carrying IPv4 and IPv6 Datagrams, plus other network protocol packets, directly over the ISO MPEG-2 Transport Stream as TS Private Data 💖 ULE specifies a base encapsulation format and supports an Extension Header format, which lets it carry extra header information to help with network and Receiver processing ✨ This encapsulation meets the design and architectural requirement for a lightweight encapsulation that is defined in RFC 4259 [RFC4259] 🦋
Section 3.1 of RFC 4259 lays out several topological scenarios for MPEG-2 Transmission Networks 🗺️ Here's a quick summary of them:
- A. Broadcast TV and Radio Delivery. This is not within the scope of this document 📺
- B. Broadcast Networks used as an ISP. This is like scenario A, but it also includes IP services to access the public Internet 🌐
- C. Unidirectional Star IP Scenario. This provides a data network that delivers a common bit stream to typically medium-sized groups of Receivers 🌟
- D. Datacast Overlay. This uses MPEG-2 physical and link layers to provide extra connectivity, such as unidirectional multicast, to supplement an existing IP-based Internet service 🍓
- E. Point-to-Point Links. This connectivity may be provided using a pair of transmit and receive interfaces 🔗
- F. Two-Way IP Networks. 💜
RFC 4259 says that ULE must be robust to errors and security threats 🚨 Security also has to consider both unidirectional (A, B, C, and D) and bidirectional (E and F) links for the scenarios above 🔥
There's an initial analysis of security requirements for MPEG-2 transmission networks in the "Security Considerations" section of RFC 4259 🧐 For example, when these networks aren't using a wireline network, the normal security issues around using wireless links to carry Internet traffic should be considered [RFC3819] 📡
The security considerations of RFC 4259 recommend that any new encapsulation defined by the IETF should allow Transport Stream encryption, and it should also support optional link-layer authentication of the Subnetwork Data Unit (SNDU) payload 🔐 In ULE [RFC4326], it's suggested that this may be provided in a flexible way using Extension Headers 🧩 That does require defining a mandatory Extension Header, but it has the advantage of decoupling the specification of the security functions from the encapsulation functions 💅
This document builds on the analysis above and works out the security requirements for ULE in MPEG-2 transmission networks in detail 🎀
A security framework for deploying secure ULE networks, which describes the different building blocks and interface definitions, is in Appendix A 🌈
2. Requirements Notation 📝
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 RFC 2119 [RFC2119] 🫶
Other terms used in this document are defined below 👇
- ATSC: Advanced Television Systems Committee. A framework and a set of associated standards for transmitting video, audio, and data using the ISO MPEG-2 Standard 📺
- DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for transmitting video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2] 🇪🇺
- Encapsulator: A network device that receives Protocol Data Units (PDUs) and formats them into Payload Units (known here as SNDUs) for output as a stream of TS Packets 📦
- GCKS: Group Controller and Key Server. A server that authenticates members of a secure group and provides them with policy and keying material 🔑
- LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer protocol defined by the IEEE 802 standard, which follows the Ethernet Medium Access Control Header 🧱
- MAC: Message Authentication Code 🔏
- MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that encapsulates PDUs, forming a Digital Storage Media Command and Control (DSM-CC) Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel 🎁
- MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardised by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]) 🎬
- NPA: Network Point of Attachment. In this document, it refers to a 6-byte destination address (resembling an IEEE Medium Access Control address) within the MPEG-2 transmission network, used to identify individual Receivers or groups of Receivers 📍
- PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets 📨
- PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of TS Packets. It's used to identify the TS Logical Channel that a TS Packet belongs to [ISO-MPEG2] 🆔 The TS Packets forming the parts of a Table Section, Packetised Elementary Stream (PES), or other Payload Unit must all carry the same PID value 🧷 The all-zeros PID
0x0000, as well as other PID values, are reserved for specific PSI/SI Tables [ISO-MPEG2] 🚫 The all-ones PID value0x1FFFindicates a Null TS Packet, which is introduced to maintain a constant bit rate of a TS Multiplex 🫧 There is no required relationship between the PID values used for TS Logical Channels transmitted over different TS Multiplexes 🌸 - Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or to the bridging module when operating at the link layer) 📡
- SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2] 🗃️
- SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit 🎀
- TS: Transport Stream [ISO-MPEG2]. A method of transmission at the MPEG-2 layer that uses TS Packets. It represents Layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex 🧠
- TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. This may be a common physical link (that is, a transmission at a specified symbol rate, Forward Error Correction (FEC) setting, and transmission frequency), or an encapsulation provided by another protocol layer (for example, Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259]. For example, this could redistribute the same multicast content to two terrestrial TV transmission cells 🗼
- TS Packet: A fixed-length 188-byte unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4-byte header, plus optional overhead including an Adaptation Field, encryption details, and time stamp information to synchronise a set of related TS Logical Channels ⏱️
- ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by the definition of a stream_type in SI/PSI [ISO-MPEG2] 🌊
3. Threat Analysis 🔍
3.1. System Components 🧚
Okay so picture this: a whole bunch of gear working together to get IP over MPEG-2 🎀 Figure 1 shows it all. It's adapted from [RFC4259], and Section 3.3 of that doc is where the picture comes from ✨
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ ULE | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexer | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexer | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS MuxFigure 1: An example configuration for a unidirectional service for IP transport over MPEG-2 (adapted from [RFC4259])
Okay so the main cast in this network is:
- ULE Encapsulation Gateways (the ULE Encapsulator) 💌
- SI-Table signalling generator (input to the multiplexer) 📋
- Receivers (the endpoints for ULE Streams) 📡
- TS multiplexers (including re-multiplexers) 🔀
- Modulators 📶
The TS Packets get carried to the Receiver over a physical layer that usually has Forward Error Correction (FEC) coding 🛡️ That coding interleaves the bytes of several consecutive, but unrelated, TS Packets 🌀 Because of the FEC-coding and synchronisation processing, injecting a single TS Packet is very difficult 🙈 Swapping out a whole sequence of packets is also difficult, but it's possible (see Section 3.2) 💅
A Receiver in an MPEG-2 TS transmission network needs to identify a TS Logical Channel (or MPEG-2 Elementary Stream) so it can reassemble the fragments of PDUs sent by an L2 source [RFC4259] ✨ In an MPEG-2 TS, that association is made through the Packet Identifier, PID [ISO-MPEG2] 🔑 At the sender, each source gets a locally unique set of PID values for each stream it originates. Still, there is no required relationship between the PID value used at the sender and the one received at the Receiver 🫶 Network devices may re-number the PID values tied to one or more TS Logical Channels (e.g., ULE Streams). They do this to prevent clashes at a multiplexer between input streams that carry the same PID on different input multiplexes. That also means updating entries in the PMT [ISO-MPEG2] and any other SI tables that reference the PID value 🔄 A device may also modify and/or insert new SI data into the control plane (also sent as TS Packets identified by their PID value). But here's the tea: there is only one valid source of data for each MPEG-2 Elementary Stream, and it's bound to a PID value 🍵 (This observation could simplify the requirement for authentication of the source of a ULE Stream 🧠)
In an MPEG-2 network, a set of signalling messages [RFC4947] may need to be broadcast (e.g., by an Encapsulation Gateway or another device) to form the L2 control plane 📣 Examples of signalling messages include the Program Association Table (PAT), Program Map Table (PMT), and Network Information Table (NIT) 📚 In existing MPEG-2 transmission networks, these messages are broadcast in the clear (no encryption or integrity checks) 😬 The integrity and authenticity of these messages matter a lot for the ULE network to work correctly. That means supporting its security objectives for availability, on top of confidentiality and integrity 👑 One method recently proposed [RFC5163] encapsulates these messages using ULE 🎁 In those cases, all the security requirements of this document apply to securing these signalling messages 🔐
ULE Stream security only concerns the security between the ULE Encapsulation Gateway (ULE Encapsulator) and the Receiver 🚧 In lots of deployment scenarios, the user of a ULE Stream has to secure communications beyond the link, since other network links get used alongside the ULE link 🌐 So if authentication of the endpoints (the IP Sources) is required, or users worry about losing confidentiality, integrity, or authenticity of their communication data, they'll need end-to-end network security mechanisms, e.g., IPsec or Transport Layer Security (TLS) 🦋 Governmental users may be forced by regulations to use specific approved implementations of those mechanisms 🏛️ So in those cases, the confidentiality and integrity of the user data get handled by the end-to-end security mechanism. The ULE security measures then focus on traffic flow confidentiality, either for user data that's already encrypted or for users who choose not to use end-to-end security mechanisms 🫧
ULE links may also be used for communications where the two IP endpoints aren't under central control (e.g., when browsing a public web site) 🌍 In those cases, it may be impossible to enforce any end-to-end security mechanisms 😭 Still, a common goal is that users can make the same security assumptions as they would for wired links [RFC3819] ✨ ULE security could make that happen by protecting the ULE Stream, which is the part that's vulnerable to passive attacks 🛡️
On the flip side, a ULE Stream can link networks such as branch offices to a central office 🏢 In that setup, ULE link-layer security could be the sole provider of confidentiality and integrity 💜 Users who need high assurance of security (e.g., government use) will need to use approved cryptographic equipment (e.g., at the network layer) 🔒 An implementation of ULE Link Security equipment could also be certified for use by specific user communities 🎀
3.2. Threats 🔥
The simplest type of network threat is a passive threat 👀 It includes eavesdropping on or monitoring of transmissions, with the goal of getting information that's being transmitted. On broadcast networks (especially ones using widely available, low-cost physical layer interfaces, like DVB), passive threats are the major threats 📺 One example is an intruder monitoring the MPEG-2 transmission broadcast and then extracting the data carried within the link. Another example is an intruder trying to figure out who the communicating parties are and how much traffic they send, by sniffing (L2) addresses 🕵️♀️ This is a well-known issue in the security field. It's a bigger problem on broadcast networks like MPEG-2 transmission networks, though, because Receiver hardware is easy to get and the networks span a wide geographical area 🌏
Active threats (or attacks) are generally harder to pull off than passive threats 💪 They usually need more sophisticated resources, and they may require access to the transmitter. In the context of MPEG-2 transmission networks, examples of active attacks are:
- Masquerading: An entity pretends to be a different entity. This includes masquerading as other users and subnetwork control plane messages 🎭
- Modification of messages in an unauthorised manner. ✏️
- Replay attacks: When an intruder sends some old (authentic) messages to the Receiver. On a broadcast link, access to previous broadcast data is easy 🔁
- Denial-of-Service (DoS) attacks: When an entity fails to perform its proper function, or acts in a way that prevents other entities from performing their proper functions 💀
The active threats mentioned above are major security concerns for the Internet community [BELLOVIN]. Masquerading and modification of IP packets are comparatively easy in an Internet environment, whereas such attacks are much harder for MPEG-2 broadcast links 😤 This could, for instance, motivate the mandatory use of sequence numbers in IPsec, but not for synchronous links 🔢 This is further reflected in the security requirements for Case 2 and 3 in Section 4 below 📝
As explained in Section 3.1, the PID associated with an Elementary Stream can be modified (e.g., in some systems by reception of an updated SI table, or in other systems until the next announcement/discovery data is received) 🔄 An attacker who can modify the content of the received multiplex (e.g., by replaying data and/or control information) could inject data locally into the received stream with an arbitrary PID value 🚨 Not me imagining the chaos 🙈
3.3. Threat Cases 🕵️♀️
okay so bestie, remember how Section 1 mapped out the MPEG-2 Transmission Network scenarios? 🗺️ Based on that, the security threats boil down to three cases:
- Case 1: Monitoring (passive threat). 👀 The intruder just watches the ULE broadcasts to learn what's in the ULE data, and/or tracks who's talking to whom by watching the destination NPA address. 💅 For this one, we have to protect the ULE payload data and the identity of ULE Receivers, no excuses.
- Case 2: Locally conducting active attacks on the MPEG-TS multiplex. 😈 This intruder is sophisticated enough to override the original transmission from the ULE Encapsulation Gateway and swap in a modified MPEG-TS transmission for a single ULE Receiver or a small group of Receivers (think one company site). The MPEG-2 transmission network operator might not even notice. 🫣 So we need to protect ULE data integrity and authenticity, and stop replays of old messages.
- Case 3: Globally conducting active attacks on the MPEG-TS multiplex. 🦹 This is a sophisticated intruder who can override the whole MPEG-2 transmission multiplex. The requirements are similar to Case 2. The good news is the MPEG-2 transmission network operator can usually spot these attacks and fix things by restoring the original transmission. 🛠️
For both Cases 2 and 3, there are two sub-cases:
- Insider attacks, i.e., active attacks from adversaries inside the network who know the secret material. 🥷
- Outsider attacks, i.e., active attacks from adversaries who don't know the secret material. 🧍♀️
Priority-wise, Case 1 is the major threat in MPEG-2 transmission systems. 🚨 Case 2 is a lesser threat, relevant to specific network configurations, especially when insider attacks are possible. Case 3 is less likely to show up in an operational network, and the MPEG-2 transmission operator is expected to notice it. It will require restoring the original transmission. The assumption here is that physical access to network components (multiplexers, etc.) and/or connecting physical media is secure. 🔐 So, Case 3 is not considered any further in this document. 🙅♀️
4. Security Requirements for IP over MPEG-2 TS 📋
okay, now that we've looked at the threats in Section 3, we can figure out the security requirements. 🧠 Here's the list:
Req 1. Data confidentiality MUST be provided by a link that supports ULE Stream Security, so it prevents passive attacks and reduces the risk of active threats. 🔒
Req 2. Protection of the L2 NPA address is OPTIONAL. ✨ In broadcast networks, this protection can stop an intruder from tracking the identity of ULE Receivers and how much traffic they send and receive. 📡
Req 3. Integrity protection and source authentication of ULE Stream data are OPTIONAL. 🛡️ They can be used to prevent the active attacks described in Section 3.2.
Req 4. Protection against replay attacks is OPTIONAL. 🔁 It's used to counter the active attacks described in Section 3.2.
Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. 🤝 This can happen during the initial key exchange and authentication phase, before the ULE Receiver can join a secure session with the ULE Encapsulator (ULE source). It could be unidirectional or bidirectional, depending on the underlying key management protocol. 🔑
Other general requirements for all threat cases for link-layer security are:
- GReq (a) ULE key management functions MUST be decoupled from ULE security services such as encryption and source authentication. 🧩 This lets both systems be developed independently, which is so smart. 🧠
- GReq (b) Support SHOULD be provided for automated as well as manual insertion of keys and policy into the relevant databases. 🗂️
- GReq (c) Algorithm agility MUST be supported. It should be possible to update the crypto algorithms and hashes when they become obsolete, without affecting the overall security of the system. 🔄 Future-proofing is everything. ✨
- GReq (d) The security extension header MUST be compatible with other ULE extension headers. 🎀 The method must let other extension headers (either mandatory or optional) be used in combination with a security extension. It is RECOMMENDED that these are placed after the security extension header. 💖 This gives full protection for all headers, and it avoids situations where the SNDU has to be discarded while processing the security extension header even though the preceding headers were already evaluated. 🙈 There's one exception: the Timestamp extension SHOULD precede the security extension header [RFC5163]. 🕰️ In that case, the timestamp is unaffected by security services such as data confidentiality, and it can be decoded without any key material. 🗝️
Looking at the threat cases in Section 3.3, here's how the security requirements shake out for each case:
- Case 1: Data confidentiality (Req 1) MUST be provided to prevent monitoring of ULE data, such as user information and IP addresses. 🫶 Protection of NPA addresses (Req 2) MAY be provided to prevent tracking of ULE Receivers and their communications.
- Case 2: On top of the Case 1 requirements, new measures MAY be implemented, such as authentication schemes using Message Authentication Codes, digital signatures, or Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082], to provide integrity protection and source authentication (Reqs 3 and 5). 💅 Sequence numbers (Req 4) MAY also be used to protect against replay attacks. 🔁 For outsider attacks, group authentication using Message Authentication Codes can provide the required level of security (Reqs 3 and 5). ✅ This significantly reduces the ability of intruders to successfully inject their own data into the MPEG-TS stream. 🙅♀️ However, Scenario 2 threats only apply in specific service cases, so authentication and protection against replay attacks are OPTIONAL. ⚖️ These measures add transmission and processing overhead, though. 📉 Intrusion detection systems may also be needed by the MPEG-2 network operator. 🚨 Ideally, these are paired with perimeter security policy to monitor common DoS attacks. 🏰
- Case 3: As stated in Section 3.3, the requirements here are similar to Case 2. But since the MPEG-2 transmission network operator can usually identify these attacks, the constraints on intrusion detection are less strict than in Case 2. 😌
Table 1 below shows the threats that apply to ULE networks, and the security mechanisms that help mitigate them. 📊
Security Mechanism
-----------------------------------------------
|Data |Data |Source |Data |Intru |Iden |
|Privacy |fresh |Authent|Integ |sion |tity |
| |ness |ication|rity |Dete |Prote |
| | | | |ction |ction |
Threat | | | | | | |
---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------|
| DoS Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------|
| Modification | - | - | X | X | X | - |
| of Messages | | | | | | |
---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats
in ULE Networks5. Design Recommendations for ULE Security Extension Header 🎨
Table 1 can help you pick the fields for a ULE Security Extension Header framework. 🧁
Security services can be grouped into profiles based on their security requirements. ✨ For example, there could be a base profile (with payload encryption and identity protection), and a second profile that extends it to also provide source authentication and protection against replay attacks. 🌈 Even though using specific security techniques is optional, it is RECOMMENDED that receiver devices implement all the techniques in Reqs 2-5 of Section 4, so every profile stays interoperable. 🤝
A modular design of ULE security can use and benefit from existing key management protocols, like the Group Secure Association Key Management Protocol (GSAKMP) [RFC4535] and the Group Domain of Interpretation (GDOI) [RFC3547] defined by the IETF Multicast Security (MSEC) working group. 🔑 This doesn't rule out other key management methods where they're a better fit. 💜
IPsec [RFC4301] and TLS [RFC5246] also provide a proven security architecture, defining key exchange mechanisms and the ability to use a range of cryptographic algorithms. 🏛️ ULE security can make use of these established mechanisms and algorithms. 💖 See Appendix A for more details. 📖
6. Compatibility with Generic Stream Encapsulation 🦋
RFC 5163 [RFC5163] describes three new Extension Headers that can be used with Unidirectional Link Encapsulation, ULE, [RFC4326] and the Generic Stream Encapsulation (GSE) that was designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers [GSE]. 🛰️
The security threats and requirements in this document apply to both ULE and GSE encapsulations. 🫶
7. Summary 📝
This document analyses a set of threats and security requirements. ✨ It defines the requirements for ULE security and explains the motivation for link security as part of the Encapsulation layer.
ULE security MUST provide link-layer encryption and ULE Receiver identity protection. 🔐 The framework MUST support the optional ability to provide link-layer authentication and integrity assurance, as well as protection against insertion of old (duplicated) data into the ULE Stream (i.e., replay protection). 🛡️ This set of features is optional, so you don't pay the encapsulation overhead when you don't need it. 💅
ULE Stream security between a ULE Encapsulation Gateway and the corresponding Receiver(s) is considered an additional security mechanism to IPsec, TLS, and application layer end-to-end security. It is NOT a replacement for them. 🙅♀️ It lets a network operator provide functions similar to IPsec, but it also provides MPEG-2 transmission link confidentiality and protection of ULE Receiver identity (NPA address). 🎀
Appendix A describes a set of building blocks that can be used to realise a framework that provides ULE security functions. 🧚
8. Security Considerations 🛡️
Okay bestie, link-layer (L2) encryption of IP traffic is super common on broadcast and radio links 📡. It works as a sidekick to end-to-end security like TLS [RFC5246], SSH [RFC4251], and IPsec [RFC4301] 💅.
A big goal here is giving you the same level of privacy you'd get on a wired link 🔒. It is recommended that an ISP or user provide end-to-end security services based on well-known mechanisms such as IPsec or TLS. Those are the proven ones, no cap 🙌.
This document gives a threat analysis and works out the security requirements for link encryption, plus optional link-layer integrity/authentication of the SNDU payload 🧠✨.
There are some security issues that were raised in RFC 4326 [RFC4326] that this document does not address. They're out of scope, so here they are 👀:
- The security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
- Integrity issues related to the removal of the LAN FCS in a bridged networking environment. The removal of bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver.
- There is a potential security issue when a Receiver receives a PDU with two Length fields. The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. 🚨
9. Acknowledgments 🫶
The authors want to give a huge shoutout to Gorry Fairhurst (University of Aberdeen) for the help and advice 🌸. They also thank Laurence Duquerroy and Stephane Coombes (ESA), and Yim Fun Hu (University of Bradford), for their contributions 💜.
10. References 📚
10.1. Normative References
- [ISO-MPEG2] "Information technology -- generic coding of moving pictures and associated audio information systems, Part I", ISO 13818-1, International Standards Organisation (ISO), 2000.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
10.2. Informative References
- [BELLOVIN] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", Computer Communications Review 2:19, pp. 32-48, April 1989. http://www.cs.columbia.edu/~smb/
- [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI).
- [GSE] TS 102 606, "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards, Institute (ETSI), 2007.
- [IEEE-802] "Local and metropolitan area networks-Specific requirements Part 2: Logical Link Control", IEEE 802.2, IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
- [ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International Standards Organisation (ISO), 1998.
- [ITU-H222] H.222.0, "Information technology, Generic coding of moving pictures and associated audio information Systems", International Telecommunication Union, (ITU-T), 1995.
- [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
- [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
- [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
- [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
- [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006.
- [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
- [RFC5163] Fairhurst, G. and B. Collini-Nocker, "Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)", RFC 5163, April 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
Appendix A. ULE Security Framework 🎀
This section describes a security framework for deploying secure ULE networks 🔐.
A.1. Building Blocks
This ULE Security framework describes the following building blocks, as shown in Figure 2 below 🧩:
- The Key Management Block
- The ULE Security Extension Header Block
- The ULE Databases Block
Within the Key Management Block, the communication between the Group Member entity and the Group Server entity happens in the control plane 🕹️. The ULE Security Header Block applies security to the ULE SNDU, and this happens in the ULE data plane. The ULE Security Databases Block acts as the interface between the Key Management Block (control plane) and the ULE Security Header Block (ULE data plane), as shown in Figure 2. The Security Databases Block exists on both the group member and server sides. It has been left out of Figure 2 just for clarity 👀.
-----
+------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | |
| Group Member |\---------/| Group Server | |
| Block | | Block | Control
+------+----------+ +----------------+ Plane
| | |
| | |
| | \ /
----------- Key management <-> ULE Security databases -----
| |
\ /
+------+----------+
| ULE |
| SAD / SPD |
| Databases |
| Block |
+------+-+--------+
/ \
| |
----------- ULE Security databases <-> ULE Security Header ----
| | / \
| | |
| | |
+------+-+--------+ ULE Data
| ULE Security | Plane
| Extension Header| |
| Block | |
+-----------------+ \ /
-----Figure 2: Secure ULE Framework Building Blocks
A.1.1. Key Management Block 🔑
A key management framework is required to provide security at the ULE level using extension headers. This framework is responsible for user authentication, access control, and Security Association negotiation. That negotiation covers the security algorithms to be used, the generation of the different session keys, and policy material. The key management framework can be either automated or manual. This means the key management client entity (shown as the Key Management Group Member Block in Figure 2) will be present in all ULE Receivers, as well as at the ULE Encapsulators. The ULE Encapsulator could also be the Key Management Group Server Entity (shown as the Key Management Group Server Block in Figure 2).
This happens when the ULE Encapsulator also acts as the Key Management Group Server. Deployment may use either automated key management protocols (e.g., GSAKMP [RFC4535]) or manual insertion of keying material.
A.1.2. ULE Security Databases Block 🗄️
There needs to be two databases, similar to the IPsec databases.
- ULE-SAD: ULE Security Association Database contains all the Security Associations that are currently established with different ULE peers.
- ULE-SPD: ULE Security Policy Database contains the policies as described by the system manager. These policies describe the security services that must be enforced.
While traditionally link-layer security has operated using simple policy mechanisms, it is envisaged that ULE security should provide flexibility comparable to IPsec. The above design is based on the two databases defined for IPsec [RFC4301]. These databases could be used to implement either simple policies (as in traditional link security services) or more complex policies (as in IPsec).
The exact details of the header patterns that the SPD and SAD will have to support for all use cases will be described in a separate document. This document only highlights the need for such interfaces between the ULE data plane and the Key Management control plane.
A.1.3. ULE Extension Header Block 🦋
A new security extension header for the ULE protocol is required to provide the security features of data confidentiality, identity protection, data integrity, data authentication, and mechanisms to prevent replay attacks. Security keying material will be used for the different security algorithms (for encryption/decryption, MAC generation, etc.), which are used to meet the security requirements described in detail in Section 4 of this document.
This block will use the keying material and policy information from the ULE Security Database Block on the ULE payload, to generate the secure ULE Extension Header or to decipher the secure ULE extension header to get the ULE payload. An example overview of the ULE Security extension header format, along with the ULE header and payload, is shown in Figure 3 below.
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+Figure 3: ULE Security Extension Header Placement
A.2. Interface Definition 💖
Two new interfaces have to be defined between the blocks as shown in Figure 2 above. These interfaces are:
- Key Management Block <-> ULE Security Databases Block
- ULE Security Databases Block <-> ULE Security Header Block
Okay so the first interface is how the Key Management Block inserts keys, security associations, and policies into the ULE Database Block 🔑. The second is how the ULE Security Extension Header Block gets the keys and policy material it needs to generate the security extension header ✨.
A.2.1. Key Management <-> ULE Security Databases 🗝️
This interface is between the Key Management Block of a group member (GM client) and the ULE Security Database Block (shown in Figure 2). The Key Management GM entity talks to the GCKS and then gets the relevant security information (keys, cipher mode, security service, ULE_Security_ID, and other relevant keying material as well as policy). Then it inserts all of that data into the ULE Security Database Block. The Key Management could be either automated (e.g., GSAKMP [RFC4535] or GDOI [RFC3547]), or the security information could be manually inserted using this interface. Bestie, that's a lot of flexibility 🦋.
Examples of interface functions are:
Insert_record_database (char * Database, char * record, char *
Unique_ID);
Update_record_database (char * Database, char * record, char *
Unique_ID);
Delete_record_database (char * Database, char * Unique_ID);The definitions of the variables are as follows:
- Database - This is a pointer to the ULE Security databases
- record - This is the rows of security attributes to be entered or modified in the above databases
- Unique_ID - This is the primary key to look up records (rows of security attributes) in the above databases
A.2.2. ULE Security Databases <-> ULE Security Header 🌸
This interface is between the ULE Security Database and the ULE Security Extension Header Block as shown in Figure 2. When sending traffic, the ULE encapsulator uses the Destination Address, the PID, and possibly other information such as L3 source and destination addresses to locate the relevant security record within the ULE Security Database. It then uses the data in the record to create the ULE security extension header.
For received traffic, the ULE decapsulator, on receiving the ULE SNDU, uses the Destination Address, the PID, and a ULE Security ID that the ULE encapsulator inserted into the security extension to retrieve the relevant record from the Security Database. It then uses this information to decrypt the ULE extension header.
For both cases (sending or receiving traffic), only one interface is needed, since the main difference between the sender and receiver is the direction of the flow of traffic. An example of such an interface is as follows:
Get_record_database (char * Database, char * record, char *
Unique_ID);Appendix B. Motivation for ULE Link-Layer Security 🎀
Examination of the threat analysis and security requirements in Sections 3 and 4 has shown that there is a need to provide security in MPEG-2 transmission networks employing ULE. This section compares the placement of security functionalities in different layers. It's giving comparison shopping, honestly 🛍️.
B.1. Security at the IP Layer (Using IPsec) 🔐
The security architecture for the Internet Protocol [RFC4301] describes security services for traffic at the IP layer. This architecture primarily defines services for Internet Protocol (IP) unicast packets, as well as manually configured IP multicast packets.
It is possible to use IPsec to secure ULE Streams. The major advantage of IPsec is its wide implementation in IP routers and hosts. IPsec in transport mode can be used for end-to-end security transparently over MPEG-2 transmission links with little impact.
In the context of MPEG-2 transmission links, if IPsec is used to secure a ULE Stream, then the ULE Encapsulator and Receivers are equivalent to the security gateways in IPsec terminology. A security gateway implementation of IPsec uses tunnel mode. Such usage has the following disadvantages:
- There is an extra transmission overhead associated with using IPsec in tunnel mode, i.e., the extra IP header (IPv4 or IPv6).
- There is a need to protect the identity (NPA address) of ULE Receivers over the ULE broadcast medium; IPsec is not suitable for providing this service. In addition, the interfaces of these devices do not necessarily have IP addresses (they can be L2 devices).
- Multicast is considered a major service over ULE links. The current IPsec specifications [RFC4301] only define a pairwise tunnel between two IPsec devices with manual keying. Work is in progress in defining the extra detail needed for multicast and to use the tunnel mode with address preservation to allow efficient multicasting. For further details refer to [RFC5374].
B.2. Link Security below the Encapsulation Layer 🧱
Link layer security can be provided at the MPEG-2 TS layer (below ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a specific PID value. However, an MPEG-2 TS may typically multiplex several IP flows, belonging to different users, using a common PID. Therefore, all multiplexed traffic will share the same security keys.
This has the following advantages:
- The bit stream sent on the broadcast network does not expose any L2 or L3 headers; specifically, all addresses, type fields, and length fields are encrypted prior to transmission.
- This method does not preclude the use of IPsec, TLS, or any other form of higher-layer security.
However, it has the following disadvantages:
- When a PID is shared between several users, each ULE Receiver needs to decrypt all MPEG-2 TS Packets with a matching PID, possibly including those that are not required to be forwarded. Therefore, it does not have the flexibility to separately secure individual IP flows.
- When a PID is shared between several users, the ULE Receivers will have access to private traffic destined to other ULE Receivers, since they share a common PID and key.
- IETF-based key management that is very flexible and secure is not used in existing MPEG-2 based systems. Existing access control mechanisms in such systems have limited flexibility in terms of controlling the use of keying and rekeying. Therefore, if the key is compromised, this will impact several ULE Receivers. 😬
Currently, there are few deployed L2 security systems for MPEG-2 transmission networks. Conditional access for digital TV broadcasting is one example. However, this approach is optimised for TV services and is not well-suited to IP packet transmission. Some other systems are specified in standards such as MPE [ETSI-DAT], but there are currently no known implementations, and these methods are not applicable to GSE.
B.3. Link Security as a Part of the Encapsulation Layer 💜
Examining the threat analysis in Section 3 has shown that protection of ULE Stream from eavesdropping and ULE Receiver identity are major requirements.
There are several advantages in using ULE link-layer security:
- The protection of the complete ULE Protocol Data Unit (PDU), including IP addresses. The protection can be applied either per IP flow or per Receiver NPA address.
- Ability to protect the identity of the Receiver within the MPEG-2 transmission network at the IP layer and also at L2.
- Efficient protection of IP multicast over ULE links.
- Transparency to the use of Network Address Translation (NATs) [RFC3715] and TCP Performance Enhancing Proxies (PEP) [RFC3135], which require the ability to inspect and modify the packets sent over the ULE link.
This method does not preclude the use of IPsec at L3 (or TLS [RFC5246] at L4). IPsec and TLS provide strong authentication of the endpoints in the communication.
L3 end-to-end security would partially deny the advantage listed above (use of PEP, compression, etc.), since those techniques could only be applied to TCP packets bearing a TCP-encapsulated IPsec packet exchange, but not the TCP packets of the original applications, which in particular inhibits compression.
End-to-end security (IPsec, TLS, etc.) may be used independently to provide strong authentication of the endpoints in the communication. This authentication is desirable in many scenarios to ensure that the correct information is being exchanged between the trusted parties, whereas Layer 2 methods cannot provide this guarantee. Layer 2 can't do that part alone, so end-to-end security is the glow-up 🌈
Authors' Addresses 🫶
Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
EMail: h.cruickshank@surrey.ac.uk
Prashant Pillai
Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
EMail: p.pillai@bradford.ac.uk
Michael Noisternig
Multimedia Comm. Group, Dpt. of Computer Sciences
University of Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg
Austria
EMail: mnoist@cosy.sbg.ac.at
Sunil Iyengar
Space & Defence
Logica
Springfield Drive
Leatherhead
Surrey KT22 7LP
UK
EMail: sunil.iyengar@logica.com📦 where this page comes from
- ietf: rfc5458 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms