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: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 10:43:19 -0400

Yakov,

> be added to the BGP protocol spec. 

Where will this text be inserted into the BGP specification?

We don't usually speak of routers, we speak of BGP speakers and
probably should use that consistently throughout this text.

>    and/or masquerade as a legitimate peer router. Because the mechanism

s/Absent use of mechanisms.*,/In the absence of these security mechanisms/

or something similar?

>    and must allow a network administrator to activate it on a per-peer

s/must/MUST/g

>    could be used as keys. Keys also should be changed periodically,

Should "should" be "SHOULD"? :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 10:43:19 -0400

Yakov,

or something similar?

s/must/MUST/g

-- 
Jeff Haas 
NextHop Technologies

---

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

Jeff,

> Where will this text be inserted into the BGP specification?

Perhaps in the Security Considerations section.

> probably should use that consistently throughout this text.

Sure.

> s/Absent use of mechanisms.*,/In the absence of these security mechanisms/

Sure.

> >    and must allow a network administrator to activate it on a per-peer

Sure.

> Should "should" be "SHOULD"? :-)

Sure.

Yakov.

---

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

Jeff,

Sure.

Sure.

Sure.

Sure.

Yakov.

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 17 May 2004 11:26:41 -0400

>    for multiple peers, the offered security services are degraded.

I assume this refers to the increased probability 
of the key being operationally compromised. 
Perhaps this should be made explicit.

>    TCP connections already represents a vulnerability, as noted above.)

The parenthetical comment has an unresolved 
reference -- the "noted above" ain't above. 
(Unless this relates to something already in the 
spec and not the proposed text?)

>spec please post them to the list by May 24, 2004.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 17 May 2004 11:26:41 -0400

--John

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 12:52:05 -0400

In message <[email-masked]>, Yakov Rekhter writes

Yakov,

This is a stretch.  Regardless, I suggest we include this exactly as
Steve suggested unless any part of it can be shown to be false.

>    Because the mechanism

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.  It also covers address and port so you can't read
from one connection and replay on another.

If Steve means that a DoS is possible by sending the same valid packet
over and over, even though TCP will ignore the resend of data prior to
the sequence number, then the above statement should either be dropped
or changed to state that a DoS attack is possible which does no damage
other than increase CPU loading.

Unless Steve can tell us how a replay attack is possible, then this
sentence should be removed.  If it is a false statement, it needs to
be removed.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 12:52:05 -0400

Yakov,

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 14:44:02 -0400

> from one connection and replay on another.

Presume you are in circumstances in which a replay attack is possible.
Presume also that you can sniff the wire.
Given the above, the circumstances under which an attack are valid are:
1. The key is still the same (or much less likely, a different key
   results in the same MAC)
2. The source, dst, src port, dst port tuples are the same.
3. The segment which you are looking to replay is within the window.

Given all of the above, it is possible to replay the packet.
If the packet is a SYN or RST, then you can obviously disrupt the session.
You can gather these by simply sniffing the wire and simply replaying
any that are within the acceptable TCP session and window.

If the packet is a data packet, the behavior will depend on the
TCP implementation.  This may desynchronize the session at the
least.

Note that I am not a TCP expert nor do I play one on TV.  However,
I've heard some interesting stories about how different implementations
fail to follow the spec and odd behaviors thus caused.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 14:44:02 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 16:12:35 -0400

> fail to follow the spec and odd behaviors thus caused.

Unless you can match the exact start and end of the packet after the
wrap occurs, all you have is a DoS attach that is good for one shot
every week or so.  And you have to be able to packet sniff to do it.

Real threat - very close to zero.  We have better things to worry
about.

If some implementation doesn't cease when the BGP flow gets out of
sync its very broken.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 16:28:08 -0400

Curtis,

> Real threat - very close to zero.  We have better things to worry

I'd agree.  IMO the security folk tend to be very picky about knowing
the circumstances of where we have issues no matter how small the
window.

IIRC, your original objection was showing how this could be done or
otherwise delete the sentences that covered it.  I think we've
shown how.  Deriving the unlikelihood of this set of circumstances
can be left to the reader.

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 17:09:33 -0400

> can be left to the reader.

The threat is exactly zero if you change the key once a week or more
so I still think the sentence can be omited.  At least it needs to be
clarified.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 16:12:35 -0400

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 May 2004 16:28:08 -0400

Curtis,

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 May 2004 17:09:33 -0400

Curtis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 May 2004 15:11:55 -0400

John,

>I assume this refers to the increased probability of the key being 
>operationally compromised. Perhaps this should be made explicit.

There are several concerns. Use of a key in other than a pairwise 
disjoint fashion  undermines the data origin authentication service, 
because other than the peer router can generate traffic that will be 
treated as being from the peer. Also, if the router interface 
addresses used on a link are not globally unique, then traffic from 
one link could be injected into another link and accepted as valid, 
if the same key is used. And, as you noted, more widespread 
distribution of a secret key generally increases the likelihood that 
the key may be compromised.

>The parenthetical comment has an unresolved reference -- the "noted 
>above" ain't above. (Unless this relates to something already in the 

Strike the "as the noted above" text.  The vulnerability here is that 
traffic from one TCP connection between two routers can be replayed 
into a later connection, when sequence numbers align appropriately, 
because the same key is used for many TCP connections (over time) 
between a pair of routers.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 May 2004 15:11:55 -0400

John,

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 May 2004 11:03:35 -0400

> the key may be compromised.

Common practice is to put the same key in all core routers of a given
provider.  The thinking there is if a core router is compromised the
provider has more important things to worry about than BGP replay
attacks.  Yes it would be better to have separate keys.  This just
happens to be a common choice.

The providers I worked for never used the same encryption keys for
anything for routers that were on customer premise.

> between a pair of routers.

Each BGP session will have a unique key pair.  The router that is on
the TCP accept end of the connection has port 179 but the other port
number is randomly chosen with each session.  Therefore you can't
replay from one session into the next.  If a BGP cease occurs due to
misaligned packets in a insertion attempt, all previously snooped
packets become of no value to the attacker.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 20 May 2004 11:03:35 -0400

Curtis