idnits 2.17.1 draft-ietf-ipdvb-sec-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 895. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ISO-MPEG2], [RFC4326]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Unrecognized Status in '', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2007) is 6265 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE-802.2' is mentioned on line 170, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-MPEG2' -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) -- No information found for draft-fairhurst-ipdvb-ule-ext-xx - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H.Cruickshank 3 Internet Draft S. Iyengar 4 draft-ietf-ipdvb-sec-req-01.txt University of Surrey, UK 5 L. Duquerroy 6 Alcatel Alenia Space, France 7 Expires: September 2, 2007 P. Pillai 8 University of Bradford, UK 9 Category: WG Draft intended for PS March 2, 2007 11 Security requirements for the Unidirectional Lightweight 12 Encapsulation (ULE) protocol 13 draft-ietf-ipdvb-sec-req-01.txt 15 Status of this Draft 17 By submitting this Internet-Draft, each author represents that 18 any applicable patent or other IPR claims of which he or she is 19 aware have been or will be disclosed, and any of which he or she 20 becomes aware will be disclosed, in accordance with Section 6 of 21 BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on September 2, 2007. 42 Abstract 44 The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a 45 range of transmission methods for a range of services. This 46 document provides a threat analysis and derives the security 47 requirements when using the Transport Stream, TS, to support an 48 Internet network-layer using Unidirectional Lightweight 49 Encapsulation (ULE) [RFC4326]. The document also provides the 50 motivation for link-level security for a ULE Stream. A ULE Stream 51 may be used to send IPv4 packets, IPv6 packets, and other 52 Protocol Data Units (PDUs) to an arbitrarily large number of 53 Receivers supporting unicast and/or multicast transmission. 55 Table of Contents 57 1. Introduction..............................................2 58 2. Requirements notation......................................4 59 3. Threat Analysis...........................................6 60 3.1. System Components.....................................6 61 Figure 1: An example configuration for a unidirectional........6 62 Service for IP transport over MPEG-2 [RFC4259]................6 63 3.2. Threats..............................................8 64 3.3. Threat Scenarios......................................9 65 4. Security Requirements for IP over MPEG-2 TS...............11 66 5. IPsec and MPEG-2 Transmission Networks....................12 67 6. Motivation for ULE link-layer security....................13 68 6.1. Link security below the Encapsulation layer..........13 69 6.2. Link security as a part of the Encapsulation layer....14 70 7. Summary..................................................15 71 8. Security Considerations...................................15 72 9. IANA Considerations......................................16 73 10. Acknowledgments.........................................16 74 11. References..............................................16 75 11.1. Normative References................................16 76 11.2. Informative References..............................16 77 Author's Addresses..........................................18 78 Intellectual Property Statement..............................19 79 Disclaimer of Validity.............Error! Bookmark not defined. 80 Copyright Statement................Error! Bookmark not defined. 81 Document History............................................20 82 Appendix A: ULE Security Framework...........................22 84 1. Introduction 86 The MPEG-2 Transport Stream (TS) has been widely accepted not 87 only for providing digital TV services, but also as a subnetwork 88 technology for building IP networks. RFC 4326 [RFC4326] describes 89 the Unidirectional Lightweight Encapsulation (ULE) mechanism for 90 the transport of IPv4 and IPv6 Datagrams and other network 91 protocol packets directly over the ISO MPEG-2 Transport Stream as 92 TS Private Data. ULE specifies a base encapsulation format and 93 supports an extension format that allows it to carry additional 94 header information to assist in network/Receiver processing. The 95 encapsulation satisfies the design and architectural requirement 96 for a lightweight encapsulation defined in RFC 4259 [RFC4259]. 98 Section 3.1 of RFC 4259 presents several topological scenarios 99 for MPEG-2 Transmission Networks. A summary of these scenarios 100 are presented below (for full detail, please refer to RFC 4259). 102 1. Broadcast TV and Radio Delivery. 104 2. Broadcast Networks used as an ISP. This resembles to scenario 105 1, but includes the provision of IP services providing access 106 to the public Internet. 108 3. Unidirectional Star IP Scenario. It utilizes a Hub station to 109 provide a data network delivering a common bit stream to 110 typically medium-sized groups of Receivers. 112 4. Datacast Overlay. It employs MPEG-2 physical and link layers 113 to provide additional connectivity such as unidirectional 114 multicast to supplement an existing IP-based Internet service. 116 5. Point-to-Point Links. 118 6. Two-Way IP Networks. This can be typically satellite-based and 119 star-based utilising a Hub station to deliver a common bit 120 stream to medium- sized groups of receivers. A bidirectional 121 service is provided over a common air-interface. 123 RFC 4259 states that ULE must be robust to errors and security 124 threats. Security must also consider both unidirectional as well 125 as bidirectional links for the scenarios mentioned above. 127 An initial analysis of the security requirements in MPEG-2 128 transmission networks is presented in the security considerations 129 section of RFC 4259. For example, when such networks are not 130 using a wireline network, the normal security issues relating to 131 the use of wireless links for transport of Internet traffic 132 should be considered [RFC3819]. 134 The security considerations of RFC 4259 recommends that any new 135 encapsulation defined by the IETF should allow Transport Stream 136 encryption and should also support optional link-level 137 authentication of the SNDU payload. In ULE [RFC4326], it is 138 suggested that this may be provided in a flexible way using 139 Extension Headers. This requires the definition of a mandatory 140 header extension, but has the advantage that it decouples 141 specification of the security functions from the encapsulation 142 functions. 144 This document extends the above analysis and derives a detailed 145 the security requirements for ULE in MPEG-2 transmission 146 networks. 148 2. Requirements notation 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 151 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in 153 RFC2119 [RFC2119]. 155 Other terms used in this document are defined below: 157 ATSC: Advanced Television Systems Committee. A framework and a 158 set of associated standards for the transmission of video, audio, 159 and data using the ISO MPEG-2 standard. 161 DVB: Digital Video Broadcast. A framework and set of associated 162 standards published by the European Telecommunications Standards 163 Institute (ETSI) for the transmission of video, audio, and data 164 using the ISO MPEG-2 Standard [ISO-MPEG2]. 166 Encapsulator: A network device that receives PDUs and formats 167 these into Payload Units (known here as SNDUs) for output as a 168 stream of TS Packets. 170 LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer 171 protocol defined by the IEEE 802 standard, which follows the 172 Ethernet Medium Access Control Header. 174 MAC: Message Authentication Code. 176 MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that 177 encapsulates PDUs, forming a DSM-CC Table Section. Each Section 178 is sent in a series of TS Packets using a single TS Logical 179 Channel. 181 MPEG-2: A set of standards specified by the Motion Picture 182 Experts Group (MPEG) and standardized by the International 183 Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T 184 (in H.222 [ITU-H222]). 186 NPA: Network Point of Attachment. In this document, refers to a 187 6-byte destination address (resembling an IEEE Medium Access 188 Control address) within the MPEG-2 transmission network that is 189 used to identify individual Receivers or groups of Receivers. 191 PDU: Protocol Data Unit. Examples of a PDU include Ethernet 192 frames, IPv4 or IPv6 datagrams, and other network packets. 194 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in 195 the header of TS Packets. This is used to identify the TS 196 Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS 197 Packets forming the parts of a Table Section, PES, or other 198 Payload Unit must all carry the same PID value. The all-zeros 199 PID 0x0000 as well as other PID values is reserved for specific 200 PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 201 indicates a Null TS Packet introduced to maintain a constant bit 202 rate of a TS Multiplex. There is no required relationship 203 between the PID values used for TS Logical Channels transmitted 204 using different TS Multiplexes. 206 Receiver: Equipment that processes the signal from a TS Multiplex 207 and performs filtering and forwarding of encapsulated PDUs to the 208 network-layer service (or bridging module when operating at the 209 link layer). 211 SI Table: Service Information Table [ISO-MPEG2]. In this 212 document, this term describes a table that is defined by another 213 standards body to convey information about the services carried 214 in a TS Multiplex. A Table may consist of one or more Table 215 Sections; however, all sections of a particular SI Table must be 216 carried over a single TS Logical Channel [ISO-MPEG2]. 218 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 219 Payload Unit. 221 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 222 MPEG-2 level using TS Packets; it represents layer 2 of the 223 ISO/OSI reference model. See also TS Logical Channel and TS 224 Multiplex. 226 TS Multiplex: In this document, this term defines a set of MPEG-2 227 TS Logical Channels sent over a single lower-layer connection. 228 This may be a common physical link (i.e., a transmission at a 229 specified symbol rate, FEC setting, and transmission frequency) 230 or an encapsulation provided by another protocol layer (e.g., 231 Ethernet, or RTP over IP). The same TS Logical Channel may be 232 repeated over more than one TS Multiplex (possibly associated 233 with a different PID value) [RFC4259]; for example, to 234 redistribute the same multicast content to two terrestrial TV 235 transmission cells. 237 TS Packet: A fixed-length 188B unit of data sent over a TS 238 Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus 239 optional overhead including an Adaptation Field, encryption 240 details, and time stamp information to synchronise a set of 241 related TS Logical Channels. 243 3. Threat Analysis 245 3.1. System Components 247 +------------+ +------------+ 248 | IP | | IP | 249 | End Host | | End Host | 250 +-----+------+ +------------+ 251 | ^ 252 +------------>+---------------+ | 253 + IP | | 254 +-------------+ Encapsulator | | 255 SI-Data | +------+--------+ | 256 +-------+-------+ |MPEG-2 TS Logical Channel | 257 | MPEG-2 | | | 258 | SI Tables | | | 259 +-------+-------+ ->+------+--------+ | 260 | -->| MPEG-2 | . . . 261 +------------>+ Multiplexor | | 262 MPEG-2 TS +------+--------+ | 263 Logical Channel |MPEG-2 TS Mux | 264 | | 265 Other ->+------+--------+ | 266 MPEG-2 -->+ MPEG-2 | | 267 TS --->+ Multiplexor | | 268 ---->+------+--------+ | 269 |MPEG-2 TS Mux | 270 | | 271 +------+--------+ +------+-----+ 272 |Physical Layer | | MPEG-2 | 273 |Modulator +---------->+ Receiver | 274 +---------------+ MPEG-2 +------------+ 275 TS Mux 276 Figure 1: An example configuration for a unidirectional 277 Service for IP transport over MPEG-2 [RFC4259]. 279 As shown in Figure 1 above (from section 3.3 of [RFC4259]), there 280 are several entities within the MPEG-2 transmission network 281 architecture. These include: 283 o ULE Encapsulation Gateways (or Encapsulator or ULE source) 284 o SI-Table signalling generator (input to the multiplexor) 286 o Receivers 288 o TS multiplexers (including re-multiplexers) 290 o Modulators 292 In an MPEG-2 network a set of signalling messages [ID-AR] may 293 need to be broadcast (e.g. by an Encapsulation Gateway or other 294 device) to form the L2 control plane. Examples of signalling 295 messages include the Program Association Table (PAT), Program Map 296 Table (PMT) and Network Information Table (NIT). In existing 297 MPEG-2 transmission networks, these messages are broadcast in the 298 clear (no encryption or integrity checks). The integrity as well 299 as authenticity of these messages is important for correct 300 working of the ULE network. Even though securing these messages 301 is an orthogonal issue, one method recently proposed [ID-EF] 302 encapsulates these messages using ULE. In such cases all the 303 security requirements of this draft apply in securing these 304 signalling messages. 306 ULE link security focuses only on the security between the ULE 307 Encapsulation Gateway (ULE source) and the Receiver. Securing the 308 ULE source and receivers eliminates the need to consider security 309 issues regarding the remaining system components, such as 310 multiplexers, re-multiplexers and modulators. 312 In a MPEG-2 TS transmission network, the originating source of TS 313 Packets is either a L2 interface device (media encoder, 314 encapsulation gateway, etc) or a L2 network device (TS 315 multiplexer, etc). These devices may, but do not necessarily, 316 have an associated IP address. In the case of an encapsulation 317 gateway (e.g. ULE sender), the device may operate at L2 or L3, 318 and is not normally the originator of an IP traffic flow, and 319 usually the IP source address of the packets that it forwards do 320 not correspond to an IP address associated with the device. When 321 authentication of the IP source is required this must be provided 322 by IPsec, TLS, etc. operating at a higher layer. 324 The TS Packets are carried to the Receiver over a physical layer 325 that usually includes Forward Error Correction (FEC) coding that 326 interleaves the bytes of several consecutive, but unrelated, TS 327 Packets. FEC coding and synchronisation processing makes 328 injection of single TS Packets very difficult. Replacement of a 329 sequence of packets is also difficult, but possible (see section 330 3.2 below). 332 A Receiver in a MPEG-2 TS transmission network needs to identify 333 a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble 334 the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 335 TS, this association is made via the Packet Identifier, PID [ISO- 336 MPEG2]. At the sender, each source associates a locally unique 337 set of PID values with each stream it originates. However, there 338 is no required relationship between the PID value used at the 339 sender and that received at the Receiver. Network devices may re- 340 number the PID values associated with one or more TS Logical 341 Channels (e.g. ULE Streams) to prevent clashes at a multiplexer 342 between input streams with the same PID carried on different 343 input multiplexes (updating entries in the PMT [ISO-MPEG2], and 344 other SI tables that reference the PID value). A device may also 345 modify and/or insert new SI data into the control plane (also 346 sent as TS Packets identified by their PID value). 348 The PID associated with an Elementary Stream can therefore be 349 modified (e.g. in some systems by reception of an updated SI 350 table, or in other systems until the next announcement/discovery 351 data is received). An attacker that is able to modify the content 352 of the received multiplex (e.g. replay data and/or control 353 information) could inject data locally into the received stream 354 with an arbitrary PID value. 356 One method to provide security is to secure the entire Stream at 357 the MPEG-2 TS level. This stream of TS Packets carried in a 358 multiplex is usually received by many Receivers. The approach is 359 well-suited to TV-transmission, data-push, etc, where the PID 360 carries one or a set of flows (e.g. video/audio Packetized 361 Elementary Stream (PES) Packets) with similar security 362 requirements. 364 Where a ULE Stream carries a set of IP traffic flows to different 365 destinations with a range of properties (multicast, unicast, 366 etc), it is often not appropriate to provide IP confidentiality 367 services for the entire ULE Stream. For many expected 368 applications of ULE, a finer-grain control is therefore required, 369 at least permitting control of data confidentiality/authorisation 370 at the level of a single MAC/NPA address. However there is only 371 one valid source of data for each MPEG-2 Elementary Stream, bound 372 to a PID value. This observation could simplify the requirement 373 for authentication of the source of a ULE Stream. 375 3.2. Threats 377 The simplest type of network threat is a passive threat. This 378 includes eavesdropping or monitoring of transmissions, with a 379 goal to obtain information that is being transmitted. In 380 broadcast networks (especially those utilising widely available 381 low-cost physical layer interfaces, such as DVB) passive threats 382 are considered the major threats. An example of such a threat is 383 an intruder monitoring the MPEG-2 transmission broadcast and then 384 extracting traffic information concerning the communication 385 between IP hosts using a link. Another example is of an intruder 386 trying to gain information about the communication parties by 387 monitoring their ULE Receiver NPA addresses; an intruder can gain 388 information by determining the layer 2 identity of the 389 communicating parties and the volume of their traffic. This is a 390 well-known issue in the security field; however it is more of a 391 problem in the case of broadcast networks such as MPEG-2 392 transmission networks because of the easy availability of 393 receiver hardware and the wide geographical span of the networks. 395 Active threats (or attacks) are, in general, more difficult to 396 implement successfully than passive threats, and usually require 397 more sophisticated resources and may require access to the 398 transmitter. Within the context of MPEG-2 transmission networks, 399 examples of active attacks are: 401 o Masquerading: An entity pretends to be a different entity. 402 This includes masquerading other users and subnetwork control 403 plane messages. 405 o Modification of messages in an unauthorised manner. 407 o Replay attacks: When an intruder sends some old (authentic) 408 messages to the Receiver. In the case of a broadcast link, 409 access to previous broadcast data is easy. 411 o Denial of Service attacks: When an entity fails to perform its 412 proper function or acts in a way that prevents other entities 413 from performing their proper functions. 415 The active threats mentioned above are major security concerns 416 for the Internet community [BELLOVIN]. Masquerading and 417 modification of IP packets are comparatively easy in an Internet 418 environment whereas such attacks are in fact much harder for 419 broadcast links. This could for instance motivate the use of 420 sequence numbers in IPsec, but not the mandatory use of them on 421 synchronous links and this is further reflected in the security 422 requirements for Case 2 and 3 in section 4 below. 424 3.3. Threat Scenarios 425 Analysing the topological scenarios for MPEG-2 Transmission 426 Networks in section 1, the security threat cases can be 427 abstracted into three cases: 429 o Case 1: Monitoring (passive threat). Here the intruder 430 monitors the ULE broadcasts to gain information about the ULE 431 data and/or tracking the communicating parties identities (by 432 monitoring the destination NPA). In this scenario, measures 433 must be taken to protect the ULE data and the identity of ULE 434 Receivers. 436 o Case 2: Local hijacking of the MPEG-TS multiplex (active 437 threat). Here an intruder is assumed to be sufficiently 438 sophisticated to over-ride the original transmission from the 439 ULE Encapsulation Gateway and deliver a modified version of 440 the MPEG-TS transmission to a single ULE Receiver or a small 441 group of Receivers (e.g. in a single company site). The MPEG 442 transmission network operator might not be aware of such 443 attacks. Measures must be taken to ensure ULE source 444 authentication and preventing replay of old messages. 446 o Case 3: Global hijacking of the MPEG-TS multiplex (active 447 threat). Here we assume an intruder is very sophisticated and 448 able to hijack the whole MPEG transmission multiplex. The 449 requirements here are similar to scenario 2. The MPEG 450 transmission network operator can usually identify such 451 attacks and may resort to some means to restore the original 452 transmission. 454 For both cases 2 and 3, there can be two sub cases: 456 o Insider attacks i.e. active attacks from adversaries in the 457 known of secret material. 459 o Outsider attacks i.e. active attacks from outside of a virtual 460 private network. 462 In terms of priority, case 1 is considered the major threat in 463 MPEG transmission systems. Case 2 is likely to a lesser degree 464 within certain network configurations, especially when there are 465 insider attacks. Hence, protection against such active actives 466 should be used only when such a threat is a real possibility. 467 Case 3 is envisaged to be less practical, because it will be very 468 difficult to pass unnoticed by the MPEG transmission operator. It 469 will require restoration of the original transmission. The 470 assumption being here is that physical access to the network 471 components (multiplexors, etc) and/or connecting physical media 472 is secure. Therefore case 3 is not considered further in this 473 document. 475 4. Security Requirements for IP over MPEG-2 TS 477 From the threat analysis in section 3, the following security 478 requirements can be derived: 480 o Data confidentiality is the major requirement to mitigate 481 passive threats in MPEG-2 broadcast networks. 483 o Protection of Layer 2 NPA address. In broadcast networks this 484 protection can be used to prevent an intruder tracking the 485 identity of ULE Receivers and the volume of their traffic. 487 o Integrity protection and authentication of the ULE source is 488 required against active attacks described in section 3.2. 490 o Protection against replay attacks. This is required for the 491 active attacks described in section 3.2. 493 o Layer L2 ULE Source and Receiver authentication: This is 494 normally performed during the initial key exchange and 495 authentication phase, before the ULE Receiver can join a 496 secure session with the ULE Encapsulator (ULE source). 498 Other general requirements are: 500 o Decoupling of ULE key management functions from ULE security 501 services such as encryption and source authentication. This 502 allows the independent development of both systems. 504 o Support for automated as well as manual insertion of keys and 505 policy into the relevant databases. 507 o Algorithm agility is needed. Changes in crypto algorithms, 508 hashes as they become obsolete should be updated without 509 affecting the overall security of the system. 511 o Traceability: To monitor transmission network using log files 512 to record the activities in the network and detect any 513 intrusion. 515 o Authentication of control and management messages in MPEG-2 516 transmission networks such as the SI tables (see Figure 1). 518 o Secure Policy management 519 o Compatibility with other networking functions such as NAT 520 Network Address Translation (NAT) [RFC3715] or TCP 521 acceleration can be used in a wireless broadcast networks. 523 o Compatibility and operational with ULE extension headers i.e. 524 allow encryption of a compressed SNDU payload. 526 Examining the threat cases in section 3.3, the security 527 requirements for each case can be summarised as: 529 o Case 1: Data confidentiality MUST be provided to prevent 530 monitoring of the ULE data (such as user information and IP 531 addresses). Protection of NPA addresses MUST be provided to 532 prevent tracking ULE Receivers and their communications. 534 o Case 2: In addition to case 1 requirements, new measures need 535 to be implemented such as authentication schemes using Message 536 Authentication Codes, digital signatures or TESLA [RFC4082] 537 and using sequence numbers to prevent replay attacks in terms 538 of insider attacks. In terms of outsider attacks group 539 authentication using Message Authentication Codes should 540 provide the same level of security. This will significantly 541 reduce the ability of intruders to inject their own data into 542 the MPEG-TS stream. However, scenario 2 threats apply only in 543 specific service cases and therefore source authentication and 544 protection against replay attacks are OPTIONAL. Such measures 545 incur extra link transmission and processing overheads. 547 o Case 3: The requirements here are similar to Case 2. In 548 addition, intrusion detection is also desirable by the MPEG-2 549 network operator. 551 5. IPsec and MPEG-2 Transmission Networks 553 The security architecture for the Internet Protocol [RFC4301] 554 describes security services for traffic at the IP layer. This 555 architecture primarily defines services for the Internet Protocol 556 (IP) unicast packets, as well as manually configured IP multicast 557 packets. 559 It is possible to use IPsec to secure ULE links. The major 560 advantage of IPsec is its wide implementation in IP routers and 561 hosts. IPsec in transport mode can be used for end-to-end 562 security transparently over MPEG-2 transmission links with little 563 impact. 565 In the context of MPEG-2 transmission links, if IPsec is used to 566 secure a ULE link, then the ULE Encapsulator and Receivers are 567 equivalent to the security gateways in IPsec terminology. A 568 security gateway implementation of IPsec uses tunnel mode. Such 569 usage has the following disadvantages: 571 o There is an extra transmission overhead associated with using 572 IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 574 o There is a need to protect the identity (NPA) of ULE Receivers 575 over the ULE broadcast medium; IPsec is not suitable for 576 providing this service. In addition, the interfaces of these 577 devices do not necessarily have IP addresses (they can be L2 578 devices). 580 o Multicast is considered a major service over ULE links. The 581 current IPsec specifications [RFC4301] only define a pairwise 582 tunnel between two IPsec devices with manual keying. Work is 583 in progress in defining the extra detail needed for multicast 584 and to use the tunnel mode with address preservation to allow 585 efficient multicasting. For further details refer to [WEIS06]. 587 6. Motivation for ULE link-layer security 589 Examination of the threat analysis and security requirements in 590 sections 3 and 4 has shown that there is a need to provide link- 591 layer (L2) security in MPEG-2 transmission networks employing 592 ULE. 594 ULE link security (between a ULE Encapsulation Gateway to 595 Receivers) is therefore considered an additional security 596 mechanism to IPsec, TLS, and application layer security, not a 597 replacement. It allows a network operator to provide similar 598 functions to that of IPsec [RFC4301], but in addition provides 599 MPEG-2 transmission link confidentiality and protection of ULE 600 Receiver identity (NPA). 602 A modular design to ULE Security may allow it to use and benefit 603 from IETF key management protocols, such as the Multicast 604 Security group (MSEC) GSAKMP [RFC4535] and GDOI [RFC3547] 605 protocols. This does not preclude the use of other key management 606 methods in scenarios where this is more appropriate. 608 6.1. Link security below the Encapsulation layer 610 Link layer security can be provided at the MPEG-TS level (below 611 ULE. MPEG-TS encryption encrypts all TS Packets sent with a 612 specific PID value. However, MPEG-TS may typically multiplex 613 several IP flows, belonging to different users, using a common 614 PID. Therefore all multiplexed traffic will share the same 615 security keys. 617 This has the following advantages: 619 o The bit stream sent on the broadcast network does not expose 620 any L2 or L3 headers, specifically all addresses, type fields, 621 and length fields are encrypted prior to transmission. 623 o This method does not preclude the use of IPsec, or any other 624 form of higher-layer security. 626 However it has the following disadvantages: 628 o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with 629 a matching PID, possibly including those that are not required 630 to be forwarded. Therefore it does not have the flexibility to 631 separately secure individual IP flows. 633 o ULE Receivers will have access to private traffic destined to 634 other ULE Receivers, since they share a common PID and key. 636 o Encryption of the MPE NPA address is not permitted in such 637 systems. 639 o IETF-based key management are not used in existing systems. 640 Existing access control mechanisms have limited flexibility in 641 terms of controlling the use of key and rekeying. Therefore if 642 the key is compromised, then this will impact several ULE 643 Receivers. 645 In practice there are few L2 security systems for MPEG 646 transmission networks. Conditional access for digital TV 647 broadcasting is one example. However, this approach is optimised 648 for TV services and is not well-suited to IP packet transmission. 649 Some other systems are specified in standards such as MPE [ETSI- 650 DAT], but there are currently no known implementations. 652 6.2. Link security as a part of the Encapsulation layer 654 Examining the threat analysis in section 3 has shown that 655 protection of ULE link from eavesdropping and ULE Receiver 656 identity are major requirements. 658 There are several major advantages in using ULE link level 659 security: 661 o The protection of the complete ULE Protocol Data Unit (PDU) 662 including IP addresses. The protection can be applied either 663 per IP flow or per Receiver NPA address. 665 o Ability to protect the identity of the Receiver within the 666 MPEG-2 transmission network. 668 o Efficient protection of IP multicast over ULE links. 670 o Transparency to the use of Network Address Translation (NATs) 671 [RFC3715] and TCP Performance Enhancing Proxies (PEP) 672 [RFC3135], which require the ability to inspect and modify the 673 packets sent over the ULE link. 675 This method does not preclude the use of IPsec at L3 (or TLS 676 [RFC4346] at L4). IPsec and TLS provide strong authentication of 677 the end-points in the communication. This authentication is 678 desirable in many scenarios to ensure that the correct 679 information is being exchanged between the trusted entities, 680 whereas Layer 2 methods cannot provide this guarantee. 682 IPsec /TLS also provide a proven security architecture defining 683 key exchange mechanisms and the ability to use a range of 684 cryptographic algorithms. ULE security can make use of these 685 established mechanisms and algorithms but the advantages are 686 distinct from those when using IPsec or TLS. 688 7. Summary 690 This document analyses a set of threats and security 691 requirements. It also defines the requirements for ULE security 692 and states the motivation for link security as a part of the 693 Encapsulation layer. 695 This includes a need to provide L2 encryption and ULE Receiver 696 identity protection. There is an optional requirement for L2 697 authentication and integrity assurance as well as protection 698 against insertion of old (duplicated) data into the ULE stream 699 (i.e. replay protection). This is optional because of the 700 associated overheads for the extra features and they are only 701 required for specific service cases 703 8. Security Considerations 705 Link-level (L2) encryption of IP traffic is commonly used in 706 broadcast/radio links to supplement End-to-End security (e.g. 707 provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). A 708 common objective is to provide the same level of privacy as wired 709 links. An ISP or User may also wish to provide end-to-end 710 security services to the end-users (based on well known 711 mechanisms such as IPsec or TLS). 713 This document provides a threat analysis and derives the security 714 requirements to provide optional link encryption and link-level 715 integrity / authentication of the SNDU payload. 717 9. IANA Considerations 719 This document does not define any protocol and does not require 720 any IANA assignments. 722 10. Acknowledgments 724 The authors acknowledge the help and advice from Gorry Fairhurst 725 (University of Aberdeen). The authors also acknowledge 726 contributions from Stephane Coombes (ESA) and Yim Fun Hu 727 (University of Bradford). 729 11. References 731 11.1. Normative References 733 [ISO-MPEG2] "Information technology -- generic coding of moving 734 pictures and associated audio information systems, 735 Part I", ISO 13818-1, International Standards 736 Organisation (ISO), 2000. 738 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 1997. 741 11.2. Informative References 743 [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution 744 Mechanisms for IP Datagrams over MPEG-2 Networks", 745 Work in Progress , June 2006, IETF Work in 792 Progress. 794 [RFC3715] B. Aboba and W Dixson, "IPsec-Network Address 795 Translation (NAT) Compatibility Requirements" IETF 796 RFC 3715, March 2004. 798 [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security 799 (TLS) Protocol Version 1.1", IETF RFC 4346, April 800 2006. 802 [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing 803 Proxies Intended to Mitigate Link-Related 804 Degradations", IETF RFC 3135, June 2001. 806 [RFC4301] Kent, S. and Seo K., "Security Architecture for the 807 Internet Protocol", IETF RFC 4301, December 2006. 809 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 810 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., 811 and L. Wood, "Advice for Internet Subnetwork 812 Designers", BCP 89, IETF RFC 3819, July 2004. 814 [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) 815 Protocol Architecture", IETF RFC 4251, January 2006. 817 [ID-EF] G. Fairhurst, "Extension Formats for the ULE 818 Encapsulation to support the Generic Stream 819 Encapsulation (GSE)", Work in Progress < draft- 820 fairhurst-ipdvb-ule-ext-xx.txt>. 822 Author's Addresses 824 Haitham Cruickshank 825 Centre for Communications System Research (CCSR) 826 University of Surrey 827 Guildford, Surrey, GU2 7XH 828 UK 829 Email: h.cruickshank@surrey.ac.uk 831 Sunil Iyengar 832 Centre for Communications System Research (CCSR) 833 University of Surrey 834 Guildford, Surrey, GU2 7XH 835 UK 836 Email: S.Iyengar@surrey.ac.uk 838 Laurence Duquerroy 839 Research Department/Advanced Telecom Satellite Systems 840 Alcatel Space, Toulouse 841 France 842 E-Mail: Laurence.Duquerroy@space.alcatel.fr 844 Prashant Pillai 845 Mobile and Satellite Communications Research Centre 846 School of Engineering, Design and Technology 847 University of Bradford 848 Richmond Road, Bradford BD7 1DP 849 UK 850 Email: P.Pillai@bradford.ac.uk 852 12. IPR Notices 854 Copyright (c) The IETF Trust (2007). 856 12.1. Intellectual Property Statement 858 Full Copyright Statement 860 This document is subject to the rights, licenses and restrictions 861 contained in BCP 78, and except as set forth therein, the authors 862 retain all their rights. 864 This document and the information contained herein are provided 865 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 866 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 867 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 868 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 869 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 870 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 871 FITNESS FOR A PARTICULAR PURPOSE. 873 12.2. Intellectual Property 875 The IETF takes no position regarding the validity or scope of any 876 Intellectual Property Rights or other rights that might be 877 claimed to pertain to the implementation or use of the technology 878 described in this document or the extent to which any license 879 under such rights might or might not be available; nor does it 880 represent that it has made any independent effort to identify any 881 such rights. Information on the procedures with respect to 882 rights in RFC documents can be found in BCP 78 and BCP 79. 884 Copies of IPR disclosures made to the IETF Secretariat and any 885 assurances of licenses to be made available, or the result of an 886 attempt made to obtain a general license or permission for the 887 use of such proprietary rights by implementers or users of this 888 specification can be obtained from the IETF on-line IPR 889 repository at http://www.ietf.org/ipr. 891 The IETF invites any interested party to bring to its attention 892 any copyrights, patents or patent applications, or other 893 proprietary rights that may cover technology that may be required 894 to implement this standard. Please address the information to 895 the IETF at ietf-ipr@ietf.org. 897 13. Copyright Statement 899 Copyright (C) The IETF Trust (2007). 901 >>> NOTE to RFC Editor: Please remove this appendix prior to 902 publication] 904 Document History 906 Individual Draft-ID-00 908 o This draft is intended as a study item for proposed future 909 work by the IETF in this area. 911 o Major security concerns from Steve Bellovin who also agreed 912 that Layer 2 Address hiding is a necessary security service. 914 o Motivation for security over ULE was not clear (Joerg Ott) 916 o Not sure where this was leading for Non -IP traffic and key 917 management (Margaret Wasserman). 919 o It was recommended that a separate requirements draft was 920 first needed before suggesting any solutions (Bellovin) 922 Issues to be resolved in next revision (01): 924 o Title change (inserted "security requirements " rather than 925 "security extension") 927 o Separate security requirements draft 929 o Threat Analysis 931 Individual Draft -ID-01 933 o Load of discussion on the mailing lists regarding signalling 934 traffic security and the threats involved (Gorry, Montpetit 935 and Art) 937 o Benefits of IPSec over ULE as well as the fact the document 938 was not easy to read (Gerrard Gessler and Wolfgang Fritche) 940 o What were the benefits of NPA protection? 942 o Threats in broadcast networks was raised by Gorry 944 Issues to be resolved in next revision (02): 946 o Add section 3 on threats 948 o Address Signalling threats 950 o Make the document easy to read 952 Individual Draft -ID-02 954 o Merged draft with the one proposed by Prashant and included 955 him as an author. 957 o Define the threat scenarios and the security requirement for 958 these scenarios. 960 o English fixed 962 Issues to be resolved in next revision (03): 964 o Include subsection 3.1 Threat Scenarios and the requirements 965 for these scenarios 967 o English Fixed 969 Individual Draft -ID-03 971 o Major comments and suggestions (Michael Noistering) regarding 972 authentication and integrity assurance. He also suggested that 973 the threat scenarios (section 3.2) should be expanded. 975 o Elaborate the impact of threats for IP as opposed to Layer 2 976 (Gorry Fairhurst) 978 Issues to be resolved in next revision (04): 980 o Expanded the threat scenarios. 982 o Algorithm Agility added as a requirement (gorry) 984 o Nits have been taken care of and addressed. 986 o English Fixed 987 Individual Draft -ID-04 989 o Minor comment from Michael regarding replay protection 991 o Minor comments form Gorry. 993 Issues to be resolved in next revision (05): 995 o Nits have been taken care of and addressed. 997 o English Fixed 999 Working Group Draft 00 1001 o Fixed editorial mistakes and ID style for WG adoption. 1003 Working Group Draft 01 1005 o Fixed editorial mistakes and added some changes as pointed out 1006 by Knut (ESA) and added an appendix which shows the framework 1007 for securing the ULE network. 1009 Appendix A: ULE Security Framework 1011 This section aims to define a preliminary security framework for 1012 widespread deployment of secure ULE networks. 1014 Building Blocks 1016 This ULE Security framework defines the following building blocks 1017 as shown in the figure 2 below: 1019 1. The Key Management Block 1021 2. The ULE Extension Header Block 1023 3. The ULE Databases Block 1025 +------+----------+ +---------------- 1026 | Key Management |/------------\| Key Management | 1027 | Block |\------------/| Block | 1028 | Group Member | | Group Server | 1029 +------+----------+ +---------------- 1030 | | 1031 | | 1032 | | 1033 | | 1034 | | 1035 \ / 1036 +------+----------+ 1037 | ULE | 1038 | SAD / SPD | 1039 | Interface Block | 1040 +------+-+--------+ 1041 / \ 1042 | | 1043 | | 1044 | | 1045 | | 1046 | | 1047 | | 1048 +------+-+--------+ 1049 | ULE Security | 1050 | Extension Header| 1051 | Block | 1052 +-----------------+ 1053 Figure 2: Secure ULE framework Building Blocks 1055 1. Key Management Block 1057 In order to provide security at the ULE level using extension 1058 headers, a key management framework is required. This key 1059 management framework is responsible for user authentication, 1060 access control, and Security Association negotiation (which 1061 include the negotiations of the security algorithms to be used 1062 and the generation of the different session keys as well as 1063 policy material). This Key management framework can be either 1064 automated or manual. Hence Key management client entity will be 1065 present in all ULE receivers as well as ULE sources. In some 1066 cases the ULE source could also be the Key Server Entity. Key 1067 management protocols like GSAKMP may be used or manual insertion 1068 of keying material can also be deployed. 1070 2.ULE Extension header Block 1072 A new security extension header for the ULE protocol is required 1073 to provide the security features of data confidentiality, data 1074 integrity, data authentication and mechanisms to prevent replay 1075 attacks. Security keying material will be used for the different 1076 security algorithms (for encryption/decryption, MAC generation, 1077 etc.), which are used to meet the security requirements, 1078 described in detail in Section 4 of this draft. 1080 This block will use the keying material and policy information from 1081 the ULE security database block on the ULE payload to generate the 1082 secure ULE extension Header or to decipher the secure ULE extension 1083 header to get the ULE payload. An example overview of the ULE 1084 Security extension header format along with the ULE header and 1085 payload is shown in figure 3 below. There could be other extension 1086 headers placed before or after the ULE Security Header extension 1088 +-------+------+-------------------------------+------+ 1089 | ULE |SEC | Protocol Data Unit | | 1090 |Header |Header| |CRC-32| 1091 +-------+------+-------------------------------+------+ 1092 Figure 3: ULE Sec Header extension Placement 1094 3. ULE Databases Block 1096 There needs to be two databases i.e. similar to the IPSec 1097 databases. 1099 o ULE-SAD: ULE Secure Association Database contains all the 1100 Security Associations that are currently established with 1101 different ULE peers. 1103 o ULE-SPD: ULE Secure Policy Database contains the policies as 1104 defined by the system manager. Those policies describe the 1105 security services that must be enforced 1107 The design of these two databases will be based on IPSec 1108 databases as defined in RFC4301 [RFC4301]. 1110 Interface definition 1112 Two new interfaces have to be defined between the three blocks as 1113 shown in figure 2 above. These interfaces are: 1115 o Key management <-> ULE Security databases 1117 o ULE Security databases <-> ULE interfaces 1119 While the first interface is used by the Key Management Block to 1120 insert keys, security associations and policies into the ULE 1121 Database Block, the second interface is used by the ULE Extension 1122 Header Block to get the keys and policy material for the ULE 1123 Payloads. 1125 1. Key management <-> ULE Security databases 1126 This interface is between the Key Management client block (GM 1127 client) and the ULE Security Database block. The Key management 1128 client will communicate with the GCKS and then get the relevant 1129 security information (keys, cipher mode, security service, 1130 ULE_Security_ID and other relevant keying material as well as 1131 policy) and insert this data into the ULE Security database 1132 block. The ULE Security database block holds the records of all 1133 security associations currently used as well as information for 1134 security policy control. The Key management could be either 1135 automated (GSAKMP) or manually inserted using this interface. The 1136 following three interface functions are defined: 1138 . Insert_record_database (char * Database, char * record, char * 1139 Unique_ID); 1140 . Update_record_database (char * Database, char * record, char * 1141 Unique_ID); 1142 . Delete_record_database (char * Database, char * Unique_ID); 1144 2. ULE Security databases <-> ULE interfaces 1146 This interface is between the ULE Security Database and the ULE 1147 Engine. For Outbound Traffic, firstly the ULE Engine using the 1148 Destination Address and the ULE_Security_ID searches the ULE 1149 Security Database for the relevant security record. It then uses 1150 the record data to create the ULE security extension header 1151 [ref]. For inbound traffic, the ULE engine on receiving the ULE 1152 packet will first get the record from the Security Database using 1153 the Destination Address and the ULE_Security_ID. It then uses 1154 this information to decrypt the ULE extension header. 1156 In both cases only one interface is needed: 1158 . Get_record_database (char * Database, char * record, char * 1159 Unique_ID);