[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-ietf-ipdvb-sec-req

Internet Engineering Task Force                    H. Cruickshank
Internet Draft                                         S. Iyengar
Document:                                    University of Surrey
draft-cruickshank-ipdvb-sec-req-01.txt
                                                     L. Duquerroy
                                             Alcatel Alenia Space



Category: Internet Draft                               1 May 2006


        Security requirements for the Unidirectional Lightweight
        Encapsulation (ULE) protocol


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/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   Abstract

   This document provides a threat analysis and derives security
   requirements for MPEG-2 transmission links using the Unidirectional
   Lightweight Encapsulation (ULE). It also provides the motivation for
   ULE link level security. This work is intended as a work item of the
   ipdvb WG, and contributions are sought from the IETF on this topic.





Expires November 2006                                    [page 1]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


   Table of Contents

   1. Introduction
   1.1 System Components
   2. Threat Analysis
   3. Security Requirements for IP over MPEG-2 TS
   4. IPsec and MPEG-2 Transmission Networks
   4.1 Tunnel mode use of IPsec for multicast
   4.2 IPsec and L2 security
   5. Motivation for ULE link-layer security
   5.1 Link security below the Encapsulation layer
   5.2 Link security as a part of the Encapsulation layer
   6. Summary
   7. Acknowledgments
   8. Security Considerations
   9. References
   9.1 Normative References
   9.2 Informative References
   10. Authors' Addresses
   11. IPR Notices
   11.1 Intellectual Property Statement
   11.2 Disclaimer of Validity
   12. Copyright Statement
   13. IANA Considerations



























Expires November 2006                                    [page 2]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


1. Introduction

   In the security considerations section of RFC 4259[ipdvb-arch],
   there is an initial analysis of the security requirements in MPEG-2
   transmission networks. For example, when the MPEG-2 transmission
   network is not using a wireline network, the normal security issues
   relating to the use of wireless links for transport of Internet
   traffic should be considered [rfc 3819].  RFC 4259 recommends that
   any new encapsulation defined by the IETF allows Transport Stream
   encryption and also supports optional link level
   encryption/authentication of the SNDU payload.  In ULE [ipdvb-ule],
   this may be provided in a flexible way using Extension Headers.
   This requires definition of a mandatory header extension, but has
   the advantage that it decouples specification of the security
   functions from the encapsulation functions.  This method also
   supports encryption of the NPA/MAC addresses.

   This document extends the above analysis and derives the security
   requirements.

   The main objective of this document is to specify the requirements
   for securing the link between the Encapsulation Gateways (ULE
   source) and Receivers only.  In addition, this document provides an
   overview of the threat analysis for an IP network that utilises ULE
   over an underlying MPEG-2 transmission network.

   The MPEG-2 Transport Stream (TS) has been widely accepted not only
   for providing digital TV services, but also as a subnetwork
   technology for building IP networks. The Unidirectional Lightweight
   Encapsulation (ULE) mechanism described in [ipdvb-ule] for the
   transport of IPv4 and IPv6 Datagrams, bridged Ethernet frames and
   other network protocol packets directly over the ISO MPEG-2 Transport
   Stream as TS Private Data. ULE specifies a base encapsulation format
   and supports an extension format that allows it to carry additional
   header information to assist in network/Receiver processing.

   Important characteristics of MPEG-2 transmission networks are that
   they may provide link-level broadcast capability, and that many
   support applications that require access to a very large number of
   subnetwork nodes [ipdvb-arch]. In addition, the majority of MPEG-2
   transmission networks are bandwidth-limited, encapsulation protocols
   must therefore add minimal overhead to ensure good link efficiency
   while providing adequate network services. They also need to be
   simple to minimize processing, robust to errors and security
   threats, and extensible to a wide range of services.

   In MPEG-2 transmission network there are several signalling messages
   that broadcast by the Network Control Centre (NCC).  Examples of
   these signalling messages or SI tables) are PAT - Program Association
   Table, PMT - Program Map Table and NIT - Network Information Table.

