draft-ietf-rtgwg-rfc3682bis-03.txt   draft-ietf-rtgwg-rfc3682bis-04.txt 
INTERNET-DRAFT V. Gill INTERNET-DRAFT V. Gill
draft-ietf-rtgwg-rfc3682bis-03.txt J. Heasley draft-ietf-rtgwg-rfc3682bis-04.txt J. Heasley
D. Meyer D. Meyer
Category Proposed Standard Category Proposed Standard
Updates: RFC 3682 Obsoletes: RFC 3682
Expires: March 2005 September 2004 Expires: March 2005 September 2004
The Generalized TTL Security Mechanism (GTSM) The Generalized TTL Security Mechanism (GTSM)
<draft-ietf-rtgwg-rfc3682bis-03.txt> <draft-ietf-rtgwg-rfc3682bis-04.txt>
Status of this Memo Status of this Memo
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667 [RFC3667]. By submitting provisions of section 3 of RFC 3667 [RFC3667]. By submitting
this Internet-Draft, each author represents that any this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is 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 aware have been or will be disclosed, and any of which he or
skipping to change at page 2, line 23 skipping to change at page 2, line 23
to protect a protocol stack from CPU-utilization based attacks has to protect a protocol stack from CPU-utilization based attacks has
been proposed in many settings (see for example, RFC 2461). This been proposed in many settings (see for example, RFC 2461). This
document generalizes these techniques for use by other protocols such document generalizes these techniques for use by other protocols such
as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP), as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),
Bidirectional Forwarding Detection, and Label Distribution Protocol Bidirectional Forwarding Detection, and Label Distribution Protocol
(LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM) (LDP) (RFC 3036). While the Generalized TTL Security Mechanism (GTSM)
is most effective in protecting directly connected protocol peers, it is most effective in protecting directly connected protocol peers, it
can also provide a lower level of protection to multi-hop sessions. can also provide a lower level of protection to multi-hop sessions.
GTSM is not directly applicable to protocols employing flooding GTSM is not directly applicable to protocols employing flooding
mechanisms (e.g., multicast), and use of multi-hop GTSM should be mechanisms (e.g., multicast), and use of multi-hop GTSM should be
considered on a case-by-case basis. This document updates RFC 3682. considered on a case-by-case basis. This document obsoletes RFC
3682.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4 2. Assumptions Underlying GTSM. . . . . . . . . . . . . . . . . . 4
2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4 2.1. GTSM Negotiation. . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 5 2.2. Assumptions on Attack Sophistication. . . . . . . . . . . . 5
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6 3.1. Multi-hop Scenarios . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 7 3.1.1. Intra-domain Protocol Handling . . . . . . . . . . . . . 7
skipping to change at page 7, line 27 skipping to change at page 7, line 27
filtering at the network edge for any packet that has a source filtering at the network edge for any packet that has a source
address of one of the loopback addresses used for the intra-domain address of one of the loopback addresses used for the intra-domain
peering. In addition, the current best practice is to further protect peering. In addition, the current best practice is to further protect
such peers or adjacencies with an MD5 signature [RFC2385]. such peers or adjacencies with an MD5 signature [RFC2385].
4. Acknowledgments 4. Acknowledgments
The use of the TTL field to protect BGP originated with many The use of the TTL field to protect BGP originated with many
different people, including Paul Traina and Jon Stewart. Ryan different people, including Paul Traina and Jon Stewart. Ryan
McDowell also suggested a similar idea. Steve Bellovin, Jay McDowell also suggested a similar idea. Steve Bellovin, Jay
Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Pekka Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Pekka Savola,
Savola, Robert Raszuk aand Alex Zinin lso provided useful Robert Raszuk and Alex Zinin also provided useful feedback on earlier
feedback on earlier versions of this document. David Ward versions of this document. David Ward provided insight on the
provided insight on the generalization of the original generalization of the original BGP-specific idea.
BGP-specific idea.
5. Security Considerations 5. Security Considerations
GTSM is a simple procedure that protects single hop protocol GTSM is a simple procedure that protects single hop protocol
sessions, except in those cases in which the peer has been sessions, except in those cases in which the peer has been
compromised. In particular, it does not protect against the compromised. In particular, it does not protect against the wide
wide range of on-the-wire attacks; protection from these range of on-the-wire attacks; protection from these attacks requires
attacks requires more rigorous security mechanisms. more rigorous security mechanisms.
5.1. TTL (Hop Limit) Spoofing 5.1. TTL (Hop Limit) Spoofing
The approach described here is based on the observation that a TTL 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 (or Hop Limit) value of 255 is non-trivial to spoof, since as the
packet passes through routers towards the destination, the TTL is packet passes through routers towards the destination, the TTL is
decremented by one. As a result, when a router receives a packet, it 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 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 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 none of the routers in the path are compromised in such a way that
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/