draft-ietf-ipdvb-sec-req-02.txt   draft-ietf-ipdvb-sec-req-03.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-02.txt University of Surrey, UK draft-ietf-ipdvb-sec-req-03.txt University of Surrey, UK
L. Duquerroy P. Pillai
Alcatel Alenia Space, France Expires: December 29, 2007 University of Bradford, UK
Expires: November 10, 2007 P. Pillai
University of Bradford, UK
Category: WG Draft intended for INFORMATIONAL RFC May 10, 2007 Category: WG Draft intended for INFORMATIONAL RFC June 29, 2007
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-02.txt draft-ietf-ipdvb-sec-req-03.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 42 skipping to change at page 1, line 40
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 November 10, 2007. This Internet-Draft will expire on December 29, 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 supports a range of
range of transmission methods for a range of services. This transmission methods for a range of services. This document
document provides a threat analysis and derives the security provides a threat analysis and derives the security requirements
requirements when using the Transport Stream, TS, to support an when using the Transport Stream, TS, to support an Internet
Internet network-layer using Unidirectional Lightweight network-layer using Unidirectional Lightweight Encapsulation
Encapsulation (ULE) [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.
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 3.2. Threats.......................................9
Service for IP transport over MPEG-2 [RFC4259]................6 3.3. Threat Scenarios..............................10
3.2. Threats..............................................8 4. Security Requirements for IP over MPEG-2 TS...........11
3.3. Threat Scenarios.....................................10 5. Motivation for ULE link-layer security................13
4. Security Requirements for IP over MPEG-2 TS...............11 5.1. Security at the IP layer (using IPSEC)...........13
4.1. Compatibility with Generic Stream Encapsulation.......13 5.2. Link security below the Encapsulation layer.......14
5. IPsec and MPEG-2 Transmission Networks....................13 5.3. Link security as a part of the encapsulation layer.15
6. Motivation for ULE link-layer security....................14 6. Design recommendations for ULE Security Header Extension16
6.1. Link security below the Encapsulation layer..........14 7. Compatibility with Generic Stream Encapsulation........17
6.2. Link security as a part of the encapsulation layer....15 8. Summary..........................................17
7. Summary..................................................16 9. Security Considerations............................17
8. Security Considerations...................................17 10. IANA Considerations...............................18
9. IANA Considerations......................................17 11. Acknowledgments..................................18
10. Acknowledgments.........................................17 12. References.......................................18
11. References..............................................18 12.1. Normative References..........................18
11.1. Normative References................................18 12.2. Informative References........................19
11.2. Informative References..............................18 13. Author's Addresses................................20
Author's Addresses..........................................20 14. IPR Notices......................................21
12. IPR Notices.............................................20 14.1. Intellectual Property Statement................21
12.1. Intellectual Property Statement.....................20 14.2. Intellectual Property.........................21
12.2. Intellectual Property...............................21 15. Copyright Statement...............................22
13. Copyright Statement......................................21 Appendix A: ULE Security Framework......................22
Document History............................................21 Document History.....................................26
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
skipping to change at page 4, line 11 skipping to change at page 4, line 11
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.
A security framework for deployment of secure ULE networks
describing the different building blocks and the interface
definitions is presented in Appendix A.
2. Requirements notation 2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
Other terms used in this document are defined below: Other terms used in this document are defined below:
ATSC: Advanced Television Systems Committee. A framework and a ATSC: Advanced Television Systems Committee. A framework and a
skipping to change at page 6, line 30 skipping to change at page 6, line 34
| ^ | ^
+------------>+---------------+ | +------------>+---------------+ |
+ IP | | + IP | |
+-------------+ Encapsulator | | +-------------+ Encapsulator | |
SI-Data | +------+--------+ | SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel | +-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | | | MPEG-2 | | |
| SI Tables | | | | SI Tables | | |
+-------+-------+ ->+------+--------+ | +-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . . | -->| MPEG-2 | . . .
+------------>+ Multiplexor | | +------------>+ Multiplexer | |
MPEG-2 TS +------+--------+ | MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux | Logical Channel |MPEG-2 TS Mux |
| | | |
Other ->+------+--------+ | Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | | MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | | TS --->+ Multiplexer | |
---->+------+--------+ | ---->+------+--------+ |
|MPEG-2 TS Mux | |MPEG-2 TS Mux |
| | | |
+------+--------+ +------+-----+ +------+--------+ +------+-----+
|Physical Layer | | MPEG-2 | |Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver | |Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+ +---------------+ MPEG-2 +------------+
TS Mux TS Mux
Figure 1: An example configuration for a unidirectional Figure 1: An example configuration for a unidirectional service
Service for IP transport over MPEG-2 [RFC4259]. 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 (the 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 multiplexer)
o Receivers (the end points for ULE security) 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 an MPEG-2 network a set of signalling messages [ID-AR] may
need to be broadcast (e.g. by an Encapsulation Gateway or other
device) to form the Layer 2 (L2) control plane. Examples of
signalling messages include the Program Association Table (PAT),
Program Map Table (PMT) and Network Information Table (NIT). In
existing MPEG-2 transmission networks, these messages are
broadcast in the clear (no encryption or integrity checks). The
integrity as well as authenticity of these messages is important
for correct working of the ULE working of the ULE network, i.e.
supporting its security objectives in the area of availability,
in addition to confidentiality and integrity. One method recently
proposed [ID-EF] encapsulates these messages using ULE. In such
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
Encapsulation Gateway (ULE source) and the Receiver. Often times,
the user of satellite communication link have to secure their
communications beyond that satellite link, because terrestrial
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 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. do not correspond to an IP address associated with the device.
When authentication of the IP source is required this must be
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).
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 a 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). 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.)
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
device) to form the Layer 2 (L2) control plane. Examples of
signalling messages include the Program Association Table (PAT),
Program Map Table (PMT) and Network Information Table (NIT). In
existing MPEG-2 transmission networks, these messages are
broadcast in the clear (no encryption or integrity checks). The
integrity as well as authenticity of these messages is important
for correct working of the ULE network, i.e. supporting its
security objectives in the area of availability, in addition to
confidentiality and integrity. One method recently proposed [ID-
EF] encapsulates these messages using ULE. In such 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
Encapsulation Gateway (ULE source) and the Receiver. In many
deployment scenarios the user of a ULE Stream has to secure
communications beyond the link since other network links are
utilised in addition to the ULE link. Therefore, if
authentication of the end-point i.e. the IP Sources is required,
or users are concerned about loss of confidentiality, integrity
or authenticity of their communication data, they will have to
employ end-to-end network security mechanisms like IPSec or
Transport Layer Security (TLS). Governmental users may be forced
by regulations to employ specific, approved implementations of
those mechanisms. Hence for such cases the confidentiality and
integrity of the user data will already be taken care of by the
end-to-end security mechanism and the ULE security measures would
focus on either providing traffic flow confidentiality for user
data that has already been encrypted or for users who choose not
to implement end-to-end security mechanisms.
In contrast to the above, if a ULE Stream is used to directly
join networks which are considered physically secure, for example
branch offices to a central office, ULE link Security 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
manufacturer of ULE Link Security equipment obtains governmental
approval for their implementation.
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
skipping to change at page 9, line 20 skipping to change at page 9, line 25
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 49 skipping to change at page 9, line 46
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]. The defense against for the Internet community [BELLOVIN]. Masquerading and
majority of these active attacks is data integrity using modification of IP packets are comparatively easy in an Internet
cryptographic techniques and sequence numbers. Also intrusion environment whereas such attacks are in fact much harder for
detection systems coupled with perimeter security policy are MPEG-2 broadcast links. This could for instance motivate the
needed to monitor most denial of service attacks. mandatory use of sequence numbers in IPsec, but not for
synchronous links. This is further reflected in the security
Masquerading and modification of IP packets are comparatively requirements for Case 2 and 3 in section 4 below.
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 As explained in section 3.1, the PID associated with an
destinations with a range of properties (multicast, unicast, Elementary Stream can be modified (e.g. in some systems by
etc), it is often not appropriate to provide IP confidentiality reception of an updated SI table, or in other systems until the
services for the entire ULE Stream. For many expected next announcement/discovery data is received). An attacker that
applications of ULE, a finer-grain control is therefore required, is able to modify the content of the received multiplex (e.g.
at least permitting control of data confidentiality/authorisation replay data and/or control information) could inject data locally
at the level of a single MAC/NPA address. However there is only into the received stream with an arbitrary PID value.
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 flow and the identity of must be taken to protect the ULE data flow and the identity of
ULE Receivers. 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 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 source
authentication and preventing replay of old messages. authentication 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 transmission multiplex. and able to over-ride the whole MPEG-2 transmission multiplex.
The requirements here are similar to scenario 2. The MPEG 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 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-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 transmission operator. It difficult to pass unnoticed by the MPEG-2 transmission operator.
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 (multiplexors, 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:
o Data flow 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.
skipping to change at page 12, line 7 skipping to change at page 11, line 42
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). This is secure session with the ULE Encapsulator (ULE source). This is
normally receiver to hub authentication and it could be either normally receiver to hub authentication and it could be either
one 0-drectional or bidirectional authentication based on the unidirectional or bidirectional authentication based on the
underlying key management protocol. 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.
skipping to change at page 12, line 39 skipping to change at page 12, line 28
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.
o 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.
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 flow 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 MAY 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] in
and using sequence numbers to prevent replay attacks in terms order to provide integrity protection and source
of insider attacks. In terms of outsider attacks group authentication, and using sequence numbers to protect against
replay 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 successfully inject their
the MPEG-TS stream. However, scenario 2 threats apply only in own data into the MPEG-TS stream. However, scenario 2 threats
specific service cases and therefore source authentication and apply only in specific service cases, and therefore
protection against replay attacks are OPTIONAL. Such measures authentication and protection against replay attacks are
incur transmission of additional overhead and additional OPTIONAL. Such measures incur additional transmission as well
processing overheads. Moreover intrusion detection may also be as processing overheads. Moreover, intrusion detection systems
needed by the MPEG-2 network operator. may also be needed by the MPEG-2 network operator. These
should best be coupled with perimeter security policy to
monitor most denial-of-service 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 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.
4.1. Compatibility with Generic Stream Encapsulation 5. Motivation for ULE link-layer security
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 Examination of the threat analysis and security requirements in
are applicable to ULE and GSE encapsulations. It might be sections 3 and 4 has shown that there is a need to provide
desirable to authenticate some/all of the headers; such decision security in MPEG-2 transmission networks employing ULE. This
can be part of the security policy for the MPEG2 transmission section compares the disadvantages when security functionalities
network. are present in different layers.
5. IPsec and MPEG-2 Transmission Networks 5.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 links. 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
skipping to change at page 14, line 25 skipping to change at page 14, line 18
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 [WEIS06].
6. Motivation for ULE link-layer security 5.2. Link security below the Encapsulation layer
Examination of the threat analysis and security requirements in
sections 3 and 4 has shown that there is a need to provide link-
layer (L2) security in MPEG-2 transmission networks employing
ULE.
ULE link security (between a ULE Encapsulation Gateway to
Receivers) is therefore considered an additional security
mechanism to IPsec, TLS, and application layer security, not a
replacement. It allows a network operator to provide similar
functions to that of IPsec [RFC4301], but in addition provides
MPEG-2 transmission link confidentiality and protection of ULE
Receiver identity (NPA).
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.
6.1. Link security below the Encapsulation layer
Link layer security can be provided at the MPEG-TS layer (below Link layer security can be provided at the MPEG-2 TS layer (below
ULE. MPEG-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-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.
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.
o This method does not preclude the use of IPsec, or any other o This method does not preclude the use of IPsec, TLS, or any
form of higher-layer security. other form of higher-layer security.
However it has the following disadvantages: However it has the following disadvantages:
o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with
a matching PID, possibly including those that are not required a matching PID, possibly including those that are not required
to be forwarded. Therefore it does not have the flexibility to to be forwarded. Therefore it does not have the flexibility to
separately secure individual IP flows. separately secure individual IP flows.
o ULE Receivers will have access to private traffic destined to o ULE Receivers will have access to private traffic destined to
other ULE Receivers, since they share a common PID and key. other ULE Receivers, since they share a common PID and key.
o Encryption of the MPE NPA address is not permitted in such
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.
Currently there are few deployed L2 security systems for MPEG 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.
6.2. Link security as a part of the encapsulation layer 5.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 link 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
skipping to change at page 16, line 32 skipping to change at page 15, line 48
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 L3 end-to-end security would partially deny the advantage listed
just above (use of PEP, compression etc), since those techniques just above (use of PEP, compression etc), since those techniques
could only be applied to TCP packets bearing a TCP-encapsulated could only be applied to TCP packets bearing a TCP-encapsulated
IPsec packet exchange, but not the TCP packets of the original IPsec packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression. applications, which in particular inhibits compression.
IPsec /TLS also provide a proven security architecture defining End-to-end security (IPsec, TLS, etc.) may be used independently
to provide strong authentication of the end-points in the
communication. This authentication is desirable in many scenarios
to ensure that the correct information is being exchanged between
the trusted parties, whereas Layer 2 methods cannot provide this
guarantee.
6. Design recommendations for ULE Security Header Extension
Table 1 below shows the threats that are applicable to ULE
networks and the relevant security mechanism to mitigate those
threats. This would help in the design of the ULE Security
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.
Mitigation of Threat
-----------------------------------------------
|Payload |Counter|Source |Data |Intru |Iden |
|Encry |/Nonce |Authent|Integ |sion |tity |
|ption | |ication|rity |Dete |Prote |
| | | | |ction |ction |
Attack | | | | | | |
---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------|
| Dos Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------|
| Modification | - | - | X | X | X | - |
| of Mesages | | | | | | |
---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats
in ULE Networks.
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 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.
distinct from those when using IPsec or TLS.
7. Summary 7. Compatibility with Generic Stream Encapsulation
The [ID-EF] document 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 MPEG-2 transmission
network.
8. 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.
ULE security includes a need to provide link-layer encryption and ULE security includes a need to provide link-layer encryption and
ULE Receiver identity protection. There is an optional ULE Receiver identity protection. There is an optional
requirement for link-layer authentication and integrity assurance requirement for link-layer authentication and integrity assurance
as well as protection against insertion of old (duplicated) data as well as protection against insertion of old (duplicated) data
into the ULE stream (i.e. replay protection). This is optional into the ULE stream (i.e. replay protection). This is optional
because of the associated overheads for the extra features and because of the associated overheads for the extra features and
they are only required for specific service cases. they are only required for specific service cases.
ULE link security (between a ULE Encapsulation Gateway to
Receivers) is considered as an additional security mechanism to
IPsec, TLS, and application layer end-to-end security, and not as
a replacement. It allows a network operator to provide similar
functions to that of IPsec, but in addition provides MPEG-2
transmission link confidentiality and protection of ULE Receiver
identity (NPA). End-to-end security mechanism may then be used
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 these security functions. realise a framework that provides ULE security functions.
8. Security Considerations 9. 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). 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. It is recommended that an ISP or user provide end-to-end
security services to the end-users (based on well known security services based on well known mechanisms such as IPsec or
mechanisms such as IPsec or TLS). TLS.
This document provides a threat analysis and derives the security This document provides a threat analysis and derives the security
requirements to provide optional link encryption and 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 (out of scope)
such as: such as:
o The security issue with un-initialised stuffing bytes. In o The security issue with un-initialised stuffing bytes. In
ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 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 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 exposes the traffic to potentially undetected frames exposes the traffic to potentially undetected
corruption while being processed by the Encapsulator and/or corruption while 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 10. 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 but a subsequent document that defines a any IANA assignments but a subsequent document that defines a
layer 2 security extension to ULE will require IANA involvement. layer 2 security extension to ULE will require IANA involvement.
10. Acknowledgments 11. 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 Laurence Duquerroy and Stephane Coombes (ESA),
(University of Bradford). Yim Fun Hu (University of Bradford) and Michael Noisternig from
University of Salzburg.
11. References 12. References
11.1. Normative References 12.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.
11.2. Informative References 12.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] "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.
skipping to change at page 19, line 51 skipping to change at page 20, line 43
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-ietf- Encapsulation (GSE)", Work in Progress < draft-ietf-
ipdvb-ule-ext-01.txt>. ipdvb-ule-ext-03.txt>.
Author's Addresses 13. 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
Research Department/Advanced Telecom Satellite Systems
Thales Alenia Space, Toulouse
France
E-Mail: Laurence.Duquerroy@alcatelaleniaspace.com
Prashant Pillai Prashant Pillai
Mobile and Satellite Communications Research Centre 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
12. IPR Notices 14. IPR Notices
Copyright (c) The IETF Trust (2007). Copyright (c) The IETF Trust (2007).
12.1. Intellectual Property Statement 14.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
retain all their rights. retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
12.2. Intellectual Property 14.2. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at page 21, line 35 skipping to change at page 22, line 23
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org. the IETF at ietf-ipr@ietf.org.
13. Copyright Statement 15. Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
Document History
Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption.
Working Group Draft 01
o Fixed editorial mistakes and added an appendix which shows the
preliminary framework for securing the ULE network.
Working Group Draft 02
o Fixed editorial mistakes and added some important changes as
pointed out by Knut Eckstein (ESA), Gorry Fairhurst and
UNISAL.
Appendix A: ULE Security Framework Appendix A: ULE Security Framework
This section aims to define a preliminary security framework for This section defines a security framework for the deployment of
widespread deployment of secure ULE networks. secure ULE networks.
Building Blocks A.1 Building Blocks
This ULE Security framework defines the following building blocks This ULE Security framework defines the following building blocks
as shown in figure 2 below: as shown in figure 2 below:
1. The Key Management Block o The Key Management Block
2. The ULE Extension Header Block o The ULE Security Extension Header Block
3. The ULE Databases Block o The ULE Databases Block
+------+----------+ +---------------- Within the Key Management block the communication between the
| Key Management |/------------\| Key Management | Group Member entity and the Group Server entity happens in the
| Block |\------------/| Block | control plane. The ULE Security header block applies security to
| Group Member | | Group Server | the ULE SNDU and this happens in the ULE data plane. The ULE
+------+----------+ +---------------- Security databases block acts as the interface between the Key
| | management block (control plane) and the ULE Security Header
| | block (ULE data plane) as shown in figure 2.
| |
| | ------
+------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | |
| Block |\---------/| Block | |
| Group Member | | Group Server | Control
+------+----------+ +----------------+ Plane
| | |
| | |
| | \ /
----------- Key management <-> ULE Security databases -----
| | | |
\ / \ /
+------+----------+ +------+----------+
| ULE | | ULE |
| SAD / SPD | | SAD / SPD |
| Interface Block | | Databases |
| Block |
+------+-+--------+ +------+-+--------+
/ \ / \
| | | |
| | ----------- ULE Security databases <-> ULE Security Header ----
| | | | / \
| | | | |
| | | | |
| | +------+-+--------+ ULE Data
+------+-+--------+ | ULE Security | Plane
| ULE Security | | Extension Header| |
| Extension Header| | Block | |
| Block | +-----------------+ \ /
+-----------------+ -----
Figure 2: Secure ULE framework Building Blocks
1. Key Management Block Figure 2: Secure ULE Framework Building Blocks
A.1.1 Key Management Block
A key management framework is required to provide security at the A key management framework is required to provide security at the
ULE level using extension headers. In order to provide security ULE level using extension headers. This key management framework
at the ULE level using extension headers, a key management is responsible for user authentication, access control, and
framework is required. This key management framework is Security Association negotiation (which include the negotiations
responsible for user authentication, access control, and Security of the security algorithms to be used and the generation of the
Association negotiation (which include the negotiations of the different session keys as well as policy material). The Key
security algorithms to be used and the generation of the
different session keys as well as policy material). This Key
management framework can be either automated or manual. Hence management framework can be either automated or manual. Hence
this key management client entity will be present in all ULE this key management client entity (shown as the Key Management
Group Member block in figure 2) will be present in all ULE
receivers as well as at the ULE sources (encapsulation gateways). receivers as well as at the ULE sources (encapsulation gateways).
In some cases the ULE source could also be the Key Server Entity. The ULE source could also be the Key Management Group Server
Deployment may use either automated key management protocols Entity (shown as the Key Management Group Server block in figure
(e.g. GSAKMP [RFC4535]) or manual insertion of keying material. 2. This happens when the ULE source also acts as the Key
Management Group Server. Deployment may use either automated key
management protocols (e.g. GSAKMP [RFC4535]) or manual insertion
of keying material.
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 draft. described in detail in Section 4 of this document.
This block will use the keying material and policy information from This block will use the keying material and policy information
the ULE security database block on the ULE payload to generate the from the ULE security database block on the ULE payload to
secure ULE Extension Header or to decipher the secure ULE extension generate the secure ULE Extension Header or to decipher the
header to get the ULE payload. An example overview of the ULE secure ULE extension header to get the ULE payload. An example
Security extension header format along with the ULE header and overview of the ULE Security extension header format along with
payload is shown in figure 3 below. There could be other extension the ULE header and payload is shown in figure 3 below. There
headers (either mandatory or optional) but these will always be could be other extension headers (either mandatory or optional)
placed after the security extension header. In this way all but these will always be placed after the security extension
extension headers (if any) follow the security extension header. header. In this way all extension headers (if any) follow the
When applying the security services for example confidentiality, security extension header. When applying the security services
input to the cipher algorithm will the cover the fields from the end for example confidentiality, input to the cipher algorithm will
of the security extension header to the end of the PDU. 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 Security Header Extension Placement
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 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. 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 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 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 tot he ULE data plane and the Key Management such interfaces between the ULE data plane and the Key Management
control plane. control plane.
Interface definition A.2 Interface definition
Two new interfaces have to be defined between the three blocks as Two new interfaces have to be defined between the blocks as shown
shown in figure 2 above. These interfaces are: in Figure 2 above. These interfaces are:
o Key management <-> ULE Security databases o Key Management block <-> ULE Security databases block
o ULE Security databases <-> ULE interfaces o ULE Security databases block <-> ULE Security Header block
While the first interface is used by the Key Management Block to While the first interface is used by the Key Management Block to
insert keys, security associations and policies into the ULE insert keys, security associations and policies into the ULE
Database Block, the second interface is used by the ULE Extension Database Block, the second interface is used by the ULE Security
Header Block to get the keys and policy material for the ULE Extension Header Block to get the keys and policy material for
Payloads. generation of the security extension header.
1. Key management <-> ULE Security databases A.2.1 Key Management <-> ULE Security databases
This interface is between the Key Management client block (GM
client) and the ULE Security Database block. The Key management This interface is between the Key Management group member block
client will communicate with the GCKS and then get the relevant (GM client) and the ULE Security Database block (shown in figure
security information (keys, cipher mode, security service, 2). The Key Management GM entity will communicate with the GCKS
ULE_Security_ID and other relevant keying material as well as and then get the relevant security information (keys, cipher
policy) and insert this data into the ULE Security database mode, security service, ULE_Security_ID and other relevant keying
block. The ULE Security database block holds the records of all material as well as policy) and insert this data into the ULE
security associations currently used by an encapsulator (all Security database block. The Key Management could be either
channels) as well as information for security policy control. The automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually
Key management could be either automated (e.g. GSAKMP [RFC4535] inserted using this interface. The following three interface
or GDOI [RFC3547]) or 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
2. ULE Security Databases <-> ULE Interfaces 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
Engine. To send traffic, firstly the ULE Engine using the Security Extension Header block as shown in figure 2. To send
Destination Address and the ULE_Security_ID searches the ULE traffic, firstly the ULE encapsulator using the ULE_Security_ID,
Destination Address and possibly the PID, searches the ULE
Security Database for the relevant security record. It then uses Security Database for the relevant security record. It then uses
the data in the record to create the ULE security extension the data in the record to create the ULE security extension
header [this will be designed in a later draft]. For received header. For received traffic, the ULE decapsulator on receiving
traffic, the ULE engine on receiving the ULE packet will first the ULE SNDU will first get the record from the Security Database
get the record from the Security Database using the Destination using the ULE_Security_ID, the Destination Address and possibly
Address and the ULE_Security_ID. It then uses this information to the PID. It then uses this information to decrypt the ULE
decrypt the ULE extension header. extension header.
In both cases only one interface is needed since the only For both cases (either send or receive traffic) only one
difference between the sender and receiver is the flow of interface is needed since the only difference between the sender
traffic: 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);
>>> NOTE to RFC Editor: Please remove this appendix prior to
publication]
Document History
Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption.
Working Group Draft 01
o Fixed editorial mistakes and added an appendix which shows the
preliminary framework for securing the ULE network.
Working Group Draft 02
o Fixed editorial mistakes and added some important changes as
pointed out by Knut Eckstein (ESA), Gorry Fairhurst and
UNISAL.
o Added section 4.1 on GSE. Extended the security considerations
section.
o Extended the appendix to show the extension header placement.
o The definition of the header patterns for the ULE Security
databases will be defined in a separate draft.
o Need to include some words on key management transport over
air interfaces, actually key management bootstrapping.
Working Group Draft 03
o Fixed editorial mistakes and added some important changes as
pointed out by Gorry Fairhurst.
o Table 1 added in Section 6.2 to list the different security
techniques to mitigate the various possible network threats.
o Figure 2 modified to clearly explain the different interfaces
present in the framework.
o New Section 7 has been added.
o New Section 6 has been added.
o The previous sections 5 and 6 have been combined to section 5.
o Sections 3, 8 and 9 have been rearranged and updated with
comments and suggestions from Michael Noisternig from
University of Salzburg.
o The Authors and the Acknowledgments section have been updated.
 End of changes. 94 change blocks. 
331 lines changed or deleted 358 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/