Expires November 2006                                    [page 3]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


   transmission network, these messages are broadcast in clear (no
   encryption or integrity checks).  The integrity of these messages is
   important for the correct working of the ULE network.  However,
   securing these messages is out of scope for ULE security.

   1.1 System Components

   There are several entities within the MPEG-2 transmission network
   architecture, as defined in [ipdvb-arch]). These include (ULE)
   Encapsulation Gateways, TS multiplexers (including re-multiplexers),
   modulators and Receivers.

   The ULE link security focuses on security between the Encapsulation
   Gateways (ULE source) and Receivers only.


2. Threat Analysis

   The simplest type of network threat is a passive threat. Passive
   attacks include eavesdropping or monitoring of transmissions, with a
   goal to obtain information that is being transmitted. In broadcast
   networks (especially those utilising widely available low-cost
   physical layer interfaces, such as DVB) passive threats are
   considered the major threats. An example of such a threat is an
   intruder monitoring the MPEG-2 transmission broadcast and being able
   to extract traffic communicated between IP hosts. Another example an
   intruder trying to gain information about the communication parties
   by monitoring their Layer 2 MAC/NPA addresses; an intruder can gain
   some information by just knowing the identity of the communicating
   parties and the volume of their traffic. This is a well-known issue
   in the security field; however it is more problematic in the case of
   broadcast networks such as MPEG-2 transmission networks.

   Active threats (or attacks) are, in general, more difficult to
   implement successfully than passive threats, and usually require
   more sophisticated resources and may require access to the
   transmitter. Examples of active attacks are:

      - Masquerading: where an entity pretends to be a different
        entity. This includes masquerading other users and subnetwork
        control plane messages
      - Modification of messages in an unauthorised manner.
      - Repudiation: Repudiation of origin occurs when a party denies
        being the originator of a message and repudiation of
        destination occurs when a party denies the reception of a
        message.
      - Replay attacks: When an intruder sends some old (authentic)
        messages to the Receiver.



Expires November 2006                                    [page 4]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


      - Denial of service attacks:  When an entity fails to perform its
        proper function or acts in a way that prevents other entities
        from performing their proper functions.

   Active threats such as replay masquerading, replay, modification of
   messages and injecting IP packet attacks are major security concerns
   for the Internet community and several of these attacks have been
   described [Bellovin].  The defence against such attacks is data
   integrity using cryptographic techniques and sequence numbers.

   In the context of active threats in MPEG-2 transmission networks,
   ULE source authentication (i.e. verification that packets are being
   sent by the expected Encapsulation Gateway) is required by the ULE
   Receivers. Although attacks such as masquerading, modification of
   messages and injecting IP packets are more difficult. However such
   attacks on individual ULE Receivers are possible and can pass
   unnoticed by the ULE network operators or ISPs.  Therefore ULE
   authentication and integrity checks are required. Of course IPsec
   can used for source authentication, further analysis on IPsec is
   presented in section 4.


3. Security Requirements for IP over MPEG-2 TS

   From the above analysis, the following security requirements can be
   derived:

      - Data confidentiality is the major requirement against passive
        threats (using encryption).  L2 encryption or L3 (IPsec)
        encryption can satisfy this requirement.

      - For active threats: ULE source authentication and data
        integrity are required, using techniques such as message
        authentication code and digital signatures.  Sequence numbers
        are required to stop replay attacks.  Therefore, L2 data
        integrity/authentication is optional, but still important in
        environments in which several independent networks share a
        single transmission resource.  In addition, functions to
        determine the integrity of control and management messages in
        MPEG-2 transmission networks such as SI tables are another
        optional requirement, but are outside the scope of ULE
        security.

      - Optional hiding of Layer 2 MAC/NPA address.  This is needed
        particularly in the MPEG-2 broadcast networks to stop an
        intruder gaining information by observing the identity of the
        communicating parties and the volume of their traffic.
             - Layer L2 terminal authentication. This will be part of
        the key management. It will be performed during the initial
        key exchange and authentication phase.




