Subject: [sidr] the need for speed

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2012 14:48:02 -0500

I am trying to understand why our fellow engineers at Verisign are
obsessed with global propagation of RPKI data on the order of a few
minutes.  Then a friend hit me with the clue by four.  It's about third
party DDoS (and other attack) mitigation.

When an NTT (just an example) customer is attacked, the customer can
request that their upstream sink and scrub the traffic as it naturally
passes through NTT.  NTT passes the scrubbed traffic on to the customer,
and that's that.

But, when the customer's upstream does not provide such services, or the
customer has other reasons for not using the upstream service, they can
buy the scrubbing service from a third party, e.g. Verisign.  Verisign
will announce the customer's prefix(es) from a Verisign AS, receive the
traffic, scrub it clean, and send the cleaned traffic to the customer,
often via a tunnel.

Well and good, except Verisign is announcing someone else's prefix, a
basic violation of BGP origination validation.  Naturally, the customer
who contracts to Verisign for this service issues a ROA for the
prefix(es) to the Verisign AS, and it is not a violation, all is serene.

But what if Verisign wants to take on a new customer in panic "Help, I
am being attacked and will pay you a lot of money to fix this?"  The
time for the fix is dependent on how quickly a new ROA for the victim's
prefix(es) can propagate.

Alternatively, the victim could pull their normal ROA(s) for their
prefix(es) and the world would get NotFound and believe Verisign's
announcement(s).  But this too relies on quick propagation of RPKI data.

Observe that this is a problem in origin validation, i.e.  what is being
deployed today.  The RFCs are published, the code is in the routers, ...
the horse has left the barn.

Yet another item to go into the display case of security vs. utility.
Ah well.  But I sympathize with Verisign's business case and have no
desire to whack it.  And I assume others think similarly.

There is this little problem.  Today, the Internet has no technology for
reliable global fast distribution of a database.  No, DNS is not the
answer.  But please have that argument on a different thread.  The only
thing of which I am aware is Google's Spanner [0], which is a brilliant
piece of work.  But it is not lightweight (e.g. True Time), is
proprietary, is likely considered very secret sauce, and even Google
lists it as research as opposed to beta :)

IMIHO, this is a *really* interesting area for research, though I
suspect sidr is not the place to conduct it.  But it's research, not
something we can paint on today.  So we are left with propagation on the
order of a very few hours, AKA 'human time', and our discussions of how
to reduce load on CAs so we can query them more frequently.

randy

---

[0] - http://research.google.com/archive/spanner.html

---

From: "Borchert, Oliver" <[email-masked]>
Date: Tue, 18 Dec 2012 15:29:29 -0500

One solution here is that the mitigator either prepends the victims AS (works with "origin only") including the downside that the path is one hop longer. But hey, better than nothing. For origin + path validation the victim creates a bgpsec peering with the mitigator and signs the path. This can be done pretty easily I guess.
This might not be the most effective solution but IMHO it works  ;-)

Oliver
-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Tuesday, December 18, 2012 2:48 PM
To: sidr wg list
Subject: [sidr] the need for speed

I am trying to understand why our fellow engineers at Verisign are obsessed with global propagation of RPKI data on the order of a few minutes.  Then a friend hit me with the clue by four.  It's about third party DDoS (and other attack) mitigation.

When an NTT (just an example) customer is attacked, the customer can request that their upstream sink and scrub the traffic as it naturally passes through NTT.  NTT passes the scrubbed traffic on to the customer, and that's that.

But, when the customer's upstream does not provide such services, or the customer has other reasons for not using the upstream service, they can buy the scrubbing service from a third party, e.g. Verisign.  Verisign will announce the customer's prefix(es) from a Verisign AS, receive the traffic, scrub it clean, and send the cleaned traffic to the customer, often via a tunnel.

Well and good, except Verisign is announcing someone else's prefix, a basic violation of BGP origination validation.  Naturally, the customer who contracts to Verisign for this service issues a ROA for the
prefix(es) to the Verisign AS, and it is not a violation, all is serene.

But what if Verisign wants to take on a new customer in panic "Help, I am being attacked and will pay you a lot of money to fix this?"  The time for the fix is dependent on how quickly a new ROA for the victim's
prefix(es) can propagate.

Alternatively, the victim could pull their normal ROA(s) for their
prefix(es) and the world would get NotFound and believe Verisign's announcement(s).  But this too relies on quick propagation of RPKI data.

Observe that this is a problem in origin validation, i.e.  what is being deployed today.  The RFCs are published, the code is in the routers, ...
the horse has left the barn.

Yet another item to go into the display case of security vs. utility.
Ah well.  But I sympathize with Verisign's business case and have no desire to whack it.  And I assume others think similarly.

There is this little problem.  Today, the Internet has no technology for reliable global fast distribution of a database.  No, DNS is not the answer.  But please have that argument on a different thread.  The only thing of which I am aware is Google's Spanner [0], which is a brilliant piece of work.  But it is not lightweight (e.g. True Time), is proprietary, is likely considered very secret sauce, and even Google lists it as research as opposed to beta :)

IMIHO, this is a *really* interesting area for research, though I suspect sidr is not the place to conduct it.  But it's research, not something we can paint on today.  So we are left with propagation on the order of a very few hours, AKA 'human time', and our discussions of how to reduce load on CAs so we can query them more frequently.

randy

---

[0] - http://research.google.com/archive/spanner.html
_______________________________________________
sidr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sidr

---

From: Dongting Yu <[email-masked]>
Date: Tue, 18 Dec 2012 13:24:09 -0800

[apologies if I am sending this multiple times, having trouble with replying]

A concept that could be borrowed from DNS side is the ability for
anyone to go from the top and skip the cache(s) on an ad hoc basis.
Perhaps we need a similar capability here, for anyone to query from
the top. This way, a new announcement can (for example) carry a flag
that says "this may look invalid but if you skip the cache you will
see that it is", and suggests the receiving party to validate it from
the top.

Of course, two things will soon follow: some will always ask others to
skip the cache, which would defeat the purpose of caching (but I would
argue that it is not hard to figure out who are wasting others'
bandwidth and cpu, by comparing the non-cached versions as requested
and the cached versions), and this mechanism itself can be used to
launch a DDoS (to which I would argue the RIRs already has enough
resources to handle it, or some tricks can be perhaps applied to make
this problem less significant in the first place).

Dongting

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 18 Dec 2012 16:52:14 -0500

> anyone to go from the top and skip the cache(s) on an ad hoc basis.

stop... no.

The architecture as laid out is, from 'roa creator' to 'roa consumer', roughly:
  A publication point (nominally one per roa-creator)
  B gatherers (nominally one per roa-consumer)
  C internal-cache-systems (some number per roa-consumer)
  D routers

(yes, there is the iana->rir part of the tree
 yes, there are are more than just ROAs in the repositories)

So, the part that Randy and Danny and Eric are talking about is, as
far as the global system, is the A -> B conversation. Once you get
beyond B (to C and D) the problem is entirely inside some operator's
network and nothing on the outside matters.

Essentially the problem here is distribution of 10k of data to ~40k
endpoints (today, it'll grow tomorrow, fine) in ~2 mins time (or 5
mins or 10 mins or ... someone draw a line in the sand so we know what
the target is)

> see that it is", and suggests the receiving party to validate it from

at the router? no, don't do that.

> skip the cache, which would defeat the purpose of caching (but I would

once you have QOS, everything is EF!

> resources to handle it, or some tricks can be perhaps applied to make

do they?

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Dec 2012 17:03:00 -0500

Adding to Oliver's suggestion, it will be even more effective if, in the "origin only" case, 
the mitigator announces a slightly more specific (e.g., two /17s  for a /16) 
if the maxlength of the victim's existing ROA permits it (of course, victim’s AS is inserted 
as the origin AS as suggested). 
More specific wins, so the downside of one hop longer path length goes away.  

And in the full path validation case, the victim forward signs a more specific 
(if permissible by existing ROA) to the mitigator. The victim also sets pCount = 0 for this update.

Sriram

> From: [email-masked] [[email-masked]] On Behalf Of Borchert, Oliver [[email-masked]]

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Dec 2012 17:09:40 -0500

> party DDoS (and other attack) mitigation.

It's not just about this, that's certainly AN example.  Operators can envision lots of reasons why it'd be a good idea for the routing system to converge rapidly.  How many do you need?

> traffic, scrub it clean, and send the cleaned traffic to the customer,

