Internet DRAFT - draft-ppillai-ipdvb-sule
draft-ppillai-ipdvb-sule
Network Working Group P. Pillai
Internet-Draft Y. F. Hu
Expires: November, 2006 University of Bradford
May 03, 2006
Secure Unidirectional Lightweight Encapsulation Protocol
draft-ppillai-ipdvb-sule-00.txt
Status of this Memo
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the Secure Unidirectional Encapsulation
Protocol (S-ULE) that secures the IP traffic transported using ULE to
provide data authentication, data confidentiality, data integrity and
to mechanisms to prevent replay attacks.
Pillai & F. Hu Expires November 30, 2006 [Page 1]
Internet-Draft Secure ULE May 2006
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Requirements . . . . . . . . . . . . . . . . . . . . 6
4. Secure ULE SNDU Format . . . . . . . . . . . . . . . . . . . . 7
4.1. Destination Address Absent (D) Field . . . . . . . . . . . 7
4.2. Length Field . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Type Field . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Destination NPA Address Field . . . . . . . . . . . . . . 8
4.5. ULE_Security_ID Field . . . . . . . . . . . . . . . . . . 8
4.6. Sequence Number Field . . . . . . . . . . . . . . . . . . 8
4.7. Type Field . . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Encrypted PDU . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Message Authentication Code (MAC) Field . . . . . . . . . 9
5. Receiver Procedure . . . . . . . . . . . . . . . . . . . . . . 10
6. Secure ULE SNDU example . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Pillai & F. Hu Expires November 30, 2006 [Page 2]
Internet-Draft Secure ULE May 2006
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Pillai & F. Hu Expires November 30, 2006 [Page 3]
Internet-Draft Secure ULE May 2006
2. Introduction
The Unidirectional Encapsulation Protocol [RFC4326] is used for the
transportation of user traffic like IP datagrams, Ethernet
frames,etc. over ISO MPEG-2 Transport Streams [RFC4259] . This
document describes the Secure ULE protocol that can be used for
securing these ULE SNDUs for providing all the different security
requirements.
The set of security services that Secure ULE can provide includes
access control, data integrity, data origin authentication, rejection
of replayed packets and also data confidentiality.
On Securing the ULE SNDUs, security is provided at the link layer as
opposed to other existing mechanisms like IPSEC that provides
security at the network-layer or TLS that provides transport-layer
security. Since these services are provided at the link layer any
network layer protocol like IP, Ethernet, etc. may be used with
Secure ULE.
IPSEC [RFC2401] is one of the most widely deployed security protocols
that addresses all the important security requirements. Though IPSEC
in tunnel mode can be used to provide security over the MPEG-2
transmission networks, but it has several disadvantages. Some of
these are:
o The extra IP header introduces large overheads.
o Data Confidentiality is not provided for the complete IP Packets,
i.e. the outer IP Header are not secured, hence the IPSEC tunnel
end points are not hidden.
o IPSEC can be used to secure only IP datagrams and cannot be used
to provide security services for any other network protocols that
may be transported over the MPEG-2 Transport Streams using ULE
(like Ethernet Frames, MPLS, ATM, etc.)
o IPSEC is incompatible with NAT
o IPSEC is incompatible with TCP Performance Enhancing Proxies (PEP)
[RFC3135] that may be used in MPEG-2 based systems like the
Digital Video Broadcast (DVB) using the satellite for downlink
[DVBS] and uplink [DVBRCS]
Secure ULE aims to provide the same level of security services as
provided by IPSEC but with less packet overheads. Since Secure ULE
provides security between the MPEG-2 transmitter and receiver for
individual users at the link layer, it is not restricted to only IP
Pillai & F. Hu Expires November 30, 2006 [Page 4]
Internet-Draft Secure ULE May 2006
datagrams but can alsobe used for any network protocol that can be
carried by ULE including IP, Ethernet, ATM, MPLS etc.
Secure ULE shall use key management protocols like IKASMP, GDOI,
GSAKMP, MIKEY, etc to manage all the security related keys for the
individual users and multicast groups. These are out of scope of
this document.
Pillai & F. Hu Expires November 30, 2006 [Page 5]
Internet-Draft Secure ULE May 2006
3. Security Requirements
MPEG-2 based networks are susceptible to several security attacks,
both passive and active. Some of the main security requirements that
Secure ULE aims to achieve for IP services running on MPEG-2 based
systems are:
o Data Authentication: Data authentication allows a receiver to
verify that the data is sent by the claimed sender. Data
authentication can be achieved by calculating a Message
Authentication Code (MAC) using a shared secret key. This MAC is
also transmitted along with the data. The receiver would also
calculate the MAC for the received data using the shared key, and
then compare this computed MAC value to the one sent by the sender
along with the data. If the two matches, then the receiver knows
that the data had to be sent from the claimed sender. Hence the
message is authenticated.
o Data Integrity: Data integrity provides a way for the receiver of
the data message to know if the data has been tampered in transit
by an attacker. Data integrity is closely related to data
authentication. The MAC used for data authentication also
provides data integrity. The receiver of the data calculates the
MAC and compares it to the one transmitted by the sender. If an
adversary had tampered with the message then the two MACs would
not match.
o Data Confidentiality: Data confidentiality is achieved by
encrypting the information before transmission so that only
authorised people can decrypt the transmitted information while an
adversary would not be able to recover the important information
even if it got hold of the transmitted data.
o Replay Attacks Countermeasures: Methods against replay attacks
need to ensure that the received data is recent and that an
adversary has not replayed old messages at a later time. One of
the most common methods to provide data freshness is to use a
monotonically increasing sequence number with every message and
reject any messages with old sequence number values.
Pillai & F. Hu Expires November 30, 2006 [Page 6]
Internet-Draft Secure ULE May 2006
4. Secure ULE SNDU Format
Secure ULE aims to secure the transmission of user traffic over
MPEG-2 Transport Streams. In order to address the security issues,
Figure 1 shows the packet format of the Secure ULE protocol. The
higher layer data PDUs are encapsulated using Secure ULE to form an
Secure ULE (S-ULE) SNDU similar to the standard ULE SNDUs.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|D| Length | Type = S-ULE |
+-+----------------------------+------------------------------+
| Receiver Destination NPA Address * |
| +------------------------------+
| | ULE_Security_ID |
+------------------------------+------------------------------+
| ULE_Security_ID | Sequence Number |
+------------------------------+------------------------------+
| Sequence Number | Type = Type of PDU |
+------------------------------+------------------------------+
| |
| |
= Encrypted PDU =
| |
| |
+-------------------------------------------------------------+
| Message Authentication Code (MAC) |
| |
+-------------------------------------------------------------+
Figure 1: Secure ULE SNDU
The Secure ULE Header extension is derived from the ULE base header
and follows the mandatory extension header format. The extension
header for Secure ULE consists of a 32-bit security identifier,
ULE_Security_ID and a 32-bit sequence number. This is then followed
by the type field which indicates the type of the payload being
encapsulated.
The format of the Destination Address Absent field (D), the Length
field the Type field and the Receiver Destination NPA address field
directly follow and are used in the same way as defined for standard
ULE [RFC4326].
4.1. Destination Address Absent (D) Field
The most significant bit of the Length Field carries the value of the
Pillai & F. Hu Expires November 30, 2006 [Page 7]
Internet-Draft Secure ULE May 2006
Destination Address Absent Field (D) which follows the same
defination as in standard ULE[RFC4326]. When D is set to 0, it
indicates the presence of the Destination Address Field while D set
to 1 indicates that a Destination Address Field is not present.
4.2. Length Field
A 15-bit Length field denotes the length, in bytes, of the SNDU
counted from the byte following the Type field, up to and including
the MAC[RFC4326].
4.3. Type Field
A 16-bit Type Field indicates that this is a Secure ULE SNDU
[RFC4326].
[XXX IANA ACTION REQUIRED XXX]
IANA action is required to assign the Type field for Secure ULE.
[XXX END of IANA ACTION XXX]
4.4. Destination NPA Address Field
The SNDU Destination Address Field is optional . This field is MUST
be carried when field D is set to 0 and may be ommited when D=1
[RFC4326].
4.5. ULE_Security_ID Field
A 32-bit security identifier, the ULE_Security_ID similar to the
Security Parameter Index (SPI)used in IPSEC has been added to
uniquely identify the secure session. This ULE_Security_ID would
represent the security association between the MPEG-2 transmitter and
receiver for a particular session and will indicate the keys and
algorithms used for encrypting the data payload. Encryption
algorithms like DES, 3DES, etc. may be used for encrypting the data.
4.6. Sequence Number Field
A 32-bit sequence number has been added to the ULE SNDU to prevent
replay attacks. 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.
Pillai & F. Hu Expires November 30, 2006 [Page 8]
Internet-Draft Secure ULE May 2006
4.7. Type Field
This second type field denotes the type of packet that is
encapsulated in the Secure ULE SNDU.
4.8. Encrypted PDU
To achieve data confidentiality, the traffic between the two MPEG-2
TS Transmitter and Receiver needs to be encrypted. The network layer
PDUs are first encrypted and then encapsulated in the Secure ULE
SNDU. The security associations between the two communicating points
will describe the algorithms and keys used for encryption purposes.
Secure ULE does not impose the use of any specific encryption
algorithm, but instead should be able to support the commonly used
algorithms like DES, 3DES etc.
4.9. Message Authentication Code (MAC) Field
To provide both data authenticity and data integrity, a Message
Authentication Code (MAC) is used instead of the 32-bit CRC proposed
by the original ULE protocol. The MAC is calculated over the
extension header and the data payload. The receiver would calculate
the MAC for the received packet and compare it with the transmitted
value. The two would not match in only 2 cases, firstly either there
was an error during processing or transmission over the MPEG-2
Network, or secondly the packet has not been sent from an
authenticated entity. In either case, the packet should be
discarded. Hence the same MAC can be used for data origin
authentication and to provide data integrity for transmission/
processing errors.
To directly replace the 32-bit CRC, HMAC-MD5-32 or HMAC-SHA1-32 can
be used for generating a 32-bit MAC. However, a short MAC may be
susceptible to brute force attacks according to the birthday paradox.
Secure ULE when used in MPEG-2 networks such as the Digital Video
Broadcast (DVB) architecture or the Advanced Television Systems
Committee (ATSC) would work along with other security mechanisms
provided at the lower layers like the common scrambling and/or DVB-
RCS individual scrambling mechanisms in DVB. Under such scenarios a
32-bit MAC may be sufficient. If a stronger MAC is still required,
then similar to IPSEC, HMAC-SHA1-96 may be used.
Pillai & F. Hu Expires November 30, 2006 [Page 9]
Internet-Draft Secure ULE May 2006
5. Receiver Procedure
Upon reception of the Secure ULE SNDU, the receiver may first filter
the received packets according to the recevier destination NPA
address (if present).
It would then use the ULE_Security_ID to Obtain the security
associations between the transmitter and receiver. With this the
receiver would know the algorithms and keys used for both encryption
of the encapsulated PDU and for generation of the message
authentication code. It would then use the sequence number for
filtering out any out-of-sequence packets.
The next step would be to check the MAC to verify the authenticity
and integrity of the received packet. If the calculated MAC does not
match the transmitted MAC, then the packet is discarded.
Finally the encapsulated payload will be decrypted.
Pillai & F. Hu Expires November 30, 2006 [Page 10]
Internet-Draft Secure ULE May 2006
6. Secure ULE SNDU example
This section describes the Secure ULE SNDU when IP datagrams are
secured using Secure ULE. First the header of the Secure ULE SNDU is
formed by adding the ULE_Security_ID and the Sequence number for this
particular session. Then the type of the PDU being carried is added
to the header. The IPv4 datagrams are first encrypted using the
algorithms and keys defined during the setup of the security
association between the transmitter and receiver and then added to
the Secure ULE SNDU, which is the followed by the message
authentication code.
The two encapsulation are shown below in Figure 2 and Figure 3.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|0| Length (15 bits) | Type = S-ULE |
+-+----------------------------+------------------------------+
| Receiver Destination NPA Address (48 bits) |
| +------------------------------+
| | ULE_Security_ID |
+------------------------------+------------------------------+
| ULE_Security_ID | Sequence Number |
+------------------------------+------------------------------+
| Sequence Number | Type = IPv4 |
+------------------------------+------------------------------+
| |
| |
= Encrypted IP Datagram =
| |
| |
+-------------------------------------------------------------+
| Message Authentication Code |
| |
+-------------------------------------------------------------+
Figure 2: Secure ULE SNDU with D=0
Pillai & F. Hu Expires November 30, 2006 [Page 11]
Internet-Draft Secure ULE May 2006
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|1| Length (15 bits) | Type = S-ULE |
+-+----------------------------+------------------------------+
| ULE_Security_ID |
+-------------------------------------------------------------+
| Sequence Number |
+------------------------------+------------------------------+
| Type = IPv4 | |
+------------------------------+ |
| |
| |
= Encrypted IP Datagram =
| |
| |
+-------------------------------------------------------------+
| Message Authentication Code |
| |
+-------------------------------------------------------------+
Figure 3: Secure ULE SNDU with D=1
Pillai & F. Hu Expires November 30, 2006 [Page 12]
Internet-Draft Secure ULE May 2006
7. Security Considerations
To Be Completed.
Pillai & F. Hu Expires November 30, 2006 [Page 13]
Internet-Draft Secure ULE May 2006
8. IANA Considerations
IANA action will be required to assign a ULE Type registry entry for
this protocol.
Pillai & F. Hu Expires November 30, 2006 [Page 14]
Internet-Draft Secure ULE May 2006
9. References
9.1. Normative References
[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 Streams", RFC 4326,
December 2005.
9.2. Informative References
[DVBRCS] "Digital Video Broadcasting (DVB): Interaction Channel for
satellite distribution systems", ETSI EN 301 790 v1.4.1,
2005.
[DVBS] "Digital Video Broadcasting (DVB): Framing structure,
channel coding and modulation for 11/12 GHz satellite
services", ETSI EN 301 421 v1.1.2, 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[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.
[RFC4259] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
Pillai & F. Hu Expires November 30, 2006 [Page 15]
Internet-Draft Secure ULE May 2006
Authors' Addresses
Prashant Pillai
University of Bradford
School of Engineering, Design and Technology
Bradford, West Yorkshire BD7 1DP
United Kingdom
Phone: +44 1274 233720
Email: p.pillai@bradford.ac.uk
Yim Fun Hu
University of Bradford
School of Engineering, Design and Technology
Bradford, West Yorkshire BD7 1DP
United Kingdom
Phone: +44 1274 234151
Email: y.f.hu@bradford.ac.uk
Pillai & F. Hu Expires November 30, 2006 [Page 16]
Internet-Draft Secure ULE May 2006
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.
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.
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.
Acknowledgment
To be completed.
Pillai & F. Hu Expires November 30, 2006 [Page 17]
