Network Working Group                                          V. Manral
Internet-Draft                                                       IPI
Expires: August 20, 2006                                        S. Hares
                                                                 NextHop
                                                                R. White
                                                           Cisco Systems
                                                       February 20, 2006


   Issues with existing Cryptographic Protection Methods for Routing
                               Protocols
                   draft-manral-rpsec-existing-crypto-02

Status of this Memo

   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 July 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Routing protocols often use cryptographic mechanisms to authenticate
   data being received from a neighboring router has not been modified
   in transit, and actually originated from the nrighboring router
   purporting to have originating the data.  Most of the cryptographic



Manral, et al.         Expires August 20, 2006                  [Page 1]


Internet-Draft     Routing Protocol Protection Issues       August 2006


   mechanisms rely on hash algorithms applied to the data in the routing
   protocol packet, which means the data is transported, in the clear,
   along with the has signature based on the data itself.  These
   mechanisms rely on the manual configuration of the keys used to seed,
   or build, these hash based sigantures.  This document outlines some
   of the problems with manual keying of these cryptographic algorithms.

Requirements Language

   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 RFC 2119 [RFC2119].

Table of Contents

   1.   Problem Statement  . . . . . . . . . . . . . . . . . . . . .   3

   2.   OSPF (OSPFv2)  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1  Management Issues with OSPF  . . . . . . . . . . . . . . .   4
     2.2  Technical Issues with OSPF . . . . . . . . . . . . . . . .   4

   3.   OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Management Issues with OSPFv3  . . . . . . . . . . . . . .   6
     3.2  Technical Issues with OSPFv3 . . . . . . . . . . . . . . .   6

   4.   IS-IS  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1  Management Issues with IS-IS . . . . . . . . . . . . . . .   8
     4.2  Technical Issues with IS-IS  . . . . . . . . . . . . . . .   8

   5.   BGP  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1  Management Issues with BGP . . . . . . . . . . . . . . . .  10
     5.2  Technical Issues with BGP  . . . . . . . . . . . . . . . .  10

   6.   The Routing Information Protocol (RIP) . . . . . . . . . . .  12

   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13

   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  14

   9.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  15

   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1   Normative References . . . . . . . . . . . . . . . . . .  16
     10.2   Informative References . . . . . . . . . . . . . . . . .  17

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17

        Intellectual Property and Copyright Statements . . . . . . .  18



Manral, et al.         Expires August 20, 2006                  [Page 2]


Internet-Draft     Routing Protocol Protection Issues          August 2006


1.  Problem Statement

   Routing protocols, such as OSPF [RFC2740] [RFC2328], IS-IS [RFC1995],
   and [BGP], rely on various mechanisms to create a cryptographic
   digest of each transmitted routing protocol.  Generally, these
   digests are the results of a hash algorithm, such as [MD5], across
   the contents of the packet being transmitted, using a private key as
   the hash base (or seed).  These digests are recomputed by the
   receiving router, using the same key as the originating router used
   to create the hash, and compared with the transmited digest to
   verify:

   o  That the router originating this piece of data is authorized to
      peer with the local router, and to transmit routing data.  This
      generally protects against falsely generated routing data being
      injected into a routing system by rogue systems.

   o  That the data has not been changed while transiting between the
      two neighboring routers.

   These sorts of authentication methods are not generally used to
   protect the confidentiality of information being exchanged between
   routers, since this information (entries in the routing table) is
   generally freely available in many other context; if anyone has
   access to the physical media between two routers exchanging routing
   data, they will also probably have other ways to capture or otherwise
   discover the contents of the routing tables in those routers.

   The main problems with the authentication mechanisms in use today
   revolve around:

   o  Manual configuration of shared secret keys, especially in large
      scale networks, poses a major management problem, especially as
      there is generally no way to gracefully move from one secret key
      to another.

   o  In some cases, when manual keys are configured, some forms of
      replay protection are disabled, allowing the routing protocol to
      be attacked.

   In fact, the MD5 digest algorithm was not designed to be used in the
   way most routing protocols are using it, which leads to serious
   security implications.








Manral, et al.         Expires August 20, 2006                  [Page 3]


Internet-Draft     Routing Protocol Protection Issues       August 2006