Thanks for the explanation, I'm glad you took the time to _listen to operators about some of the ways of doing this.

> basic violation of BGP origination validation.  

Actually, it's not a violation of anything - it's their intent - which is what this all boils down to.  It's only a violation if your system doesn't model intent and assumes it knows something is a violation... It's the same policy that's reflected in your ROA, I'm just not captive to that today.

It's also by default how routing works today, as you well know...

> Naturally, the customer

Actually, it's not.  We don't know or care about ROAs today on the Internet.

> announcement(s).  But this too relies on quick propagation of RPKI data.

And opens the floodgates for downgrade attacks in this very heavy system you've been envisioning for over a decade, downgrade attacks that all the folks building these systems don't really seem to care about.

"Just fail open, you're no worse off than you are today" -- except that I have a bunch of new dependencies with 10x spend on routers and network engineers to debug RPKI and BGPSEC in order to route things - all for not.  

Tell a bank that - you've upgraded you security system and it costs 10x, but if there's a problem, just fail open, folks can still get money.

> the horse has left the barn.

Hah, nice..  Glad you're considering the requirements now that your gerbil has left the barn!

> Yet another item to go into the display case of security vs. utility.

Right, you've designed something that doesn't even fix leaks - which many operators believe are an operational security problem and they happen by default (e.g., the last big routing security snafu we've seen, and go read GROW if you disagree), slows routing convergence on the Internet to hours or days at the least (from double digit seconds today), introduces lots of new external system dependencies (e.g., RIRs, whom YOU say have no operational clue), removes all the scaling properties of BGP over the past 2 decades (adds periodic updates, breaks packing, order magnitude larger updates, etc..), and you say if there's problems, just fail open (i.e., downgrade attacks).  You just admitted that operators can't change keys on two ends of a transport connection, and in the next breath you tell me how an Internet-scale system that requires global coherency for verification objects for every prefix in the entire system across every BGP router and RPKI is going to work, all on the backbone of rsync?

> desire to whack it.  And I assume others think similarly.

How kind of you...

> lists it as research as opposed to beta :)

Right, so we should bolt PKI into your heap of rsync cruft onto the routing system to solve what problem?  Yet another item to go into the "and Randy Bush came down from the mountain, with two tablets in hand, to graciously bestow again upon all the operational monkeys clue from a superior galaxy far away, under the auspices of operator but funded by the USG, with a new system aimed to control what's routed on the Internet, how operators route and configure their networks and what external entities they're captive to - who cares if it's routed securely!, he proclaimed, I WILL EMPLOY RSYNC AND BOLT PKI ON BGP, it will be my legacy, youngsters, I WON, so take your requirements to the university, this is the iRBtf!"  The Internet was sad.

> to reduce load on CAs so we can query them more frequently.

Requirements require research, indeed...  It would have been good if we started here, rather than with SBGP-renamed and slamming RPKI directly into routers, it's just plain silly.  You should visit the work in GROW on why IRRs are challenged, or why leaks ARE operational AND security problems.

I think if you built general purpose Internet number resource certification and considered why things like the IRRs have had challenges, and why there should be autonomy in today's Internet operations, you'd be a lot better off...  Instead, you built routed resource certification through an RPKI introducing new control points and made RIPv1 scale look like a panacea compared to RPKI-enabled BGPSEC, and muddied it all with the likes of random subjects, and then fixed with ghostbusters records, and grandparenting for more control points, and snail-paced convergence where relying parties have to discover everything new in a global system with potentially tens of thousands of publication points, and and increased attack surfaces and inter-domain churn orders or magnitude - and you couldn't even fix leaks, which happen by default, and which you're still going to need to fix with IRRs...

Randy, you've done a fine job socially engineering this work through the IETF, I'll give you that!

-danny

EVIL_OPERATOR: Just waiting for a call from one of the RIRs to engage us in mitigating DDoS attacks to their repositories; or for the opportunity to operationalize an overly complex system that folks are captive to - wohoo!

---

From: Ross Anderson <[email-masked]>
Date: Tue, 18 Dec 2012 22:10:28 +0000

So to mitigate an attack you conduct another one ...

Ross

On 18/12/2012, Sriram, Kotikalapudi <[email-masked]> wrote:
>> One solution here is that the mitigator either prepends the victims AS
>> (works with "origin only") including the downside that the path is one hop
>> longer. But hey, better than nothing. For origin + path validation the
>> victim creates a bgpsec peering with the mitigator and signs the path.
>> This can be done pretty easily I guess.
>

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Dec 2012 18:24:10 -0500

Since the intent is good, it is not an “attack” (at least as far as the mitigator and the victim are concerned). 
In BGPSEC (i.e. the path validation case), the proposed solution (below) is clearly not even an apparent attack. 
The victim (customer) is intentionally propagating a signed update to a service provider (the mitigator). 
The DDoS mitigation works (continues to work like it does today) without having to create/propagate new RPKI objects.
  
Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ross Anderson [[email-masked]]
Sent: Tuesday, December 18, 2012 5:10 PM
To: Sriram, Kotikalapudi
Cc: Borchert, Oliver; Randy Bush; sidr wg list
Subject: Re: [sidr] the need for speed

Ross

---

From: Russ White <[email-masked]>
Date: Tue, 18 Dec 2012 19:10:33 -0500

> party DDoS (and other attack) mitigation.

In other words, when you can't provide a technical argument, it's
easiest just to jump to the ad hominem attacks...

> the horse has left the barn.

The horse that leaves the barn too soon will quickly find itself on
cobblestones.

Let me turn this around for you.

That you think security should not mirror the table at the speed of the
table tells me that you're not really interested in what should happen
--which needs to lead what actually happens to be a useful piece of
information-- but in what has happened.

So, should we imply from this what your business case is, where you
intend to make money off of this work, and attack you for that
implication? Or what the RIR's business case is, and where they make
their money?

Or should we stick to technical problems and realistic solutions?

Most effective security, as I said above, tells me about intent --which
means that notification of changes in intent must run as fast as intent
changes. In routing, intent changes as fast as the table changes, not
much slower. It's not so much that humans move quickly, it's that there
are so many of them moving at one time that is the bothersome piece of
this problem --and the piece that the current design doesn't even
attempt to take into consideration.

Russ

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

---

From: Eric Osterweil <[email-masked]>
Date: Tue, 18 Dec 2012 19:15:20 -0500

> The DDoS mitigation works (continues to work like it does today) without having to create/propagate new RPKI objects.

So.... how, exactly, do we know it is not an attack?  Is the ``intent bit'' set on all the updates?

Eric

---

From: Randy Bush <[email-masked]>
Date: Tue, 18 Dec 2012 19:40:34 -0500

Forget a out kink with longer prefixes etc. victim withdraws. 

randy, on a stinkin' iPoop

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 18 Dec 2012 19:45:03 -0500

Update is signed from the victim (customer) to the mitigator.
If somone other than the customer signs that customer's prefix to the mitigator
(or to anyone else for that matter), then that update will fail validatation.
There is no need for an intent bit.

I hope I understood your question correctly.

Sriram

________________________________________
From: Eric Osterweil [[email-masked]]
Sent: Tuesday, December 18, 2012 7:15 PM
To: Sriram, Kotikalapudi
Cc: [email-masked]; sidr wg list
Subject: Re: [sidr] the need for speed

Eric

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Dec 2012 21:34:06 -0500

> as the origin AS as suggested). 

While I appreciate your consideration, this won't work.  There are lots of practical reasons why, e.g., diverting a /17 worth of traffic through a DDoS mitigation service is a bad idea when only a subset (e.g., a /32 or /24) is under attack.  Being as surgical as possible is important, for lots of operational and financial reasons. 

FWIW, I can do "origin validation" with access/filter lists and IRRs today, I don't need other parties to control how my prefixes are routed everywhere on the Internet, like folks appear to be aiming to "help me with" here.

And Randy, longer prefixes from "mitigator" with victim withdrawing (i.e., what I think you were trying to convey with "Forget a out kink with longer prefixes etc. victim withdraws.") would leave you with no place to deliver the legitimate "scrubbed" traffic, and that might well be a problem, unless you were intending to effectively complete the attack.

> More specific wins, so the downside of one hop longer path length goes away. 

More specifics override longer prefixes?  Spoofed origins circumvent "origin validation"?  Meh.  We knew this already, and I suspect we're not the only ones...  

> (if permissible by existing ROA) to the mitigator. The victim also sets pCount = 0 for this update.

