[Idr] proposed additional text

[Yakov Rekhter <yakov at juniper.net>]

Folks,

During the IESG review Steve Kent proposed the following text to
be added to the BGP protocol spec. 

   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 are still subject to some forms of replay attacks.
   
   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
   and distributing) the keys used to compute the MAC. A different
   key should be used for each protected peer. If the same key is used
   for multiple peers, the offered security services are degraded.
   (In fact, the reuse of the same key with the same peer for multiple
   TCP connections already represents a vulnerability, as noted above.)
   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. Keys also should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack.
   
   RFC 2385 calls for implementations to support keys "composed of a
   string of printable ASCII of 80 bytes or less ."  While it is
   difficult to specify an appropriate key size for a wide range of
   environments, it is worth noting that current standards for analogous
   integrity algorithms make use of key sizes of about 128-256 bits.
   An 80-byte, printable ASCII string, falls into this range.

If there are any objections to adding this text to the protocol
spec please post them to the list by May 24, 2004.

Yakov.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr