draft-ietf-ipdvb-sec-req-00.txt   draft-ietf-ipdvb-sec-req-01.txt 
Internet Engineering Task Force H.Cruickshank Internet Engineering Task Force H.Cruickshank
Internet Draft S. Iyengar Internet Draft S. Iyengar
draft-ietf-ipdvb-sec-req-00.txt University of Surrey, UK draft-ietf-ipdvb-sec-req-01.txt University of Surrey, UK
L. Duquerroy L. Duquerroy
Alcatel Alenia Space, France Alcatel Alenia Space, France
Expires: June 8, 2007 P. Pillai Expires: September 2, 2007 P. Pillai
University of Bradford, UK University of Bradford, UK
Category: Internet Draft December 8, 2006 Category: WG Draft intended for PS March 2, 2007
Security requirements for the Unidirectional Lightweight Security requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol Encapsulation (ULE) protocol
draft-ietf-ipdvb-sec-req-00.txt draft-ietf-ipdvb-sec-req-01.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 June 8, 2007. This Internet-Draft will expire on September 2, 2007.
Abstract Abstract
The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a The MPEG-2 standard defined by ISO 13818-1 [ISO-MPEG2] supports a
range of transmission methods for a range of services. This range of transmission methods for a range of services. This
document provides a threat analysis and derives the security document provides a threat analysis and derives the security
requirements when using the Transport Stream, TS, to support an requirements when using the Transport Stream, TS, to support an
Internet network-layer using Unidirectional Lightweight Internet network-layer using Unidirectional Lightweight
Encapsulation (ULE) [RFC4326]. The document also provides the Encapsulation (ULE) [RFC4326]. The document also provides the
motivation for link-level security for a ULE Stream. A ULE Stream motivation for link-level 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......................................3 2. Requirements notation......................................4
3. Threat Analysis...........................................5 3. Threat Analysis...........................................6
3.1. System Components.....................................6 3.1. System Components.....................................6
Figure 1: An example configuration for a unidirectional........6
Service for IP transport over MPEG-2 [RFC4259]................6
3.2. Threats..............................................8 3.2. Threats..............................................8
3.3. Threat Scenarios.....................................10 3.3. Threat Scenarios......................................9
4. Security Requirements for IP over MPEG-2 TS...............11 4. Security Requirements for IP over MPEG-2 TS...............11
5. IPsec and MPEG-2 Transmission Networks....................12 5. IPsec and MPEG-2 Transmission Networks....................12
6. Motivation for ULE link-layer security....................13 6. Motivation for ULE link-layer security....................13
6.1. Link security below the Encapsulation layer..........13 6.1. Link security below the Encapsulation layer..........13
6.2. Link security as a part of the Encapsulation layer....14 6.2. Link security as a part of the Encapsulation layer....14
7. Summary..................................................15 7. Summary..................................................15
8. Security Considerations...................................15 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..............................16 11.2. Informative References..............................16
Author's Addresses..........................................18 Author's Addresses..........................................18
Intellectual Property Statement..............................19 Intellectual Property Statement..............................19
Disclaimer of Validity......................................19 Disclaimer of Validity.............Error! Bookmark not defined.
Copyright Statement.........................................19 Copyright Statement................Error! Bookmark not defined.
Document History............................................20
Appendix A: ULE Security Framework...........................22
1. Introduction 1. Introduction
The MPEG-2 Transport Stream (TS) has been widely accepted not The MPEG-2 Transport Stream (TS) has been widely accepted not
only for providing digital TV services, but also as a subnetwork only for providing digital TV services, but also as a subnetwork
technology for building IP networks. RFC 4326 [RFC4326] describes technology for building IP networks. RFC 4326 [RFC4326] describes
the Unidirectional Lightweight Encapsulation (ULE) mechanism for the Unidirectional Lightweight Encapsulation (ULE) mechanism for
the transport of IPv4 and IPv6 Datagrams and other network the transport of IPv4 and IPv6 Datagrams and other network
protocol packets directly over the ISO MPEG-2 Transport Stream as protocol packets directly over the ISO MPEG-2 Transport Stream as
TS Private Data. ULE specifies a base encapsulation format and TS Private Data. ULE specifies a base encapsulation format and
skipping to change at page 6, line 34 skipping to change at page 6, line 41
MPEG-2 -->+ MPEG-2 | | MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | | TS --->+ Multiplexor | |
---->+------+--------+ | ---->+------+--------+ |
|MPEG-2 TS Mux | |MPEG-2 TS Mux |
| | | |
+------+--------+ +------+-----+ +------+--------+ +------+-----+
|Physical Layer | | MPEG-2 | |Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver | |Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+ +---------------+ MPEG-2 +------------+
TS Mux TS Mux
Figure 1 :An example configuration for a unidirectional Service Figure 1: An example configuration for a unidirectional
for IP transport over MPEG-2 [RFC4259]. Service for IP transport over MPEG-2 [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 (or Encapsulator or ULE source) o ULE Encapsulation Gateways (or Encapsulator or ULE source)
o SI-Table signalling generator (input to the multiplexor) o SI-Table signalling generator (input to the multiplexor)
o Receivers o Receivers
o TS multiplexers (including re-multiplexers) o TS multiplexers (including re-multiplexers)
o Modulators o Modulators
In an MPEG-2 network a set of signalling messages [ID-AR] may In an MPEG-2 network a set of signalling messages [ID-AR] may
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 L2 control plane. Examples of signalling device) to form the L2 control plane. Examples of signalling
messages include the Program Association Table (PAT), Program Map messages include the Program Association Table (PAT), Program Map
Table (PMT) and Network Information Table (NIT). In existing Table (PMT) and Network Information Table (NIT). In existing
MPEG-2 transmission networks, these messages are broadcast in the MPEG-2 transmission networks, these messages are broadcast in the
skipping to change at page 8, line 27 skipping to change at page 8, line 31
The PID associated with an Elementary Stream can therefore be The PID associated with an Elementary Stream can therefore be
modified (e.g. in some systems by reception of an updated SI modified (e.g. in some systems by reception of an updated SI
table, or in other systems until the next announcement/discovery table, or in other systems until the next announcement/discovery
data is received). An attacker that is able to modify the content data is received). An attacker that is able to modify the content
of the received multiplex (e.g. replay data and/or control of the received multiplex (e.g. replay data and/or control
information) could inject data locally into the received stream information) could inject data locally into the received stream
with an arbitrary PID value. with an arbitrary PID value.
One method to provide security is to secure the entire Stream at One method to provide security is to secure the entire Stream at
the MPEG-2 TS level. This stream of TS Packets carried in a the MPEG-2 TS level. This stream of TS Packets carried in a
multiplex are usually received by many Receivers. The approach is multiplex is usually received by many Receivers. The approach is
well-suited to TV-transmission, data-push, etc, where the PID well-suited to TV-transmission, data-push, etc, where the PID
carries one or a set of flows (e.g. video/audio Packetized carries one or a set of flows (e.g. video/audio Packetized
Elementary Stream (PES) Packets) with similar security Elementary Stream (PES) Packets) with similar security
requirements. requirements.
Where a ULE Stream carries a set of IP traffic flows to different Where a ULE Stream carries a set of IP traffic flows to different
destinations with a range of properties (multicast, unicast, destinations with a range of properties (multicast, unicast,
etc), it is often not appropriate to provide IP confidentiality etc), it is often not appropriate to provide IP confidentiality
services for the entire ULE Stream. For many expected services for the entire ULE Stream. For many expected
applications of ULE, a finer-grain control is therefore required, applications of ULE, a finer-grain control is therefore required,
skipping to change at page 15, line 27 skipping to change at page 15, line 26
[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. This authentication is
desirable in many scenarios to ensure that the correct desirable in many scenarios to ensure that the correct
information is being exchanged between the trusted entities, information is being exchanged between the trusted entities,
whereas Layer 2 methods cannot provide this guarantee. whereas Layer 2 methods cannot provide this guarantee.
IPsec /TLS also provides a proven security architecture defining IPsec /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 but the advantages are established mechanisms and algorithms but the advantages are
distinct from those when using IPsec or TLS. distinct from those when using IPsec or TLS.
7. Summary 7. Summary
This document analyses a set of threats and security This document analyses a set of threats and security
requirements. It also defines the requirements for ULE security requirements. It also defines the requirements for ULE security
and states the motivation for link security as a part of the and states the motivation for link security as a part of the
skipping to change at page 18, line 24 skipping to change at page 18, line 20
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 [ID-EF] G. Fairhurst, "Extension Formats for the ULE
Encapsulation to support the Generic Stream Encapsulation to support the Generic Stream
Encapsulation (GSE)", Work in Progress < draft- Encapsulation (GSE)", Work in Progress < draft-
fairhurst-ipdvb-ule-ext-00.txt>. fairhurst-ipdvb-ule-ext-xx.txt>.
Author's Addresses 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
skipping to change at page 19, line 4 skipping to change at page 18, line 46
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
Laurence Duquerroy Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse Alcatel Space, Toulouse
France France
E-Mail: Laurence.Duquerroy@space.alcatel.fr E-Mail: Laurence.Duquerroy@space.alcatel.fr
Prashant Pillai Prashant Pillai
Mobile and Satellite Communications Research Centre Mobile and Satellite Communications Research Centre
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
Intellectual Property Statement 12. IPR Notices
Copyright (c) The IETF Trust (2007).
12.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.
12.2. Intellectual Property
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 19, line 36 skipping to change at page 20, line 8
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.
Disclaimer of Validity 13. Copyright Statement
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.
Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions Copyright (C) The IETF Trust (2007).
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
>>> 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
WG-ID-00 Individual Draft-ID-00
o This draft is intended as a study item for proposed future o This draft is intended as a study item for proposed future
work by the IETF in this area. work by the IETF in this area.
o Major security concerns from Steve Bellovin who also agreed o Major security concerns from Steve Bellovin who also agreed
that Layer 2 Address hiding is a necessary security service. that Layer 2 Address hiding is a necessary security service.
o Motivation for security over ULE was not clear (Joerg Ott) o Motivation for security over ULE was not clear (Joerg Ott)
o Not sure where this was leading for Non -IP traffic and key o Not sure where this was leading for Non -IP traffic and key
skipping to change at page 20, line 40 skipping to change at page 20, line 42
Issues to be resolved in next revision (01): Issues to be resolved in next revision (01):
o Title change (inserted "security requirements " rather than o Title change (inserted "security requirements " rather than
"security extension") "security extension")
o Separate security requirements draft o Separate security requirements draft
o Threat Analysis o Threat Analysis
WG-ID-01 Individual Draft -ID-01
o Load of discussion on the mailing lists regarding signalling o Load of discussion on the mailing lists regarding signalling
traffic security and the threats involved (Gorry, Montpetit traffic security and the threats involved (Gorry, Montpetit
and Art) and Art)
o Benefits of IPSec over ULE as well as the fact the document o Benefits of IPSec over ULE as well as the fact the document
was not easy to read (Gerrard Gessler and Wolfgang Fritche) was not easy to read (Gerrard Gessler and Wolfgang Fritche)
o What were the benefits of NPA protection? o What were the benefits of NPA protection?
o Threats in broadcast networks was raised by Gorry o Threats in broadcast networks was raised by Gorry
Issues to be resolved in next revision (02): Issues to be resolved in next revision (02):
o Add section 3 on threats o Add section 3 on threats
o Address Signalling threats o Address Signalling threats
o Make the document easy to read o Make the document easy to read
skipping to change at page 21, line 14 skipping to change at page 21, line 16
o Threats in broadcast networks was raised by Gorry o Threats in broadcast networks was raised by Gorry
Issues to be resolved in next revision (02): Issues to be resolved in next revision (02):
o Add section 3 on threats o Add section 3 on threats
o Address Signalling threats o Address Signalling threats
o Make the document easy to read o Make the document easy to read
WG-ID-02 Individual Draft -ID-02
o Merged draft with the one proposed by Prashant and included o Merged draft with the one proposed by Prashant and included
him as an author. him as an author.
o Define the threat scenarios and the security requirement for o Define the threat scenarios and the security requirement for
these scenarios. these scenarios.
o English fixed o English fixed
Issues to be resolved in next revision (03): Issues to be resolved in next revision (03):
o Include subsection 3.1 Threat Scenarios and the requirements o Include subsection 3.1 Threat Scenarios and the requirements
for these scenarios for these scenarios
o English Fixed o English Fixed
WG-ID-03 Individual Draft -ID-03
o Major comments and suggestions (Michael Noistering) regarding o Major comments and suggestions (Michael Noistering) regarding
authentication and integrity assurance. He also suggested that authentication and integrity assurance. He also suggested that
the threat scenarios (section 3.2) should be expanded. the threat scenarios (section 3.2) should be expanded.
o Elaborate the impact of threats for IP as opposed to Layer 2 o Elaborate the impact of threats for IP as opposed to Layer 2
(Gorry Fairhurst) (Gorry Fairhurst)
Issues to be resolved in next revision (04): Issues to be resolved in next revision (04):
o Expanded the threat scenarios. o Expanded the threat scenarios.
o Algorithm Agility added as a requirement (gorry) o Algorithm Agility added as a requirement (gorry)
o Nits have been taken care of and addressed. o Nits have been taken care of and addressed.
o English Fixed o English Fixed
Individual Draft -ID-04
WG-ID-04
o Minor comment from Michael regarding replay protection o Minor comment from Michael regarding replay protection
o Minor comments form Gorry. o Minor comments form Gorry.
Issues to be resolved in next revision (05): Issues to be resolved in next revision (05):
o Nits have been taken care of and addressed. o Nits have been taken care of and addressed.
o English Fixed o English Fixed
[>>> NOTE to RFC Editor: End of appendix] Working Group Draft 00
o Fixed editorial mistakes and ID style for WG adoption.
Working Group Draft 01
o Fixed editorial mistakes and added some changes as pointed out
by Knut (ESA) and added an appendix which shows the framework
for securing the ULE network.
Appendix A: ULE Security Framework
This section aims to define a preliminary security framework for
widespread deployment of secure ULE networks.
Building Blocks
This ULE Security framework defines the following building blocks
as shown in the figure 2 below:
1. The Key Management Block
2. The ULE Extension Header Block
3. The ULE Databases Block
+------+----------+ +----------------
| Key Management |/------------\| Key Management |
| Block |\------------/| Block |
| Group Member | | Group Server |
+------+----------+ +----------------
| |
| |
| |
| |
| |
\ /
+------+----------+
| ULE |
| SAD / SPD |
| Interface Block |
+------+-+--------+
/ \
| |
| |
| |
| |
| |
| |
+------+-+--------+
| ULE Security |
| Extension Header|
| Block |
+-----------------+
Figure 2: Secure ULE framework Building Blocks
1. Key Management Block
In order to provide security at the ULE level using extension
headers, a key management framework is required. This key
management framework is responsible for user authentication,
access control, and Security Association negotiation (which
include the negotiations of the security algorithms to be used
and the generation of the different session keys as well as
policy material). This Key management framework can be either
automated or manual. Hence Key management client entity will be
present in all ULE receivers as well as ULE sources. In some
cases the ULE source could also be the Key Server Entity. Key
management protocols like GSAKMP may be used or manual insertion
of keying material can also be deployed.
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 draft.
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. There could be other extension
headers placed before or after the ULE Security Header extension
+-------+------+-------------------------------+------+
| ULE |SEC | Protocol Data Unit | |
|Header |Header| |CRC-32|
+-------+------+-------------------------------+------+
Figure 3: ULE Sec Header extension Placement
3. ULE Databases Block
There needs to be two databases i.e. similar to the IPSec
databases.
o ULE-SAD: ULE Secure Association Database contains all the
Security Associations that are currently established with
different ULE peers.
o ULE-SPD: ULE Secure Policy Database contains the policies as
defined by the system manager. Those policies describe the
security services that must be enforced
The design of these two databases will be based on IPSec
databases as defined in RFC4301 [RFC4301].
Interface definition
Two new interfaces have to be defined between the three blocks as
shown in figure 2 above. These interfaces are:
o Key management <-> ULE Security databases
o ULE Security databases <-> ULE interfaces
While the first interface is used by the Key Management Block to
insert keys, security associations and policies into the ULE
Database Block, the second interface is used by the ULE Extension
Header Block to get the keys and policy material for the ULE
Payloads.
1. Key management <-> ULE Security databases
This interface is between the Key Management client block (GM
client) and the ULE Security Database block. The Key management
client will communicate with the GCKS and then get the relevant
security information (keys, cipher mode, security service,
ULE_Security_ID and other relevant keying material as well as
policy) and insert this data into the ULE Security database
block. The ULE Security database block holds the records of all
security associations currently used as well as information for
security policy control. The Key management could be either
automated (GSAKMP) or manually inserted using this interface. The
following three interface functions are defined:
. Insert_record_database (char * Database, char * record, char *
Unique_ID);
. Update_record_database (char * Database, char * record, char *
Unique_ID);
. Delete_record_database (char * Database, char * Unique_ID);
2. ULE Security databases <-> ULE interfaces
This interface is between the ULE Security Database and the ULE
Engine. For Outbound Traffic, firstly the ULE Engine using the
Destination Address and the ULE_Security_ID searches the ULE
Security Database for the relevant security record. It then uses
the record data to create the ULE security extension header
[ref]. For inbound traffic, the ULE engine on receiving the ULE
packet will first get the record from the Security Database using
the Destination Address and the ULE_Security_ID. It then uses
this information to decrypt the ULE extension header.
In both cases only one interface is needed:
. Get_record_database (char * Database, char * record, char *
Unique_ID);
 End of changes. 29 change blocks. 
40 lines changed or deleted 52 lines changed or added

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