Assuming they're capable of "forward signing" and distributing an update to the "mitigator"'s BGP speakers -- something I definitely wouldn't count on with the scale and virulence of attacks today.  YMMV...

That said, in an RPKI-enabled BGPSEC world I suppose the mitigator could "leak" the route with some degree of impact, as you point out.  As could attackers, of course, thereby allowing the leak itself to trigger the DoS on the target, but we've been there as well already.

Additionally, as Chris keeps pointing out, it'd be trivial these days for an attacker to drop 10 or 20 or 100G of packet love on an RIR and just break the targets routing via RPKI DDoS - that's an attack vector I don't have to worry about today (beyond the SIDR work).   Or with a fully functional RPKI-enabled BGPSEC simply "leak" their route and blackhole the traffic, molest selectively, or "other"), but again, we know this...

I guess the point here is that I really don't need you to solve this problem for me Sriram, I just don't want you to add a bunch of baggage that introduces more vulnerabilities and fragility, breaks my agility, and yet solves very little of any problem I actually care about as an operator.

BTW: Is there's some actual bound on the number of use cases (i.e., actual operational engineering objectives and techniques employed today) such as this where changes to "policy" in the RPKI may need to occur and be propagated to all RPs in less than hrmm... many hours[?].   Perhaps we should hit up the NOG lists and ask folks about their requirements for making changes, or learn from systems impacted from just this in the past (e.g., IRRs).

Of course, I suspect it's largely futile given Randy's comments about horses and barns et al.., and he really was serious about "running code and running away!".  Problem is, people have to deal with the residue; Randy is usually on the unhappy side of this equation...

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 18 Dec 2012 19:35:37 -0700

> More specific wins, so the downside of one hop longer path length goes away.  

Sound fine in theory, but will not work in practice.  *When* the original announcement is a (IPv4) /24 and all providers filter on announcements > /24 ... you're, umm, up a creek without a paddle if you don't have an ability to [immediately] originate the same /24 from a "proxy" AS.

Remember, there's a *lot* of "legitimate" more specifics out there already, primarily for the purposes of Traffic Engineering (TE).

-shane

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Dec 2012 21:36:17 -0500

On Dec 18, 2012, at 4:52 PM, Christopher Morrow wrote:

>>  (to which I would argue the RIRs already has enough

Heh, fine question Chris..  If they don't, they'd better get busy increasing fees and putting business cases together, I hear it's not cheap - I sure hope my RIR fees don't go up to justify this...

-danny

---

From: Danny McPherson <[email-masked]>
Date: Tue, 18 Dec 2012 21:37:09 -0500

> Sound fine in theory, but will not work in practice.  *When* the original announcement is a (IPv4) /24 and all providers filter on announcements > /24 ... you're, umm, up a creek without a paddle i…

Good point Shane, I forgot that one...

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 18 Dec 2012 20:12:13 -0700

> party DDoS (and other attack) mitigation.

Right, that's one reason[1] ... but, in the spirit of full disclosure here, since you didn't say "for example" in the case of Verisign ... there are other companies *aside* from Verisign that offer third-party DDoS scrubbing and attack mitigation services:

https://www.google.com/#hl=en&tbo=d&sclient=psy-ab&q=ddos%20scrubbing%20service&oq=&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&bvm=bv.1355534169,d.aWM&fp=a7e118819f5e1e5b&bpcl=40096503&biw=1209&bih=766&pf=p&pdl=300

http://www.bing.com/search?q=DDos+scrubbing+services&qs=n&form=QBRE&pq=ddos+scrubbing+services&sc=0-14&sp=-1&sk=

Quite frankly, the Google ads (at the top and to the right) are more useful in this particular instance than the actual search results.  Sigh.  (Although, I find the ads for Residential Cleaning and "Merry Maids" to be quite humorous in a list of ads results for "DDoS scrubbing" ... good job Google! :-).

-shane

[1] I'd also note there are legitimate cases where customers may be unable to serve traffic for their content/service/application, (think: unexpected, but legitimate flash crowds/traffic combined with under-provisioned tail circuit capacity).  In that case, it may be far easier for the customer to temporarily give up, say, a /24 that their content/service/application was being served out of and allow a third party to announce it out of the SP's AS (while still serving the same content/service/application off servers moved to or X-connect'ed to a new 'higher bandwidth' location), until the "storm passed" ...

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 19 Dec 2012 08:21:14 -0500

> Sound fine in theory, but will not work in practice.  *When* the original announcement is 
> a (IPv4) /24 and all providers filter on announcements > /24 ... you're, umm, up a creek 
> without a paddle if you don't have an ability to [immediately] originate the same /24 from a "proxy" AS.
>

The proposed solution would work fine in practice as well. 
Whichever prefix (or more specific of it) that the mitigator and the victim decide to 
propagate (via the mitigator) for DDoS mitigation today in BGP, the same prefix can also 
be propagated with BGPSEC (and more securely). 
If “all providers filter on announcements > /24” as you say, 
then that is a constraint for the DDoS mitigation method under discussion 
regardless of whether it is in BGP or BGPSEC.

Sriram

---

From: Russ White <[email-masked]>
Date: Wed, 19 Dec 2012 08:47:08 -0500

> be propagated with BGPSEC (and more securely). 

How long will it take a BGPSEC update to traverse the network,
end-to-end? Remember that the update must be re-signed at every hop,
take into account the normal speed of BGP operations, and don't forget
the processing, serialization, and memory delay load of adding a
signature...

Just thought I'd bring us back to the original subject line --this isn't
about solving the problem for "perfect security," but for real world use.

And no, "it'll be fast enough once we've gone a generation or two of
routers into the future," isn't a good enough answer. The only way to
know what the Internet will look like in ten years is to stop innovation
and growth in their tracks --I know a lot of folks would really like
this solution, but...

BTW, BGPSEC isn't even close to "perfect security." In fact, I don't
think BGPSEC actually solves much of anything at all at this point
--other than allowing you to point fingers at the "guilty party" much
more effectively than in the past. I can't seem to find that particular
requirement in any requirements document, though.

Russ

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

---

From: Shane Amante <[email-masked]>
Date: Wed, 19 Dec 2012 06:50:23 -0700

> The proposed solution would work fine in practice as well.

In who's world?  ;-)

> be propagated with BGPSEC (and more securely). 

I thought we were just talking about _Origin_ Validation, not BGPSEC?

> regardless of whether it is in BGP or BGPSEC.

Not true.  There are a variety of techniques available today, which will fail with Origin Validation.  By way of a couple of examples, here they are.  First, "Proxy AS" originates same /24 as "Victim AS".
1)  "Victim AS" then withdraws their /24 and falls back on an existing, covering aggregate, e.g.: /23, /20, etc. for delivery of the scrubbed traffic.
2)  "Victim AS" performs AS_PATH prepending of their /24 to make it less preferred compared to the new, shorter AS_PATH length "Proxy AS" origination.
3)  "Victim AS" uses their SP's BGP "Traffic Engineering" Communities to signal to their Service Provider(s) to lower LOCAL_PREF of the Victim's /24, inside their SP(s) AS, compared to the /24 being announced from "Proxy AS".

It's all about intent ...

-shane

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 19 Dec 2012 09:42:17 -0500

> While I appreciate your consideration, this won't work.  There are lots of practical reasons why, e.g., diverting a /17 worth of traffic through a DDoS mitigation service is a bad idea when only a…

With the proposed solution (in BGPSEC), it is possible to announce (for the DDoS mitigation) 
any /17 or /22 or /24 that the mitigator needs to announce.  
The victim has to have set the maxlength long enough in anticipation of this (for coordination 
with the mitigator).  Shane pointed out perhaps “all providers filter on announcements > /24”. 
That is a constraint for the DDoS mitigation method under discussion 
regardless of whether it is in BGP or BGPSEC.

> And Randy, longer prefixes from "mitigator" with victim withdrawing (i.e., what I think you were trying to convey with "Forget a out kink with longer prefixes etc. victim withdraws.") would leave y…

I am curious, if the mitigator announces a more specific (longer length) prefix, 
then how do they leave a path open to deliver the scrubbed traffic back to the victim’s server 
residing in that more specific prefix? All the ASes around the mitigator would be directing 
any traffic for the victim’s server towards the mitigator and not towards the victim. 
Well, may be the victim has an alternate server in the address space not impacted 
by the announcement of the more specific? Or, there is a back channel (like a VPN) 
to deliver the scrubbed data back to the victim?    
   