Expires November 2006                                    [page 5]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


      - End-to-end security (such as IPsec and TLS) and ULE link
        security should work in parallel without obstructing each
        other.

      - Decoupling of ULE key management functions from ULE encryption.
        This will allow the independent definition of these systems
        such as the re-use of existing security management systems (
        e.g. GSAKMP [msec-gsakmp] and GDOI [msec-gdoi]), if there is a
        IP infrastructure, or other systems such as DVB-RCS [etsi-
        dvbrcs] and/or the development of new systems, as required.

      - Other general requirements are:

        * Operational issues: Because of the possible large coverage of
        a broadcast transmission network, it may be required to deliver
        data to many different countries that may have different
        security legislation (related to authorized encryption
        algorithms and the length of keys). Therefore the ULE security
        system should allow a wide range of security parameters during
        the negotiation phase in order to offer flexibility to
        operators.  In ULE security, the choice of such algorithms will
        be decided by the key management system in use.

        * Compatibility with other networking functions: Other
        networking functions such as NAT (Network Address Translation)
        [rfc 3715] or TCP acceleration can be used in a wireless DVB
        networks. The ULE security solution should be compatible with
        functions such as NAT/NAPT, IPsec, TLS, etc.

        * Traceability (such as using intrusion detection systems): To
        monitor transmission network (e.g. using log files to record
        the activities on the network).  This is out of scope for ULE
        security.


4. IPsec and MPEG-2 Transmission Networks

   IPsec supports two modes of use: transport mode and tunnel mode. In
   transport mode, AH and ESP provide protection primarily for next
   layer protocols; in tunnel mode, AH and ESP are applied to tunnelled
   IP packets. In both modes, data integrity is provided and in
   addition, ESP provides the data privacy service as well.




Expires November 2006                                    [page 6]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


   It is possible to use IPsec to secure ULE links.  The major
   advantage of IPsec is its wide implementation in IP routers and
   hosts. The Security Architecture for the Internet Protocol [rfc 4301]
   describes security services for traffic at the IP layer. That
   architecture primarily defines services for Internet Protocol (IP)
   unicast packets, as well as manually configured IP multicast
   packets.

   However IPsec is not well-suited to protect the identity of the ULE
   encapsulator/Receivers to provide this.  The interfaces of these
   devices also do not necessarily have IP addresses (they can be L2
   devices).

   In addition, IP Multicast is considered as a major service over
   MPEG-2 Transmission Networks. A document produced by the IETF msec
   Working Group on IPsec extensions for multicast [msec-ipsec-ext]
   describes extensions to [rfc 4301] that further define the IPsec
   security architecture for packets that carry a multicast address in
   the IP destination field, allowing these to remain IP multicast
   packets.

   4.1 Tunnel mode use of IPsec for multicast

   In the context of MPEG-2 transmission links, if IPsec is used to
   secure a ULE link, then the ULE gateways and Receivers are
   equivalent to the security gateways in IPsec terminology. A security
   gateway implementation of IPsec using the multicast extensions MUST
   use tunnel mode. In particular, the security gateway must use the
   tunnel mode to encapsulate incoming fragments.

   With IPsec tunnel mode, there are two challenges: First, if the
   destination of an IP multicast packet is changed it will no longer
   be properly routed.  Secondly, IP multicast routing protocols also
   typically create multicast distribution trees based on the source
   address. An IPsec security gateway that changes the source address
   of an IP multicast packet, again this will cause multicast routing
   problems. The [msec-ipsec-ext] document defines a way for retaining
   both the IP source and destination addresses of the inner IP header
   to allow IP multicast routing protocols to route the packet
   irrespective of the packet being IPsec protected. This
   interpretation of tunnel mode is known as tunnel mode with address
   preservation.

   4.2 IPsec and L2 security

   IPsec in transport mode can be used for end-to-end security
   transparently of MPEG-2 transmission links with no impact.

   However, if IPsec is used to secure ULE links, then it must be used
   in tunnel mode. Such usage has the following disadvantages:

Expires November 2006                                    [page 7]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006



      - There is a need to protect the identity of ULE
        encapsulator/Receivers over the ULE broadcast medium; IPsec is
        not suitable for providing this service.

      - There is an extra overheads associated with using IPsec in
        tunnel mode, i.e. the extra IP header (IPv4 or IPv6).

      - Multicast is considered as a major service over ULE links. The
        current IPsec specifications [rfc 4301] only define a pairwise
        tunnel between two IPsec devices with manual keying. Work in
        progress [msec-ipsec-ext] is defining the extra detail needed
        for multicast and to use the tunnel mode with address
        preservation as described in section 4.1.

   In the ULE link context, in addition to the IPsec tunnelling
   overhead, the source and destination address preservation means that
   these IP addresses are broadcast in the clear.  This provides an
   opportunity to intercept the traffic information (weakening the
   ability to provide the identity hiding).  However [msec-ipsec-ext]
   mentions the possibility that multicast data is sent through a
   service provider network, and is encapsulated under a different IP
   multicast address while in the provider network. The source address
   of the encapsulating (outside) IP header could be changed to that of
   the ULE gateway.


