Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Mon, 14 Nov 2011 06:13:32 -0500

Brian,
 
For BGP-4 updates, Geoff does provide the peak numbers observed
for prefix updates in 1 second intervals.
http://bgpupdates.potaroo.net/instability/bgpupd.html
For example: 
Peak Prefix Update Rate per second:  1539   
while 
Average Prefix Updates per second:  2.76 
I suspect the peak perhaps corresponds to BGP session reset events
when updates are generated back-to-back.
If you exclude those reset events, then BGP-4 chattiness 
will have low variance. 
 
Since we do not have operational BGPSEC yet, we cannot obtain similar
measurements at present. But I am confident that if you focus on BGPSEC 
chattiness only due to beaconing (i.e., exclude BGP session resets events),
then the burstiness (of BGPSEC beacons alone) will be low.
Bear in mind that the protocol recommends beacons should be jittered
in time, and when thousands of prefixes are beaconed in a time-jittered
fashion from distributed sites, they smooth out 
and the resulting beacon arrival process at a router
would be a rather smooth Poisson process (variance/mean = 1).
So the peak # beacons in n-second intervals (for n>=1) will likely be a small 
multiple of the mean # beacons in n-second intervals. 
Again mind you, on the otherhand, if BGPSEC session resets occur, then that
would be quite different -- thousands of BGPSEC updates (not beacons) 
would be sent back-to-back in that case between the two affected peers. 
It may be noted that operators are anyway used to allowing 10s of seconds for 
table convergence after session resets.
(You will see an analysis of convergence following BGPSEC session reset 
in the presentation that Randy and I have in the SIDR WG meeting tomorrow.)   

Sriram
________________________________________
>From: Brian Dickson [[email-masked]]
>
>Hi, Sriram,
>
>Could you supply similar kinds of numbers, but with "peak" instead of
>"average", esp. 50%ile, 75%ile,  and 95%-ile levels for "peak"?
>
>Average is much less important than peak, in my experience.
>Steady-state is easy.
>
>Also, in noisy/spiky data, mean != median typically. BGP is noisy/spiky.
>
>(Also when doing percentiles, it is essential to say, "95%ile on
>5-minute samples, over a period of 1 week" for instance - and those
>would be the customary sample windows to use.)
>
>Thanks,
>Brian

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 14 Nov 2011 07:25:45 -0500

It will be as bursty as the sender of the bursts pleases.

A great way for the receiver of those non-urgent bursts
to insulate itself is to send them in a different tcp
session than regular BGP updates. It can then throttle
the BGPSEC bursts without affecting regular BGP.

If you consider a BGPSEC update only to be a signature
for a regular update, then there is no race condition.

In other words, to advertise a route, BGP needs
to send an unsigned update in the regular session,
as well as a signed one in the non-urgent BGPSEC
session.

An unsigned route is still useable in the absence of
a signed one. It is simply "NotFound" instead of "Valid".

If you put the BGPSEC traffic into a separate non-urgent
session, this spruce goose might just get off the ground.

--
Jakob Heitz.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sriram, Kotikalapudi
> Sent: Monday, November 14, 2011 3:14 AM
> To: Brian Dickson
> Cc: sidr wg list
> Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
> 
> Brian,
> 
> For BGP-4 updates, Geoff does provide the peak numbers observed for
> prefix updates in 1 second intervals.
> Average Prefix Updates per second:  2.76 I suspect the peak perhaps
> corresponds to BGP session reset events when updates are generated
> back-to-back.
> If you exclude those reset events, then BGP-4 chattiness will have
> low variance.
> 
> Since we do not have operational BGPSEC yet, we cannot obtain
> similar measurements at present. But I am confident that if you
> focus on BGPSEC chattiness only due to beaconing (i.e., exclude BGP
> session resets events), then the burstiness (of BGPSEC beacons
> alone) will be low.
> in time, and when thousands of prefixes are beaconed in a time-
> jittered fashion from distributed sites, they smooth out and the
> resulting beacon arrival process at a router would be a rather
> smooth Poisson process (variance/mean = 1).
> So the peak # beacons in n-second intervals (for n>=1) will likely
> be a small multiple of the mean # beacons in n-second intervals.
> Again mind you, on the otherhand, if BGPSEC session resets occur,
> then that would be quite different -- thousands of BGPSEC updates
> (not beacons) would be sent back-to-back in that case between the
> two affected peers.
> It may be noted that operators are anyway used to allowing 10s of
> seconds for table convergence after session resets.
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Mon, 14 Nov 2011 22:26:33 +0800

> It will be as bursty as the sender of the bursts pleases.

that is true today, someone can annouce at an arbitrary rate

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 14 Nov 2011 10:16:22 -0500

The difference is that today's updates all have the same urgency.
BGPSEC is not urgent. It doesn't matter if you don't receive a signature for a few minutes.
An UNREACH is not signed.

