Mailing List Archive

> Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID
> route announcement; the result is RPKI UNKNOWN.

Which is fine until UNKNOWNs are no longer permitted, a logical next
step. It may not apply globally, initially perhaps just a US anti
terrorist measure requiring all networks in the USA do it.

> The only way a court order could make a route announcement get the
> RPKI status *INVALID* would be to:
> 1: Remove the original, legitimate ROA
> 2: Tamper with the Registry, inject a false ROA authorizing another
> AS to make the announcement look like a hijack

Domains already get FBI hijacked so this seems plausible too.

> All in all, for an RPKI-specific court order to be effective in
> taking a network offline, the RIR would have to tamper with the
> registry, inject false data and try to make sure it's not detected so
> nobody applies a local override.

Doesn't need to be undetected, more likely it'll be quite overt
and have a big don't mess FBI entry in the RIR similar to
www.megaupload.com

brandon

On Sun, Apr 29, 2012 at 11:28:58AM -0400,
Jennifer Rexford <jrex@CS.Princeton.EDU> wrote
a message of 37 lines which said:

> How does this interact with the presence of certificates for
> supernets, though? That is, suppose an ISP creates a legitimate ROA
> for 12.0.0.0/8, after ensuring that all of its customers have
> legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose
> one of these customers has its legitimate ROA revoked by a court
> order. Would the legitimate announcement of that subnet (originated
> by the customer's ASN) still result in UNKNOWN status, or would it
> look like a sub-prefix hijack because the announcement has a
> different ASN than the matching 12.0.0.0/8 prefix?

The second (and therefore Alex Band's example is not good). But it
depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA
(section 3.3 of RFC 6482).

If, in the future, RIRs or operators create ROAs for all the blocks
they manage, revocation of a ROA will be deadly.

On Sun, 29 Apr 2012, Stephane Bortzmeyer wrote:

> > How does this interact with the presence of certificates for
> > supernets, though? That is, suppose an ISP creates a legitimate ROA
> > for 12.0.0.0/8, after ensuring that all of its customers have
> > legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose
> > one of these customers has its legitimate ROA revoked by a court
> > order. Would the legitimate announcement of that subnet (originated
> > by the customer's ASN) still result in UNKNOWN status, or would it
> > look like a sub-prefix hijack because the announcement has a
> > different ASN than the matching 12.0.0.0/8 prefix?
>
> The second (and therefore Alex Band's example is not good). But it
> depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA
> (section 3.3 of RFC 6482).
>
unclear as the scenario doesn't depend on the maxLength (wrt the
current specs). If there are valid covering ROAs in the RPKI and none of
them match in the origin AS (customer ROA removed), the route prefix is
invalid.

The scenario is similar to the case in which the ISP starts to create
a ROA for a superblock before the customer adds its route prefix into
the RPKI ... this happened with AT&T during testing, for example,
https://labs.ripe.net/Members/waehlisch/one-day-in-the-life-of-rpki



Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

Alex,

On Apr 29, 2012, at 8:16 AM, Alex Band wrote:
> All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.

I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override).

As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs.

Regards,
-drc

On 29/04/2012 16:16, Alex Band wrote:
> All in all, for an RPKI-specific court order to be effective in taking a
> network offline, the RIR would have to tamper with the registry, inject
> false data and try to make sure it's not detected so nobody applies a
> local override.

You mean, like an FBI domain seizure on the basis of a US court order?

Realistically, it doesn't matter a whole lot if the occasional network here
or there applies a local override. If their upstream transit provider
isn't carrying the prefix (on the basis of similar simultaneous court
orders), it's game over for that prefix.

Nick

On 29 Apr 2012, at 22:03, David Conrad wrote:

> Alex,
>
> On Apr 29, 2012, at 8:16 AM, Alex Band wrote:
>> All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.
>
> I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override).
>
> As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs.

Thanks David, I know that a court order doesn't have to specific. I just want to make people aware that in the case of RPKI, things are not as clear cut as "Revoked ROA = Offline network". It depends on many factors and I just want to offer a little perspective of what's involved.

-Alex

(P.S. I'm going on holiday for a week without internet access, so I won't be able to follow up on this thread for a while)