> More specifics override longer prefixes?  

Not sure what you mean. More specific and longer prefix mean the same thing. 

>> (if permissible by existing ROA) to the mitigator. The victim also sets pCount = 0 for this update.
-- snip --
> That said, in an RPKI-enabled BGPSEC world I suppose the mitigator could "leak" the route with some degree of impact, as you point out.  As could attackers, of course, thereby allowing the leak its…

If you mean the DoS attacker is also leaking the more specific route announced 
by the mitigaor, then he (the DoS attacker) would be quite a fool, isn’t it? 
It would seem he is then conducting DoS on his own router (in the data plane).
  
Sriram

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 19 Dec 2012 10:25:20 -0500

> I thought we were just talking about _Origin_ Validation, not BGPSEC?

Well, we were talking about both. But we can talk one at a time.
It is well known that origin_only_validation has limitations in general 
(e.g., spoofed origin, subprefix hijack with spoofed origin, etc.).
In fact, the DDoS mitigation being discussed here is taking advantage of 
those limitations in the origin_only_validation case.
BGPSEC overcomes the limitations of origin_only_validation, and works
quite cleanly (IMHO) in this DDoS mitigation scenario for the benefit of 
the victim and the mitigator.

> It's all about intent ...

I read what you described above quite carefully twice.  
But it is not clear to me how origin_only_validation fails or interferes 
in any of the methods you outlined above.
I am sure you recognize by now that with origin_only_validation in place,
in the proposed solution, the mitigator needs to spoof the victim’s origin
in order to pass ROA validation.

(Again, if we advance to path validation, then the proposed solution in BGPSEC
does not require the origin spoofing etc. ... we have already gone over that.)  

Sriram

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 19 Dec 2012 17:22:53 +0100

Hi Danny, WG,

People have mentioned that if the security was somehow part of the updates themselves, then you could have security at the speed of updates. I don't see how this could work, it would have to be a completely different set of standards from what's currently being worked on. Most likely this would result in lots of cycles on routers, but without any concrete proposals on this there really isn't much more I can sensibly say about this approach here..

So for the sake of argument let me just stick to the model that we have now where the RPKI is an external system, separate from the BGP updates.

This means that when operators make changes in BGP, they will also need to edit part of the RPKI. 

Chris described a path from roa (or any rpki object) creator to consumer:

>  C internal-cache-systems (some number per roa-consumer)

Strictly speaking there is a step before A: creating the new objects. Dependent on the system (and especially if a remote pub server is used) there may be a short delay before the objects are actually published.

> mins or 10 mins or ... someone draw a line in the sand so we know what

I would really like to echo Chris's last paragraph here. What do you think is a reasonable time to propagate from an operator editing the RPKI (A) -> 99.9% of Bs?

I understand that half a day is way too long. Instantaneous is theoretically impossible when BGP and RPKI are separate. But is there really no reasonable pragmatic indication of what would be 'good enough' for the real world? E.g. if we can come up with a structure that enables repositories to support 100k RP tools ('B', assuming 2 gatherers per ASN) getting their *updates* (full dump separate thread please) every 10 minutes, is that good enough?

Cheers
Tim

---

From: Shane Amante <[email-masked]>
Date: Wed, 19 Dec 2012 09:23:24 -0700

Sriram,

> the victim and the mitigator.

I'm not sure I'd agree with your assessment, but see below for why.

> in order to pass ROA validation.

There are still a few problems with your proposal:
1)  Spoofing the Origin ASN means you will always have a longer AS_PATH length ("Spoofed Origin ASN + Proxy AS") vs. just originating the IP prefix from the "Proxy AS".  Yes, you can _try_ to workaround that using some of the 'tricks' I outlined above, but in thinking about this more I'm not sure all of those techniques I mentioned could be used.  In the proposals for Origin Validation (only), it's suggested that SP's will either:
    a)  Drop IP prefixes with Invalid Origin (Proxy AS) altogether -- maybe not now, but that's the _goal_, eventually, right?  This would obviously outright ban "Proxy AS" from originating the IP prefix from that AS for the purposes of DDoS attack mitigation or other reasons.
    b)  Lower LOCAL_PREF of "Invalid" Origin vs. Valid Origin (per, draft-ietf-sidr-origin-ops) ... perhaps for the foreseeable future.  So, in this case, even AS_PATH prepending by the "Victim AS" would not be effective, because the higher LOCAL_PREF of the Valid Origin/ROA of "Victim AS" will override the lower LOCAL_PREF of an Invalid Origin/ROA of the "Proxy AS".  
... Does the above make it more clear how origin_only validation fails or interferes with all of the methods I've outlined above?

2)  I'm sure you realize that there may not be HW, (routers), available to perform spoofing of the Origin AS you propose.  For example, in the case where capacity to a customer's site in undersized, it's possible for me to [quickly] extend a X-connect from my PE router to their L2 switch, (or plug their servers/switches into my L2 switches connected to my PE router).  In that case, my PE router has one, and only one, global ASN configured on it.  I have no choice *but* to originate that prefix from my ASN, (the "Proxy ASN" if you will).

3)  Since you seem to want to venture into BGPSEC, I'm unclear how you're proposing to -- again, in an emergency -- get BGPSEC router (or, AS?) keys to the "Proxy AS" to allow forward-signing of "Spoofed Origin AS -> Proxy AS".  Given the victim is under DDoS attack, transmission of private (?) signing keys and uploading them into the 3rd-party DDoS mitigators routers to allow the spoofed Origin AS to forward sign BGP announcements seems, umm, a bit hazardous (and time-consuming)?  Particularly in the case where the Victim AS was using a per-AS signing key, not a per-router+per-AS signing key.  That's going to open up the Victim AS to a potentially wider attack surface for the duration of having the DDoS mitigation service spoof the Origin AS, behind their "Transit AS", and/or the period of time for the Victim AS to publish and roll-over to new BGPSEC per-AS or per-router-per-AS signing keys, no?

> does not require the origin spoofing etc. ... we have already gone over that.)  

I'm not following your logic here. 

-shane

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 19 Dec 2012 17:33:54 +0000

>[1] I'd also note there are legitimate cases where customers may be
>unable to serve traffic for their content/service/application, (think:
>unexpected, but legitimate flash crowds/traffic combined with
>under-provisioned tail circuit capacity).  In that case, it may be far
>easier for the customer to temporarily give up, say, a /24 that their
>content/service/application was being served out of and allow a third
>party to announce it out of the SP's AS (while still serving the same
>content/service/application off servers moved to or X-connect'ed to a new
>'higher bandwidth' location), until the "storm passed" ...

In these use cases, what breaks if we allow two ROAs to co-exist in the
system (one authorizing the customer AS and one authorizing the proxy AS
to originate the prefix) _much before_ the attack (or storm) takes place?
After all, this is a valid business relationship. Choose your pill wisely.

- Pradosh

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 19 Dec 2012 13:00:12 -0500

> system (one authorizing the customer AS and one authorizing the proxy AS

the system already permits multiple ROA's for the same prefix, right?

> After all, this is a valid business relationship. Choose your pill wisely.

the concern, for the dos-mitigation and really for the flashcrowds as
well (same thing in the end, "Oops, server go boom, move service to
more-servers-r-us!"), is the lack of prior relationship and thus lack
of existence of a new ROA.

-chris
(course, I could have missed your question entirely)

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Dec 2012 13:13:06 -0500

[ apologies for having the attention span of a chihuahua, but i am being
  eaten by airplanes and relatives ]

i was trying to make only two points

  o there is a useful poster child for the need for O(minutes) rpki (or
    perhaps just roa) propagation.  as folk have repeatedly said, we
    need concrete examples and goals.

  o unfortunately, there is no internet technology today to completely,
    accurately, and securely maintain a globally distributed database
    (e.g. at every non-trivial pop) with time constraints on the order
    of a minute.  it's a research problem.  and a *really* interesting
    one.

i am confident that the folk providing third-party mitigation services
are clever enough to figure out their own hacks around this problem, and
we do not need to second guess what might best work for them.

and my apologies to anyone who is offended by my using ntt, verisign,
and whoever as examples.  the subject has been sufficiently clouded by
indirection, hand-waving, and conjecture.  concrete examples are good,
and they're ones i know.  oh, and apologies to chihuahuas, i guess :)

randy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 19 Dec 2012 16:18:18 -0200

>> [1] I'd also note there are legitimate cases where customers may be
...

> After all, this is a valid business relationship. Choose your pill wisely.

Is't this already allowed ? I don't think we need to change anything for
this to work.

> - Pradosh

~Carlos

---

From: Richard Barnes <[email-masked]>
Date: Wed, 19 Dec 2012 13:24:39 -0500

> Is't this already allowed ? I don't think we need to change anything for

I think that's the point.

Going back to Randy's original message, the point is that if you can plan ahead, then there's no issue here.  The only problem arises if you need to authorize someone at the last minute, which, as Randy points out, is not really a solved problem.

--Richard

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 19 Dec 2012 18:54:39 +0000

>I think that's the point.

Yes, exactly.

- Pradosh

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Wed, 19 Dec 2012 18:54:42 +0000

>the system already permits multiple ROA's for the same prefix, right?

Yes (e.g. multihoming) and hence the question of why we can't use that
framework.

>(course, I could have missed your question entirely)

No, thanks for clarifying. For DDoS mitigation at least, I thought there
would be a prior business relationship. I am not familiar with on-the-fly
relationship building process.

- Pradosh

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 19 Dec 2012 14:01:11 -0500

> relationship building process.

for that case, and shane's (and probably a few more) the 'new
relationship' could exist for:
  1) a short period of time
  2) immediately upon close of a phone call

