IPDVB Working Group M. Noisternig
Internet Draft University of Salzburg
Intended status: Standards Track P. Pillai
Expires: January 2010 University of Bradford
H. Cruickshank
University of Surrey
July 13, 2009

Security Extension for Unidirectional Lightweight Encapsulation
Protocol
draft-noisternig-ipdvb-sec-ext-01.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 January 13, 2009.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).

Noisternig et al. Expires January 13, 2010 [Page 1]

Internet-Draft Security Extension for ULE July 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
unauthorized 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 ........................................... 9
5.4. Encrypted Destination Address Field ..................... 9
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 January 13, 2010 [Page 2]

Internet-Draft Security Extension for ULE July 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. Acknowledgments ............................................ 21
11. References ................................................. 22
11.1. Normative References .................................. 22
11.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).

The extension also supports what is called 'identity protection' in
this specification. This allows hiding destination addresses from
unauthorized receiver devices, thus enabling a form of traffic flow
confidentiality.

The method described in this document provides security for ULE SNDUs
at the link layer, in contrast to higher-layer mechanisms, such as
IPsec [7] and TLS [10]. This allows protecting any network layer
protocol (even with Ethernet bridging), while higher-layer security
may be used independently and in parallel. Link-layer signalling
information may be protected as well.

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

Noisternig et al. Expires January 13, 2010 [Page 3]

Internet-Draft Security Extension for ULE July 2009

Index (SPI) in the IPsec protocols, assists receiver devices in
looking up security states. The design of the 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.

Key management protocols assuming similar processing functionality,
such as the MSEC Group Domain of Interpretation (GDOI) [8] and the
Group Secure Association Key Management Protocol (GSAKMP) [6], may be
adapted for the ULE scenario. Simple configurations are supported
using manual keying (i.e., pre-shared keys).

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 for both bi-directional and
unidirectional links, as well as unicast and multicast settings [9].

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

GSE - Generic Stream Encapsulation

IPsec - Internet Protocol Security

MPE - Multi-Protocol Encapsulation

MAC - Message Authentication Code

NAT - Network Address Translation

Noisternig et al. Expires January 13, 2010 [Page 4]

Internet-Draft Security Extension for ULE July 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

SID - Security Identifier

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

VPN - Virtual Private Network

4. Security Services

MPEG-2 based networks are susceptible to several security attacks,
both passive and active [4]. Some of the main security services
(mandatory or optional) that the security extension for ULE provides:

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 access to the transmitted data.

Noisternig et al. Expires January 13, 2010 [Page 5]

Internet-Draft Security Extension for ULE July 2009

o Receiver address hiding (optional): Hiding an SNDU's real
destination NPA address from an adversary is an important step in
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 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 unlikely be
able to derive a correct one.

Noisternig et al. Expires January 13, 2010 [Page 6]

Internet-Draft Security Extension for ULE July 2009

o Replay attacks countermeasures (optional): Methods against replay
attacks need to ensure that an adversary has not replayed old
authentic 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
effected 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 the format of an SNDU 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 [11], 3DES, AES [12], 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 January 13, 2010 [Page 7]

Internet-Draft Security Extension for ULE July 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). The
security extension header follows the ULE base header. 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.

Noisternig et al. Expires January 13, 2010 [Page 8]

Internet-Draft Security Extension for ULE July 2009

The following subsections describe the fields that are part of or are
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.

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, and instead appears in the security extension
header, where it is encrypted subsequently (along with the payload

Noisternig et al. Expires January 13, 2010 [Page 9]

Internet-Draft Security Extension for ULE July 2009

data). If no other label is inserted in the base header's address
field (see section 5.2), the D bit is set to 1.

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 to provide replay protection, 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 [3]. 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

This field, when present, carries the tag of a Message Authentication
Code (MAC) to provide both data origin authentication and data
integrity. 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 [9]. Without authenticating the source, an

Noisternig et al. Expires January 13, 2010 [Page 10]

Internet-Draft Security Extension for ULE July 2009

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 [7] 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 this
specification the SPI is equivalent to the SID. However, under
automated key management, this mechanism of using the SPI does not
work for multicast settings, multi-sender shared SA scenarios, and
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 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. To support shared SAs
permitting bi-directional communication and avoid the effort of

Noisternig et al. Expires January 13, 2010 [Page 11]

Internet-Draft Security Extension for ULE July 2009

duplicating SAs, an SAD may 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 being 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 an independent 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
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. When a GCKS is configured, it 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

Noisternig et al. Expires January 13, 2010 [Page 12]

Internet-Draft Security Extension for ULE July 2009

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:

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, 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. This document does
not describe how to create such databases, or how to store, manage,
and look up SPs within the SPD; this is regarded as implementation
specific detail.

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:

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.

Noisternig et al. Expires January 13, 2010 [Page 13]

Internet-Draft Security Extension for ULE July 2009

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, the GCKS 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 (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 usual [3].

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
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 these 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

Noisternig et al. Expires January 13, 2010 [Page 14]

Internet-Draft Security Extension for ULE July 2009

identity protection, the destination NPA address is omitted
from the base header, setting the base header's D bit to 1
(though another label may be re-inserted, see section 5.2). 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
(e.g., the sequence number incremented by one).

Noisternig et al. Expires January 13, 2010 [Page 15]

Internet-Draft Security Extension for ULE July 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 performed:

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 January 13, 2010 [Page 16]

Internet-Draft Security Extension for ULE July 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. 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 usual [3]. 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. 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 MUST be silently discarded.

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.

6. Update SA: After successful reception of an SNDU, the SA MUST be
updated (e.g., the sequence number set to the one found within the
SNDU, incremented by one).

Noisternig et al. Expires January 13, 2010 [Page 17]

Internet-Draft Security Extension for ULE July 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 January 13, 2010 [Page 18]

Internet-Draft Security Extension for ULE July 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 [5]. 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 a 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 for end-to-end security. 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 January 13, 2010 [Page 19]

Internet-Draft Security Extension for ULE July 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 [9].
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 January 13, 2010 [Page 20]

Internet-Draft Security Extension for ULE July 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. 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 January 13, 2010 [Page 21]

Internet-Draft Security Extension for ULE July 2009

11. References

11.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.

11.2. Informative References

[4] H. Cruickshank, P. Pillai, M. Noisternig, and S. Iyengar,
"Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", RFC 5458, March 2009.

[5] "Digital Video Broadcasting (DVB): Interaction Channel for
satellite distribution systems", ETSI EN 301 790 v1.4.1, 2005.

[6] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535,
June 2006.

[7] S. Kent and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.

[8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.

[9] 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.

[10] http://www.ietf.org/html.charters/tls-charter.html

[11] National Institute of Standards and Technology, "Data
Encryption Standard (DES)", Federal Information Processing
Standard (FIPS) Publication, FIPS PUB 46-3, October 1999.

[12] National Institute of Standards and Technology, "Advanced
Encryption Standard (AES)", Federal Information Processing

Noisternig et al. Expires January 13, 2010 [Page 22]

Internet-Draft Security Extension for ULE July 2009

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 January 13, 2010 [Page 23]