doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc4552.txt b/doc/rfc/rfc4552.txt
new file mode 100644
index 0000000..b90cc14
--- /dev/null
+++ b/doc/rfc/rfc4552.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           M. Gupta
+Request for Comments: 4552                               Tropos Networks
+Category: Standards Track                                       N. Melam
+                                                        Juniper Networks
+                                                               June 2006
+
+
+               Authentication/Confidentiality for OSPFv3
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes means and mechanisms to provide
+   authentication/confidentiality to OSPFv3 using an IPv6 Authentication
+   Header/Encapsulating Security Payload (AH/ESP) extension header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 1]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................2
+   2. Transport Mode vs. Tunnel Mode ..................................3
+   3. Authentication ..................................................3
+   4. Confidentiality .................................................3
+   5. Distinguishing OSPFv3 from OSPFv2 ...............................4
+   6. IPsec Requirements ..............................................4
+   7. Key Management ..................................................5
+   8. SA Granularity and Selectors ....................................7
+   9. Virtual Links ...................................................8
+   10. Rekeying .......................................................9
+      10.1. Rekeying Procedure ........................................9
+      10.2. KeyRolloverInterval .......................................9
+      10.3. Rekeying Interval ........................................10
+   11. IPsec Protection Barrier and SPD ..............................10
+   12. Entropy of Manual Keys ........................................12
+   13. Replay Protection .............................................12
+   14. Security Considerations .......................................12
+   15. References ....................................................13
+      15.1. Normative References .....................................13
+      15.2. Informative References ...................................13
+
+1.  Introduction
+
+   OSPF (Open Shortest Path First) Version 2 [N1] defines the fields
+   AuType and Authentication in its protocol header to provide security.
+   In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields
+   were removed from OSPF headers.  OSPFv3 relies on the IPv6
+   Authentication Header (AH) and IPv6 Encapsulating Security Payload
+   (ESP) to provide integrity, authentication, and/or confidentiality.
+
+   This document describes how IPv6 AH/ESP extension headers can be used
+   to provide authentication/confidentiality to OSPFv3.
+
+   It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
+   ESP [N4], the concept of security associations, tunnel and transport
+   mode of IPsec, and the key management options available for AH and
+   ESP (manual keying [N3] and Internet Key Exchange (IKE)[I1]).
+
+1.1.  Conventions Used in This Document
+
+   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 [N7].
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 2]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+2.  Transport Mode vs. Tunnel Mode
+
+   The transport mode Security Association (SA) is generally used
+   between two hosts or routers/gateways when they are acting as hosts.
+   The SA must be a tunnel mode SA if either end of the security
+   association is a router/gateway.  Two hosts MAY establish a tunnel
+   mode SA between themselves.  OSPFv3 packets are exchanged between
+   routers.  However, since the packets are locally delivered, the
+   routers assume the role of hosts in the context of tunnel mode SA.
+   All implementations conforming to this specification MUST support
+   transport mode SA to provide required IPsec security to OSPFv3
+   packets.  They MAY also support tunnel mode SA to provide required
+   IPsec security to OSPFv3 packets.
+
+3.  Authentication
+
+   Implementations conforming to this specification MUST support
+   authentication for OSPFv3.
+
+   In order to provide authentication to OSPFv3, implementations MUST
+   support ESP and MAY support AH.
+
+   If ESP in transport mode is used, it will only provide authentication
+   to OSPFv3 protocol packets excluding the IPv6 header, extension
+   headers, and options.
+
+   If AH in transport mode is used, it will provide authentication to
+   OSPFv3 protocol packets, selected portions of IPv6 header, selected
+   portions of extension headers, and selected options.
+
+   When OSPFv3 authentication is enabled,
+
+      o  OSPFv3 packets that are not protected with AH or ESP MUST be
+         silently discarded.
+
+      o  OSPFv3 packets that fail the authentication checks MUST be
+         silently discarded.
+
+4.  Confidentiality
+
+   Implementations conforming to this specification SHOULD support
+   confidentiality for OSPFv3.
+
+   If confidentiality is provided, ESP MUST be used.
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 3]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   When OSPFv3 confidentiality is enabled,
+
+      o  OSPFv3 packets that are not protected with ESP MUST be silently
+         discarded.
+
+      o  OSPFv3 packets that fail the confidentiality checks MUST be
+         silently discarded.
+
+5.  Distinguishing OSPFv3 from OSPFv2
+
+   The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89), and
+   OSPF distinguishes them based on the OSPF header version number.
+   However, current IPsec standards do not allow using arbitrary
+   protocol-specific header fields as the selectors.  Therefore, the
+   OSPF version field in the OSPF header cannot be used to distinguish
+   OSPFv3 packets from OSPFv2 packets.  As OSPFv2 is only for IPv4 and
+   OSPFv3 is only for IPv6, the version field in the IP header can be
+   used to distinguish OSPFv3 packets from OSPFv2 packets.
+
+6.  IPsec Requirements
+
+   In order to implement this specification, the following IPsec
+   capabilities are required.
+
+   Transport mode
+      IPsec in transport mode MUST be supported. [N3]
+
+   Multiple Security Policy Databases (SPDs)
+      The implementation MUST support multiple SPDs with an SPD
+      selection function that provides an ability to choose a specific
+      SPD based on interface. [N3]
+
+   Selectors
+      The implementation MUST be able to use source address, destination
+      address, protocol, and direction as selectors in the SPD.
+
+   Interface ID tagging
+      The implementation MUST be able to tag the inbound packets with
+      the ID of the interface (physical or virtual) via which it
+      arrived. [N3]
+
+   Manual key support
+      Manually configured keys MUST be able to secure the specified
+      traffic. [N3]
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 4]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   Encryption and authentication algorithms
+      The implementation MUST NOT allow the user to choose stream
+      ciphers as the encryption algorithm for securing OSPFv3 packets
+      since the stream ciphers are not suitable for manual keys.
+
+      Except when in conflict with the above statement, the key words
+      "MUST", "MUST NOT", "REQUIRED", "SHOULD", and "SHOULD NOT" that
+      appear in the [N6] document for algorithms to be supported are to
+      be interpreted as described in [N7] for OSPFv3 support as well.
+
+   Dynamic IPsec rule configuration
+      The routing module SHOULD be able to configure, modify, and delete
+      IPsec rules on the fly.  This is needed mainly for securing
+      virtual links.
+
+   Encapsulation of ESP packet
+      IP encapsulation of ESP packets MUST be supported.  For
+      simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
+
+   Different SAs for different Differentiated Services Code Points
+      (DSCPs)
+      As per [N3], the IPsec implementation MUST support the
+      establishment and maintenance of multiple SAs with the same
+      selectors between a given sender and receiver.  This allows the
+      implementation to associate different classes of traffic with the
+      same selector values in support of Quality of Service (QoS).
+
+7.  Key Management
+
+   OSPFv3 exchanges both multicast and unicast packets.  While running
+   OSPFv3 over a broadcast interface, the authentication/confidentiality
+   required is "one to many".  Since IKE is based on the Diffie-Hellman
+   key agreement protocol and works only for two communicating parties,
+   it is not possible to use IKE for providing the required "one to
+   many" authentication/confidentiality.  This specification mandates
+   the usage of Manual Keying with current IPsec implementations.
+   Future specifications can explore the usage of protocols like
+   Kerberized Internet Negotiation of Keys/Group Secure Association Key
+   Management Protocol (KINK/GSAKMP) when they are widely available.  In
+   manual keying, SAs are statically installed on the routers and these
+   static SAs are used to authenticate/encrypt packets.
+
+   The following discussion explains that it is not scalable and is
+   practically infeasible to use different security associations for
+   inbound and outbound traffic to provide the required "one to many"
+   security.  Therefore, the implementations MUST use manually
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 5]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   configured keys with the same SA parameters (Security Parameter Index
+   (SPI), keys, etc.) for both inbound and outbound SAs (as shown in
+   Figure 3).
+
+          A                  |
+        SAa     ------------>|
+        SAb     <------------|
+                             |
+          B                  |
+        SAb     ------------>|
+        SAa     <------------|                 Figure 1
+                             |
+          C                  |
+        SAa/SAb ------------>|
+        SAa/SAb <------------|
+                             |
+                         Broadcast
+                          Network
+
+   If we consider communication between A and B in Figure 1, everything
+   seems to be fine.  A uses security association SAa for outbound
+   packets and B uses the same for inbound packets and vice versa.  Now
+   if we include C in the group and C sends a packet using SAa, then
+   only A will be able to understand it.  Similarly, if C sends a packet
+   using SAb, then only B will be able to understand it.  Since the
+   packets are multicast and they are going to be processed by both A
+   and B, there is no SA for C to use so that both A and B can
+   understand them.
+
+          A                  |
+        SAa     ------------>|
+        SAb     <------------|
+        SAc     <------------|
+                             |
+          B                  |
+        SAb     ------------>|
+        SAa     <------------|                 Figure 2
+        SAc     <------------|
+                             |
+          C                  |
+        SAc     ------------>|
+        SAa     <------------|
+        SAb     <------------|
+                             |
+                         Broadcast
+                          Network
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 6]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   The problem can be solved by configuring SAs for all the nodes on
+   every other node as shown in Figure 2.  So A, B, and C will use SAa,
+   SAb, and SAc, respectively, for outbound traffic.  Each node will
+   lookup the SA to be used based on the source (A will use SAb and SAc
+   for packets received from B and C, respectively).  This solution is
+   not scalable and practically infeasible because a large number of SAs
+   will need to be configured on each node.  Also, the addition of a
+   node in the broadcast network will require the addition of another SA
+   on every other node.
+
+         A                   |
+        SAo     ------------>|
+        SAi     <------------|
+                             |
+         B                   |
+        SAo     ------------>|
+        SAi     <------------|                 Figure 3
+                             |
+         C                   |
+        SAo     ------------>|
+        SAi     <------------|
+                             |
+                         Broadcast
+                          Network
+
+   The problem can be solved by using the same SA parameters (SPI, keys,
+   etc.) for both inbound (SAi) and outbound (SAo) SAs as shown in
+   Figure 3.
+
+8.  SA Granularity and Selectors
+
+   The user SHOULD be given the choice of sharing the same SA among
+   multiple interfaces or using a unique SA per interface.
+
+   OSPFv3 supports running multiple instances over one interface using
+   the "Instance Id" field contained in the OSPFv3 header.  As IPsec
+   does not support arbitrary fields in the protocol header to be used
+   as the selectors, it is not possible to use different SAs for
+   different OSPFv3 instances running over the same interface.
+   Therefore, all OSPFv3 instances running over the same interface will
+   have to use the same SA.  In OSPFv3 RFC terminology, SAs are per-link
+   and not per-interface.
+
+
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 7]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+9.  Virtual Links
+
+   A different SA than the SA of the underlying interface MUST be
+   provided for virtual links.  Packets sent on virtual links use
+   unicast non-link local IPv6 addresses as the IPv6 source address,
+   while packets sent on other interfaces use multicast and unicast link
+   local addresses.  This difference in the IPv6 source address
+   differentiates the packets sent on virtual links from other OSPFv3
+   interface types.
+
+   As the virtual link end point IPv6 addresses are not known, it is not
+   possible to install SPD/Security Association Database (SAD) entries
+   at the time of configuration.  The virtual link end point IPv6
+   addresses are learned during the routing table computation process.
+   The packet exchange over the virtual links starts only after the
+   discovery of the end point IPv6 addresses.  In order to protect these
+   exchanges, the routing module must install the corresponding SPD/SAD
+   entries before starting these exchanges.  Note that manual SA
+   parameters are preconfigured but not installed in the SAD until the
+   end point addresses are learned.
+
+   According to the OSPFv3 RFC [N2], the virtual neighbor's IP address
+   is set to the first prefix with the "LA-bit" set from the list of
+   prefixes in intra-area-prefix-Link State Advertisements (LSAs)
+   originated by the virtual neighbor.  But when it comes to choosing
+   the source address for the packets that are sent over the virtual
+   link, the RFC [N2] simply suggests using one of the router's own
+   global IPv6 addresses.  In order to install the required security
+   rules for virtual links, the source address also needs to be
+   predictable.  Hence, routers that implement this specification MUST
+   change the way the source and destination addresses are chosen for
+   packets exchanged over virtual links when IPsec is enabled.
+
+   The first IPv6 address with the "LA-bit" set in the list of prefixes
+   advertised in intra-area-prefix-LSAs in the transit area MUST be used
+   as the source address for packets exchanged over the virtual link.
+   When multiple intra-area-prefix-LSAs are originated, they are
+   considered concatenated and are ordered by ascending Link State ID.
+
+   The first IPv6 address with the "LA-bit" set in the list of prefixes
+   received in intra-area-prefix-LSAs from the virtual neighbor in the
+   transit area MUST be used as the destination address for packets
+   exchanged over the virtual link.  When multiple intra-area-prefix-
+   LSAs are received, they are considered concatenated and are ordered
+   by ascending Link State ID.
+
+   This makes both the source and destination addresses of packets
+   exchanged over the virtual link predictable when IPsec is enabled.
+
+
+
+Gupta & Melam               Standards Track                     [Page 8]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+10.  Rekeying
+
+   To maintain the security of a link, the authentication and encryption
+   key values SHOULD be changed periodically.
+
+10.1.  Rekeying Procedure
+
+   The following three-step procedure SHOULD be provided to rekey the
+   routers on a link without dropping OSPFv3 protocol packets or
+   disrupting the adjacency.
+
+   (1) For every router on the link, create an additional inbound SA for
+       the interface being rekeyed using a new SPI and the new key.
+
+   (2) For every router on the link, replace the original outbound SA
+       with one using the new SPI and key values.  The SA replacement
+       operation should be atomic with respect to sending OSPFv3 packets
+       on the link so that no OSPFv3 packets are sent without
+       authentication/encryption.
+
+   (3) For every router on the link, remove the original inbound SA.
+
+   Note that all routers on the link must complete step 1 before any
+   begin step 2.  Likewise, all the routers on the link must complete
+   step 2 before any begin step 3.
+
+   One way to control the progression from one step to the next is for
+   each router to have a configurable time constant KeyRolloverInterval.
+   After the router begins step 1 on a given link, it waits for this
+   interval and then moves to step 2.  Likewise, after moving to step 2,
+   it waits for this interval and then moves to step 3.
+
+   In order to achieve smooth key transition, all routers on a link
+   should use the same value for KeyRolloverInterval and should initiate
+   the key rollover process within this time period.
+
+   At the end of this procedure, all the routers on the link will have a
+   single inbound and outbound SA for OSPFv3 with the new SPI and key
+   values.
+
+10.2.  KeyRolloverInterval
+
+   The configured value of KeyRolloverInterval should be long enough to
+   allow the administrator to change keys on all the OSPFv3 routers.  As
+   this value can vary significantly depending upon the implementation
+   and the deployment, it is left to the administrator to choose an
+   appropriate value.
+
+
+
+
+Gupta & Melam               Standards Track                     [Page 9]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+10.3.  Rekeying Interval
+
+   This section analyzes the security provided by manual keying and
+   recommends that the encryption and authentication keys SHOULD be
+   changed at least every 90 days.
+
+   The weakest security provided by the security mechanisms discussed in
+   this specification is when NULL encryption (for ESP) or no encryption
+   (for AH) is used with the HMAC-MD5 authentication.  Any other
+   algorithm combinations will at least be as hard to break as the ones
+   mentioned above.  This is shown by the following reasonable
+   assumptions:
+
+      o  NULL Encryption and HMAC-SHA-1 Authentication will be more
+         secure as HMAC-SHA-1 is considered to be more secure than
+         HMAC-MD5.
+
+      o  NON-NULL Encryption and NULL Authentication combination is not
+         applicable as this specification mandates authentication when
+         OSPFv3 security is enabled.
+
+      o  Data Encryption Security (DES) Encryption and HMAC-MD5
+         Authentication will be more secure because of the additional
+         security provided by DES.
+
+      o  Other encryption algorithms like 3DES and the Advanced
+         Encryption Standard (AES) will be more secure than DES.
+
+   RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5
+   signature option.  The analysis provided in RFC 3562 is also
+   applicable to this specification as the analysis is independent of
+   data patterns.
+
+11.  IPsec Protection Barrier and SPD
+
+   The IPsec protection barrier MUST be around the OSPF protocol.
+   Therefore, all the inbound and outbound OSPF traffic goes through
+   IPsec processing.
+
+   The SPD selection function MUST return an SPD with the following rule
+   for all the interfaces that have OSPFv3
+   authentication/confidentiality disabled.
+
+      No.  source       destination       protocol        action
+      1     any            any              OSPF          bypass
+
+
+
+
+
+
+Gupta & Melam               Standards Track                    [Page 10]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   The SPD selection function MUST return an SPD with the following
+   rules for all the interfaces that have OSPFv3
+   authentication/confidentiality enabled.
+
+      No.  source       destination       protocol        action
+      2   fe80::/10        any             OSPF           protect
+      3   fe80::/10        any       ESP/OSPF or AH/OSPF  protect
+      4   src/128        dst/128           OSPF           protect
+      5   src/128        dst/128     ESP/OSPF or AH/OSPF  protect
+
+   For rules 2 and 4, action "protect" means encrypting/calculating
+   Integrity Check Value (ICV) and adding an ESP or AH header.  For
+   rules 3 and 5, action "protect" means decrypting/authenticating the
+   packets and stripping the ESP or AH header.
+
+   Rule 1 will bypass the OSPFv3 packets without any IPsec processing on
+   the interfaces that have OSPFv3 authentication/confidentiality
+   disabled.
+
+   Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been
+   secured with ESP/AH headers.
+
+   ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet
+   secured with ESP or AH.
+
+   Rules 2 and 3 are meant to secure the unicast and multicast OSPF
+   packets that are not being exchanged over the virtual links.
+
+   Rules 4 and 5 are meant to secure the packets being exchanged over
+   virtual links.  These rules are installed after learning the virtual
+   link end point IPv6 addresses.  These rules MUST be installed in the
+   SPD for the interfaces that are connected to the transit area for the
+   virtual link.  These rules MAY alternatively be installed on all the
+   interfaces.  If these rules are not installed on all the interfaces,
+   clear text or malicious OSPFv3 packets with the same source and
+   destination addresses as the virtual link end point IPv6 addresses
+   will be delivered to OSPFv3.  Though OSPFv3 drops these packets as
+   they were not received on the right interface, OSPFv3 receives some
+   clear text or malicious packets even when the security is enabled.
+   Installing these rules on all the interfaces ensures that OSPFv3 does
+   not receive these clear text or malicious packets when security is
+   enabled.  On the other hand, installing these rules on all the
+   interfaces increases the processing overhead on the interfaces where
+   there is no other IPsec processing.  The decision of whether to
+   install these rules on all the interfaces or on just the interfaces
+   that are connected to the transit area is a private decision and
+   doesn't affect the interoperability in any way.  Hence it is an
+   implementation choice.
+
+
+
+Gupta & Melam               Standards Track                    [Page 11]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+12.  Entropy of Manual Keys
+
+   The implementations MUST allow the administrator to configure the
+   cryptographic and authentication keys in hexadecimal format rather
+   than restricting it to a subset of ASCII characters (letters,
+   numbers, etc.).  A restricted character set will reduce key entropy
+   significantly as discussed in [I2].
+
+13.  Replay Protection
+
+   Since it is not possible using the current standards to provide
+   complete replay protection while using manual keying, the proposed
+   solution will not provide protection against replay attacks.
+
+   Detailed analysis of various vulnerabilities of the routing protocols
+   and OSPF in particular is discussed in [I3] and [I2].  The conclusion
+   is that replay of OSPF packets can cause adjacencies to be disrupted,
+   which can lead to a DoS attack on the network.  It can also cause
+   database exchange process to occur continuously thus causing CPU
+   overload as well as micro loops in the network.
+
+14.  Security Considerations
+
+   This memo discusses the use of IPsec AH and ESP headers to provide
+   security to OSPFv3 for IPv6.  Hence, security permeates throughout
+   this document.
+
+   OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
+   vulnerabilities in two scenarios -- one with no authentication or
+   simple password authentication and the other with cryptographic
+   authentication.  The solution described in this specification
+   provides protection against all the vulnerabilities identified for
+   scenarios with cryptographic authentication with the following
+   exceptions:
+
+   Limitations of manual key:
+
+   This specification mandates the usage of manual keys.  The following
+   are the known limitations of the usage of manual keys.
+
+      o  As the sequence numbers cannot be negotiated, replay protection
+         cannot be provided.  This leaves OSPF insecure against all the
+         attacks that can be performed by replaying OSPF packets.
+
+      o  Manual keys are usually long lived (changing them often is a
+         tedious task).  This gives an attacker enough time to discover
+         the keys.
+
+
+
+
+Gupta & Melam               Standards Track                    [Page 12]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+      o  As the administrator is manually configuring the keys, there is
+         a chance that the configured keys are weak (there are known
+         weak keys for DES/3DES at least).
+
+   Impersonating attacks:
+
+   The usage of the same key on all the OSPF routers connected to a link
+   leaves them all insecure against impersonating attacks if any one of
+   the OSPF routers is compromised, malfunctioning, or misconfigured.
+
+   Detailed analysis of various vulnerabilities of routing protocols is
+   discussed in [I3].
+
+15.  References
+
+15.1.  Normative References
+
+   [N1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+   [N2] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740,
+        December 1999.
+
+   [N3] Kent, S. and K. Seo, "Security Architecture for the Internet
+        Protocol", RFC 4301, December 2005.
+
+   [N4] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
+        December 2005.
+
+   [N5] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
+
+   [N6] Eastlake 3rd, D., "Cryptographic Algorithm Implementation
+        Requirements for Encapsulating Security Payload (ESP) and
+        Authentication Header (AH)", RFC 4305, December 2005.
+
+   [N7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+15.2.  Informative References
+
+   [I1] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
+        December 2005.
+
+   [I2] Jones, E. and O. Moigne, "OSPF Security Vulnerabilities
+        Analysis", Work in Progress.
+
+   [I3] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing
+        Protocols", Work in Progress.
+
+
+
+
+Gupta & Melam               Standards Track                    [Page 13]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+   [I4] Leech, M., "Key Management Considerations for the TCP MD5
+        Signature Option", RFC 3562, July 2003.
+
+Acknowledgements
+
+   The authors would like to extend sincere thanks to Marc Solsona,
+   Janne Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells,
+   Vishwas Manral, and Sam Hartman for providing useful information and
+   critiques on this memo.  The authors would like to extend special
+   thanks to Acee Lindem for many editorial changes.
+
+   We would also like to thank members of the IPsec and OSPF WG for
+   providing valuable review comments.
+
+Authors' Addresses
+
+   Mukesh Gupta
+   Tropos Networks
+   555 Del Rey Ave
+   Sunnyvale, CA 94085
+
+   Phone: 408-331-6889
+   EMail: mukesh.gupta@tropos.com
+
+
+   Nagavenkata Suresh Melam
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   Phone: 408-505-4392
+   EMail: nmelam@juniper.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                    [Page 14]
+
+RFC 4552       Authentication/Confidentiality for OSPFv3       June 2006
+
+
+Full 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.
+
+   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.
+
+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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Gupta & Melam               Standards Track                    [Page 15]
+