so, some extra churn in the rpki system as well as routing-system data
changes. I think one of the points to haggle about is 'how quick' do
they need to happen.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 19 Dec 2012 16:12:22 -0500

>1)  Spoofing the Origin ASN means you will always have a longer AS_PATH
>length ("Spoofed Origin ASN + Proxy AS") vs. just originating the IP prefix from
>the "Proxy AS".  Yes, you can _try_ to workaround that using some of the 'tricks'
>I outlined above, but in thinking about this more I'm not sure all of those
>techniques I mentioned could be used.  In the proposals for Origin Validation
>(only), it's suggested that SP's will either:

This has been said before but worth a repeat --
Talking about the spoofed origin ASN solution, 
the concern about path length increase by one hop really 
goes away because, as Danny has also pointed out, the mitigator wants to be
rather surgical and hence announces a more specific (longer length) prefix
in most cases. Thus, the mitigator is drawing towards itself the traffic
that is DDoS'ing the victim's server but minimizes drawing traffic destined 
to other unaffected parts of the victim's address space.

Due to the spoofed origin ASN, the proxy AS's BGP update is always Valid
(in terms of the origin-only-validation outcome).
I feel that none of the workaround tricks you mention are necessary
considering that the BGP announcement from the proxy AS is for 
a more specific prefix (most of the time) and it is always Valid 

>    a)  Drop IP prefixes with Invalid Origin (Proxy AS) altogether -- maybe not now,
>but that's the _goal_, eventually, right?  This would obviously outright ban
>"Proxy AS" from originating the IP prefix from that AS for the purposes of DDoS
>attack mitigation or other reasons.

This concern goes away per explanation provided above.

>    b)  Lower LOCAL_PREF of "Invalid" Origin vs. Valid Origin (per, draft-ietf-sidr-
>origin-ops) ... perhaps for the foreseeable future.  So, in this case, even AS_PATH
>prepending by the "Victim AS" would not be effective, because the higher
>LOCAL_PREF of the Valid Origin/ROA of "Victim AS" will override the lower
>LOCAL_PREF of an Invalid Origin/ROA of the "Proxy AS".

This concern also goes away per explanation provided above.

>... Does the above make it more clear how origin_only validation fails or
>interferes with all of the methods I've outlined above?

As I have explained above, we can eliminate the possibility of failure or interference
by two means: (1) Proxy AS spoofs origin AS; (2) Proxy AS announces
a more specific prefix (in most cases of DDoS mitigation).

>
>2)  I'm sure you realize that there may not be HW, (routers), available to
>perform spoofing of the Origin AS you propose.  For example, in the case where
>capacity to a customer's site in undersized, it's possible for me to [quickly]
>extend a X-connect from my PE router to their L2 switch, (or plug their
>servers/switches into my L2 switches connected to my PE router).  In that case,
>my PE router has one, and only one, global ASN configured on it.  I have no
>choice *but* to originate that prefix from my ASN, (the "Proxy ASN" if you will).
>

Is this that much different from AS prepending? Instead of inserting multiple
times the PE router's ASN (in the prepending case), it inserts once the
DDoS-mitigation customer's ASN in the path. Alternatively, the victim can
set up a BGP session to the mitigator and inject the route 
(no spoofing by proxy AS in that case).
But then I am not a developer/implementer ;) 

>3)  Since you seem to want to venture into BGPSEC, I'm unclear how you're
>proposing to -- again, in an emergency -- get BGPSEC router (or, AS?) keys to the
>"Proxy AS" to allow forward-signing of "Spoofed Origin AS -> Proxy AS".  Given
>the victim is under DDoS attack, transmission of private (?) signing keys and
>uploading them into the 3rd-party DDoS mitigators routers to allow the spoofed
>Origin AS to forward sign BGP announcements seems, umm, a bit hazardous
>(and time-consuming)?  Particularly in the case where the Victim AS was using a
>per-AS signing key, not a per-router+per-AS signing key.  That's going to open up
>the Victim AS to a potentially wider attack surface for the duration of having the
>DDoS mitigation service spoof the Origin AS, behind their "Transit AS", and/or
>the period of time for the Victim AS to publish and roll-over to new BGPSEC per-
>AS or per-router-per-AS signing keys, no?
>

The solution that Oliver and I suggested does not have any of the complications
that you mention above: 
http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html 
http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html 
The victim AS does not need to transfer any router keys to the proxy AS.
Instead the victim AS provides a signed update (with pCount=0) to the
proxy AS (by creating a BGPSEC peering session or by other suitable means).

Sriram

---

From: "Borchert, Oliver" <[email-masked]>
Date: Wed, 19 Dec 2012 17:36:55 -0500

> In these use cases, what breaks if we allow two ROAs to co-exist in the system (one authorizing the customer AS and one authorizing the proxy AS to originate the prefix) _much before_ the attack (or storm) takes place?

Nothing will break, just think of multi-homing where two service providers announce the prefix out of their AS. Or just before a ROA expires a replacement should be installed beforehand to prevent ending up with an "invalid" during the origin validation.  
Again, I think it is worthwhile to mention that it takes only one ROA to declare the origin validation as valid.

Oliver

---

From: Shane Amante <[email-masked]>
Date: Wed, 19 Dec 2012 16:16:45 -0700

On Dec 19, 2012, at 2:12 PM, "Sriram, Kotikalapudi" <[email-masked]> wrote:
[--snip--]

FWIW, I disagree with your assertions, but am cutting to the chase, because I think you're still failing to understand why/when it's not possible to "spoof" the Victim's AS.

> But then I am not a developer/implementer ;) 

There is no PE <-> CE eBGP session where one can originate the IP Prefix from the "Victim AS".  There is just this:

  ISP
Proxy-AS       Victim IP prefix
  AS1
+------+      +-------------------------------------+
| PE-1 |======| Victim's L2 switches and/or servers |
+------+      +-------------------------------------+

              ^
              |
              +---- This is not a CE router

On the router PE-1, in the ISP AS (AS1), I am originating a BGP announcement for a _directly_connected_ prefix, where the victim's server/network/service is located.  I am not aware of a capability in any implementation that I'm familiar with where I can originate that directly connected IP prefix for the Victim's network and have it appear to be from the Victim's Original AS.  When I originate an IP prefix on PE-1, the Origin-AS of that IP prefix is AS1, the "Proxy AS", not the "Victim's AS".  Then again, perhaps I have not looked hard enough at existing implementations ...

Quite frankly, *not* having the capability in router implementations to Originate an IP prefix with any random Origin_AS, (e.g.: PE-1), is possibly one of the more effective deterrents /against/ mis-originating an IP prefix from the 'intended'/correct Origin AS -- ooooh, there's that word "intent" again.

> proxy AS (by creating a BGPSEC peering session or by other suitable means).

Awesome.  So, now we've got a recommendation to:
a)  Spoof the Victim's Origin AS; and,
b)  Use pCount = 0 to avoid validating the AS_PATH signatures

I'm failing to see what the group is trying to accomplish here if these are the recommendations.  One has to question what value there is in deploying Origin Validation & BGPSEC if the answer when it can't accommodate a operationally viable scenarios is to effectively "turn it off".

-shane

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 09:34:51 -0500

