draft-ietf-ipdvb-sec-req-03.txt   draft-ietf-ipdvb-sec-req-04.txt 
Internet Engineering Task Force H.Cruickshank Internet Engineering Task Force H.Cruickshank
Internet Draft S. Iyengar Internet-Draft University of Surrey, UK
draft-ietf-ipdvb-sec-req-03.txt University of Surrey, UK Intended status: Informational S. Iyengar
Expires: March 8, 2008 University of Surrey, UK
P. Pillai P. Pillai
Expires: December 29, 2007 University of Bradford, UK University of Bradford, UK
October 11, 2007
Category: WG Draft intended for INFORMATIONAL RFC June 29, 2007
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-03.txt draft-ietf-ipdvb-sec-req-04.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 40 skipping to change at page 1, line 40
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 29, 2007. This Internet-Draft will expire on March 8, 2007.
Abstract Abstract
The MPEG-2 standard defined by ISO 13818-1 supports a range of The MPEG-2 standard defined by ISO 13818-1 supports a range of
transmission methods for a range of services. This document transmission methods for a range of services. This document
provides a threat analysis and derives the security requirements provides a threat analysis and derives the security requirements
when using the Transport Stream, TS, to support an Internet when using the Transport Stream, TS, to support an Internet
network-layer using Unidirectional Lightweight Encapsulation network-layer using Unidirectional Lightweight Encapsulation
(ULE) defined in RFC4326. The document also provides the (ULE) defined in RFC4326. The document also provides the
motivation for link-layer security for a ULE Stream. A ULE Stream motivation for link-layer security for a ULE Stream. A ULE Stream
may be used to send IPv4 packets, IPv6 packets, and other may be used to send IPv4 packets, IPv6 packets, and other
Protocol Data Units (PDUs) to an arbitrarily large number of Protocol Data Units (PDUs) to an arbitrarily large number of
Receivers supporting unicast and/or multicast transmission. Receivers supporting unicast and/or multicast transmission.
Table of Contents Table of Contents
1. Introduction.......................................2 1. Introduction................................................2
2. Requirements notation...............................4 2. Requirements notation.......................................4
3. Threat Analysis....................................6 3. Threat Analysis.............................................6
3.1. System Components..............................6 3.1. System Components......................................6
3.2. Threats.......................................9 3.2. Threats................................................8
3.3. Threat Scenarios..............................10 3.3. Threat Scenarios......................................10
4. Security Requirements for IP over MPEG-2 TS...........11 4. Security Requirements for IP over MPEG-2 TS................11
5. Motivation for ULE link-layer security................13 5. Motivation for ULE link-layer security.....................13
5.1. Security at the IP layer (using IPSEC)...........13 5.1. Security at the IP layer (using IPSEC)................13
5.2. Link security below the Encapsulation layer.......14 5.2. Link security below the Encapsulation layer...........14
5.3. Link security as a part of the encapsulation layer.15 5.3. Link security as a part of the encapsulation layer....15
6. Design recommendations for ULE Security Header Extension16 6. Design recommendations for ULE Security Header Extension...15
7. Compatibility with Generic Stream Encapsulation........17 7. Compatibility with Generic Stream Encapsulation............16
8. Summary..........................................17 8. Summary....................................................17
9. Security Considerations............................17 9. Security Considerations....................................18
10. IANA Considerations...............................18 10. IANA Considerations.......................................18
11. Acknowledgments..................................18 11. Acknowledgments...........................................18
12. References.......................................18 12. References................................................18
12.1. Normative References..........................18 12.1. Normative References.................................19
12.2. Informative References........................19 12.2. Informative References...............................19
13. Author's Addresses................................20 13. Author's Addresses........................................20
14. IPR Notices......................................21 14. IPR Notices...............................................21
14.1. Intellectual Property Statement................21 14.1. Intellectual Property Statement......................21
14.2. Intellectual Property.........................21 14.2. Intellectual Property................................21
15. Copyright Statement...............................22 15. Copyright Statement.......................................22
Appendix A: ULE Security Framework......................22 Appendix A: ULE Security Framework............................22
Document History.....................................26 Document History..............................................26
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 8, line 21 skipping to change at page 8, line 19
need to be broadcast (e.g. by an Encapsulation Gateway or other need to be broadcast (e.g. by an Encapsulation Gateway or other
device) to form the Layer 2 (L2) control plane. Examples of device) to form the Layer 2 (L2) control plane. Examples of
signalling messages include the Program Association Table (PAT), signalling messages include the Program Association Table (PAT),
Program Map Table (PMT) and Network Information Table (NIT). In Program Map Table (PMT) and Network Information Table (NIT). In
existing MPEG-2 transmission networks, these messages are existing MPEG-2 transmission networks, these messages are
broadcast in the clear (no encryption or integrity checks). The broadcast in the clear (no encryption or integrity checks). The
integrity as well as authenticity of these messages is important integrity as well as authenticity of these messages is important
for correct working of the ULE network, i.e. supporting its for correct working of the ULE network, i.e. supporting its
security objectives in the area of availability, in addition to security objectives in the area of availability, in addition to
confidentiality and integrity. One method recently proposed [ID- confidentiality and integrity. One method recently proposed [ID-
EF] encapsulates these messages using ULE. In such cases all the EXT] encapsulates these messages using ULE. In such cases all the
security requirements of this document apply in securing these security requirements of this document apply in securing these
signalling messages. signalling messages.
ULE link security focuses only on the security between the ULE ULE link security focuses only on the security between the ULE
Encapsulation Gateway (ULE source) and the Receiver. In many Encapsulation Gateway (ULE source) and the Receiver. In many
deployment scenarios the user of a ULE Stream has to secure deployment scenarios the user of a ULE Stream has to secure
communications beyond the link since other network links are communications beyond the link since other network links are
utilised in addition to the ULE link. Therefore, if utilised in addition to the ULE link. Therefore, if
authentication of the end-point i.e. the IP Sources is required, authentication of the end-point i.e. the IP Sources is required,
or users are concerned about loss of confidentiality, integrity or users are concerned about loss of confidentiality, integrity
skipping to change at page 12, line 19 skipping to change at page 12, line 16
hashes as they become obsolete should be updated without hashes as they become obsolete should be updated without
affecting the overall security of the system. affecting the overall security of the system.
o Traceability: To monitor transmission network using log files o Traceability: To monitor transmission network using log files
to record the activities in the network and detect any to record the activities in the network and detect any
intrusion. intrusion.
o Protection against loss of service (availability) through o Protection against loss of service (availability) through
malicious reconfiguration of system components (see Figure 1). malicious reconfiguration of system components (see Figure 1).
o Secure Policy management
o Compatibility with other networking functions such as NAT o Compatibility with other networking functions such as NAT
Network Address Translation (NAT) [RFC3715] or TCP Network Address Translation (NAT) [RFC3715] or TCP
acceleration can be used in a wireless broadcast networks. acceleration can be used in a wireless broadcast networks.
o Compatibility and operational with ULE extension headers i.e. o Compatibility and operational with ULE extension headers i.e.
allow encryption of a compressed SNDU payload. allow encryption of a compressed SNDU payload.
o Where a ULE Stream carries a set of IP traffic flows to o Where a ULE Stream carries a set of IP traffic flows to
different destinations with a range of properties (multicast, different destinations with a range of properties (multicast,
unicast, etc), it is often not appropriate to provide IP unicast, etc), it is often not appropriate to provide IP
skipping to change at page 14, line 21 skipping to change at page 14, line 15
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 [WEIS06]. efficient multicasting. For further details refer to [WEIS06].
5.2. Link security below the Encapsulation layer 5.2. Link security below the Encapsulation layer
Link layer security can be provided at the MPEG-2 TS layer (below Link layer security can be provided at the MPEG-2 TS layer (below
ULE. MPEG-2 TS encryption encrypts all TS Packets sent with a ULE). MPEG-2 TS encryption encrypts all TS Packets sent with a
specific PID value. However, an MPEG-2 TS may typically multiplex specific PID value. However, an MPEG-2 TS may typically multiplex
several IP flows, belonging to different users, using a common several IP flows, belonging to different users, using a common
PID. Therefore all multiplexed traffic will share the same PID. Therefore all multiplexed traffic will share the same
security keys. security keys.
This has the following advantages: This has the following advantages:
o The bit stream sent on the broadcast network does not expose o The bit stream sent on the broadcast network does not expose
any L2 or L3 headers, specifically all addresses, type fields, any L2 or L3 headers, specifically all addresses, type fields,
and length fields are encrypted prior to transmission. and length fields are encrypted prior to transmission.
o This method does not preclude the use of IPsec, TLS, or any o This method does not preclude the use of IPsec, TLS, or any
other form of higher-layer security. other form of higher-layer security.
However it has the following disadvantages: However it has the following disadvantages:
o Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with o When a PID is shared between several users, each ULE Receiver
a matching PID, possibly including those that are not required needs to decrypt all MPEG-2 TS Packets with a matching PID,
to be forwarded. Therefore it does not have the flexibility to possibly including those that are not required to be
forwarded. Therefore it does not have the flexibility to
separately secure individual IP flows. separately secure individual IP flows.
o ULE Receivers will have access to private traffic destined to o When a PID is shared between several users, the ULE Receivers
other ULE Receivers, since they share a common PID and key. will have access to private traffic destined to other ULE
Receivers, since they share a common PID and key.
o IETF-based key management are not used in existing systems. o IETF-based key management is not used in existing systems.
Existing access control mechanisms have limited flexibility in Existing access control mechanisms 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.
5.3. Link security as a part of the encapsulation layer 5.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 link from eavesdropping and ULE Receiver protection of ULE link 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
skipping to change at page 15, line 37 skipping to change at page 15, line 33
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. This authentication is the end-points in the communication.
desirable in many scenarios to ensure that the correct
information is being exchanged between the trusted entities,
whereas Layer 2 methods cannot provide this guarantee.
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 just above (use of PEP, compression etc), since those techniques
could only be applied to TCP packets bearing a TCP-encapsulated could only be applied to TCP packets bearing a TCP-encapsulated
IPsec 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
skipping to change at page 16, line 22 skipping to change at page 16, line 15
extension header. For example this could help in the selection of extension header. For example this could help in the selection of
security fields in the ULE Security extension Header design. security fields in the ULE Security extension Header design.
Moreover the security services could also be grouped into Moreover the security services could also be grouped into
profiles based on different security requirements. One example is profiles based on different security requirements. One example is
to have a base profile which does payload encryption and identity to have a base profile which does payload encryption and identity
protection. The second profile could do the above as well as protection. The second profile could do the above as well as
source authentication. source authentication.
Mitigation of Threat Mitigation of Threat
----------------------------------------------- -----------------------------------------------
|Payload |Counter|Source |Data |Intru |Iden | | Data | Data |Source |Data |Intru |Iden |
|Encry |/Nonce |Authent|Integ |sion |tity | |Privacy | fresh |Authent|Integ |sion |tity |
|ption | |ication|rity |Dete |Prote | | | ness |ication|rity |Dete |Prote |
| | | | |ction |ction | | | | | |ction |ction |
Attack | | | | | | | Attack | | | | | | |
---------------|--------|-------|-------|-------|-------|------| ---------------|--------|-------|-------|-------|-------|------|
| 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 | - |
| of Mesages | | | | | | | | of Messages | | | | | | |
--------------------------------------------------------------- ---------------------------------------------------------------
Table 1: Security techniques to mitigate network threats Table 1: Security techniques to mitigate network threats
in ULE Networks. in ULE Networks.
A modular design to ULE Security may allow it to use and benefit A modular design to ULE Security may allow it to use and benefit
from IETF key management protocols, such as GSAKMP [RFC4535] and from IETF key management protocols, such as GSAKMP [RFC4535] and
GDOI [RFC3547] protocols defined by the IETF Multicast Security GDOI [RFC3547] protocols defined by the IETF Multicast Security
(MSEC) working group. This does not preclude the use of other key (MSEC) 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 or TLS also provide a proven security architecture defining IPsec or TLS also provide a proven security architecture defining
key exchange mechanisms and the ability to use a range of key exchange mechanisms and the ability to use a range of
cryptographic algorithms. ULE security can make use of these cryptographic algorithms. ULE security can make use of these
established mechanisms and algorithms. established mechanisms and algorithms.
7. Compatibility with Generic Stream Encapsulation 7. Compatibility with Generic Stream Encapsulation
The [ID-EF] document describes two new Header Extensions that may The [ID-EXT] document describes two new Header Extensions that
be used with Unidirectional Link Encapsulation, ULE, [RFC4326] may be used with Unidirectional Link Encapsulation, ULE,
and the Generic Stream Encapsulation (GSE) that has been designed [RFC4326] and the Generic Stream Encapsulation (GSE) that has
for the Generic Mode (also known as the Generic Stream (GS), been designed for the Generic Mode (also known as the Generic
offered by second-generation DVB physical layers, and Stream (GS)), offered by second-generation DVB physical layers,
specifically for DVB-S2 [ID-EF]. and specifically for DVB-S2 [ID-EXT].
The security threats and requirement presented in this document The security threats and requirement presented in this document
are applicable to ULE and GSE encapsulations. It might be are applicable to ULE and GSE encapsulations. It might be
desirable to authenticate some/all of the headers; such decision desirable to authenticate some/all of the headers; such decision
can be part of the security policy for the MPEG-2 transmission can be part of the security policy for the MPEG-2 transmission
network. network.
8. Summary 8. Summary
This document analyses a set of threats and security This document analyses a set of threats and security
skipping to change at page 19, line 17 skipping to change at page 19, line 21
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997. Requirement Levels", BCP 14, RFC 2119, 1997.
12.2. Informative References 12.2. Informative References
[ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution [ID-AR] G. Fairhurst, M-J Montpetit "Address Resolution
Mechanisms for IP Datagrams over MPEG-2 Networks", Mechanisms for IP Datagrams over MPEG-2 Networks",
Work in Progress <draft-ietf-ipdvb-ar-05.txt. Work in Progress <draft-ietf-ipdvb-ar-05.txt.
[ID-EXT] G. Fairhurst and B. Collini-Nocker, "Extension
Formats for Unidirectional Lightweight Encapsulation
(ULE) and the Generic Stream Encapsulation (GSE)",
Work in Progress, draft-ietf-ipdvb-ule-ext-04.txt,
August 2007.
[IEEE-802] "Local and metropolitan area networks-Specific [IEEE-802] "Local and metropolitan area networks-Specific
requirements Part 2: Logical Link Control", IEEE requirements Part 2: Logical Link Control", IEEE
802.2, IEEE Computer Society, (also ISO/IEC 8802-2), 802.2, IEEE Computer Society, (also ISO/IEC 8802-2),
1998. 1998.
[ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International [ISO-8802] ISO/IEC 8802.2, "Logical Link Control", International
Standards Organisation (ISO), 1998. Standards Organisation (ISO), 1998.
[ITU-H222] H.222.0, "Information technology, Generic coding of [ITU-H222] H.222.0, "Information technology, Generic coding of
moving pictures and associated audio information moving pictures and associated audio information
skipping to change at page 20, line 40 skipping to change at page 20, line 49
Internet Protocol", IETF RFC 4301, December 2006. Internet Protocol", IETF RFC 4301, December 2006.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, IETF RFC 3819, July 2004. Designers", BCP 89, IETF RFC 3819, July 2004.
[RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4251] T. Ylonen, C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", IETF RFC 4251, January 2006. Protocol Architecture", IETF RFC 4251, January 2006.
[ID-EF] G. Fairhurst, "Extension Formats for the ULE
Encapsulation to support the Generic Stream
Encapsulation (GSE)", Work in Progress < draft-ietf-
ipdvb-ule-ext-03.txt>.
13. Author's Addresses 13. Author's Addresses
Haitham Cruickshank,
Haitham Cruickshank Centre for Communications System Research (CCSR),
Centre for Communications System Research (CCSR) University of Surrey,
University of Surrey
Guildford, Surrey, GU2 7XH Guildford, Surrey, GU2 7XH
UK UK
Email: h.cruickshank@surrey.ac.uk Email: h.cruickshank@surrey.ac.uk
Sunil Iyengar Sunil Iyengar,
Centre for Communications System Research (CCSR) Centre for Communications System Research (CCSR),
University of Surrey University of Surrey,
Guildford, Surrey, GU2 7XH Guildford, Surrey, GU2 7XH
UK UK
Email: S.Iyengar@surrey.ac.uk Email: S.Iyengar@surrey.ac.uk
Prashant Pillai Prashant Pillai,
Mobile and Satellite Communications Research Centre (MSCRC) Mobile and Satellite Communications Research Centre (MSCRC),
School of Engineering, Design and Technology School of Engineering, Design and Technology,
University of Bradford University of Bradford,
Richmond Road, Bradford BD7 1DP Richmond Road, Bradford BD7 1DP
UK UK
Email: P.Pillai@bradford.ac.uk Email: p.pillai@bradford.ac.uk
14. IPR Notices 14. IPR Notices
Copyright (c) The IETF Trust (2007). Copyright (c) The IETF Trust (2007).
14.1. Intellectual Property Statement 14.1. Intellectual Property Statement
Full Copyright Statement Full Copyright Statement
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
skipping to change at page 24, line 30 skipping to change at page 24, line 33
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. There the ULE header and payload is shown in figure 3 below. There
could be other extension headers (either mandatory or optional) could be other extension headers (either mandatory or optional)
but these will always be placed after the security extension but these will always be placed after the security extension
header. In this way all extension headers (if any) follow the header. However, there is an exception: the timestamp extension
security extension header. When applying the security services may be placed before the security extension header [ID-EXT]. When
for example confidentiality, input to the cipher algorithm will applying the security services for example confidentiality, input
cover the fields from the end of the security extension header to to the cipher algorithm will cover the fields from the end of the
the end of the PDU. security extension header to the end of the PDU.
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | | | ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32| |Header |Header| |CRC-32|
+-------+------+-------------------------------+------+ +-------+------+-------------------------------+------+
Figure 3: ULE Security Header Extension Placement Figure 3: ULE Security Header Extension Placement
A.1.3 ULE Security Databases Block A.1.3 ULE Security Databases Block
There needs to be two databases i.e. similar to the IPSec There needs to be two databases i.e. similar to the IPSec
skipping to change at page 26, line 24 skipping to change at page 26, line 28
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. To send Security Extension Header block as shown in figure 2. To send
traffic, firstly the ULE encapsulator using the ULE_Security_ID, traffic, firstly the ULE encapsulator using the ULE_Security_ID,
Destination Address and possibly the PID, searches the ULE Destination Address and possibly the PID, searches the ULE
Security Database for the relevant security record. It then uses Security Database for the relevant security record. It then uses
the data in the record to create the ULE security extension the data in the record to create the ULE security extension
header. For received traffic, the ULE decapsulator on receiving header. For received traffic, the ULE decapsulator on receiving
the ULE SNDU will first get the record from the Security Database the ULE SNDU will first get the record from the Security Database
using the ULE_Security_ID, the Destination Address and possibly using the ULE_Security_ID, the Destination Address and possibly
the PID. It then uses this information to decrypt the ULE the PID. It then uses this information to decrypt the ULE
extension header. extension header. For both cases (either send or receive traffic)
only one interface is needed since the only difference between
For both cases (either send or receive traffic) only one the sender and receiver is the direction of the flow of traffic:
interface is needed since the only difference between the sender
and receiver is the direction of the flow of traffic:
. Get_record_database (char * Database, char * record, char * . Get_record_database (char * Database, char * record, char *
Unique_ID); Unique_ID);
>>> NOTE to RFC Editor: Please remove this appendix prior to >>> NOTE to RFC Editor: Please remove this appendix prior to
publication] publication]
Document History Document History
Working Group Draft 00 Working Group Draft 00
skipping to change at line 1253 skipping to change at page 27, line 46
o New Section 6 has been added. o New Section 6 has been added.
o The previous sections 5 and 6 have been combined to section 5. o The previous sections 5 and 6 have been combined to section 5.
o Sections 3, 8 and 9 have been rearranged and updated with o Sections 3, 8 and 9 have been rearranged and updated with
comments and suggestions from Michael Noisternig from comments and suggestions from Michael Noisternig from
University of Salzburg. University of Salzburg.
o The Authors and the Acknowledgments section have been updated. o The Authors and the Acknowledgments section have been updated.
Working Group Draft 04
o Fixed editorial mistakes and added some important changes as
pointed out by DVB-GBS group, Gorry Fairhurst and Laurence
Duquerroy.
o Table 1 modified to have consistent use of Security Services.
o Text modified to be consistent with the draft-ietf-ipdvb-ule-
ext-04.txt
 End of changes. 25 change blocks. 
85 lines changed or deleted 81 lines changed or added

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