Subject: Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system

From: "Montgomery, Douglas" <[email-masked]>
Date: Sat, 1 Dec 2012 10:17:48 -0500

On 11/30/12 4:19 PM, "Danny McPherson" <[email-masked]> wrote:

>
>On Nov 30, 2012, at 4:08 PM, Christopher Morrow wrote:
>
>> On Fri, Nov 30, 2012 at 3:11 PM, Danny McPherson <[email-masked]> wrote:
>>>> limits on its reaction time.   Certainly from my perspective, more
>>>>suited
>>>> to pre-publishing preventative data, then creating reactionary data.
>>> 
>>> And the state of the art in DDoS mitigation doesn't allow this, period.
>> 
>> it sure does, if there's a contract in place... it's the 'oh noz! now
>> we're under attack and need to bring in $DDOSPROVIDER!!' that isn't
>> covered.
>
>Right, IF there's a contract in place..
>
>Perhaps this new latency will drive folks to be more proactive..  not!
>:-)
>
>-danny

It is kind of interesting to think about this requirement - the ability to
need to announce a prefix from a new, previously unseen origin, driven by
a previously non-existant business relationship, anywhere in the world
with a moments notice ... This will be a challenge to any system that
where the users of resource certification information caches data from its
authoritative sources.

It is also interesting to consider that these requirements are basically
the requirements of a hijack, with the exception that some-where, at the
speed of light, some-one declared this one is "OK".

Not trying to be provocative (dialing that down in general would be a good
thing)  ... Just actually trying to think about this as a serious system
requirement.

Maybe we should have just put the ROA in the BGPSEC update!   Call up your
DDOS mitigation provider, give them the private key for your Address
Allocation .. And your done!  The new BGP update, contains the ROA.  That
is the authorization of the new origin moves at the same speed of the
updates that need it.

Just and idea.

Dougm

---

From: Bryan Weber <[email-masked]>
Date: Sat, 1 Dec 2012 10:48:14 -0500

I can think of several possible problems with sticking a ROA in a BGP update.

*) The crypto to validate the ROA must be performed. My third hand knowledge of this is that since this can be expensive the router vendors don't want to do this on the actual routers. Thus the reason for the repository caches in the first place. So this is not a technical reason as much as a real world reason.
*) Are ROAs sufficient?  What about BGP speaking server certificates or whatever other CMS objects end up being part of BGPSec? For the DDoS example a ROA might be sufficient, but would there be cases where other types of objects should be disseminated via update messages?
*) Can a BGP update accommodate the amount of extra data that would be required? 
*) Finally, an actual technical hurdle. In a hosted model, you might not have the private key for your address allocation. It may be protected and only live in memory on an HSM somewhere… And do you *really* want to share your private key with another company anyway?

Just my opinion, but I suspect that a party attempting a hijack would probably be more patient than a legitimate party. The hijacker would care more about being able to take over the traffic successfully as opposed to quickly I suspect. Quick would just be a bonus. The party being DDoS'd on the other hand has financial incentive to alleviate the attack as quickly as possible.

Just my 2 cents.

-Bryan

On Dec 1, 2012, at 10:17 AM, "Montgomery, Douglas" <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Dec 2012 07:36:41 +0900

> It is kind of interesting to think about this requirement - the
> ability to need to announce a prefix from a new, previously unseen
> origin, driven by a previously non-existant business relationship,
> anywhere in the world with a moments notice ... This will be a
> challenge to any system that where the users of resource certification
> information caches data from its authoritative sources.

it will be a 'challenge' to any system where a secondary data set is
being used to validate bgp, certificates, irr, smoke signals.

randy

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Dec 2012 09:04:53 -0500

> speed of light, some-one declared this one is "OK".

It's a route announcement in the system Doug, just like any other today.

> is the authorization of the new origin moves at the same speed of the

See, again, we're trying to start with solutions and deal with the imposition of an architectures reeking of 80s and early 90s baggage (i.e., PKI & SBGP-esque) and all their constraints, without recognizing why those systems are no longer favorable or why they weren't adopted in the first place!  Adding all this rigidity and ignoring systemic complexities you're introducing, while not address some pretty fundamental concerns (e.g., use of "expired data in RPKI", "lack of robustness in today's nation-state/cyber security landscape", doesn't deal with "leaks", downgrade attacks from algorithms, expired certificates, or unprotected attributes, latency in RPs being aware of new information", etc...

Slamming a hierarchical PKI into a distributed routing system is what didn't work in the 90s, agreed.  I still contend that work in SIDR would be more effective if we'd focus on a general Internet number resource certification system and decouple precisely how it's employed in the routing system (or other applications, e.g. SAVI, SEND, whatever..).  Here, we're focusing on routed resource certification to control what's routed on the Internet, not how or if it's "secure", or the lack of responsiveness of the system.

