IPDVB Working Group H. Cruickshank Internet-Draft S. Iyengar Intended status: Informational University of Surrey, UK P. Pillai Expires: October 4, 2008 University of Bradford, UK April 4, 2008 Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol draft-ietf-ipdvb-sec-req-06.txt Status of this Draft By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 4, 2008. Abstract The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a range 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 RFC4326. 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. Cruickshank et.al. Expires October 4, 2008 [Page 1] Internet-Draft Security Requirements for ULE April 2008 Table of Contents 1. Introduction................................................2 2. Requirements notation.......................................3 3. Threat Analysis.............................................6 3.1. System Components......................................6 3.2. Threats................................................9 3.3. Threat Scenarios......................................10 4. Security Requirements for IP over MPEG-2 TS................11 5. Design recommendations for ULE Security Header Extension...13 6. Compatibility with Generic Stream Encapsulation............14 7. Summary....................................................14 8. Security Considerations....................................15 9. IANA Considerations........................................16 10. Acknowledgments...........................................16 11. References................................................16 11.1. Normative References.................................16 11.2. Informative References...............................16 12. Author's Addresses........................................18 13. IPR Notices...............................................18 13.1. Intellectual Property Statement......................19 14. Copyright Statement.......................................19 Appendix A: ULE Security Framework............................20 Appendix B: Motivation for ULE link-layer security............24 Document History..............................................27 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 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 are presented below (for full detail, please refer to RFC 4259): 1. Broadcast TV and Radio Delivery. 2. Broadcast Networks used as an ISP. This resembles to scenario 1, but includes the provision of IP services providing access Cruickshank et.al. Expires April 12, 2008 [Page 2] Internet-Draft Security Requirements for ULE April 2008 to the public Internet. 3. Unidirectional Star IP Scenario. It utilizes a Hub station to provide a data network delivering a common bit stream to typically medium-sized groups of Receivers. 4. Datacast Overlay. It employs MPEG-2 physical and link layers to provide additional connectivity such as unidirectional multicast to supplement an existing IP-based Internet service. 5. Point-to-Point Links. 6. Two-Way IP Networks. This can be typically satellite-based and star-based utilising a Hub station to deliver a common bit stream to medium-sized groups of receivers. A bidirectional service is provided over a common air-interface. RFC 4259 states that ULE must be robust to errors and security threats. Security must also consider both unidirectional as well as bidirectional 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]. The security considerations of RFC 4259 recommends that any new encapsulation defined by the IETF should allow Transport Stream encryption and should also support optional link-layer authentication of the 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 header extension, but has the advantage that it decouples specification of the security functions from the encapsulation functions. This document extends the above analysis and derives a detailed 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 Cruickshank et.al. Expires April 12, 2008 [Page 3] Internet-Draft Security Requirements for ULE April 2008 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [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 PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets. 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 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 standardized 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 Cruickshank et.al. Expires April 12, 2008 [Page 4] Internet-Draft Security Requirements for ULE April 2008 Packets forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000 as well as other PID values is 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. 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, 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 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B 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 Cruickshank et.al. Expires April 12, 2008 [Page 5] Internet-Draft Security Requirements for ULE April 2008 encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2]. 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) Cruickshank et.al. Expires April 12, 2008 [Page 6] Internet-Draft Security Requirements for ULE April 2008 o Receivers (the end points for ULE streams) o TS multiplexers (including re-multiplexers) o Modulators In a MPEG-2 TS transmission network, the originating source of TS Packets is either a L2 interface device (media encoder, encapsulation gateway, etc) or a L2 network device (TS multiplexer, etc). These devices may, but do not necessarily, have an associated IP address. In the case of an encapsulation gateway (e.g. ULE sender), the device may operate at L2 or Layer 3 (L3), and is not normally the originator of an IP traffic flow, and usually the IP source address of the packets that it forwards do not correspond to an IP address associated with the device. 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 a 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 a L2 source [RFC4259]. In a 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 [ID-AR] may need to be broadcast (e.g. by an Encapsulation Gateway or other device) to form the Layer 2 (L2) control plane. Examples of Cruickshank et.al. Expires April 12, 2008 [Page 7] Internet-Draft Security Requirements for ULE April 2008 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 [ID- EXT] encapsulates these messages using ULE. In such cases all the security requirements of this document apply in securing these signalling messages. ULE link security focuses only on 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 end-point i.e. the IP Sources is required, or users are concerned about loss of confidentiality, integrity or authenticity of their communication data, they will have to employ end-to-end network security mechanisms like 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 confidentiality and integrity of the user data will already be taken care of by the end-to-end security mechanism and the ULE security measures would focus on either providing traffic flow confidentiality 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 end- points 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 can rely on security assumptions as of wired links. ULE security could achieve this by protecting the vulnerable (in terms of passive attacks) ULE link. In contrast to the above, if a ULE Stream is used to directly join networks which are considered physically secure, for example branch offices to a central office, ULE link Security could be the sole provider of confidentiality and integrity. In this scenario, governmental users could still have to employ approved cryptographic equipment at the network layer or above, unless a manufacturer of ULE Link Security equipment obtains governmental approval for their implementation. Cruickshank et.al. Expires April 12, 2008 [Page 8] Internet-Draft Security Requirements for ULE April 2008 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) passive threats are considered the major threats. An example of such a threat is an intruder monitoring the MPEG-2 transmission broadcast and then extracting traffic information concerning the communication between IP hosts using a link. Another example is of an intruder trying to gain information about the communication parties by monitoring their ULE Receiver NPA addresses; an intruder can gain information by determining the layer 2 identity of the communicating parties and the volume of their traffic. 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. 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 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 Cruickshank et.al. Expires April 12, 2008 [Page 9] Internet-Draft Security Requirements for ULE April 2008 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 Scenarios Analysing the topological scenarios for MPEG-2 Transmission Networks in section 1, the security threat cases 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). In this scenario, measures must be taken to protect the ULE payload data and the identity of ULE Receivers. o Case 2: Locally conduct active attacks on the MPEG-TS multiplex. Here an intruder is assumed to be sufficiently sophisticated to over-ride 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 source authentication and preventing replay of old messages. o Case 3: Globally conduct active attacks on the MPEG-TS multiplex. Here we assume an intruder is very sophisticated and able to over-ride the whole MPEG-2 transmission multiplex. The requirements here are similar to scenario 2. The MPEG-2 transmission network operator can usually identify such attacks and may resort to some means 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 outside of a virtual Cruickshank et.al. Expires April 12, 2008 [Page 10] Internet-Draft Security Requirements for ULE April 2008 private network. In terms of priority, case 1 is considered the major threat in MPEG-2 transmission systems. Case 2 is likely to a lesser degree within certain network configurations, especially when there are insider attacks. Hence, protection against such active attacks should be used only when such a threat is a real possibility. Case 3 is envisaged to be less practical, because it will be very difficult to pass unnoticed by the MPEG-2 transmission operator. It will require restoration of the original transmission. The assumption being here is 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 considered in order to mitigate passive and active threats in MPEG-2 broadcast networks. Req 2. Protection of Layer 2 NPA address MAY be provided. 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 authentication of the ULE source MAY be provided to prevent active attacks described in section 3.2. Req 4. Protection against replay attacks MAY be provided. This is required for the active attacks described in section 3.2. Req 5. Layer L2 ULE Source and Receiver authentication MAY be provided. This is normally 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 is normally receiver to hub authentication and it could be either unidirectional or bidirectional authentication based on the underlying key management protocol. Other general requirements are: GReq (a) ULE key management functions SHALL be decoupled from ULE Cruickshank et.al. Expires April 12, 2008 [Page 11] Internet-Draft Security Requirements for ULE April 2008 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. Changes in crypto algorithms, hashes as they become obsolete should be updated without affecting the overall security of the system. GReq (d) Traceability SHOULD be supported to monitor the transmission network using log files to record the activities in the network and detect any intrusion. GReq (e) Protection against loss of service (availability) through malicious reconfiguration of system components (see Figure 1) MUST be present. GReq (f) The security system MUST be compatible with other networking functions such as NAT Network Address Translation (NAT) [RFC3715] or TCP acceleration can be used in a wireless broadcast networks. GReq (g) The security extension header MUST be compatible with other ULE extension headers GReq (h) Where a ULE Stream carries a set of IP traffic flows to different destinations with a range of properties (multicast, unicast, etc), it is often not appropriate to provide IP confidentiality services for the entire ULE Stream. For many expected applications of ULE, a finer-grain control MAY therefore be required, at least permitting control of data confidentiality/authorisation at the level of a single MAC/NPA address. 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 Cruickshank et.al. Expires April 12, 2008 [Page 12] Internet-Draft Security Requirements for ULE April 2008 Authentication Codes, digital signatures or TESLA [RFC4082] in order to provide integrity protection and source authentication (Req 2, Req 3 and Req 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 should provide the same level of security (Req 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 most denial- of-service 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. The general requirements GReq(a) to GReq(h) are good security practices and apply to all the scenarios above, where appropriate. 5. Design recommendations for ULE Security Header Extension Table 1 below shows the threats that are applicable to ULE networks and the relevant security mechanism to mitigate those threats. This would help in the design of the ULE Security extension header. For example this could help in the selection of security fields in the ULE Security extension Header design. Moreover the security services could also be grouped into profiles based on different security requirements. One example is to have a base profile which does payload encryption and identity protection. The second profile could do the above as well as source authentication. A modular design to ULE Security may allow it to use and benefit from IETF key management protocols, such as GSAKMP [RFC4535] and GDOI [RFC3547] protocols 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. IPsec or TLS also provide a proven security architecture defining key exchange mechanisms and the ability to use a range of Cruickshank et.al. Expires April 12, 2008 [Page 13] Internet-Draft Security Requirements for ULE April 2008 cryptographic algorithms. ULE security can make use of these established mechanisms and algorithms. Mitigation of Threat ----------------------------------------------- | Data | Data |Source |Data |Intru |Iden | |Privacy | fresh |Authent|Integ |sion |tity | | | ness |ication|rity |Dete |Prote | | | | | |ction |ction | Attack | | | | | | | ---------------|--------|-------|-------|-------|-------|------| | 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. 6. Compatibility with Generic Stream Encapsulation The [ID-EXT] document describes two new Header Extensions 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, and specifically for DVB-S2 [ID-EXT]. The security threats and requirement presented in this document are applicable to ULE and GSE encapsulations. It might be desirable to authenticate some/all of the headers; such decision can be part of the security policy for the MPEG-2 transmission network. 7. Summary This document analyses a set of threats and security requirements. It also defines the requirements for ULE security and states the motivation for link security as a part of the Encapsulation layer. Cruickshank et.al. Expires April 12, 2008 [Page 14] Internet-Draft Security Requirements for ULE April 2008 ULE security includes a need to provide link-layer encryption and ULE Receiver identity protection. There is an optional requirement 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 is optional because of the associated overheads for the extra features and they are only required for specific service cases. ULE link security (between a ULE Encapsulation Gateway to Receivers) is considered as 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). End-to-end security mechanism may then be used additionally and independently for providing strong authentication of the end-points in the communication. Annexe 1 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 [RFC4346], SSH [RFC4251], IPsec [RFC4301). 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 (out of scope) such as: 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 for bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Cruickshank et.al. Expires April 12, 2008 [Page 15] Internet-Draft Security Requirements for ULE April 2008 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. IANA Considerations There are no IANA actions defined in this document. 10. 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), Yim Fun Hu (University of Bradford) and Michael Noisternig from University of Salzburg. 11. References 11.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, 1997. 11.2. Informative References [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", Work in Progress , June 2006, IETF Work in Progress. [RFC3715] B. Aboba and W Dixson, "IPsec-Network Address Translation (NAT) Compatibility Requirements" IETF RFC 3715, March 2004. [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security Cruickshank et.al. Expires April 12, 2008 [Page 17] Internet-Draft Security Requirements for ULE April 2008 (TLS) Protocol Version 1.1", IETF RFC 4346, April 2006. [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", IETF RFC 3135, June 2001. [RFC4301] Kent, S. and Seo K., "Security Architecture for the Internet Protocol", IETF RFC 4301, December 2006. [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, IETF RFC 3819, July 2004. [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", IETF RFC 4251, January 2006. 12. Author's Addresses Haitham Cruickshank Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: h.cruickshank@surrey.ac.uk Sunil Iyengar Centre for Communications System Research (CCSR) University of Surrey Guildford, Surrey, GU2 7XH UK Email: S.Iyengar@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 13. IPR Notices Copyright (c) The IETF Trust (2007). Cruickshank et.al. Expires April 12, 2008 [Page 18] Internet-Draft Security Requirements for ULE April 2008 13.1. Intellectual Property Statement Full Copyright Statement This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 14. Copyright Statement Copyright (C) The IETF Trust (2008). Cruickshank et.al. Expires April 12, 2008 [Page 19] Internet-Draft Security Requirements for ULE April 2008 Appendix A: ULE Security Framework This section defines a security framework for the deployment of secure ULE networks. A.1 Building Blocks This ULE Security framework defines 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. ------ +------+----------+ +----------------+ / \ | Key Management |/---------\| Key Management | | | Block |\---------/| Block | | | Group Member | | Group Server | Control +------+----------+ +----------------+ Plane | | | | | | | | \ / ----------- Key management <-> ULE Security databases ----- | | \ / +------+----------+ | ULE | | SAD / SPD | | Databases | | Block | +------+-+--------+ / \ | | ----------- ULE Security databases <-> ULE Security Header ---- Cruickshank et.al. Expires April 12, 2008 [Page 20] Internet-Draft Security Requirements for ULE April 2008 | | / \ | | | | | | +------+-+--------+ 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. 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 Extension Header Block A new security extension header for the ULE protocol is required to provide the security features of data confidentiality, 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. There Cruickshank et.al. Expires April 12, 2008 [Page 21] Internet-Draft Security Requirements for ULE April 2008 could be other extension headers (either mandatory or optional). It is RECOMMENDED that these are placed after the security extension header. This permits full protection for all headers. It avoids situations where the SNDU has to be discarded on processing the security extension header, while preceding headers have already have been evaluated. One exception is the Timestamp extension which SHOULD precede the security extension header [ID- EXT]. When applying the security services for example confidentiality, input to the cipher algorithm will cover the fields from the end of the security extension header to the end of the PDU. +-------+------+-------------------------------+------+ | ULE |SEC | Protocol Data Unit | | |Header |Header| |CRC-32| +-------+------+-------------------------------+------+ Figure 3: ULE Security Header Extension Placement A.1.3 ULE Security Databases Block There needs to be two databases i.e. similar to the IPSec databases. o ULE-SAD: ULE Secure Association Database contains all the Security Associations that are currently established with different ULE peers. o ULE-SPD: ULE Secure Policy Database contains the policies as defined by the system manager. These policies describe the security services that must be enforced The design of these two databases will be based on IPSec databases as defined in RFC4301 [RFC4301]. The exact details of the header patterns that the SPD and SAD will have to support for all use cases will be defined 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.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 Cruickshank et.al. Expires April 12, 2008 [Page 22] Internet-Draft Security Requirements for ULE April 2008 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 group member block (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 manually inserted using this interface. The following three interface functions are defined: . 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 lookup 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. To send traffic, firstly the ULE encapsulator using the ULE_Security_ID, Destination Address and possibly the PID, searches the ULE Security Database for the relevant security record. It then uses the data in the record to create the ULE security extension header. For received traffic, the ULE decapsulator on receiving Cruickshank et.al. Expires April 12, 2008 [Page 23] Internet-Draft Security Requirements for ULE April 2008 the ULE SNDU will first get the record from the Security Database using the ULE_Security_ID, the Destination Address and possibly the PID. 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 only difference between the sender and receiver is the direction of the flow of traffic: . 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 disadvantages when security functionalities are present 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 links. 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 link, 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) 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 Cruickshank et.al. Expires April 12, 2008 [Page 24] Internet-Draft Security Requirements for ULE April 2008 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 [WEIS06]. 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. 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 key and rekeying. Therefore if the key is compromised, then this will impact several ULE Receivers. Currently there are few deployed L2 security systems for MPEG-2 Cruickshank et.al. Expires April 12, 2008 [Page 25] Internet-Draft Security Requirements for ULE April 2008 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. B.3 Link security as a part of the encapsulation layer Examining the threat analysis in section 3 has shown that protection of ULE link from eavesdropping and ULE Receiver identity are major requirements. There are several major 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 [RFC4346] at L4). IPsec and TLS provide strong authentication of the end-points in the communication. L3 end-to-end security would partially deny the advantage listed just 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 end-points 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. Cruickshank et.al. Expires April 12, 2008 [Page 26] Internet-Draft Security Requirements for ULE April 2008 >>> NOTE to RFC Editor: Please remove this appendix prior to publication] Document History Working Group Draft 00 o Fixed editorial mistakes and ID style for WG adoption. Working Group Draft 01 o Fixed editorial mistakes and added an appendix which shows the preliminary framework for securing the ULE network. Working Group Draft 02 o Fixed editorial mistakes and added some important changes as pointed out by Knut Eckstein (ESA), Gorry Fairhurst and UNISAL. o Added section 4.1 on GSE. Extended the security considerations section. o Extended the appendix to show the extension header placement. o The definition of the header patterns for the ULE Security databases will be defined in a separate draft. o Need to include some words on key management transport over air interfaces, actually key management bootstrapping. Working Group Draft 03 o Fixed editorial mistakes and added some important changes as pointed out by Gorry Fairhurst. o Table 1 added in Section 6.2 to list the different security techniques to mitigate the various possible network threats. o Figure 2 modified to clearly explain the different interfaces present in the framework. Cruickshank et.al. Expires April 12, 2008 [Page 27] Internet-Draft Security Requirements for ULE April 2008 o New Section 7 has been added. o New Section 6 has been added. o The previous sections 5 and 6 have been combined to section 5. o Sections 3, 8 and 9 have been rearranged and updated with comments and suggestions from Michael Noisternig from University of Salzburg. o The Authors and the Acknowledgments section have been updated. Working Group Draft 04 o Fixed editorial mistakes and added some important changes as pointed out by DVB-GBS group, Gorry Fairhurst and Laurence Duquerroy. o Table 1 modified to have consistent use of Security Services. o Text modified to be consistent with the draft-ietf-ipdvb-ule- ext-04.txt Working Group Draft 06 o Fixed editorial mistakes and added some important changes as pointed out by Pat Cain and Gorry Fairhurst. o Figure 1 modified to have consistent use of Security Services. o Text modified in Section 4 to clearly state the requirements. o Moved Section 5 to the Appendix B o Updated IANA consideration section o Numbered the different requirements and cross referenced them within the text. Cruickshank et.al. Expires April 12, 2008 [Page 28]