draft-ietf-ipdvb-sec-req-01.txt   draft-ietf-ipdvb-sec-req-02.txt 
Internet Engineering Task Force H.Cruickshank Internet Engineering Task Force H.Cruickshank
Internet Draft S. Iyengar Internet Draft S. Iyengar
draft-ietf-ipdvb-sec-req-01.txt University of Surrey, UK draft-ietf-ipdvb-sec-req-02.txt University of Surrey, UK
L. Duquerroy L. Duquerroy
Alcatel Alenia Space, France Alcatel Alenia Space, France
Expires: September 2, 2007 P. Pillai Expires: November 10, 2007 P. Pillai
University of Bradford, UK University of Bradford, UK
Category: WG Draft intended for PS March 2, 2007
Category: WG Draft intended for INFORMATIONAL RFC May 10, 2007
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-01.txt draft-ietf-ipdvb-sec-req-02.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 41 skipping to change at page 1, line 42
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 September 2, 2007. This Internet-Draft will expire on November 10, 2007.
Abstract Abstract
The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a
range of transmission methods for a range of services. This range of transmission methods for a range of services. This
document provides a threat analysis and derives the security document provides a threat analysis and derives the security
requirements when using the Transport Stream, TS, to support an requirements when using the Transport Stream, TS, to support an
Internet network-layer using Unidirectional Lightweight Internet network-layer using Unidirectional Lightweight
Encapsulation (ULE) [RFC4326]. The document also provides the Encapsulation (ULE) [RFC4326]. The document also provides the
motivation for link-level 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.
Table of Contents Table of Contents
1. Introduction..............................................2 1. Introduction..............................................2
2. Requirements notation......................................4 2. Requirements notation......................................4
3. Threat Analysis...........................................6 3. Threat Analysis...........................................6
3.1. System Components.....................................6 3.1. System Components.....................................6
Figure 1: An example configuration for a unidirectional........6 Figure 1: An example configuration for a unidirectional........6
Service for IP transport over MPEG-2 [RFC4259]................6 Service for IP transport over MPEG-2 [RFC4259]................6
3.2. Threats..............................................8 3.2. Threats..............................................8
3.3. Threat Scenarios......................................9 3.3. Threat Scenarios.....................................10
4. Security Requirements for IP over MPEG-2 TS...............11 4. Security Requirements for IP over MPEG-2 TS...............11
5. IPsec and MPEG-2 Transmission Networks....................12 4.1. Compatibility with Generic Stream Encapsulation.......13
6. Motivation for ULE link-layer security....................13 5. IPsec and MPEG-2 Transmission Networks....................13
6.1. Link security below the Encapsulation layer..........13 6. Motivation for ULE link-layer security....................14
6.2. Link security as a part of the Encapsulation layer....14 6.1. Link security below the Encapsulation layer..........14
7. Summary..................................................15 6.2. Link security as a part of the encapsulation layer....15
8. Security Considerations...................................15 7. Summary..................................................16
9. IANA Considerations......................................16 8. Security Considerations...................................17
10. Acknowledgments.........................................16 9. IANA Considerations......................................17
11. References..............................................16 10. Acknowledgments.........................................17
11.1. Normative References................................16 11. References..............................................18
11.2. Informative References..............................16 11.1. Normative References................................18
Author's Addresses..........................................18 11.2. Informative References..............................18
Intellectual Property Statement..............................19 Author's Addresses..........................................20
Disclaimer of Validity.............Error! Bookmark not defined. 12. IPR Notices.............................................20
Copyright Statement................Error! Bookmark not defined. 12.1. Intellectual Property Statement.....................20
Document History............................................20 12.2. Intellectual Property...............................21
13. Copyright Statement......................................21
Document History............................................21
Appendix A: ULE Security Framework...........................22 Appendix A: ULE Security Framework...........................22
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 format that allows it to carry additional
header information to assist in network/Receiver processing. The header information to assist in network/Receiver processing. The
encapsulation satisfies the design and architectural requirement encapsulation satisfies the design and architectural requirement
for a lightweight encapsulation defined in RFC 4259 [RFC4259]. 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. 1. Broadcast TV and Radio Delivery.
2. Broadcast Networks used as an ISP. This resembles to scenario 2. 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 3. 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.
skipping to change at page 3, line 43 skipping to change at page 3, line 46
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-level 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 header extension, 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.
skipping to change at page 4, line 29 skipping to change at page 4, line 33
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-2, IEEE-802.2]. 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 5, line 34 skipping to change at page 5, line 38
document, this term describes a table that is defined by another document, this term describes a table that is defined by another
standards body to convey information about the services carried standards body to convey information about the services carried
in a TS Multiplex. A Table may consist of one or more Table in a TS Multiplex. A Table may consist of one or more Table
Sections; however, all sections of a particular SI Table must be Sections; however, all sections of a particular SI Table must be
carried over a single TS Logical Channel [ISO-MPEG2]. carried over a single TS 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 level using TS Packets; it represents layer 2 of the MPEG-2 layer using TS Packets; it represents layer 2 of the
ISO/OSI reference model. See also TS Logical Channel and TS ISO/OSI 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 Logical Channels sent over a single lower-layer connection. TS Logical Channels sent over a single lower-layer connection.
This may be a common physical link (i.e., a transmission at a This may be a common physical link (i.e., a transmission at a
specified symbol rate, FEC setting, and transmission frequency) specified symbol rate, FEC setting, and transmission frequency)
or an encapsulation provided by another protocol layer (e.g., or an encapsulation provided by another protocol layer (e.g.,
Ethernet, or RTP over IP). The same TS Logical Channel may be 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
skipping to change at page 6, line 48 skipping to change at page 7, line 6
|Modulator +---------->+ Receiver | |Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+ +---------------+ MPEG-2 +------------+
TS Mux TS Mux
Figure 1: An example configuration for a unidirectional Figure 1: An example configuration for a unidirectional
Service for IP transport over MPEG-2 [RFC4259]. Service for IP transport over MPEG-2 [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 (or Encapsulator or ULE source) o ULE Encapsulation Gateways (the Encapsulator or ULE source)
o SI-Table signalling generator (input to the multiplexor) o SI-Table signalling generator (input to the multiplexor)
o Receivers o Receivers (the end points for ULE security)
o TS multiplexers (including re-multiplexers) o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
In an MPEG-2 network a set of signalling messages [ID-AR] may In an MPEG-2 network a set of signalling messages [ID-AR] 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 L2 control plane. Examples of signalling device) to form the Layer 2 (L2) control plane. Examples of
messages include the Program Association Table (PAT), Program Map signalling messages include the Program Association Table (PAT),
Table (PMT) and Network Information Table (NIT). In existing Program Map Table (PMT) and Network Information Table (NIT). In
MPEG-2 transmission networks, these messages are broadcast in the existing MPEG-2 transmission networks, these messages are
clear (no encryption or integrity checks). The integrity as well broadcast in the clear (no encryption or integrity checks). The
as authenticity of these messages is important for correct integrity as well as authenticity of these messages is important
working of the ULE network. Even though securing these messages for correct working of the ULE working of the ULE network, i.e.
is an orthogonal issue, one method recently proposed [ID-EF] supporting its security objectives in the area of availability,
encapsulates these messages using ULE. In such cases all the in addition to confidentiality and integrity. One method recently
security requirements of this draft apply in securing these proposed [ID-EF] encapsulates these messages using ULE. In such
signalling messages. cases all the security requirements of this document apply in
securing these signalling messages.
ULE link security focuses only on the security between the ULE ULE link security focuses only on the security between the ULE
Encapsulation Gateway (ULE source) and the Receiver. Securing the Encapsulation Gateway (ULE source) and the Receiver. Often times,
ULE source and receivers eliminates the need to consider security the user of satellite communication link have to secure their
issues regarding the remaining system components, such as communications beyond that satellite link, because terrestrial
multiplexers, re-multiplexers and modulators. public network links are utilized in addition to the satellite
link. Therefore, if users are concerned about loss of
confidentiality and loss of integrity of their communication
data, they will employ end-to-end network security mechanisms
like IPSec or TLS. Governmental users may be forced by
regulations to employ specific, approved implementations of those
mechanisms.
In contrast to the above, if a satellite link is used to directly
join networks which are considered physically secure, for example
branch offices to a central office, ULE Sec could be the sole
provider of confidentiality and integrity. In this scenario,
governmental users could still have to employ approved
cryptographic equipment at the network layer or above, unless a
ULE Sec equipment manufacturer would obtain governmental approval
for his implementation.
All of this means that in many cases the confidentiality and
integrity of the user data will already be taken care of. So ULE
security measures would focus on either providing traffic flow
confidentiality for user data that has already been encrypted or
user data encryption for users who choose not to implement end-
to-end security mechanisms.
In a MPEG-2 TS transmission network, the originating source of TS In a MPEG-2 TS transmission network, the originating source of TS
Packets is either a L2 interface device (media encoder, Packets is either a L2 interface device (media encoder,
encapsulation gateway, etc) or a L2 network device (TS 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 L3, gateway (e.g. ULE sender), the device may operate at L2 or Layer
and is not normally the originator of an IP traffic flow, and 3 (L3), and is not normally the originator of an IP traffic flow,
usually the IP source address of the packets that it forwards do and usually the IP source address of the packets that it forwards
not correspond to an IP address associated with the device. When do not correspond to an IP address associated with the device.
authentication of the IP source is required this must be provided When authentication of the IP source is required this must be
by IPsec, TLS, etc. operating at a higher layer. provided by IPsec, TLS, etc. operating at a higher layer.
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 below). 3.2 below).
A Receiver in a MPEG-2 TS transmission network needs to identify A Receiver in a 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 an 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). sent as TS Packets identified by their PID value).
The PID associated with an Elementary Stream can therefore be
modified (e.g. in some systems by reception of an updated SI
table, or in other systems until the next announcement/discovery
data is received). An attacker that is able to modify the content
of the received multiplex (e.g. replay data and/or control
information) could inject data locally into the received stream
with an arbitrary PID value.
One method to provide security is to secure the entire Stream at
the MPEG-2 TS level. This stream of TS Packets carried in a
multiplex is usually received by many Receivers. The approach is
well-suited to TV-transmission, data-push, etc, where the PID
carries one or a set of flows (e.g. video/audio Packetized
Elementary Stream (PES) Packets) with similar security
requirements.
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 is therefore required,
at least permitting control of data confidentiality/authorisation
at the level of a single MAC/NPA address. However there is only
one valid source of data for each MPEG-2 Elementary Stream, bound
to a PID value. This observation could simplify the requirement
for authentication of the source of a ULE Stream.
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 considered the major threats. An example of such a threat is
an intruder monitoring the MPEG-2 transmission broadcast and then an intruder monitoring the MPEG-2 transmission broadcast and then
extracting traffic information concerning the communication extracting traffic information concerning the communication
between IP hosts using a link. Another example is of an intruder between IP hosts using a link. Another example is of an intruder
trying to gain information about the communication parties by trying to gain information about the communication parties by
monitoring their ULE Receiver NPA addresses; an intruder can gain monitoring their ULE Receiver NPA addresses; an intruder can gain
information by determining the layer 2 identity of the information by determining the layer 2 identity of the
communicating parties and the volume of their traffic. This is a 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.
As explained in section 3.1, the PID associated with an
Elementary Stream can be modified (e.g. in some systems by
reception of an updated SI table, or in other systems until the
next announcement/discovery data is received). An attacker that
is able to modify the content of the received multiplex (e.g.
replay data and/or control information) could inject data locally
into the received stream with an arbitrary PID value.
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.
skipping to change at page 9, line 41 skipping to change at page 9, line 49
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 attacks: When an entity fails to perform its
proper function or acts in a way that prevents other entities proper function or acts in a way that prevents 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 the Internet community [BELLOVIN]. Masquerading and for the Internet community [BELLOVIN]. The defense against
modification of IP packets are comparatively easy in an Internet majority of these active attacks is data integrity using
environment whereas such attacks are in fact much harder for cryptographic techniques and sequence numbers. Also intrusion
broadcast links. This could for instance motivate the use of detection systems coupled with perimeter security policy are
sequence numbers in IPsec, but not the mandatory use of them on needed to monitor most denial of service attacks.
synchronous links and this is further reflected in the security
requirements for Case 2 and 3 in section 4 below. Masquerading and modification of IP packets are comparatively
easy in an Internet environment whereas such attacks are in fact
much harder for broadcast links. This could for instance motivate
the use of sequence numbers in IPsec, but not the mandatory use
of them on synchronous links and this is further reflected in the
security requirements for Case 2 and 3 in section 4 below.
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 is therefore required,
at least permitting control of data confidentiality/authorisation
at the level of a single MAC/NPA address. However there is only
one valid source of data for each MPEG-2 Elementary Stream, bound
to a PID value. This observation could simplify the requirement
for authentication of the source of a ULE Stream.
3.3. Threat Scenarios 3.3. Threat Scenarios
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 threat cases can be
abstracted into three cases: abstracted 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 data and the identity of ULE must be taken to protect the ULE data flow and the identity of
Receivers. ULE Receivers.
o Case 2: Local hijacking of the MPEG-TS multiplex (active o Case 2: Locally conduct active attacks on the MPEG-TS
threat). 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 group of Receivers (e.g. in a single company site). The MPEG
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 source
authentication and preventing replay of old messages. authentication and preventing replay of old messages.
o Case 3: Global hijacking of the MPEG-TS multiplex (active o Case 3: Globally conduct active attacks on the MPEG-TS
threat). Here we assume an intruder is very sophisticated and multiplex. Here we assume an intruder is very sophisticated
able to hijack the whole MPEG transmission multiplex. The and able to over-ride the whole MPEG transmission multiplex.
requirements here are similar to scenario 2. The MPEG The requirements here are similar to scenario 2. The MPEG
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 in the o Insider attacks i.e. active attacks from adversaries in the
known of secret material. known of 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 virtual
private network. 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 transmission systems. Case 2 is likely to a lesser degree MPEG 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 actives 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 transmission operator. It difficult to pass unnoticed by the MPEG transmission operator. It
will require restoration of the original transmission. The 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 (multiplexors, etc) and/or connecting physical media components (multiplexors, 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:
o Data confidentiality is the major requirement to mitigate o Data flow confidentiality is the major requirement to mitigate
passive threats in MPEG-2 broadcast networks. passive threats in MPEG-2 broadcast networks.
o Protection of Layer 2 NPA address. In broadcast networks this o Protection of Layer 2 NPA address. In broadcast networks this
protection can be used to prevent an intruder tracking the protection can be used to prevent an intruder tracking the
identity of ULE Receivers and the volume of their traffic. identity of ULE Receivers and the volume of their traffic.
o Integrity protection and authentication of the ULE source is o Integrity protection and authentication of the ULE source is
required against active attacks described in section 3.2. required against active attacks described in section 3.2.
o Protection against replay attacks. This is required for the o Protection against replay attacks. This is required for the
active attacks described in section 3.2. active attacks described in section 3.2.
o Layer L2 ULE Source and Receiver authentication: This is o Layer L2 ULE Source and Receiver authentication: This is
normally performed during the initial key exchange and normally 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 session with the ULE Encapsulator (ULE source). secure session with the ULE Encapsulator (ULE source). This is
normally receiver to hub authentication and it could be either
one 0-drectional or bidirectional authentication based on the
underlying key management protocol.
Other general requirements are: Other general requirements are:
o Decoupling of ULE key management functions from ULE security o Decoupling of ULE key management functions from ULE security
services such as encryption and source authentication. This services such as encryption and source authentication. This
allows the independent development of both systems. allows the independent development of both systems.
o Support for automated as well as manual insertion of keys and o Support for automated as well as manual insertion of keys and
policy into the relevant databases. policy into the relevant databases.
o Algorithm agility is needed. Changes in crypto algorithms, o Algorithm agility is needed. Changes in crypto algorithms,
hashes as they become obsolete should be updated without hashes as they become obsolete should be updated without
affecting the overall security of the system. affecting the overall security of the system.
o Traceability: To monitor transmission network using log files o Traceability: To monitor transmission network using log files
to record the activities in the network and detect any to record the activities in the network and detect any
intrusion. intrusion.
o Authentication of control and management messages in MPEG-2 o Protection against loss of service (availability) through
transmission networks such as the SI tables (see Figure 1). malicious reconfiguration of system components (see Figure 1).
o Secure Policy management o Secure Policy management
o Compatibility with other networking functions such as NAT o Compatibility with other networking functions such as NAT
Network Address Translation (NAT) [RFC3715] or TCP Network Address Translation (NAT) [RFC3715] or TCP
acceleration can be used in a wireless broadcast networks. acceleration can be used in a wireless broadcast networks.
o Compatibility and operational with ULE extension headers i.e. o Compatibility and operational with ULE extension headers i.e.
allow encryption of a compressed SNDU payload. allow encryption of a compressed SNDU payload.
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:
skipping to change at page 12, line 14 skipping to change at page 12, line 42
o Compatibility with other networking functions such as NAT o Compatibility with other networking functions such as NAT
Network Address Translation (NAT) [RFC3715] or TCP Network Address Translation (NAT) [RFC3715] or TCP
acceleration can be used in a wireless broadcast networks. acceleration can be used in a wireless broadcast networks.
o Compatibility and operational with ULE extension headers i.e. o Compatibility and operational with ULE extension headers i.e.
allow encryption of a compressed SNDU payload. allow encryption of a compressed SNDU payload.
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 MUST be provided to prevent o Case 1: Data flow confidentiality MUST be provided to prevent
monitoring of the ULE data (such as user information and IP monitoring of the ULE data (such as user information and IP
addresses). Protection of NPA addresses MUST be provided to addresses). Protection of NPA addresses MAY be provided to
prevent tracking ULE Receivers and their communications. prevent tracking ULE Receivers and their communications.
o Case 2: In addition to case 1 requirements, new measures need o Case 2: In addition to case 1 requirements, new measures need
to be implemented such as authentication schemes using Message to be implemented such as authentication schemes using Message
Authentication Codes, digital signatures or TESLA [RFC4082] Authentication Codes, digital signatures or TESLA [RFC4082]
and using sequence numbers to prevent replay attacks in terms and using sequence numbers to prevent replay attacks in terms
of insider attacks. In terms of outsider attacks group of insider attacks. In terms of outsider attacks group
authentication using Message Authentication Codes should authentication using Message Authentication Codes should
provide the same level of security. This will significantly provide the same level of security. This will significantly
reduce the ability of intruders to inject their own data into reduce the ability of intruders to inject their own data into
the MPEG-TS stream. However, scenario 2 threats apply only in the MPEG-TS stream. However, scenario 2 threats apply only in
specific service cases and therefore source authentication and specific service cases and therefore source authentication and
protection against replay attacks are OPTIONAL. Such measures protection against replay attacks are OPTIONAL. Such measures
incur extra link transmission and processing overheads. incur transmission of additional overhead and additional
processing overheads. Moreover intrusion detection may also be
needed by the MPEG-2 network operator.
o Case 3: The requirements here are similar to Case 2. In o Case 3: As stated in section 3.3. The requirements here are
addition, intrusion detection is also desirable by the MPEG-2 similar to Case 2 but since the MPEG transmission network
network operator. operator can usually identify such attacks the constraints on
intrusion detections are less than in case 2.
4.1. Compatibility with Generic Stream Encapsulation
The draft-ietf-ipdvb-ule-ext-01.txt document [ID-EF] describes
two new Header Extensions that may be used with Unidirectional
Link Encapsulation, ULE, [RFC4326] and the Generic Stream
Encapsulation (GSE) that has been designed for the Generic Mode
(also known as the Generic Stream (GS), offered by second-
generation DVB physical layers, and specifically for DVB-S2 [ID-
EF].
The security threats and requirement presented in this document
are applicable to ULE and GSE encapsulations. It might be
desirable to authenticate some/all of the headers; such decision
can be part of the security policy for the MPEG2 transmission
network.
5. IPsec and MPEG-2 Transmission Networks 5. IPsec and MPEG-2 Transmission Networks
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 links. The major
skipping to change at page 13, line 41 skipping to change at page 14, line 41
ULE link security (between a ULE Encapsulation Gateway to ULE link security (between a ULE Encapsulation Gateway to
Receivers) is therefore considered an additional security Receivers) is therefore considered an additional security
mechanism to IPsec, TLS, and application layer security, not a mechanism to IPsec, TLS, and application layer security, not a
replacement. It allows a network operator to provide similar replacement. It allows a network operator to provide similar
functions to that of IPsec [RFC4301], but in addition provides functions to that of IPsec [RFC4301], but in addition provides
MPEG-2 transmission link confidentiality and protection of ULE MPEG-2 transmission link confidentiality and protection of ULE
Receiver identity (NPA). Receiver identity (NPA).
A modular design to ULE Security may allow it to use and benefit A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as the Multicast from IETF key management protocols, such as GSAKMP [RFC4535] and
Security group (MSEC) GSAKMP [RFC4535] and GDOI [RFC3547] GDOI [RFC3547] protocols defined by the IETF Multicast Security
protocols. This does not preclude the use of other key management (MSEC) working group. This does not preclude the use of other key
methods in scenarios where this is more appropriate. management methods in scenarios where this is more appropriate.
6.1. Link security below the Encapsulation layer 6.1. Link security below the Encapsulation layer
Link layer security can be provided at the MPEG-TS level (below Link layer security can be provided at the MPEG-TS layer (below
ULE. MPEG-TS encryption encrypts all TS Packets sent with a ULE. MPEG-TS encryption encrypts all TS Packets sent with a
specific PID value. However, MPEG-TS may typically multiplex specific PID value. However, an MPEG-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.
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 or L3 headers, specifically all addresses, type fields, any L2 or L3 headers, specifically all addresses, type fields,
and length fields are encrypted prior to transmission. and length fields are encrypted prior to transmission.
skipping to change at page 14, line 36 skipping to change at page 15, line 36
o Encryption of the MPE NPA address is not permitted in such o Encryption of the MPE NPA address is not permitted in such
systems. systems.
o IETF-based key management are not used in existing systems. o IETF-based key management are not used in existing systems.
Existing access control mechanisms have limited flexibility in Existing access control mechanisms have limited flexibility in
terms of controlling the use of key and rekeying. Therefore if terms of controlling the use of key and rekeying. Therefore if
the key is compromised, then this will impact several ULE the key is compromised, then this will impact several ULE
Receivers. Receivers.
In practice there are few L2 security systems for MPEG Currently there are few deployed L2 security systems for MPEG
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.
6.2. Link security as a part of the Encapsulation layer 6.2. 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 link from eavesdropping and ULE Receiver
identity are major requirements. identity are major requirements.
There are several major advantages in using ULE link level 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
MPEG-2 transmission network. MPEG-2 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], which require the ability to inspect and modify the [RFC3135], which require the ability to inspect and modify the
packets sent over the ULE link. packets sent 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 [RFC4346] at L4). IPsec and TLS provide strong authentication of
the end-points in the communication. This authentication is the end-points in the communication. This authentication is
desirable in many scenarios to ensure that the correct desirable in many scenarios to ensure that the correct
information is being exchanged between the trusted entities, information is being exchanged between the trusted entities,
whereas Layer 2 methods cannot provide this guarantee. whereas Layer 2 methods cannot provide this guarantee.
L3 end-to-end security would partially deny the advantage listed
just above (use of PEP, compression etc), since those techniques
could only be applied to TCP packets bearing a TCP-encapsulated
IPsec packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression.
IPsec /TLS also provide a proven security architecture defining IPsec /TLS also provide a proven security architecture defining
key exchange mechanisms and the ability to use a range of key exchange mechanisms and the ability to use a range of
cryptographic algorithms. ULE security can make use of these cryptographic algorithms. ULE security can make use of these
established mechanisms and algorithms but the advantages are established mechanisms and algorithms but the advantages are
distinct from those when using IPsec or TLS. distinct from those when using IPsec or TLS.
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 also defines the requirements for ULE security
and states the motivation for link security as a part of the and states the motivation for link security as a part of the
Encapsulation layer. Encapsulation layer.
This includes a need to provide L2 encryption and ULE Receiver ULE security includes a need to provide link-layer encryption and
identity protection. There is an optional requirement for L2 ULE Receiver identity protection. There is an optional
authentication and integrity assurance as well as protection requirement for link-layer authentication and integrity assurance
against insertion of old (duplicated) data into the ULE stream as well as protection against insertion of old (duplicated) data
(i.e. replay protection). This is optional because of the into the ULE stream (i.e. replay protection). This is optional
associated overheads for the extra features and they are only because of the associated overheads for the extra features and
required for specific service cases they are only required for specific service cases.
Annexe 1 describes a set of building blocks that may be used to
realise a framework that provides these security functions.
8. Security Considerations 8. Security Considerations
Link-level (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). A provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). A
common objective is to provide the same level of privacy as wired common objective is to provide the same level of privacy as wired
links. An ISP or User may also wish to provide end-to-end links. An ISP or User may also wish to provide end-to-end
security services to the end-users (based on well known security services to the end-users (based on well known
mechanisms such as IPsec or TLS). mechanisms such as 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 optional link encryption and link-level requirements to provide optional link encryption and 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
[RFC4326] that are not addressed in this document (out of scope)
such as:
o The security issue with un-initialised stuffing bytes. In
ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
o Integrity issues related to the removal of the LAN FCS in a
bridged networking environment. The removal for bridged
frames exposes the traffic to potentially undetected
corruption while being processed 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 9. IANA Considerations
This document does not define any protocol and does not require This document does not define any protocol and does not require
any IANA assignments. any IANA assignments but a subsequent document that defines a
layer 2 security extension to ULE will require IANA involvement.
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 Stephane Coombes (ESA) and Yim Fun Hu contributions from Stephane Coombes (ESA) and Yim Fun Hu
(University of Bradford). (University of Bradford).
11. References 11. References
skipping to change at page 16, line 43 skipping to change at page 18, line 25
[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.
11.2. Informative References 11.2. Informative References
[ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution [ID-AR] 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. Work in Progress <draft-ietf-ipdvb-ar-05.txt.
[IEEE-802.2]"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-2] 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] Montpetit, M.-J., Fairhurst, G., Clausen, H.,
Collini-Nocker, B., and H. Linder, "A Framework for Collini-Nocker, B., and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks", Transmission of IP Datagrams over MPEG-2 Networks",
skipping to change at page 18, line 22 skipping to change at page 19, line 50
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, IETF RFC 3819, July 2004. Designers", BCP 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.
[ID-EF] G. Fairhurst, "Extension Formats for the ULE [ID-EF] G. Fairhurst, "Extension Formats for the ULE
Encapsulation to support the Generic Stream Encapsulation to support the Generic Stream
Encapsulation (GSE)", Work in Progress < draft- Encapsulation (GSE)", Work in Progress < draft-ietf-
fairhurst-ipdvb-ule-ext-xx.txt>. ipdvb-ule-ext-01.txt>.
Author's Addresses 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 Sunil Iyengar
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: S.Iyengar@surrey.ac.uk Email: S.Iyengar@surrey.ac.uk
Laurence Duquerroy Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse Thales Alenia Space, Toulouse
France France
E-Mail: Laurence.Duquerroy@space.alcatel.fr E-Mail: Laurence.Duquerroy@alcatelaleniaspace.com
Prashant Pillai Prashant Pillai
Mobile and Satellite Communications Research Centre Mobile and Satellite Communications Research Centre
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
12. IPR Notices 12. IPR Notices
skipping to change at page 20, line 17 skipping to change at page 21, line 44
13. Copyright Statement 13. Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
>>> NOTE to RFC Editor: Please remove this appendix prior to >>> NOTE to RFC Editor: Please remove this appendix prior to
publication] publication]
Document History Document History
Individual Draft-ID-00
o This draft is intended as a study item for proposed future
work by the IETF in this area.
o Major security concerns from Steve Bellovin who also agreed
that Layer 2 Address hiding is a necessary security service.
o Motivation for security over ULE was not clear (Joerg Ott)
o Not sure where this was leading for Non -IP traffic and key
management (Margaret Wasserman).
o It was recommended that a separate requirements draft was
first needed before suggesting any solutions (Bellovin)
Issues to be resolved in next revision (01):
o Title change (inserted "security requirements " rather than
"security extension")
o Separate security requirements draft
o Threat Analysis
Individual Draft -ID-01
o Load of discussion on the mailing lists regarding signalling
traffic security and the threats involved (Gorry, Montpetit
and Art)
o Benefits of IPSec over ULE as well as the fact the document
was not easy to read (Gerrard Gessler and Wolfgang Fritche)
o What were the benefits of NPA protection?
o Threats in broadcast networks was raised by Gorry
Issues to be resolved in next revision (02):
o Add section 3 on threats
o Address Signalling threats
o Make the document easy to read
Individual Draft -ID-02
o Merged draft with the one proposed by Prashant and included
him as an author.
o Define the threat scenarios and the security requirement for
these scenarios.
o English fixed
Issues to be resolved in next revision (03):
o Include subsection 3.1 Threat Scenarios and the requirements
for these scenarios
o English Fixed
Individual Draft -ID-03
o Major comments and suggestions (Michael Noistering) regarding
authentication and integrity assurance. He also suggested that
the threat scenarios (section 3.2) should be expanded.
o Elaborate the impact of threats for IP as opposed to Layer 2
(Gorry Fairhurst)
Issues to be resolved in next revision (04):
o Expanded the threat scenarios.
o Algorithm Agility added as a requirement (gorry)
o Nits have been taken care of and addressed.
o English Fixed
Individual Draft -ID-04
o Minor comment from Michael regarding replay protection
o Minor comments form Gorry.
Issues to be resolved in next revision (05):
o Nits have been taken care of and addressed.
o English Fixed
Working Group Draft 00 Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption. o Fixed editorial mistakes and ID style for WG adoption.
Working Group Draft 01 Working Group Draft 01
o Fixed editorial mistakes and added an appendix which shows the
preliminary framework for securing the ULE network.
o Fixed editorial mistakes and added some changes as pointed out Working Group Draft 02
by Knut (ESA) and added an appendix which shows the framework
for securing the ULE network. o Fixed editorial mistakes and added some important changes as
pointed out by Knut Eckstein (ESA), Gorry Fairhurst and
UNISAL.
Appendix A: ULE Security Framework Appendix A: ULE Security Framework
This section aims to define a preliminary security framework for This section aims to define a preliminary security framework for
widespread deployment of secure ULE networks. widespread deployment of secure ULE networks.
Building Blocks Building Blocks
This ULE Security framework defines the following building blocks This ULE Security framework defines the following building blocks
as shown in the figure 2 below: as shown in figure 2 below:
1. The Key Management Block 1. The Key Management Block
2. The ULE Extension Header Block 2. The ULE Extension Header Block
3. The ULE Databases Block 3. The ULE Databases Block
+------+----------+ +---------------- +------+----------+ +----------------
| Key Management |/------------\| Key Management | | Key Management |/------------\| Key Management |
| Block |\------------/| Block | | Block |\------------/| Block |
skipping to change at page 23, line 28 skipping to change at page 23, line 15
| | | |
+------+-+--------+ +------+-+--------+
| ULE Security | | ULE Security |
| Extension Header| | Extension Header|
| Block | | Block |
+-----------------+ +-----------------+
Figure 2: Secure ULE framework Building Blocks Figure 2: Secure ULE framework Building Blocks
1. Key Management Block 1. Key Management Block
In order to provide security at the ULE level using extension A key management framework is required to provide security at the
headers, a key management framework is required. This key ULE level using extension headers. In order to provide security
management framework is responsible for user authentication, at the ULE level using extension headers, a key management
access control, and Security Association negotiation (which framework is required. This key management framework is
include the negotiations of the security algorithms to be used responsible for user authentication, access control, and Security
and the generation of the different session keys as well as Association negotiation (which include the negotiations of the
policy material). This Key management framework can be either security algorithms to be used and the generation of the
automated or manual. Hence Key management client entity will be different session keys as well as policy material). This Key
present in all ULE receivers as well as ULE sources. In some management framework can be either automated or manual. Hence
cases the ULE source could also be the Key Server Entity. Key this key management client entity will be present in all ULE
management protocols like GSAKMP may be used or manual insertion receivers as well as at the ULE sources (encapsulation gateways).
of keying material can also be deployed. In some cases the ULE source could also be the Key Server Entity.
Deployment may use either automated key management protocols
(e.g. GSAKMP [RFC4535]) or manual insertion of keying material.
2.ULE Extension header Block 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 draft. described in detail in Section 4 of this draft.
This block will use the keying material and policy information from This block will use the keying material and policy information from
the ULE security database block on the ULE payload to generate the the ULE security database block on the ULE payload to generate the
secure ULE extension Header or to decipher the secure ULE extension secure ULE Extension Header or to decipher the secure ULE extension
header to get the ULE payload. An example overview of the ULE header to get the ULE payload. An example overview of the ULE
Security extension header format along with the ULE header and Security extension header format along with the ULE header and
payload is shown in figure 3 below. There could be other extension payload is shown in figure 3 below. There could be other extension
headers placed before or after the ULE Security Header extension headers (either mandatory or optional) but these will always be
placed after the security extension header. In this way all
extension headers (if any) follow the security extension header.
When applying the security services for example confidentiality,
input to the cipher algorithm will the 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 Sec Header extension Placement Figure 3: ULE Sec Header Extension Placement
3. ULE Databases Block 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 Secure 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 Secure Policy Database contains the policies as
defined by the system manager. Those policies describe the defined by the system manager. Those 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 will be based on IPSec
databases as defined in RFC4301 [RFC4301]. databases as defined in RFC4301 [RFC4301].
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
separate document. This document only highlights the need for
such interfaces tot he ULE data plane and the Key Management
control plane.
Interface definition Interface definition
Two new interfaces have to be defined between the three blocks as Two new interfaces have to be defined between the three blocks as
shown in figure 2 above. These interfaces are: shown in figure 2 above. These interfaces are:
o Key management <-> ULE Security databases o Key management <-> ULE Security databases
o ULE Security databases <-> ULE interfaces o ULE Security databases <-> ULE interfaces
While the first interface is used by the Key Management Block to While the first interface is used by the Key Management Block to
skipping to change at page 25, line 11 skipping to change at page 25, line 11
Payloads. Payloads.
1. Key management <-> ULE Security databases 1. Key management <-> ULE Security databases
This interface is between the Key Management client block (GM This interface is between the Key Management client block (GM
client) and the ULE Security Database block. The Key management client) and the ULE Security Database block. The Key management
client will communicate with the GCKS and then get the relevant client will communicate with the GCKS and then get the relevant
security information (keys, cipher mode, security service, security information (keys, cipher mode, security service,
ULE_Security_ID and other relevant keying material as well as ULE_Security_ID and other relevant keying material as well as
policy) and insert this data into the ULE Security database policy) and insert this data into the ULE Security database
block. The ULE Security database block holds the records of all block. The ULE Security database block holds the records of all
security associations currently used as well as information for security associations currently used by an encapsulator (all
security policy control. The Key management could be either channels) as well as information for security policy control. The
automated (GSAKMP) or manually inserted using this interface. The Key management could be either automated (e.g. GSAKMP [RFC4535]
or GDOI [RFC3547]) or manually inserted using this interface. The
following three interface 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);
2. ULE Security databases <-> ULE interfaces The definitions of the variables are as follows:
. Database - This is a pointer to the ULE Security databases
. record - This is the rows of security attributes to be
entered or modified in the above databases
. Unique_ID - This is the primary key to lookup records (rows
of security attributes) in the above databases
2. ULE Security Databases <-> ULE Interfaces
This interface is between the ULE Security Database and the ULE This interface is between the ULE Security Database and the ULE
Engine. For Outbound Traffic, firstly the ULE Engine using the Engine. To send traffic, firstly the ULE Engine using the
Destination Address and the ULE_Security_ID searches the ULE Destination Address and the ULE_Security_ID searches the ULE
Security Database for the relevant security record. It then uses Security Database for the relevant security record. It then uses
the record data to create the ULE security extension header the data in the record to create the ULE security extension
[ref]. For inbound traffic, the ULE engine on receiving the ULE header [this will be designed in a later draft]. For received
packet will first get the record from the Security Database using traffic, the ULE engine on receiving the ULE packet will first
the Destination Address and the ULE_Security_ID. It then uses get the record from the Security Database using the Destination
this information to decrypt the ULE extension header. Address and the ULE_Security_ID. It then uses this information to
decrypt the ULE extension header.
In both cases only one interface is needed: In both cases only one interface is needed since the only
difference between the sender and receiver is the flow of
traffic:
. Get_record_database (char * Database, char * record, char * . Get_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
 End of changes. 68 change blocks. 
254 lines changed or deleted 267 lines changed or added

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