--
Dr. Haitham S. Cruickshank
Lecturer
Communications Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey, Guildford, Surrey GU2 7XH, UK
Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
Internet Engineering Task Force H. Cruickshank
Internet Draft S. Iyengar
Document: draft-cruickshank-ipdvb-sec?req-01.txt University of Surrey
S. Combes
L. Duquerroy
Alcatel Space
Category: Internet Draft 6 September 2005
Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol
Status of this Draft
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
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 describing 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 the 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 supported
applications 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 ULE network architecture,
as defined in [ipdvb-arch]), such as 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 March 2006 [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 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; 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 security field, however this is more problematic
in 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 March 2006 [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. As such, Steve Bellovin [Bellovin] describes
several of these attacks. 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 (Encapsulation Gateways) 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 with 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 March 2006 [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 overheads.
- Optional protection of Layer 2 MAC/NPA address. This is needed
particularly in the MPEG-2 broadcast networks to stop intruder
gaining information by just knowing the identity of the
communicating parties and the volume of their traffic. IPsec can
not provide this service, however it 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. Also 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.
- 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.
. Operational issues: Because of the possible large coverage of
broadcast transmission network, it may be required to deliver
data to many different countries that may have different
Expires March 2006 [page 5]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
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 tunneled
IP packets. In both modes, data integrity is provided and in
addition, ESP provides 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. The msec document on IPsec extensions for
multicast [msec-ipsec-ext] describes extensions to [RFC2401BIS] that
further define the IPsec security architecture for packets with a
multicast address in the IP destination field 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 the ULE link, then the ULE gateways and Receivers are
equivalent to 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 tunnel
mode to encapsulate incoming fragments.
Expires March 2006 [page 6]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
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 method 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 defines pairwise
tunnel between two IPsec devices with manual keying. The [msec-
ipsec-ext] document, work in progress in defining the extra
details needed for multicast and the tunnel mode with address
preservation. In the ULE link context, in addition to the IPsec
tunnelling overheads, the source and destination address
preservation means that these IP address broadcast in the clear.
This will weaken further the identity hiding concept over the
MPEG-2 transmission links. However [msec-ipsec-ext] document
mentions the possibility of multicast data is sent through a
service provider network, and encapsulated under a different IP
multicast address while in the provider network. Similarly the
source address on the outside IP header could be changed to that
of the DVB gateway.
Expires March 2006 [page 7]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
5. Motivation for ULE link layer security
Examining the threat analysis and security requirements in sections
2 and 3 show 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)
might not be sufficient.
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 end-to-end security
between hosts and ULE providing security over the MPEG-2
transmission link. However, there is no direct interaction between
the IPsec and the ULE security system.
ULE may 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 which
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 MPEG-TS may multiplex several IP streams
and/or other MPEG services using a common PID. Therefore all
multiplexed traffic will share the same security keys. This had the
following disadvantages:
- Each ULE Receiver needs to decrypt some MPG-TS packets that does
not need
- ULE Receivers will be able to see the private traffic destined to
other ULE Receivers sharing the same key.
- 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.
Expires March 2006 [page 8]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
- 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, show 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. 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. Therefore new lightweight data integrity methods
or procedures can be provided by the ULE security system
Therefore the ULE security system should be incremental and provides
ULE link encryption as a basic service. Addition services such as
data 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
Expires March 2006 [page 9]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
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 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 provides threat analysis and derives the security
requirements to provide optional link encryption and link level
integrity / authentication of the SNDU payload.
8. 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.
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
Expires March 2006 [page 10]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
[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 .
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
Expires March 2006 [page 11]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
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
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
Expires March 2006 [page 12]
INTERNET DRAFT Encapsulation for IP over MPEG-2/DVB Sept. 2005
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 March 2006 [page 13]