diff options
Diffstat (limited to 'doc/rfc/rfc5458.txt')
| -rw-r--r-- | doc/rfc/rfc5458.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc5458.txt b/doc/rfc/rfc5458.txt new file mode 100644 index 0000000..d8fe55a --- /dev/null +++ b/doc/rfc/rfc5458.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group H. Cruickshank +Request for Comments: 5458 University of Surrey +Category: Informational P. Pillai + University of Bradford + M. Noisternig + University of Salzburg + S. Iyengar + Logica + March 2009 + + + Security Requirements for + the Unidirectional Lightweight Encapsulation (ULE) Protocol + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +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, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The MPEG-2 standard defined by ISO 13818-1 supports a range of + transmission methods for a variety of services. This document + provides a threat analysis and derives the security requirements when + using the Transport Stream, TS, to support an Internet network-layer + using Unidirectional Lightweight Encapsulation (ULE) defined in RFC + 4326. The document also provides the motivation for link-layer + security for a ULE Stream. A ULE Stream may be used to send IPv4 + packets, IPv6 packets, and other Protocol Data Units (PDUs) to an + arbitrarily large number of Receivers supporting unicast and/or + multicast transmission. + + The analysis also describes applicability to the Generic Stream + Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB) + Project. + + + + +Cruickshank, et al. Informational [Page 1] + +RFC 5458 Security Requirements for ULE March 2009 + + +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 ........25 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cruickshank, et al. Informational [Page 2] + +RFC 5458 Security Requirements for ULE March 2009 + + +1. Introduction + + The MPEG-2 Transport Stream (TS) has been widely accepted not only + for providing digital TV services, but also as a subnetwork + technology for building IP networks. RFC 4326 [RFC4326] describes + the Unidirectional Lightweight Encapsulation (ULE) mechanism for the + transport of IPv4 and IPv6 Datagrams and 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 that allows it to carry additional header + information to assist in network/Receiver processing. The + encapsulation satisfies the design and architectural requirement for + a lightweight encapsulation defined in RFC 4259 [RFC4259]. + + Section 3.1 of RFC 4259 presents several topological scenarios for + MPEG-2 Transmission Networks. A summary of these scenarios is + presented below: + + A. Broadcast TV and Radio Delivery. This is not within the scope of + this document. + + B. Broadcast Networks used as an ISP. This resembles scenario A, but + includes IP services to access the public Internet. + + C. Unidirectional Star IP Scenario. This provides a data network + delivering a common bit stream to typically medium-sized groups of + Receivers. + + D. Datacast Overlay. This employs MPEG-2 physical and link layers to + provide additional 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 states that ULE must be robust to errors and security + threats. Security must also consider both unidirectional (A, B, C, + and D) as well as bidirectional (E and F) links for the scenarios + mentioned above. + + An initial analysis of the security requirements in MPEG-2 + transmission networks is presented in the "Security Considerations" + section of RFC 4259. For example, when such networks are not using a + wireline network, the normal security issues relating to the use of + wireless links for transport of Internet traffic should be considered + [RFC3819]. + + + +Cruickshank, et al. Informational [Page 3] + +RFC 5458 Security Requirements for ULE March 2009 + + + The security considerations of RFC 4259 recommend that any new + encapsulation defined by the IETF should allow Transport Stream + encryption and should also support optional link-layer authentication + of the Subnetwork Data Unit (SNDU) payload. In ULE [RFC4326], it is + suggested that this may be provided in a flexible way using Extension + Headers. This requires the definition of a mandatory Extension + Header, but has the advantage that it decouples specification of the + security functions from the encapsulation functions. + + This document extends the above analysis and derives in detail the + security requirements for ULE in MPEG-2 transmission networks. + + A security framework for deployment of secure ULE networks describing + the different building blocks and the interface definitions is + presented 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 the transmission of 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 the transmission of video, audio, and data using + the ISO MPEG-2 Standard [ISO-MPEG2]. + + Encapsulator: A network device that receives Protocol Data Units + (PDUs) and formats these 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 + and provides the policy and keying material to members of a secure + group. + + 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. + + + + + +Cruickshank, et al. Informational [Page 4] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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, refers to a + 6-byte destination address (resembling an IEEE Medium Access Control + address) within the MPEG-2 transmission network that is 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. This is used to identify the TS Logical + Channel to which a TS Packet belongs [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 value 0x1FFF + indicates a Null TS Packet 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 using 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 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 using TS Packets; it represents Layer 2 of the ISO/OSI + reference model. See also TS Logical Channel and TS Multiplex. + + + +Cruickshank, et al. Informational [Page 5] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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 (i.e., a transmission at a specified symbol + rate, Forward Error Correction (FEC) setting, and transmission + frequency) or an encapsulation provided by another protocol layer + (e.g., 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, to 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 definition of a + stream_type in SI/PSI [ISO-MPEG2]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cruickshank, et al. Informational [Page 6] + +RFC 5458 Security Requirements for ULE March 2009 + + +3. Threat Analysis + +3.1. System Components + + +------------+ +------------+ + | 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 Mux + + Figure 1: An example configuration for a unidirectional service + for IP transport over MPEG-2 (adapted from [RFC4259]) + + As shown in Figure 1 above (from Section 3.3 of [RFC4259]), there are + several entities within the MPEG-2 transmission network architecture. + These include: + + o ULE Encapsulation Gateways (the ULE Encapsulator) + + o SI-Table signalling generator (input to the multiplexer) + + o Receivers (the endpoints for ULE Streams) + + o TS multiplexers (including re-multiplexers) + + + +Cruickshank, et al. Informational [Page 7] + +RFC 5458 Security Requirements for ULE March 2009 + + + o Modulators + + The TS Packets are carried to the Receiver over a physical layer that + usually includes Forward Error Correction (FEC) coding that + interleaves the bytes of several consecutive, but unrelated, TS + Packets. FEC-coding and synchronisation processing makes injection + of single TS Packets very difficult. Replacement of a sequence of + packets is also difficult, but 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) to reassemble the + fragments of PDUs sent by an L2 source [RFC4259]. In an MPEG-2 TS, + this association is made via the Packet Identifier, PID [ISO-MPEG2]. + At the sender, each source associates a locally unique set of PID + values with each stream it originates. However, there is no required + relationship between the PID value used at the sender and that + received at the Receiver. Network devices may re-number the PID + values associated with one or more TS Logical Channels (e.g., ULE + Streams) to prevent clashes at a multiplexer between input streams + with the same PID carried on different input multiplexes (updating + entries in the PMT [ISO-MPEG2], and 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). However, there is only one valid source of data for each + MPEG-2 Elementary Stream, 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 other 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 as well as authenticity of these + messages is important for correct working of the ULE network, i.e., + supporting its security objectives in the area of availability, in + addition to confidentiality and integrity. One method recently + proposed [RFC5163] encapsulates these messages using ULE. In such + cases all the security requirements of this document apply in + securing these signalling messages. + + ULE Stream security only concerns the security between the ULE + Encapsulation Gateway (ULE Encapsulator) and the Receiver. In many + deployment scenarios the user of a ULE Stream has to secure + communications beyond the link since other network links are utilised + in addition to the ULE link. Therefore, if authentication of the + endpoints, i.e., the IP Sources, is required, or users are concerned + + + +Cruickshank, et al. Informational [Page 8] + +RFC 5458 Security Requirements for ULE March 2009 + + + about loss of confidentiality, integrity, or authenticity of their + communication data, they will have to employ end-to-end network + security mechanisms, e.g., IPsec or Transport Layer Security (TLS). + Governmental users may be forced by regulations to employ specific + approved implementations of those mechanisms. Hence, for such cases, + the requirements for confidentiality and integrity of the user data + will be met by the end-to-end security mechanism and the ULE security + measures would focus on providing traffic flow confidentiality either + for user data that has already been encrypted or for users who choose + not to implement end-to-end security mechanisms. + + ULE links may also be used for communications where the two IP + endpoints are not under central control (e.g., when browsing a public + web site). In these cases, it may be impossible to enforce any end- + to-end security mechanisms. Yet, a common objective is that users + may make the same security assumptions as for wired links [RFC3819]. + ULE security could achieve this by protecting the vulnerable (in + terms of passive attacks) ULE Stream. + + In contrast to the above, a ULE Stream can be used to link networks + such as branch offices to a central office. ULE link-layer security + could be the sole provider of confidentiality and integrity. In this + scenario, users requiring high assurance of security (e.g., + government use) will need to employ 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. This + includes eavesdropping or monitoring of transmissions, with a goal to + obtain information that is being transmitted. In broadcast networks + (especially those utilising widely available low-cost physical layer + interfaces, such as DVB), the 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 determine the identity of + the communicating parties and the volume of their traffic by sniffing + (L2) addresses. This is a well-known issue in the security field; + however, it is more of a problem in the case of broadcast networks + such as MPEG-2 transmission networks because of the easy availability + of Receiver hardware and the wide geographical span of the networks. + + + + + + + + +Cruickshank, et al. Informational [Page 9] + +RFC 5458 Security Requirements for ULE March 2009 + + + Active threats (or attacks) are, in general, more difficult to + implement successfully than passive threats, and usually require more + sophisticated resources and may require access to the transmitter. + Within the context of MPEG-2 transmission networks, examples of + active attacks are: + + o Masquerading: An entity pretends to be a different entity. This + includes masquerading other users and subnetwork control plane + messages. + + o Modification of messages in an unauthorised manner. + + o Replay attacks: When an intruder sends some old (authentic) + messages to the Receiver. In the case of a broadcast link, access + to previous broadcast data is easy. + + o 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 in fact 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 that is able + to modify the content of the received multiplex (e.g., replay data + and/or control information) could inject data locally into the + received stream with an arbitrary PID value. + +3.3. Threat Cases + + Analysing the topological scenarios for MPEG-2 Transmission Networks + in Section 1, the security threats can be abstracted into three + cases: + + o Case 1: Monitoring (passive threat). Here the intruder monitors + the ULE broadcasts to gain information about the ULE data and/or + tracking the communicating parties identities (by monitoring the + destination NPA address). In this scenario, measures must be taken + to protect the ULE payload data and the identity of ULE Receivers. + + + +Cruickshank, et al. Informational [Page 10] + +RFC 5458 Security Requirements for ULE March 2009 + + + o Case 2: Locally conducting active attacks on the MPEG-TS multiplex. + Here an intruder is assumed to be sufficiently sophisticated to + override the original transmission from the ULE Encapsulation + Gateway and deliver a modified version of the MPEG-TS transmission + to a single ULE Receiver or a small group of Receivers (e.g., in a + single company site). The MPEG-2 transmission network operator + might not be aware of such attacks. Measures must be taken to + ensure ULE data integrity and authenticity and preventing replay of + old messages. + + o Case 3: Globally conducting active attacks on the MPEG-TS + multiplex. This assumes a sophisticated intruder able to override + the whole MPEG-2 transmission multiplex. The requirements are + similar to case 2. The MPEG-2 transmission network operator can + usually identify such attacks and provide corrective action to + restore the original transmission. + + For both Cases 2 and 3, there can be two sub-cases: + + o Insider attacks, i.e., active attacks from adversaries within the + network with knowledge of the secret material. + + o Outsider attacks, i.e., active attacks from adversaries without + knowledge of the secret material. + + In terms of priority, Case 1 is considered the major threat in MPEG-2 + transmission systems. Case 2 is considered a lesser threat, + appropriate to specific network configurations, especially when + vulnerable to insider attacks. Case 3 is less likely to be found in + an operational network, and is expected to be noticed by the MPEG-2 + transmission operator. It will require restoration of the original + transmission. The assumption being that physical access to the + network components (multiplexers, etc.) and/or connecting physical + media is secure. Therefore, Case 3 is not considered further in this + document. + +4. Security Requirements for IP over MPEG-2 TS + + From the threat analysis in Section 3, the following security + requirements can be derived: + + Req 1. Data confidentiality MUST be provided by a link that supports + ULE Stream Security to prevent passive attacks and reduce the risk + of active threats. + + + + + + + +Cruickshank, et al. Informational [Page 11] + +RFC 5458 Security Requirements for ULE March 2009 + + + Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast + networks, this protection can be used to prevent an intruder + tracking the identity of ULE Receivers and the volume of their + traffic. + + Req 3. Integrity protection and source authentication of ULE Stream + data are OPTIONAL. These can be used to prevent the active + attacks described in Section 3.2. + + Req 4. Protection against replay attacks is OPTIONAL. This is used + to counter the active attacks described in Section 3.2. + + Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. This + can be performed during the initial key exchange and + authentication phase, before the ULE Receiver can join a secure + session with the ULE Encapsulator (ULE source). This could be + either unidirectional or bidirectional authentication based 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 allows the independent development of both systems. + + 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. + + GReq (d) The security extension header MUST be compatible with other + ULE extension headers. The method must allow other extension + headers (either mandatory or optional) to be used in combination + with a security extension. It is RECOMMENDED that these are + placed after the security extension header. This permits full + protection for all headers. It also avoids situations where the + SNDU has to be discarded on processing the security extension + header, while preceding headers have already been evaluated. One + exception is the Timestamp extension that SHOULD precede the + security extension header [RFC5163]. In this case, the timestamp + will be unaffected by security services such as data + confidentiality and can be decoded without the need for key + material. + + + + + +Cruickshank, et al. Informational [Page 12] + +RFC 5458 Security Requirements for ULE March 2009 + + + Examining the threat cases in Section 3.3, the security requirements + for each case can be summarised as: + + o Case 1: Data confidentiality (Req 1) MUST be provided to prevent + monitoring of the ULE data (such as user information and IP + addresses). Protection of NPA addresses (Req 2) MAY be provided to + prevent tracking ULE Receivers and their communications. + + o Case 2: In addition to 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] in order to provide + integrity protection and source authentication (Reqs 3 and 5). In + addition, sequence numbers (Req 4) MAY be used to protect against + replay attacks. In terms of outsider attacks, group authentication + using Message Authentication Codes can provide the required level + of security (Reqs 3 and 5). This will significantly reduce the + ability of intruders to successfully inject their own data into the + MPEG-TS stream. However, scenario 2 threats apply only in specific + service cases, and therefore authentication and protection against + replay attacks are OPTIONAL. Such measures incur additional + transmission as well as processing overheads. Moreover, intrusion + detection systems may also be needed by the MPEG-2 network + operator. These should best be coupled with perimeter security + policy to monitor common DoS attacks. + + o 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 such attacks, the constraints on intrusion + detections are less than in Case 2. + + Table 1 below shows the threats that are applicable to ULE networks, + and the relevant security mechanisms to mitigate those threats. + + + + + + + + + + + + + + + + + + +Cruickshank, et al. Informational [Page 13] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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 Networks + +5. Design Recommendations for ULE Security Extension Header + + Table 1 may assist in selecting fields within a ULE Security + Extension Header framework. + + Security services may be grouped into profiles based on security + requirements, e.g., a base profile (with payload encryption and + identity protection) and a second profile that extends this to also + provide source authentication and protection against replay attacks. + Although the use of specific security techniques is optional, it is + RECOMMENDED that receiver devices should implement all the techniques + in Reqs 2-5 of Section 4 to ensure interoperability of all profiles. + + A modular design of ULE security may allow it to use and benefit from + existing key management protocols, such as 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 does not preclude the + use of other key management methods in scenarios where this is more + appropriate. + + + + + + + + +Cruickshank, et al. Informational [Page 14] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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 may be + used with Unidirectional Link Encapsulation, ULE, [RFC4326] and the + Generic Stream Encapsulation (GSE) that has been 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 presented in this document are + applicable to ULE and GSE encapsulations. + +7. Summary + + This document analyses a set of threats and security requirements. + It defines the requirements for ULE security and states the + motivation for link security as a 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 for 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 to reduce encapsulation overhead when not required. + + 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, + and not as a replacement. It allows a network operator to provide + similar functions to that of IPsec, but in addition provides MPEG-2 + transmission link confidentiality and protection of ULE Receiver + identity (NPA address). + + Appendix A describes a set of building blocks that may be used to + realise a framework that provides ULE security functions. + +8. Security Considerations + + Link-layer (L2) encryption of IP traffic is commonly used in + broadcast/radio links to supplement end-to-end security (e.g., + provided by TLS [RFC5246], SSH [RFC4251], IPsec [RFC4301]). + + + + + +Cruickshank, et al. Informational [Page 15] + +RFC 5458 Security Requirements for ULE March 2009 + + + A common objective is to provide the same level of privacy as wired + links. It is recommended that an ISP or user provide end-to-end + security services based on well-known mechanisms such as IPsec or + TLS. + + This document provides a threat analysis and derives the security + requirements to provide link encryption and optional link-layer + integrity/authentication of the SNDU payload. + + There are some security issues that were raised in RFC 4326 [RFC4326] + that are not addressed in this document (i.e., are out of scope), + e.g.: + + o The security issue with un-initialised stuffing bytes. In ULE, + these bytes are set to 0xFF (normal practice in MPEG-2). + + o 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. + + o 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 acknowledge the help and advice from Gorry Fairhurst + (University of Aberdeen). The authors also acknowledge contributions + from Laurence Duquerroy and Stephane Coombes (ESA), and Yim Fun Hu + (University of Bradford). + +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. + + + + + + + +Cruickshank, et al. Informational [Page 16] + +RFC 5458 Security Requirements for ULE March 2009 + + + [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. + + + + + +Cruickshank, et al. Informational [Page 17] + +RFC 5458 Security Requirements for ULE March 2009 + + + [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. + + + + + + + + + + + + + + + + +Cruickshank, et al. Informational [Page 18] + +RFC 5458 Security Requirements for ULE March 2009 + + +Appendix A. ULE Security Framework + + This section describes a security framework for the deployment of + secure ULE networks. + +A.1. Building Blocks + + This ULE Security framework describes the following building blocks + as shown in Figure 2 below: + + o The Key Management Block + + o The ULE Security Extension Header Block + + o 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 in + both the group member and server sides. However, it has been omitted + from Figure 2 just for clarity. + + + + + + + + + + + + + + + + + + + + + + + + + + +Cruickshank, et al. Informational [Page 19] + +RFC 5458 Security Requirements for ULE March 2009 + + + ----- + +------+----------+ +----------------+ / \ + | 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 key management framework is + responsible for user authentication, access control, and Security + Association negotiation (which include the negotiations of the + security algorithms to be used and the generation of the different + session keys as well as policy material). The key management + framework can be either automated or manual. Hence, this 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). + + + + +Cruickshank, et al. Informational [Page 20] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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, i.e., similar to the IPsec + databases. + + o ULE-SAD: ULE Security Association Database contains all the + Security Associations that are currently established with different + ULE peers. + + o 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. + + + + + +Cruickshank, et al. Informational [Page 21] + +RFC 5458 Security Requirements for ULE March 2009 + + + +-------+------+-------------------------------+------+ + | 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: + + o Key Management Block <-> ULE Security Databases Block + + o ULE Security Databases Block <-> ULE Security Header Block + + While the first interface is used by the Key Management Block to + insert keys, security associations, and policies into the ULE + Database Block, the second interface is used by the ULE Security + Extension Header Block to get the keys and policy material for + generation of 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 will communicate with the GCKS and then + get the relevant security information (keys, cipher mode, security + service, ULE_Security_ID, and other relevant keying material as well + as policy) and insert this data into the ULE Security Database Block. + The Key Management could be either automated (e.g., GSAKMP [RFC4535] + or GDOI [RFC3547]), or security information could be manually + inserted using this interface. + + Examples of interface functions are: + + o Insert_record_database (char * Database, char * record, char * + Unique_ID); + + o Update_record_database (char * Database, char * record, char * + Unique_ID); + + o Delete_record_database (char * Database, char * Unique_ID); + + The definitions of the variables are as follows: + + o Database - This is a pointer to the ULE Security databases + + + + +Cruickshank, et al. Informational [Page 22] + +RFC 5458 Security Requirements for ULE March 2009 + + + o record - This is the rows of security attributes to be entered or + modified in the above databases + + o 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 will use the Destination + Address, the PID, and a ULE Security ID inserted by the ULE + encapsulator 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 (either send or + receive 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: + + o 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. + +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 the 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. + + + + + +Cruickshank, et al. Informational [Page 23] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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: + + o There is an extra transmission overhead associated with using IPsec + in tunnel mode, i.e., the extra IP header (IPv4 or IPv6). + + o 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). + + o 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: + + o 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. + + o This method does not preclude the use of IPsec, TLS, or any other + form of higher-layer security. + + However it has the following disadvantages: + + o 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. + + + + + +Cruickshank, et al. Informational [Page 24] + +RFC 5458 Security Requirements for ULE March 2009 + + + o 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. + + o 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: + + o 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. + + o Ability to protect the identity of the Receiver within the MPEG-2 + transmission network at the IP layer and also at L2. + + o Efficient protection of IP multicast over ULE links. + + o 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. + + + + + + + + +Cruickshank, et al. Informational [Page 25] + +RFC 5458 Security Requirements for ULE March 2009 + + + 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. + +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 + + + + + + +Cruickshank, et al. Informational [Page 26] + |