[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: I-D submission (draft-cruickshank-ipdvb-sec-req-02.txt)
Dear ipdvb WG,
Many thanks to Gorry for submitting the above draft
(draft-cruickshank-ipdvb-sec-req-02.txt) on our behalf. We would like
the ipdvb WG to adopt this work as WG work item, please.
First many thanks to Prashant for all his comments and his name is added
to the new draft.
I will try to summarise the comments from ipdvb WG and our responses
that added to the new draft: There were several questions related ULE
source authentication and protection against replays attacks are they
mandatory or optional. In order to clarify the security requirement,
three scenarios are added to section 2.1:
o Scenario 1: Monitoring (passive threat). Here the intruder
monitors the ULE broadcasts in order to gain information about ULE data
and/or tracking the communicating parties.
o Scenario 2: Local high jacking of the MPEG-TS multiplex (active
threat). Here we assume an intruder is sophisticated and able to block
the original transmission from the ULE Encapsulation Gateway and deliver
a modified version of the MPEG-TS transmission to a single ULE Receiver
or a small group of Receivers (e.g. in a single company site
o Scenario 3: Global high jacking of the MPEG-TS multiplex (active
threat). Here we assume an intruder is very sophisticated and able to
high jack the whole MPEG transmission multiplex.
In addition, Section 3 analysis these scenarios further and extract the
security requirements:
o Scenario 1: Data confidentiality MUST be provided to prevent
monitoring of the ULE data (such as IP packet and user information).
Also ULE MAC address hiding MUST be provided to prevent access to
communicating parties' identity and tracking their communications.
These requirements are mandatory for a ULE security system. Identity
hiding is used mobile phone networks such as GSM and UMTS.
o Scenario 2: In addition to scenario 1 requirements, new
measures are needed to be implemented such as source authentication and
using sequence numbers to prevent replay attacks. However, scenario 2
threats can happen only in specific service cases and therefore source
authentication and sequence numbers SHOULD be optional for the ULE
security system because of the extra overheads it incurs.
o Scenario 3: ULE security system can not protect against such
attacks. This scenario is out of scope for this document.
Finally and regarding ULE security implementation plans: We are in
process of submitting a related draft that describes the actual ULE
security format with extension headers. We intend and plan to have an
implementation ready by the end of the year. Would any other people
also be interested in collaborating or developing their own
implementations?
Haitham (& all co-authors)
----
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
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: 19 June 2006 10:05
To: Internet-Drafts Administrator
Cc: Gorry Fairhurst; Cruickshank HS Dr (CCSR)
Subject: I-D submission (draft-cruickshank-ipdvb-sec-req-02.txt)
I'm submitting this on behalf of the authors,
Gorry Fairhurst
(ipdvb WG Chair)
Internet Engineering Task Force H.Cruickshank
Internet Draft S. Iyengar
draft-cruickshank-ipdvb-sec-req-02.txt University of Surrey, UK
L. Duquerroy
Alcatel Alenia Space, France
Expires: December 2006 P. Pillai
University of Bradford, UK
Category: Internet Draft June 16, 2006
Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol
draft-cruickshank-ipdvb-sec-req-02.txt
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/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 December 16, 2006.
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
Cruickshank Expires December 15, 2006 [Page 1]
Internet-Draft Security Requirements for ULE June 2006
the motivation for ULE link-level security. This work is intended
as a work item of the ipdvb WG, and contributions are sought from
the IETF on this topic.
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 [1].
Table of Contents
1. Introduction 2
1.1. System Components 4
2. Threat Analysis 4
2.1. Threat Scenarios 5
2.1.1. Scenario 1: Monitoring (passive threat) 5
2.1.2. Scenario 2: Local highjacking of the MPEG-TS
multiplex (active threat) 6
2.1.3. Scenario 3: Global high jacking of the MPEG-TS
multiplex (active threat) 6
3. Security Requirements for IP over MPEG-2 TS 6
4. IPsec and MPEG-2 Transmission Networks 8
4.1. Tunnel mode use of IPsec for multicast 9
4.2. IPsec and L2 security 9
5. Motivation for ULE link-layer security 10
5.1. Link security below the Encapsulation layer 11
5.2. Link security as a part of the Encapsulation layer 11
6. Summary 12
7. Security Considerations 13
8. IANA Considerations 13
9. Acknowledgments 13
10. References 14
10.1. Normative References 14
10.2. Informative References 14
Author's Addresses 15
Intellectual Property Statement 16
Disclaimer of Validity 16
Copyright Statement 16
1. Introduction
In the security considerations section of RFC 4259[2], there is
an initial analysis of the security requirements in MPEG-2
transmission networks. For example, when the MPEG-2 transmission
Cruickshank Expires December 15, 2006 [Page 2]
Internet-Draft Security Requirements for ULE June 2006
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 [16]. RFC 4259 recommends
that any new encapsulation defined by the IETF allows Transport
Stream encryption and also supports optional link level
encryption/authentication of the SNDU payload. In ULE [3], this
may be provided in a flexible way using Extension Headers. This
requires definition of a mandatory header extension, but has the
advantage that it decouples specification of the security
functions from the encapsulation functions. This method also
supports hiding of the NPA/MAC addresses.
This document extends the above analysis and derives the security
requirements for ULE.
The main objective of this document is to specify the
requirements for securing the link between the Encapsulation
Gateways (ULE source) and Receivers only. In addition, this
document provides an overview of the threat analysis for 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 [3] can be
used 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.
Important 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 [2]. 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.
In MPEG-2 transmission network there are several signalling
messages that are broadcast by the Encapsulator or Multiplexor
in the form of tables. Examples of these signalling messages or
(SI tables) are PAT - Program Association Table, PMT - Program
Cruickshank Expires December 15, 2006 [Page 3]
Internet-Draft Security Requirements for ULE June 2006
Map Table and NIT - Network Information Table. In existing MPEG-
2 transmission networks, these messages are broadcast in clear
(no encryption or integrity checks). The integrity of these
messages is important for the correct working of the ULE network.
However, securing these messages is out of scope for ULE
security.
1.1. System Components
There are several entities in within the MPEG-2 transmission
network architecture, as defined in [2]). These include (ULE)
Encapsulation Gateways, TS multiplexers (including re-
multiplexers), modulators and Receivers.
The ULE link security focuses on security between the
Encapsulation Gateways (ULE source) and Receivers only.
2. Threat Analysis
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 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:
o Masquerading: where an entity pretends to be a different
entity. This includes masquerading other users and subnetwork
control plane messages.
o Modification of messages in an unauthorised manner.
Cruickshank Expires December 15, 2006 [Page 4]
Internet-Draft Security Requirements for ULE June 2006
o 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.
o Replay attacks: When an intruder sends some old (authentic)
messages to the Receiver.
o 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.
Active threats such as masquerading, replay, modification of
messages and injecting IP packet attacks are major security
concerns for the Internet community and several of these attacks
have been described [5]. 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. Therefore ULE authentication and integrity checks are
required. IPsec can be used to provide source authentication but
has some disadvantages; further analysis on IPsec is presented in
section 4.
2.1. Threat Scenarios
In normal MPEG transmission networks packets are transmitted by
the ULE Encapsulation Gateway to the ULE Receivers. This is
sometimes called a star topology which is the main focus of this
document. Mesh topologies where ULE Receivers are ULE sources as
well are out of scope of this document.
In the star topology, three threat scenarios can be envisaged:
2.1.1. Scenario 1: Monitoring (passive threat)
Here the intruder monitors the ULE broadcasts in order to gain
information about ULE data and/or tracking the communicating
parties. In this scenario, measures should be taken to hide the
ULE data and the ULE Receivers identity.
Cruickshank Expires December 15, 2006 [Page 5]
Internet-Draft Security Requirements for ULE June 2006
2.1.2. Scenario 2: Local high jacking of the MPEG-TS multiplex
(active threat)
Here we assume an intruder is sophisticated and able to block the
original transmission from the ULE Encapsulation Gateway and
deliver a modified version of the MPEG-TS transmission to a
single ULE Receiver or a small group of Receivers (e.g. in a
single company site). The MPEG transmission network might not be
aware of such attacks. In addition to the security requirements
for scenario 1, here extra measures should be taken to ensure ULE
source authentication and preventing replay of old messages.
2.1.3. Scenario 3: Global high jacking of the MPEG-TS multiplex
(active threat)
Here we assume an intruder is very sophisticated and able to high
jack the whole MPEG transmission multiplex. The requirements here
are similar to scenario 2. The MPEG transmission network can
quickly identify such attacks. This type of attack cannot be
protected against with a ULE security system. The MPEG
transmission network must resort to other means to restore the
original transmissions.
In terms of priority, scenario 1 is considered the major threat
in MPEG transmission systems. Scenario 2 is likely to a smaller
degree in certain cases and hence the extra protections should be
optional and used only when such threat is a possibility to some
MPEG transmission services. Scenario 3 is not envisaged to be a
practical because it will be very difficult to pass unnoticed by
the MPEG transmission operator. Therefore scenario 3 is out of
scope for this document.
3. Security Requirements for IP over MPEG-2 TS
From the above analysis, the following security requirements can
be derived:
o Data confidentiality is the major requirement against passive
threats (using encryption). L2 encryption or L3 (IPsec)
encryption can satisfy this requirement.
o Hiding 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.
o For active threats: ULE source authentication and data
Cruickshank Expires December 15, 2006 [Page 6]
Internet-Draft Security Requirements for ULE June 2006
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 such as SI tables are another
optional requirement, but are outside the scope of ULE
security.
o Layer L2 endpoint authentication: This will be part of the key
management. It will be performed during the initial key
exchange and authentication phase.
o End-to-end security (such as IPsec and TLS [13]) and ULE link
security should work in parallel without obstructing each
other.
o 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 [9] and GDOI [10]), plus other
systems such as DVB-RCS [6] and/or the development of new
systems, as required.
o Other general requirements are:
o Protection of the management system and the infrastructure
from unauthorized people. ULE encryption will provide
partial protection through the key management procedures
and data encryption.
o 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.
o Compatibility with other networking functions: Other
networking functions such as NAT (Network Address
Translation) [12] or TCP acceleration can be used in a
Cruickshank Expires December 15, 2006 [Page 7]
Internet-Draft Security Requirements for ULE June 2006
wireless DVB networks (see RFC3135). The ULE security
solution should be compatible with functions such as
NAT/NAPT, IPsec, TLS, etc.
o 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.
Examining scenarios 1 and 2 in section 2.1., the requirements for
each scenario can be summarised as:
Scenario 1: Data confidentiality MUST be provided to prevent
monitoring of the ULE data (such as IP packet and user
information). Also ULE MAC address hiding should be provided to
prevent access to communicating parties' identity and tracking
their communications. These requirements are mandatory for a ULE
security system.
Scenario 2: In addition to scenario 1 requirements, additional
measures need to be implemented such as source authentication and
using sequence numbers to prevent replay attacks. This will stop
intruders from injecting their own data into the MPEG-TS stream.
However, scenario 2 threats can happen only in specific service
cases and therefore source authentication and sequence numbers
SHOULD be optional for the ULE security system because of the
extra overheads it incurs.
Scenario 3: ULE security system can not protect against such
attacks.
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 [15]
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.
Cruickshank Expires December 15, 2006 [Page 8]
Internet-Draft Security Requirements for ULE June 2006
However IPsec is not well-suited to protect the identity of the
ULE encapsulator/Receivers to provide this. The interfaces of
these devices also do not necessarily have IP addresses (they can
be L2 devices).
In addition, IP Multicast is considered as a major service over
MPEG-2 Transmission Networks. A document produced by the IETF
Multicast Security (msec) [8] Working Group on IPsec extensions
for multicast [11] describes extensions to [15] 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 Encapsulators and Receivers are
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 document referenced in
[11] 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:
o There is a need to protect the identity of ULE encapsulator /
receivers over the ULE broadcast medium; IPsec is not suitable
for providing this service.
Cruickshank Expires December 15, 2006 [Page 9]
Internet-Draft Security Requirements for ULE June 2006
o There is an extra overheads associated with using IPsec in
tunnel mode, i.e. the extra IP header (IPv4 or IPv6).
o Multicast is considered as a major service over ULE links. The
current IPsec specifications [15] only define a pairwise
tunnel between two IPsec devices with manual keying. Work in
progress [11] is defining the extra detail needed for
multicast and to use the tunnel mode with address preservation
as described in section 4.1.
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 [11]
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.
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
[7], but in addition provides link confidentiality and Receiver
identity hiding.
End-to-end security, IPsec and ULE link security (between ULE
Encapsulation Gateway to the ULE Receivers) can 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 envisaged.
A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as the MSEC [9] and GDOI
[10]. This does not preclude the use of other key management
methods in scenarios that benefit from this.
Cruickshank Expires December 15, 2006 [Page 10]
Internet-Draft Security Requirements for ULE June 2006
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 using a common PID. Therefore all multiplexed traffic
will share the same security keys.
This has the following advantages:
o 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.
o This method does not preclude the use of IPsec, or any other
form of higher-layer security.
However it has the following disadvantages:
o 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. Therefore it does not have the flexibility to
secure every individual IP connection separately.
o ULE Receivers will be able to see the private traffic destined
to other ULE Receivers, since they share a common key.
o If the key is compromised, then this will impact several ULE
Receivers. Existing access control mechanisms have limited
flexibility in terms of controlling the use of key and
rekeying. IETF based key management are not used in existing
systems.
In practice there are not many L2 security systems for MPEG
transmission networks. Conditional access for digital TV
broadcasting is one example that exists today. This system is
optimised for TV services and will be suitable to IP packet
transmissions. Some other systems are specified in standards such
the MPE [4] system. However, there are no known implementations
of such systems.
5.2. Link security as a part of the Encapsulation layer
Therefore major advantages for ULE link security are:
o The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses.
Cruickshank Expires December 15, 2006 [Page 11]
Internet-Draft Security Requirements for ULE June 2006
o Ability to protect the identity of the Receiver within the
MPEG-2 transmission network.
o Efficient protection of IP multicast over ULE links.
o Transparency to the use of Network Address Translation (NATs)
[12] and TCP Performance Enhancing Proxies (PEP) [14], which
require the ability to inspect and modify the packets sent
over the ULE link.
o 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 [4], 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, 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 using HMACs is one
possibility which an associated overheads per ULE packets.
Another possibility is to use lightweight data integrity methods
or procedures can be provided by the ULE security system. In
addition sequence numbers can provide protection against replay
attacks.
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
Cruickshank Expires December 15, 2006 [Page 12]
Internet-Draft Security Requirements for ULE June 2006
Encapsulation layer. In summary, there is a strong need for L2
encryption and ULE Receiver identity hiding.
There is an addition need (optional) for L2 source authentication
and protection against insertion of other data into the ULE
stream (i.e. data integrity). This is optional because of the
associated overheads for the extra features and they are only
required for specific service cases.
7. 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.
8. IANA Considerations
This document does not define any protocol and does not require
any IANA assignments.
9. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen), Stephane Coombes (ESA) and Y.F. Hu
(University of Bradford) in the preparation of this draft.
Cruickshank Expires December 15, 2006 [Page 13]
Internet-Draft Security Requirements for ULE June 2006
10. References
10.1. Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] 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.
[3] 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.
[4] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).
10.2. Informative References
[5] Bellovin, S., "Problem Area for the IP Security protocols",
Computer Communications Review 2:19, pp. 32-48, April 989.
http://www.cs.columbia.edu/~smb/
[6] "Digital Video Broadcasting (DVB) -- interaction channel
for satellite distribution systems", ETSI EN 301 790 V1.4.1
(2005-04)
[7] http://www.ietf.org/html.charters/wg-
dir.html#Security%20Area. RFCs 2401, 2402 and 2406
[8] http://www.ietf.org/html.charters/msec-charter.html
[9] H Harney (SPARTA), et al, "GSAKMP: Group Secure Association
Group Management Protocol", <draft-ietf-msec-gsakmp-sec-
10.txt>, IETF Work in Progress.
[10] M. Baugher, et al, "GDOI: The Group Domain of
Interpretation", RFC 3547.
[11] Weis B., et al, "Multicast Extensions to the Security
Architecture for the Internet", <draft-ietf-msec-ipsec-
extensions-01.txt>, IETF Work in Progress.
Cruickshank Expires December 15, 2006 [Page 14]
Internet-Draft Security Requirements for ULE June 2006
[12] B. Aboba and W Dixson, "IPsec-Network Address Translation
(NAT) Compatibility Requirements"
[13] http://www.ietf.org/html.charters/tls-charter.html
[14] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001.
[15] Kent, S. and Seo K., "Security Architecture for the
Internet Protocol", RFC 4301, December 2006.
[16] 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.
Author's 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 Space, Toulouse
France
E-Mail: Laurence.Duquerroy@space.alcatel.fr
Prashant Pillai
Mobile and Satellite Communications Research Centre
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: P.Pillai@bradford.ac.uk
Cruickshank Expires December 15, 2006 [Page 15]
Internet-Draft Security Requirements for ULE June 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.
Cruickshank Expires December 15, 2006 [Page 16]