On 28/04/2012 14:04, Alex Band wrote:
> At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote
> on RPKI at the general meeting. The result was that the RIPE NCC has the
> green light to continue offering the Resource Certification service,
> including all BGP Origin Validation related functionality. It's correct
> that concerns were raised in the area of security, resilience and
> operator autonomy, as you mention. These concerns are continuously being
> evaluated and addressed. The response to the update that was given at
> RIPE 64 two weeks ago indicated that the membership and Community are
> happy with the approach the RIPE NCC is taking in this regard. Of course
> I realize that some people will never be convinced, no matter which
> steps are taken…

Alex, I have to take exception with your statement that people in the RIPE
region are generally happy about RPKI and the RIPE NCC RPKI project. They
aren't.

On the basis of some initial interest in the RIPE community several years
ago, the RIPE NCC embarked on a certification + rpki project. By way of
clarification for other readers of this mailing list, the RIPE NCC is a
Dutch company constituted to carry out the policy requirements of the RIPE
community. The way this is supposed to work is that the RIPE community
puts forward policy proposals, and the RIPE NCC carries these policies out.

Some time after the certification project was started in the NCC, a policy
proposal (2008-08) was floated in the RIPE community in order to turn this
into official RIPE policy, so that it could be formally carried out by the
RIPE NCC.

Mid last year, after extensive and heated discussion on the address policy
working group mailing list, that policy proposal was withdrawn from the
RIPE policy development process because it was clear that a large number of
people in the RIPE community were deeply uneasy about a variety of
implications. It is true that some of these concerns have been addressed
to some extent by the NCC, but the core issues of concern are fundamental
to RPKI.

Later that year, several potential proposals were put forward by the RIPE
NCC board at the Nov 2011 general meeting concerning the future of the RIPE
NCC certification project. The RIPE NCC members - who are a fee-paying
subset of the RIPE community - voted by 52% to 48% to keep funding the
project. By any objective measure, this is an alarmingly slim majority.

In short:

- a substantial number of people, both within the RIPE community and
within the RIPE NCC membership have serious concerns about the long-term
legal consequences of this project which have not (in their opinion) been
addressed adequately.

- the RIPE NCC is now funding a project for which there is no consensus
policy supported by the RIPE community, and is doing this on the basis of a
hair's breath majority vote amongst its membership.

Nick

> As Randy points out, this is not unique to SIDR-defined RPKI. It is
> applicable to any top-down hierarchical authorization mechanism.
> Security has (non-monetary) costs.

as this derives from address space ownership's dependence on the current
hierarchic administrative allocation model, to fix it merely change the
administrative model or our trust model that depends on that hierarchy.

randy

On 29 Apr 2012, at 22:50, Nick Hilliard wrote:

> On 28/04/2012 14:04, Alex Band wrote:
>> At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote
>> on RPKI at the general meeting. The result was that the RIPE NCC has the
>> green light to continue offering the Resource Certification service,
>> including all BGP Origin Validation related functionality. It's correct
>> that concerns were raised in the area of security, resilience and
>> operator autonomy, as you mention. These concerns are continuously being
>> evaluated and addressed. The response to the update that was given at
>> RIPE 64 two weeks ago indicated that the membership and Community are
>> happy with the approach the RIPE NCC is taking in this regard. Of course
>> I realize that some people will never be convinced, no matter which
>> steps are taken…
>
> Alex, I have to take exception with your statement that people in the RIPE
> region are generally happy about RPKI and the RIPE NCC RPKI project. They
> aren't.

That's not what I said. :)

> - a substantial number of people, both within the RIPE community and
> within the RIPE NCC membership have serious concerns about the long-term
> legal consequences of this project which have not (in their opinion) been
> addressed adequately.


I already linked to my RIPE64 presentation from two weeks ago before, but here it is again:
https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

Slide 2-4: we heard you. This is what I said:

>> The response to the update that was given at
>> RIPE 64 two weeks ago indicated that the membership and Community are
>> happy with the approach the RIPE NCC is taking in this regard.

This is where I suspect you may be:

>> I realize that some people will never be convinced, no matter which
>> steps are taken…

So all in all you quoted me well. :)

-Alex

Now getting in my car for some internet-free holidays in the sun. See you all in a week!

> free dinner at nanog/van for anyone who can explain how the dnssec
> approach meets the defcon attack. hint: it is a path attack, not an
> origin attack, and the dns pidgeon has no hooks to path attack
> prevention. at ripe, joe gersh asked me for an example of a path attack
> and i told him of the defcon demo. seems he also did not bother to do
> his homework. but it makes good pr.
....
> you are right, you have not done your homework. rpki-based origin
> validation asks no changes to bgp.

