draft-ietf-ipdvb-sec-req-05.txt   draft-ietf-ipdvb-sec-req-06.txt 
IPDVB Working Group H. Cruickshank IPDVB Working Group H. Cruickshank
Internet-Draft S. Iyengar Internet-Draft S. Iyengar
Intended status: Informational University of Surrey, UK Intended status: Informational University of Surrey, UK
P. Pillai P. Pillai
Expires: April 12, 2008 University of Bradford, UK Expires: October 4, 2008 University of Bradford, UK
November 18, 2007 April 4, 2008
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-05.txt draft-ietf-ipdvb-sec-req-06.txt
Status of this Draft Status of this Draft
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 38 skipping to change at page 1, line 38
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 12, 2008. This Internet-Draft will expire on October 4, 2008.
Abstract Abstract
The MPEG-2 standard defined by ISO 13818-1 supports a range of The MPEG-2 standard defined by ISO 13818-1 supports a range of
transmission methods for a range of services. This document transmission methods for a range of services. This document
provides a threat analysis and derives the security requirements provides a threat analysis and derives the security requirements
when using the Transport Stream, TS, to support an Internet when using the Transport Stream, TS, to support an Internet
network-layer using Unidirectional Lightweight Encapsulation network-layer using Unidirectional Lightweight Encapsulation
(ULE) defined in RFC4326. The document also provides the (ULE) defined in RFC4326. The document also provides the
motivation for link-layer security for a ULE Stream. A ULE Stream motivation for link-layer security for a ULE Stream. A ULE Stream
may be used to send IPv4 packets, IPv6 packets, and other may be used to send IPv4 packets, IPv6 packets, and other
Protocol Data Units (PDUs) to an arbitrarily large number of Protocol Data Units (PDUs) to an arbitrarily large number of
Receivers supporting unicast and/or multicast transmission. Receivers supporting unicast and/or multicast transmission.
Table of Contents Table of Contents
1. Introduction................................................2 1. Introduction................................................2
2. Requirements notation.......................................4 2. Requirements notation.......................................3
3. Threat Analysis.............................................6 3. Threat Analysis.............................................6
3.1. System Components......................................6 3.1. System Components......................................6
3.2. Threats................................................9 3.2. Threats................................................9
3.3. Threat Scenarios......................................10 3.3. Threat Scenarios......................................10
4. Security Requirements for IP over MPEG-2 TS................11 4. Security Requirements for IP over MPEG-2 TS................11
5. Motivation for ULE link-layer security.....................13 5. Design recommendations for ULE Security Header Extension...13
5.1. Security at the IP layer (using IPSEC)................13 6. Compatibility with Generic Stream Encapsulation............14
5.2. Link security below the Encapsulation layer...........14 7. Summary....................................................14
5.3. Link security as a part of the encapsulation layer....15 8. Security Considerations....................................15
6. Design recommendations for ULE Security Header Extension...16 9. IANA Considerations........................................16
7. Compatibility with Generic Stream Encapsulation............17 10. Acknowledgments...........................................16
8. Summary....................................................17 11. References................................................16
9. Security Considerations....................................18 11.1. Normative References.................................16
10. IANA Considerations.......................................18 11.2. Informative References...............................16
11. Acknowledgments...........................................18 12. Author's Addresses........................................18
12. References................................................19 13. IPR Notices...............................................18
12.1. Normative References.................................19 13.1. Intellectual Property Statement......................19
12.2. Informative References...............................19 14. Copyright Statement.......................................19
13. Author's Addresses........................................21 Appendix A: ULE Security Framework............................20
14. IPR Notices...............................................21 Appendix B: Motivation for ULE link-layer security............24
14.1. Intellectual Property Statement......................21 Document History..............................................27
14.2. Intellectual Property................................22
15. Copyright Statement.......................................22
Appendix A: ULE Security Framework............................22
Document History..............................................28
1. Introduction 1. Introduction
The MPEG-2 Transport Stream (TS) has been widely accepted not The MPEG-2 Transport Stream (TS) has been widely accepted not
only for providing digital TV services, but also as a subnetwork only for providing digital TV services, but also as a subnetwork
technology for building IP networks. RFC 4326 [RFC4326] describes technology for building IP networks. RFC 4326 [RFC4326] describes
the Unidirectional Lightweight Encapsulation (ULE) mechanism for the Unidirectional Lightweight Encapsulation (ULE) mechanism for
the transport of IPv4 and IPv6 Datagrams and other network the transport of IPv4 and IPv6 Datagrams and other network
protocol packets directly over the ISO MPEG-2 Transport Stream as protocol packets directly over the ISO MPEG-2 Transport Stream as
TS Private Data. ULE specifies a base encapsulation format and TS Private Data. ULE specifies a base encapsulation format and
skipping to change at page 6, line 11 skipping to change at page 5, line 50
with a different PID value) [RFC4259]; for example, to with a different PID value) [RFC4259]; for example, to
redistribute the same multicast content to two terrestrial TV redistribute the same multicast content to two terrestrial TV
transmission cells. transmission cells.
TS Packet: A fixed-length 188B unit of data sent over a TS TS Packet: A fixed-length 188B unit of data sent over a TS
Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus
optional overhead including an Adaptation Field, encryption optional overhead including an Adaptation Field, encryption
details, and time stamp information to synchronise a set of details, and time stamp information to synchronise a set of
related TS Logical Channels. related TS Logical Channels.
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE
encapsulated PDUs. ULE Streams may be identified by definition of
a stream_type in SI/PSI [ISO-MPEG2].
3. Threat Analysis 3. Threat Analysis
3.1. System Components 3.1. System Components
+------------+ +------------+ +------------+ +------------+
| IP | | IP | | IP | | IP |
| End Host | | End Host | | End Host | | End Host |
+-----+------+ +------------+ +-----+------+ +------------+
| ^ | ^
+------------>+---------------+ | +------------>+---------------+ |
+ IP | | + ULE | |
+-------------+ Encapsulator | | +-------------+ Encapsulator | |
SI-Data | +------+--------+ | SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel | +-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | | | MPEG-2 | | |
| SI Tables | | | | SI Tables | | |
+-------+-------+ ->+------+--------+ | +-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . . | -->| MPEG-2 | . . .
+------------>+ Multiplexer | | +------------>+ Multiplexer | |
MPEG-2 TS +------+--------+ | MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux | Logical Channel |MPEG-2 TS Mux |
skipping to change at page 6, line 45 skipping to change at page 6, line 41
TS --->+ Multiplexer | | TS --->+ Multiplexer | |
---->+------+--------+ | ---->+------+--------+ |
|MPEG-2 TS Mux | |MPEG-2 TS Mux |
| | | |
+------+--------+ +------+-----+ +------+--------+ +------+-----+
|Physical Layer | | MPEG-2 | |Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver | |Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+ +---------------+ MPEG-2 +------------+
TS Mux TS Mux
Figure 1: An example configuration for a unidirectional service Figure 1: An example configuration for a unidirectional service
for IP transport over MPEG-2 [RFC4259]. for IP transport over MPEG-2 (adapted from [RFC4259]).
As shown in Figure 1 above (from section 3.3 of [RFC4259]), there As shown in Figure 1 above (from section 3.3 of [RFC4259]), there
are several entities within the MPEG-2 transmission network are several entities within the MPEG-2 transmission network
architecture. These include: architecture. These include:
o ULE Encapsulation Gateways (the Encapsulator or ULE source) o ULE Encapsulation Gateways (the ULE Encapsulator)
o SI-Table signalling generator (input to the multiplexer) o SI-Table signalling generator (input to the multiplexer)
o Receivers (the end points for ULE streams) o Receivers (the end points for ULE streams)
o TS multiplexers (including re-multiplexers) o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
In a MPEG-2 TS transmission network, the originating source of TS In a MPEG-2 TS transmission network, the originating source of TS
Packets is either a L2 interface device (media encoder, Packets is either a L2 interface device (media encoder,
encapsulation gateway, etc) or a L2 network device (TS encapsulation gateway, etc) or a L2 network device (TS
multiplexer, etc). These devices may, but do not necessarily, multiplexer, etc). These devices may, but do not necessarily,
skipping to change at page 8, line 20 skipping to change at page 8, line 17
broadcast in the clear (no encryption or integrity checks). The broadcast in the clear (no encryption or integrity checks). The
integrity as well as authenticity of these messages is important integrity as well as authenticity of these messages is important
for correct working of the ULE network, i.e. supporting its for correct working of the ULE network, i.e. supporting its
security objectives in the area of availability, in addition to security objectives in the area of availability, in addition to
confidentiality and integrity. One method recently proposed [ID- confidentiality and integrity. One method recently proposed [ID-
EXT] encapsulates these messages using ULE. In such cases all the EXT] encapsulates these messages using ULE. In such cases all the
security requirements of this document apply in securing these security requirements of this document apply in securing these
signalling messages. signalling messages.
ULE link security focuses only on the security between the ULE ULE link security focuses only on the security between the ULE
Encapsulation Gateway (ULE source) and the Receiver. In many Encapsulation Gateway (ULE Encapsulator) and the Receiver. In
deployment scenarios the user of a ULE Stream has to secure many deployment scenarios the user of a ULE Stream has to secure
communications beyond the link since other network links are communications beyond the link since other network links are
utilised in addition to the ULE link. Therefore, if utilised in addition to the ULE link. Therefore, if
authentication of the end-point i.e. the IP Sources is required, authentication of the end-point i.e. the IP Sources is required,
or users are concerned about loss of confidentiality, integrity or users are concerned about loss of confidentiality, integrity
or authenticity of their communication data, they will have to or authenticity of their communication data, they will have to
employ end-to-end network security mechanisms like IPSec or employ end-to-end network security mechanisms like IPSec or
Transport Layer Security (TLS). Governmental users may be forced Transport Layer Security (TLS). Governmental users may be forced
by regulations to employ specific, approved implementations of by regulations to employ specific, approved implementations of
those mechanisms. Hence for such cases the confidentiality and those mechanisms. Hence for such cases the confidentiality and
integrity of the user data will already be taken care of by the integrity of the user data will already be taken care of by the
skipping to change at line 479 skipping to change at page 10, line 47
o Case 3: Globally conduct active attacks on the MPEG-TS o Case 3: Globally conduct active attacks on the MPEG-TS
multiplex. Here we assume an intruder is very sophisticated multiplex. Here we assume an intruder is very sophisticated
and able to over-ride the whole MPEG-2 transmission multiplex. and able to over-ride the whole MPEG-2 transmission multiplex.
The requirements here are similar to scenario 2. The MPEG-2 The requirements here are similar to scenario 2. The MPEG-2
transmission network operator can usually identify such transmission network operator can usually identify such
attacks and may resort to some means to restore the original attacks and may resort to some means to restore the original
transmission. transmission.
For both cases 2 and 3, there can be two sub cases: For both cases 2 and 3, there can be two sub cases:
Cruickshank et.al. Expires April 12, 2008 [Page o Insider attacks i.e. active attacks from adversaries within
10] the network with knowledge of the secret material.
o Insider attacks i.e. active attacks from adversaries in the
known of secret material.
o Outsider attacks i.e. active attacks from outside of a virtual o Outsider attacks i.e. active attacks from outside of a virtual
private network. private network.
In terms of priority, case 1 is considered the major threat in In terms of priority, case 1 is considered the major threat in
MPEG-2 transmission systems. Case 2 is likely to a lesser degree MPEG-2 transmission systems. Case 2 is likely to a lesser degree
within certain network configurations, especially when there are within certain network configurations, especially when there are
insider attacks. Hence, protection against such active attacks insider attacks. Hence, protection against such active attacks
should be used only when such a threat is a real possibility. should be used only when such a threat is a real possibility.
Case 3 is envisaged to be less practical, because it will be very Case 3 is envisaged to be less practical, because it will be very
skipping to change at line 506 skipping to change at page 11, line 24
assumption being here is that physical access to the network assumption being here is that physical access to the network
components (multiplexers, etc) and/or connecting physical media components (multiplexers, etc) and/or connecting physical media
is secure. Therefore case 3 is not considered further in this is secure. Therefore case 3 is not considered further in this
document. document.
4. Security Requirements for IP over MPEG-2 TS 4. Security Requirements for IP over MPEG-2 TS
From the threat analysis in section 3, the following security From the threat analysis in section 3, the following security
requirements can be derived: requirements can be derived:
o Data confidentiality is the major requirement to mitigate Req 1. Data confidentiality MUST be considered in order to
passive threats in MPEG-2 broadcast networks. mitigate passive and active threats in MPEG-2 broadcast
networks.
o Protection of Layer 2 NPA address. In broadcast networks this Req 2. Protection of Layer 2 NPA address MAY be provided. In
protection can be used to prevent an intruder tracking the broadcast networks this protection can be used to prevent an
identity of ULE Receivers and the volume of their traffic. intruder tracking the identity of ULE Receivers and the volume
of their traffic.
o Integrity protection and authentication of the ULE source is Req 3. Integrity protection and authentication of the ULE source
required against active attacks described in section 3.2. MAY be provided to prevent active attacks described in section
3.2.
o Protection against replay attacks. This is required for the Req 4. Protection against replay attacks MAY be provided. This is
active attacks described in section 3.2. required for the active attacks described in section 3.2.
o Layer L2 ULE Source and Receiver authentication: This is Req 5. Layer L2 ULE Source and Receiver authentication MAY be
normally performed during the initial key exchange and provided. This is normally performed during the initial key
authentication phase, before the ULE Receiver can join a exchange and authentication phase, before the ULE Receiver can
secure session with the ULE Encapsulator (ULE source). This is join a secure session with the ULE Encapsulator (ULE source).
normally receiver to hub authentication and it could be either This is normally receiver to hub authentication and it could
unidirectional or bidirectional authentication based on the be either unidirectional or bidirectional authentication based
underlying key management protocol. on the underlying key management protocol.
Other general requirements are: Other general requirements are:
Cruickshank et.al. Expires April 12, 2008 [Page GReq (a) ULE key management functions SHALL be decoupled from ULE
11] security services such as encryption and source authentication.
This allows the independent development of both systems.
o Decoupling of ULE key management functions from ULE security
services such as encryption and source authentication. This
allows the independent development of both systems.
o Support for automated as well as manual insertion of keys and GReq (b) Support SHOULD be provided for automated as well as
policy into the relevant databases. manual insertion of keys and policy into the relevant
databases.
o Algorithm agility is needed. Changes in crypto algorithms, GReq (c) Algorithm agility MUST be supported. Changes in crypto
hashes as they become obsolete should be updated without algorithms, hashes as they become obsolete should be updated
affecting the overall security of the system. without affecting the overall security of the system.
o Traceability: To monitor transmission network using log files GReq (d) Traceability SHOULD be supported to monitor the
to record the activities in the network and detect any transmission network using log files to record the activities
intrusion. in the network and detect any intrusion.
o Protection against loss of service (availability) through GReq (e) Protection against loss of service (availability)
malicious reconfiguration of system components (see Figure 1). through malicious reconfiguration of system components (see
Figure 1) MUST be present.
o Compatibility with other networking functions such as NAT GReq (f) The security system MUST be compatible with other
Network Address Translation (NAT) [RFC3715] or TCP networking functions such as NAT Network Address Translation
acceleration can be used in a wireless broadcast networks. (NAT) [RFC3715] or TCP acceleration can be used in a wireless
broadcast networks.
o Compatibility and operational with ULE extension headers i.e. GReq (g) The security extension header MUST be compatible with
allow encryption of a compressed SNDU payload. other ULE extension headers
o Where a ULE Stream carries a set of IP traffic flows to GReq (h) Where a ULE Stream carries a set of IP traffic flows to
different destinations with a range of properties (multicast, different destinations with a range of properties (multicast,
unicast, etc), it is often not appropriate to provide IP unicast, etc), it is often not appropriate to provide IP
confidentiality services for the entire ULE Stream. For many confidentiality services for the entire ULE Stream. For many
expected applications of ULE, a finer-grain control is expected applications of ULE, a finer-grain control MAY
therefore required, at least permitting control of data therefore be required, at least permitting control of data
confidentiality/authorisation at the level of a single MAC/NPA confidentiality/authorisation at the level of a single MAC/NPA
address. address.
Examining the threat cases in section 3.3, the security Examining the threat cases in section 3.3, the security
requirements for each case can be summarised as: requirements for each case can be summarised as:
o Case 1: Data confidentiality MUST be provided to prevent o Case 1: Data confidentiality (Req 1) MUST be provided to
monitoring of the ULE data (such as user information and IP prevent monitoring of the ULE data (such as user information
addresses). Protection of NPA addresses MAY be provided to and IP addresses). Protection of NPA addresses (Req 2) MAY be
prevent tracking ULE Receivers and their communications. provided to prevent tracking ULE Receivers and their
communications.
o Case 2: In addition to case 1 requirements, new measures need o Case 2: In addition to case 1 requirements, new measures MAY
to be implemented such as authentication schemes using Message be implemented such as authentication schemes using Message
Authentication Codes, digital signatures or TESLA [RFC4082] in Authentication Codes, digital signatures or TESLA [RFC4082] in
order to provide integrity protection and source order to provide integrity protection and source
authentication (Req 2, Req 3 and Req 5). In addition sequence
numbers (Req 4) MAY be used to protect against replay attacks.
In terms of outsider attacks, group authentication using
Message Authentication Codes should provide the same level of
security (Req 3 and 5). This will significantly reduce the
ability of intruders to successfully inject their own data
into the MPEG-TS stream. However, scenario 2 threats apply
only in specific service cases, and therefore authentication
and protection against replay attacks are OPTIONAL. Such
measures incur additional transmission as well as processing
overheads. Moreover, intrusion detection systems may also be
needed by the MPEG-2 network operator. These should best be
coupled with perimeter security policy to monitor most denial-
of-service attacks.
Cruickshank et.al. Expires April 12, 2008 [Page o Case 3: As stated in section 3.3, the requirements here are
12]
authentication, and using sequence numbers to protect against
replay attacks. In terms of outsider attacks, group
authentication using Message Authentication Codes should
provide the same level of security. This will significantly
reduce the ability of intruders to successfully inject their
own data into the MPEG-TS stream. However, scenario 2 threats
apply only in specific service cases, and therefore
authentication and protection against replay attacks are
OPTIONAL. Such measures incur additional transmission as well
as processing overheads. Moreover, intrusion detection systems
may also be needed by the MPEG-2 network operator. These
should best be coupled with perimeter security policy to
monitor most denial-of-service attacks.
o Case 3: As stated in section 3.3. The requirements here are
similar to Case 2 but since the MPEG-2 transmission network similar to Case 2 but since the MPEG-2 transmission network
operator can usually identify such attacks the constraints on operator can usually identify such attacks the constraints on
intrusion detections are less than in case 2. intrusion detections are less than in case 2.
5. Motivation for ULE link-layer security The general requirements GReq(a) to GReq(h) are good security
practices and apply to all the scenarios above, where
Examination of the threat analysis and security requirements in appropriate.
sections 3 and 4 has shown that there is a need to provide
security in MPEG-2 transmission networks employing ULE. This
section compares the disadvantages when security functionalities
are present in different layers.
5.1. Security at the IP layer (using IPSEC)
The security architecture for the Internet Protocol [RFC4301]
describes security services for traffic at the IP layer. This
architecture primarily defines services for the Internet Protocol
(IP) unicast packets, as well as manually configured IP multicast
packets.
It is possible to use IPsec to secure ULE links. The major
advantage of IPsec is its wide implementation in IP routers and
hosts. IPsec in transport mode can be used for end-to-end
security transparently over MPEG-2 transmission links with little
impact.
In the context of MPEG-2 transmission links, if IPsec is used to
secure a ULE link, then the ULE Encapsulator and Receivers are
equivalent to the security gateways in IPsec terminology. A
security gateway implementation of IPsec uses tunnel mode. Such
usage has the following disadvantages:
Cruickshank et.al. Expires April 12, 2008 [Page
13]
o There is an extra transmission overhead associated with using
IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6).
o There is a need to protect the identity (NPA) of ULE Receivers
over the ULE broadcast medium; IPsec is not suitable for
providing this service. In addition, the interfaces of these
devices do not necessarily have IP addresses (they can be L2
devices).
o Multicast is considered a major service over ULE links. The
current IPsec specifications [RFC4301] only define a pairwise
tunnel between two IPsec devices with manual keying. Work is
in progress in defining the extra detail needed for multicast
and to use the tunnel mode with address preservation to allow
efficient multicasting. For further details refer to [WEIS06].
5.2. Link security below the Encapsulation layer
Link layer security can be provided at the MPEG-2 TS layer (below
ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
specific PID value. However, an MPEG-2 TS may typically multiplex
several IP flows, belonging to different users, 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, TLS, or any
other form of higher-layer security.
However it has the following disadvantages:
o When a PID is shared between several users, 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
separately secure individual IP flows.
o When a PID is shared between several users, the ULE Receivers
will have access to private traffic destined to other ULE
Receivers, since they share a common PID and key.
Cruickshank et.al. Expires April 12, 2008 [Page
14]
o IETF-based key management is not used in existing systems.
Existing access control mechanisms have limited flexibility in
terms of controlling the use of key and rekeying. Therefore if
the key is compromised, then this will impact several ULE
Receivers.
Currently there are few deployed L2 security systems for MPEG-2
transmission networks. Conditional access for digital TV
broadcasting is one example. However, this approach is optimised
for TV services and is not well-suited to IP packet transmission.
Some other systems are specified in standards such as MPE [ETSI-
DAT], but there are currently no known implementations.
5.3. Link security as a part of the encapsulation layer
Examining the threat analysis in section 3 has shown that
protection of ULE link from eavesdropping and ULE Receiver
identity are major requirements.
There are several major advantages in using ULE link layer
security:
o The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses. The protection can be applied either
per IP flow or per Receiver NPA address.
o Ability to protect the identity of the Receiver within the
MPEG-2 transmission network at the IP layer and also at L2.
o Efficient protection of IP multicast over ULE links.
o Transparency to the use of Network Address Translation (NATs)
[RFC3715] 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 at L3 (or TLS
[RFC4346] at L4). IPsec and TLS provide strong authentication of
the end-points in the communication.
L3 end-to-end security would partially deny the advantage listed
just above (use of PEP, compression etc), since those techniques
could only be applied to TCP packets bearing a TCP-encapsulated
IPsec packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression.
Cruickshank et.al. Expires April 12, 2008 [Page
15]
End-to-end security (IPsec, TLS, etc.) may be used independently
to provide strong authentication of the end-points in the
communication. This authentication is desirable in many scenarios
to ensure that the correct information is being exchanged between
the trusted parties, whereas Layer 2 methods cannot provide this
guarantee.
6. Design recommendations for ULE Security Header Extension 5. Design recommendations for ULE Security Header Extension
Table 1 below shows the threats that are applicable to ULE Table 1 below shows the threats that are applicable to ULE
networks and the relevant security mechanism to mitigate those networks and the relevant security mechanism to mitigate those
threats. This would help in the design of the ULE Security threats. This would help in the design of the ULE Security
extension header. For example this could help in the selection of extension header. For example this could help in the selection of
security fields in the ULE Security extension Header design. security fields in the ULE Security extension Header design.
Moreover the security services could also be grouped into Moreover the security services could also be grouped into
profiles based on different security requirements. One example is profiles based on different security requirements. One example is
to have a base profile which does payload encryption and identity to have a base profile which does payload encryption and identity
protection. The second profile could do the above as well as protection. The second profile could do the above as well as
source authentication. source authentication.
A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as GSAKMP [RFC4535] and
GDOI [RFC3547] protocols defined by the IETF Multicast Security
(MSEC) working group. This does not preclude the use of other key
management methods in scenarios where this is more appropriate.
IPsec or TLS also provide 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
established mechanisms and algorithms.
Mitigation of Threat Mitigation of Threat
----------------------------------------------- -----------------------------------------------
| Data | Data |Source |Data |Intru |Iden | | Data | Data |Source |Data |Intru |Iden |
|Privacy | fresh |Authent|Integ |sion |tity | |Privacy | fresh |Authent|Integ |sion |tity |
| | ness |ication|rity |Dete |Prote | | | ness |ication|rity |Dete |Prote |
| | | | |ction |ction | | | | | |ction |ction |
Attack | | | | | | | Attack | | | | | | |
---------------|--------|-------|-------|-------|-------|------| ---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X | | Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------| |---------------------------------------------------------------|
skipping to change at line 770 skipping to change at page 14, line 28
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Replay Attacks| - | X | X | X | X | - | | Replay Attacks| - | X | X | X | X | - |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Dos Attacks | - | X | X | X | X | - | | Dos Attacks | - | X | X | X | X | - |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Modification | - | - | X | X | X | - | | Modification | - | - | X | X | X | - |
| of Messages | | | | | | | | of Messages | | | | | | |
--------------------------------------------------------------- ---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats Table 1: Security techniques to mitigate network threats
in ULE Networks. in ULE Networks.
A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as GSAKMP [RFC4535] and
GDOI [RFC3547] protocols defined by the IETF Multicast Security
(MSEC) working group. This does not preclude the use of other key
management methods in scenarios where this is more appropriate.
Cruickshank et.al. Expires April 12, 2008 [Page
16]
IPsec or TLS also provide a proven security architecture defining 6. Compatibility with Generic Stream Encapsulation
key exchange mechanisms and the ability to use a range of
cryptographic algorithms. ULE security can make use of these
established mechanisms and algorithms.
7. Compatibility with Generic Stream Encapsulation
The [ID-EXT] document describes two new Header Extensions that The [ID-EXT] document describes two new Header Extensions that
may be used with Unidirectional Link Encapsulation, ULE, may be used with Unidirectional Link Encapsulation, ULE,
[RFC4326] and the Generic Stream Encapsulation (GSE) that has [RFC4326] and the Generic Stream Encapsulation (GSE) that has
been designed for the Generic Mode (also known as the Generic been designed for the Generic Mode (also known as the Generic
Stream (GS)), offered by second-generation DVB physical layers, Stream (GS)), offered by second-generation DVB physical layers,
and specifically for DVB-S2 [ID-EXT]. and specifically for DVB-S2 [ID-EXT].
The security threats and requirement presented in this document The security threats and requirement presented in this document
are applicable to ULE and GSE encapsulations. It might be are applicable to ULE and GSE encapsulations. It might be
desirable to authenticate some/all of the headers; such decision desirable to authenticate some/all of the headers; such decision
can be part of the security policy for the MPEG-2 transmission can be part of the security policy for the MPEG-2 transmission
network. network.
8. Summary 7. Summary
This document analyses a set of threats and security This document analyses a set of threats and security
requirements. It also defines the requirements for ULE security requirements. It also defines the requirements for ULE security
and states the motivation for link security as a part of the and states the motivation for link security as a part of the
Encapsulation layer. Encapsulation layer.
ULE security includes a need to provide link-layer encryption and ULE security includes a need to provide link-layer encryption and
ULE Receiver identity protection. There is an optional ULE Receiver identity protection. There is an optional
requirement for link-layer authentication and integrity assurance requirement for link-layer authentication and integrity assurance
as well as protection against insertion of old (duplicated) data as well as protection against insertion of old (duplicated) data
skipping to change at line 825 skipping to change at page 15, line 24
Receivers) is considered as an additional security mechanism to Receivers) is considered as an additional security mechanism to
IPsec, TLS, and application layer end-to-end security, and not as IPsec, TLS, and application layer end-to-end security, and not as
a replacement. It allows a network operator to provide similar a replacement. It allows a network operator to provide similar
functions to that of IPsec, but in addition provides MPEG-2 functions to that of IPsec, but in addition provides MPEG-2
transmission link confidentiality and protection of ULE Receiver transmission link confidentiality and protection of ULE Receiver
identity (NPA). End-to-end security mechanism may then be used identity (NPA). End-to-end security mechanism may then be used
additionally and independently for providing strong additionally and independently for providing strong
authentication of the end-points in the communication. authentication of the end-points in the communication.
Annexe 1 describes a set of building blocks that may be used to Annexe 1 describes a set of building blocks that may be used to
Cruickshank et.al. Expires April 12, 2008 [Page
17]
realise a framework that provides ULE security functions. realise a framework that provides ULE security functions.
9. Security Considerations 8. Security Considerations
Link-layer (L2) encryption of IP traffic is commonly used in Link-layer (L2) encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g. broadcast/radio links to supplement End-to-End security (e.g.
provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301). provided by TLS [RFC4346], SSH [RFC4251], IPsec [RFC4301).
A common objective is to provide the same level of privacy as A common objective is to provide the same level of privacy as
wired links. It is recommended that an ISP or user provide end- wired links. It is recommended that an ISP or user provide end-
to-end security services based on well known mechanisms such as to-end security services based on well known mechanisms such as
IPsec or TLS. IPsec or TLS.
skipping to change at line 864 skipping to change at page 16, line 11
bridged networking environment. The removal for bridged bridged networking environment. The removal for bridged
frames exposes the traffic to potentially undetected frames exposes the traffic to potentially undetected
corruption while being processed by the Encapsulator and/or corruption while being processed by the Encapsulator and/or
Receiver. Receiver.
o There is a potential security issue when a Receiver receives a o There is a potential security issue when a Receiver receives a
PDU with two Length fields: The Receiver would need to PDU with two Length fields: The Receiver would need to
validate the actual length and the Length field and ensure validate the actual length and the Length field and ensure
that inconsistent values are not propagated by the network. that inconsistent values are not propagated by the network.
10. IANA Considerations 9. IANA Considerations
This document does not define any protocol and does not require There are no IANA actions defined in this document.
any IANA assignments but a subsequent document that defines a
layer 2 security extension to ULE will require IANA involvement.
11. Acknowledgments 10. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen). The authors also acknowledge (University of Aberdeen). The authors also acknowledge
contributions from Laurence Duquerroy and Stephane Coombes (ESA), contributions from Laurence Duquerroy and Stephane Coombes (ESA),
Cruickshank et.al. Expires April 12, 2008 [Page
18]
Yim Fun Hu (University of Bradford) and Michael Noisternig from Yim Fun Hu (University of Bradford) and Michael Noisternig from
University of Salzburg. University of Salzburg.
12. References 11. References
12.1. Normative References 11.1. Normative References
[ISO-MPEG2] "Information technology -- generic coding of moving [ISO-MPEG2] "Information technology -- generic coding of moving
pictures and associated audio information systems, pictures and associated audio information systems,
Part I", ISO 13818-1, International Standards Part I", ISO 13818-1, International Standards
Organisation (ISO), 2000. Organisation (ISO), 2000.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
12.2. Informative References 11.2. Informative References
[ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", Mechanisms for IP Datagrams over MPEG-2 Networks",
Work in Progress <draft-ietf-ipdvb-ar-05.txt. Work in Progress <draft-ietf-ipdvb-ar-05.txt.
[ID-EXT] G. Fairhurst and B. Collini-Nocker, "Extension [ID-EXT] G. Fairhurst and B. Collini-Nocker, "Extension
Formats for Unidirectional Lightweight Encapsulation Formats for Unidirectional Lightweight Encapsulation
(ULE) and the Generic Stream Encapsulation (GSE)", (ULE) and the Generic Stream Encapsulation (GSE)",
Work in Progress, draft-ietf-ipdvb-ule-ext-06.txt, Work in Progress, draft-ietf-ipdvb-ule-ext-07.txt,
August 2007. January 2008.
[IEEE-802] "Local and metropolitan area networks-Specific [IEEE-802] "Local and metropolitan area networks-Specific
requirements Part 2: Logical Link Control", IEEE requirements Part 2: Logical Link Control", IEEE
802.2, IEEE Computer Society, (also ISO/IEC 8802-2), 802.2, IEEE Computer Society, (also ISO/IEC 8802-2),
1998. 1998.
[ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International [ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International
Standards Organisation (ISO), 1998. Standards Organisation (ISO), 1998.
[ITU-H222] H.222.0, "Information technology, Generic coding of [ITU-H222] H.222.0, "Information technology, Generic coding of
moving pictures and associated audio information moving pictures and associated audio information
Systems", International Telecommunication Union, Systems", International Telecommunication Union,
(ITU-T), 1995. (ITU-T), 1995.
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H.,
Collini-Nocker, B., and H. Linder, "A Framework for Collini-Nocker, B., and H. Linder, "A Framework for
Transmission of IP Datagrams over MPEG-2 Networks", Transmission of IP Datagrams over MPEG-2 Networks",
IETF RFC 4259, November 2005. IETF RFC 4259, November 2005.
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Cruickshank et.al. Expires April 12, 2008 [Page
19]
Lightweight Encapsulation (ULE) for Transmission of Lightweight Encapsulation (ULE) for Transmission of
IP Datagrams over an MPEG-2 Transport Stream (TS)", IP Datagrams over an MPEG-2 Transport Stream (TS)",
IETF RFC 4326, December 2005. IETF RFC 4326, December 2005.
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB [ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI). Telecommunications Standards Institute (ETSI).
[BELLOVIN] S.Bellovin, "Problem Area for the IP Security [BELLOVIN] S.Bellovin, "Problem Area for the IP Security
protocols", Computer Communications Review 2:19, pp. protocols", Computer Communications Review 2:19, pp.
skipping to change at line 974 skipping to change at page 18, line 17
[RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing [RFC3135] J. Border, M. Kojo, eyt. al., "Performance Enhancing
Proxies Intended to Mitigate Link-Related Proxies Intended to Mitigate Link-Related
Degradations", IETF RFC 3135, June 2001. Degradations", IETF RFC 3135, June 2001.
[RFC4301] Kent, S. and Seo K., "Security Architecture for the [RFC4301] Kent, S. and Seo K., "Security Architecture for the
Internet Protocol", IETF RFC 4301, December 2006. Internet Protocol", IETF RFC 4301, December 2006.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork and L. Wood, "Advice for Internet Subnetwork
Cruickshank et.al. Expires April 12, 2008 [Page
20]
Designers", BCP 89, IETF RFC 3819, July 2004. Designers", BCP 89, IETF RFC 3819, July 2004.
[RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", IETF RFC 4251, January 2006. Protocol Architecture", IETF RFC 4251, January 2006.
13. Author's Addresses 12. Author's Addresses
Haitham Cruickshank Haitham Cruickshank
Centre for Communications System Research (CCSR) Centre for Communications System Research (CCSR)
University of Surrey University of Surrey
Guildford, Surrey, GU2 7XH Guildford, Surrey, GU2 7XH
UK UK
Email: h.cruickshank@surrey.ac.uk Email: h.cruickshank@surrey.ac.uk
Sunil Iyengar Sunil Iyengar
Centre for Communications System Research (CCSR) Centre for Communications System Research (CCSR)
skipping to change at line 1006 skipping to change at page 18, line 46
Email: S.Iyengar@surrey.ac.uk Email: S.Iyengar@surrey.ac.uk
Prashant Pillai Prashant Pillai
Mobile and Satellite Communications Research Centre (MSCRC) Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology School of Engineering, Design and Technology
University of Bradford University of Bradford
Richmond Road, Bradford BD7 1DP Richmond Road, Bradford BD7 1DP
UK UK
Email: p.pillai@bradford.ac.uk Email: p.pillai@bradford.ac.uk
14. IPR Notices 13. IPR Notices
Copyright (c) The IETF Trust (2007). Copyright (c) The IETF Trust (2007).
14.1. Intellectual Property Statement 13.1. Intellectual Property Statement
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Cruickshank et.al. Expires April 12, 2008 [Page This document and the information contained herein are provided
21] on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
This document and the information contained herein are provided on an IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF FITNESS FOR A PARTICULAR PURPOSE.
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be
pertain to the implementation or use of the technology described in claimed to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to
found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the
such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR
http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be required
this standard. Please address the information to the IETF at to implement this standard. Please address the information to
ietf-ipr@ietf.org. the IETF at ietf-ipr@ietf.org.
14. Copyright Statement
Copyright (C) The IETF Trust (2008).
Appendix A: ULE Security Framework Appendix A: ULE Security Framework
This section defines a security framework for the deployment of This section defines a security framework for the deployment of
secure ULE networks. secure ULE networks.
A.1 Building Blocks A.1 Building Blocks
This ULE Security framework defines the following building blocks This ULE Security framework defines the following building blocks
Cruickshank et.al. Expires April 12, 2008 [Page
22]
as shown in figure 2 below: as shown in figure 2 below:
o The Key Management Block o The Key Management Block
o The ULE Security Extension Header Block o The ULE Security Extension Header Block
o The ULE Databases Block o The ULE Databases Block
Within the Key Management block the communication between the Within the Key Management block the communication between the
Group Member entity and the Group Server entity happens in the Group Member entity and the Group Server entity happens in the
skipping to change at line 1114 skipping to change at page 21, line 14
| | / \ | | / \
| | | | | |
| | | | | |
+------+-+--------+ ULE Data +------+-+--------+ ULE Data
| ULE Security | Plane | ULE Security | Plane
| Extension Header| | | Extension Header| |
| Block | | | Block | |
+-----------------+ \ / +-----------------+ \ /
----- -----
Cruickshank et.al. Expires April 12, 2008 [Page
23]
Figure 2: Secure ULE Framework Building Blocks Figure 2: Secure ULE Framework Building Blocks
A.1.1 Key Management Block A.1.1 Key Management Block
A key management framework is required to provide security at the A key management framework is required to provide security at the
ULE level using extension headers. This key management framework ULE level using extension headers. This key management framework
is responsible for user authentication, access control, and is responsible for user authentication, access control, and
Security Association negotiation (which include the negotiations Security Association negotiation (which include the negotiations
of the security algorithms to be used and the generation of the of the security algorithms to be used and the generation of the
different session keys as well as policy material). The Key different session keys as well as policy material). The Key
management framework can be either automated or manual. Hence management framework can be either automated or manual. Hence
this key management client entity (shown as the Key Management this key management client entity (shown as the Key Management
Group Member block in figure 2) will be present in all ULE Group Member block in figure 2) will be present in all ULE
receivers as well as at the ULE sources (encapsulation gateways). receivers as well as at the ULE Encapsulators. The ULE
The ULE source could also be the Key Management Group Server Encapsulator could also be the Key Management Group Server Entity
Entity (shown as the Key Management Group Server block in figure (shown as the Key Management Group Server block in figure 2. This
2. This happens when the ULE source also acts as the Key happens when the ULE Encapsulator also acts as the Key Management
Management Group Server. Deployment may use either automated key Group Server. Deployment may use either automated key management
management protocols (e.g. GSAKMP [RFC4535]) or manual insertion protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying
of keying material. material.
A.1.2 ULE Extension Header Block A.1.2 ULE Extension Header Block
A new security extension header for the ULE protocol is required A new security extension header for the ULE protocol is required
to provide the security features of data confidentiality, data to provide the security features of data confidentiality, data
integrity, data authentication and mechanisms to prevent replay integrity, data authentication and mechanisms to prevent replay
attacks. Security keying material will be used for the different attacks. Security keying material will be used for the different
security algorithms (for encryption/decryption, MAC generation, security algorithms (for encryption/decryption, MAC generation,
etc.), which are used to meet the security requirements, etc.), which are used to meet the security requirements,
described in detail in Section 4 of this document. described in detail in Section 4 of this document.
This block will use the keying material and policy information from This block will use the keying material and policy information
the ULE security database block on the ULE payload to generate the from the ULE security database block on the ULE payload to
secure ULE Extension Header or to decipher the secure ULE extension generate the secure ULE Extension Header or to decipher the
header to get the ULE payload. An example overview of the ULE secure ULE extension header to get the ULE payload. An example
Security extension header format along with the ULE header and overview of the ULE Security extension header format along with
payload is shown in figure 3 below. There could be other extension the ULE header and payload is shown in figure 3 below. There
headers (either mandatory or optional). It is RECOMMENDED that these could be other extension headers (either mandatory or optional).
are placed after the security extension header. This permits full It is RECOMMENDED that these are placed after the security
protection for all headers. It avoids situations where the SNDU has extension header. This permits full protection for all headers.
to be discarded on processing the security extension header, while It avoids situations where the SNDU has to be discarded on
preceding headers have already have been evaluated. One exception is processing the security extension header, while preceding headers
the Timestamp extension which SHOULD precede the security extension have already have been evaluated. One exception is the Timestamp
extension which SHOULD precede the security extension header [ID-
Cruickshank et.al. Expires April 12, 2008 [Page EXT]. When applying the security services for example
24] confidentiality, input to the cipher algorithm will cover the
fields from the end of the security extension header to the end
header [ID-EXT].. When applying the security services for example of the PDU.
confidentiality, input to the cipher algorithm will cover the fields
from the end of the security extension header to the end of the PDU.
Cruickshank et.al. Expires April 12, 2008 [Page
25]
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Header Extension Placement Figure 3: ULE Security Header Extension Placement
A.1.3 ULE Security Databases Block A.1.3 ULE Security Databases Block
There needs to be two databases i.e. similar to the IPSec There needs to be two databases i.e. similar to the IPSec
databases. databases.
skipping to change at line 1215 skipping to change at page 23, line 15
While the first interface is used by the Key Management Block to While the first interface is used by the Key Management Block to
insert keys, security associations and policies into the ULE insert keys, security associations and policies into the ULE
Database Block, the second interface is used by the ULE Security Database Block, the second interface is used by the ULE Security
Extension Header Block to get the keys and policy material for Extension Header Block to get the keys and policy material for
generation of the security extension header. generation of the security extension header.
A.2.1 Key Management <-> ULE Security databases A.2.1 Key Management <-> ULE Security databases
This interface is between the Key Management group member block This interface is between the Key Management group member block
Cruickshank et.al. Expires April 12, 2008 [Page
26]
(GM client) and the ULE Security Database block (shown in figure (GM client) and the ULE Security Database block (shown in figure
2). The Key Management GM entity will communicate with the GCKS 2). The Key Management GM entity will communicate with the GCKS
and then get the relevant security information (keys, cipher and then get the relevant security information (keys, cipher
mode, security service, ULE_Security_ID and other relevant keying mode, security service, ULE_Security_ID and other relevant keying
material as well as policy) and insert this data into the ULE material as well as policy) and insert this data into the ULE
Security database block. The Key Management could be either Security database block. The Key Management could be either
automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]) or manually
inserted using this interface. The following three interface inserted using this interface. The following three interface
functions are defined: functions are defined:
skipping to change at line 1262 skipping to change at page 24, line 14
the ULE SNDU will first get the record from the Security Database the ULE SNDU will first get the record from the Security Database
using the ULE_Security_ID, the Destination Address and possibly using the ULE_Security_ID, the Destination Address and possibly
the PID. It then uses this information to decrypt the ULE the PID. It then uses this information to decrypt the ULE
extension header. For both cases (either send or receive traffic) extension header. For both cases (either send or receive traffic)
only one interface is needed since the only difference between only one interface is needed since the only difference between
the sender and receiver is the direction of the flow of traffic: the sender and receiver is the direction of the flow of traffic:
. Get_record_database (char * Database, char * record, char * . Get_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
Cruickshank et.al. Expires April 12, 2008 [Page Appendix B: Motivation for ULE link-layer security
27]
Examination of the threat analysis and security requirements in
sections 3 and 4 has shown that there is a need to provide
security in MPEG-2 transmission networks employing ULE. This
section compares the disadvantages when security functionalities
are present in different layers.
B.1 Security at the IP layer (using IPsec)
The security architecture for the Internet Protocol [RFC4301]
describes security services for traffic at the IP layer. This
architecture primarily defines services for the Internet Protocol
(IP) unicast packets, as well as manually configured IP multicast
packets.
It is possible to use IPsec to secure ULE links. The major
advantage of IPsec is its wide implementation in IP routers and
hosts. IPsec in transport mode can be used for end-to-end
security transparently over MPEG-2 transmission links with little
impact.
In the context of MPEG-2 transmission links, if IPsec is used to
secure a ULE link, then the ULE Encapsulator and Receivers are
equivalent to the security gateways in IPsec terminology. A
security gateway implementation of IPsec uses tunnel mode. Such
usage has the following disadvantages:
o There is an extra transmission overhead associated with using
IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6).
o There is a need to protect the identity (NPA) of ULE Receivers
over the ULE broadcast medium; IPsec is not suitable for
providing this service. In addition, the interfaces of these
devices do not necessarily have IP addresses (they can be L2
devices).
o Multicast is considered a major service over ULE links. The
current IPsec specifications [RFC4301] only define a pairwise
tunnel between two IPsec devices with manual keying. Work is
in progress in defining the extra detail needed for multicast
and to use the tunnel mode with address preservation to allow
efficient multicasting. For further details refer to [WEIS06].
B.2 Link security below the encapsulation layer
Link layer security can be provided at the MPEG-2 TS layer (below
ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
specific PID value. However, an MPEG-2 TS may typically multiplex
several IP flows, belonging to different users, 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, TLS, or any
other form of higher-layer security.
However it has the following disadvantages:
o When a PID is shared between several users, 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
separately secure individual IP flows.
o When a PID is shared between several users, the ULE Receivers
will have access to private traffic destined to other ULE
Receivers, since they share a common PID and key.
o IETF-based key management that is very flexible and secure is
not used in existing MPEG-2 based systems. Existing access
control mechanisms in such systems have limited flexibility in
terms of controlling the use of key and rekeying. Therefore if
the key is compromised, then this will impact several ULE
Receivers.
Currently there are few deployed L2 security systems for MPEG-2
transmission networks. Conditional access for digital TV
broadcasting is one example. However, this approach is optimised
for TV services and is not well-suited to IP packet transmission.
Some other systems are specified in standards such as MPE [ETSI-
DAT], but there are currently no known implementations.
B.3 Link security as a part of the encapsulation layer
Examining the threat analysis in section 3 has shown that
protection of ULE link from eavesdropping and ULE Receiver
identity are major requirements.
There are several major advantages in using ULE link layer
security:
o The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses. The protection can be applied either
per IP flow or per Receiver NPA address.
o Ability to protect the identity of the Receiver within the
MPEG-2 transmission network at the IP layer and also at L2.
o Efficient protection of IP multicast over ULE links.
o Transparency to the use of Network Address Translation (NATs)
[RFC3715] 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 at L3 (or TLS
[RFC4346] at L4). IPsec and TLS provide strong authentication of
the end-points in the communication.
L3 end-to-end security would partially deny the advantage listed
just above (use of PEP, compression etc), since those techniques
could only be applied to TCP packets bearing a TCP-encapsulated
IPsec packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression.
End-to-end security (IPsec, TLS, etc.) may be used independently
to provide strong authentication of the end-points in the
communication. This authentication is desirable in many scenarios
to ensure that the correct information is being exchanged between
the trusted parties, whereas Layer 2 methods cannot provide this
guarantee.
>>> NOTE to RFC Editor: Please remove this appendix prior to >>> NOTE to RFC Editor: Please remove this appendix prior to
publication] publication]
Document History Document History
Working Group Draft 00 Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption. o Fixed editorial mistakes and ID style for WG adoption.
skipping to change at line 1307 skipping to change at page 28, line 5
o Fixed editorial mistakes and added some important changes as o Fixed editorial mistakes and added some important changes as
pointed out by Gorry Fairhurst. pointed out by Gorry Fairhurst.
o Table 1 added in Section 6.2 to list the different security o Table 1 added in Section 6.2 to list the different security
techniques to mitigate the various possible network threats. techniques to mitigate the various possible network threats.
o Figure 2 modified to clearly explain the different interfaces o Figure 2 modified to clearly explain the different interfaces
present in the framework. present in the framework.
Cruickshank et.al. Expires April 12, 2008 [Page
28]
o New Section 7 has been added. o New Section 7 has been added.
o New Section 6 has been added. o New Section 6 has been added.
o The previous sections 5 and 6 have been combined to section 5. o The previous sections 5 and 6 have been combined to section 5.
o Sections 3, 8 and 9 have been rearranged and updated with o Sections 3, 8 and 9 have been rearranged and updated with
comments and suggestions from Michael Noisternig from comments and suggestions from Michael Noisternig from
University of Salzburg. University of Salzburg.
skipping to change at line 1333 skipping to change at page 28, line 28
o Fixed editorial mistakes and added some important changes as o Fixed editorial mistakes and added some important changes as
pointed out by DVB-GBS group, Gorry Fairhurst and Laurence pointed out by DVB-GBS group, Gorry Fairhurst and Laurence
Duquerroy. Duquerroy.
o Table 1 modified to have consistent use of Security Services. o Table 1 modified to have consistent use of Security Services.
o Text modified to be consistent with the draft-ietf-ipdvb-ule- o Text modified to be consistent with the draft-ietf-ipdvb-ule-
ext-04.txt ext-04.txt
Cruickshank et.al. Expires April 12, 2008 [Page Working Group Draft 06
29]
o Fixed editorial mistakes and added some important changes as
pointed out by Pat Cain and Gorry Fairhurst.
o Figure 1 modified to have consistent use of Security Services.
o Text modified in Section 4 to clearly state the requirements.
o Moved Section 5 to the Appendix B
o Updated IANA consideration section
o Numbered the different requirements and cross referenced them
within the text.
 End of changes. 66 change blocks. 
350 lines changed or deleted 306 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/