draft-ietf-ipdvb-sec-req-06.txt   draft-ietf-ipdvb-sec-req-07.txt 
IPDVB Working Group H. Cruickshank IPDVB Working Group H. Cruickshank
Internet-Draft S. Iyengar Internet-Draft University of Surrey, UK
Intended status: Informational University of Surrey, UK Intended status: Informational P. Pillai
P. Pillai Expires: Dec 16, 2008 University of Bradford, UK
Expires: October 4, 2008 University of Bradford, UK Michael Noisternig
April 4, 2008 University of Salzburg, Austria
S. Iyengar
Logica, UK
17 June, 2008
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-06.txt draft-ietf-ipdvb-sec-req-07.txt
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 38 skipping to change at page 1, line 41
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 4, 2008. This Internet-Draft will expire on December 17, 2008.
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 range of services. This document
provides a threat analysis and derives the security requirements provides a threat analysis and derives the security requirements
when using the Transport Stream, TS, to support an Internet when using the Transport Stream, TS, to support an Internet
network-layer using Unidirectional Lightweight Encapsulation network-layer using Unidirectional Lightweight Encapsulation
(ULE) defined in RFC4326. The document also provides the (ULE) defined in RFC4326. The document also provides the
motivation for link-layer security for a ULE Stream. A ULE Stream motivation for link-layer security for a ULE Stream. A ULE Stream
may be used to send IPv4 packets, IPv6 packets, and other may be used to send IPv4 packets, IPv6 packets, and other
Protocol Data Units (PDUs) to an arbitrarily large number of Protocol Data Units (PDUs) to an arbitrarily large number of
Receivers supporting unicast and/or multicast transmission. Receivers supporting unicast and/or multicast transmission.
The analysis also describes applicability to the Generic Stream
Encapsulation (GSE) defined by the Digital Video Broadcasting
(DVB) Project.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction .............................................. 2
2. Requirements notation.......................................3 2. Requirements notation ..................................... 4
3. Threat Analysis.............................................6 3. Threat Analysis ........................................... 6
3.1. System Components......................................6 3.1. System Components .................................... 6
3.2. Threats................................................9 3.2. Threats .............................................. 9
3.3. Threat Scenarios......................................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 Header Extension...13 5. Design recommendations for ULE Security Extension Header . 14
6. Compatibility with Generic Stream Encapsulation............14 6. Compatibility with Generic Stream Encapsulation .......... 14
7. Summary....................................................14 7. Summary .................................................. 14
8. Security Considerations....................................15 8. Security Considerations .................................. 16
9. IANA Considerations........................................16 9. IANA Considerations ...................................... 16
10. Acknowledgments...........................................16 10. Acknowledgments ......................................... 16
11. References................................................16 11. References .............................................. 16
11.1. Normative References.................................16 11.1. Normative References ............................... 16
11.2. Informative References...............................16 11.2. Informative References ............................. 17
12. Author's Addresses........................................18 12. Author's Addresses ...................................... 19
13. IPR Notices...............................................18 13. IPR Notices ............................................. 19
13.1. Intellectual Property Statement......................19 13.1. Intellectual Property Statement .................... 19
14. Copyright Statement.......................................19 14. Copyright Statement...................................... 20
Appendix A: ULE Security Framework............................20 Appendix A: ULE Security Framework .......................... 20
Appendix B: Motivation for ULE link-layer security............24 Appendix B: Motivation for ULE link-layer security .......... 24
Document History..............................................27 Document History ............................................ 27
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 for providing digital TV services, but also as a subnetwork only 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 transport of IPv4 and IPv6 Datagrams and other network the transport of IPv4 and IPv6 Datagrams and other network
protocol packets directly over the ISO MPEG-2 Transport Stream as protocol packets directly over the ISO MPEG-2 Transport Stream as
TS Private Data. ULE specifies a base encapsulation format and TS Private Data. ULE specifies a base encapsulation format and
supports an extension format that allows it to carry additional supports an Extension Header format that allows it to carry
header information to assist in network/Receiver processing. The additional header information to assist in network/Receiver
encapsulation satisfies the design and architectural requirement processing. The encapsulation satisfies the design and
for a lightweight encapsulation defined in RFC 4259 [RFC4259]. architectural requirement for a lightweight encapsulation defined
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 MPEG-2 Transmission Networks. A summary of these scenarios for MPEG-2 Transmission Networks. A summary of these scenarios
are presented below (for full detail, please refer to RFC 4259): are presented below (for full detail, please refer to RFC 4259):
1. Broadcast TV and Radio Delivery. A. Broadcast TV and Radio Delivery.
2. Broadcast Networks used as an ISP. This resembles to scenario B. Broadcast Networks used as an ISP. This resembles to scenario
1, but includes the provision of IP services providing access 1, but includes the provision of IP services providing access
to the public Internet. to the public Internet.
3. Unidirectional Star IP Scenario. It utilizes a Hub station to C. Unidirectional Star IP Scenario. It utilizes a Hub station to
provide a data network delivering a common bit stream to provide a data network delivering a common bit stream to
typically medium-sized groups of Receivers. typically medium-sized groups of Receivers.
4. Datacast Overlay. It employs MPEG-2 physical and link layers D. Datacast Overlay. It employs MPEG-2 physical and link layers
to provide additional connectivity such as unidirectional to provide additional connectivity such as unidirectional
multicast to supplement an existing IP-based Internet service. multicast to supplement an existing IP-based Internet service.
5. Point-to-Point Links. E. Point-to-Point Links. This connectivity may be provided using
a pair of transmit and receive interfaces.
6. Two-Way IP Networks. This can be typically satellite-based and F. Two-Way IP Networks. This can be (for example) satellite-based
star-based utilising a Hub station to deliver a common bit and star-based utilising a Hub station to deliver a common bit
stream to medium-sized groups of receivers. A bidirectional stream to medium-sized groups of Receivers. A bidirectional
service is provided over a common air-interface. service is provided over a common air-interface.
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 as well threats. Security must also consider both unidirectional (A, B, C
as bidirectional links for the scenarios mentioned above. and D) as well as bidirectional (E and F) links for the scenarios
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 wireline network, the normal security issues relating to using a wireline network, the normal security issues relating to
the use of wireless links for transport of Internet traffic the use of wireless links for transport of Internet traffic
should be considered [RFC3819]. should be considered [RFC3819].
The security considerations of RFC 4259 recommends that any new The security considerations of RFC 4259 recommends 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 of the SNDU payload. In ULE [RFC4326], it is authentication of the 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 Headers. This requires the definition of a mandatory Extension Headers. This requires the definition of a mandatory
header extension, but has the advantage that it decouples Extension Header, but has the advantage that it decouples
specification of the security functions from the encapsulation specification of the security functions from the encapsulation
functions. functions.
This document extends the above analysis and derives a detailed This document extends the above analysis and derives a detailed
the security requirements for ULE in MPEG-2 transmission the 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 the different building blocks and the interface describing the different building blocks and the interface
definitions is presented in Appendix A. definitions is presented in Appendix A.
skipping to change at page 4, line 24 skipping to change at page 4, line 37
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 the ISO MPEG-2 Standard [ISO-MPEG2]. using the ISO MPEG-2 Standard [ISO-MPEG2].
Encapsulator: A network device that receives PDUs and formats Encapsulator: A network device that receives PDUs and formats
these into Payload Units (known here as SNDUs) for output as a these into Payload Units (known here as SNDUs) for output as a
stream of TS Packets. stream of TS Packets.
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 Medium Access Control Header. Ethernet 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 DSM-CC Table Section. Each Section
is sent in a series of TS Packets using a single TS Logical is sent in a series of TS Packets using a single TS Logical
Channel. Channel.
skipping to change at page 7, line 4 skipping to change at page 7, line 16
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 several entities within the MPEG-2 transmission network are several entities within the MPEG-2 transmission network
architecture. These include: architecture. 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 end points for ULE streams) o Receivers (the end points for ULE streams)
o TS multiplexers (including re-multiplexers) o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
In a MPEG-2 TS transmission network, the originating source of TS In an MPEG-2 TS transmission network, the originating source of
Packets is either a L2 interface device (media encoder, TS Packets is either a Layer 2 (L2) interface device (media
encapsulation gateway, etc) or a L2 network device (TS encoder, encapsulation gateway, etc) or a L2 network device (TS
multiplexer, etc). These devices may, but do not necessarily, multiplexer, etc). These devices may, but do not necessarily,
have an associated IP address. In the case of an encapsulation have an associated IP address. In the case of an encapsulation
gateway (e.g. ULE sender), the device may operate at L2 or Layer gateway (e.g. ULE sender), the device may operate at L2 or Layer
3 (L3), and is not normally the originator of an IP traffic flow, 3 (L3), and is not normally the originator of an IP traffic flow,
and usually the IP source address of the packets that it forwards and usually the IP source address of the packets that it forwards
do not correspond to an IP address associated with the device. does not correspond to an IP address associated with the device.
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 usually includes Forward Error Correction (FEC) coding that 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 of single TS Packets very difficult. Replacement of a injection of single TS Packets very difficult. Replacement of a
sequence of packets is also difficult, but possible (see section sequence of packets is also difficult, but possible (see section
3.2). 3.2).
A Receiver in a MPEG-2 TS transmission network needs to identify A Receiver in an MPEG-2 TS transmission network needs to identify
a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble
the fragments of PDUs sent by a L2 source [RFC4259]. In a MPEG-2 the fragments of PDUs sent by a L2 source [RFC4259]. In an MPEG-2
TS, this association is made via the Packet Identifier, PID [ISO- TS, this association is made via the Packet Identifier, PID [ISO-
MPEG2]. At the sender, each source associates a locally unique MPEG2]. At the sender, each source associates a locally unique
set of PID values with each stream it originates. However, there set of PID values with each stream it originates. However, there
is no required relationship between the PID value used at the is no required relationship between the PID value used at the
sender and that received at the Receiver. Network devices may re- sender and that received at the Receiver. Network devices may re-
number the PID values associated with one or more TS Logical number the PID values associated with one or more TS Logical
Channels (e.g. ULE Streams) to prevent clashes at a multiplexer Channels (e.g. ULE Streams) to prevent clashes at a multiplexer
between input streams with the same PID carried on different between input streams with the same PID carried on different
input multiplexes (updating entries in the PMT [ISO-MPEG2], and input multiplexes (updating entries in the PMT [ISO-MPEG2], and
other SI tables that reference the PID value). A device may also other SI tables that reference the PID value). A device may also
modify and/or insert new SI data into the control plane (also modify and/or insert new SI data into the control plane (also
sent as TS Packets identified by their PID value). However there sent as TS Packets identified by their PID value). However, there
is only one valid source of data for each MPEG-2 Elementary is only one valid source of data for each MPEG-2 Elementary
Stream, bound to a PID value. (This observation could simplify Stream, bound to a PID value. (This observation could simplify
the requirement for authentication of the source of a ULE the requirement for authentication of the source of a ULE
Stream.) Stream.)
In an MPEG-2 network a set of signalling messages [ID-AR] may In an MPEG-2 network a set of signalling messages [RFC4947] may
need to be broadcast (e.g. by an Encapsulation Gateway or other need to be broadcast (e.g. by an Encapsulation Gateway or other
device) to form the Layer 2 (L2) control plane. Examples of device) to form the L2 control plane. Examples of signalling
signalling messages include the Program Association Table (PAT), messages include the Program Association Table (PAT), Program Map
Program Map Table (PMT) and Network Information Table (NIT). In Table (PMT) and Network Information Table (NIT). In existing
existing MPEG-2 transmission networks, these messages are MPEG-2 transmission networks, these messages are broadcast in the
broadcast in the clear (no encryption or integrity checks). The clear (no encryption or integrity checks). The integrity as well
integrity as well as authenticity of these messages is important as authenticity of these messages is important for correct
for correct working of the ULE network, i.e. supporting its working of the ULE network, i.e. supporting its security
security objectives in the area of availability, in addition to objectives in the area of availability, in addition to
confidentiality and integrity. One method recently proposed [ID- confidentiality and integrity. One method recently proposed
EXT] encapsulates these messages using ULE. In such cases all the [RFC5163] encapsulates these messages using ULE. In such cases
security requirements of this document apply in securing these all the security requirements of this document apply in securing
signalling messages. these signalling messages.
ULE link security focuses only on 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 deployment scenarios the user of a ULE Stream has to secure many 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 in addition to the ULE link. Therefore, if utilised in addition to the ULE link. Therefore, if
authentication of the end-point i.e. the IP Sources is required, authentication of the end-points, i.e. the IP Sources is
or users are concerned about loss of confidentiality, integrity required, or users are concerned about loss of confidentiality,
or authenticity of their communication data, they will have to integrity, or authenticity of their communication data, they will
employ end-to-end network security mechanisms like IPSec or have to employ end-to-end network security mechanisms, e.g. IPsec
Transport Layer Security (TLS). Governmental users may be forced or Transport Layer Security (TLS). Governmental users may be
by regulations to employ specific, approved implementations of forced by regulations to employ specific, approved
those mechanisms. Hence for such cases the confidentiality and implementations of those mechanisms. Hence for such cases, the
integrity of the user data will already be taken care of by the requirements for confidentiality and integrity of the user data
end-to-end security mechanism and the ULE security measures would will be met by the end-to-end security mechanism and the ULE
focus on either providing traffic flow confidentiality for user security measures would focus on either providing traffic flow
data that has already been encrypted or for users who choose not confidentiality for user data that has already been encrypted or
to implement end-to-end security mechanisms. for users who choose not to implement end-to-end security
mechanisms.
ULE links may also be used for communications where the two end- ULE links may also be used for communications where the two IP
points are not under central control (e.g., when browsing a end-points are not under central control (e.g., when browsing a
public web site). In these cases, it may be impossible to enforce public web site). In these cases, it may be impossible to enforce
any end-to-end security mechanisms. Yet, a common objective is any end-to-end security mechanisms. Yet, a common objective is
that users can rely on security assumptions as of wired links. that users may make the same security assumptions as for wired
ULE security could achieve this by protecting the vulnerable (in links [RFC3819]. ULE security could achieve this by protecting
terms of passive attacks) ULE link. the vulnerable (in terms of passive attacks) ULE Stream.
In contrast to the above, if a ULE Stream is used to directly In contrast to the above, a ULE Stream can be used to link
join networks which are considered physically secure, for example networks such as branch offices to a central office. ULE link-
branch offices to a central office, ULE link Security could be layer security could be the sole provider of confidentiality and
the sole provider of confidentiality and integrity. In this integrity. In this scenario, users requiring high assurance of
scenario, governmental users could still have to employ approved security (e.g. government use) will need to employ approved
cryptographic equipment at the network layer or above, unless a cryptographic equipment (e.g. at the network layer). An
manufacturer of ULE Link Security equipment obtains governmental implementation of ULE Link Security equipment could also be
approval for their implementation. certified for use by specific user 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 obtain information that is being transmitted. In goal to obtain information that is being transmitted. In
broadcast networks (especially those utilising widely available broadcast networks (especially those utilising widely available
low-cost physical layer interfaces, such as DVB) passive threats low-cost physical layer interfaces, such as DVB) passive threats
are considered the major threats. An example of such a threat is are the major threats. One example is an intruder monitoring the
an intruder monitoring the MPEG-2 transmission broadcast and then MPEG-2 transmission broadcast and then extracting the data
extracting traffic information concerning the communication carried within the link. Another example is of an intruder trying
between IP hosts using a link. Another example is of an intruder to determine the identity of the communicating parties and the
trying to gain information about the communication parties by volume of their traffic by sniffing (L2) addresses. This is a
monitoring their ULE Receiver NPA addresses; an intruder can gain
information by determining the layer 2 identity of the
communicating parties and the volume of their traffic. This is a
well-known issue in the security field; however it is more of a well-known issue in the security field; however it is more of a
problem in the case of broadcast networks such as MPEG-2 problem in the case of broadcast networks such as MPEG-2
transmission networks because of the easy availability of transmission networks because of the easy availability 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 sophisticated resources and may require access to the more sophisticated resources and may require access to the
transmitter. Within the context of MPEG-2 transmission networks, transmitter. Within the context of MPEG-2 transmission networks,
examples of active attacks are: examples of active attacks are:
o Masquerading: An entity pretends to be a different entity. o Masquerading: An entity pretends to be a different entity.
This includes masquerading other users and subnetwork control This includes masquerading other users and subnetwork control
plane messages. plane 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 to previous broadcast data is easy. access to previous broadcast data is easy.
o Denial of Service attacks: When an entity fails to perform its o Denial-of-Service (DoS) attacks: When an entity fails to
proper function or acts in a way that prevents other entities perform its proper function or acts in a way that prevents
from performing their proper functions. other entities from performing their proper functions.
The active threats mentioned above are major security concerns The active threats mentioned above are major security concerns
for the Internet community [BELLOVIN]. Masquerading and for the Internet community [BELLOVIN]. Masquerading and
modification of IP packets are comparatively easy in an Internet modification of IP packets are comparatively easy in an Internet
environment whereas such attacks are in fact much harder for environment, whereas such attacks are in fact much harder for
MPEG-2 broadcast links. This could for instance motivate the MPEG-2 broadcast links. This could for instance motivate the
mandatory use of sequence numbers in IPsec, but not for mandatory use of sequence numbers in IPsec, but not for
synchronous links. This is further reflected in the security synchronous links. This is further reflected in the security
requirements for Case 2 and 3 in section 4 below. requirements for Case 2 and 3 in section 4 below.
As explained in section 3.1, the PID associated with an As explained in section 3.1, the PID associated with an
Elementary Stream can be modified (e.g. in some systems by Elementary Stream can be modified (e.g. in some systems by
reception of an updated SI table, or in other systems until the reception of an updated SI table, or in other systems until the
next announcement/discovery data is received). An attacker that next announcement/discovery data is received). An attacker that
is able to modify the content of the received multiplex (e.g. is able to modify the content of the received multiplex (e.g.
replay data and/or control information) could inject data locally replay data and/or control information) could inject data locally
into the received stream with an arbitrary PID value. into the received stream with an arbitrary PID value.
3.3. Threat Scenarios 3.3. Threat cases
Analysing the topological scenarios for MPEG-2 Transmission Analysing the topological scenarios for MPEG-2 Transmission
Networks in section 1, the security threat cases can be Networks in section 1, the security threats can be abstracted
abstracted into three cases: into three cases:
o Case 1: Monitoring (passive threat). Here the intruder o Case 1: Monitoring (passive threat). Here the intruder
monitors the ULE broadcasts to gain information about the ULE monitors the ULE broadcasts to gain information about the ULE
data and/or tracking the communicating parties identities (by data and/or tracking the communicating parties identities (by
monitoring the destination NPA). In this scenario, measures monitoring the destination NPA). In this scenario, measures
must be taken to protect the ULE payload data and the identity must be taken to protect the ULE payload data and the identity
of ULE Receivers. of ULE Receivers.
o Case 2: Locally conduct active attacks on the MPEG-TS o Case 2: Locally conduct active attacks on the MPEG-TS
multiplex. Here an intruder is assumed to be sufficiently multiplex. Here an intruder is assumed to be sufficiently
sophisticated to over-ride the original transmission from the sophisticated to over-ride the original transmission from the
ULE Encapsulation Gateway and deliver a modified version of ULE Encapsulation Gateway and deliver a modified version of
the MPEG-TS transmission to a single ULE Receiver or a small the MPEG-TS transmission to a single ULE Receiver or a small
group of Receivers (e.g. in a single company site). The MPEG-2 group of Receivers (e.g. in a single company site). The MPEG-2
transmission network operator might not be aware of such transmission network operator might not be aware of such
attacks. Measures must be taken to ensure ULE source attacks. Measures must be taken to ensure ULE data integrity
authentication and preventing replay of old messages. and authenticity and preventing replay of old messages.
o Case 3: Globally conduct active attacks on the MPEG-TS o Case 3: Globally conduct active attacks on the MPEG-TS
multiplex. Here we assume an intruder is very sophisticated multiplex. Here we assume an intruder is very sophisticated
and able to over-ride the whole MPEG-2 transmission multiplex. and able to over-ride the whole MPEG-2 transmission multiplex.
The requirements here are similar to scenario 2. The MPEG-2 The requirements here are similar to scenario 2. The MPEG-2
transmission network operator can usually identify such transmission network operator can usually identify such
attacks and may resort to some means to restore the original attacks and may resort to some means to restore the original
transmission. 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 network with knowledge of the secret material. the network with knowledge of the secret material.
o Outsider attacks i.e. active attacks from outside of a virtual o Outsider attacks, i.e. active attacks from outside of a
private network. virtual private network.
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 transmission systems. Case 2 is likely to a lesser degree MPEG-2 transmission systems. Case 2 is likely to a lesser degree
within certain network configurations, especially when there are within certain network configurations, especially when there are
insider attacks. Hence, protection against such active attacks insider attacks. Hence, protection against such active attacks
should be used only when such a threat is a real possibility. should be used only when such a threat is a real possibility.
Case 3 is envisaged to be less practical, because it will be very Case 3 is envisaged to be less practical, because it will be very
difficult to pass unnoticed by the MPEG-2 transmission operator. difficult to pass unnoticed by the MPEG-2 transmission operator.
It will require restoration of the original transmission. The It will require restoration of the original transmission. The
assumption being here is that physical access to the network assumption being here is that physical access to the network
components (multiplexers, etc) and/or connecting physical media components (multiplexers, etc) and/or connecting physical media
is secure. Therefore case 3 is not considered further in this is secure. Therefore case 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 considered in order to Req 1. Data confidentiality MUST be provided by a link that
mitigate passive and active threats in MPEG-2 broadcast supports ULE Stream Security to prevent passive attacks and
networks. reduce the risk of active threats.
Req 2. Protection of Layer 2 NPA address MAY be provided. In Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast
broadcast networks this protection can be used to prevent an networks this protection can be used to prevent an intruder
intruder tracking the identity of ULE Receivers and the volume tracking the identity of ULE Receivers and the volume of their
of their traffic. traffic.
Req 3. Integrity protection and authentication of the ULE source Req 3. Integrity protection and source authentication of ULE
MAY be provided to prevent active attacks described in section Stream data are OPTIONAL. These can be used to prevent active
3.2. attacks described in section 3.2.
Req 4. Protection against replay attacks MAY be provided. This is Req 4. Protection against replay attacks is OPTIONAL. This is
required for the active attacks described in section 3.2. required for the active attacks described in section 3.2.
Req 5. Layer L2 ULE Source and Receiver authentication MAY be Req 5. L2 ULE Source and Receiver authentication is OPTIONAL.
provided. This is normally performed during the initial key This can be performed during the initial key exchange and
exchange and authentication phase, before the ULE Receiver can authentication phase, before the ULE Receiver can join a
join a secure session with the ULE Encapsulator (ULE source). secure session with the ULE Encapsulator (ULE source). This
This is normally receiver to hub authentication and it could could be either unidirectional or bidirectional authentication
be either unidirectional or bidirectional authentication based based on the underlying key management protocol.
on the underlying key management protocol.
Other general requirements are: Other general requirements for all threat cases for link-layer
security are:
GReq (a) ULE key management functions SHALL 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 insertion of keys and policy into the relevant manual insertion of keys and policy into the relevant
databases. databases.
GReq (c) Algorithm agility MUST be supported. Changes in crypto GReq (c) Algorithm agility MUST be supported. Changes in crypto
algorithms, hashes as they become obsolete should be updated algorithms, hashes as they become obsolete should be updated
without affecting the overall security of the system. without affecting the overall security of the system.
GReq (d) Traceability SHOULD be supported to monitor the GReq (d) The security extension header MUST be compatible with
transmission network using log files to record the activities other ULE extension headers. There could be other extension
in the network and detect any intrusion. headers (either mandatory or optional). It is RECOMMENDED that
these are placed after the security extension header. This
GReq (e) Protection against loss of service (availability) permits full protection for all headers. It also avoids
through malicious reconfiguration of system components (see situations where the SNDU has to be discarded on processing the
Figure 1) MUST be present. security extension header, while preceding headers have already
been evaluated. One exception is the Timestamp extension which
GReq (f) The security system MUST be compatible with other SHOULD precede the security extension header [RFC5163]. In this
networking functions such as NAT Network Address Translation case, the timestamp will be unaffected by security services
(NAT) [RFC3715] or TCP acceleration can be used in a wireless such as data confidentiality and can be decoded without the
broadcast networks. need for key material.
GReq (g) The security extension header MUST be compatible with
other ULE extension headers
GReq (h) Where a ULE Stream carries a set of IP traffic flows to
different destinations with a range of properties (multicast,
unicast, etc), it is often not appropriate to provide IP
confidentiality services for the entire ULE Stream. For many
expected applications of ULE, a finer-grain control MAY
therefore be required, at least permitting control of data
confidentiality/authorisation at the level of a single MAC/NPA
address.
Examining the threat cases in section 3.3, the security Examining the threat cases in section 3.3, the security
requirements for each case can be summarised as: requirements 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 monitoring of the ULE data (such as user information prevent monitoring of the ULE data (such as user information
and IP addresses). Protection of NPA addresses (Req 2) MAY be and IP addresses). Protection of NPA addresses (Req 2) MAY be
provided to prevent tracking ULE Receivers and their provided to 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 implemented such as authentication schemes using Message be implemented such as authentication schemes using Message
Authentication Codes, digital signatures or TESLA [RFC4082] in Authentication Codes, digital signatures, or TESLA [RFC4082]
order to provide integrity protection and source in order to provide integrity protection and source
authentication (Req 2, Req 3 and Req 5). In addition sequence authentication (Req 2, Req 3 and Req 5). In addition, sequence
numbers (Req 4) MAY be used to protect against replay attacks. numbers (Req 4) MAY be used to protect against replay attacks.
In terms of outsider attacks, group authentication using In terms of outsider attacks, group authentication using
Message Authentication Codes should provide the same level of Message Authentication Codes should provide the same level of
security (Req 3 and 5). This will significantly reduce the security (Req 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 MPEG-TS stream. However, scenario 2 threats apply into the MPEG-TS stream. However, scenario 2 threats apply
only in specific service cases, and therefore authentication only in specific service cases, and therefore authentication
and protection against replay attacks are OPTIONAL. Such and protection against replay attacks are OPTIONAL. Such
measures incur additional transmission as well as processing measures incur additional transmission as well as processing
overheads. Moreover, intrusion detection systems may also be overheads. Moreover, intrusion detection systems may also be
needed by the MPEG-2 network operator. These should best be needed by the MPEG-2 network operator. These should best be
coupled with perimeter security policy to monitor most denial- coupled with perimeter security policy to monitor common DoS
of-service 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 to Case 2 but since the MPEG-2 transmission network similar to Case 2 but since the MPEG-2 transmission network
operator can usually identify such attacks the constraints on operator can usually identify such attacks the constraints on
intrusion detections are less than in case 2. intrusion detections are less than in case 2.
The general requirements GReq(a) to GReq(h) are good security
practices and apply to all the scenarios above, where
appropriate.
5. Design recommendations for ULE Security Header Extension
Table 1 below shows the threats that are applicable to ULE Table 1 below shows the threats that are applicable to ULE
networks and the relevant security mechanism to mitigate those networks, and the relevant security mechanisms to mitigate those
threats. This would help in the design of the ULE Security threats.
extension header. For example this could help in the selection of
security fields in the ULE Security extension Header design.
Moreover the security services could also be grouped into
profiles based on different security requirements. One example is
to have a base profile which does payload encryption and identity
protection. The second profile could do the above as well as
source authentication.
A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as GSAKMP [RFC4535] and
GDOI [RFC3547] protocols defined by the IETF Multicast Security
(MSEC) working group. This does not preclude the use of other key
management methods in scenarios where this is more appropriate.
IPsec or TLS also provide a proven security architecture defining
key exchange mechanisms and the ability to use a range of
cryptographic algorithms. ULE security can make use of these
established mechanisms and algorithms.
Mitigation of Threat Mitigation of Threat
----------------------------------------------- -----------------------------------------------
| 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 |
Attack | | | | | | | Attack | | | | | | |
---------------|--------|-------|-------|-------|-------|------| ---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X | | Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| 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
Table 1 may assist in selecting fields within a ULE Security
Extension Header framework.
Security services may be grouped into profiles based on security
requirements, e.g. a base profile (with payload encryption and
identity protection), and a second profile that extends this to
also provide source authentication and protection against replay
attacks.
A modular design of ULE security may allow it to use and benefit
from existing key management protocols, such as GSAKMP [RFC4535]
and GDOI [RFC3547] defined by the IETF Multicast Security (MSEC)
working group. This does not preclude the use of other key
management methods in scenarios where this is more appropriate.
IPsec and TLS also provide a proven security architecture
defining key exchange mechanisms and the ability to use a range
of cryptographic algorithms. ULE security can make use of these
established mechanisms and algorithms.
6. Compatibility with Generic Stream Encapsulation 6. Compatibility with Generic Stream Encapsulation
The [ID-EXT] document describes two new Header Extensions that The [RFC5163] document describes three new Extension Headers that
may be used with Unidirectional Link Encapsulation, ULE, may be used with Unidirectional Link Encapsulation, ULE,
[RFC4326] and the Generic Stream Encapsulation (GSE) that has [RFC4326] and the Generic Stream Encapsulation (GSE) that has
been designed for the Generic Mode (also known as the Generic been designed for the Generic Mode (also known as the Generic
Stream (GS)), offered by second-generation DVB physical layers, Stream (GS)), offered by second-generation DVB physical layers
and specifically for DVB-S2 [ID-EXT]. [GSE].
The security threats and requirement presented in this document The security threats and requirement presented in this document
are applicable to ULE and GSE encapsulations. It might be are applicable to ULE and GSE encapsulations.
desirable to authenticate some/all of the headers; such decision
can be part of the security policy for the MPEG-2 transmission
network.
7. Summary 7. Summary
This document analyses a set of threats and security This document analyses a set of threats and security
requirements. It also defines the requirements for ULE security requirements. It defines the requirements for ULE security and
and states the motivation for link security as a part of the states the motivation for link security as a part of the
Encapsulation layer. Encapsulation layer.
ULE security includes a need to provide link-layer encryption and ULE security must provide link-layer encryption and ULE Receiver
ULE Receiver identity protection. There is an optional identity protection. The framework must support the optional
requirement for link-layer authentication and integrity assurance ability to provide for link-layer authentication and integrity
as well as protection against insertion of old (duplicated) data assurance, as well as protection against insertion of old
into the ULE stream (i.e. replay protection). This is optional (duplicated) data into the ULE stream (i.e. replay protection).
because of the associated overheads for the extra features and This set of features is optional to reduce encapsulation overhead
they are only required for specific service cases. when not required.
ULE link security (between a ULE Encapsulation Gateway to ULE stream security between a ULE Encapsulation Gateway and the
Receivers) is considered as an additional security mechanism to corresponding Receiver(s) is considered an additional security
IPsec, TLS, and application layer end-to-end security, and not as mechanism to IPsec, TLS, and application layer end-to-end
a replacement. It allows a network operator to provide similar security, and not as a replacement. It allows a network operator
functions to that of IPsec, but in addition provides MPEG-2 to provide similar functions to that of IPsec, but in addition
transmission link confidentiality and protection of ULE Receiver provides MPEG-2 transmission link confidentiality and protection
identity (NPA). End-to-end security mechanism may then be used of ULE Receiver identity (NPA).
additionally and independently for providing strong
authentication of the end-points in the communication.
Annexe 1 describes a set of building blocks that may be used to Annexe 1 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 [RFC4346], 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 links. It is recommended that an ISP or user provide end- wired links. It is recommended that an ISP or user provide end-
to-end security services based on well known mechanisms such as to-end security services based on well known mechanisms such as
IPsec or TLS. IPsec or 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] that are not addressed in this document (out of scope) [RFC4326] that are not addressed in this document (i.e. are out
such as: of scope), e.g.:
o The security issue with un-initialised stuffing bytes. In o The security issue with un-initialised stuffing bytes. In ULE,
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 networking environment. The removal for bridged bridged networking environment. The removal for bridged frames
frames exposes the traffic to potentially undetected exposes the traffic to potentially undetected corruption while
corruption while being processed by the Encapsulator and/or being processed by the Encapsulator and/or Receiver.
Receiver.
o There is a potential security issue when a Receiver receives a o There is a potential security issue when a Receiver receives a
PDU with two Length fields: The Receiver would need to PDU with two Length fields: The Receiver would need to
validate the actual length and the Length field and ensure validate the actual length and the Length field and ensure
that inconsistent values are not propagated by the network. that inconsistent values are not propagated by the network.
9. IANA Considerations 9. IANA Considerations
There are no IANA actions defined in this document. There are no IANA actions defined in this document.
10. Acknowledgments 10. 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 from Laurence Duquerroy and Stephane Coombes (ESA), contributions from Laurence Duquerroy and Stephane Coombes (ESA),
Yim Fun Hu (University of Bradford) and Michael Noisternig from and Yim Fun Hu (University of Bradford).
University of Salzburg.
11. References 11. References
11.1. Normative References 11.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 I", ISO 13818-1, International Standards Part I", ISO 13818-1, International Standards
Organisation (ISO), 2000. Organisation (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, 1997.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of
IP Datagrams over an MPEG-2 Transport Stream (TS)",
IETF RFC 4326, December 2005.
11.2. Informative References 11.2. Informative References
[ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution [RFC4947] G. Fairhurst, M.-J. Montpetit, "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", Mechanisms for IP Datagrams over MPEG-2 Networks",
Work in Progress <draft-ietf-ipdvb-ar-05.txt. IETF RFC 4947, July 2007.
[ID-EXT] G. Fairhurst and B. Collini-Nocker, "Extension [RFC5163] G. Fairhurst and B. Collini-Nocker, "Extension Header
Formats for Unidirectional Lightweight Encapsulation formats for Unidirectional Lightweight Encapsulation
(ULE) and the Generic Stream Encapsulation (GSE)", (ULE) and the Generic Stream Encapsulation (GSE)",
Work in Progress, draft-ietf-ipdvb-ule-ext-07.txt, IETF RFC 5163, April 2008.
January 2008.
[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, IEEE Computer Society, (also ISO/IEC 8802-2), 802.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), 1995. (ITU-T), 1995.
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., [RFC4259] M.-J. Montpetit, G. Fairhurst, H. Clausen, B.
Collini-Nocker, B., and H. Linder, "A Framework for Collini-Nocker, and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks", Transmission of IP Datagrams over MPEG-2 Networks",
IETF RFC 4259, November 2005. IETF RFC 4259, November 2005.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of
IP Datagrams over an MPEG-2 Transport Stream (TS)",
IETF RFC 4326, December 2005.
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
[BELLOVIN] S.Bellovin, "Problem Area for the IP Security [BELLOVIN] S.Bellovin, "Problem Area for the IP Security
protocols", Computer Communications Review 2:19, pp. protocols", Computer Communications Review 2:19, pp.
32-48, April 989. http://www.cs.columbia.edu/~smb/ 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- [RFC4082] A. Perrig, D. Song, " Timed Efficient Stream Loss-
Tolerant Authentication (TESLA): Multicast Source Tolerant Authentication (TESLA): Multicast Source
Authentication Transform Introduction", IETF RFC Authentication Transform Introduction", IETF RFC
4082, June 2005. 4082, June 2005.
[RFC4535] H Harney, et al, "GSAKMP: Group Secure Association [RFC4535] H. Harney, et al, "GSAKMP: Group Secure Association
Group Management Protocol", IETF RFc 4535, June 2006. Group Management Protocol", IETF RFc 4535, June 2006.
[RFC3547] M. Baugher, et al, "GDOI: The Group Domain of [RFC3547] M. Baugher, et al, "GDOI: The Group Domain of
Interpretation", IETF RFC 3547. Interpretation", IETF RFC 3547.
[WEIS06] Weis B., et al, "Multicast Extensions to the Security [WEIS08] B. Weis, et al, "Multicast Extensions to the Security
Architecture for the Internet", <draft-ietf-msec- Architecture for the Internet", <draft-ietf-msec-
ipsec-extensions-02.txt>, June 2006, IETF Work in ipsec-extensions-09.txt>, June 2008, IETF Work in
Progress. Progress.
[RFC3715] B. Aboba and W Dixson, "IPsec-Network Address [RFC3715] B. Aboba, W. Dixson, "IPsec-Network Address
Translation (NAT) Compatibility Requirements" IETF Translation (NAT) Compatibility Requirements" IETF
RFC 3715, March 2004. RFC 3715, March 2004.
[RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", IETF RFC 4346, April (TLS) Protocol Version 1.1", IETF RFC 4346, April
2006. 2006.
[RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing
Proxies Intended to Mitigate Link-Related Proxies Intended to Mitigate Link-Related
Degradations", IETF RFC 3135, June 2001. Degradations", IETF RFC 3135, June 2001.
[RFC4301] Kent, S. and Seo K., "Security Architecture for the [RFC4301] S. Kent, K. Seo, "Security Architecture for the
Internet Protocol", IETF RFC 4301, December 2006. Internet Protocol", IETF RFC 4301, December 2006.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R.
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L.
and L. Wood, "Advice for Internet Subnetwork Wood, "Advice for Internet Subnetwork Designers", BCP
Designers", BCP 89, IETF RFC 3819, July 2004. 89, IETF RFC 3819, July 2004.
[RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", IETF RFC 4251, January 2006. Protocol Architecture", IETF RFC 4251, January 2006.
12. Author's Addresses 12. Author's Addresses
Haitham Cruickshank Haitham Cruickshank
Centre for Communications System Research (CCSR) Centre for Communications System Research (CCSR)
University of Surrey University of Surrey
Guildford, Surrey, GU2 7XH Guildford, Surrey, GU2 7XH
UK UK
Email: h.cruickshank@surrey.ac.uk Email: h.cruickshank@surrey.ac.uk
Sunil Iyengar
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: S.Iyengar@surrey.ac.uk
Prashant Pillai Prashant Pillai
Mobile and Satellite Communications Research Centre (MSCRC) Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology School of Engineering, Design and Technology
University of Bradford University of Bradford
Richmond Road, Bradford BD7 1DP Richmond Road, Bradford BD7 1DP
UK UK
Email: p.pillai@bradford.ac.uk Email: p.pillai@bradford.ac.uk
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
Sunil Iyengar
Space & Defence
Logica
Springfield Drive
Leatherhead
Surrey KT22 7LP
UK
Email: sunil.iyengar@logica.com
13. IPR Notices 13. IPR Notices
Copyright (c) The IETF Trust (2007). Copyright (c) The IETF Trust (2007).
13.1. Intellectual Property Statement 13.1. Intellectual Property Statement
Full Copyright Statement Full Copyright Statement
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
skipping to change at page 21, line 27 skipping to change at page 22, line 17
A key management framework is required to provide security at the A key management framework is required to provide security at the
ULE level using extension headers. This key management framework ULE level using extension headers. This key management framework
is responsible for user authentication, access control, and is responsible for user authentication, access control, and
Security Association negotiation (which include the negotiations Security Association negotiation (which include the negotiations
of the security algorithms to be used and the generation of the of the security algorithms to be used and the generation of the
different session keys as well as policy material). The Key different session keys as well as policy material). The Key
management framework can be either automated or manual. Hence management framework can be either automated or manual. Hence
this key management client entity (shown as the Key Management this key management client entity (shown as the Key Management
Group Member block in figure 2) will be present in all ULE Group Member block in figure 2) will be present in all ULE
receivers as well as at the ULE Encapsulators. The ULE Receivers as well as at the ULE Encapsulators. The ULE
Encapsulator could also be the Key Management Group Server Entity Encapsulator could also be the Key Management Group Server Entity
(shown as the Key Management Group Server block in figure 2. This (shown as the Key Management Group Server block in figure 2. This
happens when the ULE Encapsulator also acts as the Key Management 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 of keying protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying
material. material.
A.1.2 ULE Extension Header Block A.1.2 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 provide the security features of data confidentiality, data to provide the security features of data confidentiality, data
integrity, data authentication and mechanisms to prevent replay integrity, data authentication, and mechanisms to prevent replay
attacks. Security keying material will be used for the different attacks. Security keying material will be used for the different
security algorithms (for encryption/decryption, MAC generation, security algorithms (for encryption/decryption, MAC generation,
etc.), which are used to meet the security requirements, etc.), which are used to meet the security requirements,
described in detail in Section 4 of this document. described in detail in Section 4 of this document.
This block will use the keying material and policy information This block will use the keying material and policy information
from the ULE security database block on the ULE payload to from the ULE security database block on the ULE payload to
generate the secure ULE Extension Header or to decipher the generate the secure ULE Extension Header or to decipher the
secure ULE extension header to get the ULE payload. An example secure ULE extension header to get the ULE payload. An example
overview of the ULE Security extension header format along with overview of the ULE Security extension header format along with
the ULE header and payload is shown in figure 3 below. There the ULE header and payload is shown in figure 3 below.
could be other extension headers (either mandatory or optional).
It is RECOMMENDED that these are placed after the security
extension header. This permits full protection for all headers.
It avoids situations where the SNDU has to be discarded on
processing the security extension header, while preceding headers
have already have been evaluated. One exception is the Timestamp
extension which SHOULD precede the security extension header [ID-
EXT]. When applying the security services for example
confidentiality, input to the cipher algorithm will cover the
fields from the end of the security extension header to the end
of the PDU.
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Header Extension Placement Figure 3: ULE Security Extension Header Placement
A.1.3 ULE Security Databases Block A.1.3 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 Secure 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 ULE peers. different ULE peers.
o ULE-SPD: ULE Secure Policy Database contains the policies as o ULE-SPD: ULE Security Policy Database contains the policies as
defined by the system manager. These policies describe the defined 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 will be based on IPSec The design of these two databases may be based on IPsec databases
databases as defined in RFC4301 [RFC4301]. as defined in RFC4301 [RFC4301].
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 have to support for all use cases will be defined in a will have to support for all use cases will be defined in a
separate document. This document only highlights the need for separate document. This document only highlights the need for
such interfaces between the ULE data plane and the Key Management such interfaces between the ULE data plane and the Key Management
control plane. control plane.
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
skipping to change at page 23, line 21 skipping to change at page 23, line 48
A.2.1 Key Management <-> ULE Security databases A.2.1 Key Management <-> ULE Security databases
This interface is between the Key Management group member block This interface is between the Key Management group member block
(GM client) and the ULE Security Database block (shown in figure (GM client) and the ULE Security Database block (shown in figure
2). The Key Management GM entity will communicate with the GCKS 2). The Key Management GM entity will communicate with the GCKS
and then get the relevant security information (keys, cipher and then get the relevant security information (keys, cipher
mode, security service, ULE_Security_ID and other relevant keying mode, security service, ULE_Security_ID and other relevant keying
material as well as policy) and insert this data into the ULE material as well as policy) and insert this data into the ULE
Security database block. The Key Management could be either Security database block. The Key Management could be either
automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]), or security
inserted using this interface. The following three interface information could be manually inserted using this interface. The
functions are defined: following three interface functions are defined:
. Insert_record_database (char * Database, char * record, char * . Insert_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
. Update_record_database (char * Database, char * record, char * . Update_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
. Delete_record_database (char * Database, char * Unique_ID); . Delete_record_database (char * Database, char * Unique_ID);
The definitions of the variables are as follows: The definitions of the variables are as follows:
. Database - This is a pointer to the ULE Security databases . Database - This is a pointer to the ULE Security databases
. record - This is the rows of security attributes to be . record - This is the rows of security attributes to be
entered or modified in the above databases entered or modified in the above databases
. Unique_ID - This is the primary key to lookup records (rows . Unique_ID - This is the primary key to lookup records (rows
of security attributes) in the above databases of 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. To send Security Extension Header block as shown in figure 2. When
traffic, firstly the ULE encapsulator using the ULE_Security_ID, sending traffic, the ULE encapsulator uses the Destination
Destination Address and possibly the PID, searches the ULE Address, the PID, and possibly other information such as L3
Security Database for the relevant security record. It then uses source and destination addresses to locate the relevant security
the data in the record to create the ULE security extension record within the ULE Security Database. It then uses the data in
header. For received traffic, the ULE decapsulator on receiving the record to create the ULE security extension header. For
the ULE SNDU will first get the record from the Security Database received traffic, the ULE decapsulator on receiving the ULE SNDU
using the ULE_Security_ID, the Destination Address and possibly will use the Destination Address, the PID, and a ULE Security ID
the PID. It then uses this information to decrypt the ULE inserted by the ULE encapsulator into the security extension to
extension header. For both cases (either send or receive traffic) retrieve the relevant record from the Security Database. It then
only one interface is needed since the only difference between uses this information to decrypt the ULE extension header. For
the sender and receiver is the direction of the flow of traffic: both cases (either send or receive traffic) only one interface is
needed since the main difference between the sender and receiver
is the direction of the flow of traffic:
. Get_record_database (char * Database, char * record, char * . 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 in MPEG-2 transmission networks employing ULE. This security in MPEG-2 transmission networks employing ULE. This
section compares the disadvantages when security functionalities section compares the placement of security functionalities in
are present 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 links. 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 transparently over MPEG-2 transmission links with little security 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 link, 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 gateway implementation of IPsec uses tunnel mode. Such security gateway implementation of IPsec uses tunnel mode. Such
usage has the following disadvantages: usage has the following disadvantages:
o There is an extra transmission overhead associated with using o There is an extra transmission overhead associated with using
IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6).
o There is a need to protect the identity (NPA) of ULE Receivers o There is a need to protect the identity (NPA) of ULE Receivers
over the ULE broadcast medium; IPsec is not suitable for over the ULE broadcast medium; IPsec is not suitable for
providing this service. In addition, the interfaces of these providing this service. In addition, the interfaces of these
devices do not necessarily have IP addresses (they can be L2 devices do not necessarily have IP addresses (they can 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 progress in defining the extra detail needed for multicast in progress in defining the extra detail needed for multicast
and to use the tunnel mode with address preservation to allow and to use the tunnel mode with address preservation to allow
efficient multicasting. For further details refer to [WEIS06]. efficient multicasting. For further details refer to [WEIS08].
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. Therefore all multiplexed traffic will share the same PID. Therefore all multiplexed traffic will share the same
security keys. security keys.
skipping to change at page 26, line 13 skipping to change at page 26, line 41
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 TV services and is not well-suited to IP packet transmission. for TV services and is not well-suited to IP packet transmission.
Some other systems are specified in standards such as MPE [ETSI- Some other systems are specified in standards such as MPE [ETSI-
DAT], but there are currently no known implementations. DAT], but there are currently no known implementations.
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 of ULE link from eavesdropping and ULE Receiver protection of ULE Stream from eavesdropping and ULE Receiver
identity are major requirements. identity are major requirements.
There are several major advantages in using ULE link layer There are several major advantages in using ULE link layer
security: 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 IP flow or per Receiver NPA address. per 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
skipping to change at line 1295 skipping to change at page 29, line 21
o Figure 1 modified to have consistent use of Security Services. o Figure 1 modified to have consistent use of Security Services.
o Text modified in Section 4 to clearly state the requirements. o Text modified in Section 4 to clearly state the requirements.
o Moved Section 5 to the Appendix B o Moved Section 5 to the Appendix B
o Updated IANA consideration section o Updated IANA consideration section
o Numbered the different requirements and cross referenced them o Numbered the different requirements and cross referenced them
within the text. 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.
 End of changes. 99 change blocks. 
300 lines changed or deleted 291 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/