Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 2385

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Network Working Group                                       A. Heffernan
Request for Comments: 2385                                 cisco Systems
Category: Standards Track                                    August 1998

      Protection of BGP Sessions via the TCP MD5 Signature Option

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 (1998).  All Rights Reserved.

IESG Note

   This document describes currrent existing practice for securing BGP
   against certain simple attacks.  It is understood to have security
   weaknesses against concerted attacks.

Abstract

   This memo describes a TCP extension to enhance security for BGP.  It
   defines a new TCP option for carrying an MD5 [RFC1321] digest in a
   TCP segment.  This digest acts like a signature for that segment,
   incorporating information known only to the connection end points.
   Since BGP uses TCP as its transport, using this option in the way
   described in this paper significantly reduces the danger from certain
   security attacks on BGP.

1.0  Introduction

   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets.

   To spoof a connection using the scheme described in this paper, an
   attacker would not only have to guess TCP sequence numbers, but would
   also have had to obtain the password included in the MD5 digest.
   This password never appears in the connection stream, and the actual
   form of the password is up to the application.  It could even change

Heffernan                   Standards Track                     [Page 1]
RFC 2385                TCP MD5 Signature Option             August 1998

   during the lifetime of a particular connection so long as this change
   was synchronized on both ends (although retransmission can become
   problematical in some TCP implementations with changing passwords).

   Finally, there is no negotiation for the use of this option in a
   connection, rather it is purely a matter of site policy whether or
   not its connections use the option.

2.0  Proposal

   Every segment sent on a TCP connection to be protected against
   spoofing will contain the 16-byte MD5 digest produced by applying the
   MD5 algorithm to these items in the following order:

       1. the TCP pseudo-header (in the order: source IP address,
          destination IP address, zero-padded protocol number, and
          segment length)
       2. the TCP header, excluding options, and assuming a checksum of
          zero
       3. the TCP segment data (if any)
       4. an independently-specified key or password, known to both TCPs
          and presumably connection-specific

   The header and pseudo-header are in network byte order.  The nature
   of the key is deliberately left unspecified, but it must be known by
   both ends of the connection.  A particular TCP implementation will
   determine what the application may specify as the key.

   Upon receiving a signed segment, the receiver must validate it by
   calculating its own digest from the same data (using its own key) and
   comparing the two digest.  A failing comparison must result in the
   segment being dropped and must not produce any response back to the
   sender.  Logging the failure is probably advisable.

   Unlike other TCP extensions (e.g., the Window Scale option
   [RFC1323]), the absence of the option in the SYN,ACK segment must not
   cause the sender to disable its sending of signatures.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.
   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of signatures must
   be under the complete control of the application, not at the mercy of
   the remote host not understanding the option.

Heffernan                   Standards Track                     [Page 2]
RFC 2385                TCP MD5 Signature Option             August 1998

3.0  Syntax

   The proposed option has the following format:

             +---------+---------+-------------------+
             | Kind=19 |Length=18|   MD5 digest...   |
             +---------+---------+-------------------+
             |                                       |
             +---------------------------------------+
             |                                       |