On behalf of the authors, I wish to submit the enclosed
draft:
Security Extension for Unidirectional Lightweight
Encapsulation
Protocol <draft-cruickshank-ipdvb-sec-02.txt>
Best
wishes,
Gorry
Internet Engineering Task Force H. Cruickshank
University of Surrey, UK
Internet Draft P. Pillai
draft-cruickshank-ipdvb-sec-02.txt University of Bradford, UK
S. Iyengar
University Of Surrey, UK
Expires: December 2006 L. Duquerroy
Alcatel Alenia Space, France
Category: Internet Draft June 22, 2006
Security Extension for Unidirectional Lightweight Encapsulation
Protocol
draft-cruickshank-ipdvb-sec-02.txt
Status of this Draft
By submitting this Internet-Draft, each author represents that
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
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 22, 2006.
Abstract
This document describes the extension format for Unidirectional
Encapsulation Protocol (ULE) that secures the IP traffic
transported using ULE to provide security features like data
Cruickshank Expires December 21, 2006 [Page 1]
Internet-Draft Security Extension for ULE June 2006
confidentiality, data integrity, data origin authentication and
mechanisms to prevent replay attacks.
Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC2119 [2].
Table of Contents
1. Introduction 3
1.1. Abbreviations used in this Document 4
2. ULE Security Extension 4
2.1. Security Services 5
2.2. Secure ULE SNDU Format 6
2.2.1. Destination Address Absent (D) Field 8
2.2.2. Length Field 8
2.2.3. Type Field 8
2.2.4. Destination NPA Address Field 8
2.2.5. ULE-SID Field 8
2.2.6. Sequence Number Field 9
2.2.7. Message Authentication Code (MAC) Field 9
2.2.7.1. Type Field 9
2.2.7.2. Encrypted PDU 9
2.3. Transmitter Processing 10
2.4. Receiver Processing 10
3. Key Exchange Procedure 11
3.1. IPsec Key Management for L2 11
3.2. Alternative Key Management 12
4. Secure ULE SNDU example 12
5. Security Considerations 13
6. IANA Considerations 13
7. Acknowledgments 13
8. References 14
8.1. Normative References 14
8.2. Informative References 14
Author's Addresses 15
Intellectual Property Statement 15
Disclaimer of Validity 16
Copyright Statement 16
Cruickshank Expires December 21, 2006 [Page 2]
Internet-Draft Security Extension for ULE June 2006
1. Introduction
The Unidirectional Lightweight Encapsulation Protocol (ULE) [3]
is used for the transportation of user traffic like IP datagrams,
ethernet frames, etc. over ISO MPEG-2 Transport Streams (TS) [1].
This document describes a new ULE Mandatory extension header for
providing link layer security for ULE.
In MPEG-2 transmission networks employing ULE, there is a need to
provide link-layer security, particularly where network layer and
transport-layer security may not be sufficient. The security
requirements are presented and discussed in detail in draft-
cruickshank-ipdvb-sec-req-02. The set of security services that
the security extension for ULE can provide includes data
confidentiality, data integrity, data origin authentication and
rejection of replayed packets. The focus is on providing suitable
link encryption. However, link layer data integrity and data
origin authentication is provided as an optional security
service, especially for systems where there are several ULE
transmitters (e.g. satellite meshed systems with On-Board
Processing).
On Securing the ULE SNDUs, security is provided at the link layer
as opposed to other existing mechanisms like IP Security (IPsec)
[7] that provides security at the network-layer or TLS [10] that
provides transport layer security. Since these security services
are provided at the link layer any network layer protocol like IP
(even with Ethernet bridging) may be used with Secure ULE.
ULE may use and benefit from IETF key management protocols, such
as the MSEC GDOI [8] and GSAKMP [6]. This does not preclude the
use of other key management methods in scenarios which benefit
from this. The encryption algorithms, key lengths, etc. will be
defined making use of the standard IPsec suites. For this
purpose a security association identity similar to the IPsec SPI
[7] is used.
In some current encapsulation methods like MPE [4], encryption of
the MAC address requires each Receiver to decrypt all encrypted
data sent using a TS Logical Channel (identified by a PID),
before it can then filter the PDUs that matches the set of
Network Point of Attachment (NPA) addresses that the Receiver
wishes to receive. Therefore encryption of the MPE NPA address
is not permitted in such systems. This document specifies a
method which provides support for using temporary Layer 2 NPA
address.
Cruickshank Expires December 21, 2006 [Page 3]
Internet-Draft Security Extension for ULE June 2006
1.1. Abbreviations used in this Document
AES - Advanced Encryption Standard
DVB - Digital Video Broadcasting
GDOI - Group Domain of Interpretation
GSKAMP - Group Secure Association Key Management Protocol
IPsec - Internet Protocol Security
MPE - Multi-Protocol Encapsulation
MAC - Message Authentication Code
NAT - Network Address Translation
NCC - Network Control Centre
NPA - Network Point of Attachment
PEP - Protocol Enhancing Proxy
PID - Packet Identifier
PDU - Protocol Data Unit
SAD - Security Association Database
SHA - Standard Hash Algorithm
SNDU - SubNetwork Data Unit
SPD - Security Policy Database
TLS - Transport Layer Security
ULE - Unidirectional Lightweight Encapsulation Protocol
2. ULE Security Extension
This section describes the security services offered and the
packet format of the security extension for ULE. The procedures
for processing the security extension header at the transmitter
and the receiver are also described.
Cruickshank Expires December 21, 2006 [Page 4]
Internet-Draft Security Extension for ULE June 2006
2.1. Security Services
MPEG-2 based networks are susceptible to several security
attacks, both passive and active. Some of the main security
services (mandatory or optional) that the security extension for
ULE aims to provide for IP services running on MPEG-2 based
systems are:
o Data Confidentiality (Mandatory): Data confidentiality is
achieved by encrypting the higher layer PDU before
encapsulation in the ULE SNDU, so that only authorised
receivers can decrypt the transmitted information while an
adversary would not be able to recover the important
information even if it got hold of the transmitted data.
o Receiver NPA address hiding (mandatory): This is an important
objective for ULE security to prevent any passive attacks like
traffic analysis. Using option D=1 (no NPA address) is OK as
long as the ULE_Security_IDentifier (ULE-SID) is unique in the
whole ULE network. This implies the need for a centralised
key management system that generates the ULE-SID. If NPA
address is used (option D=0) in the base ULE header, then the
Network Control Centre (NCC) is responsible for generating a
temporary NPA address. The temporary NPA address should be
used for all secure communications with that Receiver. The ULE
encapsulator should be notified of these addresses as well. In
addition, the temporary NPA address will change from time to
time depending on the security policy and it is not directly
related to each ULE session. It can change periodically (for
example after a specified period of time and/or after a
specified volume of traffic has been sent to that terminal).
The temporary NPA address is used in association with the ULE-
SID for specific session security. It is envisaged that there
will be a small impact on the NCC for handling two NPA
addresses for each terminal.
o Data origin authentication (Optional): Data origin (source)
authentication allows a receiver to verify that the data is
sent by the claimed sender. To achieve data origin
authentication, a Message Authentication Code (MAC) is
generated for each message using a shared secret key and is
also transmitted along with the data. The ULE receiver would
also calculate the MAC for the received data using the shared
key, and then compare this computed MAC value to the one sent
by the sender along with the data. If the two matches, then
the receiver knows that the data had to be sent from the
claimed sender.
Cruickshank Expires December 21, 2006 [Page 5]
Internet-Draft Security Extension for ULE June 2006
o Data Integrity (Optional): Data integrity provides a way for
the receiver of the data message to know if the data has been
tampered in transit by an attacker. The MAC used for data
authentication also provides data integrity. The receiver of
the data calculates the MAC and compares it to the one
transmitted by the sender. If an adversary had tampered with
the message then the two MACs would not match.
o Replay Attacks Countermeasures (Optional): Methods against
replay attacks need to ensure that the received data is recent
and that an adversary has not replayed old messages at a later
time. A monotonically increasing sequence number would be used
with every message and messages with old sequence number
values would be rejected. The choice of using sequence numbers
is dictated by policy and is done by the key management
system.
Another issue is key space, which means security key storage and
the related key databases. There is a need for the following two
databases for the correct processing on security in ULE
transmitters and receivers:
o Security Policy Database (SPD): This database contains the
policies that determine the processing of all ULE
inbound/outbound traffic (such as encrypting all outbound ULE
traffic destined to a certain terminal).
o Security Association Database (SAD): Each entry defines the
parameters associated with one ULE-SID such as encryption
keys, keys and algorithms used for calculating the MAC,
presence of Sequence number and MAC. Each ULE-SID has an entry
in the SAD.
This document proposes to re-use existing techniques in IPsec
architecture and therefore the SPD and the SAD will follow the
format of these databases as defined in RFC 4301 [7]. The
security suite of algorithms for data encryption and data
authenticity / integrity specified in IPsec/MSEC will be used for
ULE security. The design of these databases will be simpler and
also the lookups because unlike in IPsec only the ULE-SID along
with the NPA address is needed to retrieve the data from these
databases.
2.2. Secure ULE SNDU Format
The security extension aims to secure the transmission of user
traffic over MPEG-2 Transport Streams. In order to address the
Cruickshank Expires December 21, 2006 [Page 6]
Internet-Draft Security Extension for ULE June 2006
security issues, Figure 1 shows the SNDU format with the security
extension header.
This security extension is a standard extension header as
described in Section 5 of RFC 4326 [3] and it should not affect
the ULE base protocol. This security extension header MAY
directly follow the ULE base header as shown in Figure 1 or it
MAY also follow another specific extension header.
This security extension header is a Mandatory ULE Extension
header. This means that a receiver MUST either process this
header before it processes the next extension header or the
encapsulated PDU, otherwise the entire SNDU should be discarded.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|D| Length | Type = S-ULE |
+-+----------------------------+------------------------------+
| Receiver Destination NPA Address * |
| +------------------------------+
| | ULE_Security_ID |
+------------------------------+------------------------------+
| ULE_Security_ID | Sequence Num.(Optional) |
+------------------------------+------------------------------+
| Sequence Number (Optional) | MAC (Optional) |
+------------------------------+------------------------------+
| MAC (Optional) | Type = Type of PDU |
+------------------------------+------------------------------+
| |
| |
= Encrypted PDU =
| |
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Code |
+-------------------------------------------------------------+
Figure 1 General SNDU format with Security extension header (D=0)
In Figure 1, the Type field in the base header denotes that the
mandatory security extension header is present. The receiver
destination NPA address is optional. After the base ULE header
the security extension header is followed. This header contains
the ULE-SID, the optional Sequence Number field and the optional
Message Authentication Code (MAC) field. The next type field
denotes the type of the enclosed PDU. The higher layer PDU is
encrypted and then encapsulated in the SNDU.
Cruickshank Expires December 21, 2006 [Page 7]
Internet-Draft Security Extension for ULE June 2006
The format of the Destination Address Absent field (D), the
Length field the Type field and the Receiver Destination NPA
address field directly follow and are used in the same way as
defined for standard ULE [3].
2.2.1. Destination Address Absent (D) Field
The most significant bit of the Length Field carries the value of
the Destination Address Absent Field (D) which follows the same
definition as in standard ULE [3]. When D is set to 0, it
indicates the presence of the Destination Address Field while D
set to 1 indicates that a Destination Address Field is not
present.
2.2.2. Length Field
A 15-bit Length field denotes the length, in bytes, of the SNDU
counted from the byte following the Type field, up to and
including the CRC [3].
2.2.3. Type Field
A 16-bit Type Field indicates that this is a Secure ULE SNDU [3].
[XXX IANA ACTION REQUIRED XXX]
IANA action is required to assign the Type field for the security
extension header.
[XXX END of IANA ACTION XXX]
2.2.4. Destination NPA Address Field
The SNDU Destination Address Field is optional. This field is
MUST be carried when field D is set to 0 and may be omitted when
D=1 [3].
2.2.5. ULE-SID Field
A 32-bit security identifier, the ULE-SID similar to the Security
Parameter Index (SPI) used in IPsec has been added to uniquely
identify the secure session. This ULE-SID would represent the
security association between the MPEG-2 transmitter and receiver
for a particular session and will indicate the keys and
algorithms used for encrypting the data payload and calculating
the MAC. The ULE-SID can be used by a receiver to filter PDUs
along with the NPA address.
Cruickshank Expires December 21, 2006 [Page 8]
Internet-Draft Security Extension for ULE June 2006
2.2.6. Sequence Number Field
An optional 32-bit sequence number has been added to the ULE SNDU
to prevent replay attacks. The gateway would monotonically
increment this number when it sends a packet to the receiver and
the receiver would verify the correct sequence number. If an
adversary tries to inject or replay old packets the sequence
number would not match. This would result in discarding the
packet.
2.2.7. Message Authentication Code (MAC) Field
To provide both data origin authentication and data integrity, a
Message Authentication Code (MAC) is used in the extension
header.
The MAC is calculated over the security extension header and the
encrypted data payload. The receiver would calculate the MAC for
the received packet and compare it with the transmitted value.
The two would not match in only 2 cases, firstly either there was
an error during processing or transmission over the MPEG-2
Network, or secondly the packet has not been sent from an
authenticated entity.
In either case, the packet should be discarded. Hence the same
MAC can be used for data origin authentication and to provide
data integrity for transmission/processing errors.
2.2.7.1. Type Field
This second type field denotes the type of packet that is
encrypted and encapsulated in the Secure ULE SNDU.
2.2.7.2. Encrypted PDU
To achieve data confidentiality, the traffic between the MPEG-2
TS Transmitter (ULE Encapsulator) and Receiver needs to be
encrypted. The network layer PDUs are first encrypted and then
encapsulated in the Secure ULE SNDU. The security associations
between the two communicating points will describe the algorithms
and keys used for encryption purposes.
Secure ULE does not impose the use of any specific encryption
algorithm and should be able to support the commonly used
algorithms like DES, 3DES etc.
Cruickshank Expires December 21, 2006 [Page 9]
Internet-Draft Security Extension for ULE June 2006
2.3. Transmitter Processing
The following procedure is followed at the encapsulator for
processing the security extension header for ULE:
o Upon reception of the higher layer PDU, the SPD is first
queried to check the policy to be applied to the packet. If
security is needed then an SA must exist in the SAD (this is
done by the key management system). The parameters are
retrieved from the SAD and the PDU is first encrypted using
the key and the algorithm as indicated in the SAD
o The header of the base protocol (and other extension headers
if present) would be added to the SNDU.
o The ULE-SID for the security association between the
transmitter and the receiver would be added next.
o The SAD would be used to see if the sequence number has to be
added. If yes, then the corresponding sequence number is added
to the SNDU.
o The SAD would also be checked to see if the data origin
authentication and data integrity has to be provided. If yes,
then the MAC has to be calculated. The MAC is calculated over
the encrypted PDU, the Security header i.e. the ULE-SID and
the Sequence Number (if present) and the secret key. The MAC
is then added to the extension header in the SNDU.
o Then the encrypted higher layer PDU is encapsulated to the
SNDU.
o Finally, the CRC is calculated as defined in Section 4.6 of
RFC4326 [3] and added.
2.4. Receiver Processing
The following procedure is followed at the receiver for
processing the security extension header for ULE:
o Upon reception of the Secure ULE SNDU, the receiver may first
filter the received packets according to the receiver
destination NPA address (if present).
o The CRC is verified as defined in RFC4326 [3].
o It would then use the ULE-SID to obtain the security
Cruickshank Expires December 21, 2006 [Page 10]
Internet-Draft Security Extension for ULE June 2006
associations between the transmitter and receiver and retrieve
the data from the SAD. With this the receiver would know if
the sequence number and the MAC are present or not. This would
also be used to get the algorithms and keys used for both
encryption of the encapsulated PDU and for generation of the
message authentication code.
o It would then use the sequence number for filtering out any
out of-sequence packets.
o The next step would be to check the MAC to verify the
authenticity and integrity of the received packet. If the
calculated MAC does not match the transmitted MAC, then the
packet is discarded.
o Finally the encapsulated payload will be decrypted.
3. Key Exchange Procedure
This section describes the key exchange procedure, used to
install and manage the keys at Receivers. There is a need to
take into account the two cases described in [9], both
unidirectional and bi-directional transfers. The key management
procedures are independent from the ULE operations. During the
key exchange procedure, the ULE-SID will be defined.
The exact data encryption and data integrity choices are linked
to the key management systems in use. One example is the security
suite 1 (defined in GSAKMP [6]). This uses AES (CBC mode, Key
Length: 128 bits) for data encryption and DSS-ASN1-DER for
digital signature and SHA-1 as the Hash algorithm. Other suites
will be added in future versions.
A detailed key management system is not presented in this
document, but two approaches are outlined.
3.1. IPsec Key Management for L2
Existing key management systems can be used such as the MSEC key
exchange protocols, GDOI and GSAKMP. The format of the ULE-SID
will be identical to the security association as defined in GDOI
or GSAKMP. The initial key exchange between the security server
(which may reside with the NCC) and the ULE receiver can be
transported either within the ULE network or may be performed by
some other means. This is a matter of policy and an architecture
decision. For example, for bi-directional transfers the whole key
exchange procedures could be carried within the ULE network,
Cruickshank Expires December 21, 2006 [Page 11]
Internet-Draft Security Extension for ULE June 2006
while for unidirectional transfers, some other bidirectional
connection should be used.
3.2. Alternative Key Management
The method described here for link security could be used with
alternative key management systems when used as a part of a
system that already implements a key management infrastructure
(e.g. the DVB-RCS security system [5]). The format of the ULE-SID
will be the same format as defined in DVB-RCS security
procedures.
4. Secure ULE SNDU example
This section shows the ULE SNDU with the security extension
header when IP datagrams are secured using Secure ULE.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|D| Length (15 bits) | Type = S-ULE |
+-+----------------------------+------------------------------+
| Temporary Receiver Destination NPA Address (48 bits) |
| +------------------------------+
| | ULE_Security_ID |
+------------------------------+------------------------------+
| ULE_Security_ID | Sequence Num.(Optional) |
+------------------------------+------------------------------+
| Sequence Number (Optional) | MAC (Optional) |
+------------------------------+------------------------------+
| MAC (Optional) | Type = Type of IPv4 |
+------------------------------+------------------------------+
| |
= Encrypted IP Datagram =
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Code (32 bits) |
+-------------------------------------------------------------+
Figure 2 Secure ULE SNDU with D=0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+----------------------------+------------------------------+
|1| Length (15 bits) | Type = S-ULE |
+-+----------------------------+------------------------------+
| ULE_Security_ID |
+-------------------------------------------------------------+
| Sequence Number (Optional) |
+------------------------------+------------------------------+
Cruickshank Expires December 21, 2006 [Page 12]
Internet-Draft Security Extension for ULE June 2006
| Message Authentication Code (Optional) |
+------------------------------+------------------------------+
| Type = IPv4 | |
+------------------------------+ |
| |
= Encrypted IP Datagram =
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Code |
+-------------------------------------------------------------+
Figure 3 Secure ULE SNDU with D=1
5. Security Considerations
Link-level (L2) encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.
provided by TLS, SSH, Open PGP, S/MIME, IPsec). A common
objective is to provide the same level of privacy as terrestrial
links. This document defines a method to provide optional link
encryption. The method may also support optional link level
integrity / authentication of the SNDU payload plus sequence
numbers for anti-replay attacks. This is provided in a flexible
way using a ULE Mandatory Extension Header. This decouples
specification of the security functions from the encapsulation
functions. This method also supports encryption of the NPA
addresses. The encryption and integrity algorithms are similar to
the ones used in IPsec/MSEC protocols.
6. IANA Considerations
IANA action is required to assign the Type field for the security
extension header (Section 2.2.3).
7. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen), Stephane Coombes (ESA) and Yim Fun Hu
(University of Bradford) in the preparation of this draft.
Cruickshank Expires December 21, 2006 [Page 13]
Internet-Draft Security Extension for ULE June 2006
8. References
8.1. Normative References
[1] ISO/IEC DIS 13818-1, "Information technology - Generic
codeing of moving pictures and associated audio information
- Part1: Systems", International Standards Organisation
(ISO)
[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Streams", RFC 4326,
December 2005.
8.2. Informative References
[4] "Digital Video Broadcasting (DVB): DVB Specifications for
Data Broadcasting", ETSI EN 301 192 v1.3.1, 2003.
[5] "Digital Video Broadcasting (DVB): Interaction Channel for
satellite distribution systems", ETSI EN 301 790 v1.4.1,
2005.
[6] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protcol", IETF
draft (work in progress), May 2005.
[7] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[8] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[9] Montpetit, M., Fairhurst, G., Clausen, H., Collini-Nocker,
B., and H. Linder, "A Framework for Transmission of IP
Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[10] http://www.ietf.org/html.charters/tls-charter.html
Cruickshank Expires December 21, 2006 [Page 14]
Internet-Draft Security Extension for ULE June 2006
Author's Addresses
Haitham Cruickshank
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: h.cruickshank@surrey.ac.uk
Prashant Pillai
Mobile and Satellite Communications Research Centre
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: p.pillai@bradford.ac.uk
Sunil Iyengar
Centre for Communications System Research (CCSR)
University of Surrey
Guildford, Surrey, GU2 7XH
UK
Email: S.Iyengar@surrey.ac.uk
Laurence Duquerroy
Research Department/Advanced Telecom Satellite Systems
Alcatel Space, Toulouse
France
E-Mail: Laurence.Duquerroy@space.alcatel.fr
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementers or users of this
Cruickshank Expires December 21, 2006 [Page 15]
Internet-Draft Security Extension for ULE June 2006
specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to
the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
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 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 Internet Society (2006).
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.
Cruickshank Expires December 21, 2006 [Page 16]