Subject: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation

From: Jeffrey Haas <[email-masked]>
Date: Fri, 1 Apr 2011 13:11:42 +0000

Per the microphone at SIDR on Friday:

1. Text should be added to strongly recommend that when a route that is
about to expire is having an update of the expiration advertised that
receiving peers should treat the reception of an update with no other
changes to the reachability than the expiration time and signatures as a
refresh of the existing route.  Implementations supporting temporal time
breaking in path selection should *not* treat the refresh as a new update.

2. Short expiry times are an attack on the routing system, especially boxes
with slow signature processors.  Routes that will expire "soon" should be
refreshed with enough time so that receiving peers can take their own sweet
time to validate that a new valid path has been received in spare cycles.

Note that I realize that it is difficult to distinguish between a refresh
vs. an update.  Suggestion 2 may make poor cryptographic protocol sense.
This effectively has BGP holding onto a stale announcement for a period of
time until it has validated the route.

-- Jeff

---

From: Russ White <[email-masked]>
Date: Sat, 02 Apr 2011 13:26:53 -0400

> breaking in path selection should *not* treat the refresh as a new update.

I would think the problem here is that the BGP implementation must:

1. Know not to know run bestpath on such a path change.
2. Know to send a new update, although the bestpath hasn't changed.

It would be useful to indicate the portions of the BGP RFCs that must be
changed in order to support this.

:-)

Russ

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 4 Apr 2011 00:10:44 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, April 01, 2011 9:12 AM
To: [email-masked]
Subject: [sidr] IETF 80 - suggestions related to expiry time and BGP implementation

2. Short expiry times are an attack on the routing system, especially boxes with slow signature processors.  Routes that will expire
"soon" should be refreshed with enough time so that receiving peers can take their own sweet time to validate that a new valid path
has been received in spare cycles.

[WEG] Along those same lines - I think we need a global minimum value for beacons to reduce the exposure to this DoS attack (on the
validating router) vector. We already have scaling issues when too many  eBGP peers set their BGP timers too aggressively on the
same box, and that is at least locally controllable by enforcing a minimum in the negotiated session. There's no negotiation
happening here, and therefore no way to protect those routers, short of ignoring updates, which generates stale routes and probably
churn (depending on the policy).
In fact, this starts looking a lot like the Route Flap Dampening problem we're trying to solve elsewhere in IETF - a very small
amount of the prefixes might be responsible for an overwhelming majority of the updates to the detriment of the routing system's
performance. Even if it's just a refresh, there's a non-trivial impact if too many people start being overly paranoid about their
expiry times. 

But by the same token, being too conservative with the expiry means that there is a longer period of exposure where a replay would
be effective, and the value of implementing the overhead at all starts becoming questionable. How long is too long for a replay
attack to go unnoticed? I'd bet that a lot of the folks worried about this would answer in minutes, while those concerned primarily
with the hardware in their routers would answer in hours...

This is an area where any info we have about the prevalence of replay attacks and their characteristics would be really helpful in
determining how much risk we are preventing by addressing this specific attack vector vs how much overhead we're generating with
this expiry machinery.

Thanks,
Wes George

---

From: Randy Bush <[email-masked]>
Date: Sun, 03 Apr 2011 21:32:11 -0700

> How long is too long for a replay attack to go unnoticed? I'd bet that
> a lot of the folks worried about this would answer in minutes, while
> those concerned primarily with the hardware in their routers would
> answer in hours...

from the bgpsec-ops docco

   As beaconing places a load on the entire global routing system,
   careful thought MUST be given to any need to beacon frequently.  This
   would be based on a conservative estimation of the vulnerability to a
   replay attack.

   Beacon timing and signature validity periods SHOULD be as follows:

   The Exemplary Citizen:  Prefix originators who are not overly
      concerned about replay attacks might announce with a signature
      validity of multiple weeks and beacon one third of the validity
      period.

   Normal Prefix:  Most prefixes SHOULD announce with a signature
      validity of a week and beacon every three days.

   Critical Prefix:  Of course, we all think what we do is critical.
      But prefixes of top level DNS servers, and RPKI publication points
      are actually critical to large swaths of the Internet and are
      therefore tempting targets for replay attacks.  It is suggested
      that the beaconing of these prefixes SHOULD be two to four hours,
      with a signature validity of six to twelve hours.

      Note that this may incur route flap damping (RFD) with current
      default but deprecated RFD parameters, see [I-D.ymbk-rfd-usable].

randy