Internet Engineering Task Force H. Cruickshank
Internet Draft S. Iyengar
Document: draft-cruickshank-ipdvb-sec-01.txt University of Surrey
L. Duquerroy
Alcatel Alenia Space
Category: Internet Draft 11 May 2006
A Secure Extension for the Unidirectional Lightweight
Encapsulation (ULE) protocol
Status of this Draft
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.
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 [RFC2119].
Abstract
This document proposes an extension format for the Unidirectional
Lightweight Encapsulation (ULE) protocol. This work is intended as
a work item of the ipdvb WG, and contributions are sought from the
IETF on this topic.
Expires November 2006 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
Table of Contents
1. Introduction
1.1 Definitions used in this document
2. Link Security Protocol
2.1 Encryption of the SNDU payload
2.2 Encryption Extension Header format
3. Key Exchange Procedure
3.1 IPsec Key Management for L2
3.2 Alternative Key Management
4. Summary
5. Acknowledgments
6. Security Considerations
7. References
7.1 Normative References
7.2 Informative References
8. Authors' Addresses
9. IPR Notices
9.1 Intellectual Property Statement
9.2 Disclaimer of Validity
10. Copyright Statement
11. IANA Considerations
Annexe A. Examples of use
Expires November 2006 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
1. Introduction
This document describes an extension header for providing link
layer security for the ULE [RFC4326] encapsulation which
supports transport of IP datagrams or other network layer packets
over ISO MPEG-2 Transport Streams [iso-mpeg].
In MPEG-2 transmission networks employing ULE, there is a need to
provide link-layer (L2) security, particularly where network
layer and transport-layer security (e.g. IPsec, TLS) may not be
sufficient. The security requirements are presented in draft-
cruickshank-ipdvb-sec-req-01.
ULE may use and benefit from IETF key management protocols, such
as the MSEC GDOI [RFC3547, RFC3547] and GSAKMP [msec-gsakmp].
This does not preclude the use of other key management methods in
scenarios which benefit from this.
In some current encapsulation methods, e.g. MPE [etsi-dat],
encryption of the MAC address requires each Receiver to decrypt
all encrypted data sent using a TS Logical Channel (PID), before
it can then filter the PDUs that matches the set of MAC/NPA
addresses that the Receiver wishes to receive, therefore
encryption of the MPE MAC address is not permitted in such
systems. This document specifies a mode in that provides optional
support for using temporary Layer 2 MAC/NPA address.
To support link level encryption, an encryption
extension header is defined, and included in the SNDU payload.
This approach is generic and decouples the encapsulation from the
evolution of future security methods.
The proposed approach suggests a new ULE Mandatory Extension
header for a security. Encryption algorithms, key lengths, etc.
will be defined making use of the standard IPsec suites [msec],
as a security association id similar to the IPsec SPI [IPsec] is
used. The focus is on providing suitable link encryption.
However, Link layer data integrity is provided as an optional
security service, especially for systems where there are several
ULE transmitters (e.g. satellite meshed systems with On-Board
Processing)
1.1 Definitions used in this document
AES Advanced Encryption Standard [msec-gsakmp]
D-bit Destination Address Omitted field [RFC4326]
DVB Digital Video Broadcast
GDOI Group Domain of Interpretation [RFC3547]
GSKAMP Group Secure Association Key Management Protocol
[msecgsakmp]
IPsec Internet Protocol Security suite [ipsec, RFC2401,
RFC2402, RFC2406]
L2 Link Layer
MPE Multi-Protocol Encapsulation [etsi-dat]
NAT Network Address Translation [RFC3715]
NCC Network Control Centre
PEP Protocol Enhancing Proxy [RFC3135]
PID Packet Identifier [iso-mpeg]
PDU Protocol Data Unit (IP packey, MPLS frame, etc)
Expires November 2006 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
SHA-1 Standard Hash Algorithm 1 [msec-gsakmp]
SID Security Identifier
SNDU Subnetwork Data Unit [RFC4326]
RFC 4082 Timed Efficient Stream Loss-Tolerant Authentication
TLS Transport Layer Security [tls]
TS MPEG-2 Transport Stream [RFC4259]
ULE Unidirectional-Lightweight Encapsulation
2. Link Security Protocol
This section describes the link security protocol for the ULE
protocol.
2.1 Encryption of the SNDU payload
The security suite of algorithms for data encryption and data
integrity specified in IPsec/MSEC will be used for ULE security.
The SNDU padding must be used in order to make the SNDU length as
multiples of 8 or 16 byes depending on the type of encryption
algorithm used.
Another issue is key space there is a need for two databases for
the correct processing on security in ULE Transmitters and
Receivers:
. Security Policy Database (SPD): This database contains the
policies that determine the processing of all ULE inbound /
outbound traffic (such as encrypting all outbound ULE traffic
destined to a certain terminal).
. Security Association Database (SAD): Each entry defines the
parameters associated with one ULE-SID such as encryption
. keys. Each ULE-SID has an entry in the SAD.
The main aim of this document is to re-use existing techniques in
IPsec architecture and therefore the SDP, SAD and will follow the
format of these databases as defined in RFC 4301 [RFC4301].
The encryption is done on the entire PDU including the checksum.
In the case of using sequence numbers the sequence number field
is not included in the encryption process In order to prevent
against the hijacking of the MPEG2-TS transport stream, a source
authentication integrity block is appended to the above mentioned
encrypted block. This integrity is applied over the whole SNDU
including the header and after encryption (and if included the
sequence number field too). At the receiver end if the integrity
check fails the receiver can drop the packet without decrypting
the packet. The choice of the integrity service is flagged as a
matter of policy by the gateway and is handled by the key
management system.
In order to prevent replay attacks, the optional field of
sequence number is added to the encrypted payload. This field is
left in the open and does not need to be encrypted. It is a 32
bit value and it follows the ULE-SID field. The choice of using
sequence numbers is dictated by policy and is done by the key
management system.
2.2 Encryption Extension Header format
Expires November 2006 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
A ULE [RFC4326] encryption header extension is defined for use
with any ULE payload. This extension header MAY directly follow
the ULE base header (as illustrated in figures 1 and 2). It MAY
also follow another specified extension header.
The Encryption Extension is a Mandatory ULE Extension Header.
This means that a Receiver MUST either process this header,
before it processes the next header (or the enclosed PDU);
otherwise the entire SNDU is to be discarded. The first two
bytes of the encrypted data block contain a ULE Type field,
defined by [RFC4326] that specifies the type/extension header
that follows.
This document defines one code-point for encryption headers.
SNDUs that are not encrypted do NOT include this header.
IANA action is required to assign a one code point from ULE
Mandatory Next-Layer-Header Registry.
00YY Secure ULE A
The ULE Security IDentifier (ULE-SID) is a 32 bit value. The
ULE-SID can be used by a Receiver to filter PDUs in
conjunction with the set of MAC/NPA addresses that it wishes to
receive. ULE-SID to have a similar format to the Security
Parameter Index (SPI) used in IPSEC and MSEC protocols.
The extension MAY be used with PDUs that carry a NPA/MAC address
(D=0) or with PDUs that omit this field (D=1). In the latter
case, there is no MAC address present to a receiver of an
encrypted ULE PDU.
Receiver NPA/MAC address hiding is an important objective for ULE
security. Using option D=1 (no MAC/NPA address) is OK as long as
the ULE-SID is unique in the whole ULE network. This implies the
need for a centralised key management system that generates the
ULE-SID. If MAC/NPA address is used (option D=0), then the
Network Control Center (NCC) is responsible for generating this
temporary MAC/NPA address. The temporary MAC/NPA address should
be used for all secure communications with that Receiver. In
addition, the temporary MAC/NPA address will change from time to
time depending on the security policy and it is not directly
related to each ULE session. It can change periodically (for
example after a specified period of time and/or after a specified
volume of traffic has been sent to that terminal). The temporary
MAC/NPA address is used in association with the ULE-SID for
specific session security. It is envisaged that there will be
small impact on the NCC for handling two MAC/NPA addresses for
each terminal.
In order to prevent replay attacks a optional 32-bit sequence
number has been added to the ULE SNDU. The value of this sequence
number would be set to 0 at the beginning of the session. The
gateway would monotonically increment this number when it sends a
packet to the receiver and the receiver would verify the correct
sequence number. If an adversary tries to inject or replay old
packets the sequence number would not match. This would result in
discarding the packet.
The optional source authentication block is necessary in
Expires November 2006 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
situations where the MPEG2-TS stream can be hijacked. This block
prevents the attack and also provides data origin authentication.
Light weight authentication mechanisms (e.g. RFC 4082 [RFC4082] could
be used for this security service.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 | Length (2B) | Type = Secure ULE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Receiver temporary NPA Address (6B) |
+ +--+--+--+--+--+--+--+--+
| | ULE SID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ULE SID |Seq. Number (optional) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+ Seq Number (4B) | |
|--+--+--+--+--+--+--+--+ | |
| Encrypted Block |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
| Integrity Block (optional) |
+--+--+--+---+--+--+--+--+--+--+--+--+--+--+--+-|
Figure 1: SNDU Format for the Encryption Header (D=0)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|1 | Length (2B) | Type = Secure ULE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ULE SID (4B) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Seq. Number (optional) (4B) |
|--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| +
| Encrypted Block |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
+ Integrity Block (optional) +
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: SNDU Format for the Encryption Header (D=1).
This encryption header has a type value with one of two IANA-
assigned 16-bit next-layer-header values.
3 Key Exchange Procedures
This section describes the key exchange procedure, used to
install and manage the keys at Receivers. There is a need to
take into account the two cases described in [RFC4259], both
unidirectional and bi-directional transfers.
Expires November 2006 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
The key management procedures are independent from the ULE
operations. During the key exchange procedure, the ULE-SID will
be defined.
The exact data encryption and data integrity choices are
linked to the key management systems in use. One example is the
security suite 1 (defined in GSAKMP [msec-gsakmp]). This uses
AES (CBC mode, Key Length: 128 bits) for data encryption and
DSS-ASN1-DER for digital signature and SHA-1 as the Hash
algorithm. Other suites will be added in future versions.
A detailed key management system is not presented in this
document, but two approaches are outlined.
3.1 IPsec Key Management for L2
Existing key management systems can be used such as the MSEC key
exchange protocols, GDOI and GSAKMP [RFC3547 and msec-gsakmp].
The format of the ULE-SID will be identical to the security
association as defined in GDOI or GSAKMP. The initial key
exchange between the security server (which may reside with NCC)
and the ULE Receiver can be transported either within the ULE
network or may be performed by some other means. This is a
matter of policy and an architecture decision. For example, for
bi-directional transfers the whole key exchange procedures could
be carried within the ULE network, while for unidirectional
transfers, some other bidirectional connection should be used.
3.2 Alternative Key Management
The method described here for link encryption could be used with
alternative key management systems when used
as a part of a system that already implements a key management
infrastructure (e.g. the DVB-RCS security system [etsi-dvbrcs]).
The format of the ULE-SID will be the same format as defined in
DVB-RCS security procedures.
4. Summary
This document proposes a security framework for a layer 2
security method designed for the Unidirectional-Lightweight
Encapsulation (ULE) protocol. It proposes an extension format for
the Unidirectional Lightweight Encapsulation (ULE) protocol.
The key management for this protocol may be performed using IPsec
methods such as the msec gsakmp and gdoi protocols or using other
methods not defined in this document.
Expires November 2006 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
5. Acknowledgments
The authors acknowledge the help and advice from Gorry
Fairhurst (University of Aberdeen) in the preparation of this
draft.
6. Security Considerations
Link-level (L2) encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.
provided by TLS, SSH, Open PGP, S/MIME, IPsec). A common
objective is to provide the same level of privacy as terrestrial
links. An ISP or User may also wish to provide end-to-end
security services to the end-users (based on the well known
mechanisms such as IPsec).
This document defines a method to provide optional link
encryption. The method may also support optional link level
integrity / authentication of the SNDU payload plus sequence
numbers for anti-relay attacks.
This is provided in a flexible way using a ULE Mandatory
Extension Header. This decouples specification of the security
functions from the encapsulation functions. This method also
supports encryption of the NPA/MAC addresses. The encryption
and integrity algorithms are similar to the ones used in
IPSEC/MSEC protocols.
7. References
7.1 Normative References
[iso-mpeg] ISO/IEC DIS 13818-1 "Information technology --
Generic coding of moving pictures and associated audio
information: Systems", International Standards Organisation
(ISO).
[etsi-dat] EN 301 192, "Digital Video Broadcasting
(DVB); DVB Specifications for Data Broadcasting",
European Telecommunications Standards Institute (ETSI).
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP Datagrams
over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
7.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[etsi-dvbrcs] "Digital Video Broadcasting (DVB) -- interaction
channel for satellite distribution systems", ETSI EN 301 790
V1.4.1 (2005-04)
[msec-gsakmp] H Harney (SPARTA ), et al, "GSAKMP: Group Secure
Association Group Management Protocol", <draft-ietf-msec-gsakmp
-sec-10.txt>, IETF Work in Progress.
[RFC3547] M. Baugher , et al, "GDOI: The Group
Domain of Interpretation" RFC 3547.
[RFC3715] B. Aboba and W Dixson, " IPsec-Network Address
Translation (NAT) Compatibility Requirements"
[RFC4259] Montpetit, M.-J., 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.
[msec] http://www.ietf.org/html.charters/msec-charter.html
[IPsec] http://www.ietf.org/html.charters/wg-
dir.html#Security%20Area. RFCs 2401, 2402 and 2406
[tls] http://www.ietf.org/html.charters/tls-charter.html
Expires November 2006 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G.,
and Z. Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC4301] S. Kent, et al, "Security Architecture for the
Internet Protocol", RFC 4301, December 2006.
[RFC4082] A. Perrig, et al, "Timed Efficient Stream Loss-
Tolerant Authentication", RFC 4082, June 2005.
8.Authors' Addresses
Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: h.cruickshank@surrey.ac.uk
Sunil Iyengar
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: S.Iyengar@surrey.ac.uk
Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems
Alcatel Alenia Space, Toulouse
France
E-Mail: Laurence.Duquerroy@space.alcatel.fr
9. IPR Notices
9.1 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
Expires November 2006 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB May 2006
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.
9.2 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
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.
10. Copyright Statement
Copyright (C) The Internet Society (2006).
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.
12. IANA Considerations
This document will require IANA involvement. To assign a pair of
Mandatory header extension values from the ULE Registry.
Annexe A. Examples of use
No examples of use are provided in this revision of the
I-D.
Expires November 2006 [page 10]