--
Jakob Heitz.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 14 Nov 2011 20:37:24 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jakob Heitz
>

[WEG] I don't totally agree with this characterization. If the BGPSec info triggers a recalculation of bestpath from what was chosen when the unsigned update came through, this has the potential to drive 2x the work, essentially take 2x longer for convergence, plus push another round of updates to downstream neighbors, another reprogram of the FIB, etc. Seems to me by the time we've gained any benefit of saving updates for later because the box is busy, we've triggered a far worse potential death spiral on a busy box. Processing a few additional updates is rather pale in comparison to having to consistently recalculate a non-trivial percentage of the table when the box gets "busy."
Similar to buffering and QoS, you can't get something for nothing here, and there are limits to where deferred processing can help to smooth out peaks vs. simply throwing more capacity at the problem, especially in the land of often underutilized multi-core systems.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 14 Nov 2011 20:46:42 -0500

I can not believe that it will be 2X.

First case: A beacon will very rarely cause a different
bestpath.

Second case: There is actually a changed route being updated.
You will receive both a regular update and a signature.
Only one of those will casue a new bestpath in the great
majority of cases.

Basically, in the large majority of cases, a signature does not
change the bestpath.

--
Jakob Heitz.

> From: George, Wes [mailto:[email-masked]]
> Sent: Monday, November 14, 2011 5:37 PM
> To: Jakob Heitz; Randy Bush
> Cc: Sriram, Kotikalapudi; sidr wg list
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-
> ietf-sidr-bgpsec-reqs)
> 
> > Of Jakob Heitz
> [WEG] I don't totally agree with this characterization. If the
> BGPSec info triggers a recalculation of bestpath from what was
> chosen when the unsigned update came through, this has the potential
> to drive 2x the work, essentially take 2x longer for convergence,
> plus push another round of updates to downstream neighbors, another
> reprogram of the FIB, etc. Seems to me by the time we've gained any
> benefit of saving updates for later because the box is busy, we've
> triggered a far worse potential death spiral on a busy box.
> Processing a few additional updates is rather pale in comparison to
> having to consistently recalculate a non-trivial percentage of the
> table when the box gets "busy."
> Similar to buffering and QoS, you can't get something for nothing
> here, and there are limits to where deferred processing can help to
> smooth out peaks vs. simply throwing more capacity at the problem,
> especially in the land of often underutilized multi-core systems.
> 
> Wes George
> 
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 14 Nov 2011 22:03:49 -0500

> From: Jakob Heitz [mailto:[email-masked]]
> Sent: Monday, November 14, 2011 8:47 PM
> To: George, Wes; Randy Bush
> Subject: RE: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-
> sidr-bgpsec-reqs)
>

[WEG] the objective amount of impact is probably not the important bit here.

>
> First case: A beacon will very rarely cause a different bestpath.
[WEG] True. However... your comment was not specific to beacons. Also when it does, it makes the load problem you're trying to solve worse.
> Only one of those will casue a new bestpath in the great majority of
> cases.
>
> Basically, in the large majority of cases, a signature does not change
> the bestpath.
>
[WEG] Not true. Bestpath in BGPSec land is chosen based on policy informed by the difference between valid, invalid and unknown. Even if the absence or presence of the signature only toggles the route between valid and unknown, given that those have a defined policy action (eg raise or lower local pref, etc), the only way to ensure that receiving a signature later than the initial route update does not trigger a change of best path (let alone a recompute that doesn't trigger a change, which probably has nearly the same impact) is to set ones policy such that unknown and valid are the same preference. While that may be reasonable in early incremental deployment, eventually I don't think that's a safe assumption, and really eventually is when we have a scaling problem, not in early deployment.

Wes George

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 14 Nov 2011 23:51:51 -0500

> Sent: Monday, November 14, 2011 7:04 PM
> ietf-
> [WEG] True. However... your comment was not specific to beacons.
> Also when it does, it makes the load problem you're trying to solve
> worse.
> >
> change
> [WEG] Not true. Bestpath in BGPSec land is chosen based on policy
> informed by the difference between valid, invalid and unknown. Even
> if the absence or presence of the signature only toggles the route
> between valid and unknown, given that those have a defined policy
> action (eg raise or lower local pref, etc), the only way to ensure
> that receiving a signature later than the initial route update does
> not trigger a change of best path (let alone a recompute that
> doesn't trigger a change, which probably has nearly the same impact)
> is to set ones policy such that unknown and valid are the same
> preference. While that may be reasonable in early incremental
> deployment, eventually I don't think that's a safe assumption, and
> really eventually is when we have a scaling problem, not in early
> deployment.

Great, so you don't disagree that beacons mostly cause no change.
That should cover the bulk of BGPSEC updates.

That brings us a long way down from 2X.

Now, for a regular update that changes the bestpath, the signature
will likely come later (in my proposal). If it replaces an existing
valid path, the bestpath will not change until the signature arrives.
If it replaces no path, then the regular update will produce a bestpath
change, but the signature will not.

In the unlikely event that the signature arrives first, the bestpath
may change twice.

--
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 15 Nov 2011 00:15:33 -0500

Sorry to jump in here, but I think that there is a drifting into conjecture...

It would be best to stay within the realm of facts.

> That brings us a long way down from 2X.

There is no empirical basis for 2X, either in the general case or the
specific case.

If I understand the "beacon" concept correctly, this is the
re-announcement from the origin,
based on the expiry time? Is this correct?

Then the impact to the listener will be:
The sum of (per-prefix frequency x number of in-RIBs that prefix is
heard over) [i=1..N, N = number of prefixes].

If someone has a router with 10 copies of the full routing table, and
the median rate is 1/day, then this will be approximately 10 x
(routing table size) per day.
The routing table in the DFZ is about what, 350-400k? That would be
roughly 4M/day, or 50/sec.

Even modest border routers, for multi-homed networks (two upstreams
and significant local peering), that could easily be 1M+/day or
12+/sec.

On top of everything else generated by churn, which in the case of a
leaf router is 2-3/sec.

The basic principal is, unlike churn, where the peak amplitude is an
issue, this is pervasive, affecting every received prefix over every
link on which it is received, even when routing is stable.

Brian

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Nov 2011 00:46:13 -0500

> From: Brian Dickson [mailto:[email-masked]]
> Sent: Tuesday, November 15, 2011 12:16 AM

> It would be best to stay within the realm of facts.

[WEG] To clarify, the issue got conflated between the impact of simple beacon updates and the case where an actual route update comes in, but the signature is processed after the update is processed, potentially triggering a route recalc.
Route recalc does mean 2x the processing, WHEN it happens, but it will not happen in all cases. My apologies for being unclear.

Wes George

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 20:31:09 -0500

>>> I can not believe that it will be 2X.

It will likely be worse.

> change, but the signature will not.

So you are arguing that if you have two signed paths, and you receive a
new unsigned path replacing one of the signed paths --in fact, replacing
the signed path that is currently your bestpath-- you would keep using
the old bestpath even though it has a lower security preference than the
other existing signed path.

How does a system that says, "replay attacks are okay, you may accept
unsigned information over signed information, it's okay if timers are
expired, it's okay if AS' in the middle of that path can be attacked
through replays, etc.," really provide security? I'm seeing a lot of
work for little to no net gain here.

:-)

Russ

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 15 Nov 2011 21:50:04 -0500

How to treat unsigned paths is a matter of policy.
This is up to each provider to configure as he pleases.
I would prefer a signed route over an unsigned one,
but prefer an unsigned route over no route.
For more security sensitive routes, you may prefer no route
over an unsigned route. It's up to you.

I am saying, do not delay the regular updates.
Send the signatures in a separate connection.

A performance sensitive implementation does both
the signing and the checking in a low priority
process anyway. That results in two updates, one
with the regular update followed by a copy with
the signature.

I am saying to put that signature into a separate
connection, so as not to delay the higher urgency
regular updates.

--
Jakob Heitz.

> Of Russ White
> Sent: Tuesday, November 15, 2011 5:31 PM
> To: [email-masked]
> > If it replaces no path, then the regular update will produce a
> > bestpath change, but the signature will not.
> 
> So you are arguing that if you have two signed paths, and you
> receive a new unsigned path replacing one of the signed paths --in
> fact, replacing the signed path that is currently your bestpath--
> you would keep using the old bestpath even though it has a lower
> security preference than the other existing signed path.
> 
> How does a system that says, "replay attacks are okay, you may
> accept unsigned information over signed information, it's okay if
> timers are expired, it's okay if AS' in the middle of that path can
> be attacked through replays, etc.," really provide security? I'm
> seeing a lot of work for little to no net gain here.
> 
> :-)
> 
> Russ

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 22:11:02 -0500

> How to treat unsigned paths is a matter of policy.

Correct --but if you're going to, by default, not treat signed routes as
primary over unsigned ones, what's the point of the signatures?

> over an unsigned route. It's up to you.

In who's opinion? Yours or the originators? Since this is all about
making certain you're following the intent of the originator, I'd think
the originator's opinion is the one that counts here, not yours.

> connection, so as not to delay the higher urgency

Sorry, but I don't see how this really helps... What if I'm really lazy,
and just never process the signatures? What if I use a route for several
minutes, then suddenly realize it's not a valid route? Is it okay to
steal 500 people's usernames and passwords, and not 1000? Time is an
important element in routing systems, both for convergence and security.

:-)

Russ

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 15 Nov 2011 22:29:40 -0500

> From: Russ White [mailto:[email-masked]]
> Sent: Tuesday, November 15, 2011 7:11 PM
> 
> Sorry, but I don't see how this really helps... What if I'm really
> lazy, and just never process the signatures? What if I use a route
> for several minutes, then suddenly realize it's not a valid route?
> Is it okay to steal 500 people's usernames and passwords, and not
> 1000? Time is an important element in routing systems, both for
> convergence and security.

