Subject: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services

From: Brian Weis <[email-masked]>
Date: Tue, 5 Apr 2011 20:39:57 -0700

Greetings, 

I have a suggestion to draft-ymbk-bgpsec-reqs that is somewhat related to Andrei's proposal, and was previously mentioned in the Friday SIDR meeting. It also arises out of a concern that BGPSEC could make the global routing system more fragile. 

The proposed BGPSEC protocol includes a dependance on loosely synchronized time. I understand that time is the easiest means of obtaining freshness of the origin's BGPSEC signature. But it does add a practical requirement that BGP routers be dependance on an ntp time server, which was not the case previously. I'm sure there's a number of strategies that can be deployed to minimize this dependance, but in any case I suggest that the bgpsec-reqs document describe what restrictions and/or allowances that BGPSEC has on  other network services.

Personally, I'm leery of making Internet routing dependent on ntp so would prefer the requirement be no weaker than the following proposal:

3.xx A BGPSEC design MAY be dependent on network services other than BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy.

Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Apr 2011 04:21:36 -0700

> Personally, I'm leery of making Internet routing dependent on ntp so
> would prefer the requirement be no weaker than the following proposal:
> 
> 3.xx A BGPSEC design MAY be dependent on network services other than
> BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy.

if we want crypto level assurance, do you have a suggestion other than
x.509, which depends on low precision time?

for x.509 level assurance, what kind of precision does one actually
need?  my guess is on the order of hours.  so we may not want to
specifically abjure ntp, but rather express some bounds on the
precision one wants.

btw, from talking to largish operators, ntp is on all non-trivial
routers.  heck, it's even on 2511s i use for some remote oob serial
craft port access.  i am less sure of customers' edge routers.

randy

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 6 Apr 2011 13:36:32 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Wednesday, April 06, 2011 7:22 AM
To: Brian Weis
Cc: [email-masked]
Subject: Re: [sidr] Proposed draft-ymbk-bgpsec-reqs topic: dependance on network services

> BGP (e.g., ntp) but SHOULD attempt to avoid such a dependancy.

btw, from talking to largish operators, ntp is on all non-trivial routers.  heck, it's even on 2511s i use for some remote oob
serial craft port access.  i am less sure of customers' edge routers.

[WEG] +1. I don't know why we're so stressed about something so simple. It's minimally a 2 line config. There are publicly available
NTP servers. If we're really worried about NTP being a limiting factor in BGPSEC's implementation, we have a *much* larger problem.

Wes George

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Apr 2011 06:45:00 -0700

> [WEG] +1. I don't know why we're so stressed about something so
> simple.

not stressed out, though some coffee would help.

brian is a crypto/security guy.  he is validly worried that we could hit
a problem.  i suspect he is not too familiar with how we all config our
networks, and that ntp, warts and all, is kind of assumed in all base
configs.

i suspect one key here is that, if the router has a time tick and loses
it, it will be a looooong time before it loses sufficient accuracy that
x.509 gloop will notice.  and then all sorts of red flags will go up and
our noc's bgp/snmp monitors will go bright red.

another thought is that i am not sure we monitor time drift and ntp
death in our routers.  this would be a good thing if we're betting our
buns on it.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Apr 2011 11:06:08 -0400

>specifically abjure ntp, but rather express some bounds on the

In general, the precision required for a PKI depends on the tolerance 
that  relying parties have re expiration of certs and staleness of 
CRLs.  During the WG meeting we received a good suggestion to call 
for explicit local controls
for staleness of CRLs and cert expiration.  Establishing conventions for
path expiration granularity is consistent with that thrust.

Steve

---

From: Brian Weis <[email-masked]>
Date: Wed, 6 Apr 2011 09:02:23 -0700

Hi Randy,

> networks, and that ntp, warts and all, is kind of assumed in all base

I'm actually not surprised ntp is assumed in all the base configs, but I did want to see some discussion as to whether not being able to reach an ntp server for an indeterminate period of time was a problem.

My way of example, you mentioned those old 2511's in your first reply ... I'm pretty sure they don't retain the time over a reboot, which means not reaching an ntp server could be serious if you were depending on it. 

If all your BGP routers keep reasonably accurate time all of the time including over reboots, then ntp might not be a problem. I still think the requirement is a good general requirement to keep in mind for BGPSEC. 

> death in our routers.  this would be a good thing if we're betting our

That's in the spirit of my concern ....

Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 06 Apr 2011 09:05:38 -0700

> My way of example, you mentioned those old 2511's in your first reply
> ... I'm pretty sure they don't retain the time over a reboot, which
> means not reaching an ntp server could be serious if you were
> depending on it.

which is why redundant ntp service is available on every segment on
which there are routers.  and they also have remote strat 1 and 2
configured.

> If all your BGP routers keep reasonably accurate time all of the time
> including over reboots, then ntp might not be a problem. I still think
> the requirement is a good general requirement to keep in mind for
> BGPSEC.

i do not think we are in strong disagreement.  we just need modest text
which is actually in scale with both ops and x.509, a fun reach :)

randy