2.  OSPF (OSPFv2)

   OSPF [RFC2328] describes the use of an MD5 digest with OSPF packets.
   MD5 keys are manually configured.  The OSPF packet Header includes an
   authentication type field as well as 64-bits of data for use by the
   appropriate authentication scheme.  [OSPF] also provides for a non-
   decreasing sequence number to be included in each OSPF protocol
   packet to protect against replay attacks.

2.1  Management Issues with OSPF

   According to the OSPF specification, [RFC2328], digests are applied
   to packets transmitted between adjacent neighbors, rather than being
   applied to the routing information originated by a router (digests
   are not applied at the LSA level, but rather at the packet level).
   [RFC2328] states that any set of OSPF routers adjacent across a
   single link may use a different key to build MD5 digests than the key
   used to build MD5 digests on any other link.  Thus, MD5 keys may be
   configured, and changed, on a per-link basis in an OSPF network.

   [OSPF] does not specify a mechanims to negotiate keys, nor does it
   specify any mechanism to negotiate the hash algorithms to be used.

   With the proliferation of the number of hash algorithms, as well as
   the need to continuously upgrade the algorithms, manually configuring
   the information becomes very tedious.

2.2  Technical Issues with OSPF

   While [OSPF] provides relatively strong protection through the
   inclusion of MD5 sigantures, with additional data and sequence
   numbers, in transmitted packets, there are still two possible attacks
   against OSPF:

   o  The sequence number is initialized to zero when forming an
      adjacency with a newly discovered neighbor, and is also set to
      zero whenever the neighbor is brought down.  If the
      cryptographically protected packets of a router that is brought
      down(for administrative or other reasons) are stored by a
      malicious router.  The new router could replay the packets from
      the previous session thus forcing traffic through the malicious
      router.  Dropping of such packets by the router could result in
      blackholes.  Also wrongly forwarding packets could result in
      routing loops.

   o  [OSPF] allows multiple packets with the same sequence number.
      This could mean the same packet can be replayed many times before
      the next legitimate packet is sent.  An attacker may resend the
      same packet repeatedly until the next hello packet is transmitted




Manral, et al.         Expires August 20, 2006                  [Page 4]


Internet-Draft     Routing Protocol Protection Issues       August 2006


      and received, which means the hello interval determines the attack
      window.

   o  [OSPF] does not specify the use of any particular hash algorithm,
      however the use of only MD5 is specified in the document. Most OSPF
      implementations only support MD5.

      Recently, attacks on collision-resistance properties of MD5 and SHA-1
      hash functions have been discovered; [HASH-ATTACK] summarizes the
      discoveries. The attacks on MD5 are practical on any mordern computer.
      For this reason the use of algorithms needs to be discouraged.

   o  [OSPF] on a broadcast network shares the same key between all neighbors
      on a broadcast network. Some OSPF packets are sent on multicast address.

      This allows spoofing by any malicious neighbor very easy. Possesion of
      the key itself is used as an identity check. There is no other identity
      check used. A neighbor could send a packet specifying the packet came
      from some other neighbor and there would be no way in which the attacked
      router could figure out the identity of the packet sender.
































Manral, et al.         Expires August 20, 2006                  [Page 5]


Internet-Draft     Routing Protocol Protection Issues       August 2006


3.  OSPFv3

   OSPFv3 [RFC2740] relies on the IP Authentication Header described in
   [AH] and the IP Encapsulating Payload described in [ESP] to
   cryptographically sign routing information passed between routers.
   When using ESP, a null encryption algorithm is used, so the data carried
   in the OSPFv3 packets is signed, but not encrypted.  This provides data
   origin  authentication for adjacent routers, and data integrity which gives
   the assurance data transmitted by a router has not changed in transit.
   However it does not provide confidentiality of the information transmitted.
   [OSPF-AUTH] mandates the use of ESP w/ null encryption for authentication
   and also does encourages the use of confidentiality to protect the privacy of
   the routing information transmitted, using [ESP] encryption.

   [OSPF-AUTH] describes OSPFv3's use of [AH] and [ESH], and specifies
   that only manual keying of routing information may be used.