I don't understand how BGPSEC is going to prevent anyone
stealing passwords. To me, all this talk of BGP validation
preventing hacks is a load of fantasy.

The only utility I can see is in protecting reachability.
The only problem I can imagine with installing an unsigned
route is that the destination becomes unreachable. If it
was unreachable to begin with, no harm is done.

--
Jakob Heitz. x25475. 510-566-2901

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 22:32:14 -0500

> was unreachable to begin with, no harm is done.

When you're protecting reachability, what are you protecting? Whether or
not someone can reach something. I assume that the "something" you're
trying to protect reachability to would/must include things where you
enter your password.

Hence, I look at this entire problem a little differently than simply
trying to enforce a small subset of policies, or as a theoretical
exercise... If we can't prevent real world consequences with this work,
then --why are we doing it?

:-)

Russ

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 15 Nov 2011 22:38:27 -0500

> Sent: Tuesday, November 15, 2011 7:32 PM
> To: Jakob Heitz
> Cc: [email-masked]
> Subject: Re: [sidr] Burstiness of BGP updates
> 
> 
> > The only problem I can imagine with installing an unsigned route
> is
> > that the destination becomes unreachable. If it was unreachable to
> > begin with, no harm is done.
> 
> When you're protecting reachability, what are you protecting?
> Whether or not someone can reach something. I assume that the
> "something" you're trying to protect reachability to would/must
> include things where you enter your password.
> 
> Hence, I look at this entire problem a little differently than
> simply trying to enforce a small subset of policies, or as a
> theoretical exercise... If we can't prevent real world consequences
> with this work, then --why are we doing it?

We are doing it to protect reachability.

We are not protecting your password in clear text on the internet.

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 22:52:29 -0500

> We are not protecting your password in clear text on the internet.

I would challenge you to find any statement of mine where I said this
work is about "protecting your password in clear text on the internet."

"The Internet" is not an abstract collection of "things." It is a set of
reachable destinations. People go to those destinations to transact
business. If people reach the wrong destination, they transact business
with the wrong party. If a "security system," can't protect me from
reaching the wrong destination on a system designed to get me to the
right destination, then the security system is, generally speaking, useless.

I do wish I didn't have to have users connected to the networks I design
and work on --it would really make my life much simpler. But then again,
no users, no network, right? I think we sometimes get so lost in the
theory that we forget what networks are actually _for_.

:-)

Russ

---

From: Shankar K A <[email-masked]>
Date: Wed, 16 Nov 2011 05:06:29 +0100

I would prefer signed updated over unsigned updates as Jakob suggested.
But strictly speaking, IMO we should only accept signed updates, because it's the number of AS that we add in the update that we are protecting.
By accepting unsigned update we may accept unprotected path information. 

- Shankar K A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jakob Heitz
Sent: Wednesday, November 16, 2011 9:08 AM
To: Russ White
Cc: [email-masked]
Subject: Re: [sidr] Burstiness of BGP updates

> exercise... If we can't prevent real world consequences with this 
> work, then --why are we doing it?

---

From: Russ White <[email-masked]>
Date: Tue, 15 Nov 2011 23:39:36 -0500

> By accepting unsigned update we may accept unprotected path information. 

Precisely my point.

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 15 Nov 2011 23:39:52 -0500

> By accepting unsigned update we may accept unprotected path information.

it really is, or was, the intent to permit operators of networks to
decide this on their own. They MAY want to prefer
unsigned/unknown/notfound/naked prefixes for certain things. It's
really not up to us to say, is it? we can SUGGEST that they SHOULD
prefer signed over unsigned, but in the end of the day it's on them.

---

From: Shankar K A <[email-masked]>
Date: Wed, 16 Nov 2011 05:50:39 +0100

I agree that we cannot force this. However, it should be ok if we can specify these policies as best practices or recommendations.

- Shankar K A

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Wednesday, November 16, 2011 10:10 AM
To: Shankar K A
Cc: Jakob Heitz; Russ White; [email-masked]
Subject: Re: [sidr] Burstiness of BGP updates

> By accepting unsigned update we may accept unprotected path information.

it really is, or was, the intent to permit operators of networks to decide this on their own. They MAY want to prefer unsigned/unknown/notfound/naked prefixes for certain things. It's really not up to us to say, is it? we can SUGGEST that they SHOULD prefer signed over unsigned, but in the end of the day it's on them.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 16 Nov 2011 00:06:09 -0500

> Sent: Tuesday, November 15, 2011 8:40 PM
> To: Shankar K A
> Cc: Jakob Heitz; [email-masked]
> > But strictly speaking, IMO we should only accept signed updates,
> because it's the number of AS that we add in the update that we are
> protecting.