>    need concrete examples and goals.

I really think these should feed requirements analysis too [1].  I think there are a few other easy examples of this type of use case, but for requirements, maybe we need just one good one?

>    of a minute.  it's a research problem.  and a *really* interesting

I feel _this_ is where a lot of our group's false-logic starts.  This (and similar) statement(s) assume that we must deploy a global replicated state machine, which has a complete and coherent image of a globally distributed set of resource holders' states, at all RPs at all times in order for validation to succeed.  Moreover, the state of this global replicated state machine has no semantic for data authorities to inform or influence the coherence of replicated data held by RPs (in caches, etc).  It is true that this model is mandated by the current _design_, but I don't see that this is motivated by any real engineering _requirement_.  Why do we need to crawl all repos, for all resource holders in order to route?  What motivates _this_ as the only way to accomplish routing security?

In the spirit of sound engineering: since this aspect of BGPSEC is not derived from a requirement, and it is limiting us from reaching other required goals (see above), it ought to be reconsidered/thrown out.  afaik, RPKI+BGPSEC (note the BGPSEC part, not just RPKI) is something of an outlier in the field of Internet-scale systems, in that it requires everyone to have this full globally consistent cryptographic state maintained reliably at all RPs.  I point this out just to underscore the notion that we should all be circumspect in our optimistic appraisals of this design's operational viability.

I feel this design element needs to be challenged, and if it cannot be supported by requirement it should be removed from the design.

Eric

[1] http://www.ietf.org/mail-archive/web/sidr/current/msg03671.html

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 20 Dec 2012 10:39:06 -0500

> FWIW, I disagree with your assertions, but am cutting to the chase, because I think you're still failing to understand why/when it's not possible to "spoof" the Victim's AS.

Sorry, I tried my best to try to understand your point but well …
But thanks very much indeed for your patience.
I guess this particular point ( i.e. why/when it's not possible to "spoof" the Victim's AS) 
needs some paper and pencil (or white board) discussion.
Hopefully, we can do that when we meet in person (at NANOG in Feb?). 

--snip-- 
> Proxy-AS       Victim IP prefix

Thanks for the nice figure and the explanation. But I think there is a way.
I assume the ISP (Proxy AS) is the DDoS mitigator.
Is the L2 connection (1) an existing business relationship between the two parties, or 
(2) is being established in emergency after the victim came under attack and 
made a panic phone call to the DDoS mitigator (Proxy AS1)?

If it is case (1), then a ROA can be created well in advance (of any emergency) permitting 
the victim’s prefix to be announced from AS1. Right?

If it is case (2), then for what purpose is the L2 connection being set up? 
It appears to me that it is for the Proxy AS1 to channel the scrubbed traffic 
back to the victim’s network. True?

So the question is, in case (2) how does Proxy AS1 inject a route into the Internet 
showing victim AS as the origin AS. The proxy AS1 already has a route for 
the victim’s prefix from updates it got from one or more of its (AS1’s) neighbors. 
(Note that Proxy AS1 does not need to have a direct BGP peering with victim AS 
although it can establish one if needed over a multi-hop TCP, but we don’t need that here). 
Let us say, the path that AS1 has for victim’s AS (or prefix) is AS6 AS9 AS2, 
where AS2 is the victim’s ASN and AS9 and AS6 are some ASes in the middle. 
All that the Proxy AS1 needs to do is modify the path and reduce it simply to AS2. 
This is a simple path modification (MITM). Pilosov-Kapela successfully demoed 
a more complex BGP MITM back in 2008 on the live real Internet at Defcon. 
By comparison, the path modification that the mitigator (proxy AS1) needs to do 
seems feasible and simpler. Agree?
                    
> a)  Spoof the Victim's Origin AS; and,

The mitigator is *benevolently hijacking* the victim’s prefix (or subprefix) today 
to provide DDoS mitigation. Spoofing of victim’s AS may be used in the same vein, 
keeping mitigator’s update “Valid” when origin-only-validation is in use. 

Your use of “and,” above is incorrect. It should be “or”. 
Spoofing the Victim's Origin AS is applicable in the origin-validation-only case, 
not but in the path validation case (i.e. BGPSEC).
  
> b)  Use pCount = 0 to avoid validating the AS_PATH signatures

Err… No.  Where did you get that from?  
pCount represents the AS prepend count (there is a pCount associated with each AS).
pCount = 0 (in BGPSEC) simply means that the corresponding ASN must not be 
counted in the path length count. Verifying the path signatures is still a must. 
Recall that pCount = 0 was introduced originally to accommodate 
transparent router servers (IXP). In the present case, pCount = 0 helps with 
not increasing the path length when victim’s ASN is to be included in the AS path. 
But pCount = 1 can also be used if you don’t care about the +1 increment 
to the path length of the Proxy AS’s (mitigator’s) announcement.
 
> I'm failing to see what the group is trying to accomplish here if these are the recommendations.  One has to question what value there is in deploying Origin Validation & BGPSEC if the answer when…

With pCount = 0 misunderstanding removed, I hope you now see that the 
proposed solution is not simplistic as you might have thought. 
The proposed solution is helping the DDoS mitigator announce/propagate 
the victim’s prefix and stay “Valid”, while also avoiding having to create/propagate 
new RPKI objects in the emergency situation. That’s the goal, right?
   
Sriram

---

From: Bryan Weber <[email-masked]>
Date: Thu, 20 Dec 2012 10:50:48 -0500

I agree with your comment about a conversation at Nanog in February, sounds like a great idea.

Comments inline below.

Thanks,
Bryan

> seems feasible and simpler. Agree?

Sure, but isn't Eric's point that there is no ROA in this case (#2) and if propagation times are too large (days or weeks) then it doesn't really help with the DDoS mitigation?

I am also curious about AS's that are direct peers of AS2. They might not necessarily select the mitigating AS because they are also one hop away and the tie breaking criteria will be used, no?

---

From: Bryan Weber <[email-masked]>
Date: Thu, 20 Dec 2012 10:55:13 -0500

Excuse me. I misunderstood. In either case, the prefix originates out of AS2 so the existing ROA would be valid and you would just have to worry about tie breaking factors anywhere that the AS path length was 2.

Thanks,
Bryan

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 11:03:52 -0500

> I feel _this_ is where a lot of our group's false-logic starts.  This
> (and similar) statement(s) assume that we must deploy a global
> replicated state machine, which has a complete and coherent image of a
> globally distributed set of resource holders' states, at all RPs at
> all times in order for validation to succeed.  Moreover, the state of
> this global replicated state machine has no semantic for data
> authorities to inform or influence the coherence of replicated data
> held by RPs (in caches, etc).  It is true that this model is mandated
> by the current _design_, but I don't see that this is motivated by any
> real engineering _requirement_.  Why do we need to crawl all repos,
> for all resource holders in order to route?  What motivates _this_ as
> the only way to accomplish routing security?
> 
> In the spirit of sound engineering: since this aspect of BGPSEC is not
> derived from a requirement, and it is limiting us from reaching other
> required goals (see above), it ought to be reconsidered/thrown out.
> afaik, RPKI+BGPSEC (note the BGPSEC part, not just RPKI) is something
> of an outlier in the field of Internet-scale systems, in that it
> requires everyone to have this full globally consistent cryptographic
> state maintained reliably at all RPs.  I point this out just to
> underscore the notion that we should all be circumspect in our
> optimistic appraisals of this design's operational viability.
> 
> I feel this design element needs to be challenged, and if it cannot be
> supported by requirement it should be removed from the design.

bgpsec+rpki does not have the highly globally synced requirement.  your
application does.  you are tryin to add the requirement.  i agree with
you that it should not be added.  thanks for understanding.

randy

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 11:19:44 -0500

On Dec 20, 2012, at 11:03 AM, Randy Bush wrote:

> bgpsec+rpki does not have the highly globally synced requirement.  

So, in bgpsec, you (as an RP) don't need to know ROAs a priori in order to validate routes as they arrive in updates?

> your
> you that it should not be added.  

bgpsec (as currently outlined in the requirement-free draft) implicitly requires full replication of the rpki in order to make correct routing decisions.  _That_ system has this flaw, but I don't claim to own it. ;)

> thanks for understanding.

Clever! :-P

Eric

---

From: Randy Bush <[email-masked]>
Date: Thu, 20 Dec 2012 11:30:03 -0500

> So, in bgpsec, you (as an RP) don't need to know ROAs a priori in
> order to validate routes as they arrive in updates?

see "highly synched" above.  as a rp, an hour or three loose synch is
fine.

> bgpsec (as currently outlined in the requirement-free draft)

damn!  and i thought i had writted a reqs draft, which does need
updating.  let's try to limit the slinging.

and your problem is with origin validation as currntly implemented and
deployed.  it ain't bgpsec.

> implicitly requires full replication of the rpki in order to make
> correct routing decisions.

diff between loose time constraint and what is replicated.

> _That_ system has this flaw, but I don't claim to own it. ;)

are you willing to rent it out?  :)

