doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc3682.txt b/doc/rfc/rfc3682.txt
new file mode 100644
index 0000000..5866077
--- /dev/null
+++ b/doc/rfc/rfc3682.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                            V. Gill
+Request for Comments: 3682                                    J. Heasley
+Category: Experimental                                          D. Meyer
+                                                           February 2004
+
+
+             The Generalized TTL Security Mechanism (GTSM)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6)
+   to protect a protocol stack from CPU-utilization based attacks has
+   been proposed in many settings (see for example, RFC 2461).  This
+   document generalizes these techniques for use by other protocols such
+   as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
+   Bidirectional Forwarding Detection, and Label Distribution Protocol
+   (LDP) (RFC 3036).  While the Generalized TTL Security Mechanism
+   (GTSM) is most effective in protecting directly connected protocol
+   peers, it can also provide a lower level of protection to multi-hop
+   sessions.  GTSM is not directly applicable to protocols employing
+   flooding mechanisms (e.g., multicast), and use of multi-hop GTSM
+   should be considered on a case-by-case basis.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . .  2
+       2.1.  GTSM Negotiation . . . . . . . . . . . . . . . . . . . .  3
+       2.2.  Assumptions on Attack Sophistication . . . . . . . . . .  3
+   3.  GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . .  3
+       3.1.  Multi-hop Scenarios. . . . . . . . . . . . . . . . . . .  4
+             3.1.1.  Intra-domain Protocol Handling . . . . . . . . .  5
+   4.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  5
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
+       5.1.  TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . .  5
+       5.2.  Tunneled Packets . . . . . . . . . . . . . . . . . . . .  6
+             5.2.1.  IP in IP . . . . . . . . . . . . . . . . . . . .  6
+
+
+
+Gill, et al.                  Experimental                      [Page 1]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+             5.2.2.  IP in MPLS . . . . . . . . . . . . . . . . . . .  7
+       5.3.  Multi-Hop Protocol Sessions. . . . . . . . . . . . . . .  8
+   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  8
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       7.1.  Normative References . . . . . . . . . . . . . . . . . .  8
+       7.2.  Informative References . . . . . . . . . . . . . . . . .  9
+   8.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
+
+1.  Introduction
+
+   The Generalized TTL Security Mechanism (GTSM) is designed to protect
+   a router's TCP/IP based control plane from CPU-utilization based
+   attacks.  In particular, while cryptographic techniques can protect
+   the router-based infrastructure (e.g., BGP [RFC1771], [RFC1772]) from
+   a wide variety of attacks, many attacks based on CPU overload can be
+   prevented by the simple mechanism described in this document.  Note
+   that the same technique protects against other scarce-resource
+   attacks involving a router's CPU, such as attacks against
+   processor-line card bandwidth.
+
+   GTSM is based on the fact that the vast majority of protocol peerings
+   are established between routers that are adjacent [PEERING].  Thus
+   most protocol peerings are either directly between connected
+   interfaces or at the worst case, are between loopback and loopback,
+   with static routes to loopbacks.  Since TTL spoofing is considered
+   nearly impossible, a mechanism based on an expected TTL value can
+   provide a simple and reasonably robust defense from infrastructure
+   attacks based on forged protocol packets.
+
+   Finally, the GTSM mechanism is equally applicable to both TTL (IPv4)
+   and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop
+   Limit have identical semantics.  As a result, in the remainder of
+   this document the term "TTL" is used to refer to both TTL or Hop
+   Limit (as appropriate).
+
+   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 BCP 14, RFC 2119
+   [RFC2119].
+
+2.  Assumptions Underlying GTSM
+
+   GTSM is predicated upon the following assumptions:
+
+   (i)    The vast majority of protocol peerings are between adjacent
+          routers [PEERING].
+
+
+
+
+Gill, et al.                  Experimental                      [Page 2]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+   (ii)   It is common practice for many service providers to ingress
+          filter (deny) packets that have the provider's loopback
+          addresses as the source IP address.
+
+   (iii)  Use of GTSM is OPTIONAL, and can be configured on a per-peer
+          (group) basis.
+
+   (iv)   The router supports a method of classifying traffic destined
+          for the route processor into interesting/control and
+          not-control queues.
+
+   (iv)   The peer routers both implement GTSM.
+
+2.1.  GTSM Negotiation
+
+   This document assumes that GTSM will be manually configured between
+   protocol peers.  That is, no automatic GTSM capability negotiation,
+   such as is envisioned by RFC 2842 [RFC2842] is assumed or defined.
+
+2.2.  Assumptions on Attack Sophistication
+
+   Throughout this document, we assume that potential attackers have
+   evolved in both sophistication and access to the point that they can
+   send control traffic to a protocol session, and that this traffic
+   appears to be valid control traffic (i.e., has the source/destination
+   of configured peer routers).
+
+   We also assume that each router in the path between the attacker and
+   the victim protocol speaker decrements TTL properly (clearly, if
+   either the path or the adjacent peer is compromised, then there are
+   worse problems to worry about).
+
+   Since the vast majority of our peerings are between adjacent routers,
+   we can set the TTL on the protocol packets to 255 (the maximum
+   possible for IP) and then reject any protocol packets that come in
+   from configured peers which do NOT have an inbound TTL of 255.
+
+   GTSM can be disabled for applications such as route-servers and other
+   large diameter multi-hop peerings.  In the event that an the attack
+   comes in from a compromised multi-hop peering, that peering can be
+   shut down (a method to reduce exposure to multi-hop attacks is
+   outlined below).
+
+3.  GTSM Procedure
+
+   GTSM SHOULD NOT be enabled by default.  The following process
+   describes the per-peer behavior:
+
+
+
+
+Gill, et al.                  Experimental                      [Page 3]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+    (i)   If GTSM is enabled, an implementation performs the following
+          procedure:
+
+          (a)  For directly connected routers,
+
+              o Set the outbound TTL for the protocol connection to 255.
+
+              o For each configured protocol peer:
+
+                Update the receive path Access Control List (ACL) or
+                firewall to only allow protocol packets to pass onto the
+                Route Processor (RP) that have the correct <source,
+                destination, TTL> tuple.  The TTL must either be 255
+                (for a directly connected peer), or 255-(configured-
+                range-of-acceptable-hops) for a multi-hop peer.  We
+                specify a range here to achieve some robustness to
+                changes in topology.  Any directly connected check MUST
+                be disabled for such peerings.
+
+                It is assumed that a receive path ACL is an ACL that is
+                designed to control which packets are allowed to go to
+                the RP.  This procedure will only allow protocol packets
+                from adjacent router to pass onto the RP.
+
+          (b)  If the inbound TTL is 255 (for a directly connected
+               peer), or 255-(configured-range-of-acceptable-hops) (for
+               multi-hop peers), the packet is NOT processed.  Rather,
+               the packet is placed into a low priority queue, and
+               subsequently logged and/or silently discarded.  In this
+               case, an ICMP message MUST NOT be generated.
+
+    (ii)  If GTSM is not enabled, normal protocol behavior is followed.
+
+3.1.  Multi-hop Scenarios
+
+   When a multi-hop protocol session is required, we set the expected
+   TTL value to be 255-(configured-range-of-acceptable-hops).  This
+   approach provides a qualitatively lower degree of security for the
+   protocol implementing GTSM (i.e., a DoS attack could theoretically be
+   launched by compromising some box in the path).  However, GTSM will
+   still catch the vast majority of observed DDoS attacks against a
+   given protocol.  Note that since the number of hops can change
+   rapidly in real network situations, it is considered that GTSM may
+   not be able to handle this scenario adequately and an implementation
+   MAY provide OPTIONAL support.
+
+
+
+
+
+
+Gill, et al.                  Experimental                      [Page 4]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+3.1.1.  Intra-domain Protocol Handling
+
+   In general, GTSM is not used for intra-domain protocol peers or
+   adjacencies.  The special case of iBGP peers can be protected by
+   filtering at the network edge for any packet that has a source
+   address of one of the loopback addresses used for the intra-domain
+   peering.  In addition, the current best practice is to further
+   protect such peers or adjacencies with an MD5 signature [RFC2385].
+
+4.  Acknowledgments
+
+   The use of the TTL field to protect BGP originated with many
+   different people, including Paul Traina and Jon Stewart.  Ryan
+   McDowell also suggested a similar idea.  Steve Bellovin, Jay
+   Borkenhagen, Randy Bush, Vern Paxon, Pekka Savola, and Robert Raszuk
+   also provided useful feedback on earlier versions of this document.
+   David Ward provided insight on the generalization of the original
+   BGP-specific idea.
+
+5.  Security Considerations
+
+   GTSM is a simple procedure that protects single hop protocol
+   sessions, except in those cases in which the peer has been
+   compromised.
+
+5.1.  TTL (Hop Limit) Spoofing
+
+   The approach described here is based on the observation that a TTL
+   (or Hop Limit) value of 255 is non-trivial to spoof, since as the
+   packet passes through routers towards the destination, the TTL is
+   decremented by one.  As a result, when a router receives a packet, it
+   may not be able to determine if the packet's IP address is valid, but
+   it can determine how many router hops away it is (again, assuming
+   none of the routers in the path are compromised in such a way that
+   they would reset the packet's TTL).
+
+   Note, however, that while engineering a packet's TTL such that it has
+   a particular value when sourced from an arbitrary location is
+   difficult (but not impossible), engineering a TTL value of 255 from
+   non-directly connected locations is not possible (again, assuming
+   none of the directly connected neighbors are compromised, the packet
+   hasn't been tunneled to the decapsulator, and the intervening routers
+   are operating in accordance with RFC 791 [RFC791]).
+
+
+
+
+
+
+
+
+Gill, et al.                  Experimental                      [Page 5]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+5.2.  Tunneled Packets
+
+   An exception to the observation that a packet with TTL of 255 is
+   difficult to spoof occurs when a protocol packet is tunneled to a
+   decapsulator who then forwards the packet to a directly connected
+   protocol peer.  In this case the decapsulator (tunnel endpoint) can
+   either be the penultimate hop, or the last hop itself.  A related
+   case arises when the protocol packet is tunneled directly to the
+   protocol peer (the protocol peer is the decapsulator).
+
+   When the protocol packet is encapsulated in IP, it is possible to
+   spoof the TTL.  It may also be impossible to legitimately get the
+   packet to the protocol peer with a TTL of 255, as in the IP in MPLS
+   cases described below.
+
+   Finally, note that the security of any tunneling technique depends
+   heavily on authentication at the tunnel endpoints, as well as how the
+   tunneled packets are protected in flight.  Such mechanisms are,
+   however, beyond the scope of this memo.
+
+5.2.1.  IP in IP
+
+   Protocol packets may be tunneled over IP directly to a protocol peer,
+   or to a decapsulator (tunnel endpoint) that then forwards the packet
+   to a directly connected protocol peer (e.g., in IP-in-IP [RFC2003],
+   GRE [RFC2784], or various forms of IPv6-in-IPv4 [RFC2893]).  These
+   cases are depicted below.
+
+    Peer router ---------- Tunnel endpoint router and peer
+     TTL=255     [tunnel]   [TTL=255 at ingress]
+                            [TTL=255 at egress]
+
+    Peer router ---------- Tunnel endpoint router ----- On-link peer
+     TTL=255     [tunnel]   [TTL=255 at ingress]  [TTL=254 at ingress]
+                            [TTL=254 at egress]
+
+   In the first case, in which the encapsulated packet is tunneled
+   directly to the protocol peer, the encapsulated packet's TTL can be
+   set arbitrary value.  In the second case, in which the encapsulated
+   packet is tunneled to a decapsulator (tunnel endpoint) which then
+   forwards it to a directly connected protocol peer, RFC 2003 specifies
+   the following behavior:
+
+      When encapsulating a datagram, the TTL in the inner IP header is
+      decremented by one if the tunneling is being done as part of
+      forwarding the datagram; otherwise, the inner header TTL is not
+      changed during encapsulation.  If the resulting TTL in the inner
+      IP header is 0, the datagram is discarded and an ICMP Time
+
+
+
+Gill, et al.                  Experimental                      [Page 6]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+      Exceeded message SHOULD be returned to the sender.  An
+      encapsulator MUST NOT encapsulate a datagram with TTL = 0.
+
+   Hence the inner IP packet header's TTL, as seen by the decapsulator,
+   can be set to an arbitrary value (in particular, 255).  As a result,
+   it may not be possible to deliver the protocol packet to the peer
+   with a TTL of 255.
+
+5.2.2.  IP in MPLS
+
+   Protocol packets may also be tunneled over MPLS to a protocol peer
+   which either the penultimate hop (when the penultimate hop popping
+   (PHP) is employed [RFC3032]), or one hop beyond the penultimate hop.
+   These cases are depicted below.
+
+    Peer router ---------- Penultimate Hop (PH) and peer
+     TTL=255     [tunnel]   [TTL=255 at ingress]
+                            [TTL<=254 at egress]
+
+
+    Peer router ---------- Penultimate Hop  -------- On-link peer
+     TTL=255     [tunnel]   [TTL=255 at ingress]  [TTL <=254 at ingress]
+                            [TTL<=254 at egress]
+
+   TTL handling for these cases is described in RFC 3032.  RFC 3032
+   states that when the IP packet is first labeled:
+
+      ... the TTL field of the label stack entry MUST BE set to the
+      value of the IP TTL field.  (If the IP TTL field needs to be
+      decremented, as part of the IP processing, it is assumed that
+      this has already been done.)
+
+   When the label is popped:
+
+      When a label is popped, and the resulting label stack is empty,
+      then the value of the IP TTL field SHOULD BE replaced with the
+      outgoing TTL value, as defined above.  In IPv4 this also requires
+      modification of the IP header checksum.
+
+   where the definition of "outgoing TTL" is:
+
+      The "incoming TTL" of a labeled packet is defined to be the value
+      of the TTL field of the top label stack entry when the packet is
+      received.
+
+
+
+
+
+
+
+Gill, et al.                  Experimental                      [Page 7]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+   The "outgoing TTL" of a labeled packet is defined to be the larger
+   of:
+
+      a) one less than the incoming TTL,
+      b) zero.
+
+   In either of these cases, the minimum value by which the TTL could be
+   decremented would be one (the network operator prefers to hide its
+   infrastructure by decrementing the TTL by the minimum number of LSP
+   hops, one, rather than decrementing the TTL as it traverses its MPLS
+   domain).  As a result, the maximum TTL value at egress from the MPLS
+   cloud is 254 (255-1), and as a result the check described in section
+   3 will fail.
+
+5.3.  Multi-Hop Protocol Sessions
+
+   While the GTSM method is less effective for multi-hop protocol
+   sessions, it does close the window on several forms of attack.
+   However, in the multi-hop scenario GTSM is an OPTIONAL extension.
+   Protection of the protocol infrastructure beyond what is provided by
+   the GTSM method will likely require cryptographic machinery such as
+   is envisioned by Secure BGP (S-BGP) [SBGP1,SBGP2], and/or other
+   extensions.  Finally, note that in the multi-hop case described
+   above, we specify a range of acceptable TTLs in order to achieve some
+   robustness to topology changes.  This robustness to topological
+   change comes at the cost of the loss of some robustness to different
+   forms of attack.
+
+6.  IANA Considerations
+
+   This document creates no new requirements on IANA namespaces
+   [RFC2434].
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC791]   Postel, J., "Internet Protocol Specification", STD 5, RFC
+              791, September 1981.
+
+   [RFC1771]  Rekhter, Y. and T. Li (Editors), "A Border Gateway
+              Protocol (BGP-4)", RFC 1771, March 1995.
+
+   [RFC1772]  Rekhter, Y. and P. Gross, "Application of the Border
+              Gateway Protocol in the Internet", RFC 1772, March 1995.
+
+   [RFC2003]  Perkins, C., "IP Encapsulation with IP", RFC 2003, October
+              1996.
+
+
+
+Gill, et al.                  Experimental                      [Page 8]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+              Signature Option", RFC 2385, August 1998.
+
+   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+              Discover for IP Version 6 (IPv6)", RFC 2461, December
+              1998.
+
+   [RFC2784]  Farinacci, D., "Generic Routing Encapsulation (GRE)", RFC
+              2784, March 2000.
+
+   [RFC2842]  Chandra, R. and J. Scudder, "Capabilities Advertisement
+              with BGP-4", RFC 2842, May 2000.
+
+   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+              IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+   [RFC3032]  Rosen, E. Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, January 2001.
+
+   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
+              B. Thomas, "LDP Specification", RFC 3036, January 2001.
+
+   [RFC3392]  Chandra, R. and J. Scudder, "Capabilities Advertisement
+              with BGP-4", RFC 3392, November 2002.
+
+   [SBGP1]    Kent, S., C. Lynn, and K. Seo, "Secure Border Gateway
+              Protocol (Secure-BGP)", IEEE Journal on Selected Areas in
+              Communications, volume 18, number 4, April, 2000.
+
+   [SBGP2]    Kent, S., C. Lynn, J. Mikkelson, and K. Seo, "Secure
+              Border Gateway Protocol (S-BGP) -- Real World Performance
+              and Deployment Issues", Proceedings of the IEEE Network
+              and Distributed System Security Symposium, February, 2000.
+
+7.2.  Informative References
+
+   [BFD]      Katz, D. and D. Ward, "Bidirectional Forwarding
+              Detection", Work in Progress, June 2003.
+
+   [PEERING]  Empirical data gathered from the Sprint and AOL backbones,
+              October, 2002.
+
+
+
+
+
+
+Gill, et al.                  Experimental                      [Page 9]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+   [RFC2028]  Hovey, R. and S. Bradner, "The Organizations Involved in
+              the IETF Standards Process", BCP 11, RFC 2028, October
+              1996.
+
+   [RFC2434]  Narten, T., and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC3618]  Meyer, D. and W. Fenner, Eds., "The Multicast Source
+              Discovery Protocol (MSDP)", RFC 3618, October 2003.
+
+8.  Authors' Addresses
+
+   Vijay Gill
+
+   EMail: vijay@umbc.edu
+
+
+   John Heasley
+
+   EMail: heas@shrubbery.net
+
+
+   David Meyer
+
+   EMail: dmm@1-4-5.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gill, et al.                  Experimental                     [Page 10]
+
+RFC 3682           Generalized TTL Security Mechanism      February 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gill, et al.                  Experimental                     [Page 11]
+