ipdvb Working Group Michael Noisternig
Bernhard Collini-Nocker
Internet Draft University of Salzburg
July 14, 2008
Expires: January 2009
A lightweight security extension for the
Unidirectional Lightweight Encapsulation (ULE) protocol
draft-noisternig-ipdvb-ulesec-01
Status of this Document
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Unidirectional Lightweight Encapsulation (ULE) protocol is an
efficient and extensible transport mechanism for IP over MPEG-2
networks. Such networks are often operated on broadcast wireless
Noisternig Expires January 14, 2009 [Page 1]
Internet-Draft A lightweight security extension for ULE July 2008
channels, and are thus specifically vulnerable to attacks. Passive
attacks, such as eaves-dropping, are simple to perform and emphasize
the importance of security support within ULE.
This document defines a mandatory security extension for the ULE
protocol that is designed with the aim of being conservative in
bandwidth consumption and lightweight in the sense that it allows for
implementation in low-cost, resource-scarce (mobile) receiver
devices. The extension may be easily adapted to the Generic Stream
Encapsulation (GSE) protocol, which uses the same extension header
mechanism. The document describes the format of the security
extension header, specifies default security algorithms to be used
with this extension, and gives detailed processing descriptions for
devices implementing the security extension.
Conventions used in this document
The following DVB specific terms are taken from [RFC4326] and
recapitulated here for easy lookup:
DVB: Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data using
the ISO MPEG-2 standard [MPEG2].
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG) and standardized by the International Standards
Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222].
NPA: Network Point of Attachment. In this document, refers to a 48-
bit destination address (resembling an IEEE MAC address) within the
MPEG-2 transmission network that is used to identify individual
receivers or groups of receivers.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PID: Packet Identifier [MPEG2]. A 13-bit field carried in the header
of TS cells. This is used to identify the TS Logical Channel to
which a TS cell belongs [MPEG2].
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2
payload unit.
TS: Transport Stream [MPEG2]. A method of transmission at the MPEG-2
level using TS cells; it represents layer 2 of the ISO/OSI reference
model.
Noisternig Expires January 14, 2009 [Page 2]
Internet-Draft A lightweight security extension for ULE July 2008
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level [MPEG2].
All packets sent over a TS Logical Channel carry the same PID value.
ULE: Unidirectional Lightweight Encapsulation [RFC4326]. A protocol
that encapsulates PDUs into SNDUs that are sent in a series of TS
cells using a single TS Logical Channel.
Terms and abbreviations from cryptography are explained when they
first appear within this document.
All numbers encoded in protocols are to be interpreted in network
byte order.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when
appearing within this document, are to be interpreted as described in
[RFC2119].
Table of Contents
1. Introduction ................................................. 4
2. Format of the ULE Security Extension Header .................. 6
2.1. Type field .............................................. 7
2.2. VPN-ID field ............................................ 7
2.3. Key (K) bit ............................................. 7
2.4. Sequence Number.......................................... 8
2.5. Encrypted Destination Address field ..................... 8
2.6. PDU Type field .......................................... 8
2.7. MAC field ............................................... 8
3. Security Algorithms .......................................... 8
3.1. Key Derivation .......................................... 9
3.2. Encryption .............................................. 9
3.3. Identity Protection .................................... 10
3.4. Authentication and Integrity Protection ................ 11
3.5. Replay Protection ...................................... 12
4. Security Extension Header Processing ........................ 12
4.1. Preliminaries .......................................... 12
4.1.1. Security Policy Database (SPD) .................... 13
4.1.2. Security Association Database (SAD) ............... 14
4.2. Sender Processing ...................................... 16
4.2.1. General Activity Diagram .......................... 16
4.2.2. Detailed Processing Description ................... 16
4.3. Receiver Processing .................................... 20
4.3.1. General Activity Diagram .......................... 20
4.3.2. Detailed Processing Description ................... 21
5. Key Management Considerations ............................... 23
Noisternig Expires January 14, 2009 [Page 3]
Internet-Draft A lightweight security extension for ULE July 2008
5.1. Unidirectional Key Management .......................... 24
5.2. Bidirectional Key Management ........................... 25
6. Security Considerations ..................................... 25
7. IANA Considerations ......................................... 26
8. Conclusions ................................................. 26
9. Acknowledgments ............................................. 27
APPENDIX A: Rationale for the Extension Header Format .......... 28
A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI .............. 28
A.2. VPN-ID + K-Bit vs. SPI ................................. 28
A.3. 31-bit/63-bit Sequence Number .......................... 29
A.4. MAC field .............................................. 29
APPENDIX B: Rationale for the Default Security Algorithms ...... 30
B.1. Encryption ............................................. 30
B.2. Identity protection .................................... 31
B.3. Authentication ......................................... 32
B.4. Source Authentication .................................. 33
B.5. Combined Authentication and Encryption ................. 34
B.6. Replay Protection ...................................... 35
10. References ................................................. 36
10.1. Normative References .................................. 36
10.2. Informative References ................................ 36
Author's Addresses ............................................. 41
Intellectual Property Statement ................................ 41
Disclaimer of Validity ......................................... 42
1. Introduction
The Unidirectional Lightweight Encapsulation (ULE) protocol [RFC4326]
has been designed as an efficient and extensible encapsulation
mechanism of IPv4/IPv6 and other network layer packets over the ISO
MPEG-2 Transport Stream (TS) [MPEG2]. It has a simple base format,
but as such does not offer any security services; however, MPEG-2
networks are often operated on wireless channels, such as satellite
DVB-S [DVB-S] and terrestrial wireless DVB-T [DVB-T] and DVB-H [DVB-
H] links, and are thus specifically vulnerable to attacks [ULEsec-
Req]. Passive attacks, such as eavesdropping packet data or
monitoring the identities (addresses) of the communicating parties,
are easy to perform, and remain undetected. Low cost receiver devices
and the large coverage area of satellite senders add to the
likelihood of such events. Effective means to secure the ULE link are
therefore important.
One solution is to rely on end-to-end security, and on one hand,
reliable security can only be end-to-end. On the other hand, end-to-
end security may not be applicable: this is because both sides of a
communication must provide support for the same security mechanism,
Noisternig Expires January 14, 2009 [Page 4]
Internet-Draft A lightweight security extension for ULE July 2008
which will not be realizable under many conditions where the two
sides are not under central control (e.g., when browsing a public web
site). One important security requirement cannot be attained by end-
to-end security at all: the protection of the end-point addresses
("identities") of the communicating parties against eavesdropping
(subsequently referred to as "identity protection").
By securing the ULE link only, solutions can be provided for these
problems. In addition, this has the benefit that the ULE broadcast
link becomes transparent for the user in the sense that he or she can
rely on security assumptions as of wired links [RFC3819]. The IPsec
[RFC4301] security protocols could be used in tunnel mode to create
such a secure link, but this will result in significant bandwidth
overhead on satellite links (due to the IP-in-IP encapsulation).
Current IPsec specifications only define pairwise tunnels between two
devices, thus this option is not applicable for multicast and
broadcast transmissions. Last but not least, the rather high
complexity of IPsec implementations might make its realization within
low-cost receiver devices difficult.
Implementing security at the ULE link layer addresses above problems.
A more detailed rationale for ULE link layer security and a
comparison of security at the various layers can be found in [ULEsec-
Req]. It also lists the security requirements for the ULE link.
This document defines a mandatory security extension for the ULE
protocol that is designed with the aim of being conservative in
bandwidth consumption and lightweight in the sense that it allows for
implementation in low-cost, resource-scarce (mobile) receiver
devices. The extension may be easily adapted to the second-generation
Generic Stream Encapsulation (GSE) protocol [GSE], which shares the
extension header mechanism with ULE. The format of the security
extension header is described in section 2, and default security
algorithms to be used with this extension are specified in section 3.
These algorithms should address the most important security
requirements for the ULE link: data confidentiality, identity
protection, integrity protection, data authentication, and replay
protection. Section 4 then gives detailed processing descriptions for
devices implementing the security extension. While not defining any
protocol for automated key management, some guidelines are given in
section 5. After security and IANA considerations in sections 6 and
7, conclusions are presented in section 8. At the end of this
document, two appendices support the reader with more insight and
rationale on the decisions taken within this specification.
Noisternig Expires January 14, 2009 [Page 5]
Internet-Draft A lightweight security extension for ULE July 2008
2. Format of the ULE Security Extension Header
This section defines the format of the ULE security extension header,
ULEsec header in short. This format can be regarded as a framework
for a set of security transforms. While section 3 defines default
algorithms to be used within that framework, other security
transforms, especially making use of other cryptographic primitives,
modes, and key lengths, may be devised later and defined within
separate documents.
Figure 1 below shows an example format of a ULE SubNetwork Data Unit
(SNDU) containing a ULEsec header. In this example, the ULEsec
extension header directly follows the base header, and it is
RECOMMENDED that encapsulation devices always be configured that way.
Users not following this recommendation must clearly understand the
implications: first, extension headers preceding the ULEsec header
cannot be protected under the data confidentiality service; second,
when processing the security extension header, a receiver device may
decide to discard the SNDU, a point at which preceding headers will
already have been evaluated.
0 16 31
+-+-----------------------------+------------------------------+
|D| Length | Type=ULEsec/ULEsec_ID |
+-+-----------------------------+------------------------------+
| Destination Address (D=0) |
| +------------------------------+
| | VPN-ID (Type=ULEsec_ID) |
+-+-----------------------------+------------------------------+
|K| Sequence Number (31/63 bits) |
+-+-----------------------------+------------------------------+
| Encrypted Destination Address (optional) |
| +------------------------------+
| | (Encrypted) PDU Type |
+-------------------------------+------------------------------+
| |
~ (Encrypted) Payload Data ~
| |
| |
+--------------------------------------------------------------+
| |
~ MAC (optional) ~
| |
+--------------------------------------------------------------+
| CRC-32 |
+--------------------------------------------------------------+
Figure 1 Example ULE SNDU containing a security extension header
Noisternig Expires January 14, 2009 [Page 6]
Internet-Draft A lightweight security extension for ULE July 2008
The following subsections describe the fields that are part of or
directly relevant to the ULEsec header. All encoded numbers are in
network byte order.
2.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.
Two different type values are defined. The first one, denoted simply
ULEsec, SHOULD be used when receiver devices can uniquely identify
Security Associations (SAs) based on MPEG-2 TS Program Identifiers
(PIDs) and SNDU destination addresses solely. The second type,
denoted ULEsec_ID, MUST be used, when PIDs and destination addresses
alone are not sufficient to look up SAs. In this case, the VPN-ID
field will be present, which is described next.
2.2. VPN-ID field
This 16-bit field is present when the ULEsec_ID Type is chosen. It
can be viewed as a Security Parameter Index (SPI) as of IPsec
implementations [RFC4301], but more adequately simply represents a
Virtual Private Network (VPN) identifier. See above to decide when to
use this field.
2.3. Key (K) bit
This mandatory bit provides for an easy way of detecting a key
update. Whenever ULE sender (i.e., ULE encapsulator) devices switch
to new keys, they flip this bit. This enables receivers to find out
which of two concurrently defined set of keys (the current/old ones,
or the new ones) are to be used for decoding.
New keys will be issued within key management messages by a Group
Controller and Key Server (GCKS), which may or may not physically
reside with a ULE sender. After each key update, devices MUST wait
for a policy-defined amount of time before they permit switching to
new keys again. This is necessary to avoid collisions between
different keys on SNDUs sent with the same K bit. This can happen
either because a receiver still accepts old keys (see section 4.3),
or because a device has missed all key management messages during two
periods of key updates. To avoid the latter, a GCKS may periodically
send out key management messages with the key currently in use (see
section 5.1).
Noisternig Expires January 14, 2009 [Page 7]
Internet-Draft A lightweight security extension for ULE July 2008
2.4. Sequence Number
The mandatory Sequence Number field serves two purposes. First, it is
part of the nonce required for the default encryption algorithm.
Second, it is used for the replay protection service.
The default size of the Sequence Number field is 31 bits. This MAY be
extended to 63 bits when configured as such by a Security Policy (SP)
or via negotiation within a key management protocol. The larger size
MUST be used when no automated key management is available.
2.5. Encrypted Destination Address field
This field is only present if the identity protection service is used
(determined by the SPs selected). In that case, SNDUs do not contain
a 48-bit NPA destination address in the ULE base header (i.e., they
have the D bit set to 1), but the address will appear in the security
extension header's Encrypted Destination Address field instead, where
it will be encrypted subsequently (along with the payload data).
2.6. PDU Type field
This mandatory 16-bit field designates the type of the PDU or the
next extension header in the header chain.
2.7. MAC field
The security extension header has an optional (SP-configured) trailer
that follows the PDU data and contains the Message Authentication
Code (MAC) of the SNDU. This MAC SHOULD have a default length of 12
octets.
3. Security Algorithms
This section specifies a set of mandatory default security algorithms
to be used in conjunction with the ULEsec header. These algorithms
are lightweight in the sense that the only cryptographic primitive
required is the Advanced Encryption Standard (AES) [AES] with a key
size of 128 bits, denoted AES-128 in short, and only its encryption
part is used.
Implementation of default security algorithms is REQUIRED.
Within the following subsections, AES_mk(value) means AES-128
encryption of the 128-bit value using the master key mk, value[x..y]
means taking value's bits x to y, || denotes concatenation, and x^y
Noisternig Expires January 14, 2009 [Page 8]
Internet-Draft A lightweight security extension for ULE July 2008
means that bit x is to be repeated y times. All encoded numbers are
in network byte order.
3.1. Key Derivation
In order to minimize transmission overhead within a key management
protocol and to ease the setup of manual keys, separate encryption
and authentication keys are derived from a single master key. The
derived keys are computed as follows:
encr_key = AES_mk ( Salt || 0^64 )
auth_key = AES_mk ( Salt || 0^63 || 1 )
The Salt is a 64-bit value that MUST be an unpredictable value for
adversaries. It will be transmitted along with the master key either
explicitly or implicitly (e.g., derived from nonces used within the
key management protocol). Including the Salt in the key derivation
process preserves full security of the master key in case of
compromise of any derived key against an adversary using pre-
computation techniques.
3.2. Encryption
Using encryption spoils an adversary's attempt of finding out
information transmitted via eavesdropping. By encoding all data
following a security extension header's Sequence Number field up to
but not including the MAC field, confidentiality is provided for
SNDUs' payload data as well as any extension headers succeeding a
security header.
Encryption is performed by employing AES-128 in the Counter (CTR)
mode of operation, which is specified in [Modes], and using the
encr_key defined in subsection 3.1.
The CTR mode requires a Nonce as part of its input. It is a 128-bit
value and derived per packet from a 64-bit random value (Salt) that
is distributed along with the master key, the 13-bit Program
Identifier (PID) the underlying MPEG-2 TS cell originated from, and
the ULEsec header's K bit and Sequence Number as follows:
Nonce = Salt || K || Sequence Number || 0^3 || PID || 0^16.
When 63-bit sequence numbers are used, the Nonce is computed as such:
Nonce = Salt[63..32] || Salt[31] XOR K || Salt[30..0] XOR Sequence
Number[62..32] || Sequence Number[31..0] || 0^3 || PID || 0^16.
Noisternig Expires January 14, 2009 [Page 9]
Internet-Draft A lightweight security extension for ULE July 2008
The Salt is the same as that of subsection 3.1, which primarily means
that it be an unpredictable value for adversaries. Again, its purpose
is to thwart pre-computation attacks.
Special care has to be taken when PID re-mapping can occur (typically
within a multiplexer on a DVB network boundary [MPEG2]), as a
receiver will not be able to decrypt the data successfully when using
a PID value different from the sender. For one-sender scenarios where
the sender also acts as the key server, a simple solution to inform
receivers about such PID re-mapping may be to include the originating
PID within the key management messages.
3.3. Identity Protection
For additional protection against traffic flow analysis, the ULE link
layer addresses may be hidden using the identity protection service.
For this, a sender omits the 48-bit NPA destination address from the
ULE base header, sets the D bit, and places the address into the
extension header's Encrypted Destination Address field instead, where
it will be encrypted subsequently (along with the payload data). A
receiver will detect an SNDU destined to it simply by probing (i.e.,
trial-decryption).
Identity protection has the following properties:
o There is no need to store or transmit any additional information
(besides that the identity protection service is requested).
Particularly, there is no need for a central server to manage or
distribute addresses used specifically for this service.
o An adversary not in the know of a matching encryption key will not
be able to read an SNDU's NPA destination address.
o A legitimate receiver will correctly decode the address with very
high probability. In detail, the probability that an SNDU is
mistakenly accepted is given approximately by k*10^-14.4, where k
is the receiver's number of keys that do not match. Note that this
is close to typical packet-error ratios on the ULE link for small
k, which is between 10^-15.5 and 10^-16.8 on a quasi-error-free
channel.
o For even lower false-acceptance rates, the authentication
mechanism may be used. A MAC of size t bits will decrease the
probability of erroneously accepting a SNDU with a wrong key by
the factor 2^-t.
Noisternig Expires January 14, 2009 [Page 10]
Internet-Draft A lightweight security extension for ULE July 2008
Two typical use cases for this service are sketched. In the first
one, each receiver device has one distinct key to protect its unicast
data. In this case, a receiver will not miss any data destined to it,
and will mistakenly accept other SNDUs with negligible probability
(k=1).
In the second case, all sender and receiver devices on a PID use a
single shared key to protect their data, forming a VPN. Within such
VPN, all devices can correctly decode all addresses (k=0).
Note that while identity protection could be used for unicast as well
as multicast settings, it is sensible only for unicast communication,
and as such - and in order to keep the number of mismatching keys low
- should not be used for multicast scenarios.
Identity Protection MUST NOT be used without the data confidentiality
service (section 3.2).
3.4. Authentication and Integrity Protection
As a mechanism against active attacks, SNDUs may carry a Message
Authentication Code (MAC). A MAC provides integrity protection and
source authentication for unicast connections as well as other
single-sender settings. When there is more than one sender, such as
in peer-to-peer settings, or when there is a possibility that a
receiver in the know of the shared key might act as a sender, this
mechanism gets reduced to group authentication. This is regarded
sufficient, however, as attacks are primarily expected from outside
(i.e., from adversaries not in the know of the right keys) [ULEsec-
Req].
This construction of the MAC is based on the Cipher Block Chaining
(CBC) mode of operation [Modes], and is commonly known as a (plain)
CBC-MAC, which is computed as follows:
1. The SNDU, excluding the CRC and the MAC field, is first internally
right-padded with zeros to an integral multiple of the cipher's
block length (128 bits for AES), if necessary.
2. This padded data is then internally encrypted with AES-128 in CBC
mode using the auth_key defined in subsection 3.1, and an
Initialization Vector (IV) of 0.
3. The final output block of the encryption step resembles the full-
length MAC whose least-significant bits are then truncated to
receive the MAC of desired length.
Noisternig Expires January 14, 2009 [Page 11]
Internet-Draft A lightweight security extension for ULE July 2008
The CBC-MAC based on AES is fully secure up to 98 bits, or about 12
octets, when used with the default sequence number space of 2^31. 12
octets is the "standard" authentication length for the IPsec
protocols, and should be used as a default for ULEsec, too.
When extended (63-bit) sequence numbers are used, a block cipher with
larger block size should be chosen. It is advised to take the
Rijndael algorithm [Rijndael] with a block size of 256 bits as a
superset of AES.
3.5. Replay Protection
Upon switching to a new set of keys, senders and receivers will set
its sequence numbers to be sent or accepted next for a Security
Association (SA) to the value 0. A sender will increment a sender-
side sequence number by 1 after each SNDU transmitted, independently
of whether replay protection is used or not. A receiver, using replay
protection, will only accept SNDUs with a receiver-side sequence
number higher than the last one accepted. Detailed processing
descriptions regarding this service are given in section 4.
Note that replay protection using sequence numbers only works for the
one-sender scenario due to the difficulty of synchronizing replay
state among multiple senders. As such, this service MUST NOT be used
when there is multiple legitimate senders or legitimate receivers
acting as senders for a SA. Also, it SHOULD NOT be used when keys are
set up manually, as a sender would have to remember its sequence
number state across reboots.
4. Security Extension Header Processing
4.1. Preliminaries
Within the next subsections, the following terms are used to simplify
wording:
o Basic (Policy) Selector: a pair of destination NPA address and PID
value.
o Receiver-Side (Policy) Selector: a Basic (Policy) Selector with
the optional VPN-ID value.
o Sender-Side (Policy) Selector: a Basic (Policy) Selector,
optionally extended by higher-layer selector data, such as IP
addresses, TCP ports, etc.
The term (Policy) Selector is used interchangeably for those above.
Noisternig Expires January 14, 2009 [Page 12]
Internet-Draft A lightweight security extension for ULE July 2008
4.1.1. Security Policy Database (SPD)
Senders and receivers define policies describing the security
services required or permitted for outgoing and incoming data. The
collection of such Security Policies (SPs) is referred to as the
Security Policy Database (SPD).
For both outgoing and incoming data, a SPD contains an ordered list
of SPs. Each SP MUST contain the following information:
o A set of Sender-Side or Receiver-Side Policy Selectors (for
outgoing or incoming data respectively), defining the
applicability of this SP. To simplify parsing, this set MUST be
encoded as a single Selector together with a Selector Mask.
o Information about the SA(s) to be instantiated by this SP. This
contains:
o A set of subsets of above Policy Selectors, downgraded to Basic
Policy Selectors (i.e., only the address and PID are taken).
Each subset together with the optional VPN-ID value constitutes
a SA Selector, which is used for looking up or creating a
Security Association (SA) within the Security Association
Database (SAD) (see next section 4.1.2). To simplify parsing, a
single Basic Selector Mask MUST be stored, denoted SA Selector
Mask, from which the set of subsets is derived.
o An optional VPN-ID value, part of the SA Selector. If defined,
a sender MUST use this value within the VPN-ID field of the
ULEsec_ID extension header type.
o Optional Group Controller and Key Server (GCKS) data, specified
by an optional destination address and a (possibly empty set
of) PID(s). A device MAY use the PID(s) as a first check for
legitimacy of key management messages from a certain source.
When a destination address is defined, it MUST be used to
contact the GCKS for membership request on receiving a
protected SNDU for which this SP matches, and when the SP does
not contain default key data in its first set of Security
Parameters.
Noisternig Expires January 14, 2009 [Page 13]
Internet-Draft A lightweight security extension for ULE July 2008
o An ordered list of Security Parameter sets used for
instantiating a SA, sorted according to preference. A Security
Parameter set MUST allow having no security services selected
at all, which MUST be interpreted as sending or receiving data
without protection (i.e., SNDUs without a security extension
header). A sender MUST default to the first entry in the list,
unless a key management protocol permits negotiation (e.g., for
unicast, bidirectional settings) and a receiver contacts the
GCKS to request another set of Security Parameters from the
list. Each set of Security Parameters MUST contain information
about:
o The cryptographic algorithms used.
o The cryptographic parameters required by these algorithms
(e.g., the MAC length).
o The length of the sequence number field.
o Optional key data for manual keying: a master key, and an
optional Salt.
SPs may be manually set up by the owner of the sender or receiver
equipment, or dynamically distributed via a GCKS (using a key
management protocol). While the resulting SPD may become complex by
containing separate SPs for each pair of PID and NPA address data may
be sent to or received from, in general it is expected to contain
just a few entries.
This document does not define how to store, manage, and look up SPs
within the SPD, as this is regarded implementation specific details.
4.1.2. Security Association Database (SAD)
A Security Association (SA) is an instantiation of a SP. It describes
the current state of a secure connection between two or more devices.
All devices sharing a SA are part of the same VPN. The set of SAs of
a device is aggregated in the Security Association Database (SAD).
A SA MUST contain the following information:
o The SA Selector derived from the instantiating SP.
o Any GCKS data defined by the SP and the GCKS.
o Static security parameters defined by the SP (cryptographic
algorithms, MAC length, Sequence Number length, etc.).
Noisternig Expires January 14, 2009 [Page 14]
Internet-Draft A lightweight security extension for ULE July 2008
o Current and prospective dynamic security parameters (keys, Salt,
etc.), defined by the SP or the GCKS.
o The current sender-side K bit and sequence number for transmitting
data.
o The current receiver-side K bit for receiving data, and the
current receiver-side sequence number for receiving data with
replay protection.
o A flag defining whether prospective security parameters have been
received through a GCKS.
As with the SPD, this document does not define how to store, manage,
and look up SAs within the SAD.
Noisternig Expires January 14, 2009 [Page 15]
Internet-Draft A lightweight security extension for ULE July 2008
4.2. Sender Processing
4.2.1. General Activity Diagram
+-----------------+
| 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 | |
| | +-----------------+ fresh key | +-----------------+ |
| | | check keys |------------------->| switch keys | |
| | +-----------------+ available? | +-----------------+ |
| | | | | |
| | v | +------------+ |
| | +-----------------+ seq.nr. | | |
| | | check seq.nr. |-----------------------------+-----------+
| | +-----------------+ overflow? | | v
| | | expected | | +-----------------+
| | +---------------------------->|get key from GCKS|
| | | seq.nr. overflow? | | +-----------------+
| | v | | v failure?
| | +-----------------+ | | +-----------------+
| +->| construct SNDU |<-----------+ | | log event |
| | & transmit |<---------------+ +-----------------+
| +-----------------+
| v
| +-----------------+
| | update SA |
| +-----------------+
| |
+--------------+
4.2.2. Detailed Processing Description
The following list describes the processing steps for a ULE
encapsulator implementing the ULE security extension (ULEsec sender
in short):
Noisternig Expires January 14, 2009 [Page 16]
Internet-Draft A lightweight security extension for ULE July 2008
1. Get SP: After receiving a PDU from upper layers for transmission
over the ULE link, a ULEsec sender MUST consult its SPD by
scanning the ordered list of outgoing SPs until it finds a
matching policy. That is, it looks for a SP for which
(SP's Sender-Side Selector AND SP's Selector Mask)
== (SNDU's Sender-Side Selector AND SP's Selector Mask)
is true. If no such policy can be found, the data MUST be
discarded, and this event SHOULD be logged as an invalid
transmission attempt.
2. Get SA: With a SP chosen, a SA Selector is constructed as a
triple:
SA Selector := (SNDU's Basic Selector AND SP's SA Selector Mask,
SP's SA Selector Mask, SP's VPN-ID value)
The VPN-ID value, if not defined by the SP, must be set to a
reserved "null" value (i.e., a fixed value not within the 16-bit
number range of the extension header's VPN-ID field).
The SA Selector is then used to look up a SA within the SAD. If no
SA is found, it must be set up as follows: If the SP's first
Security Parameter set either contains default key data (master
key, optional Salt, etc.) or defines data to be sent without
protection, the SA is immediately created and initialized
according to these settings. Otherwise, if the SP defines a GCKS
destination address, the server MUST be contacted for obtaining
key material. During that attempt the sender SHOULD postpone or
discard transmission of the data. Any case of failure MUST result
in the data being discarded, and this SHOULD be logged accordingly
(e.g., as a user authentication failure in case of membership
denial by the GCKS).
3. Check keys: Whenever a SA is provided with fresh key material, a
sender MUST switch to the new set of keys after a policy-defined
length or point of time, and prior to a sequence number overflow
(see next step). This is done by flipping the SA's sender-side K
bit and resetting the sender-side sequence number to 0, while
selecting the fresh key material as the new current one for
sending. Note that a SA that is also used for receiving SNDUs may
still require the older set of keys as a receiver-side K bit will
be flipped at a later (policy-defined) point of time. This is to
compensate differences in key update times of multiple senders,
which means there will be a period during which some devices will
Noisternig Expires January 14, 2009 [Page 17]
Internet-Draft A lightweight security extension for ULE July 2008
already send with new keys while others will still use the old
ones.
4. Check sequence number: An implementation MUST NOT allow a SA's
sender-side sequence number to overflow. For a SA defining a GCKS
destination address, an implementation MUST contact the server for
obtaining fresh key material in anticipation of this event. When
keys are set up manually, the user SHOULD be warned about an
expected overflow. Should eventual transmission of an SNDU ever
result in the sequence number to overflow, the data MUST be
discarded instead, and this event SHOULD be logged as a sequence
number overflow event.
5. Construct SNDU: For a SA that allows passing data unprotected, the
SNDU is constructed as usual. Otherwise, it 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 MUST be
omitted from the base header (with the D bit set to 1). If a
VPN-ID value is defined within the SA, the last extension
header's (or base header's) Type field MUST contain the value
for a ULEsec_ID extension header; otherwise, it contains the
ULEsec extension header value.
b. For the ULEsec_ID extension header, the 16-bit VPN-ID field is
written.
c. Next, the SA's sender-side K bit and sequence number are
filled into the extension header's mandatory K Bit and
Sequence Number fields. The length of the Sequence Number
field is defined by the SA.
d. For the identity protection service, the destination NPA is
encoded as defined by the SA, which means it will be encrypted
along with any subsequent extension headers and the payload
data for the default identity protection algorithm.
e. Subsequently, the mandatory (Encrypted) Type field, any other
extension headers, and the PDU are encoded as defined by the
encryption algorithm selected.
f. For authentication, a MAC of length as defined by the SA is
appended. The MAC is computed over all the data encoded so
far, which means, from the start of the SNDU to the end of the
payload data.
Noisternig Expires January 14, 2009 [Page 18]
Internet-Draft A lightweight security extension for ULE July 2008
g. Finally, the CRC is calculated and appended, and the SNDU
further processed according to [RFC4326].
6. Update SA: After processing a protected SNDU is completed, a
sender MUST increment the SA's sender-side sequence number by 1.
Noisternig Expires January 14, 2009 [Page 19]
Internet-Draft A lightweight security extension for ULE July 2008
4.3. Receiver Processing
4.3.1. General Activity Diagram
+-----------------+
| receive SNDU | +-----------------+
+---->| from MPEG layer |<-------------------| discard SNDU |
| +-----------------+ +-----------------+
| v ^
| +-----------------+ decoding |
| |decode headers up| error? +-----------------+
| |to security ext. |------------------->| log event |<-+
| +-----------------+ +-----------------+ |
| | ^ ^ ^ ^ |
| | +-----------------------------+ | | | |
| v | not found/not permitted? | | | |
| +-----------------+ | | | |
| +--| get SP |<----------------------+ | | +-----+ |
| | +-----------------+ no match? | | | | |
| |permit. |permitted (SNDU w/o address)| | | | |
| |w/o |w/ | | | | |
| |sec. |sec. +-----------------------------|--+ | | |
| |ext. |ext. | id.prot. mismatch? | | | |
| | v | (SNDU w/ address) | |failure?| |
| | +-----------------+ +-----------------+ | |
| | | get SA(s) |---------------->| create SA | | |
| | +-----------------+ not found? +-----------------+ | |
| | | | success? | |
| | | +--------------------------------+ | |
| | v v | |
| | +-----------------+ not found? +-----------------+ | |
| | | select key |----------->|get key from GCKS|-------+ |
| | +-----------------+ +-----------------+ failure? |
| | | |success? |
| | | +---------------------------+ |
| | v v |
| | +-----------------+ |
| +->| decode SNDU | decoding/authentication/replay error? |
| | & pass to L3 |-----------------------------------------+
| +-----------------+
| v
| +-----------------+
| | update SA |
| +-----------------+
| |
+--------------+
Noisternig Expires January 14, 2009 [Page 20]
Internet-Draft A lightweight security extension for ULE July 2008
4.3.2. Detailed Processing Description
A receiver implementing the ULE security extension (ULEsec receiver
in short) must follow below procedure upon reception of a ULE SNDU:
1. Decode SNDU (1): The SNDU is checked for a correct CRC as
described in [RFC4326], after which the base header and the
extension headers up to either a security extension header or the
PDU are evaluated. From the base header, a Basic Policy Selector
is constructed. This one is extended to a Receiver-Side Policy
Selector by adding the VPN-ID field of a ULEsec_ID Type security
extension header, when encountered.
2. Get SP: After the SNDU passed the first filtering and evaluation
step, the SPD's ordered list of incoming policies is scanned for a
matching policy.
a. D=0: With the SNDU's D bit cleared, the following check must
be true for selecting a SP:
(SP's Receiver-Side Selector AND SP's Selector Mask)
== (SNDU's Receiver-Side Selector AND SP's Selector Mask).
If no matching policy can be found, the data MUST be discarded
immediately, and this event SHOULD be logged as reception of
an invalid SNDU.
b. D=1: When the D bit is set, above check is done as well,
except that the destination NPA address values are ignored.
If no matching policy can be found, the data MUST be discarded
immediately, and this event MAY be logged as reception of an
invalid SNDU.
If the SNDU is received without a security extension header but
the SP does not permit unprotected data to pass, the SNDU MUST be
discarded immediately, and this event SHOULD be logged as
reception of an invalid SNDU. Likewise, if there is a security
extension header but the policy allows only for unprotected data,
the SNDU MUST be discarded, and this event SHOULD be logged.
When permitted, an SNDU without a security extension header is
decoded as usually. For a protected SNDU, processing continues
with step 3.
3. Get SA: With a first match on a SP, a SA Selector is constructed
to find a SA within the SAD.
Noisternig Expires January 14, 2009 [Page 21]
Internet-Draft A lightweight security extension for ULE July 2008
a. D=0: With a destination address present, the following SA
Selector is used to directly look up a SA within the SAD:
SA Selector := (SNDU's Basic Selector data AND SP's SA
Selector Mask, SP's SA Selector Mask, SNDU's VPN-ID value)
The VPN-ID value must be set to a reserved value if not
defined by a ULEsec_ID header.
If no SA is found, it must be tried to set it up as described
in step 2 of section 4.2, Sender Processing. If creation of a
SA fails, the SNDU MUST be discarded, and this SHOULD be
logged accordingly.
b. D=1: With the D bit set, a set of SAs is looked up by omitting
the destination address:
SA Selector := (SNDU's PID AND SP's SA Selector Mask's PID,
SP's SA Selector Mask, SNDU's VPN-ID value)
From the retrieved set, every SA not defining identity
protection is ignored. Assuming the remaining set is not
empty, the K Bit and Encrypted Destination Address field are
read ahead from the security extension header. The current
key, as defined by the K Bit (see next step), is then taken
from the first SA in the set to trial-decrypt the Encryption
Destination Address field (i.e., it is decrypted to a
temporary buffer). The decrypted address MUST be checked to
match both the SP selected as well as belong to the current
SA. Then, it MUST be compared with all destination NPA
addresses a receiver accepts to look for a match. If either a
SA does not contain the current key, or there is no match for
an address, the SA is removed from the retrieved set, and
probing is done with the next one.
If no SA matches, but the SP defines default key data as well
as the identity protection service for the first set of
Security Parameters, the encryption key derived from the
default key data is used for probing with the SNDU as
described in above paragraph. (Because of this, receiver-side
SPs containing default key material SHOULD already provide
derived keys for efficiency reasons.) If this test succeeds, a
SA is constructed using the SP's first Security Parameter set;
if SA creation fails (e.g., due to out-of-memory conditions),
the SNDU MUST be discarded, and this SHOULD be logged
accordingly.
Noisternig Expires January 14, 2009 [Page 22]
Internet-Draft A lightweight security extension for ULE July 2008
When no matching SA can be found, the SP is assumed to be
selected mistakenly, and processing MUST continue at step 2.b
with the next SP in the list of incoming SPs.
4. Select key: Once a matching SA is found, proper keys must be
looked up. For this, the SNDU's K bit is compared with the SA's
receiver-side one. If they are equal, the SA's current keys are
taken for decoding. Otherwise, the SA's prospective keys must be
selected. If these are not defined, the SNDU MUST be discarded and
this event SHOULD be logged as reception of an invalid SNDU. A
receiver SA, when provided with prospective keys, must switch to
these after a policy-defined point or amount of time by flipping
its receiver-side K bit and replacing the current keys with the
fresh ones.
5. Decode SNDU (2):
a. Authenticate SNDU: For verifying authenticity and integrity, a
MAC is computed as defined for the sender side, and then
compared with the value of the SNDU's MAC field for equality.
If the two values differ, the SNDU MUST be discarded, and this
SHOULD be logged as a data authentication failure.
b. Replay Protection: To detect replays, the SNDU's Sequence
Number MUST be greater than or equal to the SA's receiver-side
sequence number; if this is not the case, the SNDU MUST be
discarded, and this event SHOULD be logged as a replay.
c. Decryption: If the data confidentiality service is used, all
data starting from the security extension header's Encrypted
Type field up to the end of the PDU data are decrypted. After
that, processing continues as normally (i.e., any other
extension headers are evaluated, and the PDU is finally passed
to upper protocol layers).
6. Update SA: Now that the SNDU has been accepted, a SA using replay
protection must be updated accordingly: If the K bits of step 4
were differing, keys are switched immediately as described in that
step; then, the SA's receiver-side sequence number is set to the
SNDU's Sequence Number value, and incremented by 1.
5. Key Management Considerations
Manual key setup is simple but practical only for small and
relatively static secure groups. When number of receivers gets high,
or users need to be added or excluded more frequently, automated key
management becomes necessary. A Group Controller and Key Server
Noisternig Expires January 14, 2009 [Page 23]
Internet-Draft A lightweight security extension for ULE July 2008
(GCKS) uses a key management protocol to automatically distribute key
material to legitimate devices in the event of new membership,
revoking of users, or key update (either periodically for increased
security, or after a security breach). The definition or selection of
any particular key management protocol is out of scope for this
document as doing so has no influence on extension header format,
security algorithms, or extension header processing. However, some
important considerations are discussed next, and one must distinguish
between the two different scenarios of unidirectional and
bidirectional communication.
5.1. Unidirectional Key Management
In unidirectional settings, security parameters can merely be decided
by the sender. Having no way for negotiation, this allows for a
simpler protocol design in this regard. However, other issues arise.
Senders must assure reliable delivery of information to all
receivers. Doing so might require sending the same data multiple
times. Receivers must be able to jump into a session at any time and
without substantial delays, either when they are turned on, or after
loss of synchronization. Replay attacks must be considered. They are
best countered with timestamps; however, this requires sender and
receivers to have synchronized clocks.
The design of a unidirectional key management protocol should allow
installing, updating, and revoking a number of different keys within
receiver devices, with new keys encrypted with any other one.
Different keys can correspond to individual, group, or global keys.
This flexibility will allow the use of various broadcast encryption
algorithms (such as the subset difference scheme [Subset]).
It is further suggested that a unidirectional key management protocol
uses the same format for re-key messages as for the initial key
distribution. In other words, re-keys should provide all the
information necessary to allow receivers to jump into the middle of a
session, which shall result in great aid for connectivity.
Existing mechanisms should be evaluated, such as [DVB-CA] and [ATSC-
CA]. For example, [DVB-CA] defines unidirectional key management in
the form of the entitlement checking and entitlement management
messages. This offers a simple mechanism for securely establishing,
updating, and revoking keys. A 3-level key hierarchy is used to
provide for a better level of safety in case of key compromise.
However, the single first-level key remains unchanged, constituting a
weakness in this system; this could be mitigated in a protocol for
the ULE security extension by either configuring receiver devices
with unique sets of first level keys, thereby allowing true broadcast
Noisternig Expires January 14, 2009 [Page 24]
Internet-Draft A lightweight security extension for ULE July 2008
encryption algorithms such as [Subset], or by permitting operators of
a VPN to update first level keys externally of the ULE network
(either manually or automatically).
5.2. Bidirectional Key Management
The availability of a back channel allows devices not only to
actively request group membership, revocation, and retransmission of
keys after loss of synchronization. Negotiation of cryptographic
algorithms and keys becomes possible, as well as enhanced security
features such as perfect forward secrecy, mutual authentication, and
identity protection when receivers are identified by other means than
their NPA address.
In contrast to unidirectional key management, numerous bidirectional
protocols have been developed for various layers of the ISO/OSI
reference model. Prominent examples include [DVB-RCS] (link layer),
IKEv2/IPsec [RFC4306] (network layer), TLS [RFC4346] (transport
layer) and SSH [RFC4253] (application layer). Naturally, they differ
highly in purpose, functionality, and complexity. While existing link
layer technology such as those within [DVB-RCS] is probably most
directly usable for ULE, requirements for bidirectional key
management must be clearly determined.
Traditional key management protocols, including the ones cited above,
are designed for unicast communication, only. ULE key management must
support VPN-like settings with a potentially large number of
receivers. One focus of the IETF MSEC working group is on developing
and standardizing scalable solutions for key management within large
groups, and several different protocols have been proposed [RFC4535,
RFC3547, GKDP, FMKE, RFC3830]). Clearly, these must be considered
when defining ULE key management.
6. Security Considerations
The security of cryptography-based systems depends in one part on the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The algorithms identified in
this document are not known to be broken at the current time, and
research so far leads to believe that the combination of algorithms
and key lengths specified within this document will likely remain
secure into the foreseeable future. Considerations that relate to
this aspect, including the correct use of algorithms, are addressed
in their respective sections or the appendices of this document.
There is a caveat regarding the security extension's Sequence Number
field when a SA secures communication for a single receiver device
Noisternig Expires January 14, 2009 [Page 25]
Internet-Draft A lightweight security extension for ULE July 2008
(i.e. for unicast communication) and the identity protection service
is used. A passive attacker may link SNDUs with increasing sequence
number to the same SA, thereby increasing its chance of identifying a
receiver and the amount and type of data transmitted to it. Future
research will investigate on possible solutions for this problem.
The security also depends on the engineering and administration of
the protocols used by the system to ensure that there are no non-
cryptographic ways to bypass security. When selecting a key
management protocol, its security will be a pre-requirement for
overall system security.
ULE link layer security may not be treated as a replacement for end-
to-end security. If reliable security is required, one MUST use end-
to-end security protocols. However, ULE link layer security can
complement end-to-end security as laid out in the conclusions in
section 8.
7. IANA Considerations
This document requires two 16-bit Type codes to be registered by the
IANA, namely one for the ULEsec security extension, and one for the
ULEsec_ID extension header type. It is suggested that the two Type
codes are allocated in a way that they differ only in their least-
significant bit. This allows use of this bit as a flag for
determining the presence of the VPN-ID field. (However, this is
merely an optimization and no requirement.)
8. Conclusions
The solution presented within this document addresses many of the
security requirements for the ULE protocol laid out in the separate
security requirements document. Passive attacks, constituting the
most important threats in the ULE network, are effectively defeated
using the data confidentiality and identity protection service. To
mitigate active attacks, MACs may be used to assure a receiver of the
authenticity and integrity of the data received. While not providing
source authentication for VPN-like settings with multiple senders,
they still render outsider attacks futile. Sequence numbers within
each SNDU allow for simple detection of replayed data on unicast
connections, without any additional bandwidth overhead.
The format of the security extension header generates minimal
bandwidth overhead, is extensible, and acts as a framework for a set
of security transforms that may be changed and updated independently
of each other. Default algorithms are defined to be lightweight and
allow implementation in low-cost devices.
Noisternig Expires January 14, 2009 [Page 26]
Internet-Draft A lightweight security extension for ULE July 2008
A key management protocol may be added later and independently of
this specification. This will allow more flexibility and security in
setting up secure connections and VPNs. Existing protocols such as
those following the guidelines of [RFC4046] might be used. However,
this will need careful assessment regarding the applicability for the
ULE link.
Note that the presented ULE security extension secures the ULE
broadcast link, only, and as such may not be treated as a replacement
for end-to-end security. In fact, ULE link layer security is an
additional security mechanism that complements end-to-end security
[ULEsec-Req]. Where end-to-end security is used, it can provide
identity protection over the ULE link in addition. When the ULE link
is used to directly connect two secure sites, ULEsec can be the sole
provider of security. In the cases where end-to-end security is not
applicable, the ULE security extension can be viewed as protecting
the weakest link, and a user can rely on security assumptions as of
wired links.
9. Acknowledgments
The document was prepared using 2-Word-v2.0.template.dot.
Noisternig Expires January 14, 2009 [Page 27]
Internet-Draft A lightweight security extension for ULE July 2008
APPENDIX A: Rationale for the Extension Header Format
A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI
In order to identify which secure connection (represented by a SA) a
secured packet belongs to, it is generally marked with a connection
identifier. For the IPsec [RFC4301] security protocols, this
identifier is known as the Security Parameter Index (SPI). It is
selected by the receiver, only, in order to avoid collisions between
different connections. This works because IPsec is designed for
secure unicast communication only. For multicast settings, a manually
assigned SPI together with manual keying can be used. The same
principle of deriving a secure connection identifier can be used with
the ULE security extension, too. Instead of an SPI, the ULE security
extension provides the VPN-ID field, when the ULEsec_ID security
extension header type is used.
One difference between IPsec and ULEsec is that IPsec is an end-to-
end security protocol. This means that on a single ULE link a ULE
decapsulator will potentially accept data from many different (IPsec)
end-to-end connections. In contrast, at the ULE link layer users are
expected to establish just a single or otherwise so few secure L2
connections that in many cases receivers can even identify
connections based on ULE destination NPA addresses and MPEG-2 TS PID
values alone. Therefore, a size of 16 bits has been chosen for the
ULEsec VPN-ID field as opposed to 32 bits as used for the SPI of the
IPsec security protocols. In addition, it is provided for a way to
omit the VPN-ID field altogether (by selecting the ULEsec extension
header type).
A.2. VPN-ID + K-Bit vs. SPI
The way re-keying works in the IPsec protocols is by creating a new
SA (i.e., secure connection) for the new keys. The new SA will have a
different SPI value than the old one, selected by the receiver again.
This model does not work for ULE, however. A receiver that failed to
receive key update messages will have no way of determining that the
new data with a different secure connection identifier is to be
received by him. This is not only an issue for multicast settings
where scalability is a concern, but also for unidirectional links
where there is no way for feedback. Instead, ULEsec uses the K Bit to
signal when re-keying occurred, and keeps the VPN-ID value constant.
Now a receiver will always know which data to accept, and it would
have to lose key management messages during two periods of key
updates for this model to fail.
Noisternig Expires January 14, 2009 [Page 28]
Internet-Draft A lightweight security extension for ULE July 2008
A.3. 31-bit/63-bit Sequence Number
A 31-bit sequence number has been chosen as a default as it does not
add too much overhead and is reasonably big for automated re-keying
to happen infrequently. For example, when SNDUs are continuously sent
on a link with an effective bit rate as high as 68 Mbit/s [DVB-S],
protected under the same key, and contain only TCP/IP acknowledgments
so the SNDU size is just 60 octets (20 octets ULE+ULEsec header, 20
octets IP header, and 20 octets TCP header), then a key can still be
used for more than four hours before the 31-bit sequence number space
will be exhausted.
For high-speed links, and when manual keying is used, the larger 63-
bit sequence numbers are to be used. This pairs well with a key size
of 128 bits for the encryption algorithm, where after 2^63 uses
security will be about halved and new keys should be set up by then.
While the Sequence Number field could be optional, too, its placement
has been made mandatory in order to not unnecessarily complicate
things, and since it is required virtually always, anyway. It could
be replaced with a timestamp, though, but this is not defined within
this specification.
A.4. MAC field
The MAC field is not a direct part of the security extension header,
but defined as a trailer. This allows the MAC to be computed in an
online way. For example, a sender can compute the MAC of an SNDU
while it is already transmitting it, and when it has sent the last
bit of the payload it can simply attach the MAC.
For a similar reason, the CRC, which can be viewed as part of the ULE
base header, is at the end of the SNDU.
Noisternig Expires January 14, 2009 [Page 29]
Internet-Draft A lightweight security extension for ULE July 2008
APPENDIX B: Rationale for the Default Security Algorithms
B.1. Encryption
The first question on the data confidentiality service is whether to
use a block cipher or a stream cipher algorithm. Stream ciphers offer
the benefit of allowing for very simple and fast implementations. One
particular stream cipher is the Arcfour (or RC4) algorithm [Arcfour],
and it can be regarded the de-facto standard among software based
implementations. However, several weaknesses have been found so far,
and while there are ways to circumvent some of them, they do not make
Arcfour a favorable choice [Arcfour-Fix]. Unfortunately, other stream
ciphers available are either not sufficiently analyzed, or are based
on linear feedback shift registers, making them suitable for cheap
hardware implementations but vulnerable to algebraic attacks.
Among block ciphers, things are looking much better. The Advanced
Encryption Standard (AES) [AES] has been quickly embraced as a
secure, fast, and open encryption algorithm since its election within
a competition held by the American NIST in the year 2000 to replace
the aging DES. Despite algebraic structures found, AES is still
considered secure.
A mode of operation is required for a block cipher to allow it to be
repeatedly used securely under the same key. NIST has standardized
several such modes [Modes]. One particular mode is the Cipher Block
Chaining (CBC) mode. It is well-understood and has good security
properties. However, it operates on full blocks only, and data must
therefore be padded to multiples of block lengths in general. In
addition, the CBC mode requires an explicit (pseudo-)random
Initialization Vector (IV) of the size of a cipher block for each
packet. This is clearly wasteful for the ULE scenario, where this
means additional average overhead of 24 octets per SNDU when used
with AES.
The Counter (CTR) mode in contrast effectively turns the block cipher
into a stream cipher, so there is no need for padding. IVs for this
mode come as nonces, so a simple counter may be used. A counter can
not only be encoded in less space than the size of a cipher block, it
may also serve as a mechanism for replay protection - in which case
no space will be wasted at all. Some of the other advantages of the
CTR mode are that only the encryption part of the block cipher
algorithm is needed, and both encryption and decryption can be
parallelized.
Strong care must be taken for the nonces to never be used twice under
the same key, or all security will be lost. Therefore, within the
Noisternig Expires January 14, 2009 [Page 30]
Internet-Draft A lightweight security extension for ULE July 2008
construction of the nonce, not only the SNDU's sequence number but
also the MPEG-2 TS cell's PID value is included. This gives a
guarantee for nonces to be unique when the encryption key is shared
across more than one PID. One case is that of multiple senders (i.e.
ULE encapsulators) using the same keys. It is assumed that there will
be at most one sender per PID for technical reasons (this does not
preclude the possibility of adversaries sending on the same PID). A
similar scenario is where a sender spreads data over multiple PIDs.
The last question is what key size to use. AES may be used with key
sizes of 128, 192, or 256 bits. Of these, 128 bits are regarded to be
sufficiently secure even for the foreseeable future, and any bigger
size would merely result in increased key management overhead and
computational effort [Standards].
B.2. Identity protection
The presented solution for identity protection is simple, yet very
effective. First, a receiver needs to probe only a very low number of
keys with an SNDU. This is because in the vast majority of cases
there is only a single or otherwise very few different keys a
receiver associates with a PID or pair of PID and VPN-ID field: For
an incoming ULEsec packet with a VPN-ID field present, the pair of
PID and VPN-ID will most commonly denote a single VPN with a single
shared key. Without a VPN-ID, the PID may represent a VPN with a
single key, or the PID will probably contain several or many unicast
or multicast connections of which the receiver accepts only a few,
namely for its own unicast and a few (if any) multicast addresses.
Each of these connections could utilize identity protection; however,
this is sensible only for unicast communication. Assuming a device is
not assigned more than one unicast address, there is only a single
key left that has to be probed with.
Second, by encrypting the address an adversary not in the know of a
matching decryption key will not be able to read the packet's
destination address. A legitimate receiver, in contrast, will
correctly decode the address with very high probability. In detail,
the chance that an SNDU is mistakenly accepted (assuming the
encryption algorithm behaves as a pseudo-random function under
different keys) is given approximately by k*10^-14.4, where k is the
receiver's number of keys that do not match. This is close to typical
packet-error ratios on the ULE link for small k, as this example
shows: assuming a quasi-error free channel with a bit-error ratio of
10^-10 [DVB-S], and - for simplicity assumed - a probability of 2^-32
for the CRC-32 failing, the chance of receiving an erroneous SNDU
undetected by the CRC ranges between approximately 10^-15.5 for a
Noisternig Expires January 14, 2009 [Page 31]
Internet-Draft A lightweight security extension for ULE July 2008
typical 1500-octet (file download) payload and 10^-16.8 for small
(VoIP) data of 60 octets.
Note that this method of identity protection requires to be combined
with the data confidentiality service for two reasons: First, it
protects only L2 addresses. Second, there is a requirement for the
data a receiver assumes to be an encrypted destination address to be
pseudo-random, or at least non-repeating (with high probability),
otherwise above equations will not hold.
This solution for identity protection is also superior to other
suggestions such as the use of temporary destination addresses
[ULEsec-CPI] for a variety of reasons. First, when creating temporary
addresses it must somehow be assured that these do not and will not
collide with real-world addresses, i.e. addresses that are in use or
might be used in the future. Second, in order to assure these
addresses to be unique a server must keep every one of them in a
database. This is clearly a disadvantage for simple settings such as
VPNs where otherwise only a single key must be stored. Third, such
addresses compromise additional information that must be distributed
in a reliable way, which is difficult for unidirectional links and
does not scale well for multicast scenarios. Last but not least, even
though these addresses are temporary, they remain constant for a
period of time and as such may pose just another chance for an
adversary to link packets with a receiver.
B.3. Authentication
By adding redundancy in the form of keyed cryptographic checksums to
packets, legitimate receivers can verify both authenticity and
integrity of the data. A Message Authentication Code (MAC) is the
result of a symmetric checksum function, so both senders and
receivers use the same key for authenticating and verifying.
MAC algorithms typically build upon cryptographic hash functions
(message digests), such as MD5 [RFC1321], SHA-1 and the SHA-2 family
[SHA], and RIPEMD-160 [RIPEMD-160]. The HMAC [RFC2104] is a popular
construction to turn a hash function into a MAC function. The
advantage of using hash functions is their simple implementability,
resulting in certain speed advantages. Despite a number of surprising
and unexpected collision attacks on hash functions published lately
[MD5-Attack, SHA-1-Attack], the HMAC construction is secure as long
as no second pre-image attacks become practical, and the hash
function's output cannot be distinguished from random data by an
adversary [Preimages, HMAC2, Standards].
Noisternig Expires January 14, 2009 [Page 32]
Internet-Draft A lightweight security extension for ULE July 2008
MAC constructions may also use block ciphers as building blocks. The
main advantage of this approach is that an already existing block
cipher implementation can be re-used. This makes the CBC-MAC (and its
variants) still a very popular solution. The security of a CBC-MAC is
directly dependent on that of the block cipher. Because of the
birthday phenomenon, the upper limit of security is also determined
by the block length of the underlying encryption algorithm, which
degrades quadratically over time [CBCMAC1, CBCMAC2]. Therefore, when
the same key is used for a long time (e.g., with extended sequence
numbers for ULEsec), a cipher with a higher block length should be
chosen, such as [Rijndael] with a block length of 256 bits.
A plain CBC-MAC is not a generally secure construction. In detail, it
is only secure for fixed-size or prefix-free messages [CBCMAC1].
However, ULE SNDUs are automatically prefix-free because of the
inclusion of the length field in the base header.
There are some interesting newer constructions based on Carter-Wegman
universal hashing, such as the UMAC [RFC4418] and the [Poly1305-AES],
both defined for use with the AES encryption algorithm. While having
excellent security properties, allowing for parallelization, and
achieving high throughputs on modern desktop processors, they are not
suitable for small hardware devices because of performing complex
operations such as multiplications in large size Galois fields and
requiring a large amount of memory.
Two surprisingly simple and parallelizable designs are presented in
[XOR-MAC] and [PMAC]. When a block cipher is plugged into the pseudo-
random function required, the complexity is similar to that of the
CBC-MAC. Security is not affected by the birthday phenomenon,
however. As both algorithms are covered by patents, they are not
selected as default authentication algorithms.
B.4. Source Authentication
MAC algorithms are symmetrical functions, so anyone in the know of
the right key could have been the author of an authenticated message.
Consequently, MACs cannot provide source authentication when there is
more than one legitimate sender, or receivers are able to act as
senders. In order to guarantee data coming from the source as
corroborated, some asymmetry must be introduced, either by using
functions that are hard to invert (digital signatures), or by
disclosing verification key material only after it has been used for
authentication (e.g., TESLA [RFC4082]).
Source authentication does not come for free, however. Digital
signature algorithms are very computationally demanding, as time
Noisternig Expires January 14, 2009 [Page 33]
Internet-Draft A lightweight security extension for ULE July 2008
needed for signing and verification is still counted in milliseconds
even on modern hardware. Additionally, bandwidth consumption is high
with typical key sizes of 1024 bits and signature sizes of 320 bits
for a level of security comparable to that of a 80-bit symmetric key
[Recommendations]. A number of different solutions have been
developed over time to overcome these shortcomings, most prominently
TESLA; however, all of them have one or another drawback such as
increased latency at the sender or receiver side, lack of re-
synchronization ability in case of packet loss, or even higher
bandwidth cost.
Source Authentication for ULEsec may be devised independently of this
specification, but it likely makes more sense for control messages
(e.g., key management messages).
B.5. Combined Authentication and Encryption
While there had always been a lack of consensus in cryptography and
security communities about the "right" way of combining
authentication with encryption, it had not been know until recently
that the only generally secure way of generic composition is Encrypt-
then-Authenticate (EtA) [Order-AE]. By following that finding within
this specification, encryption and authentication algorithms can be
changed and updated independently of each other without compromising
overall security; for example, the default CBC-MAC for authentication
could safely be replaced with a MAC using a cryptographic hash
function, or with an algorithm providing source authentication for
multi-sender scenarios.
Another recent development in cryptography are so-called
Authenticated Encryption (AE) and Authenticated Encryption with
Associated Data (AEAD) schemes. These can be viewed as modes of
operation that integrate both authentication and encryption
functionality. Excitement for these schemes can primarily be
contributed to the development of encryption modes that provide
authentication essentially for free (i.e., with negligible
computational overhead) [IAPM, XCBC, OCB]. Unfortunately, all these
so-called 1-pass schemes have patents filed on them, which is an
issue for an open standard. This circumstance initiated the
development of second-generation unpatented 2-pass schemes, most
notably CCM [CCM]. Even though these modes provide a secure two-in-
one solution (one key for both encryption and authentication), they
have lost their predecessors' main advantage: they are, as their name
says, 2-pass. As a result, they do not offer any real benefits over
the more versatile AtE generic composition approach.
Noisternig Expires January 14, 2009 [Page 34]
Internet-Draft A lightweight security extension for ULE July 2008
B.6. Replay Protection
The key idea in providing replay protection is to guarantee each
packet to be unique under the same key. This is generally achieved by
adding a monotonically increasing counter or a timestamp to the
packet header. The in-order delivery of data on the ULE link then
allows for easy detection of replays on the receiver side.
A counter is simple to use, requires minimal connection state on each
side, and is fully reliable for unicast connections and other one-
sender scenarios. It cannot be used when a key is shared among
multiple senders due to the difficulty of synchronizing replay state.
A timestamp uses synchronized clocks for the replay state. A small
window of accepted timestamps is required to compensate timing
discrepancies. This way, timestamps can be used with any number of
senders. However, this also means that they are not completely
reliable; consequently, their use is not defined within that
specification.
Noisternig Expires January 14, 2009 [Page 35]
Internet-Draft A lightweight security extension for ULE July 2008
10. References
10.1. Normative References
[RFC4326] G. Fairhurst, B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)", IETF RFC
4326, December 2005.
[MPEG2] "Information technology - generic coding of moving pictures
and associated audio information systems, Part I", ISO
13818-1, International Standards Organization (ISO), 2000.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, IETF RFC 2119, March 1997.
[AES] "Advanced Encryption Standard (AES)", FIPS PUB 197,
National Institute of Standards and Technology (NIST), Nov.
2001.
[Modes] M. Dworkin, "Recommendation for Block Cipher Modes of
Operation - Methods and Techniques", SP 800-38A, National
Institute of Standards and Technology (NIST), Dec. 2001.
10.2. Informative References
[H222] "Information technology, Generic coding of moving pictures
and associated audio information Systems", H.222.0,
International Telecommunication Union (ITU-T), 1995.
[DVB-S] "Digital Video Broadcasting (DVB); Framing structure,
channel coding and modulation for 11/12 GHz satellite
systems", ETSI EN 300 421, Aug. 1997.
[DVB-T] "Digital Video Broadcasting (DVB); Framing structure,
channel coding and modulation for digital terrestrial
television", ETSI EN 300 744, June 2006.
[DVB-H] "Digital Video Broadcasting (DVB); Transmission system for
handheld terminals (DVB-H)", ETSI EN 302 304, Nov. 2004.
[ULEsec-Req]H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar,
"Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", draft-ietf-ipdvb-sec-req-08
(work in progress), July 2008.
Noisternig Expires January 14, 2009 [Page 36]
Internet-Draft A lightweight security extension for ULE July 2008
[GSE] "Generic Stream Encapsulation (GSE) Protocol", DVB BlueBook
A116, May 2007.
[RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
Protocol", IETF RFC 4301, Dec. 2005.
[RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", IETF RFC 4346, April 2006.
[RFC4253] T. Ylonen, C. Lonvick, "The Secure Shell (SSH) Transport
Layer Protocol", IETF RFC 4253, Jan. 2006.
[RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig,
J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for
Internet Subnetwork Designers", IETF RFC 3819, July 2004.
[Rijndael]J. Daemen, V. Rijmen, "The Design of Rijndael: AES - The
Advanced Encryption Standard", Springer Verlag, March 2002,
pp. 238.
[Subset] D. Naor, M. Naor, J. Lotspiech, "Revocation and Tracing
Schemes for Stateless Receivers", Advances in Cryptology -
CRYPTO 2001, 21st Annual International Cryptology
Conference, Proceedings, August 2001, pp. 41-62.
[DVB-CA] "Digital Video Broadcasting (DVB); Support for Use of
Scrambling and Conditional Access (CA) within Digital
Broadcasting Systems", ETSI ETR 289, Jan. 1996.
[ATSC-CA] "Conditional Access System for Terrestrial Broadcast,
Revision A, with Amendment No. 1", Doc. A/70A, Advanced
Television Systems Committee, July 2004 (Sept. 2006 for
Amendment No. 1).
[DVB-RCS] "Digital Video Broadcasting (DVB); Interaction Channel for
Satellite Distribution Systems", ETSI EN 301 790, Sept.
2005.
[RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", IETF
RFC 4306, Dec. 2005.
[RFC4046] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Multicast
Security (MSEC) Group Key Management Architecture", IETF
RFC 4046, April 2005.
Noisternig Expires January 14, 2009 [Page 37]
Internet-Draft A lightweight security extension for ULE July 2008
[RFC4535] H. Harney, U. Meth, A. Colegrove, G. Gross, "GSAKMP: Group
Secure Association Key Management Protocol", IETF RFC 4535,
June 2006.
[RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group
Domain of Interpretation", IETF RFC 3547, July 2003.
[RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
"MIKEY: Multimedia Internet KEYing", IETF RFC 3830, August
2004.
[GKDP] L. Dondetti, J. Xiang, S. Rowles, "GKDP: Group Key
Distribution Protocol", IETF draft-ietf-msec-gkdp-01
(expired), March 2006.
[FMKE] L. Duquerroy, S. Josset, "The Flat Multicast Key Exchange
protocol", draft-duquer-fmke-01 (expired), Sept. 2004.
[RFC4082] A. Perrig, D. Song, R. Canetti, J. Tygar, B. Briscoe,
"Timed Efficient Stream Loss-Tolerant Authentication
(TESLA): Multicast Source Authentication Transform
Introduction", IETF RFC 4082, June 2005.
[RFC4082] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe,
"Timed Efficient Stream Loss-Tolerant Authentication
(TESLA): Multicast Source Authentication Transform
Introduction", IETF RFC 4082, June 2005.
[Arcfour] B. Schneier, "Applied Cryptography Second Edition:
protocols algorithms and source in code in C", John Wiley
and Sons, New York, 1996.
[Arcfour-Fix] B. Harris, "Improved Arcfour Modes for the Secure
Shell (SSH) Transport Layer Protocol", IETF RFC 4345, Jan.
2006.
[Standards] B. Burr, "NIST Cryptographic Standards Status Report",
PowerPoint presentation, National Institute of Standards
and Technology (NIST), April 2006.
[ULEsec-CPI]H. Cruickshank, P. Pillai, S. Iyengar, "Security
Extension for Unidirectional Lightweight Encapsulation
Protocol", draft-cruickshank-ipdvb-sec-03 (work in
progress), July 2007.
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", IETF RFC
1321, April 1992.
Noisternig Expires January 14, 2009 [Page 38]
Internet-Draft A lightweight security extension for ULE July 2008
[SHA] "The Secure Hash Standard", FIPS 180-2 (+ change notice to
include SHA-224), National Institute of Standards and
Technology (NIST), August 2002.
[RIPEMD-160]H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A
Strengthened Version of RIPEMD",
http://homes.esat.kuleuven.be/~bosselae/ripemd160.html,
April 1996.
[RFC2104] H. Krawczyk, M. Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", IETF RFC 2104, Feb.
1997.
[CBCMAC1] M. Bellare, J. Kilian, P. Rogaway, "The security of the
cipher block chaining message authentication code", Journal
of Computer and System Sciences, Vol. 61, No. 3, Dec. 2000,
pp. 362-399.
[CBCMAC2] B. Preneel, P. C. van Oorschot, "MDx-MAC and building fast
MACs from hash functions", Proc. Crypto '95: 15th Annual
International Cryptology Conference, Santa Barbara, Aug.
1995.
[RFC4418] T. Krovetz, "UMAC: Message Authentication Code using
Universal Hashing", IETF RFC 4418, March 2006.
[Poly1305-AES] D. Bernstein, "The Poly1305-AES Message-Authentication
Code", Proceedings of Fast Software Encryption, Lecture
Notes in Computer Science, Springer-Verlag, 2005.
[XOR-MAC] M. Bellare, R. Guerin, P. Rogaway, "XOR MACs: New methods
for message authentication using finite pseudorandom
functions", Advances in Cryptology - Crypto 95 Proceedings,
Lecture Notes in Computer Science, Springer-Verlag, 1995.
[PMAC] J. Black, P. Rogaway, "A Block-Cipher Mode of Operation for
Parallelizable Message Authentication", Advances in
Cryptology - EUROCRYPT '02, Lecture Notes in Computer
Science, Springer-Verlag, 2002.
[DSS] "Digital Signature Standard (DSS)", FIPS PUB 186-2 (+
change notice), National Institute of Standards and
Technology (NIST), Jan. 2000.
Noisternig Expires January 14, 2009 [Page 39]
Internet-Draft A lightweight security extension for ULE July 2008
[Order-AE]H. Krawczyk, "The order of encryption and authentication
for protecting communications", Proc. Crypto 2001: 21st
Annual International Cryptology Conference, Santa Barbara,
Aug. 2001.
[IAPM] C. Jutla, "Parallelizable Encryption Mode with Almost Free
Message Integrity", NIST proposed mode.
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
t.html
[XCBC] V. Gligor, P. Donescu, "Fast Encryption and Authentication:
XCBC Encryption and XECB Authentication Modes", NIST
proposed mode, April 2001.
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
t.html
[OCB] P. Rogaway, M. Bellare, J. Black, T. Krovetz, "OCB: A
Block-Cipher Based Mode of Operation for Efficient
Authenticated Encryption", NIST proposed mode, August 2001.
http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
t.html
[CCM] D. Whiting, R. Housley, N. Ferguson, "AES Encryption &
Authentication using CTR Mode & CBC-MAC", IEEE P802.11
802.11-02/001r0, Jan. 2002.
[MD5-Attack]X. Wang, D. Feng, X. Lai, H. Yu, "Collisions for Hash
Functions MD4, MD5, HAVAL-128 and RIPEMD", Cryptology
ePrint Archive: Report 2004/199, August 2004.
[SHA-1-Attack] X. Wang, Y. Yin, H. Yu, "Finding Collisions in the
Full SHA-1", Advances in Cryptology - Crypto 2005
Proceedings, Lecture Notes in Computer Science, Springer-
Verlag, Aug. 2005.
[Preimages] J. Kelsey, B. Schneier, "Second Preimages on n-bit Hash
Functions for Much Less than 2^n Work", Cryptology ePrint
Archive: Report 2004/304, Nov. 2004.
[HMAC2] M. Bellare, "New Proofs for NMAC and HMAC: Security without
Collision-Resistance", Advances in Cryptology - Crypto 2006
Proceedings, Lecture Notes in Computer Science Vol. 4117,
Springer-Verlag, Sept. 2006.
[Recommendations] "Recommendation for Key Management - Part 1:
General (Revised)", SP 800-57, National Institute of
Standards and Technology (NIST), May 2006.
Noisternig Expires January 14, 2009 [Page 40]
Internet-Draft A lightweight security extension for ULE July 2008
Author's Addresses
Michael Noisternig
University of Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg
Austria
Email: mnoist@cosy.sbg.ac.at
Bernhard Collini-Nocker
University of Salzburg
Jakob-Haringer-Str. 2
5020 Salzburg
Austria
Email: bnocker@cosy.sbg.ac.at
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Noisternig Expires January 14, 2009 [Page 41]
Internet-Draft A lightweight security extension for ULE July 2008
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Noisternig Expires January 14, 2009 [Page 42]