Internet Engineering Task Force H. Cruickshank
Internet Draft S. Iyengar
Document: draft-cruickshank-ipdvb-sec-req-00.txt University of Surrey
S. Combes
L. Duquerroy
Alcatel Space
Category: Internet Draft 13 September 2005
Security requirements 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.
Abstract
This document provides a threat analysis and derives security
requirements for MPEG-2 transmission links using the Unidirectional
Lightweight Encapsulation (ULE). It also provides the motivation
for ULE link level security.
Table of Contents
< to be completed >
Expires March 2006 [page 1]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
1. Introduction
A security analysis was provided in the RFC defining the ULE method
[ULE] and the ipdvb architecture [ipdvb-arch]. This document
extends that analysis and derives the security requirements. The
document provides an overview of threats that are important to an IP
network that utilises ULE over an underlying MPEG-2 transmission
network.
The MPEG-2 Transport Stream (TS) has been widely accepted not only
for providing digital TV services, but also as a subnetwork
technology for building IP networks. The Unidirectional Lightweight
Encapsulation (ULE) mechanism described in [ULE] for the transport
of IPv4 and IPv6 Datagrams, bridged Ethernet frames and other
network protocol packets directly over the ISO MPEG-2 Transport
Stream as TS Private Data. ULE specifies a base encapsulation format
and supports an extension format that allows it to carry additional
header information to assist in network/Receiver processing.
Key characteristics of MPEG-2 transmission networks are that they
may provide link-level broadcast capability, and that many support
applications that require access to a very large number of
subnetwork nodes [ipdvb-arch]. In addition, the majority of MPEG-2
transmission networks are bandwidth-limited, encapsulation protocols
must therefore add minimal overhead to ensure good link efficiency
while providing adequate network services. They also need to be
simple to minimize processing, robust to errors and security
threats, and extensible to a wide range of services.
1.1 System Components
There are several entities in within the MPEG-2 transmission network
architecture, as defined in [ipdvb-arch]). These include (ULE)
Encapsulation Gateways, TS multiplexors (including re-multiplexors),
modulators and Receivers.
The ULE link security focuses on security between the Encapsulation
Gateways (ULE source) and Receivers only.
Expires Feb. 2005 [page 2]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
2. Threat Analysis
In the security considerations section of [ipdvb-arch], there is an
initial analysis of the security requirements in MPEG-2 transmission
networks. For example, when the MPEG-2 transmission network is not
using a wireline network, the normal security issues relating to the
use of wireless links for transport of Internet traffic should be
considered [RFC3819]. As such, it recommends that any new
encapsulation defined by the IETF should allow Transport Stream
encryption and also supports optional link level encryption /
authentication of the SNDU payload. In this document, we extend the
[ipdvb-arch] threats analysis and derive a more detailed the
security requirements.
The simplest type of network threat is a passive threat. Passive
attacks include eavesdropping or monitoring of transmissions, with a
goal to obtain information that is being transmitted. In broadcast
networks (especially those utilising widely available low-cost
physical layer interfaces, such as DVB) passive threats are
considered the major threats. An example of such a threat is an
intruder monitoring the MPEG-2 transmission broadcast and being able
to extract traffic communicated between IP hosts. Another example is
an intruder trying to gain information about the communication
parties by monitoring their Layer 2 MAC/NPA addresses; an intruder
can gain some information by just knowing the identity of the
communicating parties and the volume of their traffic. This is a
well-known issue in the security field, however it is more
problematic in the case of broadcast networks such as MPEG-2
transmission networks.
Active threats (or attacks) are, in general, more difficult to
implement successfully than passive threats, and usually require
more sophisticated resources and may require access to the
transmitter. Examples of active attacks are:
- Masquerading: where an entity pretends to be a different entity.
This includes masquerading other users and subnetwork control
plane messages
- Modification of messages in an unauthorised manner.
- Repudiation: Repudiation of origin occurs when a party denies
being the originator of a message and repudiation of destination
occurs when a party denies the reception of a message. However,
this is an application layer issue and does not apply to link or
network layer communications.
- Replay attacks: When an intruder sends some old (authentic)
messages to the Receiver.
- Denial of service attacks: When an entity fails to perform its
proper function or acts in a way that prevents other entities from
performing their proper functions.
Expires Feb. 2005 [page 3]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
Active threats such as replay masquerading, modification of messages
and injecting IP packet attacks are major security concerns for the
Internet community and several of these attacks have been described
[Bellovin]. The defence against such attacks is data integrity
using cryptographic techniques and sequence numbers.
In the context of active threats in MPEG-2 transmission networks,
ULE source authentication (i.e. verification that packets are being
sent by the expected Encapsulation Gateway) is required by the ULE
Receivers. Although attacks such as masquerading, modification of
messages and injecting IP packets are more difficult. However such
attacks on individual ULE Receivers are possible and can pass
unnoticed by the ULE network operators or ISPs.
However, Active threats need a careful consideration in the context
of MPEG-2 transmission links, where the ULE method is a lightweight
protocol and we need to be careful not to turn it into a heavyweight
protocol by adding such security features. A typical integrity
check such as MD5 is 20 bytes and a typical sequence numbering
requires 4 bytes. Therefore new lightweight data integrity methods
or procedures are needed.
Expires Feb. 2005 [page 4]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
3. Security Requirements for IP over MPEG-2 TS
From the above analysis, the following security requirements can be
derived:
- Data confidentiality is the major requirement against passive
threats (using encryption). L2 encryption or L3 (IPsec)
encryption can satisfy this requirement. However IPsec must be
used in tunnel mode between ULE senders and receivers, which has
more overhead.
- Optional protection of Layer 2 MAC/NPA address. This is needed
particularly in the MPEG-2 broadcast networks to stop an intruder
gaining information by observing the identity of the communicating
parties and the volume of their traffic. IPsec can not provide
this service, however this is possible with L2 security systems.
- Layer L2 terminal authentication. This will be part of the key
management. It will be performed during the initial key exchange
and authentication phase.
- For active threats: ULE source authentication and data integrity
are required, using techniques such as message authentication code
and digital signatures. Sequence numbers are required to stop
replay attacks. Therefore, L2 data integrity/authentication is
optional, but still important in environments in which several
independent networks share a single transmission resource. In
addition, functions to determine the integrity of control and
management messages in MPEG-2 transmission networks are another
optional requirement.
- End-to-end security (such as IPsec and TLS) and ULE link security
should work in parallel without obstructing each other.
- Decoupling of ULE key management functions from ULE encryption.
This will allow the independent definition of these systems such
as the re-use of existing security management systems (e.g. GSAKMP
[msec-gsakmp] and GDOI [msec-gdoi]), plus other systems such as
DVB-RCS [ETSI-DVBRCS] and/or the development of new systems, as
required.
- There is a need to take into account the two cases described in
[ipdvb-arch] for unidirectional and bi-directional transfers.
- Other general requirements are:
Protection of the management system and the infrastructure from
unauthorised people. ULE encryption will provide partial
protection through the key management procedures and data
encryption.
Expires Feb. 2005 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
Operational issues: Because of the possible large coverage of a
broadcast transmission network, it may be required to deliver data
to many different countries that may have different security
legislation (related to authorized encryption algorithms and the
length of keys). Therefore the ULE security system should allow a
wide range of security parameters during the negotiation phase in
order to offer flexibility to operators. In ULE security, the
choice of such algorithms will be decided by the key management
system in use.
Compatibility with other networking functions: Other networking
functions such as NAT (Network Address Translation) [RFC 3715] or
TCP acceleration can be used in a wireless DVB networks. The ULE
security solution should be compatible with functions such as
NAT/NAPT, IPsec, TLS, etc. This requirement is met by ULE
security.
Traceability (such as using intrusion detection systems):To
monitor transmission network (e.g. using log files to record the
activities on the network). This is out of scope for ULE
security.
4. IPsec and MPEG-2 Transmission Networks
IPsec supports two modes of use: transport mode and tunnel mode. In
transport mode, AH and ESP provide protection primarily for next
layer protocols; in tunnel mode, AH and ESP are applied to tunnelled
IP packets. In both modes, data integrity is provided and in
addition, ESP provides the data privacy service as well.
It is possible to use IPsec to secure ULE links. The major
advantage of IPsec is its wide implementation in IP routers and
hosts. The Security Architecture for the Internet Protocol
[RFC2401BIS] describes security services for traffic at the IP
layer. That architecture primarily defines services for Internet
Protocol (IP) unicast packets, as well as manually configured IP
multicast packets.
However, IP Multicast is considered as a major service over MPEG-2
Transmission Networks. A document produced by the IETF msece Working
Group on IPsec extensions for multicast [msec-ipsec-ext] describes
extensions to [RFC2401BIS] that further define the IPsec security
architecture for packets that carry a multicast address in the IP
destination field, allowing these to remain IP multicast packets.
4.1 Tunnel mode use of IPsec for multicast
In the context of MPEG-2 transmission links, if IPsec is used to
secure a ULE link, then the ULE gateways and Receivers are
Expires Feb. 2005 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
equivalent to the security gateways in IPsec terminology. A security
gateway implementation of IPsec using the multicast extensions MUST
use tunnel mode. In particular, the security gateway must use the
tunnel mode to encapsulate incoming fragments.
With IPsec tunnel mode, there are two challenges: First, if the
destination of an IP multicast packet is changed it will no longer
be properly routed. Secondly, IP multicast routing protocols also
typically create multicast distribution trees based on the source
address. An IPsec security gateway that changes the source address
of an IP multicast packet, again this will cause multicast routing
problems. The [msec-ipsec-ext] document defines a way for retaining
both the IP source and destination addresses of the inner IP header
to allow IP multicast routing protocols to route the packet
irrespective of the packet being IPsec protected. This
interpretation of tunnel mode is known as tunnel mode with address
preservation.
4.2 IPsec and L2 security
IPsec in transport mode can be used for end-to-end security
transparently of MPEG-2 transmission links with no impact.
However, if IPsec is used to secure ULE links, then it must be used
in tunnel mode. Such usage has the following disadvantages:
- There is a need to protect the identity of ULE
encapsulator/Receivers over the ULE broadcast medium; IPsec can
not provide this service.
- There is an extra overheads associated with using IPsec in tunnel
mode, i.e. the extra IP header (IPv4 or IPv6).
- Multicast is considered as a major service over ULE links. The
current IPsec specifications [RFC 2401] only define a pairwise
tunnel between two IPsec devices with manual keying. Work in
progress [msec-ipsec-ext] is defining the extra detail needed for
multicast and to use the tunnel mode with address preservation.
In the ULE link context, in addition to the IPsec tunnelling
overhead, the source and destination address preservation means
that these IP addresses are broadcast in the clear. This provides
an opportunity to intercept the traffic information (weakening the
ability to provide the identity hiding). However [msec-ipsec-ext]
mentions the possibility that multicast data is sent through a
service provider network, and is encapsulated under a different IP
multicast address while in the provider network. The source
address of the encapsulating (outside) IP header could be changed
to that of the ULE gateway.
Expires Feb. 2005 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
5. Motivation for ULE link-layer security
Examination of the threat analysis and security requirements in
sections 2 and 3, has shown that there is a need to provide link-
layer (L2) security in MPEG-2 transmission networks employing ULE.
Particularly when network-layer and transport-layer security (e.g.
IPsec, TLS) are insufficient.
ULE link security is therefore considered an additional security
mechanism to IP, transport, and application layer security, not a
replacement. It should provide similar functions to that of IPsec
[IPsec], but in addition provides link confidentiality and Receiver
identity hiding. End-to-end security, IPsec and ULE link security
should work in parallel: IPsec providing the end-to-end security
between hosts and ULE providing the security over the MPEG-2
transmission link. However, no direct interaction between the IPsec
and the ULE security system is invisaged.
A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as the MSEC [msec-
gsakmp]and GDOI [msec-gdoi, RFC 3547]. This does not preclude the
use of other key management methods in scenarios that benefit from
this.
5.1 Link security below the Encapsulation layer
Link layer security can be provided in the MPEG-TS level (below
ULE). MPEG-TS encryption encrypts all TS Packets sent with a
specific PID value. However an MPEG-TS may multiplex several IP
streams using a common PID. Therefore all multiplexed traffic will
share the same security keys.
This has the following advantages:
- The bit stream sent on the broadcast network does not expose any
L2 or L3 headers, specifically all addresses, type fields, and
length fields are encrypted prior to transmission.
- This method does not preclude the use of IPsec, or any other form
of higher-layer security.
This had the following disadvantages:
- Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with a
matching PID, possibly including those that are not required to be
forwarded.
- ULE Receivers will be able to see the private traffic destined to
other ULE Receivers, since they share a common key.
Expires Feb. 2005 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
- If the key is compromised, then this will impact several ULE
Receivers.
5.2 Link security as a part of the Encapsulation layer
Therefore major advantages for ULE link security are:
- The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses [RFC 3819].
- Ability to protect the identity of the Receiver within the MPEG-2
transmission network.
- Efficient protection of IP multicast over ULE links.
- Transparency to the use of Network Address Translation (NATs) [RFC
3715] and TCP Performance Enhancing Proxies (PEP) [RFC3135], which
require the ability to inspect and modify the packets sent over
the ULE link.
- This method does not preclude the use of IPsec. IPsec also
provides a proven security architecture defining key exchange
mechanisms and the ability to use a range of cryptographic
algorithms. ULE security can make use of these mechanisms and
algorithms.
In some current encapsulation methods, e.g. MPE [DVB-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 match 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. For ULE security, an
optional support for Layer 2 MAC/NPA address hiding should be
provided.
Examining the threat analysis in section 2, has shown that
protection of ULE link from eavesdropping and ULE Receiver identity
hiding are major requirements. Such requirements can be met using
ULE link encryption.
In the context of active threats in MPEG-2 transmission networks,
ULE source authentication is required by the ULE Receivers. Attacks
such as masquerading, modification of messages and injecting IP
packets are more difficult. However, such attacks on individual ULE
Receivers are possible, and can pass unnoticed by the ULE network
operators or ISPs. Therefore new lightweight data integrity methods
or procedures can be provided by the ULE security system
The ULE security system should be incremental and provide ULE link
encryption as a basic service. Additional services such as data
Expires Feb. 2005 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
integrity and sequence number should be only provided where it is
needed.
6. Summary
This document analyses a set of threats and security requirements.
It also defines the requirements for ULE security and states the
motivation for Link security as a part of the Encapsulation layer.
In summary, there is a need for L2 encryption, ULE Receiver identity
hiding, L2 source authentications and protection against insertion
of other data into the ULE stream.
7. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen) in the preparation of this draft.
8. 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 wired 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 provides a threat analysis and derives the security
requirements to provide optional link encryption and link-level
integrity / authentication of the SNDU payload.
9. References
9.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).
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ULE] Fairhurst, G., Collini-Nocker, "Ultra Lightweight
Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2
Transport Stream", <draft-ietf-ule-06.txt>, IETF Work in Progress.
[ipdvb-arch] M.J. Montpetit ed., et al, "Framework for transmission
of IP datagrams over MPEG-2 Networks", <draft-ietf-ipdvb-arch-
04.txt>, IETF Work in Progress.
Expires Feb. 2005 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
9.2 Informative References
[Bellovin] Bellovin, S., "Problem Area for the IP Security
Protocols", Computer Communications Review 2:19, pp. 32-48, April
1989. http://www.cs.columbia.edu/~smb/ .
[ETSI-DVBRCS] "Digital Video Broadcasting (DVB) -- interaction
channel for satellite distribution systems", ETSI EN 301 790 V1.4.1
(2005-04)
[IPsec] http://www.ietf.org/html.charters/wg-
dir.html#Security%20Area. RFCs 2401, 2402 and 2406
[msec] http://www.ietf.org/html.charters/msec-charter.html
[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.
[msec-gdoi], RFC 3547] M. Baugher , et al, "GDOI: The Group Domain
of Interpretation", RFC 3547.
[msec-ipsec-ext] Weis B., et al, "Multicast Extensions to the
Security Architecture for the Internet", <draft-ietf-msec-ipsec-
extensions-00.txt>, IETF Work in Progress.
[NAT, RFC 3715] B. Aboba and W Dixson, "IPsec-Network Address
Translation (NAT) Compatibility Requirements"
[TLS] http://www.ietf.org/html.charters/tls-charter.html
[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.
[RFC2401] Kent, S., et al, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[RFC2401BIS] Kent, S. and Seo K., "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt, March, 2005.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood,
"Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July
2004.
Expires Feb. 2005 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
10.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
Stephane Combes
Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse
France
E-Mail: stephane.combes@space.alcatel.fr
Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse
France
E-Mail: Laurence.Duquerroy@space.alcatel.fr
11. IPR Notices
11.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 any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
Expires Feb. 2005 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11.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.
12. Copyright Statement
Copyright (C) The Internet Society (2005).
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.
13. IANA Considerations
This document does not define any protocol and does not require any
IANA assignments.
Expires Feb. 2005 [page 13]