3.1  Management Issues with OSPFv3

   [OSPF-AUTH] discusses, at length, the reasoning behind using manually
   configured keys, rather than some automated key management protocol
   such as [IKE] .  The primary problem is that all current key
   management mechanisms are deisgned for one-to-one correlation of
   keys, while OSPF adjacencies are formed on a one-to-many basis.  This
   forces the system administrator to use manually configured SAs and
   cryptographic  keys to provide the authentication and, if desired,
   confidentiality services.

   OSPFv3 security document [OSPF-AUTH] states that

      As it is not possible as per the current standards to provide
      complete replay protection while using manual keying, the proposed
      solution will not provide protection against replay attacks.

   The primary administrative issue with manually configured SA's and keys
   in the OSPFv3 case is the simple management issue of mantaining
   matching sets of keys on all routers within a network.  [OSPF-AUTH] does
   not require that all OSPFv3 routers have the same key configured for every
   neighbor, so  each set of neighbors connected to a single link could have a
   different key configured.  While this makes it easier to change the keys, by
   forcing the system administrator to only change the keys on the routers on
   a  single link, the process of manual configuration for all the routers in a
   network to change the keys used for OSPFv3 digests and confidentiality on
   a periodic basis can be difficult.







Manral, et al.         Expires August 20, 2006                  [Page 6]


Internet-Draft     Routing Protocol Protection Issues       August 2006

3.2  Technical Issues with OSPFv3

   The primary technical concern with the current specifications for
   OSPFv3 is that when manual SA and key management is used, [AH] specifies,
   in section 3.3.2, Sequence Number Generation: "The sender assumes
   anti-replay is enabled as a default, unless otherwise notified by the receiver
   (see 3.4.3) or if the SA was configured using manual key management."
   Replayed OSPFv3 packets can cause several failures in a network,
   including:

   o  Replaying hello packets with an empty neighbor list can cause all
      the neighbor adajcencies with the sending router to be reset,
      disrupting network communications.

   o  Replaying hello packets from early in the designated router
      election process on broadcast links can cause all the neighbor
      adjacencies with the sending router to be reset, disrupting
      network communications.

   o  Replaying database description (DB-Description) packets can cause
      all FULL neighbor adjacencies with the sending router to be reset,
      disrupting network communications.

   o  Replaying link state request (LS-Request) packets can cause all
      FULL neighbor adjacencies with the sending router to be reset,
      disrupting network communications.

   o  Capturing a full adjacency process (from two-way all the way to
      FULL state), and then replaying this process when the router is no
      longer attached can cause a false adjacency to be formed, allowing
      an attacker to attract and black hole traffic.

   o  [OSPFv3] on a broadcast network shares the same key between all
      neighbors on a broadcast network. Some OSPF packets are sent on
      multicast address.

      This allows spoofing by any malicious neighbor very easy. Possesion
      of the key itself is used as an identity check. There is no other
      identity check used. A neighbor could send a packet specifying the
      packet came from some other neighbor and there would be no way in
      which the attacked router could figure out the identity of the packet
      sender.








Manral, et al.         Expires August 20, 2006                  [Page 7]


Internet-Draft     Routing Protocol Protection Issues       August 2006


4.  IS-IS

   IS-IS [RFC1195] uses HMAC-MD5 authentication with manual keying, as
   described in [RFC3567].  There is no provision within IS-IS to
   encrypt the body of a routing protocol message.

4.1  Management Issues with IS-IS

   [RFC3567] states that each LSP generated by an intermediate system is
   signed with the HMAC-MD5 algorithm using a key manually defined by
   the network administrator.  Since authentication is performed on the
   LSPs transmitted by an intermediate system, rather than on the
   packets transmitted to a specific neighbor, it is implied that all
   the intermediate systems within a single flooding domain must be
   configured with the same key for authentication to work correctly.
   The initial configuration of manual keys for authentication within an
   IS-IS network is simplified by a state where LSPs containing HMAC-MD5
   authentication TLVs are accepted, but the digest is not validated.
   Once an initial set of keys are configured on all routers, however,
   changing those keys becomes much more difficult.

   IS-IS [RFC1195] does not specify a mechanims to negotiate keys, nor does
   it specify any mechanism to negotiate the hash algorithms to be used.

   With the proliferation of the number of hash algorithms, as well as
   the need to continuously upgrade the algorithms, manually configuring
   the information becomes very tedious.

4.2  Technical Issues with IS-IS

   [RFC3567] states: "This mechanism does not prevent replay attacks,
   however, in most cases, such attacks would trigger existing
   mechanisms in the IS-IS protocol that would effectively reject old
   information."  The few case where existing mechanisms in the IS-IS
   protocol would not effectively reject old information is the case of
   the hello packets (IIHs) used to discover neighbors and SNP packets.

   As described in IS-IS [RFC1195], a list of known neighbors is
   included in each hello transmitted by an intermediate system, to
   ensure two-way communications with any specific neighbor before
   exchanging link state databases.

   IS-IS does not provide a sequence number. Hence IS-IS packets are
   liable to replay attacks. As any packet can be replayed at any point
   of time, as long as the keys used are the same.

   A hello packet containing a digest within a TLV, and an emtpy





