draft-ietf-ipdvb-sec-req-08.txt   draft-ietf-ipdvb-sec-req-09.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: Jan 13, 2009 University of Bradford, UK Expires: Feb 22, 2009 University of Bradford, UK
M. Noisternig M. Noisternig
University of Salzburg, Austria University of Salzburg, Austria
S. Iyengar S. Iyengar
Logica, UK Logica, UK
14 July, 2008 23 August, 2008
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-08.txt draft-ietf-ipdvb-sec-req-09.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 January 13, 2009. This Internet-Draft will expire on February 22, 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 4, line 32 skipping to change at page 4, line 32
DVB: Digital Video Broadcast. A framework and set of associated DVB: Digital Video Broadcast. A framework and set of associated
standards published by the European Telecommunications Standards standards published by the European Telecommunications Standards
Institute (ETSI) for the transmission of video, audio, and data Institute (ETSI) for the transmission of video, audio, and data
using the ISO MPEG-2 Standard [ISO-MPEG2]. using the ISO MPEG-2 Standard [ISO-MPEG2].
Encapsulator: A network device that receives PDUs and formats Encapsulator: A network device that receives PDUs and formats
these into Payload Units (known here as SNDUs) for output as a these into Payload Units (known here as SNDUs) for output as a
stream of TS Packets. stream of TS Packets.
GCKS: Group Controller and Key Server. A server that
authenticates and provides the policy and keying material to
members of a secure group.
LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer LLC: Logical Link Control [ISO-8802], [IEEE-802]. A link-layer
protocol defined by the IEEE 802 standard, which follows the protocol defined by the IEEE 802 standard, which follows the
Ethernet Medium Access Control Header. Ethernet Medium Access Control Header.
MAC: Message Authentication Code. MAC: Message Authentication Code.
MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that MPE: Multiprotocol Encapsulation [ETSI-DAT]. A scheme that
encapsulates PDUs, forming a DSM-CC Table Section. Each Section encapsulates PDUs, forming a DSM-CC Table Section. Each Section
is sent in a series of TS Packets using a single TS Logical is sent in a series of TS Packets using a single TS Logical
Channel. Channel.
skipping to change at page 5, line 14 skipping to change at page 5, line 18
used to identify individual Receivers or groups of Receivers. used to identify individual Receivers or groups of Receivers.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet PDU: Protocol Data Unit. Examples of a PDU include Ethernet
frames, IPv4 or IPv6 datagrams, and other network packets. frames, IPv4 or IPv6 datagrams, and other network packets.
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in
the header of TS Packets. This is used to identify the TS the header of TS Packets. This is used to identify the TS
Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS
Packets forming the parts of a Table Section, PES, or other Packets forming the parts of a Table Section, PES, or other
Payload Unit must all carry the same PID value. The all-zeros Payload Unit must all carry the same PID value. The all-zeros
PID 0x0000 as well as other PID values is reserved for specific PID 0x0000 as well as other PID values are reserved for specific
PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF
indicates a Null TS Packet introduced to maintain a constant bit indicates a Null TS Packet introduced to maintain a constant bit
rate of a TS Multiplex. There is no required relationship rate of a TS Multiplex. There is no required relationship
between the PID values used for TS Logical Channels transmitted between the PID values used for TS Logical Channels transmitted
using different TS Multiplexes. using different TS Multiplexes.
Receiver: Equipment that processes the signal from a TS Multiplex Receiver: Equipment that processes the signal from a TS Multiplex
and performs filtering and forwarding of encapsulated PDUs to the and performs filtering and forwarding of encapsulated PDUs to the
network-layer service (or bridging module when operating at the network-layer service (or bridging module when operating at the
link layer). link layer).
skipping to change at page 11, line 8 skipping to change at page 11, line 8
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 address). In this scenario,
must be taken to protect the ULE payload data and the identity measures must be taken to protect the ULE payload data and the
of ULE Receivers. identity of ULE Receivers.
o Case 2: Locally conduct active attacks on the MPEG-TS o Case 2: Locally conduct active attacks on the MPEG-TS
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.
skipping to change at page 11, line 34 skipping to change at page 11, line 34
ride the whole MPEG-2 transmission multiplex. The requirements ride the whole MPEG-2 transmission multiplex. The requirements
are similar to scenario 2. The MPEG-2 transmission network are similar to scenario 2. The MPEG-2 transmission network
operator can usually identify such attacks and provide operator can usually identify such attacks and provide
corrective action to restore the original transmission. corrective action 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 adversaries without
virtual private network. knowledge of the secret material.
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 considered a lesser MPEG-2 transmission systems. Case 2 is considered a lesser
threat, appropriate to specific network configurations, threat, appropriate to specific network configurations,
especially when vulnerable to insider attacks. Case 3 is less especially when vulnerable to insider attacks. Case 3 is less
likely to be found in an operational network, and is expected to likely to be found in an operational network, and is expected to
be noticed by the MPEG-2 transmission operator. It will require be noticed by the MPEG-2 transmission operator. It will require
restoration of the original transmission. The assumption being restoration of the original transmission. The assumption being
that physical access to the network components (multiplexers, that physical access to the network components (multiplexers,
etc) and/or connecting physical media is secure. Therefore Case 3 etc.) and/or connecting physical media is secure. Therefore Case
is not considered further in this document. 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.
skipping to change at page 13, line 23 skipping to change at page 13, line 23
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 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 can provide the required 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 Security Mechanism
----------------------------------------------- -----------------------------------------------
|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 | | | | | | | Threat | | | | | | |
---------------|--------|-------|-------|-------|-------|------| ---------------|--------|-------|-------|-------|-------|------|
| Monitoring | X | - | - | - | - | X | | Monitoring | X | - | - | - | - | X |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| Masquerading | X | - | X | X | - | X | | Masquerading | X | - | X | X | - | X |
|---------------------------------------------------------------| |---------------------------------------------------------------|
| 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 | - |
skipping to change at page 15, line 13 skipping to change at page 15, line 13
A for more details. A for more details.
6. Compatibility with Generic Stream Encapsulation 6. Compatibility with Generic Stream Encapsulation
RFC 5163 [RFC5163] describes three new Extension Headers that may RFC 5163 [RFC5163] describes three new Extension Headers that may
be used with Unidirectional Link Encapsulation, ULE, [RFC4326] be used with Unidirectional Link Encapsulation, ULE, [RFC4326]
and the Generic Stream Encapsulation (GSE) that has been designed and the Generic Stream Encapsulation (GSE) that has been designed
for the Generic Mode (also known as the Generic Stream (GS)), for the Generic Mode (also known as the Generic Stream (GS)),
offered by second-generation DVB physical layers [GSE]. offered by second-generation DVB physical layers [GSE].
The security threats and requirement presented in this document The security threats and requirements 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
skipping to change at page 15, line 37 skipping to change at page 15, line 37
(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 address).
Annexe 1 describes a set of building blocks that may be used to Appendix A 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.
8. 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.
This document provides a threat analysis and derives the security This document provides a threat analysis and derives the security
requirements to provide link encryption and optional link-layer requirements to provide link encryption and optional link-layer
integrity / authentication of the SNDU payload. integrity / authentication of the SNDU payload.
skipping to change at page 20, line 45 skipping to change at page 20, line 45
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. The Security
Databases Block exists in both the group member and server sides.
However, it has been omitted from figure 2 just for clarity.
----- -----
+------+----------+ +----------------+ / \ +------+----------+ +----------------+ / \
| Key Management |/---------\| Key Management | | | Key Management |/---------\| Key Management | |
| Block |\---------/| Block | | | Group Member |\---------/| Group Server | |
| Group Member | | Group Server | Control | Block | | Block | Control
+------+----------+ +----------------+ Plane +------+----------+ +----------------+ Plane
| | | | | |
| | | | | |
| | \ / | | \ /
----------- Key management <-> ULE Security databases ----- ----------- Key management <-> ULE Security databases -----
| | | |
\ / \ /
+------+----------+ +------+----------+
| ULE | | ULE |
| SAD / SPD | | SAD / SPD |
skipping to change at page 21, line 51 skipping to change at page 21, line 51
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).
happens when the ULE Encapsulator also acts as the Key Management
Group Server. Deployment may use either automated key management
protocols (e.g. GSAKMP [RFC4535]) or manual insertion of keying
material.
A.1.2 ULE Extension Header Block
A new security extension header for the ULE protocol is required
to provide the security features of data confidentiality, data
integrity, data authentication, and mechanisms to prevent replay
attacks. Security keying material will be used for the different
security algorithms (for encryption/decryption, MAC generation,
etc.), which are used to meet the security requirements,
described in detail in Section 4 of this document.
This block will use the keying material and policy information
from the ULE Security Database Block on the ULE payload to
generate the secure ULE Extension Header or to decipher the
secure ULE extension header to get the ULE payload. An example
overview of the ULE Security extension header format along with
the ULE header and payload is shown in figure 3 below.
+-------+------+-------------------------------+------+ This happens when the ULE Encapsulator also acts as the Key
| ULE |SEC | Protocol Data Unit | | Management Group Server. Deployment may use either automated key
|Header |Header| |CRC-32| management protocols (e.g. GSAKMP [RFC4535]) or manual insertion
+-------+------+-------------------------------+------+ of keying material.
Figure 3: ULE Security Extension Header Placement
A.1.3 ULE Security Databases Block A.1.2 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
described by the system manager. These policies describe the described by the system manager. These policies describe the
skipping to change at page 23, line 7 skipping to change at page 22, line 32
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 described 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.1.3 ULE Extension Header Block
A new security extension header for the ULE protocol is required
to provide the security features of data confidentiality,
identity protection, data integrity, data authentication, and
mechanisms to prevent replay attacks. Security keying material
will be used for the different security algorithms (for
encryption/decryption, MAC generation, etc.), which are used to
meet the security requirements, described in detail in Section 4
of this document.
This block will use the keying material and policy information
from the ULE Security Database Block on the ULE payload to
generate the secure ULE Extension Header or to decipher the
secure ULE extension header to get the ULE payload. An example
overview of the ULE Security extension header format along with
the ULE header and payload is shown in figure 3 below.
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
Figure 3: ULE Security Extension Header Placement
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
skipping to change at page 25, line 14 skipping to change at page 25, line 16
In the context of MPEG-2 transmission links, if IPsec is used to In the context of MPEG-2 transmission links, if IPsec is used to
secure a ULE Stream, then the ULE Encapsulator and Receivers are secure a ULE Stream, then the ULE Encapsulator and Receivers are
equivalent to the security gateways in IPsec terminology. A equivalent to the security gateways in IPsec terminology. A
security gateway implementation of IPsec uses tunnel mode. Such security gateway implementation of IPsec uses tunnel mode. Such
usage has the following disadvantages: usage has the following disadvantages:
o There is an extra transmission overhead associated with using o There is an extra transmission overhead associated with using
IPsec in tunnel mode, i.e. the extra IP header (IPv4 or IPv6). 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 o There is a need to protect the identity (NPA address) of ULE
over the ULE broadcast medium; IPsec is not suitable for Receivers over the ULE broadcast medium; IPsec is not suitable
providing this service. In addition, the interfaces of these for providing this service. In addition, the interfaces of
devices do not necessarily have IP addresses (they can be L2 these devices do not necessarily have IP addresses (they can
devices). be L2 devices).
o Multicast is considered a major service over ULE links. The o Multicast is considered a major service over ULE links. The
current IPsec specifications [RFC4301] only define a pairwise current IPsec specifications [RFC4301] only define a pairwise
tunnel between two IPsec devices with manual keying. Work is tunnel between two IPsec devices with manual keying. Work is
in progress in defining the extra detail needed for multicast in progress in defining the extra detail needed for multicast
and to use the tunnel mode with address preservation to allow and to use the tunnel mode with address preservation to allow
efficient multicasting. For further details refer to [WEIS08]. efficient multicasting. For further details refer to [WEIS08].
B.2 Link security below the encapsulation layer B.2 Link security below the encapsulation layer
skipping to change at page 26, line 30 skipping to change at page 26, line 36
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 and these DAT], but there are currently no known implementations and these
methods are not applicable to GSE. 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 advantages in using ULE link layer security:
security:
o The protection of the complete ULE Protocol Data Unit (PDU) o The protection of the complete ULE Protocol Data Unit (PDU)
including IP addresses. The protection can be applied either including IP addresses. The protection can be applied either
per IP flow or per Receiver NPA address. per IP flow or per Receiver NPA address.
o Ability to protect the identity of the Receiver within the o Ability to protect the identity of the Receiver within the
MPEG-2 transmission network at the IP layer and also at L2. MPEG-2 transmission network at the IP layer and also at L2.
o Efficient protection of IP multicast over ULE links. o Efficient protection of IP multicast over ULE links.
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
above (use of PEP, compression etc), since those techniques could above (use of PEP, compression, etc.), since those techniques
only be applied to TCP packets bearing a TCP-encapsulated IPsec could only be applied to TCP packets bearing a TCP-encapsulated
packet exchange, but not the TCP packets of the original IPsec 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 1299 skipping to change at page 30, line 17
o Fixed some editorial mistakes and updated the reference list. o Fixed some editorial mistakes and updated the reference list.
Working Group Draft 08 Working Group Draft 08
o Rephrased some sentences to add more clarity. o Rephrased some sentences to add more clarity.
o Fixed some editorial mistakes pointed out by Gorry Fairhurst. o Fixed some editorial mistakes pointed out by Gorry Fairhurst.
o Described the interface definitions in section A.2 as examples o Described the interface definitions in section A.2 as examples
rather than requirements. rather than requirements.
Working Group Draft 09
o Clarified some sentences and fixed some editorial
inconsistencies and mistakes due to comments by Rupert
Goodings and Laurence Duquerroy.
 End of changes. 27 change blocks. 
61 lines changed or deleted 68 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/