What is the value of that?
Does this now allow me to send passwords in the clear on the internet?

--
Jakob Heitz.

---

From: Shankar K A <[email-masked]>
Date: Wed, 16 Nov 2011 06:09:28 +0100

You cannot use BGP to enable you to send such messages. There could be million other ways to do what you are saying. After this, there is one less chance. That's all.

- Shankar K A 

-----Original Message-----
From: Jakob Heitz 
Sent: Wednesday, November 16, 2011 10:36 AM
To: Russ White; Shankar K A
Cc: [email-masked]
Subject: RE: [sidr] Burstiness of BGP updates

--
Jakob Heitz.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 16 Nov 2011 00:29:29 -0500

Understanding the "real" threats, and worked, real-world examples, is important.

I cannot believe anyone in this WG would be ignorant of things like this:

http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

Does this illustrate the importance of not only validating origins,
but also only using signed prefixes if you are participating in
BGPsec?

And the importance of minimizing or eliminating the ability of someone
currently off-axis, from becoming on-axis?

Preferably eliminating exploitation of lack of proper trust boundaries
WRT leakage (reannouncement permissions)?

(It is difficult to change from off-axis to on-axis without "leaking"
- the only time "leaking" isn't strictly required, is when already
on-axis.)

Jakob, please view the whole presentation above. It was more than 3
years ago... You should have heard of it by now.

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 16 Nov 2011 00:35:03 -0500

> http://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf

this is referred to several times in Stephen Kent's presentations
actually, and in Randy's presentations to RIR/etc folk.

> but also only using signed prefixes if you are participating in

sure, but if your customer forgets to pay a bill, calls you up and
(post proper 'this is the customer' authentication) says: "Hey, srsly,
I forgot, checks in the mail to ARIN, can you accept our route pls?"

you may be willing to do same, you may also be willing to do this in
the case of internal services routes that you don't actually want
externally visible.

> currently off-axis, from becoming on-axis?

sure, see referenced slides from Kent. (and bgpsec as spec'd would
squish pilosov/kapella)

> WRT leakage (reannouncement permissions)?

re-announcement is 'harder' since it's not clear if NTT is supposed to
be passing cogent aol's routes or not, is it?

> years ago... You should have heard of it by now.

hopefully everyone's read it :)

-chris

---

From: Brian Dickson <[email-masked]>
Date: Wed, 16 Nov 2011 00:56:24 -0500

> I forgot, checks in the mail to ARIN, can you accept our route pls?"

I was using "only" in contrast to Jakob, who was suggesting having the same
prefix and as-path, both signed and unsigned, be used, and in fact the
unsigned used prior to validating the signatures.

Basically, if you have BGPsec enabled with a given peer, you might get
a combination of signed and unsigned from that peer - but for a given prefix,
you MUST only get one or the other. Invalid-sig != unsigned.

Accepting unsigned as a "fast" short-cut is insane, frankly.

Signed prefix processing actually needs to "block" until the signature
result is received.
On a per-prefix basis, of course.

This is why having your cache very close is important, as are any
possible implementation
optimizations or design considerations that improve signature
processing/capacity/timeliness.

> the case of internal services routes that you don't actually want

Sure - and locally significant signatures/trust-anchors are very
important for just such an occasion.
(For any convenient value of "local", it should be noted. City, zip
code, province, continent, building, whatever.)

> be passing cogent aol's routes or not, is it?

Agreed - I can't be specific on exactly when, but expect me to present something
"real soon now" on a nuts-and-bolts level of how to do this. Maybe a
month, maybe two.

Brian

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 16 Nov 2011 01:03:23 -0500

> code, province, continent, building, whatever.)

yup, agreed.

> "real soon now" on a nuts-and-bolts level of how to do this. Maybe a

look forward to it!
I wonder actually if some on-going survey of routing data could help
to inform when a 'leak' happens... I suspect this is what cyclops/etc
are doing (identifying normal 'status' of routes between networks),
I'm not clear on how useful this would be in the end though, my
experience with cyclops/etc haven't been useful so far :(

-chris

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 19:48:48 -0500

> Does this now allow me to send passwords in the clear on the internet?

1. Protection means to know that the site you intend to get to is
actually the site you reach.
2. Part of this protection requires protecting the routing system.
3. If you don't protect the routing system, then people are vulnerable
to various attacks against their accounts on web sites they believe they
can trust.

Is it really that complex?

What I see so far is:

1. SIDR has ruled out "knowing intentions." Without knowing intentions,
you can't very well compare what you know to what you think you should know.

2. SIDR has ruled knowing what the actual state of the system currently
is (well, at least we know what the system might have looked like a week
or two ago, and maybe a new route has come along that isn't signed but
that I should prefer over an already existing signed route, or
perhaps...) If you don't know what the system is supposed to look like,
then you don't know whether or not what you see is valid.

Can you tell me what it is SIDR is actually securing?

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 16 Nov 2011 20:17:51 -0500

