draft-ietf-ipdvb-sec-req-09.txt   rfc5458.txt 
IPDVB Working Group H. Cruickshank
Internet-Draft University of Surrey, UK Network Working Group H. Cruickshank
Intended status: Informational P. Pillai Request for Comments: 5458 University of Surrey
Expires: Feb 22, 2009 University of Bradford, UK Category: Informational P. Pillai
University of Bradford
M. Noisternig M. Noisternig
University of Salzburg, Austria University of Salzburg
S. Iyengar S. Iyengar
Logica, UK Logica
23 August, 2008 Security Requirements for
the Unidirectional Lightweight Encapsulation (ULE) Protocol
Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-09.txt
Status of this Draft
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This memo provides information for the Internet community. It does
months and may be updated, replaced, or obsoleted by other not specify an Internet standard of any kind. Distribution of this
documents at any time. It is inappropriate to use Internet- memo is unlimited.
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/shadow.html document authors. All rights reserved.
This Internet-Draft will expire on February 22, 2009. This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The MPEG-2 standard defined by ISO 13818-1 supports a range of The MPEG-2 standard defined by ISO 13818-1 supports a range of
transmission methods for a range of services. This document transmission methods for a variety of services. This document
provides a threat analysis and derives the security requirements provides a threat analysis and derives the security requirements when
when using the Transport Stream, TS, to support an Internet using the Transport Stream, TS, to support an Internet network-layer
network-layer using Unidirectional Lightweight Encapsulation using Unidirectional Lightweight Encapsulation (ULE) defined in RFC
(ULE) defined in RFC4326. The document also provides the 4326. The document also provides the motivation for link-layer
motivation for link-layer security for a ULE Stream. A ULE Stream security for a ULE Stream. A ULE Stream may be used to send IPv4
may be used to send IPv4 packets, IPv6 packets, and other packets, IPv6 packets, and other Protocol Data Units (PDUs) to an
Protocol Data Units (PDUs) to an arbitrarily large number of arbitrarily large number of Receivers supporting unicast and/or
Receivers supporting unicast and/or multicast transmission. multicast transmission.
The analysis also describes applicability to the Generic Stream The analysis also describes applicability to the Generic Stream
Encapsulation (GSE) defined by the Digital Video Broadcasting Encapsulation (GSE) defined by the Digital Video Broadcasting (DVB)
(DVB) Project. Project.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1. Introduction ....................................................3
2. Requirements Notation ..................................... 4 2. Requirements Notation ...........................................4
3. Threat Analysis ........................................... 7 3. Threat Analysis .................................................7
3.1. System Components .................................... 7 3.1. System Components ..........................................7
3.2. Threats .............................................. 9 3.2. Threats ....................................................9
3.3. Threat Cases ........................................ 10 3.3. Threat Cases ..............................................10
4. Security Requirements for IP over MPEG-2 TS .............. 11 4. Security Requirements for IP over MPEG-2 TS ....................11
5. Design recommendations for ULE Security Extension Header . 14 5. Design Recommendations for ULE Security Extension Header .......14
6. Compatibility with Generic Stream Encapsulation .......... 15 6. Compatibility with Generic Stream Encapsulation ................15
7. Summary .................................................. 15 7. Summary ........................................................15
8. Security Considerations .................................. 15 8. Security Considerations ........................................15
9. IANA Considerations ...................................... 16 9. Acknowledgments ................................................16
10. Acknowledgments ......................................... 16 10. References ....................................................16
11. References .............................................. 16 10.1. Normative References .....................................16
11.1. Normative References ............................... 16 10.2. Informative References ...................................17
11.2. Informative References ............................. 17 Appendix A. ULE Security Framework ................................19
12. Author's Addresses ...................................... 18 A.1. Building Block ............................................19
13. Intellectual Property Statement ......................... 19 A.2. Interface Definition ......................................22
14. Full Copyright Statement ................................ 20 Appendix B. Motivation for ULE Link-Layer Security ................23
Appendix A: ULE Security Framework .......................... 20 B.1. Security at the IP Layer (Using IPsec) ....................23
Appendix B: Motivation for ULE link-layer security .......... 24 B.2. Link Security below the Encapsulation Layer ...............24
Document History ............................................ 28 B.3. Link Security as a Part of the Encapsulation Layer ........25
1. Introduction 1. Introduction
The MPEG-2 Transport Stream (TS) has been widely accepted not The MPEG-2 Transport Stream (TS) has been widely accepted not only
only for providing digital TV services, but also as a subnetwork for providing digital TV services, but also as a subnetwork
technology for building IP networks. RFC 4326 [RFC4326] describes technology for building IP networks. RFC 4326 [RFC4326] describes
the Unidirectional Lightweight Encapsulation (ULE) mechanism for the Unidirectional Lightweight Encapsulation (ULE) mechanism for the
the transport of IPv4 and IPv6 Datagrams and other network transport of IPv4 and IPv6 Datagrams and other network protocol
protocol packets directly over the ISO MPEG-2 Transport Stream as packets directly over the ISO MPEG-2 Transport Stream as TS Private
TS Private Data. ULE specifies a base encapsulation format and Data. ULE specifies a base encapsulation format and supports an
supports an Extension Header format that allows it to carry Extension Header format that allows it to carry additional header
additional header information to assist in network/Receiver information to assist in network/Receiver processing. The
processing. The encapsulation satisfies the design and encapsulation satisfies the design and architectural requirement for
architectural requirement for a lightweight encapsulation defined a lightweight encapsulation defined in RFC 4259 [RFC4259].
in RFC 4259 [RFC4259].
Section 3.1 of RFC 4259 presents several topological scenarios Section 3.1 of RFC 4259 presents several topological scenarios for
for MPEG-2 Transmission Networks. A summary of these scenarios MPEG-2 Transmission Networks. A summary of these scenarios is
are presented below (see section 3.1 of RFC 4259): presented below:
A. Broadcast TV and Radio Delivery. This is not within the scope A. Broadcast TV and Radio Delivery. This is not within the scope of
of this document. this document.
B. Broadcast Networks used as an ISP. This resembles scenario A, B. Broadcast Networks used as an ISP. This resembles scenario A, but
but includes IP services to access the public Internet. includes IP services to access the public Internet.
C. Unidirectional Star IP Scenario. This provides a data network C. Unidirectional Star IP Scenario. This provides a data network
delivering a common bit stream to typically medium-sized delivering a common bit stream to typically medium-sized groups of
groups of Receivers. Receivers.
D. Datacast Overlay. This employs MPEG-2 physical and link layers D. Datacast Overlay. This employs MPEG-2 physical and link layers to
to provide additional connectivity such as unidirectional provide additional connectivity such as unidirectional multicast
multicast to supplement an existing IP-based Internet service. to supplement an existing IP-based Internet service.
E. Point-to-Point Links. This connectivity may be provided using E. Point-to-Point Links. This connectivity may be provided using a
a pair of transmit and receive interfaces. pair of transmit and receive interfaces.
F. Two-Way IP Networks. F. Two-Way IP Networks.
RFC 4259 states that ULE must be robust to errors and security RFC 4259 states that ULE must be robust to errors and security
threats. Security must also consider both unidirectional (A, B, C threats. Security must also consider both unidirectional (A, B, C,
and D) as well as bidirectional (E and F) links for the scenarios and D) as well as bidirectional (E and F) links for the scenarios
mentioned above. mentioned above.
An initial analysis of the security requirements in MPEG-2 An initial analysis of the security requirements in MPEG-2
transmission networks is presented in the security considerations transmission networks is presented in the "Security Considerations"
section of RFC 4259. For example, when such networks are not section of RFC 4259. For example, when such networks are not using a
using a wireline network, the normal security issues relating to wireline network, the normal security issues relating to the use of
the use of wireless links for transport of Internet traffic wireless links for transport of Internet traffic should be considered
should be considered [RFC3819]. [RFC3819].
The security considerations of RFC 4259 recommend that any new The security considerations of RFC 4259 recommend that any new
encapsulation defined by the IETF should allow Transport Stream encapsulation defined by the IETF should allow Transport Stream
encryption and should also support optional link-layer encryption and should also support optional link-layer authentication
authentication of the SNDU payload. In ULE [RFC4326], it is of the Subnetwork Data Unit (SNDU) payload. In ULE [RFC4326], it is
suggested that this may be provided in a flexible way using suggested that this may be provided in a flexible way using Extension
Extension Headers. This requires the definition of a mandatory Headers. This requires the definition of a mandatory Extension
Extension Header, but has the advantage that it decouples Header, but has the advantage that it decouples specification of the
specification of the security functions from the encapsulation security functions from the encapsulation functions.
functions.
This document extends the above analysis and derives in detail This document extends the above analysis and derives in detail the
the security requirements for ULE in MPEG-2 transmission security requirements for ULE in MPEG-2 transmission networks.
networks.
A security framework for deployment of secure ULE networks A security framework for deployment of secure ULE networks describing
describing the different building blocks and the interface the different building blocks and the interface definitions is
definitions is presented in Appendix A. presented in Appendix A.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in RFC 2119 [RFC2119].
RFC2119 [RFC2119].
Other terms used in this document are defined below: Other terms used in this document are defined below:
ATSC: Advanced Television Systems Committee. A framework and a ATSC: Advanced Television Systems Committee. A framework and a set
set of associated standards for the transmission of video, audio, of associated standards for the transmission of video, audio, and
and data using the ISO MPEG-2 standard. data using the ISO MPEG-2 Standard.
DVB: Digital Video Broadcast. A framework and set of associated DVB: Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data Institute (ETSI) for the transmission of video, audio, and data using
using the ISO MPEG-2 Standard [ISO-MPEG2]. the ISO MPEG-2 Standard [ISO-MPEG2].
Encapsulator: A network device that receives PDUs and formats Encapsulator: A network device that receives Protocol Data Units
these into Payload Units (known here as SNDUs) for output as a (PDUs) and formats these into Payload Units (known here as SNDUs) for
stream of TS Packets. output as a stream of TS Packets.
GCKS: Group Controller and Key Server. A server that GCKS: Group Controller and Key Server. A server that authenticates
authenticates and provides the policy and keying material to and provides the policy and keying material to members of a secure
members of a secure group. group.
LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer
protocol defined by the IEEE 802 standard, which follows the protocol defined by the IEEE 802 standard, which follows the Ethernet
Ethernet Medium Access Control Header. Medium Access Control Header.
MAC: Message Authentication Code. MAC: Message Authentication Code.
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates PDUs, forming a DSM-CC Table Section. Each Section encapsulates PDUs, forming a Digital Storage Media Command and
is sent in a series of TS Packets using a single TS Logical Control (DSM-CC) Table Section. Each Section is sent in a series of
Channel. TS Packets using a single TS Logical Channel.
MPEG-2: A set of standards specified by the Motion Picture MPEG-2: A set of standards specified by the Motion Picture Experts
Experts Group (MPEG) and standardized by the International Group (MPEG) and standardised by the International Standards
Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222
(in H.222 [ITU-H222]). [ITU-H222]).
NPA: Network Point of Attachment. In this document, refers to a NPA: Network Point of Attachment. In this document, refers to a
6-byte destination address (resembling an IEEE Medium Access 6-byte destination address (resembling an IEEE Medium Access Control
Control address) within the MPEG-2 transmission network that is address) within the MPEG-2 transmission network that is used to
used to identify individual Receivers or groups of Receivers. identify individual Receivers or groups of Receivers.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
frames, IPv4 or IPv6 datagrams, and other network packets. IPv4 or IPv6 Datagrams, and other network packets.
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the
the header of TS Packets. This is used to identify the TS header of TS Packets. This is used to identify the TS Logical
Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
Packets forming the parts of a Table Section, PES, or other forming the parts of a Table Section, Packetised Elementary Stream
Payload Unit must all carry the same PID value. The all-zeros (PES), or other Payload Unit must all carry the same PID value. The
PID 0x0000 as well as other PID values are reserved for specific all-zeros PID 0x0000 as well as other PID values are reserved for
PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF
indicates a Null TS Packet introduced to maintain a constant bit indicates a Null TS Packet introduced to maintain a constant bit rate
rate of a TS Multiplex. There is no required relationship of a TS Multiplex. There is no required relationship between the PID
between the PID values used for TS Logical Channels transmitted values used for TS Logical Channels transmitted using different TS
using different TS Multiplexes. Multiplexes.
Receiver: Equipment that processes the signal from a TS Multiplex Receiver: Equipment that processes the signal from a TS Multiplex and
and performs filtering and forwarding of encapsulated PDUs to the performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the network-layer service (or bridging module when operating at the link
link layer). layer).
SI Table: Service Information Table [ISO-MPEG2]. In this SI Table: Service Information Table [ISO-MPEG2]. In this document,
document, this term describes a table that is defined by another this term describes a table that is defined by another standards body
standards body to convey information about the services carried to convey information about the services carried in a TS Multiplex.
in a TS Multiplex. A Table may consist of one or more Table A Table may consist of one or more Table Sections; however, all
Sections; however, all sections of a particular SI Table must be sections of a particular SI Table must be carried over a single TS
carried over a single TS Logical Channel [ISO-MPEG2]. Logical Channel [ISO-MPEG2].
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit. Payload Unit.
TS: Transport Stream [ISO-MPEG2], a method of transmission at the TS: Transport Stream [ISO-MPEG2]. A method of transmission at the
MPEG-2 layer using TS Packets; it represents layer 2 of the MPEG-2 layer using TS Packets; it represents Layer 2 of the ISO/OSI
ISO/OSI reference model. See also TS Logical Channel and TS reference model. See also TS Logical Channel and TS Multiplex.
Multiplex.
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Multiplex: In this document, this term defines a set of MPEG-2 TS
TS Logical Channels sent over a single lower-layer connection. Logical Channels sent over a single lower-layer connection. This may
This may be a common physical link (i.e., a transmission at a be a common physical link (i.e., a transmission at a specified symbol
specified symbol rate, FEC setting, and transmission frequency) rate, Forward Error Correction (FEC) setting, and transmission
or an encapsulation provided by another protocol layer (e.g., frequency) or an encapsulation provided by another protocol layer
Ethernet, or RTP over IP). The same TS Logical Channel may be (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be
repeated over more than one TS Multiplex (possibly associated repeated over more than one TS Multiplex (possibly associated with a
with a different PID value) [RFC4259]; for example, to different PID value) [RFC4259]; for example, to redistribute the same
redistribute the same multicast content to two terrestrial TV multicast content to two terrestrial TV transmission cells.
transmission cells.
TS Packet: A fixed-length 188B unit of data sent over a TS TS Packet: A fixed-length 188-byte unit of data sent over a TS
Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus Multiplex [ISO-MPEG2]. Each TS Packet carries a 4-byte header, plus
optional overhead including an Adaptation Field, encryption optional overhead including an Adaptation Field, encryption details,
details, and time stamp information to synchronise a set of and time stamp information to synchronise a set of related TS Logical
related TS Logical Channels. Channels.
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
encapsulated PDUs. ULE Streams may be identified by definition of encapsulated PDUs. ULE Streams may be identified by definition of a
a stream_type in SI/PSI [ISO-MPEG2]. stream_type in SI/PSI [ISO-MPEG2].
3. Threat Analysis 3. Threat Analysis
3.1. System Components 3.1. System Components
+------------+ +------------+ +------------+ +------------+
| IP | | IP | | IP | | IP |
| End Host | | End Host | | End Host | | End Host |
+-----+------+ +------------+ +-----+------+ +------------+
| ^ | ^
skipping to change at page 7, line 38 skipping to change at page 7, line 38
MPEG-2 -->+ MPEG-2 | | MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexer | | TS --->+ Multiplexer | |
---->+------+--------+ | ---->+------+--------+ |
|MPEG-2 TS Mux | |MPEG-2 TS Mux |
| | | |
+------+--------+ +------+-----+ +------+--------+ +------+-----+
|Physical Layer | | MPEG-2 | |Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver | |Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+ +---------------+ MPEG-2 +------------+
TS Mux TS Mux
Figure 1: An example configuration for a unidirectional service Figure 1: An example configuration for a unidirectional service
for IP transport over MPEG-2 (adapted from [RFC4259]). for IP transport over MPEG-2 (adapted from [RFC4259])
As shown in Figure 1 above (from section 3.3 of [RFC4259]), there As shown in Figure 1 above (from Section 3.3 of [RFC4259]), there are
are several entities within the MPEG-2 transmission network several entities within the MPEG-2 transmission network architecture.
architecture. These include: These include:
o ULE Encapsulation Gateways (the ULE Encapsulator) o ULE Encapsulation Gateways (the ULE Encapsulator)
o SI-Table signalling generator (input to the multiplexer) o SI-Table signalling generator (input to the multiplexer)
o Receivers (the endpoints for ULE Streams) o Receivers (the endpoints for ULE Streams)
o TS multiplexers (including re-multiplexers)
o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
The TS Packets are carried to the Receiver over a physical layer The TS Packets are carried to the Receiver over a physical layer that
that usually includes Forward Error Correction (FEC) coding that usually includes Forward Error Correction (FEC) coding that
interleaves the bytes of several consecutive, but unrelated, TS interleaves the bytes of several consecutive, but unrelated, TS
Packets. FEC-coding and synchronisation processing makes Packets. FEC-coding and synchronisation processing makes injection
injection of single TS Packets very difficult. Replacement of a of single TS Packets very difficult. Replacement of a sequence of
sequence of packets is also difficult, but possible (see section packets is also difficult, but possible (see Section 3.2).
3.2).
A Receiver in an MPEG-2 TS transmission network needs to identify A Receiver in an MPEG-2 TS transmission network needs to identify a
a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble the
the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2 fragments of PDUs sent by an L2 source [RFC4259]. In an MPEG-2 TS,
TS, this association is made via the Packet Identifier, PID [ISO- this association is made via the Packet Identifier, PID [ISO-MPEG2].
MPEG2]. At the sender, each source associates a locally unique At the sender, each source associates a locally unique set of PID
set of PID values with each stream it originates. However, there values with each stream it originates. However, there is no required
is no required relationship between the PID value used at the relationship between the PID value used at the sender and that
sender and that received at the Receiver. Network devices may re- received at the Receiver. Network devices may re-number the PID
number the PID values associated with one or more TS Logical values associated with one or more TS Logical Channels (e.g., ULE
Channels (e.g. ULE Streams) to prevent clashes at a multiplexer Streams) to prevent clashes at a multiplexer between input streams
between input streams with the same PID carried on different with the same PID carried on different input multiplexes (updating
input multiplexes (updating entries in the PMT [ISO-MPEG2], and entries in the PMT [ISO-MPEG2], and other SI tables that reference
other SI tables that reference the PID value). A device may also the PID value). A device may also modify and/or insert new SI data
modify and/or insert new SI data into the control plane (also into the control plane (also sent as TS Packets identified by their
sent as TS Packets identified by their PID value). However, there PID value). However, there is only one valid source of data for each
is only one valid source of data for each MPEG-2 Elementary MPEG-2 Elementary Stream, bound to a PID value. (This observation
Stream, bound to a PID value. (This observation could simplify could simplify the requirement for authentication of the source of a
the requirement for authentication of the source of a ULE ULE Stream.)
Stream.)
In an MPEG-2 network a set of signalling messages [RFC4947] may In an MPEG-2 network, a set of signalling messages [RFC4947] may need
need to be broadcast (e.g. by an Encapsulation Gateway or other to be broadcast (e.g., by an Encapsulation Gateway or other device)
device) to form the L2 control plane. Examples of signalling to form the L2 control plane. Examples of signalling messages
messages include the Program Association Table (PAT), Program Map include the Program Association Table (PAT), Program Map Table (PMT),
Table (PMT) and Network Information Table (NIT). In existing and Network Information Table (NIT). In existing MPEG-2 transmission
MPEG-2 transmission networks, these messages are broadcast in the networks, these messages are broadcast in the clear (no encryption or
clear (no encryption or integrity checks). The integrity as well integrity checks). The integrity as well as authenticity of these
as authenticity of these messages is important for correct messages is important for correct working of the ULE network, i.e.,
working of the ULE network, i.e. supporting its security supporting its security objectives in the area of availability, in
objectives in the area of availability, in addition to addition to confidentiality and integrity. One method recently
confidentiality and integrity. One method recently proposed proposed [RFC5163] encapsulates these messages using ULE. In such
[RFC5163] encapsulates these messages using ULE. In such cases cases all the security requirements of this document apply in
all the security requirements of this document apply in securing securing these signalling messages.
these signalling messages.
ULE Stream security only concerns the security between the ULE ULE Stream security only concerns the security between the ULE
Encapsulation Gateway (ULE Encapsulator) and the Receiver. In Encapsulation Gateway (ULE Encapsulator) and the Receiver. In many
many deployment scenarios the user of a ULE Stream has to secure deployment scenarios the user of a ULE Stream has to secure
communications beyond the link since other network links are communications beyond the link since other network links are utilised
utilised in addition to the ULE link. Therefore, if in addition to the ULE link. Therefore, if authentication of the
authentication of the end-points, i.e. the IP Sources is endpoints, i.e., the IP Sources, is required, or users are concerned
required, or users are concerned about loss of confidentiality, about loss of confidentiality, integrity, or authenticity of their
integrity, or authenticity of their communication data, they will communication data, they will have to employ end-to-end network
have to employ end-to-end network security mechanisms, e.g. IPsec security mechanisms, e.g., IPsec or Transport Layer Security (TLS).
or Transport Layer Security (TLS). Governmental users may be Governmental users may be forced by regulations to employ specific
forced by regulations to employ specific approved implementations approved implementations of those mechanisms. Hence, for such cases,
of those mechanisms. Hence for such cases, the requirements for the requirements for confidentiality and integrity of the user data
confidentiality and integrity of the user data will be met by the will be met by the end-to-end security mechanism and the ULE security
end-to-end security mechanism and the ULE security measures would measures would focus on providing traffic flow confidentiality either
focus on either providing traffic flow confidentiality for user for user data that has already been encrypted or for users who choose
data that has already been encrypted or for users who choose not not to implement end-to-end security mechanisms.
to implement end-to-end security mechanisms.
ULE links may also be used for communications where the two IP ULE links may also be used for communications where the two IP
end-points are not under central control (e.g., when browsing a endpoints are not under central control (e.g., when browsing a public
public web site). In these cases, it may be impossible to enforce web site). In these cases, it may be impossible to enforce any end-
any end-to-end security mechanisms. Yet, a common objective is to-end security mechanisms. Yet, a common objective is that users
that users may make the same security assumptions as for wired may make the same security assumptions as for wired links [RFC3819].
links [RFC3819]. ULE security could achieve this by protecting ULE security could achieve this by protecting the vulnerable (in
the vulnerable (in terms of passive attacks) ULE Stream. terms of passive attacks) ULE Stream.
In contrast to the above, a ULE Stream can be used to link In contrast to the above, a ULE Stream can be used to link networks
networks such as branch offices to a central office. ULE link- such as branch offices to a central office. ULE link-layer security
layer security could be the sole provider of confidentiality and could be the sole provider of confidentiality and integrity. In this
integrity. In this scenario, users requiring high assurance of scenario, users requiring high assurance of security (e.g.,
security (e.g. government use) will need to employ approved government use) will need to employ approved cryptographic equipment
cryptographic equipment (e.g. at the network layer). An (e.g., at the network layer). An implementation of ULE Link Security
implementation of ULE Link Security equipment could also be equipment could also be certified for use by specific user
certified for use by specific user communities. communities.
3.2. Threats 3.2. Threats
The simplest type of network threat is a passive threat. This The simplest type of network threat is a passive threat. This
includes eavesdropping or monitoring of transmissions, with a includes eavesdropping or monitoring of transmissions, with a goal to
goal to obtain information that is being transmitted. In obtain information that is being transmitted. In broadcast networks
broadcast networks (especially those utilising widely available (especially those utilising widely available low-cost physical layer
low-cost physical layer interfaces, such as DVB) passive threats interfaces, such as DVB), the passive threats are the major threats.
are the major threats. One example is an intruder monitoring the One example is an intruder monitoring the MPEG-2 transmission
MPEG-2 transmission broadcast and then extracting the data broadcast and then extracting the data carried within the link.
carried within the link. Another example is an intruder trying to Another example is an intruder trying to determine the identity of
determine the identity of the communicating parties and the the communicating parties and the volume of their traffic by sniffing
volume of their traffic by sniffing (L2) addresses. This is a (L2) addresses. This is a well-known issue in the security field;
well-known issue in the security field; however it is more of a however, it is more of a problem in the case of broadcast networks
problem in the case of broadcast networks such as MPEG-2 such as MPEG-2 transmission networks because of the easy availability
transmission networks because of the easy availability of of Receiver hardware and the wide geographical span of the networks.
Receiver hardware and the wide geographical span of the networks.
Active threats (or attacks) are, in general, more difficult to Active threats (or attacks) are, in general, more difficult to
implement successfully than passive threats, and usually require implement successfully than passive threats, and usually require more
more sophisticated resources and may require access to the sophisticated resources and may require access to the transmitter.
transmitter. Within the context of MPEG-2 transmission networks, Within the context of MPEG-2 transmission networks, examples of
examples of active attacks are: active attacks are:
o Masquerading: An entity pretends to be a different entity. o Masquerading: An entity pretends to be a different entity. This
This includes masquerading other users and subnetwork control includes masquerading other users and subnetwork control plane
plane messages. messages.
o Modification of messages in an unauthorised manner. o Modification of messages in an unauthorised manner.
o Replay attacks: When an intruder sends some old (authentic) o Replay attacks: When an intruder sends some old (authentic)
messages to the Receiver. In the case of a broadcast link, messages to the Receiver. In the case of a broadcast link, access
access to previous broadcast data is easy. to previous broadcast data is easy.
o Denial-of-Service (DoS) attacks: When an entity fails to o Denial-of-Service (DoS) attacks: When an entity fails to perform
perform its proper function or acts in a way that prevents its proper function or acts in a way that prevents other entities
other entities from performing their proper functions. from performing their proper functions.
The active threats mentioned above are major security concerns The active threats mentioned above are major security concerns for
for the Internet community [BELLOVIN]. Masquerading and the Internet community [BELLOVIN]. Masquerading and modification of
modification of IP packets are comparatively easy in an Internet IP packets are comparatively easy in an Internet environment, whereas
environment, whereas such attacks are in fact much harder for such attacks are in fact much harder for MPEG-2 broadcast links.
MPEG-2 broadcast links. This could for instance motivate the This could, for instance, motivate the mandatory use of sequence
mandatory use of sequence numbers in IPsec, but not for numbers in IPsec, but not for synchronous links. This is further
synchronous links. This is further reflected in the security reflected in the security requirements for Case 2 and 3 in Section 4
requirements for Case 2 and 3 in section 4 below. below.
As explained in section 3.1, the PID associated with an As explained in Section 3.1, the PID associated with an Elementary
Elementary Stream can be modified (e.g. in some systems by Stream can be modified (e.g., in some systems by reception of an
reception of an updated SI table, or in other systems until the updated SI table, or in other systems until the next
next announcement/discovery data is received). An attacker that announcement/discovery data is received). An attacker that is able
is able to modify the content of the received multiplex (e.g. to modify the content of the received multiplex (e.g., replay data
replay data and/or control information) could inject data locally and/or control information) could inject data locally into the
into the received stream with an arbitrary PID value. received stream with an arbitrary PID value.
3.3. Threat Cases 3.3. Threat Cases
Analysing the topological scenarios for MPEG-2 Transmission Analysing the topological scenarios for MPEG-2 Transmission Networks
Networks in section 1, the security threats can be abstracted in Section 1, the security threats can be abstracted into three
into three cases: cases:
o Case 1: Monitoring (passive threat). Here the intruder o Case 1: Monitoring (passive threat). Here the intruder monitors
monitors the ULE broadcasts to gain information about the ULE the ULE broadcasts to gain information about the ULE data and/or
data and/or tracking the communicating parties identities (by tracking the communicating parties identities (by monitoring the
monitoring the destination NPA address). In this scenario, destination NPA address). In this scenario, measures must be taken
measures must be taken to protect the ULE payload data and the to protect the ULE payload data and the identity of ULE Receivers.
identity of ULE Receivers.
o Case 2: Locally conduct active attacks on the MPEG-TS o Case 2: Locally conducting active attacks on the MPEG-TS multiplex.
multiplex. Here an intruder is assumed to be sufficiently Here an intruder is assumed to be sufficiently sophisticated to
sophisticated to over-ride the original transmission from the override the original transmission from the ULE Encapsulation
ULE Encapsulation Gateway and deliver a modified version of Gateway and deliver a modified version of the MPEG-TS transmission
the MPEG-TS transmission to a single ULE Receiver or a small to a single ULE Receiver or a small group of Receivers (e.g., in a
group of Receivers (e.g. in a single company site). The MPEG-2 single company site). The MPEG-2 transmission network operator
transmission network operator might not be aware of such might not be aware of such attacks. Measures must be taken to
attacks. Measures must be taken to ensure ULE data integrity ensure ULE data integrity and authenticity and preventing replay of
and authenticity and preventing replay of old messages. old messages.
o Case 3: Globally conduct active attacks on the MPEG-TS o Case 3: Globally conducting active attacks on the MPEG-TS
multiplex. This assumes a sophisticated intruder able to over- multiplex. This assumes a sophisticated intruder able to override
ride the whole MPEG-2 transmission multiplex. The requirements the whole MPEG-2 transmission multiplex. The requirements are
are similar to scenario 2. The MPEG-2 transmission network similar to case 2. The MPEG-2 transmission network operator can
operator can usually identify such attacks and provide usually identify such attacks and provide corrective action to
corrective action to restore the original transmission. restore the original transmission.
For both Cases 2 and 3, there can be two sub-cases: For both Cases 2 and 3, there can be two sub-cases:
o Insider attacks, i.e. active attacks from adversaries within o Insider attacks, i.e., active attacks from adversaries within the
the network with knowledge of the secret material. network with knowledge of the secret material.
o Outsider attacks, i.e. active attacks from adversaries without o Outsider attacks, i.e., active attacks from adversaries without
knowledge of the secret material. knowledge of the secret material.
In terms of priority, Case 1 is considered the major threat in In terms of priority, Case 1 is considered the major threat in MPEG-2
MPEG-2 transmission systems. Case 2 is considered a lesser transmission systems. Case 2 is considered a lesser threat,
threat, appropriate to specific network configurations, appropriate to specific network configurations, especially when
especially when vulnerable to insider attacks. Case 3 is less vulnerable to insider attacks. Case 3 is less likely to be found in
likely to be found in an operational network, and is expected to an operational network, and is expected to be noticed by the MPEG-2
be noticed by the MPEG-2 transmission operator. It will require transmission operator. It will require restoration of the original
restoration of the original transmission. The assumption being transmission. The assumption being that physical access to the
that physical access to the network components (multiplexers, network components (multiplexers, etc.) and/or connecting physical
etc.) and/or connecting physical media is secure. Therefore Case media is secure. Therefore, Case 3 is not considered further in this
3 is not considered further in this document. document.
4. Security Requirements for IP over MPEG-2 TS 4. Security Requirements for IP over MPEG-2 TS
From the threat analysis in section 3, the following security From the threat analysis in Section 3, the following security
requirements can be derived: requirements can be derived:
Req 1. Data confidentiality MUST be provided by a link that Req 1. Data confidentiality MUST be provided by a link that supports
supports ULE Stream Security to prevent passive attacks and ULE Stream Security to prevent passive attacks and reduce the risk
reduce the risk of active threats. of active threats.
Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast
networks this protection can be used to prevent an intruder networks, this protection can be used to prevent an intruder
tracking the identity of ULE Receivers and the volume of their tracking the identity of ULE Receivers and the volume of their
traffic. traffic.
Req 3. Integrity protection and source authentication of ULE Req 3. Integrity protection and source authentication of ULE Stream
Stream data are OPTIONAL. These can be used to prevent active data are OPTIONAL. These can be used to prevent the active
attacks described in section 3.2. attacks described in Section 3.2.
Req 4. Protection against replay attacks is OPTIONAL. This is Req 4. Protection against replay attacks is OPTIONAL. This is used
used to counter active attacks described in section 3.2. to counter the active attacks described in Section 3.2.
Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. This
This can be performed during the initial key exchange and can be performed during the initial key exchange and
authentication phase, before the ULE Receiver can join a authentication phase, before the ULE Receiver can join a secure
secure session with the ULE Encapsulator (ULE source). This session with the ULE Encapsulator (ULE source). This could be
could be either unidirectional or bidirectional authentication either unidirectional or bidirectional authentication based on the
based on the underlying key management protocol. underlying key management protocol.
Other general requirements for all threat cases for link-layer Other general requirements for all threat cases for link-layer
security are: security are:
GReq (a) ULE key management functions MUST be decoupled from ULE GReq (a) ULE key management functions MUST be decoupled from ULE
security services such as encryption and source authentication. security services such as encryption and source authentication.
This allows the independent development of both systems. This allows the independent development of both systems.
GReq (b) Support SHOULD be provided for automated as well as GReq (b) Support SHOULD be provided for automated as well as manual
manual insertion of keys and policy into the relevant insertion of keys and policy into the relevant databases.
databases.
GReq (c) Algorithm agility MUST be supported. It should be GReq (c) Algorithm agility MUST be supported. It should be possible
possible to update the crypto algorithms and hashes when they to update the crypto algorithms and hashes when they become
become obsolete without affecting the overall security of the obsolete without affecting the overall security of the system.
system.
GReq (d) The security extension header MUST be compatible with GReq (d) The security extension header MUST be compatible with other
other ULE extension headers. The method must allow other ULE extension headers. The method must allow other extension
extension headers (either mandatory or optional) to be used in headers (either mandatory or optional) to be used in combination
combination with a security extension. It is RECOMMENDED that with a security extension. It is RECOMMENDED that these are
these are placed after the security extension header. This placed after the security extension header. This permits full
permits full protection for all headers. It also avoids protection for all headers. It also avoids situations where the
situations where the SNDU has to be discarded on processing the SNDU has to be discarded on processing the security extension
security extension header, while preceding headers have already header, while preceding headers have already been evaluated. One
been evaluated. One exception is the Timestamp extension which exception is the Timestamp extension that SHOULD precede the
SHOULD precede the security extension header [RFC5163]. In this security extension header [RFC5163]. In this case, the timestamp
case, the timestamp will be unaffected by security services will be unaffected by security services such as data
such as data confidentiality and can be decoded without the confidentiality and can be decoded without the need for key
need for key material. material.
Examining the threat cases in section 3.3, the security Examining the threat cases in Section 3.3, the security requirements
requirements for each case can be summarised as: for each case can be summarised as:
o Case 1: Data confidentiality (Req 1) MUST be provided to o Case 1: Data confidentiality (Req 1) MUST be provided to prevent
prevent monitoring of the ULE data (such as user information monitoring of the ULE data (such as user information and IP
and IP addresses). Protection of NPA addresses (Req 2) MAY be addresses). Protection of NPA addresses (Req 2) MAY be provided to
provided to prevent tracking ULE Receivers and their prevent tracking ULE Receivers and their communications.
communications.
o Case 2: In addition to Case 1 requirements, new measures MAY o Case 2: In addition to Case 1 requirements, new measures MAY be
be implemented such as authentication schemes using Message implemented such as authentication schemes using Message
Authentication Codes, digital signatures, or TESLA [RFC4082] Authentication Codes, digital signatures, or Timed Efficient Stream
in order to provide integrity protection and source Loss-Tolerant Authentication (TESLA) [RFC4082] in order to provide
authentication (Req 3 and Req 5). In addition, sequence integrity protection and source authentication (Reqs 3 and 5). In
numbers (Req 4) MAY be used to protect against replay attacks. addition, sequence numbers (Req 4) MAY be used to protect against
In terms of outsider attacks, group authentication using replay attacks. In terms of outsider attacks, group authentication
Message Authentication Codes can provide the required level of using Message Authentication Codes can provide the required level
security (Req 3 and 5). This will significantly reduce the of security (Reqs 3 and 5). This will significantly reduce the
ability of intruders to successfully inject their own data ability of intruders to successfully inject their own data into the
into the MPEG-TS stream. However, scenario 2 threats apply MPEG-TS stream. However, scenario 2 threats apply only in specific
only in specific service cases, and therefore authentication service cases, and therefore authentication and protection against
and protection against replay attacks are OPTIONAL. Such replay attacks are OPTIONAL. Such measures incur additional
measures incur additional transmission as well as processing transmission as well as processing overheads. Moreover, intrusion
overheads. Moreover, intrusion detection systems may also be detection systems may also be needed by the MPEG-2 network
needed by the MPEG-2 network operator. These should best be operator. These should best be coupled with perimeter security
coupled with perimeter security policy to monitor common DoS policy to monitor common DoS attacks.
attacks.
o Case 3: As stated in section 3.3, the requirements here are o Case 3: As stated in Section 3.3, the requirements here are similar
similar to Case 2, but since the MPEG-2 transmission network to Case 2, but since the MPEG-2 transmission network operator can
operator can usually identify such attacks, the constraints on usually identify such attacks, the constraints on intrusion
intrusion detections are less than in Case 2. detections are less than in Case 2.
Table 1 below shows the threats that are applicable to ULE Table 1 below shows the threats that are applicable to ULE networks,
networks, and the relevant security mechanisms to mitigate those and the relevant security mechanisms to mitigate those threats.
threats.
Security Mechanism Security Mechanism
----------------------------------------------- -----------------------------------------------
|Data |Data |Source |Data |Intru |Iden | |Data |Data |Source |Data |Intru |Iden |
|Privacy |fresh |Authent|Integ |sion |tity | |Privacy |fresh |Authent|Integ |sion |tity |
| |ness |ication|rity |Dete |Prote | | |ness |ication|rity |Dete |Prote |
| | | | |ction |ction | | | | | |ction |ction |
Threat | | | | | | | Threat | | | | | | |
---------------|--------|-------|-------|-------|-------|------| ---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X | | Monitoring | X | - | - | - | - | X |
skipping to change at page 14, line 24 skipping to change at page 14, line 24
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X | | Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - | | Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| DoS Attacks | - | X | X | X | X | - | | DoS Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Modification | - | - | X | X | X | - | | Modification | - | - | X | X | X | - |
| of Messages | | | | | | | | of Messages | | | | | | |
--------------------------------------------------------------- ---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats Table 1: Security techniques to mitigate network threats
in ULE Networks. in ULE Networks
5. Design recommendations for ULE Security Extension Header 5. Design Recommendations for ULE Security Extension Header
Table 1 may assist in selecting fields within a ULE Security Table 1 may assist in selecting fields within a ULE Security
Extension Header framework. Extension Header framework.
Security services may be grouped into profiles based on security Security services may be grouped into profiles based on security
requirements, e.g. a base profile (with payload encryption and requirements, e.g., a base profile (with payload encryption and
identity protection), and a second profile that extends this to identity protection) and a second profile that extends this to also
also provide source authentication and protection against replay provide source authentication and protection against replay attacks.
attacks. Although the use of specific security techniques is optional, it is
RECOMMENDED that receiver devices should implement all the techniques
in Reqs 2-5 of Section 4 to ensure interoperability of all profiles.
A modular design of ULE security may allow it to use and benefit A modular design of ULE security may allow it to use and benefit from
from existing key management protocols, such as GSAKMP [RFC4535] existing key management protocols, such as the Group Secure
and GDOI [RFC3547] defined by the IETF Multicast Security (MSEC) Association Key Management Protocol (GSAKMP) [RFC4535] and the Group
working group. This does not preclude the use of other key Domain of Interpretation (GDOI) [RFC3547] defined by the IETF
management methods in scenarios where this is more appropriate. Multicast Security (MSEC) working group. This does not preclude the
use of other key management methods in scenarios where this is more
appropriate.
IPsec [RFC4301] and TLS [RFC4346] also provide a proven security IPsec [RFC4301] and TLS [RFC5246] also provide a proven security
architecture defining key exchange mechanisms and the ability to architecture defining key exchange mechanisms and the ability to use
use a range of cryptographic algorithms. ULE security can make a range of cryptographic algorithms. ULE security can make use of
use of these established mechanisms and algorithms. See appendix these established mechanisms and algorithms. See Appendix A for more
A for more details. details.
6. Compatibility with Generic Stream Encapsulation 6. Compatibility with Generic Stream Encapsulation
RFC 5163 [RFC5163] describes three new Extension Headers that may RFC 5163 [RFC5163] describes three new Extension Headers that may be
be used with Unidirectional Link Encapsulation, ULE, [RFC4326] used with Unidirectional Link Encapsulation, ULE, [RFC4326] and the
and the Generic Stream Encapsulation (GSE) that has been designed Generic Stream Encapsulation (GSE) that has been designed for the
for the Generic Mode (also known as the Generic Stream (GS)), Generic Mode (also known as the Generic Stream (GS)), offered by
offered by second-generation DVB physical layers [GSE]. second-generation DVB physical layers [GSE].
The security threats and requirements presented in this document The security threats and requirements presented in this document are
are applicable to ULE and GSE encapsulations. applicable to ULE and GSE encapsulations.
7. Summary 7. Summary
This document analyses a set of threats and security This document analyses a set of threats and security requirements.
requirements. It defines the requirements for ULE security and It defines the requirements for ULE security and states the
states the motivation for link security as a part of the motivation for link security as a part of the Encapsulation layer.
Encapsulation layer.
ULE security must provide link-layer encryption and ULE Receiver ULE security must provide link-layer encryption and ULE Receiver
identity protection. The framework must support the optional identity protection. The framework must support the optional ability
ability to provide for link-layer authentication and integrity to provide for link-layer authentication and integrity assurance, as
assurance, as well as protection against insertion of old well as protection against insertion of old (duplicated) data into
(duplicated) data into the ULE Stream (i.e. replay protection). the ULE Stream (i.e., replay protection). This set of features is
This set of features is optional to reduce encapsulation overhead optional to reduce encapsulation overhead when not required.
when not required.
ULE Stream security between a ULE Encapsulation Gateway and the ULE Stream security between a ULE Encapsulation Gateway and the
corresponding Receiver(s) is considered an additional security corresponding Receiver(s) is considered an additional security
mechanism to IPsec, TLS, and application layer end-to-end mechanism to IPsec, TLS, and application layer end-to-end security,
security, and not as a replacement. It allows a network operator and not as a replacement. It allows a network operator to provide
to provide similar functions to that of IPsec, but in addition similar functions to that of IPsec, but in addition provides MPEG-2
provides MPEG-2 transmission link confidentiality and protection transmission link confidentiality and protection of ULE Receiver
of ULE Receiver identity (NPA address). identity (NPA address).
Appendix A describes a set of building blocks that may be used to Appendix A describes a set of building blocks that may be used to
realise a framework that provides ULE security functions. realise a framework that provides ULE security functions.
8. Security Considerations 8. Security Considerations
Link-layer (L2) encryption of IP traffic is commonly used in Link-layer (L2) encryption of IP traffic is commonly used in
broadcast/radio links to supplement end-to-end security (e.g. broadcast/radio links to supplement end-to-end security (e.g.,
provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301]). provided by TLS [RFC5246], SSH [RFC4251], IPsec [RFC4301]).
A common objective is to provide the same level of privacy as A common objective is to provide the same level of privacy as wired
wired links. It is recommended that an ISP or user provide end- links. It is recommended that an ISP or user provide end-to-end
to-end security services based on well known mechanisms such as security services based on well-known mechanisms such as IPsec or
IPsec or TLS. TLS.
This document provides a threat analysis and derives the security This document provides a threat analysis and derives the security
requirements to provide link encryption and optional link-layer requirements to provide link encryption and optional link-layer
integrity / authentication of the SNDU payload. integrity / authentication of the SNDU payload.
There are some security issues that were raised in RFC 4326 There are some security issues that were raised in RFC 4326 [RFC4326]
[RFC4326] that are not addressed in this document (i.e. are out that are not addressed in this document (i.e., are out of scope),
of scope), e.g.: e.g.:
o The security issue with un-initialised stuffing bytes. In ULE, o The security issue with un-initialised stuffing bytes. In ULE,
these bytes are set to 0xFF (normal practice in MPEG-2). these bytes are set to 0xFF (normal practice in MPEG-2).
o Integrity issues related to the removal of the LAN FCS in a o Integrity issues related to the removal of the LAN FCS in a bridged
bridged networking environment. The removal for bridged frames networking environment. The removal of bridged frames exposes the
exposes the traffic to potentially undetected corruption while traffic to potentially undetected corruption while being processed
being processed by the Encapsulator and/or Receiver. by the Encapsulator and/or Receiver.
o There is a potential security issue when a Receiver receives a
PDU with two Length fields: The Receiver would need to
validate the actual length and the Length field and ensure
that inconsistent values are not propagated by the network.
9. IANA Considerations
There are no IANA actions defined in this document. o There is a potential security issue when a Receiver receives a PDU
with two Length fields. The Receiver would need to validate the
actual length and the Length field and ensure that inconsistent
values are not propagated by the network.
10. Acknowledgments 9. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen). The authors also acknowledge (University of Aberdeen). The authors also acknowledge contributions
contributions from Laurence Duquerroy and Stephane Coombes (ESA), from Laurence Duquerroy and Stephane Coombes (ESA), and Yim Fun Hu
and Yim Fun Hu (University of Bradford). (University of Bradford).
11. References 10. References
11.1. Normative References 10.1. Normative References
[ISO-MPEG2] "Information technology -- generic coding of moving [ISO-MPEG2] "Information technology -- generic coding of moving
pictures and associated audio information systems, pictures and associated audio information systems, Part
Part I", ISO 13818-1, International Standards I", ISO 13818-1, International Standards Organisation
Organisation (ISO), 2000. (ISO), 2000.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of Lightweight Encapsulation (ULE) for Transmission of IP
IP Datagrams over an MPEG-2 Transport Stream (TS)", Datagrams over an MPEG-2 Transport Stream (TS)", RFC
IETF RFC 4326, December 2005. 4326, December 2005.
11.2. Informative References 10.2. Informative References
[RFC4947] G. Fairhurst, M.-J. Montpetit, "Address Resolution [BELLOVIN] S. Bellovin, "Security Problems in the TCP/IP Protocol
Mechanisms for IP Datagrams over MPEG-2 Networks", Suite", Computer Communications Review 2:19, pp. 32-48,
IETF RFC 4947, July 2007. April 1989. http://www.cs.columbia.edu/~smb/
[RFC5163] G. Fairhurst and B. Collini-Nocker, "Extension Header [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
formats for Unidirectional Lightweight Encapsulation Specifications for Data Broadcasting", European
(ULE) and the Generic Stream Encapsulation (GSE)", Telecommunications Standards Institute (ETSI).
IETF RFC 5163, April 2008.
[GSE] TS 102 606, "Digital Video Broadcasting (DVB); Generic
Stream Encapsulation (GSE) Protocol, "European
Telecommunication Standards, Institute (ETSI), 2007.
[IEEE-802] "Local and metropolitan area networks-Specific [IEEE-802] "Local and metropolitan area networks-Specific
requirements Part 2: Logical Link Control", IEEE requirements Part 2: Logical Link Control", IEEE 802.2,
802.2, IEEE Computer Society, (also ISO/IEC 8802-2), IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
1998.
[ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International [ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International
Standards Organisation (ISO), 1998. Standards Organisation (ISO), 1998.
[ITU-H222] H.222.0, "Information technology, Generic coding of [ITU-H222] H.222.0, "Information technology, Generic coding of
moving pictures and associated audio information moving pictures and associated audio information
Systems", International Telecommunication Union, Systems", International Telecommunication Union, (ITU-T),
(ITU-T), 1995. 1995.
[RFC4259] M.-J. Montpetit, G. Fairhurst, H. Clausen, B.
Collini-Nocker, and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks",
IETF RFC 4259, November 2005.
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).
[BELLOVIN] S. Bellovin, "Problem Area for the IP Security
protocols", Computer Communications Review 2:19, pp.
32-48, April 989. http://www.cs.columbia.edu/~smb/
[GSE] TS 102 606, "Digital Video Broadcasting (DVB);
Generic Stream Encapsulation (GSE) Protocol,
"European Telecommunication Standards, Institute
(ETSI), 2007.
[RFC4082] A. Perrig, D. Song, "Timed Efficient Stream Loss-
Tolerant Authentication (TESLA): Multicast Source
Authentication Transform Introduction", IETF RFC
4082, June 2005.
[RFC4535] H. Harney, et al, "GSAKMP: Group Secure Association
Group Management Protocol", IETF RFc 4535, June 2006.
[RFC3547] M. Baugher, et al, "GDOI: The Group Domain of
Interpretation", IETF RFC 3547.
[WEIS08] B. Weis, et al, "Multicast Extensions to the Security
Architecture for the Internet", <draft-ietf-msec-
ipsec-extensions-09.txt>, June 2008, IETF Work in
Progress.
[RFC3715] B. Aboba, W. Dixson, "IPsec-Network Address
Translation (NAT) Compatibility Requirements" IETF
RFC 3715, March 2004.
[RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", IETF RFC 4346, April
2006.
[RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing
Proxies Intended to Mitigate Link-Related
Degradations", IETF RFC 3135, June 2001.
[RFC4301] S. Kent, K. Seo, "Security Architecture for the
Internet Protocol", IETF RFC 4301, December 2006.
[RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R.
Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L.
Wood, "Advice for Internet Subnetwork Designers", BCP
89, IETF RFC 3819, July 2004.
[RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Protocol Architecture", IETF RFC 4251, January 2006. Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
12. Author's Addresses [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
Haitham Cruickshank [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address
Centre for Communications System Research (CCSR) Translation (NAT) Compatibility Requirements", RFC 3715,
University of Surrey March 2004.
Guildford, Surrey, GU2 7XH
UK
Email: h.cruickshank@surrey.ac.uk
Prashant Pillai
Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: p.pillai@bradford.ac.uk
Michael Noisternig [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Multimedia Comm. Group, Dpt. of Computer Sciences Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
University of Salzburg L. Wood, "Advice for Internet Subnetwork Designers", BCP
Jakob-Haringer-Str. 2 89, RFC 3819, July 2004.
5020 Salzburg
Austria
Email: mnoist@cosy.sbg.ac.at
Sunil Iyengar [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B.
Space & Defence Briscoe, "Timed Efficient Stream Loss-Tolerant
Logica Authentication (TESLA): Multicast Source Authentication
Springfield Drive Transform Introduction", RFC 4082, June 2005.
Leatherhead
Surrey KT22 7LP
UK
Email: sunil.iyengar@logica.com
13. Intellectual Property Statement [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
The IETF takes no position regarding the validity or scope of any [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
Intellectual Property Rights or other rights that might be Nocker, B., and H. Linder, "A Framework for Transmission
claimed to pertain to the implementation or use of the technology of IP Datagrams over MPEG-2 Networks", RFC 4259, November
described in this document or the extent to which any license 2005.
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
assurances of licenses to be made available, or the result of an Internet Protocol", RFC 4301, December 2005.
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
any copyrights, patents or patent applications, or other "GSAKMP: Group Secure Association Key Management
proprietary rights that may cover technology that may be required Protocol", RFC 4535, June 2006.
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
14. Full Copyright Statement [RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", RFC
4947, July 2007.
Copyright (C) The IETF Trust (2008). [RFC5163] Fairhurst, G. and B. Collini-Nocker, "Extension Formats
for Unidirectional Lightweight Encapsulation (ULE) and
the Generic Stream Encapsulation (GSE)", RFC 5163, April
2008.
This document is subject to the rights, licenses and restrictions [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
contained in BCP 78, and except as set forth therein, the authors (TLS) Protocol Version 1.2", RFC 5246, August 2008.
retain all their rights.
This document and the information contained herein are provided [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Extensions to the Security Architecture for the Internet
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE Protocol", RFC 5374, November 2008.
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Appendix A: ULE Security Framework Appendix A. ULE Security Framework
This section describes a security framework for the deployment of This section describes a security framework for the deployment of
secure ULE networks. secure ULE networks.
A.1 Building Blocks A.1. Building Blocks
This ULE Security framework describes the following building This ULE Security framework describes the following building blocks
blocks as shown in figure 2 below: as shown in Figure 2 below:
o The Key Management Block o The Key Management Block
o The ULE Security Extension Header Block o The ULE Security Extension Header Block
o The ULE Databases Block o The ULE Databases Block
Within the Key Management Block the communication between the Within the Key Management Block, the communication between the Group
Group Member entity and the Group Server entity happens in the Member entity and the Group Server entity happens in the control
control plane. The ULE Security Header Block applies security to plane. The ULE Security Header Block applies security to the ULE
the ULE SNDU and this happens in the ULE data plane. The ULE SNDU and this happens in the ULE data plane. The ULE Security
Security Databases Block acts as the interface between the Key Databases Block acts as the interface between the Key Management
Management Block (control plane) and the ULE Security Header Block (control plane) and the ULE Security Header Block (ULE data
Block (ULE data plane) as shown in figure 2. The Security plane) as shown in Figure 2. The Security Databases Block exists in
Databases Block exists in both the group member and server sides. both the group member and server sides. However, it has been omitted
However, it has been omitted from figure 2 just for clarity. from Figure 2 just for clarity.
----- -----
+------+----------+ +----------------+ / \ +------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | | | Key Management |/---------\| Key Management | |
| Group Member |\---------/| Group Server | | | Group Member |\---------/| Group Server | |
| Block | | Block | Control | Block | | Block | Control
+------+----------+ +----------------+ Plane +------+----------+ +----------------+ Plane
| | | | | |
| | | | | |
| | \ / | | \ /
skipping to change at page 21, line 38 skipping to change at page 20, line 38
| | | | | |
+------+-+--------+ ULE Data +------+-+--------+ ULE Data
| ULE Security | Plane | ULE Security | Plane
| Extension Header| | | Extension Header| |
| Block | | | Block | |
+-----------------+ \ / +-----------------+ \ /
----- -----
Figure 2: Secure ULE Framework Building Blocks Figure 2: Secure ULE Framework Building Blocks
A.1.1 Key Management Block A.1.1. Key Management Block
A key management framework is required to provide security at the A key management framework is required to provide security at the ULE
ULE level using extension headers. This key management framework level using extension headers. This key management framework is
is responsible for user authentication, access control, and responsible for user authentication, access control, and Security
Security Association negotiation (which include the negotiations Association negotiation (which include the negotiations of the
of the security algorithms to be used and the generation of the security algorithms to be used and the generation of the different
different session keys as well as policy material). The key session keys as well as policy material). The key management
management framework can be either automated or manual. Hence framework can be either automated or manual. Hence, this key
this key management client entity (shown as the Key Management management client entity (shown as the Key Management Group Member
Group Member Block in figure 2) will be present in all ULE Block in Figure 2) will be present in all ULE Receivers as well as at
Receivers as well as at the ULE Encapsulators. The ULE the ULE Encapsulators. The ULE Encapsulator could also be the Key
Encapsulator could also be the Key Management Group Server Entity Management Group Server Entity (shown as the Key Management Group
(shown as the Key Management Group Server Block in figure 2). Server Block in Figure 2).
This happens when the ULE Encapsulator also acts as the Key This happens when the ULE Encapsulator also acts as the Key
Management Group Server. Deployment may use either automated key Management Group Server. Deployment may use either automated key
management protocols (e.g. GSAKMP [RFC4535]) or manual insertion management protocols (e.g., GSAKMP [RFC4535]) or manual insertion of
of keying material. keying material.
A.1.2 ULE Security Databases Block A.1.2. ULE Security Databases Block
There needs to be two databases, i.e. similar to the IPsec There needs to be two databases, i.e., similar to the IPsec
databases. databases.
o ULE-SAD: ULE Security Association Database contains all the o ULE-SAD: ULE Security Association Database contains all the
Security Associations that are currently established with Security Associations that are currently established with different
different ULE peers. ULE peers.
o ULE-SPD: ULE Security Policy Database contains the policies as o ULE-SPD: ULE Security Policy Database contains the policies as
described by the system manager. These policies describe the described by the system manager. These policies describe the
security services that must be enforced. security services that must be enforced.
The design of these two databases may be based on IPsec databases While traditionally link-layer security has operated using simple
as defined in RFC4301 [RFC4301]. policy mechanisms, it is envisaged that ULE security should provide
flexibility comparable to IPsec. The above design is based on the
two databases defined for IPsec [RFC4301]. These databases could be
used to implement either simple policies (as in traditional link
security services) or more complex policies (as in IPsec).
The exact details of the header patterns that the SPD and SAD The exact details of the header patterns that the SPD and SAD will
will have to support for all use cases will be described in a have to support for all use cases will be described in a separate
separate document. This document only highlights the need for document. This document only highlights the need for such interfaces
such interfaces between the ULE data plane and the Key Management between the ULE data plane and the Key Management control plane.
control plane.
A.1.3 ULE Extension Header Block A.1.3. ULE Extension Header Block
A new security extension header for the ULE protocol is required A new security extension header for the ULE protocol is required to
to provide the security features of data confidentiality, provide the security features of data confidentiality, identity
identity protection, data integrity, data authentication, and protection, data integrity, data authentication, and mechanisms to
mechanisms to prevent replay attacks. Security keying material prevent replay attacks. Security keying material will be used for
will be used for the different security algorithms (for the different security algorithms (for encryption/decryption, MAC
encryption/decryption, MAC generation, etc.), which are used to generation, etc.), which are used to meet the security requirements,
meet the security requirements, described in detail in Section 4 described in detail in Section 4 of this document.
of this document.
This block will use the keying material and policy information This block will use the keying material and policy information from
from the ULE Security Database Block on the ULE payload to the ULE Security Database Block on the ULE payload to generate the
generate the secure ULE Extension Header or to decipher the secure ULE Extension Header or to decipher the secure ULE extension
secure ULE extension header to get the ULE payload. An example header to get the ULE payload. An example overview of the ULE
overview of the ULE Security extension header format along with Security extension header format along with the ULE header and
the ULE header and payload is shown in figure 3 below. payload is shown in Figure 3 below.
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement Figure 3: ULE Security Extension Header Placement
A.2 Interface definition A.2. Interface Definition
Two new interfaces have to be defined between the blocks as shown Two new interfaces have to be defined between the blocks as shown in
in Figure 2 above. These interfaces are: Figure 2 above. These interfaces are:
o Key Management Block <-> ULE Security Databases Block o Key Management Block <-> ULE Security Databases Block
o ULE Security Databases Block <-> ULE Security Header Block o ULE Security Databases Block <-> ULE Security Header Block
While the first interface is used by the Key Management Block to While the first interface is used by the Key Management Block to
insert keys, security associations and policies into the ULE insert keys, security associations, and policies into the ULE
Database Block, the second interface is used by the ULE Security Database Block, the second interface is used by the ULE Security
Extension Header Block to get the keys and policy material for Extension Header Block to get the keys and policy material for
generation of the security extension header. generation of the security extension header.
A.2.1 Key Management <-> ULE Security databases A.2.1. Key Management <-> ULE Security Databases
This interface is between the Key Management Block of a group This interface is between the Key Management Block of a group member
member (GM client) and the ULE Security Database Block (shown in (GM client) and the ULE Security Database Block (shown in Figure 2).
figure 2). The Key Management GM entity will communicate with the The Key Management GM entity will communicate with the GCKS and then
GCKS and then get the relevant security information (keys, cipher get the relevant security information (keys, cipher mode, security
mode, security service, ULE_Security_ID and other relevant keying service, ULE_Security_ID, and other relevant keying material as well
material as well as policy) and insert this data into the ULE as policy) and insert this data into the ULE Security Database Block.
Security Database Block. The Key Management could be either The Key Management could be either automated (e.g., GSAKMP [RFC4535]
automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]), or security or GDOI [RFC3547]), or security information could be manually
information could be manually inserted using this interface. inserted using this interface.
Examples of interface functions are: Examples of interface functions are:
o Insert_record_database (char * Database, char * record, char * o Insert_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
o Update_record_database (char * Database, char * record, char * o Update_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
o Delete_record_database (char * Database, char * Unique_ID); o Delete_record_database (char * Database, char * Unique_ID);
The definitions of the variables are as follows: The definitions of the variables are as follows:
o Database - This is a pointer to the ULE Security databases o Database - This is a pointer to the ULE Security databases
o record - This is the rows of security attributes to be entered o record - This is the rows of security attributes to be entered or
or modified in the above databases modified in the above databases
o Unique_ID - This is the primary key to lookup records (rows of o Unique_ID - This is the primary key to lookup records (rows of
security attributes) in the above databases security attributes) in the above databases
A.2.2 ULE Security Databases <-> ULE Security Header A.2.2. ULE Security Databases <-> ULE Security Header
This interface is between the ULE Security Database and the ULE This interface is between the ULE Security Database and the ULE
Security Extension Header Block as shown in figure 2. When Security Extension Header Block as shown in Figure 2. When sending
sending traffic, the ULE encapsulator uses the Destination traffic, the ULE encapsulator uses the Destination Address, the PID,
Address, the PID, and possibly other information such as L3 and possibly other information such as L3 source and destination
source and destination addresses to locate the relevant security addresses to locate the relevant security record within the ULE
record within the ULE Security Database. It then uses the data in Security Database. It then uses the data in the record to create the
the record to create the ULE security extension header. For ULE security extension header. For received traffic, the ULE
received traffic, the ULE decapsulator on receiving the ULE SNDU decapsulator on receiving the ULE SNDU will use the Destination
will use the Destination Address, the PID, and a ULE Security ID Address, the PID, and a ULE Security ID inserted by the ULE
inserted by the ULE encapsulator into the security extension to encapsulator into the security extension to retrieve the relevant
retrieve the relevant record from the Security Database. It then record from the Security Database. It then uses this information to
uses this information to decrypt the ULE extension header. For decrypt the ULE extension header. For both cases (either send or
both cases (either send or receive traffic) only one interface is receive traffic) only one interface is needed since the main
needed since the main difference between the sender and receiver difference between the sender and receiver is the direction of the
is the direction of the flow of traffic. An example of such flow of traffic. An example of such an interface is as follows:
interface is as follows:
o Get_record_database (char * Database, char * record, char * o Get_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
Appendix B: Motivation for ULE link-layer security Appendix B. Motivation for ULE Link-Layer Security
Examination of the threat analysis and security requirements in Examination of the threat analysis and security requirements in
sections 3 and 4 has shown that there is a need to provide Sections 3 and 4 has shown that there is a need to provide security
security in MPEG-2 transmission networks employing ULE. This in MPEG-2 transmission networks employing ULE. This section compares
section compares the placement of security functionalities in the placement of security functionalities in different layers.
different layers.
B.1 Security at the IP layer (using IPsec) B.1. Security at the IP Layer (Using IPsec)
The security architecture for the Internet Protocol [RFC4301] The security architecture for the Internet Protocol [RFC4301]
describes security services for traffic at the IP layer. This describes security services for traffic at the IP layer. This
architecture primarily defines services for the Internet Protocol architecture primarily defines services for the Internet Protocol
(IP) unicast packets, as well as manually configured IP multicast (IP) unicast packets, as well as manually configured IP multicast
packets. packets.
It is possible to use IPsec to secure ULE Streams. The major It is possible to use IPsec to secure ULE Streams. The major
advantage of IPsec is its wide implementation in IP routers and advantage of IPsec is its wide implementation in IP routers and
hosts. IPsec in transport mode can be used for end-to-end hosts. IPsec in transport mode can be used for end-to-end security
security transparently over MPEG-2 transmission links with little transparently over MPEG-2 transmission links with little impact.
impact.
In the context of MPEG-2 transmission links, if IPsec is used to In the context of MPEG-2 transmission links, if IPsec is used to
secure a ULE Stream, then the ULE Encapsulator and Receivers are secure a ULE Stream, then the ULE Encapsulator and Receivers are
equivalent to the security gateways in IPsec terminology. A equivalent to the security gateways in IPsec terminology. A security
security gateway implementation of IPsec uses tunnel mode. Such gateway implementation of IPsec uses tunnel mode. Such usage has the
usage has the following disadvantages: following disadvantages:
o There is an extra transmission overhead associated with using o There is an extra transmission overhead associated with using IPsec
IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). in tunnel mode, i.e., the extra IP header (IPv4 or IPv6).
o There is a need to protect the identity (NPA address) of ULE o There is a need to protect the identity (NPA address) of ULE
Receivers over the ULE broadcast medium; IPsec is not suitable Receivers over the ULE broadcast medium; IPsec is not suitable for
for providing this service. In addition, the interfaces of providing this service. In addition, the interfaces of these
these devices do not necessarily have IP addresses (they can devices do not necessarily have IP addresses (they can be L2
be L2 devices). devices).
o Multicast is considered a major service over ULE links. The o Multicast is considered a major service over ULE links. The
current IPsec specifications [RFC4301] only define a pairwise current IPsec specifications [RFC4301] only define a pairwise
tunnel between two IPsec devices with manual keying. Work is tunnel between two IPsec devices with manual keying. Work is in
in progress in defining the extra detail needed for multicast progress in defining the extra detail needed for multicast and to
and to use the tunnel mode with address preservation to allow use the tunnel mode with address preservation to allow efficient
efficient multicasting. For further details refer to [WEIS08]. multicasting. For further details refer to [RFC5374].
B.2 Link security below the encapsulation layer B.2. Link Security below the Encapsulation Layer
Link layer security can be provided at the MPEG-2 TS layer (below Link layer security can be provided at the MPEG-2 TS layer (below
ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
specific PID value. However, an MPEG-2 TS may typically multiplex specific PID value. However, an MPEG-2 TS may typically multiplex
several IP flows, belonging to different users, using a common several IP flows, belonging to different users, using a common PID.
PID. Therefore all multiplexed traffic will share the same Therefore, all multiplexed traffic will share the same security keys.
security keys.
This has the following advantages: This has the following advantages:
o The bit stream sent on the broadcast network does not expose o The bit stream sent on the broadcast network does not expose any L2
any L2 or L3 headers, specifically all addresses, type fields, or L3 headers, specifically all addresses, type fields, and length
and length fields are encrypted prior to transmission. fields are encrypted prior to transmission.
o This method does not preclude the use of IPsec, TLS, or any o This method does not preclude the use of IPsec, TLS, or any other
other form of higher-layer security. form of higher-layer security.
However it has the following disadvantages: However it has the following disadvantages:
o When a PID is shared between several users, each ULE Receiver o When a PID is shared between several users, each ULE Receiver needs
needs to decrypt all MPEG-2 TS Packets with a matching PID, to decrypt all MPEG-2 TS Packets with a matching PID, possibly
possibly including those that are not required to be including those that are not required to be forwarded. Therefore,
forwarded. Therefore it does not have the flexibility to it does not have the flexibility to separately secure individual IP
separately secure individual IP flows. flows.
o When a PID is shared between several users, the ULE Receivers o When a PID is shared between several users, the ULE Receivers will
will have access to private traffic destined to other ULE have access to private traffic destined to other ULE Receivers,
Receivers, since they share a common PID and key. since they share a common PID and key.
o IETF-based key management that is very flexible and secure is o IETF-based key management that is very flexible and secure is not
not used in existing MPEG-2 based systems. Existing access used in existing MPEG-2 based systems. Existing access control
control mechanisms in such systems have limited flexibility in mechanisms in such systems have limited flexibility in terms of
terms of controlling the use of key and rekeying. Therefore if controlling the use of keying and rekeying. Therefore, if the key
the key is compromised, then this will impact several ULE is compromised, this will impact several ULE Receivers.
Receivers.
Currently there are few deployed L2 security systems for MPEG-2 Currently, there are few deployed L2 security systems for MPEG-2
transmission networks. Conditional access for digital TV transmission networks. Conditional access for digital TV
broadcasting is one example. However, this approach is optimised broadcasting is one example. However, this approach is optimised for
for TV services and is not well-suited to IP packet transmission. TV services and is not well-suited to IP packet transmission. Some
Some other systems are specified in standards such as MPE [ETSI- other systems are specified in standards such as MPE [ETSI-DAT], but
DAT], but there are currently no known implementations and these there are currently no known implementations and these methods are
methods are not applicable to GSE. not applicable to GSE.
B.3 Link security as a part of the encapsulation layer B.3. Link Security as a Part of the Encapsulation Layer
Examining the threat analysis in section 3 has shown that Examining the threat analysis in Section 3 has shown that protection
protection of ULE Stream from eavesdropping and ULE Receiver of ULE Stream from eavesdropping and ULE Receiver identity are major
identity are major requirements. requirements.
There are several advantages in using ULE link layer security: There are several advantages in using ULE link-layer security:
o The protection of the complete ULE Protocol Data Unit (PDU) o The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses. The protection can be applied either including IP addresses. The protection can be applied either per
per IP flow or per Receiver NPA address. IP flow or per Receiver NPA address.
o Ability to protect the identity of the Receiver within the o Ability to protect the identity of the Receiver within the MPEG-2
MPEG-2 transmission network at the IP layer and also at L2. transmission network at the IP layer and also at L2.
o Efficient protection of IP multicast over ULE links. o Efficient protection of IP multicast over ULE links.
o Transparency to the use of Network Address Translation (NATs) o Transparency to the use of Network Address Translation (NATs)
[RFC3715] and TCP Performance Enhancing Proxies (PEP) [RFC3715] and TCP Performance Enhancing Proxies (PEP) [RFC3135],
[RFC3135], which require the ability to inspect and modify the which require the ability to inspect and modify the packets sent
packets sent over the ULE link. over the ULE link.
This method does not preclude the use of IPsec at L3 (or TLS This method does not preclude the use of IPsec at L3 (or TLS
[RFC4346] at L4). IPsec and TLS provide strong authentication of [RFC5246] at L4). IPsec and TLS provide strong authentication of the
the end-points in the communication. endpoints in the communication.
L3 end-to-end security would partially deny the advantage listed L3 end-to-end security would partially deny the advantage listed
above (use of PEP, compression, etc.), since those techniques above (use of PEP, compression, etc.), since those techniques could
could only be applied to TCP packets bearing a TCP-encapsulated only be applied to TCP packets bearing a TCP-encapsulated IPsec
IPsec packet exchange, but not the TCP packets of the original packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression. applications, which in particular inhibits compression.
End-to-end security (IPsec, TLS, etc.) may be used independently End-to-end security (IPsec, TLS, etc.) may be used independently to
to provide strong authentication of the end-points in the provide strong authentication of the endpoints in the communication.
communication. This authentication is desirable in many scenarios This authentication is desirable in many scenarios to ensure that the
to ensure that the correct information is being exchanged between correct information is being exchanged between the trusted parties,
the trusted parties, whereas Layer 2 methods cannot provide this whereas Layer 2 methods cannot provide this guarantee.
guarantee.
>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
Document History
Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption.
Working Group Draft 01
o Fixed editorial mistakes and added an appendix which shows the
preliminary framework for securing the ULE network.
Working Group Draft 02
o Fixed editorial mistakes and added some important changes as
pointed out by Knut Eckstein (ESA), Gorry Fairhurst and
UNISAL.
o Added section 4.1 on GSE. Extended the security considerations
section.
o Extended the appendix to show the extension header placement.
o The definition of the header patterns for the ULE Security
databases will be defined in a separate draft.
o Need to include some words on key management transport over
air interfaces, actually key management bootstrapping.
Working Group Draft 03
o Fixed editorial mistakes and added some important changes as
pointed out by Gorry Fairhurst.
o Table 1 added in Section 6.2 to list the different security
techniques to mitigate the various possible network threats.
o Figure 2 modified to clearly explain the different interfaces
present in the framework.
o New Section 7 has been added.
o New Section 6 has been added.
o The previous sections 5 and 6 have been combined to section 5.
o Sections 3, 8 and 9 have been rearranged and updated with
comments and suggestions from Michael Noisternig from
University of Salzburg.
o The Authors and the Acknowledgments section have been updated.
Working Group Draft 04
o Fixed editorial mistakes and added some important changes as
pointed out by DVB-GBS group, Gorry Fairhurst and Laurence
Duquerroy.
o Table 1 modified to have consistent use of Security Services.
o Text modified to be consistent with the draft-ietf-ipdvb-ule-
ext-04.txt
Working Group Draft 06
o Fixed editorial mistakes and added some important changes as
pointed out by Pat Cain and Gorry Fairhurst.
o Figure 1 modified to have consistent use of Security Services.
o Text modified in Section 4 to clearly state the requirements.
o Moved Section 5 to the Appendix B
o Updated IANA consideration section
o Numbered the different requirements and cross referenced them
within the text.
Working Group Draft 07
o Rephrased some sentences throughout the document to add more
clarity, mainly due to suggestions by Gorry Fairhurst.
o Updated section 4 to more clearly specify requirements,
choosing more appropriate RFC 2119 keywords, and removed some
overly general requirements.
o Moved security header placement recommendation from appendix
to list of general requirements in section 4, as suggested by
Gorry Fairhurst.
o Modified text in appendix section A.2.2 to correctly specify
which information sender and receiver use to look up security
information within the database.
o Fixed some editorial mistakes and updated the reference list.
Working Group Draft 08
o Rephrased some sentences to add more clarity. Authors' Addresses
o Fixed some editorial mistakes pointed out by Gorry Fairhurst. Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
EMail: h.cruickshank@surrey.ac.uk
o Described the interface definitions in section A.2 as examples Prashant Pillai
rather than requirements. Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
EMail: p.pillai@bradford.ac.uk
Working Group Draft 09 Michael Noisternig
Multimedia Comm. Group, Dpt. of Computer Sciences
University of Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg
Austria
EMail: mnoist@cosy.sbg.ac.at
o Clarified some sentences and fixed some editorial Sunil Iyengar
inconsistencies and mistakes due to comments by Rupert Space & Defence
Goodings and Laurence Duquerroy. Logica
Springfield Drive
Leatherhead
Surrey KT22 7LP
UK
EMail: sunil.iyengar@logica.com
 End of changes. 177 change blocks. 
871 lines changed or deleted 676 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/