Subject: [Idr] proposed additional text

From: Yakov Rekhter <[email-masked]>
Date: Mon, 17 May 2004 06:44:56 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 17 May 2004 13:59:50 -0400

Curtis,

-> A replay attack involves sending information later on when it is no
-> longer valid.  Since the TCP sequence number is covered by the TCP
-> checksum, and therefore MD5 digest that replaces it, a replay attack
-> is not possible.  

  IMHO, TCP sequence number is not designed to protect replay attacks,
  rather the intention is to detect network errors/congestion and to 
  provide a form of simple ordered byte stream reliability.

  For example, I computed that, the sequence number would wrap around:
  in (2^32 bytes * 8 bits/byte) / (10 * 10^6 bit/sec) = 3435.6 sec ~ 
  1 hour using 32 bit sequence number when streaming 10 Mbps, 
  in 343.56 sec using 32 bit sequence number when streaming 100Mbps, 
  in 0.00046 sec using 32 bit sequence numbers when streaming 75Tbps.
  
  I am not sure how TCP checksum and MD5 digest is going to protect
  if the attacker is not going to change a single bit the segment.

  So, all the replay attacker has to do is to wait for the next 
  window to sneak in the old segment after sequence number wrapping.
  This is the main reason why IPSec argued to increase the sequence
  number from 32 bit to 64 bits.

Venkata.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 May 2004 07:34:03 -0700

Folks,

How about if we'll replace

   Because the mechanism defined in RFC 2385 does not
   provide peer-entity authentication, these connections are still
   subject to some forms of replay attacks.

with the following

   Because the mechanism defined in RFC 2385 does not provide
   peer-entity authentication, these connections are still subject
   to some forms of replay attacks. Changing key more frequently
   (e.g., once a week or more) reduces the probability of such
   attacks.  Determining whether such attacks could happen in
   practice is outside the scope of this document.

Yakov.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 May 2004 01:17:45 -0400

Yakov:

this sentence is confusing.

   Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router.

Is it 
   Absent the use of mechanisms that effect these
   security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router.

If not, could you are Steve explain what it really means.

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Monday, May 17, 2004 9:45 AM
To: [email-masked]
Subject: [Idr] proposed additional text

Folks,

   

Yakov.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 20 May 2004 01:17:45 -0400

Yakov:

Is it 

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Monday, May 17, 2004 9:45 AM
To: [email-masked]
Subject: [Idr] proposed additional text

Folks,

   

Yakov.