5. Motivation for ULE link-layer security

   Examination of the threat analysis and security requirements in
   sections 2 and 3 has shown that there is a need to provide link-
   layer (L2) security in MPEG-2 transmission networks employing ULE,
   particularly when network-layer and transport-layer security (e.g.
   IPsec, TLS) are insufficient.

   ULE link security is therefore considered an additional security
   mechanism to IP, transport, and application layer security, not a
   replacement. It should provide similar functions to that of IPsec
   [IPsec], but in addition provides link confidentiality and Receiver
   identity hiding.

   End-to-end security, IPsec and ULE link security should work in
   parallel:  IPsec providing the end-to-end security between hosts and
   ULE providing the security over the MPEG-2 transmission link.
   However, no direct interaction between the IPsec and the ULE
   security system is envisaged.

   A modular design to ULE Security may allow it to use and benefit
   from IETF key management protocols, such as the MSEC [msec-gsakmp]


Expires November 2006                                    [page 8]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


   and GDOI [msec-gdoi, rfc 3547]. This does not preclude the use of
   other key management methods in scenarios that benefit from this.

   5.1 Link security below the Encapsulation layer

   Link layer security can be provided in the MPEG-TS level (below
   ULE). MPEG-TS encryption encrypts all TS Packets sent with a
   specific PID value. However MPEG-TS may multiplex several IP streams
   using a common PID. Therefore all multiplexed traffic will share the
   same security keys.

   This has the following advantages:

      - The bit stream sent on the broadcast network does not expose
        any L2 or L3 headers, specifically all addresses, type fields,
        and length fields are encrypted prior to transmission.

      - This method does not preclude the use of IPsec, or any other
        form of higher-layer security.

      However it has the following disadvantages:

      - Each ULE Receiver needs to decrypt all MPEG-2 TS Packets with a
        matching PID, possibly including those that are not required to
        be forwarded.

      - ULE Receivers will be able to see the private traffic destined
        to other ULE Receivers, since they share a common key.

      - If the key is compromised, then this will impact several ULE
        Receivers. Existing access control mechanisms have limited
        flexibility in terms of controlling the use of key and
        rekeying.  IETF based key management are not used in existing
        systems.

   5.2 Link security as a part of the Encapsulation layer

   Therefore major advantages for ULE link security are:

      - The protection of the complete ULE Protocol Data Unit (PDU)
        including IP addresses.

      - Ability to protect the identity of the Receiver within the
        MPEG-2 transmission network.

      - Efficient protection of IP multicast over ULE links.

      - Transparency to the use of Network Address Translation (NATs)
        [rfc 3715] and TCP Performance Enhancing Proxies (PEP)


Expires November 2006                                    [page 9]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


        [rfc 3135], which require the ability to inspect and modify the
        packets sent over the ULE link.

      - This method does not preclude the use of IPsec. IPsec also
        provides a proven security architecture defining key exchange
        mechanisms and the ability to use a range of cryptographic
        algorithms. ULE security can make use of these mechanisms and
        algorithms.

   In some current encapsulation methods, e.g. MPE [etsi-dat],
   encryption of the MAC address requires each Receiver to decrypt all
   encrypted data sent using a TS Logical Channel (PID), before it can
   then filter the PDUs that match the set of MAC/NPA addresses that
   the Receiver wishes to receive, therefore encryption of the MPE MAC
   address is not permitted in such systems. For ULE security, an
   optional support for Layer 2 MAC/NPA address hiding should be
   provided.

   Examining the threat analysis in section 2, has shown that
   protection of ULE link from eavesdropping and ULE Receiver identity
   hiding are major requirements. Such requirements can be met using
   ULE link encryption.

   In the context of active threats in MPEG-2 transmission networks,
   ULE source authentication is required by the ULE Receivers. Attacks
   such as masquerading, modification of messages and injecting IP
   packets are more difficult. However, such attacks on individual ULE
   Receivers are possible, and can pass unnoticed by the ULE network
   operators or ISPs. Therefore using HMACs is one possibility which
   has associated overheads per ULE packets.  Another possibility is to
   use lightweight data integrity methods or procedures that can be
   provided by the ULE security system.  In addition sequence numbers
   can provide protection against replay attacks.


6. Summary

   This document analyses a set of threats and security requirements.
   It also defines the requirements for ULE security and states the
   motivation for Link security as a part of the Encapsulation layer.
   In summary, there is a need for L2 encryption, ULE Receiver identity
   hiding, L2 source authentications and protection against insertion
   of other data into the ULE stream.


7. Acknowledgments

   The authors acknowledge the help and advice from Gorry Fairhurst
   (University of Aberdeen) in the preparation of this draft.


Expires November 2006                                    [page 10]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006

8. 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 wired links. An ISP or
   User may also wish to provide end-to-end security services to the
   end-users (based on the well known mechanisms such as IPsec).

   This document provides a threat analysis and derives the security
   requirements to provide optional link encryption and link-level
   integrity / authentication of the SNDU payload.


9. References

   9.1 Normative References

        [etsi-dat] EN 301 192, "Digital Video Broadcasting (DVB); DVB
        Specifications for Data Broadcasting", European
        Telecommunications Standards Institute (ETSI).

        [rfc 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

        [ipdvb-ule] Fairhurst, G., Collini-Nocker, "Ultra Lightweight
        Encapsulation (ULE) for transmission of IP datagrams over an
        MPEG-2 Transport Stream", <draft-ietf-ule-06.txt>, IETF Work
        in Progress.
        [ipdvb-arch] M.J. Montpetit ed., et al, "Framework for
        transmission of IP datagrams over MPEG-2 Networks", <draft-
        ietf-ipdvb-arch-04.txt>, IETF Work in Progress.

   9.2 Informative References

        [Bellovin] Bellovin, S., "Problem Area for the IP Security
        Protocols", Computer Communications Review 2:19, pp. 32-48,
        April 989. http://www.cs.columbia.edu/~smb/

        [etsi-dvbrcs] "Digital Video Broadcasting (DVB) -- interaction
        channel for satellite distribution systems", ETSI EN 301 790
        V1.4.1 (2005-04)

        [IPsec] http://www.ietf.org/html.charters/wg-
        dir.html#Security%20Area. RFCs 2401, 2402 and 2406

        [msec] http://www.ietf.org/html.charters/msec-charter.html

        [msec-gsakmp] H Harney (SPARTA), et al, "GSAKMP: Group Secure
        Association Group Management Protocol", <draft-ietf-msec-
        gsakmp-sec-10.txt>, IETF Work in Progress.

        [msec-gdoi], RFC 3547] M. Baugher, et al, "GDOI: The Group
        Domain of Interpretation", RFC 3547.

Expires November 2006                                    [page 11]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006

        [msec-ipsec-ext] Weis B., et al, "Multicast Extensions to the
        Security Architecture for the Internet", <draft-ietf-msec-
        ipsec-extensions-01.txt>, IETF Work in Progress.

        [nat, rfc 3715] B. Aboba and W Dixson, "IPsec-Network Address
        Translation (NAT) Compatibility Requirements"

        [tls] http://www.ietf.org/html.charters/tls-charter.html

        [rfc 3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and
        Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate
        Link-Related Degradations", RFC 3135, June 2001.

        [rfc 2401] Kent, S., et al, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

        [rfc 4301] Kent, S. and Seo K., "Security Architecture for the
        Internet Protocol", RFC 4301, December 2006.

        [rfc 3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
        Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
        Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC
        3819, July 2004.


10. Authors' Addresses

   Haitham Cruickshank
   Centre for Communications System Research (CCSR)
   University of Surrey
   Guildford, Surrey, GU2 7XH
   UK
   Email: h.cruickshank@surrey.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








Expires November 2006                                     [page 12]


INTERNET DRAFT  Encapsulation for IP over MPEG-2/DVB     May 2006


   11. IPR Notices

   11.1 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
   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.

   11.2 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.


12. 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.


13. IANA Considerations

   This document does not define any protocol and does not require any
   IANA assignments.




Expires November 2006                                     [page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/