idnits 2.17.1 draft-ietf-ipdvb-sec-req-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 889. 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 == Line 567 has weird spacing: '... be imple...' -- 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 (April 4, 2008) is 5837 days in the past. Is this intentional? 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 (~~), 2 warnings (==), 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 S. Iyengar 3 Intended status: Informational University of Surrey, UK 4 P. Pillai 5 Expires: October 4, 2008 University of Bradford, UK 6 April 4, 2008 8 Security requirements for the Unidirectional Lightweight 9 Encapsulation (ULE) protocol 10 draft-ietf-ipdvb-sec-req-06.txt 12 Status of this Draft 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as "work 29 in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 4, 2008. 39 Abstract 41 The MPEG-2 standard defined by ISO 13818-1 supports a range of 42 transmission methods for a range of services. This document 43 provides a threat analysis and derives the security requirements 44 when using the Transport Stream, TS, to support an Internet 45 network-layer using Unidirectional Lightweight Encapsulation 46 (ULE) defined in RFC4326. The document also provides the 47 motivation for link-layer security for a ULE Stream. A ULE Stream 48 may be used to send IPv4 packets, IPv6 packets, and other 49 Protocol Data Units (PDUs) to an arbitrarily large number of 50 Receivers supporting unicast and/or multicast transmission. 52 Table of Contents 54 1. Introduction................................................2 55 2. Requirements notation.......................................3 56 3. Threat Analysis.............................................6 57 3.1. System Components......................................6 58 3.2. Threats................................................9 59 3.3. Threat Scenarios......................................10 60 4. Security Requirements for IP over MPEG-2 TS................11 61 5. Design recommendations for ULE Security Header Extension...13 62 6. Compatibility with Generic Stream Encapsulation............14 63 7. Summary....................................................14 64 8. Security Considerations....................................15 65 9. IANA Considerations........................................16 66 10. Acknowledgments...........................................16 67 11. References................................................16 68 11.1. Normative References.................................16 69 11.2. Informative References...............................16 70 12. Author's Addresses........................................18 71 13. IPR Notices...............................................18 72 13.1. Intellectual Property Statement......................19 73 14. Copyright Statement.......................................19 74 Appendix A: ULE Security Framework............................20 75 Appendix B: Motivation for ULE link-layer security............24 76 Document History..............................................27 78 1. Introduction 80 The MPEG-2 Transport Stream (TS) has been widely accepted not 81 only for providing digital TV services, but also as a subnetwork 82 technology for building IP networks. RFC 4326 [RFC4326] describes 83 the Unidirectional Lightweight Encapsulation (ULE) mechanism for 84 the transport of IPv4 and IPv6 Datagrams and other network 85 protocol packets directly over the ISO MPEG-2 Transport Stream as 86 TS Private Data. ULE specifies a base encapsulation format and 87 supports an extension format that allows it to carry additional 88 header information to assist in network/Receiver processing. The 89 encapsulation satisfies the design and architectural requirement 90 for a lightweight encapsulation defined in RFC 4259 [RFC4259]. 91 Section 3.1 of RFC 4259 presents several topological scenarios 92 for MPEG-2 Transmission Networks. A summary of these scenarios 93 are presented below (for full detail, please refer to RFC 4259): 95 1. Broadcast TV and Radio Delivery. 97 2. Broadcast Networks used as an ISP. This resembles to scenario 98 1, but includes the provision of IP services providing access 99 to the public Internet. 101 3. Unidirectional Star IP Scenario. It utilizes a Hub station to 102 provide a data network delivering a common bit stream to 103 typically medium-sized groups of Receivers. 105 4. Datacast Overlay. It employs MPEG-2 physical and link layers 106 to provide additional connectivity such as unidirectional 107 multicast to supplement an existing IP-based Internet service. 109 5. Point-to-Point Links. 111 6. Two-Way IP Networks. This can be typically satellite-based and 112 star-based utilising a Hub station to deliver a common bit 113 stream to medium-sized groups of receivers. A bidirectional 114 service is provided over a common air-interface. 116 RFC 4259 states that ULE must be robust to errors and security 117 threats. Security must also consider both unidirectional as well 118 as bidirectional links for the scenarios mentioned above. 120 An initial analysis of the security requirements in MPEG-2 121 transmission networks is presented in the security considerations 122 section of RFC 4259. For example, when such networks are not 123 using a wireline network, the normal security issues relating to 124 the use of wireless links for transport of Internet traffic 125 should be considered [RFC3819]. 127 The security considerations of RFC 4259 recommends that any new 128 encapsulation defined by the IETF should allow Transport Stream 129 encryption and should also support optional link-layer 130 authentication of the SNDU payload. In ULE [RFC4326], it is 131 suggested that this may be provided in a flexible way using 132 Extension Headers. This requires the definition of a mandatory 133 header extension, but has the advantage that it decouples 134 specification of the security functions from the encapsulation 135 functions. 137 This document extends the above analysis and derives a detailed 138 the security requirements for ULE in MPEG-2 transmission 139 networks. 141 A security framework for deployment of secure ULE networks 142 describing the different building blocks and the interface 143 definitions is presented in Appendix A. 145 2. Requirements notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 147 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 RFC2119 [RFC2119]. 151 Other terms used in this document are defined below: 153 ATSC: Advanced Television Systems Committee. A framework and a 154 set of associated standards for the transmission of video, audio, 155 and data using the ISO MPEG-2 standard. 157 DVB: Digital Video Broadcast. A framework and set of associated 158 standards published by the European Telecommunications Standards 159 Institute (ETSI) for the transmission of video, audio, and data 160 using the ISO MPEG-2 Standard [ISO-MPEG2]. 162 Encapsulator: A network device that receives PDUs and formats 163 these into Payload Units (known here as SNDUs) for output as a 164 stream of TS Packets. 166 LLC: Logical Link Control [ISO-8802, IEEE-802]. A link-layer 167 protocol defined by the IEEE 802 standard, which follows the 168 Ethernet Medium Access Control Header. 170 MAC: Message Authentication Code. 172 MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that 173 encapsulates PDUs, forming a DSM-CC Table Section. Each Section 174 is sent in a series of TS Packets using a single TS Logical 175 Channel. 177 MPEG-2: A set of standards specified by the Motion Picture 178 Experts Group (MPEG) and standardized by the International 179 Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T 180 (in H.222 [ITU-H222]). 182 NPA: Network Point of Attachment. In this document, refers to a 183 6-byte destination address (resembling an IEEE Medium Access 184 Control address) within the MPEG-2 transmission network that is 185 used to identify individual Receivers or groups of Receivers. 187 PDU: Protocol Data Unit. Examples of a PDU include Ethernet 188 frames, IPv4 or IPv6 datagrams, and other network packets. 190 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in 191 the header of TS Packets. This is used to identify the TS 192 Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS 193 Packets forming the parts of a Table Section, PES, or other 194 Payload Unit must all carry the same PID value. The all-zeros 195 PID 0x0000 as well as other PID values is reserved for specific 196 PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 197 indicates a Null TS Packet introduced to maintain a constant bit 198 rate of a TS Multiplex. There is no required relationship 199 between the PID values used for TS Logical Channels transmitted 200 using different TS Multiplexes. 202 Receiver: Equipment that processes the signal from a TS Multiplex 203 and performs filtering and forwarding of encapsulated PDUs to the 204 network-layer service (or bridging module when operating at the 205 link layer). 207 SI Table: Service Information Table [ISO-MPEG2]. In this 208 document, this term describes a table that is defined by another 209 standards body to convey information about the services carried 210 in a TS Multiplex. A Table may consist of one or more Table 211 Sections; however, all sections of a particular SI Table must be 212 carried over a single TS Logical Channel [ISO-MPEG2]. 214 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 215 Payload Unit. 217 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 218 MPEG-2 layer using TS Packets; it represents layer 2 of the 219 ISO/OSI reference model. See also TS Logical Channel and TS 220 Multiplex. 222 TS Multiplex: In this document, this term defines a set of MPEG-2 223 TS Logical Channels sent over a single lower-layer connection. 224 This may be a common physical link (i.e., a transmission at a 225 specified symbol rate, FEC setting, and transmission frequency) 226 or an encapsulation provided by another protocol layer (e.g., 227 Ethernet, or RTP over IP). The same TS Logical Channel may be 228 repeated over more than one TS Multiplex (possibly associated 229 with a different PID value) [RFC4259]; for example, to 230 redistribute the same multicast content to two terrestrial TV 231 transmission cells. 233 TS Packet: A fixed-length 188B unit of data sent over a TS 234 Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus 235 optional overhead including an Adaptation Field, encryption 236 details, and time stamp information to synchronise a set of 237 related TS Logical Channels. 239 ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE 240 encapsulated PDUs. ULE Streams may be identified by definition of 241 a stream_type in SI/PSI [ISO-MPEG2]. 243 3. Threat Analysis 245 3.1. System Components 247 +------------+ +------------+ 248 | IP | | IP | 249 | End Host | | End Host | 250 +-----+------+ +------------+ 251 | ^ 252 +------------>+---------------+ | 253 + ULE | | 254 +-------------+ Encapsulator | | 255 SI-Data | +------+--------+ | 256 +-------+-------+ |MPEG-2 TS Logical Channel | 257 | MPEG-2 | | | 258 | SI Tables | | | 259 +-------+-------+ ->+------+--------+ | 260 | -->| MPEG-2 | . . . 261 +------------>+ Multiplexer | | 262 MPEG-2 TS +------+--------+ | 263 Logical Channel |MPEG-2 TS Mux | 264 | | 265 Other ->+------+--------+ | 266 MPEG-2 -->+ MPEG-2 | | 267 TS --->+ Multiplexer | | 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 service 277 for IP transport over MPEG-2 (adapted from [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 (the ULE Encapsulator) 285 o SI-Table signalling generator (input to the multiplexer) 286 o Receivers (the end points for ULE streams) 288 o TS multiplexers (including re-multiplexers) 290 o Modulators 292 In a MPEG-2 TS transmission network, the originating source of TS 293 Packets is either a L2 interface device (media encoder, 294 encapsulation gateway, etc) or a L2 network device (TS 295 multiplexer, etc). These devices may, but do not necessarily, 296 have an associated IP address. In the case of an encapsulation 297 gateway (e.g. ULE sender), the device may operate at L2 or Layer 298 3 (L3), and is not normally the originator of an IP traffic flow, 299 and usually the IP source address of the packets that it forwards 300 do not correspond to an IP address associated with the device. 302 The TS Packets are carried to the Receiver over a physical layer 303 that usually includes Forward Error Correction (FEC) coding that 304 interleaves the bytes of several consecutive, but unrelated, TS 305 Packets. FEC-coding and synchronisation processing makes 306 injection of single TS Packets very difficult. Replacement of a 307 sequence of packets is also difficult, but possible (see section 308 3.2). 310 A Receiver in a MPEG-2 TS transmission network needs to identify 311 a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble 312 the fragments of PDUs sent by a L2 source [RFC4259]. In a MPEG-2 313 TS, this association is made via the Packet Identifier, PID [ISO- 314 MPEG2]. At the sender, each source associates a locally unique 315 set of PID values with each stream it originates. However, there 316 is no required relationship between the PID value used at the 317 sender and that received at the Receiver. Network devices may re- 318 number the PID values associated with one or more TS Logical 319 Channels (e.g. ULE Streams) to prevent clashes at a multiplexer 320 between input streams with the same PID carried on different 321 input multiplexes (updating entries in the PMT [ISO-MPEG2], and 322 other SI tables that reference the PID value). A device may also 323 modify and/or insert new SI data into the control plane (also 324 sent as TS Packets identified by their PID value). However there 325 is only one valid source of data for each MPEG-2 Elementary 326 Stream, bound to a PID value. (This observation could simplify 327 the requirement for authentication of the source of a ULE 328 Stream.) 330 In an MPEG-2 network a set of signalling messages [ID-AR] may 331 need to be broadcast (e.g. by an Encapsulation Gateway or other 332 device) to form the Layer 2 (L2) control plane. Examples of 333 signalling messages include the Program Association Table (PAT), 334 Program Map Table (PMT) and Network Information Table (NIT). In 335 existing MPEG-2 transmission networks, these messages are 336 broadcast in the clear (no encryption or integrity checks). The 337 integrity as well as authenticity of these messages is important 338 for correct working of the ULE network, i.e. supporting its 339 security objectives in the area of availability, in addition to 340 confidentiality and integrity. One method recently proposed [ID- 341 EXT] encapsulates these messages using ULE. In such cases all the 342 security requirements of this document apply in securing these 343 signalling messages. 345 ULE link security focuses only on the security between the ULE 346 Encapsulation Gateway (ULE Encapsulator) and the Receiver. In 347 many deployment scenarios the user of a ULE Stream has to secure 348 communications beyond the link since other network links are 349 utilised in addition to the ULE link. Therefore, if 350 authentication of the end-point i.e. the IP Sources is required, 351 or users are concerned about loss of confidentiality, integrity 352 or authenticity of their communication data, they will have to 353 employ end-to-end network security mechanisms like IPSec or 354 Transport Layer Security (TLS). Governmental users may be forced 355 by regulations to employ specific, approved implementations of 356 those mechanisms. Hence for such cases the confidentiality and 357 integrity of the user data will already be taken care of by the 358 end-to-end security mechanism and the ULE security measures would 359 focus on either providing traffic flow confidentiality for user 360 data that has already been encrypted or for users who choose not 361 to implement end-to-end security mechanisms. 363 ULE links may also be used for communications where the two end- 364 points are not under central control (e.g., when browsing a 365 public web site). In these cases, it may be impossible to enforce 366 any end-to-end security mechanisms. Yet, a common objective is 367 that users can rely on security assumptions as of wired links. 368 ULE security could achieve this by protecting the vulnerable (in 369 terms of passive attacks) ULE link. 371 In contrast to the above, if a ULE Stream is used to directly 372 join networks which are considered physically secure, for example 373 branch offices to a central office, ULE link Security could be 374 the sole provider of confidentiality and integrity. In this 375 scenario, governmental users could still have to employ approved 376 cryptographic equipment at the network layer or above, unless a 377 manufacturer of ULE Link Security equipment obtains governmental 378 approval for their implementation. 380 3.2. Threats 382 The simplest type of network threat is a passive threat. This 383 includes eavesdropping or monitoring of transmissions, with a 384 goal to obtain information that is being transmitted. In 385 broadcast networks (especially those utilising widely available 386 low-cost physical layer interfaces, such as DVB) passive threats 387 are considered the major threats. An example of such a threat is 388 an intruder monitoring the MPEG-2 transmission broadcast and then 389 extracting traffic information concerning the communication 390 between IP hosts using a link. Another example is of an intruder 391 trying to gain information about the communication parties by 392 monitoring their ULE Receiver NPA addresses; an intruder can gain 393 information by determining the layer 2 identity of the 394 communicating parties and the volume of their traffic. This is a 395 well-known issue in the security field; however it is more of a 396 problem in the case of broadcast networks such as MPEG-2 397 transmission networks because of the easy availability of 398 receiver hardware and the wide geographical span of the networks. 400 Active threats (or attacks) are, in general, more difficult to 401 implement successfully than passive threats, and usually require 402 more sophisticated resources and may require access to the 403 transmitter. Within the context of MPEG-2 transmission networks, 404 examples of active attacks are: 406 o Masquerading: An entity pretends to be a different entity. 407 This includes masquerading other users and subnetwork control 408 plane messages. 410 o Modification of messages in an unauthorised manner. 412 o Replay attacks: When an intruder sends some old (authentic) 413 messages to the Receiver. In the case of a broadcast link, 414 access to previous broadcast data is easy. 416 o Denial of Service attacks: When an entity fails to perform its 417 proper function or acts in a way that prevents other entities 418 from performing their proper functions. 420 The active threats mentioned above are major security concerns 421 for the Internet community [BELLOVIN]. Masquerading and 422 modification of IP packets are comparatively easy in an Internet 423 environment whereas such attacks are in fact much harder for 424 MPEG-2 broadcast links. This could for instance motivate the 425 mandatory use of sequence numbers in IPsec, but not for 426 synchronous links. This is further reflected in the security 427 requirements for Case 2 and 3 in section 4 below. 429 As explained in section 3.1, the PID associated with an 430 Elementary Stream can be modified (e.g. in some systems by 431 reception of an updated SI table, or in other systems until the 432 next announcement/discovery data is received). An attacker that 433 is able to modify the content of the received multiplex (e.g. 434 replay data and/or control information) could inject data locally 435 into the received stream with an arbitrary PID value. 437 3.3. Threat Scenarios 439 Analysing the topological scenarios for MPEG-2 Transmission 440 Networks in section 1, the security threat cases can be 441 abstracted into three cases: 443 o Case 1: Monitoring (passive threat). Here the intruder 444 monitors the ULE broadcasts to gain information about the ULE 445 data and/or tracking the communicating parties identities (by 446 monitoring the destination NPA). In this scenario, measures 447 must be taken to protect the ULE payload data and the identity 448 of ULE Receivers. 450 o Case 2: Locally conduct active attacks on the MPEG-TS 451 multiplex. Here an intruder is assumed to be sufficiently 452 sophisticated to over-ride the original transmission from the 453 ULE Encapsulation Gateway and deliver a modified version of 454 the MPEG-TS transmission to a single ULE Receiver or a small 455 group of Receivers (e.g. in a single company site). The MPEG-2 456 transmission network operator might not be aware of such 457 attacks. Measures must be taken to ensure ULE source 458 authentication and preventing replay of old messages. 460 o Case 3: Globally conduct active attacks on the MPEG-TS 461 multiplex. Here we assume an intruder is very sophisticated 462 and able to over-ride the whole MPEG-2 transmission multiplex. 463 The requirements here are similar to scenario 2. The MPEG-2 464 transmission network operator can usually identify such 465 attacks and may resort to some means to restore the original 466 transmission. 468 For both cases 2 and 3, there can be two sub cases: 470 o Insider attacks i.e. active attacks from adversaries within 471 the network with knowledge of the secret material. 473 o Outsider attacks i.e. active attacks from outside of a virtual 474 private network. 476 In terms of priority, case 1 is considered the major threat in 477 MPEG-2 transmission systems. Case 2 is likely to a lesser degree 478 within certain network configurations, especially when there are 479 insider attacks. Hence, protection against such active attacks 480 should be used only when such a threat is a real possibility. 481 Case 3 is envisaged to be less practical, because it will be very 482 difficult to pass unnoticed by the MPEG-2 transmission operator. 483 It will require restoration of the original transmission. The 484 assumption being here is that physical access to the network 485 components (multiplexers, etc) and/or connecting physical media 486 is secure. Therefore case 3 is not considered further in this 487 document. 489 4. Security Requirements for IP over MPEG-2 TS 491 From the threat analysis in section 3, the following security 492 requirements can be derived: 494 Req 1. Data confidentiality MUST be considered in order to 495 mitigate passive and active threats in MPEG-2 broadcast 496 networks. 498 Req 2. Protection of Layer 2 NPA address MAY be provided. In 499 broadcast networks this protection can be used to prevent an 500 intruder tracking the identity of ULE Receivers and the volume 501 of their traffic. 503 Req 3. Integrity protection and authentication of the ULE source 504 MAY be provided to prevent active attacks described in section 505 3.2. 507 Req 4. Protection against replay attacks MAY be provided. This is 508 required for the active attacks described in section 3.2. 510 Req 5. Layer L2 ULE Source and Receiver authentication MAY be 511 provided. This is normally performed during the initial key 512 exchange and authentication phase, before the ULE Receiver can 513 join a secure session with the ULE Encapsulator (ULE source). 514 This is normally receiver to hub authentication and it could 515 be either unidirectional or bidirectional authentication based 516 on the underlying key management protocol. 518 Other general requirements are: 520 GReq (a) ULE key management functions SHALL be decoupled from ULE 521 security services such as encryption and source authentication. 522 This allows the independent development of both systems. 524 GReq (b) Support SHOULD be provided for automated as well as 525 manual insertion of keys and policy into the relevant 526 databases. 528 GReq (c) Algorithm agility MUST be supported. Changes in crypto 529 algorithms, hashes as they become obsolete should be updated 530 without affecting the overall security of the system. 532 GReq (d) Traceability SHOULD be supported to monitor the 533 transmission network using log files to record the activities 534 in the network and detect any intrusion. 536 GReq (e) Protection against loss of service (availability) 537 through malicious reconfiguration of system components (see 538 Figure 1) MUST be present. 540 GReq (f) The security system MUST be compatible with other 541 networking functions such as NAT Network Address Translation 542 (NAT) [RFC3715] or TCP acceleration can be used in a wireless 543 broadcast networks. 545 GReq (g) The security extension header MUST be compatible with 546 other ULE extension headers 548 GReq (h) Where a ULE Stream carries a set of IP traffic flows to 549 different destinations with a range of properties (multicast, 550 unicast, etc), it is often not appropriate to provide IP 551 confidentiality services for the entire ULE Stream. For many 552 expected applications of ULE, a finer-grain control MAY 553 therefore be required, at least permitting control of data 554 confidentiality/authorisation at the level of a single MAC/NPA 555 address. 557 Examining the threat cases in section 3.3, the security 558 requirements for each case can be summarised as: 560 o Case 1: Data confidentiality (Req 1) MUST be provided to 561 prevent monitoring of the ULE data (such as user information 562 and IP addresses). Protection of NPA addresses (Req 2) MAY be 563 provided to prevent tracking ULE Receivers and their 564 communications. 566 o Case 2: In addition to case 1 requirements, new measures MAY 567 be implemented such as authentication schemes using Message 568 Authentication Codes, digital signatures or TESLA [RFC4082] in 569 order to provide integrity protection and source 570 authentication (Req 2, Req 3 and Req 5). In addition sequence 571 numbers (Req 4) MAY be used to protect against replay attacks. 572 In terms of outsider attacks, group authentication using 573 Message Authentication Codes should provide the same level of 574 security (Req 3 and 5). This will significantly reduce the 575 ability of intruders to successfully inject their own data 576 into the MPEG-TS stream. However, scenario 2 threats apply 577 only in specific service cases, and therefore authentication 578 and protection against replay attacks are OPTIONAL. Such 579 measures incur additional transmission as well as processing 580 overheads. Moreover, intrusion detection systems may also be 581 needed by the MPEG-2 network operator. These should best be 582 coupled with perimeter security policy to monitor most denial- 583 of-service attacks. 585 o Case 3: As stated in section 3.3, the requirements here are 586 similar to Case 2 but since the MPEG-2 transmission network 587 operator can usually identify such attacks the constraints on 588 intrusion detections are less than in case 2. 590 The general requirements GReq(a) to GReq(h) are good security 591 practices and apply to all the scenarios above, where 592 appropriate. 594 5. Design recommendations for ULE Security Header Extension 596 Table 1 below shows the threats that are applicable to ULE 597 networks and the relevant security mechanism to mitigate those 598 threats. This would help in the design of the ULE Security 599 extension header. For example this could help in the selection of 600 security fields in the ULE Security extension Header design. 601 Moreover the security services could also be grouped into 602 profiles based on different security requirements. One example is 603 to have a base profile which does payload encryption and identity 604 protection. The second profile could do the above as well as 605 source authentication. 607 A modular design to ULE Security may allow it to use and benefit 608 from IETF key management protocols, such as GSAKMP [RFC4535] and 609 GDOI [RFC3547] protocols defined by the IETF Multicast Security 610 (MSEC) working group. This does not preclude the use of other key 611 management methods in scenarios where this is more appropriate. 613 IPsec or TLS also provide a proven security architecture defining 614 key exchange mechanisms and the ability to use a range of 615 cryptographic algorithms. ULE security can make use of these 616 established mechanisms and algorithms. 618 Mitigation of Threat 619 ----------------------------------------------- 620 | Data | Data |Source |Data |Intru |Iden | 621 |Privacy | fresh |Authent|Integ |sion |tity | 622 | | ness |ication|rity |Dete |Prote | 623 | | | | |ction |ction | 624 Attack | | | | | | | 625 ---------------|--------|-------|-------|-------|-------|------| 626 | Monitoring | X | - | - | - | - | X | 627 |---------------------------------------------------------------| 628 | Masquerading | X | - | X | X | - | X | 629 |---------------------------------------------------------------| 630 | Replay Attacks| - | X | X | X | X | - | 631 |---------------------------------------------------------------| 632 | Dos Attacks | - | X | X | X | X | - | 633 |---------------------------------------------------------------| 634 | Modification | - | - | X | X | X | - | 635 | of Messages | | | | | | | 636 --------------------------------------------------------------- 637 Table 1: Security techniques to mitigate network threats 638 in ULE Networks. 640 6. Compatibility with Generic Stream Encapsulation 642 The [ID-EXT] document describes two new Header Extensions that 643 may be used with Unidirectional Link Encapsulation, ULE, 644 [RFC4326] and the Generic Stream Encapsulation (GSE) that has 645 been designed for the Generic Mode (also known as the Generic 646 Stream (GS)), offered by second-generation DVB physical layers, 647 and specifically for DVB-S2 [ID-EXT]. 649 The security threats and requirement presented in this document 650 are applicable to ULE and GSE encapsulations. It might be 651 desirable to authenticate some/all of the headers; such decision 652 can be part of the security policy for the MPEG-2 transmission 653 network. 655 7. Summary 657 This document analyses a set of threats and security 658 requirements. It also defines the requirements for ULE security 659 and states the motivation for link security as a part of the 660 Encapsulation layer. 662 ULE security includes a need to provide link-layer encryption and 663 ULE Receiver identity protection. There is an optional 664 requirement for link-layer authentication and integrity assurance 665 as well as protection against insertion of old (duplicated) data 666 into the ULE stream (i.e. replay protection). This is optional 667 because of the associated overheads for the extra features and 668 they are only required for specific service cases. 670 ULE link security (between a ULE Encapsulation Gateway to 671 Receivers) is considered as an additional security mechanism to 672 IPsec, TLS, and application layer end-to-end security, and not as 673 a replacement. It allows a network operator to provide similar 674 functions to that of IPsec, but in addition provides MPEG-2 675 transmission link confidentiality and protection of ULE Receiver 676 identity (NPA). End-to-end security mechanism may then be used 677 additionally and independently for providing strong 678 authentication of the end-points in the communication. 680 Annexe 1 describes a set of building blocks that may be used to 681 realise a framework that provides ULE security functions. 683 8. Security Considerations 685 Link-layer (L2) encryption of IP traffic is commonly used in 686 broadcast/radio links to supplement End-to-End security (e.g. 687 provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). 689 A common objective is to provide the same level of privacy as 690 wired links. It is recommended that an ISP or user provide end- 691 to-end security services based on well known mechanisms such as 692 IPsec or TLS. 694 This document provides a threat analysis and derives the security 695 requirements to provide link encryption and optional link-layer 696 integrity / authentication of the SNDU payload. 698 There are some security issues that were raised in RFC 4326 699 [RFC4326] that are not addressed in this document (out of scope) 700 such as: 702 o The security issue with un-initialised stuffing bytes. In 703 ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 705 o Integrity issues related to the removal of the LAN FCS in a 706 bridged networking environment. The removal for bridged 707 frames exposes the traffic to potentially undetected 708 corruption while being processed by the Encapsulator and/or 709 Receiver. 711 o There is a potential security issue when a Receiver receives a 712 PDU with two Length fields: The Receiver would need to 713 validate the actual length and the Length field and ensure 714 that inconsistent values are not propagated by the network. 716 9. IANA Considerations 718 There are no IANA actions defined in this document. 720 10. Acknowledgments 722 The authors acknowledge the help and advice from Gorry Fairhurst 723 (University of Aberdeen). The authors also acknowledge 724 contributions from Laurence Duquerroy and Stephane Coombes (ESA), 725 Yim Fun Hu (University of Bradford) and Michael Noisternig from 726 University of Salzburg. 728 11. References 730 11.1. Normative References 732 [ISO-MPEG2] "Information technology -- generic coding of moving 733 pictures and associated audio information systems, 734 Part I", ISO 13818-1, International Standards 735 Organisation (ISO), 2000. 737 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, 1997. 740 11.2. Informative References 742 [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution 743 Mechanisms for IP Datagrams over MPEG-2 Networks", 744 Work in Progress , June 2006, IETF Work in 797 Progress. 799 [RFC3715] B. Aboba and W Dixson, "IPsec-Network Address 800 Translation (NAT) Compatibility Requirements" IETF 801 RFC 3715, March 2004. 803 [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security 804 (TLS) Protocol Version 1.1", IETF RFC 4346, April 805 2006. 807 [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing 808 Proxies Intended to Mitigate Link-Related 809 Degradations", IETF RFC 3135, June 2001. 811 [RFC4301] Kent, S. and Seo K., "Security Architecture for the 812 Internet Protocol", IETF RFC 4301, December 2006. 814 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 815 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., 816 and L. Wood, "Advice for Internet Subnetwork 817 Designers", BCP 89, IETF RFC 3819, July 2004. 819 [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) 820 Protocol Architecture", IETF RFC 4251, January 2006. 822 12. 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 Prashant Pillai 839 Mobile and Satellite Communications Research Centre (MSCRC) 840 School of Engineering, Design and Technology 841 University of Bradford 842 Richmond Road, Bradford BD7 1DP 843 UK 844 Email: p.pillai@bradford.ac.uk 846 13. IPR Notices 848 Copyright (c) The IETF Trust (2007). 850 13.1. Intellectual Property Statement 852 Full Copyright Statement 854 This document is subject to the rights, licenses and restrictions 855 contained in BCP 78, and except as set forth therein, the authors 856 retain all their rights. 858 This document and the information contained herein are provided 859 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 860 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 861 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 862 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 863 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 864 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 865 FITNESS FOR A PARTICULAR PURPOSE. 867 Intellectual Property Statement 869 The IETF takes no position regarding the validity or scope of any 870 Intellectual Property Rights or other rights that might be 871 claimed to pertain to the implementation or use of the technology 872 described in this document or the extent to which any license 873 under such rights might or might not be available; nor does it 874 represent that it has made any independent effort to identify any 875 such rights. Information on the procedures with respect to 876 rights in RFC documents can be found in BCP 78 and BCP 79. 878 Copies of IPR disclosures made to the IETF Secretariat and any 879 assurances of licenses to be made available, or the result of an 880 attempt made to obtain a general license or permission for the 881 use of such proprietary rights by implementers or users of this 882 specification can be obtained from the IETF on-line IPR 883 repository at http://www.ietf.org/ipr. 885 The IETF invites any interested party to bring to its attention 886 any copyrights, patents or patent applications, or other 887 proprietary rights that may cover technology that may be required 888 to implement this standard. Please address the information to 889 the IETF at ietf-ipr@ietf.org. 891 14. Copyright Statement 893 Copyright (C) The IETF Trust (2008). 895 Appendix A: ULE Security Framework 897 This section defines a security framework for the deployment of 898 secure ULE networks. 900 A.1 Building Blocks 902 This ULE Security framework defines the following building blocks 903 as shown in figure 2 below: 905 o The Key Management Block 907 o The ULE Security Extension Header Block 909 o The ULE Databases Block 911 Within the Key Management block the communication between the 912 Group Member entity and the Group Server entity happens in the 913 control plane. The ULE Security header block applies security to 914 the ULE SNDU and this happens in the ULE data plane. The ULE 915 Security databases block acts as the interface between the Key 916 management block (control plane) and the ULE Security Header 917 block (ULE data plane) as shown in figure 2. 919 ------ 920 +------+----------+ +----------------+ / \ 921 | Key Management |/---------\| Key Management | | 922 | Block |\---------/| Block | | 923 | Group Member | | Group Server | Control 924 +------+----------+ +----------------+ Plane 925 | | | 926 | | | 927 | | \ / 928 ----------- Key management <-> ULE Security databases ----- 929 | | 930 \ / 931 +------+----------+ 932 | ULE | 933 | SAD / SPD | 934 | Databases | 935 | Block | 936 +------+-+--------+ 937 / \ 938 | | 939 ----------- ULE Security databases <-> ULE Security Header ---- 940 | | / \ 941 | | | 942 | | | 943 +------+-+--------+ ULE Data 944 | ULE Security | Plane 945 | Extension Header| | 946 | Block | | 947 +-----------------+ \ / 948 ----- 950 Figure 2: Secure ULE Framework Building Blocks 952 A.1.1 Key Management Block 954 A key management framework is required to provide security at the 955 ULE level using extension headers. This key management framework 956 is responsible for user authentication, access control, and 957 Security Association negotiation (which include the negotiations 958 of the security algorithms to be used and the generation of the 959 different session keys as well as policy material). The Key 960 management framework can be either automated or manual. Hence 961 this key management client entity (shown as the Key Management 962 Group Member block in figure 2) will be present in all ULE 963 receivers as well as at the ULE Encapsulators. The ULE 964 Encapsulator could also be the Key Management Group Server Entity 965 (shown as the Key Management Group Server block in figure 2. This 966 happens when the ULE Encapsulator also acts as the Key Management 967 Group Server. Deployment may use either automated key management 968 protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying 969 material. 971 A.1.2 ULE Extension Header Block 973 A new security extension header for the ULE protocol is required 974 to provide the security features of data confidentiality, data 975 integrity, data authentication and mechanisms to prevent replay 976 attacks. Security keying material will be used for the different 977 security algorithms (for encryption/decryption, MAC generation, 978 etc.), which are used to meet the security requirements, 979 described in detail in Section 4 of this document. 981 This block will use the keying material and policy information 982 from the ULE security database block on the ULE payload to 983 generate the secure ULE Extension Header or to decipher the 984 secure ULE extension header to get the ULE payload. An example 985 overview of the ULE Security extension header format along with 986 the ULE header and payload is shown in figure 3 below. There 987 could be other extension headers (either mandatory or optional). 988 It is RECOMMENDED that these are placed after the security 989 extension header. This permits full protection for all headers. 990 It avoids situations where the SNDU has to be discarded on 991 processing the security extension header, while preceding headers 992 have already have been evaluated. One exception is the Timestamp 993 extension which SHOULD precede the security extension header [ID- 994 EXT]. When applying the security services for example 995 confidentiality, input to the cipher algorithm will cover the 996 fields from the end of the security extension header to the end 997 of the PDU. 999 +-------+------+-------------------------------+------+ 1000 | ULE |SEC | Protocol Data Unit | | 1001 |Header |Header| |CRC-32| 1002 +-------+------+-------------------------------+------+ 1003 Figure 3: ULE Security Header Extension Placement 1005 A.1.3 ULE Security Databases Block 1007 There needs to be two databases i.e. similar to the IPSec 1008 databases. 1010 o ULE-SAD: ULE Secure Association Database contains all the 1011 Security Associations that are currently established with 1012 different ULE peers. 1014 o ULE-SPD: ULE Secure Policy Database contains the policies as 1015 defined by the system manager. These policies describe the 1016 security services that must be enforced 1018 The design of these two databases will be based on IPSec 1019 databases as defined in RFC4301 [RFC4301]. 1021 The exact details of the header patterns that the SPD and SAD 1022 will have to support for all use cases will be defined in a 1023 separate document. This document only highlights the need for 1024 such interfaces between the ULE data plane and the Key Management 1025 control plane. 1027 A.2 Interface definition 1029 Two new interfaces have to be defined between the blocks as shown 1030 in Figure 2 above. These interfaces are: 1032 o Key Management block <-> ULE Security databases block 1033 o ULE Security databases block <-> ULE Security Header block 1035 While the first interface is used by the Key Management Block to 1036 insert keys, security associations and policies into the ULE 1037 Database Block, the second interface is used by the ULE Security 1038 Extension Header Block to get the keys and policy material for 1039 generation of the security extension header. 1041 A.2.1 Key Management <-> ULE Security databases 1043 This interface is between the Key Management group member block 1044 (GM client) and the ULE Security Database block (shown in figure 1045 2). The Key Management GM entity will communicate with the GCKS 1046 and then get the relevant security information (keys, cipher 1047 mode, security service, ULE_Security_ID and other relevant keying 1048 material as well as policy) and insert this data into the ULE 1049 Security database block. The Key Management could be either 1050 automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually 1051 inserted using this interface. The following three interface 1052 functions are defined: 1054 . Insert_record_database (char * Database, char * record, char * 1055 Unique_ID); 1056 . Update_record_database (char * Database, char * record, char * 1057 Unique_ID); 1058 . Delete_record_database (char * Database, char * Unique_ID); 1060 The definitions of the variables are as follows: 1062 . Database - This is a pointer to the ULE Security databases 1063 . record - This is the rows of security attributes to be 1064 entered or modified in the above databases 1065 . Unique_ID - This is the primary key to lookup records (rows 1066 of security attributes) in the above databases 1068 A.2.2 ULE Security Databases <-> ULE Security Header 1070 This interface is between the ULE Security Database and the ULE 1071 Security Extension Header block as shown in figure 2. To send 1072 traffic, firstly the ULE encapsulator using the ULE_Security_ID, 1073 Destination Address and possibly the PID, searches the ULE 1074 Security Database for the relevant security record. It then uses 1075 the data in the record to create the ULE security extension 1076 header. For received traffic, the ULE decapsulator on receiving 1077 the ULE SNDU will first get the record from the Security Database 1078 using the ULE_Security_ID, the Destination Address and possibly 1079 the PID. It then uses this information to decrypt the ULE 1080 extension header. For both cases (either send or receive traffic) 1081 only one interface is needed since the only difference between 1082 the sender and receiver is the direction of the flow of traffic: 1084 . Get_record_database (char * Database, char * record, char * 1085 Unique_ID); 1087 Appendix B: Motivation for ULE link-layer security 1089 Examination of the threat analysis and security requirements in 1090 sections 3 and 4 has shown that there is a need to provide 1091 security in MPEG-2 transmission networks employing ULE. This 1092 section compares the disadvantages when security functionalities 1093 are present in different layers. 1095 B.1 Security at the IP layer (using IPsec) 1097 The security architecture for the Internet Protocol [RFC4301] 1098 describes security services for traffic at the IP layer. This 1099 architecture primarily defines services for the Internet Protocol 1100 (IP) unicast packets, as well as manually configured IP multicast 1101 packets. 1103 It is possible to use IPsec to secure ULE links. The major 1104 advantage of IPsec is its wide implementation in IP routers and 1105 hosts. IPsec in transport mode can be used for end-to-end 1106 security transparently over MPEG-2 transmission links with little 1107 impact. 1109 In the context of MPEG-2 transmission links, if IPsec is used to 1110 secure a ULE link, then the ULE Encapsulator and Receivers are 1111 equivalent to the security gateways in IPsec terminology. A 1112 security gateway implementation of IPsec uses tunnel mode. Such 1113 usage has the following disadvantages: 1115 o There is an extra transmission overhead associated with using 1116 IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 1118 o There is a need to protect the identity (NPA) of ULE Receivers 1119 over the ULE broadcast medium; IPsec is not suitable for 1120 providing this service. In addition, the interfaces of these 1121 devices do not necessarily have IP addresses (they can be L2 1122 devices). 1124 o Multicast is considered a major service over ULE links. The 1125 current IPsec specifications [RFC4301] only define a pairwise 1126 tunnel between two IPsec devices with manual keying. Work is 1127 in progress in defining the extra detail needed for multicast 1128 and to use the tunnel mode with address preservation to allow 1129 efficient multicasting. For further details refer to [WEIS06]. 1131 B.2 Link security below the encapsulation layer 1133 Link layer security can be provided at the MPEG-2 TS layer (below 1134 ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a 1135 specific PID value. However, an MPEG-2 TS may typically multiplex 1136 several IP flows, belonging to different users, using a common 1137 PID. Therefore all multiplexed traffic will share the same 1138 security keys. 1140 This has the following advantages: 1142 o The bit stream sent on the broadcast network does not expose 1143 any L2 or L3 headers, specifically all addresses, type fields, 1144 and length fields are encrypted prior to transmission. 1146 o This method does not preclude the use of IPsec, TLS, or any 1147 other form of higher-layer security. 1149 However it has the following disadvantages: 1151 o When a PID is shared between several users, each ULE Receiver 1152 needs to decrypt all MPEG-2 TS Packets with a matching PID, 1153 possibly including those that are not required to be 1154 forwarded. Therefore it does not have the flexibility to 1155 separately secure individual IP flows. 1157 o When a PID is shared between several users, the ULE Receivers 1158 will have access to private traffic destined to other ULE 1159 Receivers, since they share a common PID and key. 1161 o IETF-based key management that is very flexible and secure is 1162 not used in existing MPEG-2 based systems. Existing access 1163 control mechanisms in such systems have limited flexibility in 1164 terms of controlling the use of key and rekeying. Therefore if 1165 the key is compromised, then this will impact several ULE 1166 Receivers. 1168 Currently there are few deployed L2 security systems for MPEG-2 1169 transmission networks. Conditional access for digital TV 1170 broadcasting is one example. However, this approach is optimised 1171 for TV services and is not well-suited to IP packet transmission. 1172 Some other systems are specified in standards such as MPE [ETSI- 1173 DAT], but there are currently no known implementations. 1175 B.3 Link security as a part of the encapsulation layer 1177 Examining the threat analysis in section 3 has shown that 1178 protection of ULE link from eavesdropping and ULE Receiver 1179 identity are major requirements. 1181 There are several major advantages in using ULE link layer 1182 security: 1184 o The protection of the complete ULE Protocol Data Unit (PDU) 1185 including IP addresses. The protection can be applied either 1186 per IP flow or per Receiver NPA address. 1188 o Ability to protect the identity of the Receiver within the 1189 MPEG-2 transmission network at the IP layer and also at L2. 1191 o Efficient protection of IP multicast over ULE links. 1193 o Transparency to the use of Network Address Translation (NATs) 1194 [RFC3715] and TCP Performance Enhancing Proxies (PEP) 1195 [RFC3135], which require the ability to inspect and modify the 1196 packets sent over the ULE link. 1198 This method does not preclude the use of IPsec at L3 (or TLS 1199 [RFC4346] at L4). IPsec and TLS provide strong authentication of 1200 the end-points in the communication. 1202 L3 end-to-end security would partially deny the advantage listed 1203 just above (use of PEP, compression etc), since those techniques 1204 could only be applied to TCP packets bearing a TCP-encapsulated 1205 IPsec packet exchange, but not the TCP packets of the original 1206 applications, which in particular inhibits compression. 1208 End-to-end security (IPsec, TLS, etc.) may be used independently 1209 to provide strong authentication of the end-points in the 1210 communication. This authentication is desirable in many scenarios 1211 to ensure that the correct information is being exchanged between 1212 the trusted parties, whereas Layer 2 methods cannot provide this 1213 guarantee. 1215 >>> NOTE to RFC Editor: Please remove this appendix prior to 1216 publication] 1218 Document History 1220 Working Group Draft 00 1222 o Fixed editorial mistakes and ID style for WG adoption. 1224 Working Group Draft 01 1226 o Fixed editorial mistakes and added an appendix which shows the 1227 preliminary framework for securing the ULE network. 1229 Working Group Draft 02 1231 o Fixed editorial mistakes and added some important changes as 1232 pointed out by Knut Eckstein (ESA), Gorry Fairhurst and 1233 UNISAL. 1235 o Added section 4.1 on GSE. Extended the security considerations 1236 section. 1238 o Extended the appendix to show the extension header placement. 1240 o The definition of the header patterns for the ULE Security 1241 databases will be defined in a separate draft. 1243 o Need to include some words on key management transport over 1244 air interfaces, actually key management bootstrapping. 1246 Working Group Draft 03 1248 o Fixed editorial mistakes and added some important changes as 1249 pointed out by Gorry Fairhurst. 1251 o Table 1 added in Section 6.2 to list the different security 1252 techniques to mitigate the various possible network threats. 1254 o Figure 2 modified to clearly explain the different interfaces 1255 present in the framework. 1257 o New Section 7 has been added. 1259 o New Section 6 has been added. 1261 o The previous sections 5 and 6 have been combined to section 5. 1263 o Sections 3, 8 and 9 have been rearranged and updated with 1264 comments and suggestions from Michael Noisternig from 1265 University of Salzburg. 1267 o The Authors and the Acknowledgments section have been updated. 1269 Working Group Draft 04 1271 o Fixed editorial mistakes and added some important changes as 1272 pointed out by DVB-GBS group, Gorry Fairhurst and Laurence 1273 Duquerroy. 1275 o Table 1 modified to have consistent use of Security Services. 1277 o Text modified to be consistent with the draft-ietf-ipdvb-ule- 1278 ext-04.txt 1280 Working Group Draft 06 1282 o Fixed editorial mistakes and added some important changes as 1283 pointed out by Pat Cain and Gorry Fairhurst. 1285 o Figure 1 modified to have consistent use of Security Services. 1287 o Text modified in Section 4 to clearly state the requirements. 1289 o Moved Section 5 to the Appendix B 1291 o Updated IANA consideration section 1293 o Numbered the different requirements and cross referenced them 1294 within the text.