> Is it really that complex?
(not really aimed at russ)

is the never-ending rathole of 'what are we trying to protect' really
required on-list? I think the most simple case we care about is: "Is
the routing system telling us what it is supposed to?" Or rephrased
some: "Did the route injected at the source get faithfully reproduced
down the line to the receiver?"

I'd hope that leads us safer packets and traffic for all users of the
network, but really debating if plaintext passwds are safe is far too
deep in the weeds I think.

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 20:27:05 -0500

> down the line to the receiver?"

But SIDR is currently saying that as long as the route was injected
correctly a week or two ago, "it's all good." Sorry, but I disagree.
It's not "all good."

Security compares what the state currently looks like to what the state
should look like. If "what the state should look like" could be a week
old, and you've ruled out "intentions" (which really rules out what the
system should look like), then you've ruled out "security."

Russ

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2011 09:44:15 +0800

> should look like.

the problem is how does one know what the state of the system 'should'
look like?

randy

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 20:50:03 -0500

> the problem is how does one know what the state of the system 'should'

My understanding has always been that the point of any security system
is provide a secure and verifiable indication of what the system should
look like in order to compare current events against that standard. For
instance, could you secure an airport without some idea of who should be
where and when they should be there? Or your house?

How do you detect "attack traffic," in your network? By seeing things
that shouldn't be there. If you don't know what it's supposed to look
like, how can you tell what's not supposed to be there? In the same way,
how can you "secure" the routing system without knowing what routes
should be where --in other words, without knowing what everyone intended
to advertise? Saying "it's okay if we know what it was supposed to look
like a week ago," doesn't, IMHO, solve the problem at hand.

:-)

Russ

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 02:57:42 +0100

Hi Russ,

I think the current intention is to secure the network on the basis of 
giving each prefix a badge and just check it at entrance door readers to 
each AS.

If it is allowed in it enters if it is determined by the security 
back-end to be evil it is denied.

I am not sure if you actually need to know who should be in or not at 
any given time if the backend provides the correct rules based on the 
badge readings. Of course the assumption is that HR distributed the 
badges correctly in the first place ;)

R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2011 10:01:04 +0800

hi russ,

> look like in order to compare current events against that standard.

you have been saying that for years.  and i understand your point.  what
i have never understood is *how* you can tell how things 'should' be.

so the current sidr proposals are for what we *know how to do.*  they
are not perfect, but they are a radical improvement on the current
state.

i am very open to clue on how to rigorously define how things 'should'
be, especially if it is rigorously testable given real world
constraints.

randy

---

From: Brian Dickson <[email-masked]>
Date: Wed, 16 Nov 2011 21:04:46 -0500

On Wed, Nov 16, 2011 at 8:57 PM, Robert Raszuk <[email-masked]> wrote:
> If it is allowed in it enters if it is determined by the security back-end
> to be evil it is denied.

That analogy works for packets. It doesn't work for routes.

Routing sucks. Routes attract traffic.

I would instead say, it's like a work order to install a window or door.

That someone with a work order got as far as they did, is either proof
that they are supposed to be there, or a security vulnerability, or
maybe both.

Signed work orders suggest that a window or door was requisitioned. It
doesn't necessarily confirm which wall it should go in - the one to
the next suite, the one to the vault, or the one to the street?

But, chasing analogies to their breaking point isn't necessarily constructive.

Yes, knowing what is intended is necessary if we want to provide
security, as opposed to merely vague assurance.

Given the amount of work expended thus far, taking the extra step
(which may not be large) is both advisable, and something IMNSHO
should be considered in-scope....

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 17 Nov 2011 03:10:58 +0100

Brian,

> should be considered in-scope....

Sorry if I missed it but what is this extra step ?

R.

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2011 10:16:00 +0800

> should be considered in-scope....

i think we all agree.  but talk is cheap.  send formal definitions of
intent and how to detect violations thereof.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 17 Nov 2011 11:07:08 +0800

> be, especially if it is rigorously testable given real world

Maybe this discussion could be viewed as a good motivation for revisiting the requirements draft.  It seems to me that these arguments (on both sides) could be viewed as the early stages of requirements analysis (RA).  If we can all get on the same page (or maybe into the same chapter) about what we want to protect, then we can talk about how to do it.  In the event we discover that we've carved out an unattainable requirement, we follow the exception back to RA and revisit the requirements.

Software engineering... :)

Eric

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2011 11:13:34 +0800

> Maybe this discussion could be viewed as a good motivation for
> revisiting the requirements draft.

don't require what you have no solid idea of how to achieve.

randy

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Nov 2011 22:25:31 -0500

>look like in order to compare current events against that standard.

The usual characterization of a secruity system is a set of mechanisms that
are intended to enforce a secruity policy. Only if the policy 
articulates what the system "should look like" would your definition 
be congruent.

