Internet Engineering Task Force H. Cruickshank
Internet Draft University of Surrey, UK
draft-cruickshank-ipdvb-sec-05.txt P. Pillai
Expires: January 13, 2009 University of Bradford, UK
S. Iyengar
Logica, UK
Category: Internet draft July 14, 2008
Security Extension for Unidirectional Lightweight Encapsulation
Protocol
draft-cruickshank-ipdvb-sec-05.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 January 13, 2009.
Abstract
This document describes the header extension for Unidirectional
Encapsulation Protocol (ULE) that secures the IP traffic
transported using ULE to provide security features like data
confidentiality, data integrity, data origin authentication and
mechanisms to prevent replay attacks. The format of the header
extension and processing at the Receiver and Transmitter are
Cruickshank et.al. Expires January 13, 2009 [Page 1]
Internet-Draft Security Extension for ULE July 2008
described in detail.
Table of Contents
1. Introduction................................................2
2. Requirements notation.......................................3
3. Abbreviations used in the document..........................3
4. ULE Security Extension......................................4
4.1. Security Services......................................4
4.2. Secure ULE SNDU Format.................................6
4.3. Transmitter Processing.................................9
4.4. Receiver Processing...................................10
5. Key Exchange Procedure.....................................11
5.1. IPsec Key Management for L2...........................11
5.2. Alternative Key Management............................11
6. Secure ULE SNDU example....................................12
7. Security Considerations....................................13
8. IANA Considerations........................................13
9. Acknowledgments............................................13
10. References................................................13
10.1. Normative References.................................13
10.2. Informative References...............................14
11. Author's Addresses........................................14
12. IPR Notices...............................................15
12.1. Intellectual Property Statement......................15
12.2. Intellectual Property................................16
13. Copyright Statement.......................................16
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 present or may not be
sufficient. The security requirements are presented and discussed
in detail in [4]. 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. While providing suitable link encryption is mandatory,
link layer data integrity and data origin authentication is
provided as an optional security service. These are especially
desirable for systems where there are several ULE transmitters
Cruickshank et. al. Expires January 13, 2009 [Page 2]
Internet-Draft Security Extension for ULE July 2008
(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)
[8] that provides security at the network-layer or TLS [11] 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 Group Domain of Interpretation (GDOI) [9] and Group
Secure Association Key Management Protocol (GSAKMP) [7]. This
does not preclude the use of other key management methods in
scenarios for which there is benefit. 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 Security Parameter Index (SPI)[8] is used.
In some current encapsulation methods like Multi-Protocol
Encapsulation (MPE) [5], 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.
2. 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
[2].
3. Abbreviations used in the 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
Cruickshank et. al. Expires January 13, 2009 [Page 3]
Internet-Draft Security Extension for ULE July 2008
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
SPI - Security Parameter Index
TLS - Transport Layer Security
ULE - Unidirectional Lightweight Encapsulation Protocol
4. 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.
4.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 (and other ULE
Cruickshank et. al. Expires January 13, 2009 [Page 4]
Internet-Draft Security Extension for ULE July 2008
extensions headers that may be present and require security)
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 (optional): The SNDU type that is
visible to all receivers has the value "encrypted content",
whereas the type of PDU being carried is described using a
field within the encrypted payload. This is an important
objective for ULE security to prevent any passive attacks like
traffic analysis. The option D=1 (i.e. no NPA address
present) is permitted 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 an NPA address is used (option D=0)
in the base ULE header and NPA address hiding is utilized,
then encrypted NPA address should be used. The combination of
the ULE-SID and encrypted NPA will guarantee the uniqueness of
the security association even in the case of a decentralized
key management system.
o Data origin authentication (Optional): Data origin (source)
authentication allows a ULE receiver to verify that the data
is sent by the claimed ULE 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
calculates the MAC for the received data using the shared key,
and then compares this computed MAC value to the one sent by
the sender along with the data. If the two match, then the
receiver knows that the data had to be sent from the claimed
sender.
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
Cruickshank et. al. Expires January 13, 2009 [Page 5]
Internet-Draft Security Extension for ULE July 2008
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. 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 specification may 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 [8]. 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 and possibly the PID is needed to retrieve
the data from these databases.
4.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
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 does not affect the
ULE base protocol. This security extension header is a Mandatory
ULE Extension header. This means that a receiver MUST process
this header before it processes the next extension header or the
encapsulated PDU, otherwise the entire SNDU should be discarded.
Cruickshank et. al. Expires January 13, 2009 [Page 6]
Internet-Draft Security Extension for ULE July 2008
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 Number (Optional) |
+------------------------------+------------------------------+
| Sequence Number (Optional) | Next-Type = Type of PDU |
+------------------------------+------------------------------+
| |
| |
= Encrypted PDU =
| |
| |
+------------------------------+------------------------------+
| |
= Message Authentication Code (Optional) =
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Check |
+-------------------------------------------------------------+
Figure 1 General SNDU format with Security extension header (D=0)
In Figure 1, the Type field in the base header denotes that a
mandatory security extension header is present. The receiver
destination NPA address is optional. After the base ULE header
the security extension header follows. 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.
The format of the Destination Address Absent field (D), the
Length field the Type field and the Receiver Destination NPA
address field are defined by ULE [3].
4.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) as defined by ULE [3].
Cruickshank et. al. Expires January 13, 2009 [Page 7]
Internet-Draft Security Extension for ULE July 2008
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.
4.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].
4.2.3. Type Field
A 16-bit Type Field indicates that this is a Secure ULE SNDU [3].
[XXX IANA ACTION REQUIRED to allocate xxS-ULExx XXX]
The S-ULE header is defined in the IANA maintained Next-Header
Registry for ULE and has the value xxS-ULExx
[XXX END of IANA ACTION XXX]
4.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].
4.2.5. ULE-SID Field
A 32-bit security identifier, the ULE-SID similar to the SPI used
in IPsec has been added to uniquely identify the secure session.
This ULE-SID represents the security association between the
MPEG-2 transmitter and receiver for a particular session and
indicates the keys and algorithms used for encrypting the data
payload and calculating the MAC. The ULE-SID is used by a
receiver to filter PDUs in combination with the NPA address when
present.
4.2.6. Sequence Number Field
An optional 32-bit sequence number MAY be included in the ULE
SNDU to prevent replay attacks. The gateway monotonically
increments this number when it sends a packet to the receiver and
the receiver verifies the correct sequence number and MUST
discard all SNDUs which do not match. If an adversary tries to
inject or replay old packets the sequence number would not match.
This would result in discarding the packet.
Cruickshank et. al. Expires January 13, 2009 [Page 8]
Internet-Draft Security Extension for ULE July 2008
SNDU reordering is not permitted on ULE links, and therefore any
accidental reordering of segments will result in discard.
4.2.7. Type Field
This second type field denotes the type of packet that is
encrypted and encapsulated in the Secure ULE SNDU. If another ULE
extension header follows, then this type field indicates the type
of this extension header.
4.2.8. Encrypted SNDU Payload
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 including DES [12], 3DES etc.
4.2.9. Message Authentication Code (MAC) Field
To provide both data origin authentication and data integrity, a
Message Authentication Code (MAC) is included in the extension
header.
The MAC is calculated over the ULE security extension header and
the encrypted data payload. The receiver calculates the MAC for
the each received packet and compares 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 MUST be
discarded. Hence the same MAC can be used for data origin
authentication and to provide data integrity for
transmission/processing errors.
4.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 PDU. If
Cruickshank et. al. Expires January 13, 2009 [Page 9]
Internet-Draft Security Extension for ULE July 2008
security is needed then an SA must exist in the SAD (this is
set by the key management system). The parameters are
retrieved from the SAD and it 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) is added to the SNDU.
o The ULE-SID for the security association between the
transmitter and the receiver are added next.
o The SAD is consulted to determine if the sequence number has
to be added. If required, then the corresponding sequence
number is added to the SNDU.
o Then the encrypted higher layer PDU is encapsulated to form
the SNDU.
o The SAD is then checked to determine if the data origin
authentication and data integrity has to be provided. If
required, then the MAC has to be calculated. The MAC is
calculated over the encrypted PDU (and other possible
extension headers), the Security extension header and the
secret key. The MAC is then added to the extension header in
the SNDU.
o Finally, the CRC is calculated as defined in Section 4.6 of
RFC4326 [3] and added.
4.4. Receiver Processing
The following procedure is followed at the Receiver for
processing the security extension header for ULE:
o Upon reception of a Secure ULE SNDU, the Receiver first
filters the received packets according to the receiver
destination NPA address (if present).
o The CRC is verified as defined in RFC4326 [3].
o The Receiver then uses the ULE-SID to obtain the security
associations between the transmitter and receiver and retrieve
the data from the SAD. With this the receiver determines if
the sequence number and the MAC are present or not. This is
also used to determine the algorithms and keys used for both
encryption of the encapsulated PDU and for generation of the
message authentication code.
Cruickshank et. al. Expires January 13, 2009 [Page 10]
Internet-Draft Security Extension for ULE July 2008
o If present the next step would be to check the MAC to verify
the authenticity and integrity of the received PDU. If the
calculated MAC does not match the transmitted MAC, then the
PDU is discarded.
o It would then use the sequence number for filtering any out
of-sequence packets.
o Finally the encapsulated payload will be decrypted.
5. 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 [10], 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 [7]). 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.
5.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
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, while for unidirectional
transfers, some other bidirectional connection should be used.
5.2. Alternative Key Management
The method described here for link security may be used with
alternative key management systems when used as a part of a
system that already implements a key management infrastructure
Cruickshank et. al. Expires January 13, 2009 [Page 11]
Internet-Draft Security Extension for ULE July 2008
(e.g. the DVB-RCS security system [6]). The format of the ULE-
Security-ID will be the same format as defined in DVB-RCS
security procedures.
6. Secure ULE SNDU example
This section shows the ULE SNDU with the security extension
header when IP datagrams are secured using Secure ULE. In the
example below, there are no additional extension headers.
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 |
+-+----------------------------+------------------------------+
| Encrypted Receiver Destination NPA Address (48 bits) |
| +------------------------------+
| | ULE_Security_ID |
+------------------------------+------------------------------+
| ULE_Security_ID | Sequence Number (Optional) |
+------------------------------+------------------------------+
| Sequence Number (Optional) | Type = IPv4 |
+------------------------------+------------------------------+
| |
= Encrypted IP Datagram =
| |
+------------------------------+------------------------------+
| |
= Message Authentication Code (Optional) =
| |
+-------------------------------------------------------------+
| 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) |
+------------------------------+------------------------------+
| Type = IPv4 | |
+------------------------------+ |
Cruickshank et. al. Expires January 13, 2009 [Page 12]
Internet-Draft Security Extension for ULE July 2008
| |
= Encrypted IP Datagram =
| |
+------------------------------+------------------------------+
| |
= Message Authentication Code (Optional) =
| |
+-------------------------------------------------------------+
| Cyclic Redundancy Code |
+-------------------------------------------------------------+
Figure 3 Secure ULE SNDU with D=1
7. 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 mandatory link
encryption at the ULE level. The method may also support optional
link level integrity / authentication of the SNDU payload plus
protection against replay attacks. This is provided in a flexible
way using a new ULE Mandatory Extension Header for security. 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.
8. IANA Considerations
The S-ULE header is defined in the IANA maintained Next-Header
Registry for ULE and has the value xxS-ULExx
9. Acknowledgments
The authors acknowledge the help and advice from Gorry Fairhurst
(University of Aberdeen), L. Duquerroy (Alcatel Alenia Space)
Stephane Coombes (ESA) and Yim Fun Hu (University of Bradford) in
the preparation of this document.
10. References
10.1. Normative References
[1] ISO/IEC DIS 13818-1, "Information technology - Generic
codeing of moving pictures and associated audio information
Cruickshank et. al. Expires January 13, 2009 [Page 13]
Internet-Draft Security Extension for ULE July 2008
- 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.
[4] H. Cruickshank, S. Iyengar and P. Pillai, "Security
requirements for the Unidirectional Lightweight
Encapsulation (ULE) protocol", draft-ietf-ipdvb-sec-req-
07.txt, June 17, 2008.
10.2. Informative References
[5] "Digital Video Broadcasting (DVB): DVB Specifications for
Data Broadcasting", ETSI EN 301 192 v1.3.1, 2003.
[6] "Digital Video Broadcasting (DVB): Interaction Channel for
satellite distribution systems", ETSI EN 301 790 v1.4.1,
2005.
[7] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC
4535, June 2006.
[8] S. Kent and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[9] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[10] 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.
[11] http://www.ietf.org/html.charters/tls-charter.html
[12] National Institute of Standards and Technology, "Data
encryption Standard (DES)", Federal Information Processing
Standard (FIPS) Publication, FIPS PUB 46-3, October 1999.
11. Author's Addresses
Cruickshank et. al. Expires January 13, 2009 [Page 14]
Internet-Draft Security Extension for ULE July 2008
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 (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Richmond Road, Bradford BD7 1DP
UK
Email: p.pillai@bradford.ac.uk
Sunil Iyengar
Space & Defence
Logica
Springfield Drive
Leatherhead
Surrey KT22 7LP
UK
Email: sunil.iyengar@logica.com
12. IPR Notices
Copyright (c) The IETF Trust (2008).
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.
Cruickshank et. al. Expires January 13, 2009 [Page 15]
Internet-Draft Security Extension for ULE July 2008
12.2. Intellectual Property
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
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.
13. Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Cruickshank et. al. Expires January 13, 2009 [Page 16]