idnits 2.17.1 draft-ietf-ipdvb-sec-req-05.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 1013. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1031. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1037. 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.) -- The document date (November 18, 2007) is 6004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-ipdvb-ule-ext-06 -- 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: April 12, 2008 University of Bradford, UK 6 November 18, 2007 8 Security requirements for the Unidirectional Lightweight 9 Encapsulation (ULE) protocol 10 draft-ietf-ipdvb-sec-req-05.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 May 12, 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.......................................4 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. Motivation for ULE link-layer security.....................13 62 5.1. Security at the IP layer (using IPSEC)................13 63 5.2. Link security below the Encapsulation layer...........14 64 5.3. Link security as a part of the encapsulation layer....15 65 6. Design recommendations for ULE Security Header Extension...16 66 7. Compatibility with Generic Stream Encapsulation............17 67 8. Summary....................................................17 68 9. Security Considerations....................................18 69 10. IANA Considerations.......................................18 70 11. Acknowledgments...........................................18 71 12. References................................................19 72 12.1. Normative References.................................19 73 12.2. Informative References...............................19 74 13. Author's Addresses........................................21 75 14. IPR Notices...............................................21 76 14.1. Intellectual Property Statement......................21 77 14.2. Intellectual Property................................22 78 15. Copyright Statement.......................................22 79 Appendix A: ULE Security Framework............................22 80 Document History..............................................28 82 1. Introduction 84 The MPEG-2 Transport Stream (TS) has been widely accepted not 85 only for providing digital TV services, but also as a subnetwork 86 technology for building IP networks. RFC 4326 [RFC4326] describes 87 the Unidirectional Lightweight Encapsulation (ULE) mechanism for 88 the transport of IPv4 and IPv6 Datagrams and other network 89 protocol packets directly over the ISO MPEG-2 Transport Stream as 90 TS Private Data. ULE specifies a base encapsulation format and 91 supports an extension format that allows it to carry additional 92 header information to assist in network/Receiver processing. The 93 encapsulation satisfies the design and architectural requirement 94 for a lightweight encapsulation defined in RFC 4259 [RFC4259]. 96 Section 3.1 of RFC 4259 presents several topological scenarios 97 for MPEG-2 Transmission Networks. A summary of these scenarios 98 are presented below (for full detail, please refer to RFC 4259): 100 1. Broadcast TV and Radio Delivery. 102 2. Broadcast Networks used as an ISP. This resembles to scenario 103 1, but includes the provision of IP services providing access 104 to the public Internet. 106 3. Unidirectional Star IP Scenario. It utilizes a Hub station to 107 provide a data network delivering a common bit stream to 108 typically medium-sized groups of Receivers. 110 4. Datacast Overlay. It employs MPEG-2 physical and link layers 111 to provide additional connectivity such as unidirectional 112 multicast to supplement an existing IP-based Internet service. 114 5. Point-to-Point Links. 116 6. Two-Way IP Networks. This can be typically satellite-based and 117 star-based utilising a Hub station to deliver a common bit 118 stream to medium- sized groups of receivers. A bidirectional 119 service is provided over a common air-interface. 121 RFC 4259 states that ULE must be robust to errors and security 122 threats. Security must also consider both unidirectional as well 123 as bidirectional links for the scenarios mentioned above. 125 An initial analysis of the security requirements in MPEG-2 126 transmission networks is presented in the security considerations 127 section of RFC 4259. For example, when such networks are not 128 using a wireline network, the normal security issues relating to 129 the use of wireless links for transport of Internet traffic 130 should be considered [RFC3819]. 132 The security considerations of RFC 4259 recommends that any new 133 encapsulation defined by the IETF should allow Transport Stream 134 encryption and should also support optional link-layer 135 authentication of the SNDU payload. In ULE [RFC4326], it is 136 suggested that this may be provided in a flexible way using 137 Extension Headers. This requires the definition of a mandatory 138 header extension, but has the advantage that it decouples 139 specification of the security functions from the encapsulation 140 functions. 142 This document extends the above analysis and derives a detailed 143 the security requirements for ULE in MPEG-2 transmission 144 networks. 146 A security framework for deployment of secure ULE networks 147 describing the different building blocks and the interface 148 definitions is presented in Appendix A. 150 2. Requirements notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 153 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 RFC2119 [RFC2119]. 157 Other terms used in this document are defined below: 159 ATSC: Advanced Television Systems Committee. A framework and a 160 set of associated standards for the transmission of video, audio, 161 and data using the ISO MPEG-2 standard. 163 DVB: Digital Video Broadcast. A framework and set of associated 164 standards published by the European Telecommunications Standards 165 Institute (ETSI) for the transmission of video, audio, and data 166 using the ISO MPEG-2 Standard [ISO-MPEG2]. 168 Encapsulator: A network device that receives PDUs and formats 169 these into Payload Units (known here as SNDUs) for output as a 170 stream of TS Packets. 172 LLC: Logical Link Control [ISO-8802, IEEE-802]. A link-layer 173 protocol defined by the IEEE 802 standard, which follows the 174 Ethernet Medium Access Control Header. 176 MAC: Message Authentication Code. 178 MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that 179 encapsulates PDUs, forming a DSM-CC Table Section. Each Section 180 is sent in a series of TS Packets using a single TS Logical 181 Channel. 183 MPEG-2: A set of standards specified by the Motion Picture 184 Experts Group (MPEG) and standardized by the International 185 Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T 186 (in H.222 [ITU-H222]). 188 NPA: Network Point of Attachment. In this document, refers to a 189 6-byte destination address (resembling an IEEE Medium Access 190 Control address) within the MPEG-2 transmission network that is 191 used to identify individual Receivers or groups of Receivers. 193 PDU: Protocol Data Unit. Examples of a PDU include Ethernet 194 frames, IPv4 or IPv6 datagrams, and other network packets. 196 PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in 197 the header of TS Packets. This is used to identify the TS 198 Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS 199 Packets forming the parts of a Table Section, PES, or other 200 Payload Unit must all carry the same PID value. The all-zeros 201 PID 0x0000 as well as other PID values is reserved for specific 202 PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 203 indicates a Null TS Packet introduced to maintain a constant bit 204 rate of a TS Multiplex. There is no required relationship 205 between the PID values used for TS Logical Channels transmitted 206 using different TS Multiplexes. 208 Receiver: Equipment that processes the signal from a TS Multiplex 209 and performs filtering and forwarding of encapsulated PDUs to the 210 network-layer service (or bridging module when operating at the 211 link layer). 213 SI Table: Service Information Table [ISO-MPEG2]. In this 214 document, this term describes a table that is defined by another 215 standards body to convey information about the services carried 216 in a TS Multiplex. A Table may consist of one or more Table 217 Sections; however, all sections of a particular SI Table must be 218 carried over a single TS Logical Channel [ISO-MPEG2]. 220 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 221 Payload Unit. 223 TS: Transport Stream [ISO-MPEG2], a method of transmission at the 224 MPEG-2 layer using TS Packets; it represents layer 2 of the 225 ISO/OSI reference model. See also TS Logical Channel and TS 226 Multiplex. 228 TS Multiplex: In this document, this term defines a set of MPEG-2 229 TS Logical Channels sent over a single lower-layer connection. 230 This may be a common physical link (i.e., a transmission at a 231 specified symbol rate, FEC setting, and transmission frequency) 232 or an encapsulation provided by another protocol layer (e.g., 233 Ethernet, or RTP over IP). The same TS Logical Channel may be 234 repeated over more than one TS Multiplex (possibly associated 235 with a different PID value) [RFC4259]; for example, to 236 redistribute the same multicast content to two terrestrial TV 237 transmission cells. 239 TS Packet: A fixed-length 188B unit of data sent over a TS 240 Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus 241 optional overhead including an Adaptation Field, encryption 242 details, and time stamp information to synchronise a set of 243 related TS Logical Channels. 245 3. Threat Analysis 247 3.1. System Components 249 +------------+ +------------+ 250 | IP | | IP | 251 | End Host | | End Host | 252 +-----+------+ +------------+ 253 | ^ 254 +------------>+---------------+ | 255 + IP | | 256 +-------------+ Encapsulator | | 257 SI-Data | +------+--------+ | 258 +-------+-------+ |MPEG-2 TS Logical Channel | 259 | MPEG-2 | | | 260 | SI Tables | | | 261 +-------+-------+ ->+------+--------+ | 262 | -->| MPEG-2 | . . . 263 +------------>+ Multiplexer | | 264 MPEG-2 TS +------+--------+ | 265 Logical Channel |MPEG-2 TS Mux | 266 | | 267 Other ->+------+--------+ | 268 MPEG-2 -->+ MPEG-2 | | 269 TS --->+ Multiplexer | | 270 ---->+------+--------+ | 271 |MPEG-2 TS Mux | 272 | | 273 +------+--------+ +------+-----+ 274 |Physical Layer | | MPEG-2 | 275 |Modulator +---------->+ Receiver | 276 +---------------+ MPEG-2 +------------+ 277 TS Mux 278 Figure 1: An example configuration for a unidirectional service 279 for IP transport over MPEG-2 [RFC4259]. 281 As shown in Figure 1 above (from section 3.3 of [RFC4259]), there 282 are several entities within the MPEG-2 transmission network 283 architecture. These include: 285 o ULE Encapsulation Gateways (the Encapsulator or ULE source) 286 o SI-Table signalling generator (input to the multiplexer) 288 o Receivers (the end points for ULE streams) 290 o TS multiplexers (including re-multiplexers) 292 o Modulators 294 In a MPEG-2 TS transmission network, the originating source of TS 295 Packets is either a L2 interface device (media encoder, 296 encapsulation gateway, etc) or a L2 network device (TS 297 multiplexer, etc). These devices may, but do not necessarily, 298 have an associated IP address. In the case of an encapsulation 299 gateway (e.g. ULE sender), the device may operate at L2 or Layer 300 3 (L3), and is not normally the originator of an IP traffic flow, 301 and usually the IP source address of the packets that it forwards 302 do not correspond to an IP address associated with the device. 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 a 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 a 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 [ID-AR] may 333 need to be broadcast (e.g. by an Encapsulation Gateway or other 334 device) to form the Layer 2 (L2) control plane. Examples of 335 signalling messages include the Program Association Table (PAT), 336 Program Map Table (PMT) and Network Information Table (NIT). In 337 existing MPEG-2 transmission networks, these messages are 338 broadcast in the clear (no encryption or integrity checks). The 339 integrity as well as authenticity of these messages is important 340 for correct working of the ULE network, i.e. supporting its 341 security objectives in the area of availability, in addition to 342 confidentiality and integrity. One method recently proposed [ID- 343 EXT] encapsulates these messages using ULE. In such cases all the 344 security requirements of this document apply in securing these 345 signalling messages. 347 ULE link security focuses only on the security between the ULE 348 Encapsulation Gateway (ULE source) and the Receiver. In many 349 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-point i.e. the IP Sources is required, 353 or users are concerned about loss of confidentiality, integrity 354 or authenticity of their communication data, they will have to 355 employ end-to-end network security mechanisms like IPSec or 356 Transport Layer Security (TLS). Governmental users may be forced 357 by regulations to employ specific, approved implementations of 358 those mechanisms. Hence for such cases the confidentiality and 359 integrity of the user data will already be taken care of 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 end- 366 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 can rely on security assumptions as of wired links. 370 ULE security could achieve this by protecting the vulnerable (in 371 terms of passive attacks) ULE link. 373 In contrast to the above, if a ULE Stream is used to directly 374 join networks which are considered physically secure, for example 375 branch offices to a central office, ULE link Security could be 376 the sole provider of confidentiality and integrity. In this 377 scenario, governmental users could still have to employ approved 378 cryptographic equipment at the network layer or above, unless a 379 manufacturer of ULE Link Security equipment obtains governmental 380 approval for their implementation. 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 considered the major threats. An example of such a threat is 390 an intruder monitoring the MPEG-2 transmission broadcast and then 391 extracting traffic information concerning the communication 392 between IP hosts using a link. Another example is of an intruder 393 trying to gain information about the communication parties by 394 monitoring their ULE Receiver NPA addresses; an intruder can gain 395 information by determining the layer 2 identity of the 396 communicating parties and the volume of their traffic. This is a 397 well-known issue in the security field; however it is more of a 398 problem in the case of broadcast networks such as MPEG-2 399 transmission networks because of the easy availability of 400 receiver hardware and the wide geographical span of the networks. 402 Active threats (or attacks) are, in general, more difficult to 403 implement successfully than passive threats, and usually require 404 more sophisticated resources and may require access to the 405 transmitter. Within the context of MPEG-2 transmission networks, 406 examples of active attacks are: 408 o Masquerading: An entity pretends to be a different entity. 409 This includes masquerading other users and subnetwork control 410 plane messages. 412 o Modification of messages in an unauthorised manner. 414 o Replay attacks: When an intruder sends some old (authentic) 415 messages to the Receiver. In the case of a broadcast link, 416 access to previous broadcast data is easy. 418 o Denial of Service attacks: When an entity fails to perform its 419 proper function or acts in a way that prevents other entities 420 from performing their proper functions. 422 The active threats mentioned above are major security concerns 423 for the Internet community [BELLOVIN]. Masquerading and 424 modification of IP packets are comparatively easy in an Internet 425 environment whereas such attacks are in fact much harder for 426 MPEG-2 broadcast links. This could for instance motivate the 427 mandatory use of sequence numbers in IPsec, but not for 428 synchronous links. This is further reflected in the security 429 requirements for Case 2 and 3 in section 4 below. 431 As explained in section 3.1, the PID associated with an 432 Elementary Stream can be modified (e.g. in some systems by 433 reception of an updated SI table, or in other systems until the 434 next announcement/discovery data is received). An attacker that 435 is able to modify the content of the received multiplex (e.g. 436 replay data and/or control information) could inject data locally 437 into the received stream with an arbitrary PID value. 439 3.3. Threat Scenarios 441 Analysing the topological scenarios for MPEG-2 Transmission 442 Networks in section 1, the security threat cases can be 443 abstracted into three cases: 445 o Case 1: Monitoring (passive threat). Here the intruder 446 monitors the ULE broadcasts to gain information about the ULE 447 data and/or tracking the communicating parties identities (by 448 monitoring the destination NPA). In this scenario, measures 449 must be taken to protect the ULE payload data and the identity 450 of ULE Receivers. 452 o Case 2: Locally conduct active attacks on the MPEG-TS 453 multiplex. Here an intruder is assumed to be sufficiently 454 sophisticated to over-ride the original transmission from the 455 ULE Encapsulation Gateway and deliver a modified version of 456 the MPEG-TS transmission to a single ULE Receiver or a small 457 group of Receivers (e.g. in a single company site). The MPEG-2 458 transmission network operator might not be aware of such 459 attacks. Measures must be taken to ensure ULE source 460 authentication and preventing replay of old messages. 462 o Case 3: Globally conduct active attacks on the MPEG-TS 463 multiplex. Here we assume an intruder is very sophisticated 464 and able to over-ride the whole MPEG-2 transmission multiplex. 465 The requirements here are similar to scenario 2. The MPEG-2 466 transmission network operator can usually identify such 467 attacks and may resort to some means to restore the original 468 transmission. 470 For both cases 2 and 3, there can be two sub cases: 472 Cruickshank et.al. Expires April 12, 2008 [Page 473 10] 474 o Insider attacks i.e. active attacks from adversaries in the 475 known of secret material. 477 o Outsider attacks i.e. active attacks from outside of a virtual 478 private network. 480 In terms of priority, case 1 is considered the major threat in 481 MPEG-2 transmission systems. Case 2 is likely to a lesser degree 482 within certain network configurations, especially when there are 483 insider attacks. Hence, protection against such active attacks 484 should be used only when such a threat is a real possibility. 485 Case 3 is envisaged to be less practical, because it will be very 486 difficult to pass unnoticed by the MPEG-2 transmission operator. 487 It will require restoration of the original transmission. The 488 assumption being here is that physical access to the network 489 components (multiplexers, etc) and/or connecting physical media 490 is secure. Therefore case 3 is not considered further in this 491 document. 493 4. Security Requirements for IP over MPEG-2 TS 495 From the threat analysis in section 3, the following security 496 requirements can be derived: 498 o Data confidentiality is the major requirement to mitigate 499 passive threats in MPEG-2 broadcast networks. 501 o Protection of Layer 2 NPA address. In broadcast networks this 502 protection can be used to prevent an intruder tracking the 503 identity of ULE Receivers and the volume of their traffic. 505 o Integrity protection and authentication of the ULE source is 506 required against active attacks described in section 3.2. 508 o Protection against replay attacks. This is required for the 509 active attacks described in section 3.2. 511 o Layer L2 ULE Source and Receiver authentication: This is 512 normally performed during the initial key exchange and 513 authentication phase, before the ULE Receiver can join a 514 secure session with the ULE Encapsulator (ULE source). This is 515 normally receiver to hub authentication and it could be either 516 unidirectional or bidirectional authentication based on the 517 underlying key management protocol. 519 Other general requirements are: 521 Cruickshank et.al. Expires April 12, 2008 [Page 522 11] 523 o Decoupling of ULE key management functions from ULE security 524 services such as encryption and source authentication. This 525 allows the independent development of both systems. 527 o Support for automated as well as manual insertion of keys and 528 policy into the relevant databases. 530 o Algorithm agility is needed. Changes in crypto algorithms, 531 hashes as they become obsolete should be updated without 532 affecting the overall security of the system. 534 o Traceability: To monitor transmission network using log files 535 to record the activities in the network and detect any 536 intrusion. 538 o Protection against loss of service (availability) through 539 malicious reconfiguration of system components (see Figure 1). 541 o Compatibility with other networking functions such as NAT 542 Network Address Translation (NAT) [RFC3715] or TCP 543 acceleration can be used in a wireless broadcast networks. 545 o Compatibility and operational with ULE extension headers i.e. 546 allow encryption of a compressed SNDU payload. 548 o 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 is 553 therefore 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 MUST be provided to prevent 561 monitoring of the ULE data (such as user information and IP 562 addresses). Protection of NPA addresses MAY be provided to 563 prevent tracking ULE Receivers and their communications. 565 o Case 2: In addition to case 1 requirements, new measures need 566 to be implemented such as authentication schemes using Message 567 Authentication Codes, digital signatures or TESLA [RFC4082] in 568 order to provide integrity protection and source 570 Cruickshank et.al. Expires April 12, 2008 [Page 571 12] 572 authentication, and using sequence numbers to protect against 573 replay attacks. In terms of outsider attacks, group 574 authentication using Message Authentication Codes should 575 provide the same level of security. This will significantly 576 reduce the ability of intruders to successfully inject their 577 own data into the MPEG-TS stream. However, scenario 2 threats 578 apply only in specific service cases, and therefore 579 authentication and protection against replay attacks are 580 OPTIONAL. Such measures incur additional transmission as well 581 as processing overheads. Moreover, intrusion detection systems 582 may also be needed by the MPEG-2 network operator. These 583 should best be coupled with perimeter security policy to 584 monitor most denial-of-service attacks. 586 o Case 3: As stated in section 3.3. The requirements here are 587 similar to Case 2 but since the MPEG-2 transmission network 588 operator can usually identify such attacks the constraints on 589 intrusion detections are less than in case 2. 591 5. Motivation for ULE link-layer security 593 Examination of the threat analysis and security requirements in 594 sections 3 and 4 has shown that there is a need to provide 595 security in MPEG-2 transmission networks employing ULE. This 596 section compares the disadvantages when security functionalities 597 are present in different layers. 599 5.1. Security at the IP layer (using IPSEC) 601 The security architecture for the Internet Protocol [RFC4301] 602 describes security services for traffic at the IP layer. This 603 architecture primarily defines services for the Internet Protocol 604 (IP) unicast packets, as well as manually configured IP multicast 605 packets. 607 It is possible to use IPsec to secure ULE links. The major 608 advantage of IPsec is its wide implementation in IP routers and 609 hosts. IPsec in transport mode can be used for end-to-end 610 security transparently over MPEG-2 transmission links with little 611 impact. 613 In the context of MPEG-2 transmission links, if IPsec is used to 614 secure a ULE link, then the ULE Encapsulator and Receivers are 615 equivalent to the security gateways in IPsec terminology. A 616 security gateway implementation of IPsec uses tunnel mode. Such 617 usage has the following disadvantages: 619 Cruickshank et.al. Expires April 12, 2008 [Page 620 13] 621 o There is an extra transmission overhead associated with using 622 IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 624 o There is a need to protect the identity (NPA) of ULE Receivers 625 over the ULE broadcast medium; IPsec is not suitable for 626 providing this service. In addition, the interfaces of these 627 devices do not necessarily have IP addresses (they can be L2 628 devices). 630 o Multicast is considered a major service over ULE links. The 631 current IPsec specifications [RFC4301] only define a pairwise 632 tunnel between two IPsec devices with manual keying. Work is 633 in progress in defining the extra detail needed for multicast 634 and to use the tunnel mode with address preservation to allow 635 efficient multicasting. For further details refer to [WEIS06]. 637 5.2. Link security below the Encapsulation layer 639 Link layer security can be provided at the MPEG-2 TS layer (below 640 ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a 641 specific PID value. However, an MPEG-2 TS may typically multiplex 642 several IP flows, belonging to different users, using a common 643 PID. Therefore all multiplexed traffic will share the same 644 security keys. 646 This has the following advantages: 648 o The bit stream sent on the broadcast network does not expose 649 any L2 or L3 headers, specifically all addresses, type fields, 650 and length fields are encrypted prior to transmission. 652 o This method does not preclude the use of IPsec, TLS, or any 653 other form of higher-layer security. 655 However it has the following disadvantages: 657 o When a PID is shared between several users, each ULE Receiver 658 needs to decrypt all MPEG-2 TS Packets with a matching PID, 659 possibly including those that are not required to be 660 forwarded. Therefore it does not have the flexibility to 661 separately secure individual IP flows. 663 o When a PID is shared between several users, the ULE Receivers 664 will have access to private traffic destined to other ULE 665 Receivers, since they share a common PID and key. 667 Cruickshank et.al. Expires April 12, 2008 [Page 668 14] 669 o IETF-based key management is not used in existing systems. 670 Existing access control mechanisms have limited flexibility in 671 terms of controlling the use of key and rekeying. Therefore if 672 the key is compromised, then this will impact several ULE 673 Receivers. 675 Currently there are few deployed L2 security systems for MPEG-2 676 transmission networks. Conditional access for digital TV 677 broadcasting is one example. However, this approach is optimised 678 for TV services and is not well-suited to IP packet transmission. 679 Some other systems are specified in standards such as MPE [ETSI- 680 DAT], but there are currently no known implementations. 682 5.3. Link security as a part of the encapsulation layer 684 Examining the threat analysis in section 3 has shown that 685 protection of ULE link from eavesdropping and ULE Receiver 686 identity are major requirements. 688 There are several major advantages in using ULE link layer 689 security: 691 o The protection of the complete ULE Protocol Data Unit (PDU) 692 including IP addresses. The protection can be applied either 693 per IP flow or per Receiver NPA address. 695 o Ability to protect the identity of the Receiver within the 696 MPEG-2 transmission network at the IP layer and also at L2. 698 o Efficient protection of IP multicast over ULE links. 700 o Transparency to the use of Network Address Translation (NATs) 701 [RFC3715] and TCP Performance Enhancing Proxies (PEP) 702 [RFC3135], which require the ability to inspect and modify the 703 packets sent over the ULE link. 705 This method does not preclude the use of IPsec at L3 (or TLS 706 [RFC4346] at L4). IPsec and TLS provide strong authentication of 707 the end-points in the communication. 709 L3 end-to-end security would partially deny the advantage listed 710 just above (use of PEP, compression etc), since those techniques 711 could only be applied to TCP packets bearing a TCP-encapsulated 712 IPsec packet exchange, but not the TCP packets of the original 713 applications, which in particular inhibits compression. 715 Cruickshank et.al. Expires April 12, 2008 [Page 716 15] 717 End-to-end security (IPsec, TLS, etc.) may be used independently 718 to provide strong authentication of the end-points in the 719 communication. This authentication is desirable in many scenarios 720 to ensure that the correct information is being exchanged between 721 the trusted parties, whereas Layer 2 methods cannot provide this 722 guarantee. 724 6. Design recommendations for ULE Security Header Extension 726 Table 1 below shows the threats that are applicable to ULE 727 networks and the relevant security mechanism to mitigate those 728 threats. This would help in the design of the ULE Security 729 extension header. For example this could help in the selection of 730 security fields in the ULE Security extension Header design. 731 Moreover the security services could also be grouped into 732 profiles based on different security requirements. One example is 733 to have a base profile which does payload encryption and identity 734 protection. The second profile could do the above as well as 735 source authentication. 737 Mitigation of Threat 738 ----------------------------------------------- 739 | Data | Data |Source |Data |Intru |Iden | 740 |Privacy | fresh |Authent|Integ |sion |tity | 741 | | ness |ication|rity |Dete |Prote | 742 | | | | |ction |ction | 743 Attack | | | | | | | 744 ---------------|--------|-------|-------|-------|-------|------| 745 | Monitoring | X | - | - | - | - | X | 746 |---------------------------------------------------------------| 747 | Masquerading | X | - | X | X | - | X | 748 |---------------------------------------------------------------| 749 | Replay Attacks| - | X | X | X | X | - | 750 |---------------------------------------------------------------| 751 | Dos Attacks | - | X | X | X | X | - | 752 |---------------------------------------------------------------| 753 | Modification | - | - | X | X | X | - | 754 | of Messages | | | | | | | 755 --------------------------------------------------------------- 756 Table 1: Security techniques to mitigate network threats 757 in ULE Networks. 758 A modular design to ULE Security may allow it to use and benefit 759 from IETF key management protocols, such as GSAKMP [RFC4535] and 760 GDOI [RFC3547] protocols defined by the IETF Multicast Security 761 (MSEC) working group. This does not preclude the use of other key 762 management methods in scenarios where this is more appropriate. 764 Cruickshank et.al. Expires April 12, 2008 [Page 765 16] 766 IPsec or TLS also provide a proven security architecture defining 767 key exchange mechanisms and the ability to use a range of 768 cryptographic algorithms. ULE security can make use of these 769 established mechanisms and algorithms. 771 7. Compatibility with Generic Stream Encapsulation 773 The [ID-EXT] document describes two new Header Extensions that 774 may be used with Unidirectional Link Encapsulation, ULE, 775 [RFC4326] and the Generic Stream Encapsulation (GSE) that has 776 been designed for the Generic Mode (also known as the Generic 777 Stream (GS)), offered by second-generation DVB physical layers, 778 and specifically for DVB-S2 [ID-EXT]. 780 The security threats and requirement presented in this document 781 are applicable to ULE and GSE encapsulations. It might be 782 desirable to authenticate some/all of the headers; such decision 783 can be part of the security policy for the MPEG-2 transmission 784 network. 786 8. Summary 788 This document analyses a set of threats and security 789 requirements. It also defines the requirements for ULE security 790 and states the motivation for link security as a part of the 791 Encapsulation layer. 793 ULE security includes a need to provide link-layer encryption and 794 ULE Receiver identity protection. There is an optional 795 requirement for link-layer authentication and integrity assurance 796 as well as protection against insertion of old (duplicated) data 797 into the ULE stream (i.e. replay protection). This is optional 798 because of the associated overheads for the extra features and 799 they are only required for specific service cases. 801 ULE link security (between a ULE Encapsulation Gateway to 802 Receivers) is considered as an additional security mechanism to 803 IPsec, TLS, and application layer end-to-end security, and not as 804 a replacement. It allows a network operator to provide similar 805 functions to that of IPsec, but in addition provides MPEG-2 806 transmission link confidentiality and protection of ULE Receiver 807 identity (NPA). End-to-end security mechanism may then be used 808 additionally and independently for providing strong 809 authentication of the end-points in the communication. 811 Annexe 1 describes a set of building blocks that may be used to 813 Cruickshank et.al. Expires April 12, 2008 [Page 814 17] 815 realise a framework that provides ULE security functions. 817 9. Security Considerations 819 Link-layer (L2) encryption of IP traffic is commonly used in 820 broadcast/radio links to supplement End-to-End security (e.g. 821 provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). 823 A common objective is to provide the same level of privacy as 824 wired links. It is recommended that an ISP or user provide end- 825 to-end security services based on well known mechanisms such as 826 IPsec or TLS. 828 This document provides a threat analysis and derives the security 829 requirements to provide link encryption and optional link-layer 830 integrity / authentication of the SNDU payload. 832 There are some security issues that were raised in RFC 4326 833 [RFC4326] that are not addressed in this document (out of scope) 834 such as: 836 o The security issue with un-initialised stuffing bytes. In 837 ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 839 o Integrity issues related to the removal of the LAN FCS in a 840 bridged networking environment. The removal for bridged 841 frames exposes the traffic to potentially undetected 842 corruption while being processed by the Encapsulator and/or 843 Receiver. 845 o There is a potential security issue when a Receiver receives a 846 PDU with two Length fields: The Receiver would need to 847 validate the actual length and the Length field and ensure 848 that inconsistent values are not propagated by the network. 850 10. IANA Considerations 852 This document does not define any protocol and does not require 853 any IANA assignments but a subsequent document that defines a 854 layer 2 security extension to ULE will require IANA involvement. 856 11. Acknowledgments 858 The authors acknowledge the help and advice from Gorry Fairhurst 859 (University of Aberdeen). The authors also acknowledge 860 contributions from Laurence Duquerroy and Stephane Coombes (ESA), 862 Cruickshank et.al. Expires April 12, 2008 [Page 863 18] 864 Yim Fun Hu (University of Bradford) and Michael Noisternig from 865 University of Salzburg. 867 12. References 869 12.1. Normative References 871 [ISO-MPEG2] "Information technology -- generic coding of moving 872 pictures and associated audio information systems, 873 Part I", ISO 13818-1, International Standards 874 Organisation (ISO), 2000. 876 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 1997. 879 12.2. Informative References 881 [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution 882 Mechanisms for IP Datagrams over MPEG-2 Networks", 883 Work in Progress , June 2006, IETF Work in 939 Progress. 941 [RFC3715] B. Aboba and W Dixson, "IPsec-Network Address 942 Translation (NAT) Compatibility Requirements" IETF 943 RFC 3715, March 2004. 945 [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security 946 (TLS) Protocol Version 1.1", IETF RFC 4346, April 947 2006. 949 [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing 950 Proxies Intended to Mitigate Link-Related 951 Degradations", IETF RFC 3135, June 2001. 953 [RFC4301] Kent, S. and Seo K., "Security Architecture for the 954 Internet Protocol", IETF RFC 4301, December 2006. 956 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 957 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., 958 and L. Wood, "Advice for Internet Subnetwork 960 Cruickshank et.al. Expires April 12, 2008 [Page 961 20] 962 Designers", BCP 89, IETF RFC 3819, July 2004. 964 [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) 965 Protocol Architecture", IETF RFC 4251, January 2006. 967 13. Author's Addresses 969 Haitham Cruickshank 970 Centre for Communications System Research (CCSR) 971 University of Surrey 972 Guildford, Surrey, GU2 7XH 973 UK 974 Email: h.cruickshank@surrey.ac.uk 976 Sunil Iyengar 977 Centre for Communications System Research (CCSR) 978 University of Surrey 979 Guildford, Surrey, GU2 7XH 980 UK 981 Email: S.Iyengar@surrey.ac.uk 983 Prashant Pillai 984 Mobile and Satellite Communications Research Centre (MSCRC) 985 School of Engineering, Design and Technology 986 University of Bradford 987 Richmond Road, Bradford BD7 1DP 988 UK 989 Email: p.pillai@bradford.ac.uk 991 14. IPR Notices 993 Copyright (c) The IETF Trust (2007). 995 14.1. Intellectual Property Statement 997 Full Copyright Statement 999 Copyright (C) The IETF Trust (2007). 1001 This document is subject to the rights, licenses and restrictions 1002 contained in BCP 78, and except as set forth therein, the authors 1003 retain all their rights. 1005 Cruickshank et.al. Expires April 12, 2008 [Page 1006 21] 1007 This document and the information contained herein are provided on an 1008 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1009 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1010 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1011 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1012 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1013 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1015 Intellectual Property 1017 The IETF takes no position regarding the validity or scope of any 1018 Intellectual Property Rights or other rights that might be claimed to 1019 pertain to the implementation or use of the technology described in 1020 this document or the extent to which any license under such rights 1021 might or might not be available; nor does it represent that it has 1022 made any independent effort to identify any such rights. Information 1023 on the procedures with respect to rights in RFC documents can be 1024 found in BCP 78 and BCP 79. 1026 Copies of IPR disclosures made to the IETF Secretariat and any 1027 assurances of licenses to be made available, or the result of an 1028 attempt made to obtain a general license or permission for the use of 1029 such proprietary rights by implementers or users of this 1030 specification can be obtained from the IETF on-line IPR repository at 1031 http://www.ietf.org/ipr. 1033 The IETF invites any interested party to bring to its attention any 1034 copyrights, patents or patent applications, or other proprietary 1035 rights that may cover technology that may be required to implement 1036 this standard. Please address the information to the IETF at 1037 ietf-ipr@ietf.org. 1039 Appendix A: ULE Security Framework 1041 This section defines a security framework for the deployment of 1042 secure ULE networks. 1044 A.1 Building Blocks 1046 This ULE Security framework defines the following building blocks 1048 Cruickshank et.al. Expires April 12, 2008 [Page 1049 22] 1050 as shown in figure 2 below: 1052 o The Key Management Block 1054 o The ULE Security Extension Header Block 1056 o The ULE Databases Block 1058 Within the Key Management block the communication between the 1059 Group Member entity and the Group Server entity happens in the 1060 control plane. The ULE Security header block applies security to 1061 the ULE SNDU and this happens in the ULE data plane. The ULE 1062 Security databases block acts as the interface between the Key 1063 management block (control plane) and the ULE Security Header 1064 block (ULE data plane) as shown in figure 2. 1066 ------ 1067 +------+----------+ +----------------+ / \ 1068 | Key Management |/---------\| Key Management | | 1069 | Block |\---------/| Block | | 1070 | Group Member | | Group Server | Control 1071 +------+----------+ +----------------+ Plane 1072 | | | 1073 | | | 1074 | | \ / 1075 ----------- Key management <-> ULE Security databases ----- 1076 | | 1077 \ / 1078 +------+----------+ 1079 | ULE | 1080 | SAD / SPD | 1081 | Databases | 1082 | Block | 1083 +------+-+--------+ 1084 / \ 1085 | | 1086 ----------- ULE Security databases <-> ULE Security Header ---- 1087 | | / \ 1088 | | | 1089 | | | 1090 +------+-+--------+ ULE Data 1091 | ULE Security | Plane 1092 | Extension Header| | 1093 | Block | | 1094 +-----------------+ \ / 1095 ----- 1097 Cruickshank et.al. Expires April 12, 2008 [Page 1098 23] 1099 Figure 2: Secure ULE Framework Building Blocks 1101 A.1.1 Key Management Block 1103 A key management framework is required to provide security at the 1104 ULE level using extension headers. This key management framework 1105 is responsible for user authentication, access control, and 1106 Security Association negotiation (which include the negotiations 1107 of the security algorithms to be used and the generation of the 1108 different session keys as well as policy material). The Key 1109 management framework can be either automated or manual. Hence 1110 this key management client entity (shown as the Key Management 1111 Group Member block in figure 2) will be present in all ULE 1112 receivers as well as at the ULE sources (encapsulation gateways). 1113 The ULE source could also be the Key Management Group Server 1114 Entity (shown as the Key Management Group Server block in figure 1115 2. This happens when the ULE source also acts as the Key 1116 Management Group Server. Deployment may use either automated key 1117 management protocols (e.g. GSAKMP [RFC4535]) or manual insertion 1118 of keying material. 1120 A.1.2 ULE Extension Header Block 1122 A new security extension header for the ULE protocol is required 1123 to provide the security features of data confidentiality, data 1124 integrity, data authentication and mechanisms to prevent replay 1125 attacks. Security keying material will be used for the different 1126 security algorithms (for encryption/decryption, MAC generation, 1127 etc.), which are used to meet the security requirements, 1128 described in detail in Section 4 of this document. 1130 This block will use the keying material and policy information from 1131 the ULE security database block on the ULE payload to generate the 1132 secure ULE Extension Header or to decipher the secure ULE extension 1133 header to get the ULE payload. An example overview of the ULE 1134 Security extension header format along with the ULE header and 1135 payload is shown in figure 3 below. There could be other extension 1136 headers (either mandatory or optional). It is RECOMMENDED that these 1137 are placed after the security extension header. This permits full 1138 protection for all headers. It avoids situations where the SNDU has 1139 to be discarded on processing the security extension header, while 1140 preceding headers have already have been evaluated. One exception is 1141 the Timestamp extension which SHOULD precede the security extension 1143 Cruickshank et.al. Expires April 12, 2008 [Page 1144 24] 1145 header [ID-EXT].. When applying the security services for example 1146 confidentiality, input to the cipher algorithm will cover the fields 1147 from the end of the security extension header to the end of the PDU. 1149 Cruickshank et.al. Expires April 12, 2008 [Page 1150 25] 1151 +-------+------+-------------------------------+------+ 1152 | ULE |SEC | Protocol Data Unit | | 1153 |Header |Header| |CRC-32| 1154 +-------+------+-------------------------------+------+ 1155 Figure 3: ULE Security Header Extension Placement 1157 A.1.3 ULE Security Databases Block 1159 There needs to be two databases i.e. similar to the IPSec 1160 databases. 1162 o ULE-SAD: ULE Secure Association Database contains all the 1163 Security Associations that are currently established with 1164 different ULE peers. 1166 o ULE-SPD: ULE Secure Policy Database contains the policies as 1167 defined by the system manager. These policies describe the 1168 security services that must be enforced 1170 The design of these two databases will be based on IPSec 1171 databases as defined in RFC4301 [RFC4301]. 1173 The exact details of the header patterns that the SPD and SAD 1174 will have to support for all use cases will be defined in a 1175 separate document. This document only highlights the need for 1176 such interfaces between the ULE data plane and the Key Management 1177 control plane. 1179 A.2 Interface definition 1181 Two new interfaces have to be defined between the blocks as shown 1182 in Figure 2 above. These interfaces are: 1184 o Key Management block <-> ULE Security databases block 1186 o ULE Security databases block <-> ULE Security Header block 1188 While the first interface is used by the Key Management Block to 1189 insert keys, security associations and policies into the ULE 1190 Database Block, the second interface is used by the ULE Security 1191 Extension Header Block to get the keys and policy material for 1192 generation of the security extension header. 1194 A.2.1 Key Management <-> ULE Security databases 1196 This interface is between the Key Management group member block 1198 Cruickshank et.al. Expires April 12, 2008 [Page 1199 26] 1200 (GM client) and the ULE Security Database block (shown in figure 1201 2). The Key Management GM entity will communicate with the GCKS 1202 and then get the relevant security information (keys, cipher 1203 mode, security service, ULE_Security_ID and other relevant keying 1204 material as well as policy) and insert this data into the ULE 1205 Security database block. The Key Management could be either 1206 automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually 1207 inserted using this interface. The following three interface 1208 functions are defined: 1210 . Insert_record_database (char * Database, char * record, char * 1211 Unique_ID); 1212 . Update_record_database (char * Database, char * record, char * 1213 Unique_ID); 1214 . Delete_record_database (char * Database, char * Unique_ID); 1216 The definitions of the variables are as follows: 1218 . Database - This is a pointer to the ULE Security databases 1219 . record - This is the rows of security attributes to be 1220 entered or modified in the above databases 1221 . Unique_ID - This is the primary key to lookup records (rows 1222 of security attributes) in the above databases 1224 A.2.2 ULE Security Databases <-> ULE Security Header 1226 This interface is between the ULE Security Database and the ULE 1227 Security Extension Header block as shown in figure 2. To send 1228 traffic, firstly the ULE encapsulator using the ULE_Security_ID, 1229 Destination Address and possibly the PID, searches the ULE 1230 Security Database for the relevant security record. It then uses 1231 the data in the record to create the ULE security extension 1232 header. For received traffic, the ULE decapsulator on receiving 1233 the ULE SNDU will first get the record from the Security Database 1234 using the ULE_Security_ID, the Destination Address and possibly 1235 the PID. It then uses this information to decrypt the ULE 1236 extension header. For both cases (either send or receive traffic) 1237 only one interface is needed since the only difference between 1238 the sender and receiver is the direction of the flow of traffic: 1240 . Get_record_database (char * Database, char * record, char * 1241 Unique_ID); 1243 Cruickshank et.al. Expires April 12, 2008 [Page 1244 27] 1245 >>> NOTE to RFC Editor: Please remove this appendix prior to 1246 publication] 1248 Document History 1250 Working Group Draft 00 1252 o Fixed editorial mistakes and ID style for WG adoption. 1254 Working Group Draft 01 1256 o Fixed editorial mistakes and added an appendix which shows the 1257 preliminary framework for securing the ULE network. 1259 Working Group Draft 02 1261 o Fixed editorial mistakes and added some important changes as 1262 pointed out by Knut Eckstein (ESA), Gorry Fairhurst and 1263 UNISAL. 1265 o Added section 4.1 on GSE. Extended the security considerations 1266 section. 1268 o Extended the appendix to show the extension header placement. 1270 o The definition of the header patterns for the ULE Security 1271 databases will be defined in a separate draft. 1273 o Need to include some words on key management transport over 1274 air interfaces, actually key management bootstrapping. 1276 Working Group Draft 03 1278 o Fixed editorial mistakes and added some important changes as 1279 pointed out by Gorry Fairhurst. 1281 o Table 1 added in Section 6.2 to list the different security 1282 techniques to mitigate the various possible network threats. 1284 o Figure 2 modified to clearly explain the different interfaces 1285 present in the framework. 1287 Cruickshank et.al. Expires April 12, 2008 [Page 1288 28] 1289 o New Section 7 has been added. 1291 o New Section 6 has been added. 1293 o The previous sections 5 and 6 have been combined to section 5. 1295 o Sections 3, 8 and 9 have been rearranged and updated with 1296 comments and suggestions from Michael Noisternig from 1297 University of Salzburg. 1299 o The Authors and the Acknowledgments section have been updated. 1301 Working Group Draft 04 1303 o Fixed editorial mistakes and added some important changes as 1304 pointed out by DVB-GBS group, Gorry Fairhurst and Laurence 1305 Duquerroy. 1307 o Table 1 modified to have consistent use of Security Services. 1309 o Text modified to be consistent with the draft-ietf-ipdvb-ule- 1310 ext-04.txt 1312 Cruickshank et.al. Expires April 12, 2008 [Page 1313 29]