Most security policies focus on aspects of system operation that are 
perceived as "secruity critical."  The WG charter articulates a 
security policy, focusing on origin validation and path authenticity. 
These aspects of routing security are visible and this avoid the more 
problematic question of what the system "should look like."

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 23:06:12 -0500

> don't require what you have no solid idea of how to achieve.

Maybe if someone actually laid out real requirements, someone,
someplace, could determine how to achieve most (if not all) of them. The
process SIDR has used is backwards --choose a solution, then build the
requirements around that solution. When problems arise, just change the
requirements so it's no longer a problem.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 23:27:35 -0500

> perceived as "secruity critical."  The WG charter articulates a security
> policy, focusing on origin validation and path authenticity. These
> aspects of routing security are visible and this avoid the more

Path authenticity is a check of precisely what?

What the AS Path should look like.

Once you put timers in there, and then do lazy verification, and then do
beacons, and then... You've left the realm of ensuring a received route
has a "valid" AS Path from the perspective of what the AS Path should
look like. It might have looked like that a week ago, but who knows what
it should look like right now?

As you even said:

> are intended to enforce a secruity policy.

A policy is what someone, someplace, intends. What someone intends is
simply an expression of "what the system should look like." You can't
get away from intent.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 23:32:30 -0500

> giving each prefix a badge and just check it at entrance door readers to

Don't treat routing updates as packets. Routing protocols are
distributed near real time databases, not applications that send and
receive packets.

> badges correctly in the first place ;)

But you see, that's intent.

What we're trying to do is infer undefined intent (because we won't
admit it's intent), from a rather loose and messy signature on the
packet, combined with some timers that are set so far away from real
time as to be almost useless (because it's too hard to secure route
removal in a signed packet system).

:-)

Russ

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 17 Nov 2011 14:03:30 +0800

> requirements so it's no longer a problem.

Totally agree w/ u here, Russ...

Randy, we are all arguing over what we think a secure routing system should do... It sounds like you (and your team?) have already decided what you think everyone's requirements are, but it's pretty plain to all that a fair number of people here in the wg do not agree.  One of the main reasons software systems begin with requirements analysis is precisely so that we can know if our solution meets our needs.  As I said before, if we wind up needing to rework our collective requirements, then so be it, but this process needs to be followed, not skipped.  Even your above comment has taken this out of order (skipping a requirement because you think you can't do it implies a design attempt); requirements come first... ;)

Eric

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Nov 2011 14:10:21 +0800

> The process SIDR has used is backwards --choose a solution, then build
> the requirements around that solution.

the bgpsec requirements document was started from the 2008 document
draft-ietf-rpsec-bgpsecrec-10

randy

---

From: Geoff Huston <[email-masked]>
Date: Fri, 18 Nov 2011 11:19:54 +1100

> draft-ietf-rpsec-bgpsecrec-10

That document never managed to reconcile the various views relating to
AS Path validation, so I'm unclear if you are citing this as a completed
activity, because to me it certainly appeared to be an incomplete piece
of work.

To be specific to quote from section 7 of this draft:

      AS_PATH Feasibility Check: The AS_PATH list may correspond to a
      valid list of autonomous systems according to the first
      verification category listed in the "Areas to Secure" Section
      above.  Further study will determine the extent to which this is a
      security requirement.

---

From: Tony Tauber <[email-masked]>
Date: Fri, 18 Nov 2011 09:08:37 -0500

As that old draft's author/editor (started as editor, ended up more as
author, with suggestions),
perhaps I can add some clarification to some of what's being re-hashed here.
It's likely many already understand it; some don't; some could be aided by
different wording.

Steve Kent takes the approach that working through the processing and
propagation of updates
and securing those operations to the spec.
The notion appears to me to be to model behavior based on discrete events
and the BGP FSM.

Russ White takes the approach that the overall deployed system is very
complex containing many
dimensions of variability including but not limited to time, topology, and
local practice/policy.
Following from that is a concern that, beyond a point, adding the
additional complexity being proposed
results in either no benefit or negative impact to the goals of the global
routing system.

Hopefully I've characterized things reasonably and this might help anyone
who's having
trouble following at home.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Nov 2011 15:31:59 +0100

Hello Tony,

 > Hopefully I've characterized things reasonably

Sincere apologies for critics, but observing this space as well as 
hearing voices of operators from all over the world IMHO you have not 
even stated the basic preludium to the problem at stake.

I think Russ is not just flaming that this is complex. The way I read 
what Russ is not afraid to say is that solutions in place are just not 
addressing the real BGP security issue.

If they would we do know (with around for most of us 20 years of 
internet deployments behind our belts) how to educate community to 
deploy globally any new useful functionality.

However the current proposal may very well address the Internet control 
issue rather then real internet security issue and this is the problem. 
This is something that non of the authors or implementors will ever 
admit is the objective here for a very obvious legal reasons.

Best,
R.