Manral, et al.         Expires August 20, 2006                  [Page 8]


Internet-Draft     Routing Protocol Protection Issues          August 2006




   neighbor list, could be replayed, causing all adjacencies with the
   original transmitting intermediate system to be restarted.

   A replay of an old CSNP packets could cause LSP's to be flooded, thus
   causing an LSP storm.

   IS-IS specifies the use of the hash algorithm HMAC-MD5 to protect
   IS-IS PDU's.

   IS-IS does not have a notion of Key ID. During Key rollover, each
   message received has to be checked for integrity against all keys that
   are valid. A DoS attack may be caused by sending IS-IS packets with
   random hashes. This will cause the IS-IS packet to be checked for
   authentication, with all possible keys. Thus increasing the amount of
   processing required.

   Recently, attacks on collision-resistance properties of MD5 and SHA-1
   hash functions have been discovered; [HASH-ATTACK] summarizes the
   discoveries. The attacks on MD5 are practical on any mordern computer.
   For this reason the use of algorithms needs to be discouraged.

   HMAC's are not susceptible to any known collision-reduction attack.
   However IS-IS should provide a way to upgrade to other stronger
   algorithms.

   IS-IS on a broadcast network shares the same key between all neighbors
   on a broadcast network. Some IS-IS PDU's are sent on link-layer multicast
   address.

   This makes spoofing by any malicious neighbor very easy. Possession of
   the key itself is used as an identity check. There is no other identity
   check used. A neighbor could send a packet specifying the packet came
   from some other neighbor and there would be no way in which the attacked
   router could figure out the identity of the packet sender.

















Manral, et al.         Expires August 20, 2006                  [Page 9]


Internet-Draft     Routing Protocol Protection Issues       August 2006


5.  BGP

   [BGP] uses TCP [RFC793] for transporting routing information between
   BGP speakers which have formed an adjacency, as described in
   [RFC2385], with suggestions for choosing MD5 keys described in
   [RFC3562].

   It is common to use the TCP MD5 signature optionas described in
   [RFC2385] for providing data origin authentication and data integrity
   protection of these BGP packets. with suggestions for choosing MD5 key
   length described in [RFC3562]. There is no provision for confidentiality for
   any of these BGP messages.

   This problem is made worse by the nature of the environment where BGP is
   typically used, between autonomous networks (under different
   administrative control). While routers running interior gateway protocols
   may all be configured using the same keys, and have their key rollover
   policies coordinated or set by the same administrative authority, two BGP
   peering BGP speakers may be in different administrative domains, with
   different policies for key strength, rollover times, etc. An autonomous
   system must often support a large number of keys on different BGP borders,
   since each connecting AS represents a different administrative entity.

5.1  Management Issues with BGP

   Each pair of BGP speakers forming an adjacency may have a different
   MD5 shared key, facilitating the configuration and changing of keys
   across a large scale network.  Manual configuration and maintenance
   of cryptographic keys on all routers is a challenge in any large scale
   environment, however.  Most BGP implementations will accept BGP
   packets with a bad digest for the hold interval negotiated between
   BGP peers at peering startup, allowing MD5 keys to be changed without
   impacting the operation of the network.  This technique does,
   however, allow some short period of time during which an attacker may
   inject BGP packets with false MD5 digests into the network, and can
   expect those packets to be accepted, even though their MD5 digests
   are not valid.

5.2  Technical Issues with BGP

   Since BGP relies on TCP [RFC793] for transporting data between BGP
   speakers, BGP can rely on TCP's protections against data corruption
   and replay to prevent replay attacks against BGP sessions.  A great
   deal of research has gone into the difficulty or ease with which an
   attacker can overcome these protections, including [TCP-WINDOW] and
   [BGP-ATTACK].  Most implementations of BGP have modified their TCP
   implementations to resolve the security vulnerabilities described in
   these references, where possible.



Manral, et al.         Expires August 20, 2006                  [Page 10]