At least employing some pub/sub models for new object availability, rather than requiring CAs and RPs to discover all new information about objects in the system, would be useful in this decade.

Of course, 

-danny

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Dec 2012 09:39:22 -0500

> being used to validate bgp, certificates, irr, smoke signals.

And precisely why expecting relying parties to "discover" this new information through periodic full infrastructure fetch and iteration is fundamentally broken.

-danny

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 3 Dec 2012 09:40:52 -0500

Let's not pick apart the strawman details of an abstract idea.  One could
imagine aspects of an approach that only adds one sig to an udpate, signed
by the prefix owner, not the first hop AS .. I.e., not an entire ROA CMS
object.  One could imagine this as and optional way of doing this for
emergency announcements, with the existing approach being done for the
vast, vast majority of updates, etc.

The real high level point is one way of dealing with a requirement where
authorization must move at the speed of updates, is to include the
authorization in the update, when necessary.  Clearly that will have trade
offs.

The points you make below would have to be considered *if* someone
actually fleshed out that idea ...

dougm

On 12/1/12 10:48 AM, "Bryan Weber" <[email-masked]> wrote:

>*) The crypto to validate the ROA must be performed. My third hand
>knowledge of this is that since this can be expensive the router vendors
>don't want to do this on the actual routers. Thus the reason for the
>repository caches in the first place. So this is not a technical reason
>as much as a real world reason.
>*) Are ROAs sufficient?  What about BGP speaking server certificates or
>whatever other CMS objects end up being part of BGPSec? For the DDoS
>example a ROA might be sufficient, but would there be cases where other
>types of objects should be disseminated via update messages?
>*) Finally, an actual technical hurdle. In a hosted model, you might not
>have the private key for your address allocation. It may be protected and
>only live in memory on an HSM somewhereŠ And do you *really* want to
>share your private key with another company anyway?
>
>Just my opinion, but I suspect that a party attempting a hijack would
>probably be more patient than a legitimate party. The hijacker would care
>more about being able to take over the traffic successfully as opposed to
>quickly I suspect. Quick would just be a bonus. The party being DDoS'd on
>the other hand has financial incentive to alleviate the attack as quickly
>as possible.

That is if the hijack needed a persistent address.   If it just needs to
be on the net long enough to do something specific, then maybe not.

dougm

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 3 Dec 2012 10:14:52 -0500

>It's a route announcement in the system Doug, just like any other today.

Sure.  But my point was typically today we don't do general filtering of
unauthorized originations.  If we were to accept that as a goal, then the
only difference in the emergency DDoS mitigation origination and a hijack
is a phone call.  How to represent that phone call in the system at the
speed of BGP update propagations is the point.

>See, again, we're trying to start with solutions and deal with the
>imposition of an architectures reeking of 80s and early 90s baggage
>(i.e., PKI & SBGP-esque) and all their constraints, without recognizing
>why those systems are no longer favorable or why they weren't adopted in
>the first place!  Adding all this rigidity and ignoring systemic
>complexities you're introducing, while not address some pretty
>fundamental concerns (e.g., use of "expired data in RPKI", "lack of
>robustness in today's nation-state/cyber security landscape", doesn't
>deal with "leaks", downgrade attacks from algorithms, expired
>certificates, or unprotected attributes, latency in RPs being aware of
>new information", etc...
>
>Slamming a hierarchical PKI into a distributed routing system is what
>didn't work in the 90s, agreed.  I still contend that work in SIDR would
>be more effective if we'd focus on a general Internet number resource
>certification system and decouple precisely how it's employed in the
>routing system (or other applications, e.g. SAVI, SEND, whatever..).
>Here, we're focusing on routed resource certification to control what's
>routed on the Internet, not how or if it's "secure", or the lack of
>responsiveness of the system.

Address allocation is strictly hierarchical and distributed in the
Internet today.  It seems that any resource certification system would
have to reflect that fact.

>
>At least employing some pub/sub models for new object availability,
>rather than requiring CAs and RPs to discover all new information about
>objects in the system, would be useful in this decade.

I was trying to talk about the suggested requirement of near real-time
authorization of route updates, divorced from any specific mechanisms.
OK, I know I suggested a mechanism.  But all I really meant was the
observation that the only real way to get authorization to move at the
speed of updates, is to carry the auth data in the update.  If we want to
relax that a bit ... But still be more responsive than existing proposed
mechanisms, we would need modified/different distributions mechanisms for
authorization data.

>-danny

Obviously,

Dougm

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 6 Dec 2012 12:57:19 -0500

> And precisely why expecting relying parties to "discover" this new information through periodic full infrastructure fetch and iteration is fundamentally broken.

+1

Eric

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2012 13:09:10 -0500

>> And precisely why expecting relying parties to "discover" this new information through periodic full infrastructure fetch and iteration is fundamentally broken.

+2

Russ

-- 
<><
[email-masked]
[email-masked]