idnits 2.17.1 draft-ietf-ipdvb-sec-req-07.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 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPDVB Working Group H. Cruickshank 2 Internet-Draft University of Surrey, UK 3 Intended status: Informational P. Pillai 4 Expires: Dec 16, 2008 University of Bradford, UK 5 Michael Noisternig 6 University of Salzburg, Austria 7 S. Iyengar 8 Logica, UK 9 17 June, 2008 11 Security requirements for the Unidirectional Lightweight 12 Encapsulation (ULE) protocol 13 draft-ietf-ipdvb-sec-req-07.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 December 17, 2008. 42 Abstract 44 The MPEG-2 standard defined by ISO 13818-1 supports a range of 45 transmission methods for a range of services. This document 46 provides a threat analysis and derives the security requirements 47 when using the Transport Stream, TS, to support an Internet 48 network-layer using Unidirectional Lightweight Encapsulation 49 (ULE) defined in RFC4326. The document also provides the 50 motivation for link-layer 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 The analysis also describes applicability to the Generic Stream 56 Encapsulation (GSE) defined by the Digital Video Broadcasting 57 (DVB) Project. 59 Table of Contents 61 1. Introduction .............................................. 2 62 2. Requirements notation ..................................... 4 63 3. Threat Analysis ........................................... 6 64 3.1. System Components .................................... 6 65 3.2. Threats .............................................. 9 66 3.3. Threat cases ........................................ 10 67 4. Security Requirements for IP over MPEG-2 TS............... 11 68 5. Design recommendations for ULE Security Extension Header . 14 69 6. Compatibility with Generic Stream Encapsulation .......... 14 70 7. Summary .................................................. 14 71 8. Security Considerations .................................. 16 72 9. IANA Considerations ...................................... 16 73 10. Acknowledgments ......................................... 16 74 11. References .............................................. 16 75 11.1. Normative References ............................... 16 76 11.2. Informative References ............................. 17 77 12. Author's Addresses ...................................... 19 78 13. IPR Notices ............................................. 19 79 13.1. Intellectual Property Statement .................... 19 80 14. Copyright Statement...................................... 20 81 Appendix A: ULE Security Framework .......................... 20 82 Appendix B: Motivation for ULE link-layer security .......... 24 83 Document History ............................................ 27 85 1. Introduction 87 The MPEG-2 Transport Stream (TS) has been widely accepted not 88 only for providing digital TV services, but also as a subnetwork 89 technology for building IP networks. RFC 4326 [RFC4326] describes 90 the Unidirectional Lightweight Encapsulation (ULE) mechanism for 91 the transport of IPv4 and IPv6 Datagrams and other network 92 protocol packets directly over the ISO MPEG-2 Transport Stream as 93 TS Private Data. ULE specifies a base encapsulation format and 94 supports an Extension Header format that allows it to carry 95 additional header information to assist in network/Receiver 96 processing. The encapsulation satisfies the design and 97 architectural requirement for a lightweight encapsulation defined 98 in RFC 4259 [RFC4259]. 99 Section 3.1 of RFC 4259 presents several topological scenarios 100 for MPEG-2 Transmission Networks. A summary of these scenarios 101 are presented below (for full detail, please refer to RFC 4259): 103 A. Broadcast TV and Radio Delivery. 105 B. Broadcast Networks used as an ISP. This resembles to scenario 106 1, but includes the provision of IP services providing access 107 to the public Internet. 109 C. Unidirectional Star IP Scenario. It utilizes a Hub station to 110 provide a data network delivering a common bit stream to 111 typically medium-sized groups of Receivers. 113 D. Datacast Overlay. It employs MPEG-2 physical and link layers 114 to provide additional connectivity such as unidirectional 115 multicast to supplement an existing IP-based Internet service. 117 E. Point-to-Point Links. This connectivity may be provided using 118 a pair of transmit and receive interfaces. 120 F. Two-Way IP Networks. This can be (for example) satellite-based 121 and star-based utilising a Hub station to deliver a common bit 122 stream to medium-sized groups of Receivers. A bidirectional 123 service is provided over a common air-interface. 125 RFC 4259 states that ULE must be robust to errors and security 126 threats. Security must also consider both unidirectional (A, B, C 127 and D) as well as bidirectional (E and F) links for the scenarios 128 mentioned above. 130 An initial analysis of the security requirements in MPEG-2 131 transmission networks is presented in the security considerations 132 section of RFC 4259. For example, when such networks are not 133 using a wireline network, the normal security issues relating to 134 the use of wireless links for transport of Internet traffic 135 should be considered [RFC3819]. 137 The security considerations of RFC 4259 recommends that any new 138 encapsulation defined by the IETF should allow Transport Stream 139 encryption and should also support optional link-layer 140 authentication of the SNDU payload. In ULE [RFC4326], it is 141 suggested that this may be provided in a flexible way using 142 Extension Headers. This requires the definition of a mandatory 143 Extension Header, but has the advantage that it decouples 144 specification of the security functions from the encapsulation 145 functions. 147 This document extends the above analysis and derives a detailed 148 the security requirements for ULE in MPEG-2 transmission 149 networks. 151 A security framework for deployment of secure ULE networks 152 describing the different building blocks and the interface 153 definitions is presented in Appendix A. 155 2. Requirements notation 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 158 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in 160 RFC2119 [RFC2119]. 162 Other terms used in this document are defined below: 164 ATSC: Advanced Television Systems Committee. A framework and a 165 set of associated standards for the transmission of video, audio, 166 and data using the ISO MPEG-2 standard. 168 DVB: Digital Video Broadcast. A framework and set of associated 169 standards published by the European Telecommunications Standards 170 Institute (ETSI) for the transmission of video, audio, and data 171 using the ISO MPEG-2 Standard [ISO-MPEG2]. 173 Encapsulator: A network device that receives PDUs and formats 174 these into Payload Units (known here as SNDUs) for output as a 175 stream of TS Packets. 177 LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer 178 protocol defined by the IEEE 802 standard, which follows the 179 Ethernet Medium Access Control Header. 181 MAC: Message Authentication Code. 183 MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that 184 encapsulates PDUs, forming a DSM-CC Table Section. Each Section 185 is sent in a series of TS Packets using a single TS Logical 186 Channel. 188 MPEG-2: A set of standards specified by the Motion Picture 189 Experts Group (MPEG) and standardized by the International 190 Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T 191 (in H.222 [ITU-H222]). 193 NPA: Network Point of Attachment. In this document, refers to a 194 6-byte destination address (resembling an IEEE Medium Access 195 Control address) within the MPEG-2 transmission network that is 196 used to identify individual Receivers or groups of Receivers. 198 PDU: Protocol Data Unit. Examples of a PDU include Ethernet 199 frames, IPv4 or IPv6 datagrams, and other network packets. 201 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in 202 the header of TS Packets. This is used to identify the TS 203 Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS 204 Packets forming the parts of a Table Section, PES, or other 205 Payload Unit must all carry the same PID value. The all-zeros 206 PID 0x0000 as well as other PID values is reserved for specific 207 PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 208 indicates a Null TS Packet introduced to maintain a constant bit 209 rate of a TS Multiplex. There is no required relationship 210 between the PID values used for TS Logical Channels transmitted 211 using different TS Multiplexes. 213 Receiver: Equipment that processes the signal from a TS Multiplex 214 and performs filtering and forwarding of encapsulated PDUs to the 215 network-layer service (or bridging module when operating at the 216 link layer). 218 SI Table: Service Information Table [ISO-MPEG2]. In this 219 document, this term describes a table that is defined by another 220 standards body to convey information about the services carried 221 in a TS Multiplex. A Table may consist of one or more Table 222 Sections; however, all sections of a particular SI Table must be 223 carried over a single TS Logical Channel [ISO-MPEG2]. 225 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 226 Payload Unit. 228 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 229 MPEG-2 layer using TS Packets; it represents layer 2 of the 230 ISO/OSI reference model. See also TS Logical Channel and TS 231 Multiplex. 233 TS Multiplex: In this document, this term defines a set of MPEG-2 234 TS Logical Channels sent over a single lower-layer connection. 235 This may be a common physical link (i.e., a transmission at a 236 specified symbol rate, FEC setting, and transmission frequency) 237 or an encapsulation provided by another protocol layer (e.g., 238 Ethernet, or RTP over IP). The same TS Logical Channel may be 239 repeated over more than one TS Multiplex (possibly associated 240 with a different PID value) [RFC4259]; for example, to 241 redistribute the same multicast content to two terrestrial TV 242 transmission cells. 244 TS Packet: A fixed-length 188B unit of data sent over a TS 245 Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus 246 optional overhead including an Adaptation Field, encryption 247 details, and time stamp information to synchronise a set of 248 related TS Logical Channels. 250 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE 251 encapsulated PDUs. ULE Streams may be identified by definition of 252 a stream_type in SI/PSI [ISO-MPEG2]. 254 3. Threat Analysis 256 3.1. System Components 258 +------------+ +------------+ 259 | IP | | IP | 260 | End Host | | End Host | 261 +-----+------+ +------------+ 262 | ^ 263 +------------>+---------------+ | 264 + ULE | | 265 +-------------+ Encapsulator | | 266 SI-Data | +------+--------+ | 267 +-------+-------+ |MPEG-2 TS Logical Channel | 268 | MPEG-2 | | | 269 | SI Tables | | | 270 +-------+-------+ ->+------+--------+ | 271 | -->| MPEG-2 | . . . 272 +------------>+ Multiplexer | | 273 MPEG-2 TS +------+--------+ | 274 Logical Channel |MPEG-2 TS Mux | 275 | | 276 Other ->+------+--------+ | 277 MPEG-2 -->+ MPEG-2 | | 278 TS --->+ Multiplexer | | 279 ---->+------+--------+ | 280 |MPEG-2 TS Mux | 281 | | 282 +------+--------+ +------+-----+ 283 |Physical Layer | | MPEG-2 | 284 |Modulator +---------->+ Receiver | 285 +---------------+ MPEG-2 +------------+ 286 TS Mux 287 Figure 1: An example configuration for a unidirectional service 288 for IP transport over MPEG-2 (adapted from [RFC4259]). 290 As shown in Figure 1 above (from section 3.3 of [RFC4259]), there 291 are several entities within the MPEG-2 transmission network 292 architecture. These include: 294 o ULE Encapsulation Gateways (the ULE Encapsulator) 296 o SI-Table signalling generator (input to the multiplexer) 298 o Receivers (the end points for ULE streams) 300 o TS multiplexers (including re-multiplexers) 302 o Modulators 304 In an MPEG-2 TS transmission network, the originating source of 305 TS Packets is either a Layer 2 (L2) interface device (media 306 encoder, encapsulation gateway, etc) or a L2 network device (TS 307 multiplexer, etc). These devices may, but do not necessarily, 308 have an associated IP address. In the case of an encapsulation 309 gateway (e.g. ULE sender), the device may operate at L2 or Layer 310 3 (L3), and is not normally the originator of an IP traffic flow, 311 and usually the IP source address of the packets that it forwards 312 does not correspond to an IP address associated with the device. 314 The TS Packets are carried to the Receiver over a physical layer 315 that usually includes Forward Error Correction (FEC) coding that 316 interleaves the bytes of several consecutive, but unrelated, TS 317 Packets. FEC-coding and synchronisation processing makes 318 injection of single TS Packets very difficult. Replacement of a 319 sequence of packets is also difficult, but possible (see section 320 3.2). 322 A Receiver in an MPEG-2 TS transmission network needs to identify 323 a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble 324 the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 325 TS, this association is made via the Packet Identifier, PID [ISO- 326 MPEG2]. At the sender, each source associates a locally unique 327 set of PID values with each stream it originates. However, there 328 is no required relationship between the PID value used at the 329 sender and that received at the Receiver. Network devices may re- 330 number the PID values associated with one or more TS Logical 331 Channels (e.g. ULE Streams) to prevent clashes at a multiplexer 332 between input streams with the same PID carried on different 333 input multiplexes (updating entries in the PMT [ISO-MPEG2], and 334 other SI tables that reference the PID value). A device may also 335 modify and/or insert new SI data into the control plane (also 336 sent as TS Packets identified by their PID value). However, there 337 is only one valid source of data for each MPEG-2 Elementary 338 Stream, bound to a PID value. (This observation could simplify 339 the requirement for authentication of the source of a ULE 340 Stream.) 342 In an MPEG-2 network a set of signalling messages [RFC4947] may 343 need to be broadcast (e.g. by an Encapsulation Gateway or other 344 device) to form the L2 control plane. Examples of signalling 345 messages include the Program Association Table (PAT), Program Map 346 Table (PMT) and Network Information Table (NIT). In existing 347 MPEG-2 transmission networks, these messages are broadcast in the 348 clear (no encryption or integrity checks). The integrity as well 349 as authenticity of these messages is important for correct 350 working of the ULE network, i.e. supporting its security 351 objectives in the area of availability, in addition to 352 confidentiality and integrity. One method recently proposed 353 [RFC5163] encapsulates these messages using ULE. In such cases 354 all the security requirements of this document apply in securing 355 these signalling messages. 357 ULE Stream security only concerns the security between the ULE 358 Encapsulation Gateway (ULE Encapsulator) and the Receiver. In 359 many deployment scenarios the user of a ULE Stream has to secure 360 communications beyond the link since other network links are 361 utilised in addition to the ULE link. Therefore, if 362 authentication of the end-points, i.e. the IP Sources is 363 required, or users are concerned about loss of confidentiality, 364 integrity, or authenticity of their communication data, they will 365 have to employ end-to-end network security mechanisms, e.g. IPsec 366 or Transport Layer Security (TLS). Governmental users may be 367 forced by regulations to employ specific, approved 368 implementations of those mechanisms. Hence for such cases, the 369 requirements for confidentiality and integrity of the user data 370 will be met by the end-to-end security mechanism and the ULE 371 security measures would focus on either providing traffic flow 372 confidentiality for user data that has already been encrypted or 373 for users who choose not to implement end-to-end security 374 mechanisms. 376 ULE links may also be used for communications where the two IP 377 end-points are not under central control (e.g., when browsing a 378 public web site). In these cases, it may be impossible to enforce 379 any end-to-end security mechanisms. Yet, a common objective is 380 that users may make the same security assumptions as for wired 381 links [RFC3819]. ULE security could achieve this by protecting 382 the vulnerable (in terms of passive attacks) ULE Stream. 384 In contrast to the above, a ULE Stream can be used to link 385 networks such as branch offices to a central office. ULE link- 386 layer security could be the sole provider of confidentiality and 387 integrity. In this scenario, users requiring high assurance of 388 security (e.g. government use) will need to employ approved 389 cryptographic equipment (e.g. at the network layer). An 390 implementation of ULE Link Security equipment could also be 391 certified for use by specific user communities. 393 3.2. Threats 395 The simplest type of network threat is a passive threat. This 396 includes eavesdropping or monitoring of transmissions, with a 397 goal to obtain information that is being transmitted. In 398 broadcast networks (especially those utilising widely available 399 low-cost physical layer interfaces, such as DVB) passive threats 400 are the major threats. One example is an intruder monitoring the 401 MPEG-2 transmission broadcast and then extracting the data 402 carried within the link. Another example is of an intruder trying 403 to determine the identity of the communicating parties and the 404 volume of their traffic by sniffing (L2) addresses. This is a 405 well-known issue in the security field; however it is more of a 406 problem in the case of broadcast networks such as MPEG-2 407 transmission networks because of the easy availability of 408 Receiver hardware and the wide geographical span of the networks. 410 Active threats (or attacks) are, in general, more difficult to 411 implement successfully than passive threats, and usually require 412 more sophisticated resources and may require access to the 413 transmitter. Within the context of MPEG-2 transmission networks, 414 examples of active attacks are: 416 o Masquerading: An entity pretends to be a different entity. 417 This includes masquerading other users and subnetwork control 418 plane messages. 420 o Modification of messages in an unauthorised manner. 422 o Replay attacks: When an intruder sends some old (authentic) 423 messages to the Receiver. In the case of a broadcast link, 424 access to previous broadcast data is easy. 426 o Denial-of-Service (DoS) attacks: When an entity fails to 427 perform its proper function or acts in a way that prevents 428 other entities from performing their proper functions. 430 The active threats mentioned above are major security concerns 431 for the Internet community [BELLOVIN]. Masquerading and 432 modification of IP packets are comparatively easy in an Internet 433 environment, whereas such attacks are in fact much harder for 434 MPEG-2 broadcast links. This could for instance motivate the 435 mandatory use of sequence numbers in IPsec, but not for 436 synchronous links. This is further reflected in the security 437 requirements for Case 2 and 3 in section 4 below. 439 As explained in section 3.1, the PID associated with an 440 Elementary Stream can be modified (e.g. in some systems by 441 reception of an updated SI table, or in other systems until the 442 next announcement/discovery data is received). An attacker that 443 is able to modify the content of the received multiplex (e.g. 444 replay data and/or control information) could inject data locally 445 into the received stream with an arbitrary PID value. 447 3.3. Threat cases 449 Analysing the topological scenarios for MPEG-2 Transmission 450 Networks in section 1, the security threats can be abstracted 451 into three cases: 453 o Case 1: Monitoring (passive threat). Here the intruder 454 monitors the ULE broadcasts to gain information about the ULE 455 data and/or tracking the communicating parties identities (by 456 monitoring the destination NPA). In this scenario, measures 457 must be taken to protect the ULE payload data and the identity 458 of ULE Receivers. 460 o Case 2: Locally conduct active attacks on the MPEG-TS 461 multiplex. Here an intruder is assumed to be sufficiently 462 sophisticated to over-ride the original transmission from the 463 ULE Encapsulation Gateway and deliver a modified version of 464 the MPEG-TS transmission to a single ULE Receiver or a small 465 group of Receivers (e.g. in a single company site). The MPEG-2 466 transmission network operator might not be aware of such 467 attacks. Measures must be taken to ensure ULE data integrity 468 and authenticity and preventing replay of old messages. 470 o Case 3: Globally conduct active attacks on the MPEG-TS 471 multiplex. Here we assume an intruder is very sophisticated 472 and able to over-ride the whole MPEG-2 transmission multiplex. 474 The requirements here are similar to scenario 2. The MPEG-2 475 transmission network operator can usually identify such 476 attacks and may resort to some means to restore the original 477 transmission. 479 For both cases 2 and 3, there can be two sub-cases: 481 o Insider attacks, i.e. active attacks from adversaries within 482 the network with knowledge of the secret material. 484 o Outsider attacks, i.e. active attacks from outside of a 485 virtual private network. 487 In terms of priority, case 1 is considered the major threat in 488 MPEG-2 transmission systems. Case 2 is likely to a lesser degree 489 within certain network configurations, especially when there are 490 insider attacks. Hence, protection against such active attacks 491 should be used only when such a threat is a real possibility. 492 Case 3 is envisaged to be less practical, because it will be very 493 difficult to pass unnoticed by the MPEG-2 transmission operator. 494 It will require restoration of the original transmission. The 495 assumption being here is that physical access to the network 496 components (multiplexers, etc) and/or connecting physical media 497 is secure. Therefore case 3 is not considered further in this 498 document. 500 4. Security Requirements for IP over MPEG-2 TS 502 From the threat analysis in section 3, the following security 503 requirements can be derived: 505 Req 1. Data confidentiality MUST be provided by a link that 506 supports ULE Stream Security to prevent passive attacks and 507 reduce the risk of active threats. 509 Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast 510 networks this protection can be used to prevent an intruder 511 tracking the identity of ULE Receivers and the volume of their 512 traffic. 514 Req 3. Integrity protection and source authentication of ULE 515 Stream data are OPTIONAL. These can be used to prevent active 516 attacks described in section 3.2. 518 Req 4. Protection against replay attacks is OPTIONAL. This is 519 required for the active attacks described in section 3.2. 521 Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. 522 This can be performed during the initial key exchange and 523 authentication phase, before the ULE Receiver can join a 524 secure session with the ULE Encapsulator (ULE source). This 525 could be either unidirectional or bidirectional authentication 526 based on the underlying key management protocol. 528 Other general requirements for all threat cases for link-layer 529 security are: 531 GReq (a) ULE key management functions MUST be decoupled from ULE 532 security services such as encryption and source authentication. 533 This allows the independent development of both systems. 535 GReq (b) Support SHOULD be provided for automated as well as 536 manual insertion of keys and policy into the relevant 537 databases. 539 GReq (c) Algorithm agility MUST be supported. Changes in crypto 540 algorithms, hashes as they become obsolete should be updated 541 without affecting the overall security of the system. 543 GReq (d) The security extension header MUST be compatible with 544 other ULE extension headers. There could be other extension 545 headers (either mandatory or optional). It is RECOMMENDED that 546 these are placed after the security extension header. This 547 permits full protection for all headers. It also avoids 548 situations where the SNDU has to be discarded on processing the 549 security extension header, while preceding headers have already 550 been evaluated. One exception is the Timestamp extension which 551 SHOULD precede the security extension header [RFC5163]. In this 552 case, the timestamp will be unaffected by security services 553 such as data confidentiality and can be decoded without the 554 need for key material. 556 Examining the threat cases in section 3.3, the security 557 requirements for each case can be summarised as: 559 o Case 1: Data confidentiality (Req 1) MUST be provided to 560 prevent monitoring of the ULE data (such as user information 561 and IP addresses). Protection of NPA addresses (Req 2) MAY be 562 provided to prevent tracking ULE Receivers and their 563 communications. 565 o Case 2: In addition to case 1 requirements, new measures MAY 566 be implemented such as authentication schemes using Message 567 Authentication Codes, digital signatures, or TESLA [RFC4082] 568 in order to provide integrity protection and source 569 authentication (Req 2, Req 3 and Req 5). In addition, sequence 570 numbers (Req 4) MAY be used to protect against replay attacks. 571 In terms of outsider attacks, group authentication using 572 Message Authentication Codes should provide the same level of 573 security (Req 3 and 5). This will significantly reduce the 574 ability of intruders to successfully inject their own data 575 into the MPEG-TS stream. However, scenario 2 threats apply 576 only in specific service cases, and therefore authentication 577 and protection against replay attacks are OPTIONAL. Such 578 measures incur additional transmission as well as processing 579 overheads. Moreover, intrusion detection systems may also be 580 needed by the MPEG-2 network operator. These should best be 581 coupled with perimeter security policy to monitor common DoS 582 attacks. 584 o Case 3: As stated in section 3.3. the requirements here are 585 similar to Case 2 but since the MPEG-2 transmission network 586 operator can usually identify such attacks the constraints on 587 intrusion detections are less than in case 2. 589 Table 1 below shows the threats that are applicable to ULE 590 networks, and the relevant security mechanisms to mitigate those 591 threats. 593 Mitigation of Threat 594 ----------------------------------------------- 595 |Data |Data |Source |Data |Intru |Iden | 596 |Privacy |fresh |Authent|Integ |sion |tity | 597 | |ness |ication|rity |Dete |Prote | 598 | | | | |ction |ction | 599 Attack | | | | | | | 600 ---------------|--------|-------|-------|-------|-------|------| 601 | Monitoring | X | - | - | - | - | X | 602 |---------------------------------------------------------------| 603 | Masquerading | X | - | X | X | - | X | 604 |---------------------------------------------------------------| 605 | Replay Attacks| - | X | X | X | X | - | 606 |---------------------------------------------------------------| 607 | DoS Attacks | - | X | X | X | X | - | 608 |---------------------------------------------------------------| 609 | Modification | - | - | X | X | X | - | 610 | of Messages | | | | | | | 611 --------------------------------------------------------------- 612 Table 1: Security techniques to mitigate network threats 613 in ULE Networks. 615 5. Design recommendations for ULE Security Extension Header 617 Table 1 may assist in selecting fields within a ULE Security 618 Extension Header framework. 620 Security services may be grouped into profiles based on security 621 requirements, e.g. a base profile (with payload encryption and 622 identity protection), and a second profile that extends this to 623 also provide source authentication and protection against replay 624 attacks. 626 A modular design of ULE security may allow it to use and benefit 627 from existing key management protocols, such as GSAKMP [RFC4535] 628 and GDOI [RFC3547] defined by the IETF Multicast Security (MSEC) 629 working group. This does not preclude the use of other key 630 management methods in scenarios where this is more appropriate. 632 IPsec and TLS also provide a proven security architecture 633 defining key exchange mechanisms and the ability to use a range 634 of cryptographic algorithms. ULE security can make use of these 635 established mechanisms and algorithms. 637 6. Compatibility with Generic Stream Encapsulation 639 The [RFC5163] document describes three new Extension Headers that 640 may be used with Unidirectional Link Encapsulation, ULE, 641 [RFC4326] and the Generic Stream Encapsulation (GSE) that has 642 been designed for the Generic Mode (also known as the Generic 643 Stream (GS)), offered by second-generation DVB physical layers 644 [GSE]. 646 The security threats and requirement presented in this document 647 are applicable to ULE and GSE encapsulations. 649 7. Summary 651 This document analyses a set of threats and security 652 requirements. It defines the requirements for ULE security and 653 states the motivation for link security as a part of the 654 Encapsulation layer. 656 ULE security must provide link-layer encryption and ULE Receiver 657 identity protection. The framework must support the optional 658 ability to provide for link-layer authentication and integrity 659 assurance, as well as protection against insertion of old 660 (duplicated) data into the ULE stream (i.e. replay protection). 661 This set of features is optional to reduce encapsulation overhead 662 when not required. 664 ULE stream security between a ULE Encapsulation Gateway and the 665 corresponding Receiver(s) is considered an additional security 666 mechanism to IPsec, TLS, and application layer end-to-end 667 security, and not as a replacement. It allows a network operator 668 to provide similar functions to that of IPsec, but in addition 669 provides MPEG-2 transmission link confidentiality and protection 670 of ULE Receiver identity (NPA). 672 Annexe 1 describes a set of building blocks that may be used to 673 realise a framework that provides ULE security functions. 675 8. Security Considerations 677 Link-layer (L2) encryption of IP traffic is commonly used in 678 broadcast/radio links to supplement end-to-end security (e.g. 679 provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). 681 A common objective is to provide the same level of privacy as 682 wired links. It is recommended that an ISP or user provide end- 683 to-end security services based on well known mechanisms such as 684 IPsec or TLS. 686 This document provides a threat analysis and derives the security 687 requirements to provide link encryption and optional link-layer 688 integrity / authentication of the SNDU payload. 690 There are some security issues that were raised in RFC 4326 691 [RFC4326] that are not addressed in this document (i.e. are out 692 of scope), e.g.: 694 o The security issue with un-initialised stuffing bytes. In ULE, 695 these bytes are set to 0xFF (normal practice in MPEG-2). 697 o Integrity issues related to the removal of the LAN FCS in a 698 bridged networking environment. The removal for bridged frames 699 exposes the traffic to potentially undetected corruption while 700 being processed by the Encapsulator and/or Receiver. 702 o There is a potential security issue when a Receiver receives a 703 PDU with two Length fields: The Receiver would need to 704 validate the actual length and the Length field and ensure 705 that inconsistent values are not propagated by the network. 707 9. IANA Considerations 709 There are no IANA actions defined in this document. 711 10. Acknowledgments 713 The authors acknowledge the help and advice from Gorry Fairhurst 714 (University of Aberdeen). The authors also acknowledge 715 contributions from Laurence Duquerroy and Stephane Coombes (ESA), 716 and Yim Fun Hu (University of Bradford). 718 11. References 720 11.1. Normative References 722 [ISO-MPEG2] "Information technology -- generic coding of moving 723 pictures and associated audio information systems, 724 Part I", ISO 13818-1, International Standards 725 Organisation (ISO), 2000. 727 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, 1997. 730 [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional 731 Lightweight Encapsulation (ULE) for Transmission of 732 IP Datagrams over an MPEG-2 Transport Stream (TS)", 733 IETF RFC 4326, December 2005. 735 11.2. Informative References 737 [RFC4947] G. Fairhurst, M.-J. Montpetit, "Address Resolution 738 Mechanisms for IP Datagrams over MPEG-2 Networks", 739 IETF RFC 4947, July 2007. 741 [RFC5163] G. Fairhurst and B. Collini-Nocker, "Extension Header 742 formats for Unidirectional Lightweight Encapsulation 743 (ULE) and the Generic Stream Encapsulation (GSE)", 744 IETF RFC 5163, April 2008. 746 [IEEE-802] "Local and metropolitan area networks-Specific 747 requirements Part 2: Logical Link Control", IEEE 748 802.2, IEEE Computer Society, (also ISO/IEC 8802-2), 749 1998. 751 [ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International 752 Standards Organisation (ISO), 1998. 754 [ITU-H222] H.222.0, "Information technology, Generic coding of 755 moving pictures and associated audio information 756 Systems", International Telecommunication Union, 757 (ITU-T), 1995. 759 [RFC4259] M.-J. Montpetit, G. Fairhurst, H. Clausen, B. 760 Collini-Nocker, and H. Linder, "A Framework for 761 Transmission of IP Datagrams over MPEG-2 Networks", 762 IETF RFC 4259, November 2005. 764 [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB 765 Specifications for Data Broadcasting", European 766 Telecommunications Standards Institute (ETSI). 768 [BELLOVIN] S. Bellovin, "Problem Area for the IP Security 769 protocols", Computer Communications Review 2:19, pp. 770 32-48, April 989. http://www.cs.columbia.edu/~smb/ 772 [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic 773 Stream Encapsulation (GSE) Protocol, "European 774 Telecommunication Standards, Institute (ETSI), 2007. 776 [RFC4082] A. Perrig, D. Song, " Timed Efficient Stream Loss- 777 Tolerant Authentication (TESLA): Multicast Source 778 Authentication Transform Introduction", IETF RFC 779 4082, June 2005. 781 [RFC4535] H. Harney, et al, "GSAKMP: Group Secure Association 782 Group Management Protocol", IETF RFc 4535, June 2006. 784 [RFC3547] M. Baugher, et al, "GDOI: The Group Domain of 785 Interpretation", IETF RFC 3547. 787 [WEIS08] B. Weis, et al, "Multicast Extensions to the Security 788 Architecture for the Internet", , June 2008, IETF Work in 790 Progress. 792 [RFC3715] B. Aboba, W. Dixson, "IPsec-Network Address 793 Translation (NAT) Compatibility Requirements" IETF 794 RFC 3715, March 2004. 796 [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security 797 (TLS) Protocol Version 1.1", IETF RFC 4346, April 798 2006. 800 [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing 801 Proxies Intended to Mitigate Link-Related 802 Degradations", IETF RFC 3135, June 2001. 804 [RFC4301] S. Kent, K. Seo, "Security Architecture for the 805 Internet Protocol", IETF RFC 4301, December 2006. 807 [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. 808 Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L. 809 Wood, "Advice for Internet Subnetwork Designers", BCP 810 89, IETF RFC 3819, July 2004. 812 [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) 813 Protocol Architecture", IETF RFC 4251, January 2006. 815 12. Author's Addresses 817 Haitham Cruickshank 818 Centre for Communications System Research (CCSR) 819 University of Surrey 820 Guildford, Surrey, GU2 7XH 821 UK 822 Email: h.cruickshank@surrey.ac.uk 824 Prashant Pillai 825 Mobile and Satellite Communications Research Centre (MSCRC) 826 School of Engineering, Design and Technology 827 University of Bradford 828 Richmond Road, Bradford BD7 1DP 829 UK 830 Email: p.pillai@bradford.ac.uk 832 Michael Noisternig 833 Multimedia Comm. Group, Dpt. of Computer Sciences 834 University of Salzburg 835 Jakob-Haringer-Str. 2 836 5020 Salzburg 837 Austria 838 Email: mnoist@cosy.sbg.ac.at 840 Sunil Iyengar 841 Space & Defence 842 Logica 843 Springfield Drive 844 Leatherhead 845 Surrey KT22 7LP 846 UK 847 Email: sunil.iyengar@logica.com 849 13. IPR Notices 851 Copyright (c) The IETF Trust (2007). 853 13.1. Intellectual Property Statement 855 Full Copyright Statement 857 This document is subject to the rights, licenses and restrictions 858 contained in BCP 78, and except as set forth therein, the authors 859 retain all their rights. 861 This document and the information contained herein are provided 862 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 863 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 864 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 865 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 866 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 867 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 868 FITNESS FOR A PARTICULAR PURPOSE. 870 Intellectual Property Statement 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be 874 claimed to pertain to the implementation or use of the technology 875 described in this document or the extent to which any license 876 under such rights might or might not be available; nor does it 877 represent that it has made any independent effort to identify any 878 such rights. Information on the procedures with respect to 879 rights in RFC documents can be found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the 884 use of such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR 886 repository at http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention 889 any copyrights, patents or patent applications, or other 890 proprietary rights that may cover technology that may be required 891 to implement this standard. Please address the information to 892 the IETF at ietf-ipr@ietf.org. 894 14. Copyright Statement 896 Copyright (C) The IETF Trust (2008). 898 Appendix A: ULE Security Framework 900 This section defines a security framework for the deployment of 901 secure ULE networks. 903 A.1 Building Blocks 904 This ULE Security framework defines the following building blocks 905 as shown in figure 2 below: 907 o The Key Management Block 909 o The ULE Security Extension Header Block 911 o The ULE Databases Block 913 Within the Key Management block the communication between the 914 Group Member entity and the Group Server entity happens in the 915 control plane. The ULE Security header block applies security to 916 the ULE SNDU and this happens in the ULE data plane. The ULE 917 Security databases block acts as the interface between the Key 918 management block (control plane) and the ULE Security Header 919 block (ULE data plane) as shown in figure 2. 921 ------ 922 +------+----------+ +----------------+ / \ 923 | Key Management |/---------\| Key Management | | 924 | Block |\---------/| Block | | 925 | Group Member | | Group Server | Control 926 +------+----------+ +----------------+ Plane 927 | | | 928 | | | 929 | | \ / 930 ----------- Key management <-> ULE Security databases ----- 931 | | 932 \ / 933 +------+----------+ 934 | ULE | 935 | SAD / SPD | 936 | Databases | 937 | Block | 938 +------+-+--------+ 939 / \ 940 | | 941 ----------- ULE Security databases <-> ULE Security Header ---- 942 | | / \ 943 | | | 944 | | | 945 +------+-+--------+ ULE Data 946 | ULE Security | Plane 947 | Extension Header| | 948 | Block | | 949 +-----------------+ \ / 950 ----- 952 Figure 2: Secure ULE Framework Building Blocks 954 A.1.1 Key Management Block 956 A key management framework is required to provide security at the 957 ULE level using extension headers. This key management framework 958 is responsible for user authentication, access control, and 959 Security Association negotiation (which include the negotiations 960 of the security algorithms to be used and the generation of the 961 different session keys as well as policy material). The Key 962 management framework can be either automated or manual. Hence 963 this key management client entity (shown as the Key Management 964 Group Member block in figure 2) will be present in all ULE 965 Receivers as well as at the ULE Encapsulators. The ULE 966 Encapsulator could also be the Key Management Group Server Entity 967 (shown as the Key Management Group Server block in figure 2. This 968 happens when the ULE Encapsulator also acts as the Key Management 969 Group Server. Deployment may use either automated key management 970 protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying 971 material. 973 A.1.2 ULE Extension Header Block 975 A new security extension header for the ULE protocol is required 976 to provide the security features of data confidentiality, data 977 integrity, data authentication, and mechanisms to prevent replay 978 attacks. Security keying material will be used for the different 979 security algorithms (for encryption/decryption, MAC generation, 980 etc.), which are used to meet the security requirements, 981 described in detail in Section 4 of this document. 983 This block will use the keying material and policy information 984 from the ULE security database block on the ULE payload to 985 generate the secure ULE Extension Header or to decipher the 986 secure ULE extension header to get the ULE payload. An example 987 overview of the ULE Security extension header format along with 988 the ULE header and payload is shown in figure 3 below. 990 +-------+------+-------------------------------+------+ 991 | ULE |SEC | Protocol Data Unit | | 992 |Header |Header| |CRC-32| 993 +-------+------+-------------------------------+------+ 994 Figure 3: ULE Security Extension Header Placement 996 A.1.3 ULE Security Databases Block 997 There needs to be two databases, i.e. similar to the IPsec 998 databases. 1000 o ULE-SAD: ULE Security Association Database contains all the 1001 Security Associations that are currently established with 1002 different ULE peers. 1004 o ULE-SPD: ULE Security Policy Database contains the policies as 1005 defined by the system manager. These policies describe the 1006 security services that must be enforced. 1008 The design of these two databases may be based on IPsec databases 1009 as defined in RFC4301 [RFC4301]. 1011 The exact details of the header patterns that the SPD and SAD 1012 will have to support for all use cases will be defined in a 1013 separate document. This document only highlights the need for 1014 such interfaces between the ULE data plane and the Key Management 1015 control plane. 1017 A.2 Interface definition 1019 Two new interfaces have to be defined between the blocks as shown 1020 in Figure 2 above. These interfaces are: 1022 o Key Management block <-> ULE Security databases block 1024 o ULE Security databases block <-> ULE Security Header block 1026 While the first interface is used by the Key Management Block to 1027 insert keys, security associations and policies into the ULE 1028 Database Block, the second interface is used by the ULE Security 1029 Extension Header Block to get the keys and policy material for 1030 generation of the security extension header. 1032 A.2.1 Key Management <-> ULE Security databases 1034 This interface is between the Key Management group member block 1035 (GM client) and the ULE Security Database block (shown in figure 1036 2). The Key Management GM entity will communicate with the GCKS 1037 and then get the relevant security information (keys, cipher 1038 mode, security service, ULE_Security_ID and other relevant keying 1039 material as well as policy) and insert this data into the ULE 1040 Security database block. The Key Management could be either 1041 automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]), or security 1042 information could be manually inserted using this interface. The 1043 following three interface functions are defined: 1045 . Insert_record_database (char * Database, char * record, char * 1046 Unique_ID); 1047 . Update_record_database (char * Database, char * record, char * 1048 Unique_ID); 1049 . Delete_record_database (char * Database, char * Unique_ID); 1051 The definitions of the variables are as follows: 1053 . Database - This is a pointer to the ULE Security databases 1054 . record - This is the rows of security attributes to be 1055 entered or modified in the above databases 1056 . Unique_ID - This is the primary key to lookup records (rows 1057 of security attributes) in the above databases 1059 A.2.2 ULE Security Databases <-> ULE Security Header 1061 This interface is between the ULE Security Database and the ULE 1062 Security Extension Header block as shown in figure 2. When 1063 sending traffic, the ULE encapsulator uses the Destination 1064 Address, the PID, and possibly other information such as L3 1065 source and destination addresses to locate the relevant security 1066 record within the ULE Security Database. It then uses the data in 1067 the record to create the ULE security extension header. For 1068 received traffic, the ULE decapsulator on receiving the ULE SNDU 1069 will use the Destination Address, the PID, and a ULE Security ID 1070 inserted by the ULE encapsulator into the security extension to 1071 retrieve the relevant record from the Security Database. It then 1072 uses this information to decrypt the ULE extension header. For 1073 both cases (either send or receive traffic) only one interface is 1074 needed since the main difference between the sender and receiver 1075 is the direction of the flow of traffic: 1077 . Get_record_database (char * Database, char * record, char * 1078 Unique_ID); 1080 Appendix B: Motivation for ULE link-layer security 1082 Examination of the threat analysis and security requirements in 1083 sections 3 and 4 has shown that there is a need to provide 1084 security in MPEG-2 transmission networks employing ULE. This 1085 section compares the placement of security functionalities in 1086 different layers. 1088 B.1 Security at the IP layer (using IPsec) 1090 The security architecture for the Internet Protocol [RFC4301] 1091 describes security services for traffic at the IP layer. This 1092 architecture primarily defines services for the Internet Protocol 1093 (IP) unicast packets, as well as manually configured IP multicast 1094 packets. 1096 It is possible to use IPsec to secure ULE Streams. The major 1097 advantage of IPsec is its wide implementation in IP routers and 1098 hosts. IPsec in transport mode can be used for end-to-end 1099 security transparently over MPEG-2 transmission links with little 1100 impact. 1102 In the context of MPEG-2 transmission links, if IPsec is used to 1103 secure a ULE Stream, then the ULE Encapsulator and Receivers are 1104 equivalent to the security gateways in IPsec terminology. A 1105 security gateway implementation of IPsec uses tunnel mode. Such 1106 usage has the following disadvantages: 1108 o There is an extra transmission overhead associated with using 1109 IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 1111 o There is a need to protect the identity (NPA) of ULE Receivers 1112 over the ULE broadcast medium; IPsec is not suitable for 1113 providing this service. In addition, the interfaces of these 1114 devices do not necessarily have IP addresses (they can be L2 1115 devices). 1117 o Multicast is considered a major service over ULE links. The 1118 current IPsec specifications [RFC4301] only define a pairwise 1119 tunnel between two IPsec devices with manual keying. Work is 1120 in progress in defining the extra detail needed for multicast 1121 and to use the tunnel mode with address preservation to allow 1122 efficient multicasting. For further details refer to [WEIS08]. 1124 B.2 Link security below the encapsulation layer 1126 Link layer security can be provided at the MPEG-2 TS layer (below 1127 ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a 1128 specific PID value. However, an MPEG-2 TS may typically multiplex 1129 several IP flows, belonging to different users, using a common 1130 PID. Therefore all multiplexed traffic will share the same 1131 security keys. 1133 This has the following advantages: 1135 o The bit stream sent on the broadcast network does not expose 1136 any L2 or L3 headers, specifically all addresses, type fields, 1137 and length fields are encrypted prior to transmission. 1139 o This method does not preclude the use of IPsec, TLS, or any 1140 other form of higher-layer security. 1142 However it has the following disadvantages: 1144 o When a PID is shared between several users, each ULE Receiver 1145 needs to decrypt all MPEG-2 TS Packets with a matching PID, 1146 possibly including those that are not required to be 1147 forwarded. Therefore it does not have the flexibility to 1148 separately secure individual IP flows. 1150 o When a PID is shared between several users, the ULE Receivers 1151 will have access to private traffic destined to other ULE 1152 Receivers, since they share a common PID and key. 1154 o IETF-based key management that is very flexible and secure is 1155 not used in existing MPEG-2 based systems. Existing access 1156 control mechanisms in such systems have limited flexibility in 1157 terms of controlling the use of key and rekeying. Therefore if 1158 the key is compromised, then this will impact several ULE 1159 Receivers. 1161 Currently there are few deployed L2 security systems for MPEG-2 1162 transmission networks. Conditional access for digital TV 1163 broadcasting is one example. However, this approach is optimised 1164 for TV services and is not well-suited to IP packet transmission. 1165 Some other systems are specified in standards such as MPE [ETSI- 1166 DAT], but there are currently no known implementations. 1168 B.3 Link security as a part of the encapsulation layer 1170 Examining the threat analysis in section 3 has shown that 1171 protection of ULE Stream from eavesdropping and ULE Receiver 1172 identity are major requirements. 1174 There are several major advantages in using ULE link layer 1175 security: 1177 o The protection of the complete ULE Protocol Data Unit (PDU) 1178 including IP addresses. The protection can be applied either 1179 per IP flow or per Receiver NPA address. 1181 o Ability to protect the identity of the Receiver within the 1182 MPEG-2 transmission network at the IP layer and also at L2. 1184 o Efficient protection of IP multicast over ULE links. 1186 o Transparency to the use of Network Address Translation (NATs) 1187 [RFC3715] and TCP Performance Enhancing Proxies (PEP) 1188 [RFC3135], which require the ability to inspect and modify the 1189 packets sent over the ULE link. 1191 This method does not preclude the use of IPsec at L3 (or TLS 1192 [RFC4346] at L4). IPsec and TLS provide strong authentication of 1193 the end-points in the communication. 1195 L3 end-to-end security would partially deny the advantage listed 1196 just above (use of PEP, compression etc), since those techniques 1197 could only be applied to TCP packets bearing a TCP-encapsulated 1198 IPsec packet exchange, but not the TCP packets of the original 1199 applications, which in particular inhibits compression. 1201 End-to-end security (IPsec, TLS, etc.) may be used independently 1202 to provide strong authentication of the end-points in the 1203 communication. This authentication is desirable in many scenarios 1204 to ensure that the correct information is being exchanged between 1205 the trusted parties, whereas Layer 2 methods cannot provide this 1206 guarantee. 1208 >>> NOTE to RFC Editor: Please remove this appendix prior to 1209 publication] 1211 Document History 1213 Working Group Draft 00 1215 o Fixed editorial mistakes and ID style for WG adoption. 1217 Working Group Draft 01 1219 o Fixed editorial mistakes and added an appendix which shows the 1220 preliminary framework for securing the ULE network. 1222 Working Group Draft 02 1224 o Fixed editorial mistakes and added some important changes as 1225 pointed out by Knut Eckstein (ESA), Gorry Fairhurst and 1226 UNISAL. 1228 o Added section 4.1 on GSE. Extended the security considerations 1229 section. 1231 o Extended the appendix to show the extension header placement. 1233 o The definition of the header patterns for the ULE Security 1234 databases will be defined in a separate draft. 1236 o Need to include some words on key management transport over 1237 air interfaces, actually key management bootstrapping. 1239 Working Group Draft 03 1241 o Fixed editorial mistakes and added some important changes as 1242 pointed out by Gorry Fairhurst. 1244 o Table 1 added in Section 6.2 to list the different security 1245 techniques to mitigate the various possible network threats. 1247 o Figure 2 modified to clearly explain the different interfaces 1248 present in the framework. 1250 o New Section 7 has been added. 1252 o New Section 6 has been added. 1254 o The previous sections 5 and 6 have been combined to section 5. 1256 o Sections 3, 8 and 9 have been rearranged and updated with 1257 comments and suggestions from Michael Noisternig from 1258 University of Salzburg. 1260 o The Authors and the Acknowledgments section have been updated. 1262 Working Group Draft 04 1264 o Fixed editorial mistakes and added some important changes as 1265 pointed out by DVB-GBS group, Gorry Fairhurst and Laurence 1266 Duquerroy. 1268 o Table 1 modified to have consistent use of Security Services. 1270 o Text modified to be consistent with the draft-ietf-ipdvb-ule- 1271 ext-04.txt 1273 Working Group Draft 06 1275 o Fixed editorial mistakes and added some important changes as 1276 pointed out by Pat Cain and Gorry Fairhurst. 1278 o Figure 1 modified to have consistent use of Security Services. 1280 o Text modified in Section 4 to clearly state the requirements. 1282 o Moved Section 5 to the Appendix B 1284 o Updated IANA consideration section 1286 o Numbered the different requirements and cross referenced them 1287 within the text. 1289 Working Group Draft 07 1291 o Rephrased some sentences throughout the document to add more 1292 clarity, mainly due to suggestions by Gorry Fairhurst. 1294 o Updated section 4 to more clearly specify requirements, 1295 choosing more appropriate RFC 2119 keywords, and removed some 1296 overly general requirements. 1298 o Moved security header placement recommendation from appendix 1299 to list of general requirements in section 4, as suggested by 1300 Gorry Fairhurst. 1302 o Modified text in appendix section A.2.2 to correctly specify 1303 which information sender and receiver use to look up security 1304 information within the database. 1306 o Fixed some editorial mistakes and updated the reference list.