summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4808.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4808.txt')
-rw-r--r--doc/rfc/rfc4808.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc4808.txt b/doc/rfc/rfc4808.txt
new file mode 100644
index 0000000..14cd7ea
--- /dev/null
+++ b/doc/rfc/rfc4808.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group S. Bellovin
+Request for Comments: 4808 Columbia University
+Category: Informational March 2007
+
+
+ Key Change Strategies for TCP-MD5
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ The TCP-MD5 option is most commonly used to secure BGP sessions
+ between routers. However, changing the long-term key is difficult,
+ since the change needs to be synchronized between different
+ organizations. We describe single-ended strategies that will permit
+ (mostly) unsynchronized key changes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin Informational [Page 1]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+1. Introduction
+
+ The TCP-MD5 option [RFC2385] is most commonly used to secure BGP
+ sessions between routers. However, changing the long-term key is
+ difficult, since the change needs to be synchronized between
+ different organizations. Worse yet, if the keys are out of sync, it
+ may break the connection between the two routers, rendering repair
+ attempts difficult.
+
+ The proper solution involves some sort of key management protocol.
+ Apart from the complexity of such things, RFC 2385 was not written
+ with key changes in mind. In particular, there is no KeyID field in
+ the option, which means that even a key management protocol would run
+ into the same problem.
+
+ Fortunately, a heuristic permits key change despite this protocol
+ deficiency. The change can be installed unilaterally at one end of a
+ connection; it is fully compatible with the existing protocol.
+
+1.1. Terminology
+
+ 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 [RFC2119].
+
+2. The Algorithm
+
+ Separate algorithms are necessary for transmission and reception.
+ Reception is easier; we explain it first.
+
+2.1. Reception
+
+ A receiver has a list of valid keys. Each key has a (conceptual)
+ timestamp associated with it. When a segment arrives, each key is
+ tried in turn. The segment is discarded if and only if it cannot be
+ validated by any key in the list.
+
+ In principle, there is no need to test keys in any particular order.
+ For performance reasons, though, a simple most-recently-used (MRU)
+ strategy -- try the last valid key first -- should work well. More
+ complex mechanisms, such as examining the TCP sequence number of an
+ arriving segment to see whether it fits in a hole, are almost
+ certainly unnecessary. On the other hand, validating that a received
+ segment is putatively legal, by checking its sequence number against
+ the advertised window, can help avoid denial of service attacks.
+
+ The newest key that has successfully validated a segment is marked as
+ the "preferred" key; see below.
+
+
+
+Bellovin Informational [Page 2]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+ Implicit in this scheme is the assumption that older keys will
+ eventually be unneeded and can be removed. Accordingly,
+ implementations SHOULD provide an indication of when a key was last
+ used successfully.
+
+2.2. Transmission
+
+ Transmission is more complex, because the sender does not know which
+ keys can be accepted at the far end. Accordingly, the conservative
+ strategy is to delay using any new keys for a considerable amount of
+ time, probably measured in days. This time interval is the amount of
+ asynchronicity the parties wish to permit; it is agreed upon out of
+ band and configured manually.
+
+ Some automation is possible, however. If a key has been used
+ successfully to validate an incoming segment, clearly the other side
+ knows it. Accordingly, any key marked as "preferred" by the
+ receiving part of a stack SHOULD be used for transmissions.
+
+ A sophisticated implementation could try alternate keys if the TCP
+ retransmission counter gets too high. (This is analogous to dead
+ gateway detection.) In particular, if a key change has just been
+ attempted but such segments are not acknowledged, it is reasonable to
+ fall back to the previous key and issue an alert of some sort.
+ Similarly, an implementation with a new but unused key could
+ occasionally try to use it, much in the way that TCP implementations
+ probe closed windows. Doing this avoids the "silent host" problem
+ discussed in Section 3.1. This should be done at a moderately slow
+ rate.
+
+ Note that there is an ambiguity when an acknowledgment is received
+ for a segment transmitted with two different keys. The TCP Timestamp
+ option [RFC1323] can be used for disambiguation.
+
+3. Operations
+
+3.1. Single-Ended Operations
+
+ Suppose only one end of the connection has this algorithm
+ implemented. The new key is provisioned on that system, with a start
+ time far in the future -- sufficiently far, in fact, that it will not
+ be used spontaneously. After the key is ready, the other end is
+ notified, out-of-band, that a key change can commence.
+
+ At some point, the other end is upgraded. Because it does not have
+ multiple keys available, it will start using the new key immediately
+ for its transmission, and will drop all segments that use the old
+ key. As soon as it tries to transmit, the upgraded side will
+
+
+
+Bellovin Informational [Page 3]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+ designate the new key as preferred, and will use it for all of its
+ transmissions. Note specifically that this will include
+ retransmissions of any segments rejected because they used the old
+ key.
+
+ There is a problem if the unchanged machine is a "silent host" -- a
+ host that has nothing to say, and hence does not transmit. The best
+ way to avoid this is for an upgraded machine to try a variety of keys
+ in the event of repeated unacknowledged packets, and to probe for new
+ unused keys during silent periods, as discussed in Section 2.2.
+ Alternatively, application-level KeepAlive messages may be used to
+ ensure that neither end of the connection is completely silent. See,
+ for example, Section 4.4 of [RFC4271] or Section 3.5.4 of [RFC3036].
+
+3.2. Double-Ended Operations
+
+ Double-ended operations are similar, save that both sides deploy the
+ new key at about the same time. One should be configured to start
+ using the new key at a point where it is reasonably certain that the
+ other side would have it installed, too. Assuming that has in fact
+ happened, the new key will be marked "preferred" on both sides.
+
+3.3. Monitoring
+
+ As noted, implementations should monitor when a key was last used for
+ transmission or reception. Any monitoring mechanism can be used;
+ most likely, it will be one or both of a MIB object or objects and
+ the vendor's usual command-line mechanism for displaying data of this
+ type. Regardless, the network operations center should keep track of
+ this. When a new key has been used successfully for both
+ transmission and reception for a reasonable amount of time -- the
+ exact value isn't crucial, but it should probably be longer than
+ twice the maximum segment lifetime -- the old key can be marked for
+ deletion. There is an implicit assumption here that there will not
+ be substantial overlap in the usage period of such keys; monitoring
+ systems should look for any such anomalies, of course.
+
+4. Moving Forward
+
+ As implied in Section 1, this is an interim strategy, intended to
+ make TCP-MD5 operationally usable today. We do not suggest or
+ recommend it as a long-term solution. In this section, we make some
+ suggestions about the design of a future TCP authentication option.
+
+ The first and most obvious change is to replace keyed MD5 with a
+ stronger MAC [RFC4278]. Today, HMAC-SHA1 [RFC4634] is the preferred
+ choice, though others such as UMAC [RFC4418] should be considered as
+ well.
+
+
+
+Bellovin Informational [Page 4]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+ A new authentication option should contain some form of a Key ID
+ field. Such an option would permit unambiguous identification of
+ which key was used to create the MAC for a given segment, sparing the
+ receiver the need to engage in the sort of heuristics described here.
+ A Key ID is useful with both manual and automatic key management.
+ (Note carefully that we do not prescribe any particular Key ID
+ mechanism here. Rather, we are stating a requirement: there must be
+ a simple, low-cost way to select a particular key, and it must be
+ possible to rekey without tearing down long-lived connections.)
+
+ Finally, an automated key management mechanism should be defined.
+ The general reasoning for that is set forth in [RFC4107]; specific
+ issues pertaining to BGP and TCP are given in [RFC3562].
+
+5. Security Considerations
+
+ In theory, accepting multiple keys simultaneously makes life easier
+ for an attacker. In practice, if the recommendations in [RFC3562]
+ are followed, this should not be a problem.
+
+ New keys must be communicated securely. Specifically, new key
+ messages must be kept confidential and must be properly
+ authenticated.
+
+ Having multiple keys makes CPU denial-of-service attacks easier.
+ This suggests that keeping the overlap period reasonably short is a
+ good idea. In addition, the Generalized TTL Security Mechanism
+ [RFC3682], if applicable to the local topology, can help. Note that
+ most of the time, only one key will exist; virtually all of the
+ remaining time there will be only two keys in existence.
+
+6. IANA Considerations
+
+ There are no IANA actions required. The TCP-MD5 option number is
+ defined in [RFC2385], and is currently listed by IANA.
+
+7. Acknowledgments
+
+ I'd like to thank Ron Bonica, Randy Bush, Ross Callon, Rob Evans,
+ Eric Rescorla, and Sam Weiler for their comments and inspiration.
+
+
+
+
+
+
+
+
+
+
+
+Bellovin Informational [Page 5]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
+ for High Performance", RFC 1323, May 1992.
+
+ [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.
+
+8.2. Informative References
+
+ [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
+ B. Thomas, "LDP Specification", RFC 3036, January 2001.
+
+ [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
+ Signature Option", RFC 3562, July 2003.
+
+ [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
+ Security Mechanism (GTSM)", RFC 3682, February 2004.
+
+ [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
+ Key Management", BCP 107, RFC 4107, June 2005.
+
+ [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+ Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+ [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance
+ Regarding the TCP MD5 Signature Option (RFC 2385) and the
+ BGP-4 Specification", RFC 4278, January 2006.
+
+ [RFC4418] Krovetz, T., "UMAC: Message Authentication Code using
+ Universal Hashing", RFC 4418, March 2006.
+
+ [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
+ (SHA and HMAC-SHA)", RFC 4634, August 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin Informational [Page 6]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+Author's Address
+
+ Steven M. Bellovin
+ Columbia University
+ 1214 Amsterdam Avenue
+ MC 0401
+ New York, NY 10027
+ US
+
+ Phone: +1 212 939 7149
+ EMail: bellovin@acm.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin Informational [Page 7]
+
+RFC 4808 TCP-MD5 Key Change March 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST 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 currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Bellovin Informational [Page 8]
+