you have a product which places a currently unachievable time constrains
on pretty much any mechanism which provides prefix origination security.

randy, heading for more airports

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Dec 2012 14:36:43 -0200

> So, in bgpsec, you (as an RP) don't need to know ROAs a priori in order to validate routes as they arrive in updates?

	Your RP does, but you do not need all the RPs to have it in order to
rpki+bgpsec to work.

/as

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Thu, 20 Dec 2012 11:42:06 -0500

>Excuse me. I misunderstood. In either case, the prefix originates out of AS2 so the existing ROA would be valid and you would just have to worry about tie breaking factors anywhere that the AS path…

That is right about case (#2) -- the case that we are more interested in.
But in my more mundane case (#1), it is an existing (long term) business relationship between the two parties.
So a 2nd ROA can be created proactively for the Proxy AS (AS1).

> I agree with your comment about a conversation at Nanog in February, sounds like a great idea.

Sure, thanks. I'll look forward to it.

> Sure, but isn't Eric's point that there is no ROA in this case (#2) and if propagation times are too large (days or weeks) then it doesn't really help with the DDoS mitigation?

As you have acknowledged already, the RPKI propagation delays do not come into picture for the
proposal we are examining.

Just as an aside, you may take a look at my estimates/comments also about the RPKI delays:
http://www.nist.gov/itl/antd/upload/rpki-rsync-delay-technote.pdf

Sriram

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 11:45:24 -0500

> see "highly synched" above.  as a rp, an hour or three loose synch is

No, you've got that wrong again.  In order for the system that _you_ designed to meet the requirements of those who are using and operating the Internet, it must be able to perform faster than your design can realistically manage.  That's a design flaw that came from ignoring requirements analysis.

> updating.  

Well, afaict, the requirements in your draft have not been accepted by the group, in general.  Therefore, the fact that you have a reqs draft, does not mean the designs in the other drafts meet the group's requirements.  You can't just write reqs and run away if you want people to take them seriously. ;)

> let's try to limit the slinging.

Gotcha... Stay focused on engineering. Ack...

> deployed.  it ain't bgpsec.

Umm... what?  Right now, what's deployed ain't bgpsec... What implementation are you talking about?

> diff between loose time constraint and what is replicated.

There is a requirement of data freshness.  It is not realistic _in_your_design_.  That makes your design a poor fit, and we need another approach.

> are you willing to rent it out?  :)

I'm confused... Are you ``slinging'' here? So, that's back on again?  kewl...  ;)

> on pretty much any mechanism which provides prefix origination security.

No no no... Sorry Randy, that's not how engineering works...  You see, we have a requirement... If your suggested design cannot meet it, we need to go from _there_ (your design cannot meet a requirement).  Your assumption that it is ``unachievable'' is silly. Have you explored the _entire_ solution space?  Have you gotten consensus on what problem(s) we are even solving here?  No, you haven't.  As an engineer, ymbk...

> randy, heading for more airports

gtk,

Eric

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Dec 2012 14:59:49 -0200

I keep hearing:

"this is not fast enough"

"we have a requirement to make it faster"

etc.

	But nobody has answered Tim:

"> I would really like to echo Chris's last paragraph here. What do you
>think is a reasonable time to propagate from an operator editing the
>RPKI (A) -> 99.9% of Bs?
>
> I understand that half a day is way too long. Instantaneous is
>theoretically impossible when BGP and RPKI are separate. But is there
>really no reasonable pragmatic indication of what would be 'good
>enough' for the real world? E.g. if we can come up with a structure
>that enables repositories to support 100k RP tools ('B', assuming 2
>gatherers per ASN) getting their *updates* (full dump separate thread
>please) every 10 minutes, is that good enough?
>

	So, instead of continuing a futile discussion, why not better start
working on a workable requirement?

	I have read in this list some interesting approaches to make the
repositories more reliable and giving a reasonable indication of your
expectations as operators I think it would be a good start.

/as

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 12:35:46 -0500

> working on a workable requirement?

I think a number of us in this ``futile'' argument have been pushing pretty hard to start (or some may claim revive) the requirements process.  The very fact that we are even talking about freshness and liveliness of data is a result of a few of us having to request/re-request/write drafts/do formal analysis on existing measurement/swrite tech notes/re-request again/etc.  imho, the only reason anyone is _now_ saying, ``half a day is way too long'' is because it has taken this long to get traction from the group.

My 0.02 about the above is that the first part of Tim's para talks about finding a requirement, but the 2nd part presumes the existence of a design (repos and structures)...  Let's talk about requirements first.  If we need use cases and threat models before that, then let's go _there_ first, and then on to requirements.  I feel like your comments above take for granted the fact that several of us have had to work very hard to get to this stage.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 12:38:02 -0500

> 	Your RP does, but you do not need all the RPs to have it in order to

If I want my prefixes to be validated and accepted throughout the routing system (i.e. any eBGP speaker), I need to be sure they all have the full RPKI repo.  These RPs _also_ need all of router keys in the whole world, so that they can verify the path signatures of any update they might see.

In this design, you can't be a little bit pregnant. :)

Eric

---

From: Shane Amante <[email-masked]>
Date: Thu, 20 Dec 2012 11:06:08 -0700

> Hopefully, we can do that when we meet in person (at NANOG in Feb?). 

I don't have plans to be at NANOG in February, so perhaps IETF in March?

> Is the L2 connection (1) an existing business relationship between the two parties, or 

Assume the answer is: No.

> made a panic phone call to the DDoS mitigator (Proxy AS1)?

Yes.

> the victim’s prefix to be announced from AS1. Right?

Theoretically, yes.  /Assuming/ they planned ahead.

However, I would note that the use case I've outlined above is more broad than 'just' DDoS attack.  Specifically, think of "natural or man-made disasters".  In the latter case, it's often the case that a customer's primary DataCenter is taken offline and, although they [may] have a secondary/backup DataCenter, they hadn't adequately provisioned capacity into it.  In those cases, the answer is, generally, to bypass the undersized physical equipment/tail-circuit/whatever in order to restore service as quickly as possible.  In the example diagram I've highlighted above, this could involve removing an undersized CE router from the physical path between my PE and their server farm, (because it's physical interfaces, processing power, whatever are not adequately sized).

Although you would think that with the recent natural/man-made disasters we've witnessed (Hurricane Sandy being the most recent), people would get better at "planning ahead", but unfortunately that doesn't seem to be panning out.

> back to the victim’s network. True?

In the case of DDoS mitigation, yes.  In the case, where I am helping restore service *after* a natural/man-made disaster or flash crowd/traffic, that's not the case.  I'm just sinking/sourcing traffic to them to get them back online as quickly as possible.

> seems feasible and simpler. Agree?

I disagree.  As I stated previously, commercial routers *DO NOT* allow me to originate the Victim's IP prefix from the Victim's AS.  My router (AS1) only allows me to originate IP prefixes from AS1.  My router (AS1) does not allow me to originate an IP prefix from some random AS: AS2, etc.  As I also stated, I firmly believe that's a *security* feature, not a "bug".

> keeping mitigator’s update “Valid” when origin-only-validation is in use. 

Hrm, "benevolently" implies _intent_ ... yes?  I thought "intent" was strictly verboten in this WG?  So, how will third-parties in a BGPSEC world know that the intent is "benevolent" vs. "malevolent" hijacking?

> not but in the path validation case (i.e. BGPSEC).

Why?

> to the path length of the Proxy AS’s (mitigator’s) announcement.

OK, my apologies for the misunderstanding.

But, this leads me back to the question you never answered in one of my previous e-mails on this topic.  
 
