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