draft-ietf-ipdvb-sec-req-07.txt   draft-ietf-ipdvb-sec-req-08.txt 
IPDVB Working Group H. Cruickshank IPDVB Working Group H. Cruickshank
Internet-Draft University of Surrey, UK Internet-Draft University of Surrey, UK
Intended status: Informational P. Pillai Intended status: Informational P. Pillai
Expires: Dec 16, 2008 University of Bradford, UK Expires: Jan 13, 2009 University of Bradford, UK
Michael Noisternig M. Noisternig
University of Salzburg, Austria University of Salzburg, Austria
S. Iyengar S. Iyengar
Logica, UK Logica, UK
17 June, 2008 14 July, 2008
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-07.txt draft-ietf-ipdvb-sec-req-08.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 41 skipping to change at page 1, line 41
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 December 17, 2008. This Internet-Draft will expire on January 13, 2009.
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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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.
The analysis also describes applicability to the Generic Stream The analysis also describes applicability to the Generic Stream
Encapsulation (GSE) defined by the Digital Video Broadcasting Encapsulation (GSE) defined by the Digital Video Broadcasting
(DVB) Project. (DVB) Project.
Table of Contents Table of Contents
1. Introduction .............................................. 2 1. Introduction .............................................. 2
2. Requirements notation ..................................... 4 2. Requirements Notation ..................................... 4
3. Threat Analysis ........................................... 6 3. Threat Analysis ........................................... 7
3.1. System Components .................................... 6 3.1. System Components .................................... 7
3.2. Threats .............................................. 9 3.2. Threats .............................................. 9
3.3. Threat cases ........................................ 10 3.3. Threat Cases ........................................ 10
4. Security Requirements for IP over MPEG-2 TS............... 11 4. Security Requirements for IP over MPEG-2 TS .............. 11
5. Design recommendations for ULE Security Extension Header . 14 5. Design recommendations for ULE Security Extension Header . 14
6. Compatibility with Generic Stream Encapsulation .......... 14 6. Compatibility with Generic Stream Encapsulation .......... 15
7. Summary .................................................. 14 7. Summary .................................................. 15
8. Security Considerations .................................. 16 8. Security Considerations .................................. 15
9. IANA Considerations ...................................... 16 9. IANA Considerations ...................................... 16
10. Acknowledgments ......................................... 16 10. Acknowledgments ......................................... 16
11. References .............................................. 16 11. References .............................................. 16
11.1. Normative References ............................... 16 11.1. Normative References ............................... 16
11.2. Informative References ............................. 17 11.2. Informative References ............................. 17
12. Author's Addresses ...................................... 19 12. Author's Addresses ...................................... 18
13. IPR Notices ............................................. 19 13. Intellectual Property Statement ......................... 19
13.1. Intellectual Property Statement .................... 19 14. Full Copyright Statement ................................ 20
14. Copyright Statement...................................... 20
Appendix A: ULE Security Framework .......................... 20 Appendix A: ULE Security Framework .......................... 20
Appendix B: Motivation for ULE link-layer security .......... 24 Appendix B: Motivation for ULE link-layer security .......... 24
Document History ............................................ 27 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 3, line 6 skipping to change at page 3, line 4
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
supports an Extension Header format that allows it to carry supports an Extension Header format that allows it to carry
additional header information to assist in network/Receiver additional header information to assist in network/Receiver
processing. The encapsulation satisfies the design and processing. The encapsulation satisfies the design and
architectural requirement for a lightweight encapsulation defined architectural requirement for a lightweight encapsulation defined
in RFC 4259 [RFC4259]. in RFC 4259 [RFC4259].
Section 3.1 of RFC 4259 presents several topological scenarios Section 3.1 of RFC 4259 presents several topological scenarios
for MPEG-2 Transmission Networks. A summary of these scenarios for MPEG-2 Transmission Networks. A summary of these scenarios
are presented below (for full detail, please refer to RFC 4259): are presented below (see section 3.1 of RFC 4259):
A. Broadcast TV and Radio Delivery. A. Broadcast TV and Radio Delivery. This is not within the scope
of this document.
B. Broadcast Networks used as an ISP. This resembles to scenario B. Broadcast Networks used as an ISP. This resembles scenario A,
1, but includes the provision of IP services providing access but includes IP services to access the public Internet.
to the public Internet.
C. Unidirectional Star IP Scenario. It utilizes a Hub station to C. Unidirectional Star IP Scenario. This provides a data network
provide a data network delivering a common bit stream to delivering a common bit stream to typically medium-sized
typically medium-sized groups of Receivers. groups of Receivers.
D. Datacast Overlay. It employs MPEG-2 physical and link layers D. Datacast Overlay. This employs MPEG-2 physical and link layers
to provide additional connectivity such as unidirectional to provide additional connectivity such as unidirectional
multicast to supplement an existing IP-based Internet service. multicast to supplement an existing IP-based Internet service.
E. Point-to-Point Links. This connectivity may be provided using E. Point-to-Point Links. This connectivity may be provided using
a pair of transmit and receive interfaces. a pair of transmit and receive interfaces.
F. Two-Way IP Networks. This can be (for example) satellite-based F. Two-Way IP Networks.
and star-based utilising a Hub station to deliver a common bit
stream to medium-sized groups of Receivers. A bidirectional
service is provided over a common air-interface.
RFC 4259 states that ULE must be robust to errors and security RFC 4259 states that ULE must be robust to errors and security
threats. Security must also consider both unidirectional (A, B, C threats. Security must also consider both unidirectional (A, B, C
and D) as well as bidirectional (E and F) links for the scenarios and D) as well as bidirectional (E and F) links for the scenarios
mentioned above. mentioned above.
An initial analysis of the security requirements in MPEG-2 An initial analysis of the security requirements in MPEG-2
transmission networks is presented in the security considerations transmission networks is presented in the security considerations
section of RFC 4259. For example, when such networks are not section of RFC 4259. For example, when such networks are not
using a wireline network, the normal security issues relating to using a wireline network, the normal security issues relating to
the use of wireless links for transport of Internet traffic the use of wireless links for transport of Internet traffic
should be considered [RFC3819]. should be considered [RFC3819].
The security considerations of RFC 4259 recommends that any new The security considerations of RFC 4259 recommend that any new
encapsulation defined by the IETF should allow Transport Stream encapsulation defined by the IETF should allow Transport Stream
encryption and should also support optional link-layer encryption and should also support optional link-layer
authentication of the SNDU payload. In ULE [RFC4326], it is authentication of the SNDU payload. In ULE [RFC4326], it is
suggested that this may be provided in a flexible way using suggested that this may be provided in a flexible way using
Extension Headers. This requires the definition of a mandatory Extension Headers. This requires the definition of a mandatory
Extension Header, but has the advantage that it decouples Extension Header, but has the advantage that it decouples
specification of the security functions from the encapsulation specification of the security functions from the encapsulation
functions. functions.
This document extends the above analysis and derives a detailed This document extends the above analysis and derives in detail
the security requirements for ULE in MPEG-2 transmission the security requirements for ULE in MPEG-2 transmission
networks. networks.
A security framework for deployment of secure ULE networks A security framework for deployment of secure ULE networks
describing the different building blocks and the interface describing the different building blocks and the interface
definitions is presented in Appendix A. definitions is presented in Appendix A.
2. Requirements notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
RFC2119 [RFC2119]. RFC2119 [RFC2119].
Other terms used in this document are defined below: Other terms used in this document are defined below:
ATSC: Advanced Television Systems Committee. A framework and a ATSC: Advanced Television Systems Committee. A framework and a
set of associated standards for the transmission of video, audio, set of associated standards for the transmission of video, audio,
skipping to change at page 7, line 17 skipping to change at page 7, line 49
for IP transport over MPEG-2 (adapted from [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 ULE Encapsulator) 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 endpoints for ULE Streams)
o TS multiplexers (including re-multiplexers) o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
In an MPEG-2 TS transmission network, the originating source of
TS Packets is either a Layer 2 (L2) interface device (media
encoder, encapsulation gateway, etc) or a L2 network device (TS
multiplexer, etc). These devices may, but do not necessarily,
have an associated IP address. In the case of an encapsulation
gateway (e.g. ULE sender), the device may operate at L2 or Layer
3 (L3), and is not normally the originator of an IP traffic flow,
and usually the IP source address of the packets that it forwards
does not correspond to an IP address associated with the device.
The TS Packets are carried to the Receiver over a physical layer The TS Packets are carried to the Receiver over a physical layer
that usually includes Forward Error Correction (FEC) coding that that usually includes Forward Error Correction (FEC) coding that
interleaves the bytes of several consecutive, but unrelated, TS interleaves the bytes of several consecutive, but unrelated, TS
Packets. FEC-coding and synchronisation processing makes Packets. FEC-coding and synchronisation processing makes
injection of single TS Packets very difficult. Replacement of a injection of single TS Packets very difficult. Replacement of a
sequence of packets is also difficult, but possible (see section sequence of packets is also difficult, but possible (see section
3.2). 3.2).
A Receiver in an MPEG-2 TS transmission network needs to identify A Receiver in an MPEG-2 TS transmission network needs to identify
a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble a TS Logical Channel (or MPEG-2 Elementary Stream) to reassemble
skipping to change at page 8, line 39 skipping to change at page 9, line 15
ULE Stream security only concerns the security between the ULE ULE Stream security only concerns the security between the ULE
Encapsulation Gateway (ULE Encapsulator) and the Receiver. In Encapsulation Gateway (ULE Encapsulator) and the Receiver. In
many 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-points, i.e. the IP Sources is authentication of the end-points, i.e. the IP Sources is
required, or users are concerned about loss of confidentiality, required, or users are concerned about loss of confidentiality,
integrity, or authenticity of their communication data, they will integrity, or authenticity of their communication data, they will
have to employ end-to-end network security mechanisms, e.g. IPsec have to employ end-to-end network security mechanisms, e.g. IPsec
or Transport Layer Security (TLS). Governmental users may be or Transport Layer Security (TLS). Governmental users may be
forced by regulations to employ specific, approved forced by regulations to employ specific approved implementations
implementations of those mechanisms. Hence for such cases, the of those mechanisms. Hence for such cases, the requirements for
requirements for confidentiality and integrity of the user data confidentiality and integrity of the user data will be met by the
will be met by the end-to-end security mechanism and the ULE end-to-end security mechanism and the ULE security measures would
security measures would focus on either providing traffic flow focus on either providing traffic flow confidentiality for user
confidentiality for user data that has already been encrypted or data that has already been encrypted or for users who choose not
for users who choose not to implement end-to-end security to implement end-to-end security mechanisms.
mechanisms.
ULE links may also be used for communications where the two IP ULE links may also be used for communications where the two IP
end-points are not under central control (e.g., when browsing a end-points are not under central control (e.g., when browsing a
public web site). In these cases, it may be impossible to enforce public web site). In these cases, it may be impossible to enforce
any end-to-end security mechanisms. Yet, a common objective is any end-to-end security mechanisms. Yet, a common objective is
that users may make the same security assumptions as for wired that users may make the same security assumptions as for wired
links [RFC3819]. ULE security could achieve this by protecting links [RFC3819]. ULE security could achieve this by protecting
the vulnerable (in terms of passive attacks) ULE Stream. the vulnerable (in terms of passive attacks) ULE Stream.
In contrast to the above, a ULE Stream can be used to link In contrast to the above, a ULE Stream can be used to link
skipping to change at page 9, line 27 skipping to change at page 9, line 49
3.2. Threats 3.2. Threats
The simplest type of network threat is a passive threat. This The simplest type of network threat is a passive threat. This
includes eavesdropping or monitoring of transmissions, with a includes eavesdropping or monitoring of transmissions, with a
goal to obtain information that is being transmitted. In goal to obtain information that is being transmitted. In
broadcast networks (especially those utilising widely available broadcast networks (especially those utilising widely available
low-cost physical layer interfaces, such as DVB) passive threats low-cost physical layer interfaces, such as DVB) passive threats
are the major threats. One example is an intruder monitoring the are the major threats. One example is an intruder monitoring the
MPEG-2 transmission broadcast and then extracting the data MPEG-2 transmission broadcast and then extracting the data
carried within the link. Another example is of an intruder trying carried within the link. Another example is an intruder trying to
to determine the identity of the communicating parties and the determine the identity of the communicating parties and the
volume of their traffic by sniffing (L2) addresses. This is a volume of their traffic by sniffing (L2) addresses. This is a
well-known issue in the security field; however it is more of a well-known issue in the security field; however it is more of a
problem in the case of broadcast networks such as MPEG-2 problem in the case of broadcast networks such as MPEG-2
transmission networks because of the easy availability of transmission networks because of the easy availability of
Receiver hardware and the wide geographical span of the networks. Receiver hardware and the wide geographical span of the networks.
Active threats (or attacks) are, in general, more difficult to Active threats (or attacks) are, in general, more difficult to
implement successfully than passive threats, and usually require implement successfully than passive threats, and usually require
more sophisticated resources and may require access to the more sophisticated resources and may require access to the
transmitter. Within the context of MPEG-2 transmission networks, transmitter. Within the context of MPEG-2 transmission networks,
skipping to change at page 10, line 26 skipping to change at page 10, line 46
requirements for Case 2 and 3 in section 4 below. requirements for Case 2 and 3 in section 4 below.
As explained in section 3.1, the PID associated with an As explained in section 3.1, the PID associated with an
Elementary Stream can be modified (e.g. in some systems by Elementary Stream can be modified (e.g. in some systems by
reception of an updated SI table, or in other systems until the reception of an updated SI table, or in other systems until the
next announcement/discovery data is received). An attacker that next announcement/discovery data is received). An attacker that
is able to modify the content of the received multiplex (e.g. is able to modify the content of the received multiplex (e.g.
replay data and/or control information) could inject data locally replay data and/or control information) could inject data locally
into the received stream with an arbitrary PID value. into the received stream with an arbitrary PID value.
3.3. Threat cases 3.3. Threat Cases
Analysing the topological scenarios for MPEG-2 Transmission Analysing the topological scenarios for MPEG-2 Transmission
Networks in section 1, the security threats can be abstracted Networks in section 1, the security threats can be abstracted
into three cases: into three cases:
o Case 1: Monitoring (passive threat). Here the intruder o Case 1: Monitoring (passive threat). Here the intruder
monitors the ULE broadcasts to gain information about the ULE monitors the ULE broadcasts to gain information about the ULE
data and/or tracking the communicating parties identities (by data and/or tracking the communicating parties identities (by
monitoring the destination NPA). In this scenario, measures monitoring the destination NPA). In this scenario, measures
must be taken to protect the ULE payload data and the identity must be taken to protect the ULE payload data and the identity
skipping to change at page 10, line 50 skipping to change at page 11, line 23
multiplex. Here an intruder is assumed to be sufficiently multiplex. Here an intruder is assumed to be sufficiently
sophisticated to over-ride the original transmission from the sophisticated to over-ride the original transmission from the
ULE Encapsulation Gateway and deliver a modified version of ULE Encapsulation Gateway and deliver a modified version of
the MPEG-TS transmission to a single ULE Receiver or a small the MPEG-TS transmission to a single ULE Receiver or a small
group of Receivers (e.g. in a single company site). The MPEG-2 group of Receivers (e.g. in a single company site). The MPEG-2
transmission network operator might not be aware of such transmission network operator might not be aware of such
attacks. Measures must be taken to ensure ULE data integrity attacks. Measures must be taken to ensure ULE data integrity
and authenticity and preventing replay of old messages. and authenticity and preventing replay of old messages.
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. This assumes a sophisticated intruder able to over-
and able to over-ride the whole MPEG-2 transmission multiplex. ride the whole MPEG-2 transmission multiplex. The requirements
are similar to scenario 2. The MPEG-2 transmission network
The requirements here are similar to scenario 2. The MPEG-2 operator can usually identify such attacks and provide
transmission network operator can usually identify such corrective action to restore the original transmission.
attacks and may resort to some means to restore the original
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:
o Insider attacks, i.e. active attacks from adversaries within o Insider attacks, i.e. active attacks from adversaries within
the network with knowledge of the secret material. the network with knowledge of the secret material.
o Outsider attacks, i.e. active attacks from outside of a o Outsider attacks, i.e. active attacks from outside of a
virtual private network. virtual 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 considered a lesser
within certain network configurations, especially when there are threat, appropriate to specific network configurations,
insider attacks. Hence, protection against such active attacks especially when vulnerable to insider attacks. Case 3 is less
should be used only when such a threat is a real possibility. likely to be found in an operational network, and is expected to
Case 3 is envisaged to be less practical, because it will be very be noticed by the MPEG-2 transmission operator. It will require
difficult to pass unnoticed by the MPEG-2 transmission operator. restoration of the original transmission. The assumption being
It will require restoration of the original transmission. The that physical access to the network components (multiplexers,
assumption being here is that physical access to the network etc) and/or connecting physical media is secure. Therefore Case 3
components (multiplexers, etc) and/or connecting physical media is not considered further in this document.
is secure. Therefore case 3 is not considered further in this
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:
Req 1. Data confidentiality MUST be provided by a link that Req 1. Data confidentiality MUST be provided by a link that
supports ULE Stream Security to prevent passive attacks and supports ULE Stream Security to prevent passive attacks and
reduce the risk of active threats. reduce the risk of active threats.
Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast Req 2. Protection of L2 NPA address is OPTIONAL. In broadcast
networks this protection can be used to prevent an intruder networks this protection can be used to prevent an intruder
tracking the identity of ULE Receivers and the volume of their tracking the identity of ULE Receivers and the volume of their
traffic. traffic.
Req 3. Integrity protection and source authentication of ULE Req 3. Integrity protection and source authentication of ULE
Stream data are OPTIONAL. These can be used to prevent active Stream data are OPTIONAL. These can be used to prevent active
attacks described in section 3.2. attacks described in section 3.2.
Req 4. Protection against replay attacks is OPTIONAL. This is Req 4. Protection against replay attacks is OPTIONAL. This is
required for the active attacks described in section 3.2. used to counter active attacks described in section 3.2.
Req 5. L2 ULE Source and Receiver authentication is OPTIONAL. Req 5. L2 ULE Source and Receiver authentication is OPTIONAL.
This can be performed during the initial key exchange and This can be performed during the initial key exchange and
authentication phase, before the ULE Receiver can join a authentication phase, before the ULE Receiver can join a
secure session with the ULE Encapsulator (ULE source). This secure session with the ULE Encapsulator (ULE source). This
could be either unidirectional or bidirectional authentication could be either unidirectional or bidirectional authentication
based on the underlying key management protocol. based on the underlying key management protocol.
Other general requirements for all threat cases for link-layer Other general requirements for all threat cases for link-layer
security are: security are:
GReq (a) ULE key management functions MUST be decoupled from ULE GReq (a) ULE key management functions MUST be decoupled from ULE
security services such as encryption and source authentication. security services such as encryption and source authentication.
This allows the independent development of both systems. This allows the independent development of both systems.
GReq (b) Support SHOULD be provided for automated as well as GReq (b) Support SHOULD be provided for automated as well as
manual insertion of keys and policy into the relevant manual insertion of keys and policy into the relevant
databases. databases.
GReq (c) Algorithm agility MUST be supported. Changes in crypto GReq (c) Algorithm agility MUST be supported. It should be
algorithms, hashes as they become obsolete should be updated possible to update the crypto algorithms and hashes when they
without affecting the overall security of the system. become obsolete without affecting the overall security of the
system.
GReq (d) The security extension header MUST be compatible with GReq (d) The security extension header MUST be compatible with
other ULE extension headers. There could be other extension other ULE extension headers. The method must allow other
headers (either mandatory or optional). It is RECOMMENDED that extension headers (either mandatory or optional) to be used in
combination with a security extension. It is RECOMMENDED that
these are placed after the security extension header. This these are placed after the security extension header. This
permits full protection for all headers. It also avoids permits full protection for all headers. It also avoids
situations where the SNDU has to be discarded on processing the situations where the SNDU has to be discarded on processing the
security extension header, while preceding headers have already security extension header, while preceding headers have already
been evaluated. One exception is the Timestamp extension which been evaluated. One exception is the Timestamp extension which
SHOULD precede the security extension header [RFC5163]. In this SHOULD precede the security extension header [RFC5163]. In this
case, the timestamp will be unaffected by security services case, the timestamp will be unaffected by security services
such as data confidentiality and can be decoded without the such as data confidentiality and can be decoded without the
need for key material. need for key material.
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 (Req 1) MUST be provided to o Case 1: Data confidentiality (Req 1) MUST be provided to
prevent monitoring of the ULE data (such as user information prevent monitoring of the ULE data (such as user information
and IP addresses). Protection of NPA addresses (Req 2) MAY be and IP addresses). Protection of NPA addresses (Req 2) MAY be
provided to prevent tracking ULE Receivers and their provided to prevent tracking ULE Receivers and their
communications. communications.
o Case 2: In addition to case 1 requirements, new measures MAY o Case 2: In addition to Case 1 requirements, new measures MAY
be implemented such as authentication schemes using Message be implemented such as authentication schemes using Message
Authentication Codes, digital signatures, or TESLA [RFC4082] Authentication Codes, digital signatures, or TESLA [RFC4082]
in order to provide integrity protection and source in order to provide integrity protection and source
authentication (Req 2, Req 3 and Req 5). In addition, sequence authentication (Req 2, Req 3 and Req 5). In addition, sequence
numbers (Req 4) MAY be used to protect against replay attacks. numbers (Req 4) MAY be used to protect against replay attacks.
In terms of outsider attacks, group authentication using In terms of outsider attacks, group authentication using
Message Authentication Codes should provide the same level of Message Authentication Codes should provide the same level of
security (Req 3 and 5). This will significantly reduce the security (Req 3 and 5). This will significantly reduce the
ability of intruders to successfully inject their own data ability of intruders to successfully inject their own data
into the MPEG-TS stream. However, scenario 2 threats apply into the MPEG-TS stream. However, scenario 2 threats apply
only in specific service cases, and therefore authentication only in specific service cases, and therefore authentication
and protection against replay attacks are OPTIONAL. Such and protection against replay attacks are OPTIONAL. Such
measures incur additional transmission as well as processing measures incur additional transmission as well as processing
overheads. Moreover, intrusion detection systems may also be overheads. Moreover, intrusion detection systems may also be
needed by the MPEG-2 network operator. These should best be needed by the MPEG-2 network operator. These should best be
coupled with perimeter security policy to monitor common DoS coupled with perimeter security policy to monitor common DoS
attacks. attacks.
o Case 3: As stated in section 3.3. the requirements here are 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.
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 mechanisms to mitigate those networks, and the relevant security mechanisms to mitigate those
threats. threats.
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 |
skipping to change at page 14, line 22 skipping to change at page 14, line 44
identity protection), and a second profile that extends this to identity protection), and a second profile that extends this to
also provide source authentication and protection against replay also provide source authentication and protection against replay
attacks. attacks.
A modular design of ULE security may allow it to use and benefit A modular design of ULE security may allow it to use and benefit
from existing key management protocols, such as GSAKMP [RFC4535] from existing key management protocols, such as GSAKMP [RFC4535]
and GDOI [RFC3547] defined by the IETF Multicast Security (MSEC) and GDOI [RFC3547] defined by the IETF Multicast Security (MSEC)
working group. This does not preclude the use of other key working group. This does not preclude the use of other key
management methods in scenarios where this is more appropriate. management methods in scenarios where this is more appropriate.
IPsec and TLS also provide a proven security architecture IPsec [RFC4301] and TLS [RFC4346] also provide a proven security
defining key exchange mechanisms and the ability to use a range architecture defining key exchange mechanisms and the ability to
of cryptographic algorithms. ULE security can make use of these use a range of cryptographic algorithms. ULE security can make
established mechanisms and algorithms. use of these established mechanisms and algorithms. See appendix
A for more details.
6. Compatibility with Generic Stream Encapsulation 6. Compatibility with Generic Stream Encapsulation
The [RFC5163] document describes three new Extension Headers that RFC 5163 [RFC5163] describes three new Extension Headers that may
may be used with Unidirectional Link Encapsulation, ULE, be used with Unidirectional Link Encapsulation, ULE, [RFC4326]
[RFC4326] and the Generic Stream Encapsulation (GSE) that has and the Generic Stream Encapsulation (GSE) that has been designed
been designed for the Generic Mode (also known as the Generic for the Generic Mode (also known as the Generic Stream (GS)),
Stream (GS)), offered by second-generation DVB physical layers offered by second-generation DVB physical layers [GSE].
[GSE].
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. are applicable to ULE and GSE encapsulations.
7. Summary 7. Summary
This document analyses a set of threats and security This document analyses a set of threats and security
requirements. It defines the requirements for ULE security and requirements. It defines the requirements for ULE security and
states the motivation for link security as a part of the states the motivation for link security as a part of the
Encapsulation layer. Encapsulation layer.
ULE security must provide link-layer encryption and ULE Receiver ULE security must provide link-layer encryption and ULE Receiver
identity protection. The framework must support the optional identity protection. The framework must support the optional
ability to provide for link-layer authentication and integrity ability to provide for link-layer authentication and integrity
assurance, as well as protection against insertion of old assurance, as well as protection against insertion of old
(duplicated) data into the ULE stream (i.e. replay protection). (duplicated) data into the ULE Stream (i.e. replay protection).
This set of features is optional to reduce encapsulation overhead This set of features is optional to reduce encapsulation overhead
when not required. when not required.
ULE stream security between a ULE Encapsulation Gateway and the ULE Stream security between a ULE Encapsulation Gateway and the
corresponding Receiver(s) is considered an additional security corresponding Receiver(s) is considered an additional security
mechanism to IPsec, TLS, and application layer end-to-end mechanism to IPsec, TLS, and application layer end-to-end
security, and not as a replacement. It allows a network operator security, and not as a replacement. It allows a network operator
to provide similar functions to that of IPsec, but in addition to provide similar functions to that of IPsec, but in addition
provides MPEG-2 transmission link confidentiality and protection provides MPEG-2 transmission link confidentiality and protection
of ULE Receiver identity (NPA). of ULE Receiver identity (NPA).
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
realise a framework that provides ULE security functions. realise a framework that provides ULE security functions.
skipping to change at page 18, line 9 skipping to change at page 17, line 45
IETF RFC 4259, November 2005. IETF RFC 4259, November 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.
32-48, April 989. http://www.cs.columbia.edu/~smb/ 32-48, April 989. http://www.cs.columbia.edu/~smb/
[GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic [GSE] TS 102 606, "Digital Video Broadcasting (DVB);
Stream Encapsulation (GSE) Protocol, "European Generic Stream Encapsulation (GSE) Protocol,
Telecommunication Standards, Institute (ETSI), 2007. "European Telecommunication Standards, Institute
(ETSI), 2007.
[RFC4082] A. Perrig, D. Song, " Timed Efficient Stream Loss- [RFC4082] A. Perrig, D. Song, " Timed Efficient Stream Loss-
Tolerant Authentication (TESLA): Multicast Source Tolerant Authentication (TESLA): Multicast Source
Authentication Transform Introduction", IETF RFC Authentication Transform Introduction", IETF RFC
4082, June 2005. 4082, June 2005.
[RFC4535] H. Harney, et al, "GSAKMP: Group Secure Association [RFC4535] H. Harney, et al, "GSAKMP: Group Secure Association
Group Management Protocol", IETF RFc 4535, June 2006. Group Management Protocol", IETF RFc 4535, June 2006.
[RFC3547] M. Baugher, et al, "GDOI: The Group Domain of [RFC3547] M. Baugher, et al, "GDOI: The Group Domain of
skipping to change at page 19, line 39 skipping to change at page 19, line 29
Sunil Iyengar Sunil Iyengar
Space & Defence Space & Defence
Logica Logica
Springfield Drive Springfield Drive
Leatherhead Leatherhead
Surrey KT22 7LP Surrey KT22 7LP
UK UK
Email: sunil.iyengar@logica.com Email: sunil.iyengar@logica.com
13. IPR Notices 13. Intellectual Property Statement
Copyright (c) The IETF Trust (2007).
13.1. Intellectual Property Statement
Full Copyright Statement
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.
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, THE
IETF TRUST 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.
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 Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at page 20, line 38 skipping to change at page 20, line 6
use of 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 specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr. repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org. the IETF at ietf-ipr@ietf.org.
14. Copyright Statement 14. Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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.
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, THE
IETF TRUST 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.
Appendix A: ULE Security Framework Appendix A: ULE Security Framework
This section defines a security framework for the deployment of This section describes 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
as shown in figure 2 below: This ULE Security framework describes the following building
blocks 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
control plane. The ULE Security header block applies security to control plane. The ULE Security Header Block applies security to
the ULE SNDU and this happens in the ULE data plane. The ULE the ULE SNDU and this happens in the ULE data plane. The ULE
Security databases block acts as the interface between the Key Security Databases Block acts as the interface between the Key
management block (control plane) and the ULE Security Header Management Block (control plane) and the ULE Security Header
block (ULE data plane) as shown in figure 2. Block (ULE data plane) as shown in figure 2.
------ -----
+------+----------+ +----------------+ / \ +------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | | | Key Management |/---------\| Key Management | |
| Block |\---------/| Block | | | Block |\---------/| Block | |
| Group Member | | Group Server | Control | Group Member | | Group Server | Control
+------+----------+ +----------------+ Plane +------+----------+ +----------------+ Plane
| | | | | |
| | | | | |
| | \ / | | \ /
----------- Key management <-> ULE Security databases ----- ----------- Key management <-> ULE Security databases -----
| | | |
skipping to change at page 22, line 4 skipping to change at page 21, line 35
----------- ULE Security databases <-> ULE Security Header ---- ----------- ULE Security databases <-> ULE Security Header ----
| | / \ | | / \
| | | | | |
| | | | | |
+------+-+--------+ ULE Data +------+-+--------+ ULE Data
| ULE Security | Plane | ULE Security | Plane
| Extension Header| | | Extension Header| |
| Block | | | Block | |
+-----------------+ \ / +-----------------+ \ /
----- -----
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 Encapsulators. The ULE Receivers as well as at the ULE Encapsulators. The ULE
Encapsulator could also be the Key Management Group Server Entity Encapsulator could also be the Key Management Group Server Entity
(shown as the Key Management Group Server block in figure 2. This (shown as the Key Management Group Server Block in figure 2. This
happens when the ULE Encapsulator also acts as the Key Management happens when the ULE Encapsulator also acts as the Key Management
Group Server. Deployment may use either automated key management Group Server. Deployment may use either automated key management
protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying protocols (e.g. GSAKMP [RFC4535]) or manual insertion 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 This block will use the keying material and policy information
from the ULE security database block on the ULE payload to from the ULE Security Database Block on the ULE payload to
generate the secure ULE Extension Header or to decipher the generate the secure ULE Extension Header or to decipher the
secure ULE extension header to get the ULE payload. An example secure ULE extension header to get the ULE payload. An example
overview of the ULE Security extension header format along with overview of the ULE Security extension header format along with
the ULE header and payload is shown in figure 3 below. the ULE header and payload is shown in figure 3 below.
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement Figure 3: ULE Security Extension Header Placement
skipping to change at page 23, line 4 skipping to change at page 22, line 33
overview of the ULE Security extension header format along with overview of the ULE Security extension header format along with
the ULE header and payload is shown in figure 3 below. the ULE header and payload is shown in figure 3 below.
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement Figure 3: ULE Security Extension Header 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.
o ULE-SAD: ULE Security Association Database contains all the o ULE-SAD: ULE Security Association Database contains all the
Security Associations that are currently established with Security Associations that are currently established with
different ULE peers. different ULE peers.
o ULE-SPD: ULE Security Policy Database contains the policies as o ULE-SPD: ULE Security Policy Database contains the policies as
defined by the system manager. These policies describe the described by the system manager. These policies describe the
security services that must be enforced. security services that must be enforced.
The design of these two databases may be based on IPsec databases The design of these two databases may be based on IPsec databases
as defined in RFC4301 [RFC4301]. as defined in RFC4301 [RFC4301].
The exact details of the header patterns that the SPD and SAD The exact details of the header patterns that the SPD and SAD
will have to support for all use cases will be defined in a will have to support for all use cases will be described in a
separate document. This document only highlights the need for separate document. This document only highlights the need for
such interfaces between the ULE data plane and the Key Management such interfaces between the ULE data plane and the Key Management
control plane. control plane.
A.2 Interface definition A.2 Interface definition
Two new interfaces have to be defined between the blocks as shown Two new interfaces have to be defined between the blocks as shown
in Figure 2 above. These interfaces are: in Figure 2 above. These interfaces are:
o Key Management block <-> ULE Security databases block o Key Management Block <-> ULE Security Databases Block
o ULE Security databases block <-> ULE Security Header block o ULE Security Databases Block <-> ULE Security Header Block
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 Block of a group
(GM client) and the ULE Security Database block (shown in figure member (GM client) and the ULE Security Database Block (shown in
2). The Key Management GM entity will communicate with the GCKS figure 2). The Key Management GM entity will communicate with the
and then get the relevant security information (keys, cipher GCKS 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 security automated (e.g. GSAKMP [RFC4535] or GDOI [RFC3547]), or security
information could be manually inserted using this interface. The information could be manually inserted using this interface.
following three interface functions are defined:
. Insert_record_database (char * Database, char * record, char * Examples of interface functions are:
o Insert_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
. Update_record_database (char * Database, char * record, char *
o Update_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
. Delete_record_database (char * Database, char * Unique_ID);
o Delete_record_database (char * Database, char * Unique_ID);
The definitions of the variables are as follows: The definitions of the variables are as follows:
. Database - This is a pointer to the ULE Security databases o Database - This is a pointer to the ULE Security databases
. record - This is the rows of security attributes to be
entered or modified in the above databases o record - This is the rows of security attributes to be entered
. Unique_ID - This is the primary key to lookup records (rows or modified in the above databases
of security attributes) in the above databases o Unique_ID - This is the primary key to lookup records (rows of
security attributes) in the above databases
A.2.2 ULE Security Databases <-> ULE Security Header A.2.2 ULE Security Databases <-> ULE Security Header
This interface is between the ULE Security Database and the ULE This interface is between the ULE Security Database and the ULE
Security Extension Header block as shown in figure 2. When Security Extension Header Block as shown in figure 2. When
sending traffic, the ULE encapsulator uses the Destination sending traffic, the ULE encapsulator uses the Destination
Address, the PID, and possibly other information such as L3 Address, the PID, and possibly other information such as L3
source and destination addresses to locate the relevant security source and destination addresses to locate the relevant security
record within the ULE Security Database. It then uses the data in record within the ULE Security Database. It then uses the data in
the record to create the ULE security extension header. For the record to create the ULE security extension header. For
received traffic, the ULE decapsulator on receiving the ULE SNDU received traffic, the ULE decapsulator on receiving the ULE SNDU
will use the Destination Address, the PID, and a ULE Security ID will use the Destination Address, the PID, and a ULE Security ID
inserted by the ULE encapsulator into the security extension to inserted by the ULE encapsulator into the security extension to
retrieve the relevant record from the Security Database. It then retrieve the relevant record from the Security Database. It then
uses this information to decrypt the ULE extension header. For uses this information to decrypt the ULE extension header. For
both cases (either send or receive traffic) only one interface is both cases (either send or receive traffic) only one interface is
needed since the main difference between the sender and receiver needed since the main difference between the sender and receiver
is the direction of the flow of traffic: is the direction of the flow of traffic. An example of such
interface is as follows:
. Get_record_database (char * Database, char * record, char * o Get_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
Appendix B: Motivation for ULE link-layer security Appendix B: Motivation for ULE link-layer security
Examination of the threat analysis and security requirements in Examination of the threat analysis and security requirements in
sections 3 and 4 has shown that there is a need to provide sections 3 and 4 has shown that there is a need to provide
security in MPEG-2 transmission networks employing ULE. This security in MPEG-2 transmission networks employing ULE. This
section compares the placement of security functionalities in section compares the placement of security functionalities in
different layers. different layers.
skipping to change at page 26, line 36 skipping to change at page 26, line 21
control mechanisms in such systems have limited flexibility in control mechanisms in such systems have limited flexibility in
terms of controlling the use of key and rekeying. Therefore if terms of controlling the use of key and rekeying. Therefore if
the key is compromised, then this will impact several ULE the key is compromised, then this will impact several ULE
Receivers. Receivers.
Currently there are few deployed L2 security systems for MPEG-2 Currently there are few deployed L2 security systems for MPEG-2
transmission networks. Conditional access for digital TV transmission networks. Conditional access for digital TV
broadcasting is one example. However, this approach is optimised broadcasting is one example. However, this approach is optimised
for TV services and is not well-suited to IP packet transmission. for TV services and is not well-suited to IP packet transmission.
Some other systems are specified in standards such as MPE [ETSI- Some other systems are specified in standards such as MPE [ETSI-
DAT], but there are currently no known implementations. DAT], but there are currently no known implementations and these
methods are not applicable to GSE.
B.3 Link security as a part of the encapsulation layer B.3 Link security as a part of the encapsulation layer
Examining the threat analysis in section 3 has shown that Examining the threat analysis in section 3 has shown that
protection of ULE Stream from eavesdropping and ULE Receiver protection of ULE Stream from eavesdropping and ULE Receiver
identity are major requirements. identity are major requirements.
There are several major advantages in using ULE link layer There are several major advantages in using ULE link layer
security: security:
skipping to change at page 27, line 18 skipping to change at page 27, line 4
o Transparency to the use of Network Address Translation (NATs) o Transparency to the use of Network Address Translation (NATs)
[RFC3715] and TCP Performance Enhancing Proxies (PEP) [RFC3715] and TCP Performance Enhancing Proxies (PEP)
[RFC3135], which require the ability to inspect and modify the [RFC3135], which require the ability to inspect and modify the
packets sent over the ULE link. packets sent over the ULE link.
This method does not preclude the use of IPsec at L3 (or TLS This method does not preclude the use of IPsec at L3 (or TLS
[RFC4346] at L4). IPsec and TLS provide strong authentication of [RFC4346] at L4). IPsec and TLS provide strong authentication of
the end-points in the communication. the end-points in the communication.
L3 end-to-end security would partially deny the advantage listed L3 end-to-end security would partially deny the advantage listed
just above (use of PEP, compression etc), since those techniques above (use of PEP, compression etc), since those techniques could
could only be applied to TCP packets bearing a TCP-encapsulated only be applied to TCP packets bearing a TCP-encapsulated IPsec
IPsec packet exchange, but not the TCP packets of the original packet exchange, but not the TCP packets of the original
applications, which in particular inhibits compression. applications, which in particular inhibits compression.
End-to-end security (IPsec, TLS, etc.) may be used independently End-to-end security (IPsec, TLS, etc.) may be used independently
to provide strong authentication of the end-points in the to provide strong authentication of the end-points in the
communication. This authentication is desirable in many scenarios communication. This authentication is desirable in many scenarios
to ensure that the correct information is being exchanged between to ensure that the correct information is being exchanged between
the trusted parties, whereas Layer 2 methods cannot provide this the trusted parties, whereas Layer 2 methods cannot provide this
guarantee. guarantee.
>>> NOTE to RFC Editor: Please remove this appendix prior to >>> NOTE to RFC Editor: Please remove this appendix prior to
skipping to change at line 1305 skipping to change at page 30, line 8
o Moved security header placement recommendation from appendix o Moved security header placement recommendation from appendix
to list of general requirements in section 4, as suggested by to list of general requirements in section 4, as suggested by
Gorry Fairhurst. Gorry Fairhurst.
o Modified text in appendix section A.2.2 to correctly specify o Modified text in appendix section A.2.2 to correctly specify
which information sender and receiver use to look up security which information sender and receiver use to look up security
information within the database. information within the database.
o Fixed some editorial mistakes and updated the reference list. o Fixed some editorial mistakes and updated the reference list.
Working Group Draft 08
o Rephrased some sentences to add more clarity.
o Fixed some editorial mistakes pointed out by Gorry Fairhurst.
o Described the interface definitions in section A.2 as examples
rather than requirements.
 End of changes. 69 change blocks. 
165 lines changed or deleted 150 lines changed or added

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