IPDVB Working Group M. Noisternig
Internet Draft University of Salzburg
Intended status: Standards Track P. Pillai
Expires: December 2009 University of Bradford
H. Cruickshank
University of Surrey
June 29, 2009
Security Extension for Unidirectional Lightweight Encapsulation
Protocol
draft-noisternig-ipdvb-sec-ext-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 29, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Noisternig et al. Expires December 29, 2009 [Page 1]
Internet-Draft Security Extension for ULE June 2009
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
The Unidirectional Lightweight Encapsulation (ULE) protocol provides
an efficient mechanism for transporting IP and other network layer
protocol data over MPEG-2 networks. Such networks, widely used
especially for providing digital TV services, often use broadcast
wireless transmission media, and are hence vulnerable to various
types of security attacks.
This document describes a new mandatory ULE extension to protect ULE
traffic using security features such as data confidentiality, data
integrity, data origin authentication, and prevention against replay
attacks. Additionally, destination addresses may be hidden from
illegitimate receiver devices using the identity protection feature.
The format of the security extension header as well as the processing
at receivers and transmitters are described in detail. The extension
aims to be lightweight and flexible such that it may be implemented
in low-cost, resource-scarce transceivers, and different levels of
security may be selected.
The security extension may be easily adapted to the Generic Stream
Encapsulation (GSE) protocol, which uses a similar extension header
mechanism.
Table of Contents
1. Introduction ................................................. 3
2. Requirements Notation ........................................ 4
3. Abbreviations used in this document .......................... 4
4. Security Services ............................................ 5
5. Secure ULE SNDU Format ....................................... 7
5.1. Type Field .............................................. 9
5.2. Receiver Destination Address Field ...................... 9
5.3. ULE-SID Field .......................................... 10
5.4. Encrypted Destination Address Field .................... 10
5.5. SA-Dependant Data Field ................................ 10
5.6. Encrypted Next-Type Field .............................. 10
5.7. Encrypted Payload ...................................... 10
5.8. Message Authentication Code (MAC) Field ................ 10
6. Transmitter and Receiver Processing ......................... 11
6.1. Security Policy Database (SPD) ......................... 12
6.2. Security Association Database (SAD) .................... 13
6.3. Transmitter Processing ................................. 14
Noisternig et al. Expires December 29, 2009 [Page 2]
Internet-Draft Security Extension for ULE June 2009
6.4. Receiver Processing .................................... 16
7. Key Management Considerations ............................... 18
7.1. MSEC/IPsec Key Management Protocols .................... 19
7.2. Existing L2 Key Management Infrastructure .............. 19
7.3. Other Considerations ................................... 19
8. Security Considerations ..................................... 19
9. IANA Considerations ......................................... 21
10. Conclusions ................................................ 21
11. Acknowledgments ............................................ 21
12. References ................................................. 22
12.1. Normative References .................................. 22
12.2. Informative References ................................ 22
1. Introduction
The Unidirectional Lightweight Encapsulation (ULE) protocol [3]
provides an efficient mechanism for transporting IP and other network
layer protocol data over ISO MPEG-2 Transport Streams (TS) [1]. This
document describes a new ULE mandatory extension header for providing
link layer security for ULE.
In MPEG-2 transmission networks employing ULE there is a need to
provide link layer security, particularly where network layer and
transport layer security may not be present or may not be sufficient.
The security requirements are presented and discussed in detail in
[4]. The set of security services that the security extension for ULE
can provide includes data confidentiality, data integrity, data
origin authentication and rejection of replayed packets. While
providing suitable link encryption is mandatory, link layer data
integrity and data origin authentication is provided as an optional
security service. These are especially desirable for systems where
there are several ULE transmitters (e.g., satellite mesh systems with
on-board processing).
Another feature provided is called identity protection. This allows
hiding destination addresses from illegitimate receiver devices, thus
enabling a form of traffic flow confidentiality.
On securing the ULE SNDUs, security is provided at the link layer as
opposed to existing higher-layer mechanisms like IPsec [8] or TLS
[11]. This allows them to be used independently and in parallel, and
any network layer protocol like IP (even with Ethernet bridging) may
be used with the security extension.
The security extension may use and benefit from IETF key management
protocols, such as the MSEC Group Domain of Interpretation (GDOI) [9]
and the Group Secure Association Key Management Protocol (GSAKMP)
Noisternig et al. Expires December 29, 2009 [Page 3]
Internet-Draft Security Extension for ULE June 2009
[7]. This does not preclude the use of other key management methods
in scenarios for which there is benefit.
The processing specification follows the IPsec approach of defining a
Security Policy Database (SPD) and a Security Association Database
(SAD). A Security Identifier (SID), similar to the Security Parameter
Index (SPI) in the IPsec protocols, assists receiver devices in
looking up security states. The design of above databases for ULE
security is similar but simpler because unlike in IPsec a receiver
only needs the SID along with the NPA address and possibly the PID to
retrieve the data from these databases.
Security transforms such as encryption algorithms may be modelled
after existing MSEC and IPsec security algorithms, but will be
defined in separate documents in order to proceed/update them
independently of this specification.
The ULE security extension is designed to cope with both bi-
directional and unidirectional links, as well as unicast and
multicast settings.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
3. Abbreviations used in this document
AES - Advanced Encryption Standard
DES - Data Encryption Standard
DVB - Digital Video Broadcasting
GDOI - Group Domain of Interpretation
GSKAMP - Group Secure Association Key Management Protocol
IPsec - Internet Protocol Security
MPE - Multi-Protocol Encapsulation
MAC - Message Authentication Code
NAT - Network Address Translation
Noisternig et al. Expires December 29, 2009 [Page 4]
Internet-Draft Security Extension for ULE June 2009
NCC - Network Control Centre
NPA - Network Point of Attachment
PEP - Protocol Enhancing Proxy
PID - Packet Identifier
PDU - Protocol Data Unit
SAD - Security Association Database
SHA - Standard Hash Algorithm
SNDU - Subnetwork Data Unit
SPD - Security Policy Database
SPI - Security Parameter Index
TLS - Transport Layer Security
ULE - Unidirectional Lightweight Encapsulation Protocol
4. Security Services
MPEG-2 based networks are susceptible to several security attacks,
both passive and active. Some of the main security services
(mandatory or optional) that the security extension for ULE aims to
provide are:
o Data confidentiality (mandatory): Data confidentiality is
achieved by encrypting the higher layer PDU (and other ULE
extensions headers that may be present and require security)
before encapsulation in the ULE SNDU, so that only authorised
receivers can decrypt the transmitted information while an
adversary would not be able to recover the important information
even if it got hold of the transmitted data.
Noisternig et al. Expires December 29, 2009 [Page 5]
Internet-Draft Security Extension for ULE June 2009
o Receiver address hiding (optional): Hiding an SNDU's real
destination NPA address from an adversary is arguably the most
important step on providing identity protection. While one
solution for this is to use temporary addresses, this is
susceptible to various practical issues. More importantly, from a
security point of view, temporary addresses do not provide
adequate identity protection, as a passive adversary may easily
link different SNDUs to the same connection. Also, a procedure to
allocate temporary addresses is required such that they are unique
in the system. Hence it is proposed to encrypt the destination
address. By encrypting the destination address within the SNDU, an
attacker is effectively denied from gaining information by
monitoring addresses.
o Data origin authentication (optional): Data origin (source)
authentication allows a ULE receiver to verify data as sent by a
legitimate ULE sender. A Message Authentication Code (MAC) using a
shared secret key may be used to authenticate the sender in
unicast settings, or to guarantee an SNDU originating from a group
member in secure group communication. For the latter, other source
authentication schemes, such as digital signatures, may be used in
order to assure source authenticity.
o Data integrity (optional): Data integrity provides a way for the
receiver of the data message to know if the data has been tampered
with in transit by an attacker. This is provided for by the data
origin authentication algorithm. A change in the message will
alter the authentication value, and an adversary will not be able
to derive a correct one.
Noisternig et al. Expires December 29, 2009 [Page 6]
Internet-Draft Security Extension for ULE June 2009
o Replay attacks countermeasures (optional): Methods against replay
attacks need to ensure that the received data is recent and that
an adversary has not replayed old messages at a later time. A
monotonically increasing sequence number may be part of the SA-
dependent data field of the security extension header, allowing
messages with old sequence number values to be rejected. As with
other security services, the choice of using sequence numbers is
dictated by policy, usually done by the key management system.
Note that sequence numbers resemble unkeyed connection states that
an adversary may track to link packets to different connections.
Therefore, use of sequence numbers is not mandated. One solution
is encrypting sequence numbers using standard Electronic Code Book
(ECB) mode (i.e., encrypt as one block of data). A receiver first
decrypts the encrypted value within the protocol to check for a
replay, and then may use either the encrypted value as an
initialization vector for the Cipher Block Chaining (CBC) mode of
operation, or the decoded sequence number for the Counter (CTR)
mode (with the internal counter incremented by one). The
disadvantage is a slightly higher protocol overhead compared to
unencoded sequence numbers. Another solution is to use connection-
independent timestamp values. Depending on the resolution,
timestamps may or may not provide perfect replay protection. The
drawback is a higher protocol overhead, including the need for
synchronized clocks.
5. Secure ULE SNDU Format
Figure 1 below shows an example SNDU format containing the security
extension header. The extension header is designed as a framework for
a set of security transforms, enabling high flexibility in selecting
various security services (including common encryption algorithms
such as DES [12], 3DES, AES [13], etc.). Security transforms are to
be described in separate documents, and will be based on algorithms
defined for the MSEC/IPsec protocols.
The ULE security extension is a standard extension header as
described in Section 5 of RFC 4326 [3], and does not affect the ULE
base protocol. Furthermore, the extension is a Mandatory ULE
Extension header, which means that a receiver MUST process this
header before it processes the next extension header or the
encapsulated PDU, otherwise the entire SNDU should be discarded.
When configuring use of the security extension at encapsulation
devices, it is RECOMMENDED to place the extension header directly
after the base header. This permits full protection for all headers.
Noisternig et al. Expires December 29, 2009 [Page 7]
Internet-Draft Security Extension for ULE June 2009
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|D| Length | Type = Secure-ULE |
+-+----------------------------+------------------------------+
| Receiver Destination NPA Address (D=0) |
| +------------------------------+
| | ULE-SID |
+------------------------------+------------------------------+
| Encrypted Destination NPA Address (optional) |
+------------------------------+------------------------------+
| |
= SA-Dependant Data (optional) =
| |
| +------------------------------+
| | Encrypted Next-PDU Type |
+------------------------------+------------------------------+
| |
| |
= Encrypted PDU =
| |
| |
+------------------------------+------------------------------+
| |
= Message Authentication Code (optional) =
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Check |
+-------------------------------------------------------------+
Figure 1. General SNDU format with security extension header
In Figure 1, the Type field in the base header denotes that a
mandatory security extension header is present. The receiver
destination NPA address is optional (dependent on the D bit). After
the ULE base header, the security extension header follows. This
header contains the ULE Security Identifier (SID), an optional
Encrypted Destination Address, a variable-length field whose content
is determined by a Security Association (SA), and an encrypted Type
field denoting the type of the enclosed PDU (or a subsequent
extension header if present). The security extension header has an
associated trailer following the PDU data that contains an optional
Message Authentication Code (MAC) field. Placing the MAC in the end
of the SNDU is in similar spirit to the CRC, and allows computation
in an on-line way, i.e., an encapsulator may derive the MAC of an
SNDU during the process of transmitting it, and following the last
bit of the PDU it can simply attach the MAC.
The following subsections describe the fields that are part of or are
Noisternig et al. Expires December 29, 2009 [Page 8]
Internet-Draft Security Extension for ULE June 2009
directly relevant to the security extension header in more detail.
All other fields are defined within the ULE standard [3].
5.1. Type Field
The 16-bit Type field of the ULE base header (or some other extension
header) indicates a security extension header following subsequently.
[XXX IANA ACTION REQUIRED to allocate xxSecure-ULExx XXX]
This Secure-ULE Type code is to be defined in the IANA maintained
Next-Header Registry for ULE and has the value xxSecure-ULExx
[XXX END of IANA ACTION XXX]
5.2. Receiver Destination Address Field
This field, defined in the ULE standard, typically carries the
destination NPA address of a receiver device, or the address of a
multicast group. However, when the identity protection service is
used, this address is moved into the security extension header (see
section 5.4). The address field in the base header may still be
present, though, to reduce processing constraints for other receiver
devices and aid in the lookup of security states, for example by
containing a multicast address designating a VPN of the destination.
However, it MUST NOT contain the real destination NPA address that is
hidden within the Encrypted Destination Address Field, and it MUST
NOT carry any other unique identifier for the receiver device.
Noisternig et al. Expires December 29, 2009 [Page 9]
Internet-Draft Security Extension for ULE June 2009
5.3. ULE-SID Field
A 16-bit Security Identifier (SID), similar to the SPI in IPsec, is
used to look up the security state for a connection. This SID
represents the Security Association (SA) between the ULE transmitter
and receiver for a particular session and indicates the keys and
algorithms used for encrypting the data payload and calculating the
MAC. The SID is used by a receiver to filter PDUs in combination with
the NPA address when present.
5.4. Encrypted Destination Address Field
This field is only present if the identity protection service is
selected. In that case, the 48-bit destination NPA address from the
base header is omitted (i.e., the base header's D bit set to 1), and
instead appears in the security extension header, where it is
encrypted subsequently (along with the payload data).
5.5. SA-Dependant Data Field
This variable-length optional field may contain any auxiliary
information that is specific to the particular SA. Typical content
would be sequence numbers for the purpose of replay protection and as
nonces for stream cipher encryption, or Initialisation Vectors (IVs)
for randomized security algorithms. The length of this field, of the
subentries, and their order is defined by the SA and mandated by
policy.
5.6. Encrypted Next-Type Field
This 16-bit value denotes the type of a subsequent extension header,
respectively the content type of the payload data. It is encrypted
along with the payload. If another ULE extension header follows, then
this type field indicates the type of this extension header.
5.7. Encrypted Payload
All data transmitted between ULE sender and receiver is encrypted
under the data confidentiality service. The coverage of this service
includes the Payload Data Unit (PUD), the Encrypted Next-Type Field,
and the Encrypted Destination NPA Address Field if present. The
algorithms and keys used for this purpose are determined by the SA
shared between the communicating points.
5.8. Message Authentication Code (MAC) Field
Noisternig et al. Expires December 29, 2009 [Page 10]
Internet-Draft Security Extension for ULE June 2009
This field, when present, carries the tag of a Message Authentication
Code (MAC) in order to provide both data origin authentication and
data integrity. It is RECOMMENDED that is has a default size of 12
octets. The default scope of the MAC algorithm is the entire SNDU up
to but not including the MAC and CRC fields.
The MAC field may also contain a digital signature or suitable output
of another multicast source authentication scheme if source
authentication under group communication is desired.
Reliable protection against modification of data and masquerading
attacks requires both sender and receiver identifiers to be
authenticated in addition to the payload. This is an issue for the
ULE protocol because it does not exhibit a source identifier field,
and the PID of an underlying MPEG-2 TS cell does not depict a unique
and reliable identifier. Without authenticating the source, an active
attacker may re-write the PID to appear from a different transmitter
under the same encryption key. This problem can only arise in
configurations with multiple senders sharing a key. In networks that
do not employ PID re-numbering, the PID may be part of a pseudo-
header for authenticating the source. This may be configured via
policy.
6. Transmitter and Receiver Processing
The processing specification follows the IPsec [8] approach of
defining a Security Policy Database (SPD) and a Security Association
Database (SAD). The SPD contains an ordered list of Security Policies
(SPs). These policies allow simple filtering of incoming or outgoing
data based on address and other information, including assignment of
different security services and keys to different connections and
secure groups. The SAD refers to the set of security states, called
Security Associations (SAs), which are referenced on the receiver
side using the SID along with the address information of the received
SNDU.
In the IPsec protocols, a receiver normally uses the SPI it has
chosen itself for looking up SAs within its SAD. In our proposed
extension the SPI is equivalent to the SID. However, this mechanism
of using the SPI does not work for multicast settings, for other
scenarios of group communication, and also for unidirectional links,
where the SPI value has to be centrally selected by a group
controller. A multicast IPsec implementation partially solves these
issues by taking into account the source and multicast destination of
a packet, and following a longest-match approach in determining the
appropriate SA in the following way: First, an SA is looked up using
the triple (SPI, destination, source) (1); if not successful, a
Noisternig et al. Expires December 29, 2009 [Page 11]
Internet-Draft Security Extension for ULE June 2009
search is done for (SPI, destination) (2); finally, only the SPI is
taken for the lookup (3). While (1) aims to support source-specific
multicast groups, (2) is meant for any-source multicast groups. This
document adapts that approach in the following way, using the Packet
Identifier (PID) of the underlying MPEG-2 TS cell:
For an SNDU with a multicast address present, a longest-match search
on (SID, destination NPA, PID) is performed in the incoming SAD.
Otherwise, a longest-match search is derived using (SID, PID) in the
incoming SAD. This takes into account VPN-like settings with a single
sender, as well as unidirectional links.
Support for shared SAs with multiple senders requires a coordinated
solution for determining a unique SID value. In order to support
shared SAs permitting bi-directional communication, an SAD should
only store references to SAs, and reference bi-directional SAs in
both the incoming and outgoing SAD.
Another difference to IPsec is the treatment of directionality for
SPs and SAs. In a standard IPsec implementation, a match on an SP
affects traffic in both directions, resulting in two separate
unidirectional SAs to be created. This document always requires
separate SPs to be defined for incoming and outgoing data, and in
turn allows SAs to be shared across several devices, supporting both
unidirectional links and group communication.
For the rest of this section, a Selector is defined as a pair of
destination NPA address and PID.
6.1. Security Policy Database (SPD)
An SPD contains an ordered list of SPs, similar to Access Control
Lists (ACLs). Each transmitter and receiver device defines one SPD
for outgoing data, and one for incoming SNDUs. For both databases, an
SP must provide the following information:
o An SP Selector, together with an SP Selector mask. This provides a
simple and basic way to filter based on address information. For a
transmitter SP, the Selector may be extended to include additional
filtering information, such as higher-layer addresses, and port
numbers.
o Information about the SA(s) to be instantiated by this SP, when a
match is found based on filtering. This contains:
o A Selector mask, denoted SA Selector mask, which specifies the
set of SAs derived from the policy. This provides a simple way
Noisternig et al. Expires December 29, 2009 [Page 12]
Internet-Draft Security Extension for ULE June 2009
to instantiate secure unicast connections, as well as shared SAs
for secure group communication. It is similar to the Populate-
From-Packet (PFP) flags in the IPsec specification, but slightly
more general.
o An optional SID value. If not defined, Group Controller and Key
Server (GCKS) data must be present for the SID to be selected
dynamically.
o Optional GCKS data. The GCKS must be contacted by a device which
cannot find an SA for a matching SP, and when the SP does not
define a static SID and default key data in its first set of
Security Parameters.
o An ordered list of Security Parameter sets used for
instantiating an SA, sorted according to preference. On creating
an SA, devices must default to the first entry in the list,
unless a key management protocol permits negotiation (e.g., for
unicast, bidirectional settings), and the device contacts the
GCKS to request another set of Security Parameters from the
list.
Each set of Security Parameters contains information about:
o The cryptographic algorithms used.
o The cryptographic parameters required by these algorithms (e.g.,
sequence number length, MAC length).
o Optional key data for manual keying.
A Security Parameter set may select no security services at all, by
which it is to be interpreted requesting processing without the
security extension header.
Each SPD may be manually constructed by a device or network operator,
but it may also be dynamically set up via a GCKS. Note that we do not
describe how to create such databases, or how to store, manage, and
look up SPs within the SPD, as this is regarded implementation
specific details.
6.2. Security Association Database (SAD)
A Security Association (SA) is an instantiation of an SP. It
describes the current state of a secure connection between two or
more devices. Each SA within the SAD must contain the following
information:
Noisternig et al. Expires December 29, 2009 [Page 13]
Internet-Draft Security Extension for ULE June 2009
o The SA Selector derived from the instantiating SP.
o The SID defined by the SP or the GCKS.
o Static security parameters defined by the SP (cryptographic
algorithms, MAC length, Sequence Number length, etc.).
o Dynamic security parameters (keys, sequence number, SA lifetime,
etc.), initially defined by the SP or the GCKS, and updated during
processing.
o GCKS specific data defined by the SP or the GCKS, including GCKS
contact information.
As with the SPD, the description of the implementation-specific
details of the SAD is out of scope of this document.
6.3. Transmitter Processing
The following list describes in detail the processing steps required
for a ULE encapsulator implementing the unified ULE security
extension:
1. Get SP: Upon constructing an SNDU for transmission over the ULE
link, an encapsulator must scan its outgoing SPD for a matching
policy. If no such policy can be found, the SNDU data must be
discarded, and this event should be logged as an invalid
transmission attempt.
2. Get SA: Given a matching SP, an SA is searched within the outgoing
SAD using the SNDU's Selector information and the policy's SA
Selector masks, including the SP's SID value if defined. If no SA
could be found, it must be set up as follows: If the SP's first
Security Parameter set contains default key data, or defines data
to be sent without protection, the SA is immediately created and
initialized according to these settings. Otherwise, if the SP
defines GCKS contact information, it must be queried for obtaining
key material. During that attempt the device should postpone
transmission, or discard the data. Any case of failure must result
in the data being discarded, and this event should be logged
accordingly (e.g., as a user authentication failure in the case of
membership denial by the GCKS). If the SA allows passing data
unprotected, processing continues as usually.
3. Check SA: The SA may have a pre-defined lifetime (e.g., maximum
number of encryptions, sequence number state, seconds since
instantiation) after which it may no longer be used. To allow for
Noisternig et al. Expires December 29, 2009 [Page 14]
Internet-Draft Security Extension for ULE June 2009
a transient switch-over to a new SA, the SA must define a point
prior to its lifetime end at which transmitters switch to the new
SA. If that point is reached, a device may proactively request a
new SA from a GCKS. In general, it is the responsibility of the
operator or the GCKS to create new SAs, and distributing them to
legitimate transmitter and receiver devices in time. If no new SA
is available, a transmitter may still use the current SA during
its full lifetime. After that, it must discard the data, and this
event should be logged.
4. Construct SNDU: A protected SNDU is built as follows:
a. First, the ULE base header and any extension headers preceding
the security extension header are written. If the SA requests
identity protection, the destination NPA address is omitted
from the base header, setting the base header's D bit to 1. The
last next-header-type field within the extension header chain
contains the type code for the security extension.
b. The SID value is written as the first field of the security
extension header.
c. If identity protection is used, the SNDU's destination NPA
address follows. It is encrypted along with the payload.
d. Any SA-dependent data, such as sequence numbers and
initialization vectors, are written subsequently.
e. Then, the next-header-type field, any further extension
headers, and the payload data are encoded as defined by the
SA's data confidentiality algorithm (together with the
encrypted destination NPA address).
f. For authentication and integrity protection, a MAC of length as
defined by the SA is appended. The MAC is computed over all the
data encoded so far, i.e., from the start of the SNDU to the
end of the payload data.
g. Finally, the CRC is calculated and appended, and the SNDU
further processed according to RFC 4326.
5. Update SA: After transmission of the SNDU, the SA must be updated
accordingly (e.g., the sequence number incremented by one).
Noisternig et al. Expires December 29, 2009 [Page 15]
Internet-Draft Security Extension for ULE June 2009
+-----------------+
| receive PDU | +-----------------+
+---->|from upper layers|<-------------------| discard PDU |
| +-----------------+ +-----------------+
| v ^
| +-----------------+ not found? +-----------------+
| | get SP |------------------->| log event |<-+
| +-----------------+ +-----------------+ |
| v ^ failure? |
| +-----------------+ not found? +-----------------+ |
| +--| get SA |------------------->| create SA | |
| | +-----------------+ +-----------------+ |
| |w/o | | success? |
| |sec.ext. | +----------------+ |
| | v | |
| | +-----------------+ end of | |
| | | check SA |-----------------------------------------+
| | +-----------------+ lifetime? |
| | | | +-----------------+
| | | expected | | get new SA |
| | +---------------------------->| from GCKS |
| | | lifetime end? | +-----------------+
| | v | v failure?
| | +-----------------+ | +-----------------+
| +->| construct SNDU |<-----------+ | log event |
| | & transmit | +-----------------+
| +-----------------+
| v
| +-----------------+
| | update SA |
| +-----------------+
| |
+--------------+
Figure 2. Transmitter Processing Flow Chart
6.4. Receiver Processing
For a receiver device to process SNDUs containing the security
extension, the following steps must be adhered to:
1. Decode SNDU (1): First, the CRC of an SNDU received is verified,
and the base header and extension headers preceding a security
extension header or the payload are evaluated.
2. Get SA: If a security extension header is found, a longest-match
search within the incoming SAD is performed as described in
Noisternig et al. Expires December 29, 2009 [Page 16]
Internet-Draft Security Extension for ULE June 2009
section III. If it contains a matching SA, processing continues at
step 4.
3. Get SP: The SPD is scanned similar to step 1 in the transmitter
processing specification. However, the destination NPA address may
be hidden, and consequently the SP must define whether the address
must be matched or not. When the SNDU is received without a
security extension header but the SP does not permit data to pass
unprotected, the SNDU must be discarded immediately, and this
event should be logged accordingly. Likewise, if there is a
security extension header, but the policy allows only for
unprotected data, the SNDU must be discarded, and the event should
be logged. When permitted, an unprotected SNDU is processed as
usually. Otherwise, an SA is created as described in step 2 of the
transmitter processing specification.
4. Check SA: If the SA's lifetime has expired, the SNDU must be
discarded, and this should be logged accordingly. If the extension
header contains an encrypted destination NPA address, it is first
decrypted, using the SA-dependent data, and checked for a valid
address for that SA. If the decoded address is not accepted by the
receiver device and the SA, the SNDU is discarded silently.
5. Decode SNDU (2): This step includes verification of the MAC,
protection against replay attacks, and decoding of the payload. In
any case of failure, the SNDU must be discarded, and this event
should be logged accordingly.
6. Update SA: After successful reception of an SNDU, the SA must be
updated accordingly (e.g., the sequence number set to the one
found within the SNDU, incremented by one).
Noisternig et al. Expires December 29, 2009 [Page 17]
Internet-Draft Security Extension for ULE June 2009
+-----------------+
| receive SNDU | +-----------------+
+---->| from MPEG layer |<----------------| discard SNDU |<----+
| +-----------------+ +-----------------+ |
| v ^ |
| +-----------------+ decoding error? +-----------------+ |
| |decode headers up|- - - - - - - - >| log event |<-+ |
| | to security ext.| +------->| | | |
| +-----------------+ | +-----------------+ | |
| | | not found/ ^ | |
| v | not permitted? | | |
| +-----------------+ not found? +-----------------+ | |
| +--| get SA |---------------->| get SP | | |
| | +-----------------+ | +-----------------+ | |
| |w/o | | success? | | |
| |sec.ext. v | v | |
| | +-----------------+ end of | +-----------------+ | |
| | | check SA |--------+ | create SA |->| |
| | +-----------------+ lifetime? +----------------+ | |
| | | success? | | |
| | | +--------------------------------+ | |
| | | | | |
| | v v | |
| | +-----------------+ decoding error? | |
| +->| decode SNDU |--------------------------------------+ |
| | & pass to L3 | |
| | |-----------------------------------------+
| +-----------------+ destination address mismatch?
| v
| +-----------------+
| | update SA |
| +-----------------+
| |
+--------------+
Figure 3. Receiver Processing Flow Chart
7. Key Management Considerations
Small and rather static network configurations may be supported using
manual keying. More elaborate settings, consisting of a higher number
of devices, or when users need to be added or excluded more
frequently, require some automated key management. This may be
defined independently of the ULE security extension. This section
presents some considerations on this issue.
Noisternig et al. Expires December 29, 2009 [Page 18]
Internet-Draft Security Extension for ULE June 2009
7.1. MSEC/IPsec Key Management Protocols
MSEC/IPsec key management protocols, such as the Group Domain of
Interpretation (GDOI) and the Group Secure Association Key Management
Protocol (GSAKMP) protocols, may be adapted for the ULE security
extension. This has the advantage of sharing similar functionality in
terms of SA lookup and database architectures.
The protocol may be run entirely within the ULE network, or it may be
performed by some other means. This is a matter of policy and an
architecture decision. For example, for bidirectional transfers the
whole key exchange procedures could be carried within the ULE
network, while for unidirectional links some other bidirectional
connection could be used.
7.2. Existing L2 Key Management Infrastructure
ULE security may re-use an already existing L2 key management
infrastructure, such as the DVB-RCS security system [6]. The format
of the ULE-Security-ID will be the same format as defined in DVB-RCS
security procedures.
7.3. Other Considerations
Key management protocols are traditionally assuming bidirectional
links. GSAKMP provides some initial support for push operation.
However, supporting unidirectional links within the ULE network may
require defining a new protocol. Such protocol should be designed
flexibly to support bidirectional operation as well without a change
in the header structures.
Existing L2 unidirectional mechanism may be evaluated, such as DVB-
Conditional Access (CA) and ATSC-CA.
8. Security Considerations
Link-level security is commonly used in broadcast/radio links to
supplement end-to-end security, and may not be treated as a
substitute. A common objective is to provide the same level of
privacy as terrestrial links.
A number of security considerations specific to the ULE security
extension have been outlined throughout the document. The following
paragraphs extend that analysis.
Hiding destination addresses under the identity protection service is
an effective mechanism against traffic flow analysis. However, there
Noisternig et al. Expires December 29, 2009 [Page 19]
Internet-Draft Security Extension for ULE June 2009
are other more subtle ways for a passive adversary to deduce the real
destination address of an SNDU, even when precluded from decoding the
destination NPA address field. For example, SNDUs with increasing
sequence numbers may be linked to a single connection, providing a
hint regarding the identities of the communicating parties based on
packet sizes and distribution patterns. Alternatives to sequence
numbers were outlined in section 5. When SID values are selected at
random for bidirectional links using identity protection, they may
resemble unique temporary addresses. This may be mitigated by always
selecting the smallest free SID value on a receiver device, thereby
increasing the chance of equal SID values among several devices.
However, this also means increased processing requirements in the
filtering step for these devices.
Other problems arise with certain cryptographic algorithms. Stateful
algorithms are problematic for manually keyed configurations when
devices cannot retain their cryptographic states across device
restarts (due to power or device failures, etc.). Reuse of sequence
numbers for the Counter (CTR) mode renders all encryption insecure.
Receiver devices may be vulnerable to replay attacks if they do not
remember prior lower bounds for sequence numbers. If devices cannot
store their cryptographic state in non-volatile memory, it is advised
that they resort to non-stateful schemes, such as the randomized
Cipher Block Chaining (CBC) mode for encryption, or the use of
timestamps for replay protection (if replay protection is desired).
Many stateful schemes, such as the CTR mode of operation, require
nonces as part of their input. As mentioned before, nonces must never
be re-used under the same key. To provide this guarantee,
particularly under group communication where the encryption key is
shared among several group members, some source identifier must be
incorporated into the construction of the nonce.
Within ULE networks, the PID may be used as a source identifier, but
this is not reliable. A device may receive data from different MPEG-2
multiplexes, which both may allocate PID values independently.
Furthermore, multiplexors within the network may transparently re-
number PID values. This is a problem for receivers as they require
the originating PID value for reconstructing nonces.
One solution to circumvent these issues is to assign a unique sender
identifier to each legitimate transmitter under the same key [14]. To
avoid the problem of associating an MPEG-2 TS with a sender
identifier, the latter is included explicitly as part of the nonce in
each SNDU. This means that the nonce field (e.g., sequence number)
may get enlarged by the size necessary to support a predefined
maximum number of different senders sharing a key. The other caveat
Noisternig et al. Expires December 29, 2009 [Page 20]
Internet-Draft Security Extension for ULE June 2009
of this approach is the problem of generating and distributing unique
sender identifiers.
The lack of a reliable source identifier entails also a potential
authentication insecurity. However, this only applies for specific
communication scenarios, as outlined in section 5.
9. IANA Considerations
The Secure-ULE header is defined in the IANA maintained Next-Header
Registry for ULE and has the value xxSecure-ULExx.
10. Conclusions
This document defines a method to provide mandatory link encryption
at the ULE level. The method also supports optional link level
integrity /authentication of the SNDU payload plus protection against
replay attacks, and mitigates the effectiveness of traffic flow
analysis by encrypting ULE link layer destination addresses. This is
provided in a flexible way using a new ULE Mandatory Extension
Header. This decouples specification of the security functions from
the encapsulation functions. Encryption and integrity algorithms may
be defined similar to the ones used in the IPsec/MSEC protocols, and
can be updated independently of this specification.
11. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen), L. Duquerroy (Alcatel Alenia Space)
Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in the
preparation of this document.
Noisternig et al. Expires December 29, 2009 [Page 21]
Internet-Draft Security Extension for ULE June 2009
12. References
12.1. Normative References
[1] ISO/IEC DIS 13818-1, "Information technology - Generic coding
of moving pictures and associated audio information - Part1:
Systems", International Standards Organisation (ISO)
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Streams", RFC 4326, December
2005.
[4] H. Cruickshank, P. Pillai, M. Noisternig and S. Iyengar,
"Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", RFC 5458, March 2009.
12.2. Informative References
[5] "Digital Video Broadcasting (DVB): DVB Specifications for Data
Broadcasting", ETSI EN 301 192 v1.3.1, 2003.
[6] "Digital Video Broadcasting (DVB): Interaction Channel for
satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005.
[7] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535,
June 2006.
[8] S. Kent and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[9] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.
[10] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker, B.,
and H. Linder, "A Framework for Transmission of IP Datagrams
over MPEG-2 Networks", RFC 4259, November 2005.
[11] http://www.ietf.org/html.charters/tls-charter.html
[12] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", Federal Information Processing
Standard (FIPS) Publication, FIPS PUB 46-3, October 1999.
Noisternig et al. Expires December 29, 2009 [Page 22]
Internet-Draft Security Extension for ULE June 2009
[13] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing
Standard (FIPS) Publication, FIPS PUB 197, November 2001.[14] D.
McGrew, B. Weis, "Using Counter Modes with Encapsulating
Security Payload (ESP) and Authentication Header (AH) to
Protect Group Traffic", draft-ietf-msec-ipsec-group-counter-
modes-03 (work in progress), 2009.
Author's Addresses
Michael Noisternig
University of Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg
Austria
Email: mnoist@cosy.sbg.ac.at
Prashant Pillai
Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: p.pillai@bradford.ac.uk
Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: h.cruickshank@surrey.ac.uk
Noisternig et al. Expires December 29, 2009 [Page 23]