Let me draw a little picture to make that question more clear.  Again, I'm going with the scenario that you envision is theoretically possible (under duress), which is that there is the following topology.  (Note, this is not applicable to the other scenario I outlined above where no CE router exists during restoration of service after a natural/man-made disaster).  After a DDoS attack has started to occur, the Victim has called up a DDoS scrubbing service provider and said "Help", with no prior business relationship in place.  In this case, let's assume the DDoS scrubbing provider already has a "CE-1" router, located in the DDoS scrubbing provider's DataCenter(s), sitting idle which will benevolently stand in on behalf of the "Victim AS" and will be used to inject the Victim's IP prefix(es) with the correct, original Origin_AS.  In this case, "PE-1" is owned/operated by the DDoS scrubbing provider and has "Proxy AS".  IOW, you can think of "Proxy AS" as a brand-new "Transit Provider" to the "Victim AS".  Again, since there was no prior business relationships and time is of the essence, you have to use the HW already deployed in the diagram below.  I agree that, strictly from the PoV of Origin Validation, CE-1 can originate the Victim IP prefix with the correct Origin_AS and Origin Validation will work OK -- even though, in this case, everyone will have no idea if that's what is intended or not.  However, my question above is really about Path Validation, specific to BGPSEC.  In this case, how does the "Victim AS" get their (private?) signing keys deployed /within/ CE-1 of the DDoS scrubbing provider?  Isn't that required in order for CE-1 to properly sign the AS_PATH Signature before transmittal to PE-1, in order that receivers of this BGP UPDATE will observe a valid BGP AS_PATH Signature?

  DDoS
Scrubbing
Provider
"Proxy AS"     "Vicim AS"
   AS1            AS2
+------+       +------+
| PE-1 |-------| CE-1 |
+------+       +------+

> proposed solution is not simplistic as you might have thought. 

I'm still not here, yet.

> new RPKI objects in the emergency situation. That’s the goal, right?

Yes.

-shane

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Dec 2012 16:27:30 -0200

> I think a number of us in this ``futile'' argument have been pushing pretty hard to start (or some may claim revive) the requirements process.  The very fact that we are even talking about freshnes…

That's is not true. We have seen some challenges in the current
architecture since long ago and some are trying to address them:

https://datatracker.ietf.org/doc/draft-rogaglia-sidr-multiple-publication-points/

https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-delta-protocol/

https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-cache/

> My 0.02 about the above is that the first part of Tim's para talks about finding a requirement, but the 2nd part presumes the existence of a design (repos and structures)...  

Yes. That is what we have now. If you have a better way I would like to
hear a proposal.

Let's talk about requirements first.  If we need use cases and threat
models before that, then let's go _there_ first, and then on to
requirements.  I feel like your comments above take for granted the fact
that several of us have had to work very hard to get to this stage.

Let's talk about requirements, what do you think is a reasonable time to
propagate?

> Eric

Regards,
as

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 13:53:37 -0500

> https://datatracker.ietf.org/doc/draft-tbruijnzeels-sidr-validation-local-cache/

I totally appreciate the efforts behind these design enhancements, and I am trying impugn the work that has clearly gone into them (or the people who did the work).  However, my concern is that without requirements analysis around the core of the architecture that these enhancements speak to, how do you know that you're not just building on a shaky/unstable foundation, or trying to overcome fundamental flaws in its architecture?  We haven't taken the time to outline what bgpsec needs to do in order for us to be protected by it.  Therefore, we can't describe when we've met our goals.

Note: a lot of the above work (I believe) surrounds just the RPKI, and bgpsec's requirements on _it_ may change dramatically in the face of what bgpsec ultimately needs to do.  I am becoming increasingly convinced that it is important to make the rpki vs. rpki+bgpsec distinction crystal clear.

> Yes. That is what we have now. If you have a better way I would like to

So, despite my suggestions to start with requirements, you're asking for a design?  :)

Throwing something together in a tit-for-tat would be reckless, as we don't have a solid agreement of _what_ we are trying to protect against, and therefore, we don't know _how_ we want to protect ourselves from it.  Admittedly, opinions in this group seem to vary, but we do not have a reasonable/accepted draft.

I am so glad meatspace bridges aren't built this way... We'd be driving down the road trying to convince ourselves that a 1,000 meter wide gorge up ahead was really just 900 meters of meaningful danger, and the 900 meter bridge that we built part of the way across it is good enough.

> Let's talk about requirements, what do you think is a reasonable time to

I'm happy to have the requirements discussion, but it starts with higher level questions like: what (specifically) are we trying to accomplish?  What are we trying to protect ourselves against?  What is the nature of that danger?  How do we address it? etc.  Then we can go to lower level requirements that may come out of that, like freshness.  Without understanding the high level requirements, I would worry that deciding we need to enshrine a specific deadline, and then choosing a value could be as dangerous as presuming we don't need one at all.

Eric

---

From: Eric Osterweil <[email-masked]>
Date: Thu, 20 Dec 2012 14:02:02 -0500

> I totally appreciate the efforts behind these design enhancements, and I am trying impugn the work that has clearly gone into them (or the people who did the work).  However, my concern is that wit…

Err... *_not_ trying to impugn sorry. :)

Eric

---

From: joel jaeggli <[email-masked]>
Date: Mon, 24 Dec 2012 16:32:16 -0800

> prefix(es) can propagate.
The alternative approach assuming you've planned ahead is to orginate a 
more specific with the same origin but verisign as the transit AS... 
therefore the origin validation works fine. if you do the same with the 
covering prefix you're going to have to either make your other providers 
less desirable, or withdrawal the prefix. the backhaul from your dos 
protection provider is done with a tunnel or ideally with a private 
interconnect.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 26 Dec 2012 12:37:24 -0500

> I don't have plans to be at NANOG in February, so perhaps IETF in March?

Yes, I plan to attend the IETF in March.

--snip--
> However, I would note that the use case I've outlined above is more broad than 'just' DDoS attack.  Specifically, think of "natural or man-made disasters".  In the latter case, it's often the case…

Would it be possible to leave the BGP session intact from their CE to your PE?
If not, can a new BGP session (possibly over a TCP session that may go over multiple physical hops if necessary) be set up between your PE and the customer? Customer could even use a simple PC emulating a BGP router to do this. Then they can originate their own prefix and directly pass the announcement to your PE; the update could be unsigned (when there is origin-only validation) or signed in the future (when there is path validation). 

> I disagree.  As I stated previously, commercial routers *DO NOT* allow me to originate the Victim's IP prefix from the Victim's AS.  My router (AS1) only allows me to originate IP prefixes from AS1…

Please see my comment below with you new example.

> Hrm, "benevolently" implies _intent_ ... yes?  I thought "intent" was strictly verboten in this WG?  So, how will third-parties in a BGPSEC world know that the intent is "benevolent" vs. "malevolen…

In the ROA, there is an expression of intent, but still origin-only-validation leaves door open for faked origin announcements. Third party would always treat that type of announcement as Valid provided maxlength is not violated (in the origin-only-validation case). It is the victim who knows it was a “benevolent” act by their mitigator, and therefore does not raise an alarm. This discussion is moot in the path validation case.   	

>> not but in the path validation case (i.e. BGPSEC).

When there is path validation, obviously the mitigator cannot spoof the victim’s AS; it is not possible. The mitigator can only rely on receiving a signed update from the victim; please see more elaborate comment below.

> Let me draw a little picture to make that question more clear.  Again, I'm going with the scenario that you envision is theoretically possible (under duress), which is that there is the following t…

The WG has generally held the opinion that one organization handing its private key to another is not a good practice. So I think the solution has to be of a different nature. We have to ask if it would be possible (as part of the mitigation /service recovery strategy) to quickly set up a BGPSEC session between the mitigator and the victim in cases when one did not exist already? This BGPSEC session does not have to be over a single physical hop; it can be set up over a TCP session that goes over multiple physical hops. The equipment on the victim’s side can simply be a PC that emulates a BGPSEC router or it could be their CE. Do you think this is workable?

Sriram

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 Dec 2012 12:48:58 -0500

> If not, can a new BGP session (possibly over a TCP session that may go over multiple physical hops if necessary) be set up between your PE and the customer? Customer could even use a simple PC emul…

I don't know that solving the many examples with many different
solutions one at a time is helping here... In general:
  1) there are cases where some relationship exists before the
'event', whatever that event may be
  2) there are cases where no relationship exists before the 'event'.

In both cases there are a myriad of solutions in place today, some of
which will be complicated in a more 'bgpsec' world (or a more RPKI
world). Making the potential new world be as nimble as the old seems
to be what Shane/Danny are aiming for, right? Ratholing on the 12 sins
of christmas doesn't seem helpful to the overall goal.

-chris