> As that old draft's author/editor (started as editor, ended up more
> as author, with suggestions), perhaps I can add some clarification to
> some of what's being re-hashed here. It's likely many already
> understand it; some don't; some could be aided by different wording.
>
> Steve Kent takes the approach that working through the processing
> and propagation of updates and securing those operations to the
> spec. The notion appears to me to be to model behavior based on
> discrete events and the BGP FSM.
>
> Russ White takes the approach that the overall deployed system is
> very complex containing many dimensions of variability including but
> not limited to time, topology, and local practice/policy. Following
> from that is a concern that, beyond a point, adding the additional
> complexity being proposed results in either no benefit or negative
> impact to the goals of the global routing system.
>
> Hopefully I've characterized things reasonably and this might help
> anyone who's having trouble following at home.
>
> Tony
>
> On Thu, Nov 17, 2011 at 7:19 PM, Geoff Huston<[email-masked]>  wrote:
>
>>
>>>> The process SIDR has used is backwards --choose a solution,
>>>> then build the requirements around that solution.
>>>
>>> the bgpsec requirements document was started from the 2008
>>> document draft-ietf-rpsec-bgpsecrec-10
>>
>> That document never managed to reconcile the various views relating
>> to AS Path validation, so I'm unclear if you are citing this as a
>> completed activity, because to me it certainly appeared to be an
>> incomplete piece of work.
>>
>> _______________________________________________ sidr mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/sidr
>>
>
>
>
> _______________________________________________ sidr mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/sidr

---

From: Tony Tauber <[email-masked]>
Date: Fri, 18 Nov 2011 09:53:28 -0500

On Fri, Nov 18, 2011 at 9:31 AM, Robert Raszuk <[email-masked]> wrote:

> This is something that non of the authors or implementors will ever admit
> is the objective here for a very obvious legal reasons.
>

What are these?  They are not "very obvious" to me.
I believe people can get biased and entrenched based on their personal and
professional stakes.
I'm not sure what "legal" thing you refer to.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 18 Nov 2011 16:01:54 +0100

Hi Tony,

> I'm not sure what "legal" thing you refer to.

Oh apologies .. I was under impression that we all following IETF alias 
as well as participate in global NOG/RIPE events.

As far as ietf alias see below:

-------- Original Message --------
Subject: Lawsuit against IETF/SIDR/RPKI? (fwd)
Date: Thu, 17 Nov 2011 12:06:48 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: [email-masked]

Anyone have more info on this?

Paul

---------- Forwarded message ----------
Date: Thu, 17 Nov 2011 10:34:54
From: Vesna Manojlovic <[email-masked]>
To: [email-masked]
Subject: Lawsuit against IETF/SIDR/RPKI?
X-Spam-Flag: NO

You've heard it here first ;-)

But it's still only a rumor...

(does any of you have more news about it?)

Aparently, few big carriers in the States are preparing a lawasuit 
against RPKI creators, since they are funded by US government, _and_ are 
mandating the system that the ISPs will need to implement... so - 
anti-trust suit?

Conflict of interests? etc...

I could only find some "old news" about this:
http://www.networkworld.com/news/2010/121510-feds-internet-routing-security.html

That's why it is very important to continue with the development of the
alternatives to the routing security...

BTW, I got a ticket for 28c3, so -- see you there!

Ciao,
Vesna

---

From: Tony Tauber <[email-masked]>
Date: Fri, 18 Nov 2011 11:09:00 -0500

Oh, an "obvious legal" rumor?  I'm too busy doing work to follow all those.
Has there been any follow up?
Please copy all that nonsense here also so everyone can be involved in
rumor-mongering.

Or else, please don't.

Tony

On Fri, Nov 18, 2011 at 10:01 AM, Robert Raszuk <[email-masked]> wrote:

> Oh apologies .. I was under impression that we all following IETF alias as
> well as participate in global NOG/RIPE events.
>
> Aparently, few big carriers in the States are preparing a lawasuit against
> RPKI creators, since they are funded by US government, _and_ are mandating
> the system that the ISPs will need to implement... so - anti-trust suit?
>
> http://www.networkworld.com/**news/2010/121510-feds-**
> internet-routing-security.html<http://www.networkworld.com/news/2010/121510-feds-internet-routing-security.html>
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Nov 2011 23:41:37 -0500

At 4:01 PM +0100 11/18/11, Robert Raszuk wrote:
>Oh apologies .. I was under impression that we all following IETF 
>alias as well as participate in global NOG/RIPE events.

The message in question reports a rumor, with no substantiation, so ...

Steve

---

From: Randy Bush <[email-masked]>
Date: Sun, 20 Nov 2011 10:54:42 +0100

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 22 Nov 2011 11:17:23 -0500

> Accepting unsigned as a "fast" short-cut is insane, frankly.

Why?
BGPSEC does not prevent route leaks (MITM)
BGPSEC does not prevent intercept
BGPSEC is not a panacea