Free dinner to anyone who can explain how the RPKI piece of the SIDR
work resolves path attacks. You're comparing apples to oranges here.
Neither a DNS based solution nor the RPKI will resolve path attacks, so
neither apply to the type of attack you're talking about.

There are solutions for this sort of attack. Everything from completely
loose, community based solutions to totally control freak horrible
solutions, like BGP-SEC (and which doesn't really solve the problem anyway).

> yes. rpki can also have that issue as the certs can have urls that use
> domain names. i believe they could use ip address urls instead. but
> the gathering operation differs greatly between the rpki and the dnssec
> based proposal. with the latter, you can't even tell you have the full
> set.

The problem at hand is relying on routing to build the routing system.
How does using an IP address rather than a DNS based hostname change the
need for routing to work before routing can work?

Reality check: I don't know that this is all that important, in the end.
So long as you can use an IGP locally with a default route to reach a
copy of the database, whether it be based on DNS, an RPKI, or anything
else, then you can bootstrap your EGP routing. If everything goes down
at the same time, then you would just start rebuilding from the places
where the root servers live, no matter what system's root servers we're
talking about.

So I think this is a bit of a red herring at the EGP level.

> i do not like it either. but it is a trade you make for security. and,
> at ripe ljubljana, i think alex started to discuss some schemes to
> ameliorate it. more later on this.

The problem is worse than your initial estimate. A day's worth of
downtime can cost you your business in total, not just some lost revenue.

No matter whether or not you agree with the article's premise, at least
some provider folks are starting to ask some hard questions --which is a
good thing! Let's not shut the conversation down by making broad
proclamations about how the problem has been solved, "move along,
nothing to see here," etc. There is something to see here, so slow down
and take a look. Rubbernecking, in this case, is encouraged.

Russ


--
<>< Scripture Alone, Grace Alone, Faith Alone
http://thinkinginchrist.com/

On Mon, Apr 30, 2012 at 09:41:51AM -0400,
Russ White <russw@riw.us> wrote
a message of 60 lines which said:

> Neither a DNS based solution nor the RPKI will resolve path attacks,

I want to be sure of the terminology: what is deployed presently is
the bundle RPKI+ROA. As their name say, ROA can only be used against
origin attacks. But RPKI can be used for other things than RPKI+ROA,
including BGP-sec (against path-based attacks), no?

> I want to be sure of the terminology: what is deployed presently is
> the bundle RPKI+ROA. As their name say, ROA can only be used against
> origin attacks. But RPKI can be used for other things than RPKI+ROA,
> including BGP-sec (against path-based attacks), no?

wfm

>> Neither a DNS based solution nor the RPKI will resolve path attacks,
>
> I want to be sure of the terminology: what is deployed presently is
> the bundle RPKI+ROA. As their name say, ROA can only be used against
> origin attacks. But RPKI can be used for other things than RPKI+ROA,
> including BGP-sec (against path-based attacks), no?


The RPKI can provide the keying infrastructure on which a mechanism to
"protect the path," (controversial terminology in and of itself) could
be based. Is that the right basis for path validation? I don't know that
we should assume this. But key distribution is the easy part of the
problem here.

The hard part is determining what we're trying to protect and what the
tradeoffs are in trying to defend against those attacks. BGP-SEC assumes
we care about verifying the path a "routing object" takes through the
network, we don't much care about replay attacks, policy is off the
table (except one policy specific folks care about), and operators are
willing to replace their hardware specifically to resolve this problem.

Is this the right set of presuppositions to make? The provider
community, IMHO, hasn't really participated too much in this entire
discussion, so we don't really know the answers to this question.

Russ

> Reality check: I don't know that this is all that important, in the end.
> So long as you can use an IGP locally with a default route to reach a
> copy of the database, whether it be based on DNS, an RPKI, or anything
> else, then you can bootstrap your EGP routing. If everything goes down
> at the same time, then you would just start rebuilding from the places
> where the root servers live, no matter what system's root servers we're
> talking about.

or you wait for the Elders of the Internet to visit with blessings
http://www.youtube.com/watch?v=iDbyYGrswtg

brandon

Brandon Butterworth (brandon) writes:
>
> or you wait for the Elders of the Internet to visit with blessings
> http://www.youtube.com/watch?v=iDbyYGrswtg

Didn't randy just chime in ?

On Apr 28, 2012, at 6:34 AM, Alex Band wrote:

> All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.

We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area.

None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router.

-danny

[VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf

Danny,
just one more comment.

So named vendor's support can be the worst case when there are no practical ways to deploy and it is absolutely
not clear - should we follow this hierarchical model - I think it is the key point as we pushed ourselves by inertia to this way of thinking.


Imho - it is way to nowhere in such form

We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already.



On Apr 30, 2012, at 6:53 PM, Danny McPherson wrote:

>
> On Apr 28, 2012, at 6:34 AM, Alex Band wrote:
>
>> All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.
>
> We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area.
>
> None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router.
>
> -danny
>
> [VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf
>

> We need more flexible, distributed architecture behind - no matter -
> which interests will be lobbied as we have got already.

as i agree that there is a problem, i *very* eagerly await your proposal

randy

Personally I find the BitTorrent approach interesting.

Jared Mauch

On Apr 30, 2012, at 11:46 AM, Randy Bush <randy@psg.com> wrote:

>> We need more flexible, distributed architecture behind - no matter -
>> which interests will be lobbied as we have got already.
>
> as i agree that there is a problem, i *very* eagerly await your proposal
>
> randy

Randy -
you know that I'm enough stupid- means straightforward -

may be the way is not only technical (recomendations design) - but also to combine with some policy changes as
splitting allocations and assignments (may be changing who is responsible for what?)

Or we follow the traditional way(means hierarchy) or we are capable to introduce one more
level for flexebility - we should be honest that all techinical design just follows some political or quasi-political decisions.
But I think it can be changed.

Dima
On Apr 30, 2012, at 7:46 PM, Randy Bush wrote:

>> We need more flexible, distributed architecture behind - no matter -
>> which interests will be lobbied as we have got already.
>
> as i agree that there is a problem, i *very* eagerly await your proposal
>
> randy

* Alex Band:

> All in all, for an RPKI-specific court order to be effective in
> taking a network offline, the RIR would have to tamper with the
> registry, inject false data and try to make sure it's not detected
> so nobody applies a local override.

Please keep in mind that this is what's happening with DNS: registries
are not only forced by the courts to remove delegations, but to
delegate names to specific parties.

On the other hand, it's not entirely clear whether this is such a bad
thing.

On Mon, Apr 30, 2012 at 11:51 AM, Jared Mauch <jared@puck.nether.net> wrote:
> Personally I find the BitTorrent approach interesting.

this conflates the 2 (at least!) topics here:
1) distribution of repository data
2) heirarchy of authority for the data which is in the repository

-chris

> On Apr 30, 2012, at 11:46 AM, Randy Bush <randy@psg.com> wrote:
>
>>> We need more flexible, distributed architecture behind - no matter -
>>> which interests will be lobbied as we have got already.
>>
>> as i agree that there is a problem, i *very* eagerly await your proposal
>>
>> randy
>

Randy:

> as i agree that there is a problem, i *very* eagerly await your proposal

Reality: A few years back there were a half a dozen options proposed.
soBGP, pgBGP, IRR based solutions, etc. Just recently PSVs were
discussed and dismissed as a live option.

Why?

1. Only S-BGP/BGP-SEC will solve the "man in the middle attack," within
the parameter of "I won't ever tell anyone what any of my policies are!"
This single requirement --solving one specific policy issue without
advertising policy-- has been the center pin of the entire discussion
for a number of years.

2. Any time someone proposed something different, long threads ensue
with lots of talk about how these folks don't know what they're talking
about, etc., but which contain very little technical discussion, or
thoughts on tradeoffs, etc. Any technical discussion is limited to
taking out the "man in the middle attack," and beating it over the heads
of those making the proposal --repeatedly.

So the bottom line is this: The current requirements were written around
the ability of one particular solution to solve one particular policy
issue in a way that's acceptable to a very small set of operators.

A single root has been a requirement for a long time, as well --we had
this discussion a very long time ago. No other solution proposed had a
single root, and S-BGP/BGP-SEC didn't have to use a single root. But a
single root somehow made it into the requirements, and it's stayed there
ever since.

If you want honestly more options, go back and rethink your requirements.

Russ

On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:

> is anybody taking it seriously?

It's hard to take seriously any proposal which is predicated upon recursive dependencies.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:

> People might scared to rely on DNS on accepting routes, but is this really an issue?

Yes, recursive dependencies are an issue. I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton