Subject: [Idr] proposed additional text

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 May 2004 07:32:55 -0700

Folks,

Steve Kent proposed the following replacement for the text he suggested
earlier (the text I posted on 5/17/2004). 

   BGP makes use of TCP for reliable transport of its traffic between
   peer routers. To provide connection-oriented integrity and data
   origin authentication, on a point-to-point basis, BGP specifies
   use of the mechanism defined in RFC 2385. These services are intended
   to detect and reject active wiretapping attacks against the
   inter-router TCP connections. Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router. Because the mechanism
   defined in the RFC does not provide peer-entity authentication,
   these connections may be subject to some forms of replay attacks
   that will not be detected at the TCP layer. Such attacks might
   result in delivery (from TCP) of "broken" or "spoofed" BGP messages.
   
   The mechanism defined in RFC 2385 augments the normal TCP checksum
   with a 16-byte message authentication code (MAC) that is computed
   over the same data as the TCP checksum. This MAC is based on a
   one-way hash function (MD5) and use of a secret key. The key is
   shared between peer routers and is used to generate MAC values that
   are not readily computed by an attacker who does not have access
   to the key. A compliant implementation must support this mechanism,
   and must allow a network administrator to activate it on a per-peer
   basis.
   
   RFC 2385 does not specify a means of managing (e.g., generating,
   distributing, and replacing) the keys used to compute the MAC. RFC
   3562 (an informational document) provides some guidance in this
   area, and provides rationale to support this guidance. It notes
   that a distinct key should be used for communication with each
   protected peer. If the same key is used for multiple peers, the
   offered security services may be degraded, e.g., due to increased
   risk of compromise at one router adversely affecting other routers.
   
   The keys used for MAC computation should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack. RFC 3562 suggest a crypto period (the interval during which
   a key is employed) of at most 90 days. More frequent key changes
   reduce the likelihood that replay attacks (as described above) will
   be feasible. However, absent a standard mechanism for effecting
   such changes in a coordinated fashion between peers, one cannot
   assume that BGP-4 implementations complying with this RFC will
   support frequent key changes.
   
   Obviously, each  key also should be chosen so as to be hard for an
   attacker to guess.  The techniques specified in RFC 1750 for random
   number generation provide a guide for generation of values that
   could be used as keys. RFC 2385 calls for implementations to support
   keys "composed of a string of printable ASCII of 80 bytes or less."
   RFC 3562 suggests keys used in this context be 12 to 24 bytes
   of random (pseudo-random) bits. This is fairly consistent with
   suggestions for analogous MAC algorithms, which typically employ
   keys in the range of 16-20 bytes. RFC 3562 also observes that, to
   provide enough random bits at the low end of this range, a typical
   ACSII text string would have to be close to the upper bound for
   key length specified in RFC 2385.

Please review and comment. The deadline for comments is 6/2/2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: [email-masked] (Scott Bradner)
Date: Mon, 24 May 2004 12:14:47 -0400 (EDT)

> On Mon, May 24, 2004 at 07:32:55AM -0700, Yakov Rekhter wrote:

as is normally the case with Steve's text, this text is clear and precise
and seems to say what needs to be said

Scott

---

From: "Looney, Jonathan" <[email-masked]>
Date: Mon, 24 May 2004 15:48:27 -0400

>    However, absent a standard mechanism for effecting

I think this sentence should be reworded and/or removed.  I believe that
this limitation is an operational one, rather than being a limit of a
BGP implementation.  Every BGP implementation of which I'm aware will
(as it should) let you change keys whenever you want; the difficulty is
in coordinating with peers.

-Jon