Internet-Draft     Routing Protocol Protection Issues       August 2006


   However, as mentioned earilier, MD5 is vulnerable to collision attacks, and
   can be attacked through several means, such as those explored in [MD5-ATTACK].
   Though it is can be argued that the collision attacks do not have a practical
   implication in this scenario, the use of MD5 is discouraged.

   Routers performing cryptographic processing of packets in software may
   be easier to attack. An attacker may be able to transmit enough traffic
   with false digests to a router that the router's processor and memory
   resources are consumed, causing the router to be unable to perform normal
   processing. This is particularly problematic at connections to devices
   not under local administrative control.










































Manral, et al.         Expires August 20, 2006                  [Page 11]


Internet-Draft     Routing Protocol Protection Issues       August 2006


6.  The Routing Information Protocol (RIP)

   RIP [RFC1058] does not provide for any authentication or
   authorization of routing data, and thus is vulnerable to any of the
   various attacks against routing protocols.

   RIPv2 [RFC1388, RFC1723] provides for authenticating packets by
   carrying a digest, but has no counter for replay protection.  Packets
   can be replayed at will, allowing the injection of false routing
   information and various denial of service attacks, such as
   continuously requesting a routing table download, causing devices
   running RIP to become overloaded.







































Manral, et al.         Expires August 20, 2006                  [Page 12]


Internet-Draft     Routing Protocol Protection Issues       August 2006


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.













































Manral, et al.         Expires August 20, 2006                 [Page 13]


Internet-Draft     Routing Protocol Protection Issues       August 2006


8.  Security Considerations

   This draft outlines security issues arising from the manual keying of
   cryptographic keys for various routing protocols.  No changes to any
   protocols are proposed in this draft, and no new security
   requirements result.













































Manral, et al.         Expires August 20, 2006                 [Page 14]


Internet-Draft     Routing Protocol Protection Issues       August 2006


9.  Acknowledgements

   We would like to acknowledge Sam Hartman, Ran Atkinson, Steve Kent
   and Brian Wies for their initial comments on this draft. Thanks to
   Manav Bhatia for comments on IS-IS section of the draft. Merike Kaeo
   reviewed many sections of the draft and gave a lot of useful comments.













































Manral, et al.         Expires August 20, 2006                 [Page 15]


Internet-Draft     Routing Protocol Protection Issues       August 2006


10.  References

10.1  Normative References

   [AH]       Kent, S., "IP Authentication Header",
              RFC draft-ietf-ipsec-rfc2402bis-11.txt, March 2005.

   [BGP]      Rekhter , Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC draft-ietf-idr-bgp4-26.txt,
              October 2004.

   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC draft-ietf-ipsec-esp-v3-10.txt, March 2005.

   [OSPF-AUTH]
              Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC draft-ietf-ospf-ospfv3-auth-07.txt,
              February 2005.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1058]  Hedrick, C., "Routing Information Protocol", RFC 1058,
              June 1988.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC1388]  Malkin, G., "RIP Version 2 Carrying Additional
              Information", RFC 1388, January 1993.

   [RFC1723]  Malkin, G., "RIP Version 2 - Carrying Additional
              Information", STD 56, RFC 1723, November 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.

   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
              Signature Option", RFC 3562, July 2003.




Manral, et al.         Expires August 20, 2006                 [Page 16]


Internet-Draft     Routing Protocol Protection Issues       August 2006


   [RFC3567]  Li, T. and R. Atkinson, "Intermediate System to
              Intermediate System (IS-IS) Cryptographic Authentication",
              RFC 3567, July 2003.

10.2  Informative References

   [BGP-ATTACK] Convery, S. and M. Franz, "BGP Vulnerability Testing:
              Separating Fact from FUD v1.00", June 2003.

   [TCP-WINDOW] Watson, T., "TCP Reset Spoofing", October 2003.

   [HASH-ATTACK] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC4270, November 2005.


Authors' Addresses

   Vishwas Manral
   IPI
   Bangalore
   India

   Phone:
   Fax:
   Email: vishwas.manral@gmail.com


   Sure Hares
   NextHop
   USA

   Phone:
   Fax:
   Email: shares@nexthop.com
   URI:


   Russ White
   Cisco Systems
   RTP, NC
   USA

   Phone:
   Fax:
   Email: riw@cisco.com
   URI:



Manral, et al.         Expires August 20, 2006                 [Page 17]


Internet-Draft     Routing Protocol Protection Issues       August 2006


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.


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 (2005).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Manral, et al.         Expires August 20, 2006                 [Page 18]