"The problem: Border Gateway Protocol (BGP) enables routers to
communicate about the best path to other networks, but routers don't
verify the route 'announcements.' When routing problems erupt, 'it's
very difficult to tell if this is fat fingering on a router or
malicious
<http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem>,'
said Joe Gersch, chief operating officer for Secure64, a company that
makes Domain Name System (DNS) server software. In a well-known
incident, Pakistan Telecom made an error with BGP after Pakistan's
government ordered in 2008 that ISPs block YouTube, which ended up
knocking Google's service offline
<http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world>\.
A solution exists, but it's complex, and deployment has been slow. Now
experts have found an easier way."
this seems late, compared to the various commitments made to rpki in
recent years. is anybody taking it seriously?
> "The problem: Border Gateway Protocol (BGP) enables routers to
> communicate about the best path to other networks, but routers don't
> verify the route 'announcements.' When routing problems erupt, 'it's
> very difficult to tell if this is fat fingering on a router or
> malicious
> <
,'
> said Joe Gersch, chief operating officer for Secure64, a company that
> makes Domain Name System (DNS) server software. In a well-known
> incident, Pakistan Telecom made an error with BGP after Pakistan's
> government ordered in 2008 that ISPs block YouTube, which ended up
> knocking Google's service offline
> <
.
> A solution exists, but it's complex, and deployment has been slow. Now
> experts have found an easier way."
this seems late, compared to the various commitments made to rpki in
recent years. is anybody taking it seriously?
Taking what seriously ? The commitments to rpki you speak off ?
Late is a relative term.
It does not matter if the cat is white or black, as long as it cathes the
rat.
this seems late, compared to the various commitments made to rpki in
recent years. is anybody taking it seriously?
The idea as such isn't new, this has been floating around for four
years or more, including at least one Internet draft,
draft-donnerhacke-sidr-bgp-verification-dnssec.
I don't know if we can get RPKI to deployment because RIPE and RIPE
NCC have rather serious issues with it. On the other hand, there
doesn't seem to be anything else which keeps RIRs relevant in the
post-scarcity world, so we'll see what happens.
The idea as such isn't new, this has been floating around for four
years or more, including at least one Internet draft,
draft-donnerhacke-sidr-bgp-verification-dnssec.
(disclaimer I'm almost completely clueless on RPKI).
If two fails don't make win, then I think ROVER is better solution, doesn't
need any changes to BGP just little software magic when accepting routes.
People might scared to rely on DNS on accepting routes, but is this really
an issue? I'd anyhow prefer to run verification in 'relaxed' mode, where
routes which fail authorization are logged but accepted if there wasn't
pre-existing covering route. Only drop routes if they fail authorization
_AND_ there is pre-existing covering route.
Maybe after several more years of experience and working out kinks, I could
dare to try to run verification in 'strict' more. But 'relaxed' more
already would stop the real-life problems we've seen of route-hijackings. I
don't care much about unannounced net used for spamming really.
Nick Hilliard mentioned in other forum to me bootstrapping problem. DNS
would then be inherently part of your NMS, so install DNS in your NMS, and
NMS already exists in IGP. So infra for verification should be up, before
BGP is up.
I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the discussion afterwards, it looks like it's just an old idea that was brought to the table again, with a few early adopters experimenting.
In the linked article Gersh says that RPKI is complex and deployment has been slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 2011, adoption has been incredibly good (for example compared to IPv6 and DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate using the hosted service, or running an open source package with their own CA.
But it's not just that, these ISPs didn't just blindly get certificate and walk away. There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses worth of BGP announcements. Data quality is really good. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.
I don't know if we can get RPKI to deployment because RIPE and RIPE
NCC have rather serious issues with it. On the other hand, there
doesn't seem to be anything else which keeps RIRs relevant in the
post-scarcity world, so we'll see what happens.
Could you elaborate on what those issues are?
A year ago, RIPE NCC received legal advice that RPKI-based takedowns
would not happen under Dutch law because Dutch law lacked any
provisions for that. This was used to deflect criticism that RPKI
deployment would result in too much concentration of power:
The legal analysis turned out to be incomplete and the results
incorrect---legal counsel failed to consider public order legislation.
The validaty of such an order (issued in the Dnschanger context) is
currently being challenged in a Dutch court.
From the comments on these events, I infer that RIPE NCC still does
not want to exercise this level of control over routing, and the RIPE
community does not want RIPE to have such control. But assuming that
the order stands, RPKI will provide RIPE NCC with a tool that nobody
wants it to have, and RIPE NCC can be forced to use it. Depending on
the seriousness of those concerns, that's the end of RPKI deployment.
(However, the most likely outcome of the current court case is that
this particular police order will be found invalid on a formality,
such as lack of effectiveness, providing little insight on the
validity of future orders which are more carefully crafted.)
Regarding the post-scarcity future, if most address holders never have
to come back to the RIR to request more addresses, the number of
address-related RIR/LIR transactions will decrease. Organizations
have a tendency to resist decreases in business (even non-profits),
and RPKI is an obvious source of future business.
Unfortunately, we have RFCs for good ideas but bad ideas never get
documented by the IETF (one of the few exceptions is RFC 3197). So,
bad ideas keep coming back and back again.
Would you explain in a few words why this was a bad idea? I personally
find Rover a very interesting idea, and which seems realistic.
In reality, since the RIRs launched an RPKI production service on 1
Jan 2011, adoption has been incredibly good (for example compared to
IPv6 and DNSSEC). More than 1500 ISPs and large organizations
world-wide have opted-in to the system and requested a resource
certificate using the hosted service, or running an open source
package with their own CA.
I have an experience with the deployment of DNSSEC and the problem
with DNSSEC was not to have signed zones (many are, now) but to have
people *using* these signatures to check the data (i.e. validating in
a resolver).
RPKI has many ROA (signed objects) but how many operators validate
routes on their production routers? Zero?
But it's not just that, these ISPs didn't just blindly get
certificate and walk away.
Most of the ROAs are very recent. Again, the experience with DNSSEC
shows that starting is easy ("DNSSEC in siw minutes"). It's long term
management which is *the* problem. Wait until people start to change
the routing data and watch the ROAs becoming less and less correct...
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…
Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER and the IRR facilitate is merely the ability make a *statement* about routing (with varying degrees of reliability) and doesn't have a direct impact on BGP routing itself. Ultimately, it is up to the network operator to interpret the data that is entered in the system, allow them to make an informed decision and take action they deem appropriate. Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for. In the toolsets for using the RPKI data set for routing decisions, such as the RIPE NCC RPKI Validator, every possible step is taken is taken to ensure that the operator is in the driver's seat.
I think ROVER is better solution, doesn't need any changes to BGP
just little software magic when accepting routes.
I like Rover but RPKI+ROA does not change BGP either (it will be a
different story with BGPsec).
People might scared to rely on DNS on accepting routes, but is this
really an issue?
RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository
will work only if DNS works. Not a problem in practice, since route
origins do not change every minute and the validating ROA cache can
work even if it can no longer update its data. Same thing with Rover:
temporary glitches in the DNS are not a practical problem (the router
keeps the old info).
routes which fail authorization are logged but accepted if there
wasn't pre-existing covering route. Only drop routes if they fail
authorization _AND_ there is pre-existing covering route.
It is a bit more complicated: more-specific attacks, and so on. But,
yes, you're right. As Alex Band says, Rover, RPKI and the IRR make
(authenticated) statements about route origins. You then do what you
want (what your boss wants? what the FBI wants?) with these statements
(route-map, etc).
In reality, since the RIRs launched an RPKI production service on 1
Jan 2011, adoption has been incredibly good (for example compared to
IPv6 and DNSSEC). More than 1500 ISPs and large organizations
world-wide have opted-in to the system and requested a resource
certificate using the hosted service, or running an open source
package with their own CA.
I have an experience with the deployment of DNSSEC and the problem
with DNSSEC was not to have signed zones (many are, now) but to have
people *using* these signatures to check the data (i.e. validating in
a resolver).
RPKI has many ROA (signed objects) but how many operators validate
routes on their production routers? Zero?
First you need a robust system and reliable data. Native router support is coming along. We could be getting to a stage where people will use the data in production. Time will tell...
But it's not just that, these ISPs didn't just blindly get
certificate and walk away.
Most of the ROAs are very recent. Again, the experience with DNSSEC
shows that starting is easy ("DNSSEC in siw minutes"). It's long term
management which is *the* problem. Wait until people start to change
the routing data and watch the ROAs becoming less and less correct...
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.
someone selling dnssec appliances flew a press release that a few
reporters bought without doing their homework. end of net predicted,
news at eleven.
Taking what seriously ? The commitments to rpki you speak off ?
a thousand LIRs in the ripe region, 500 elsewhere? cisco code shipping
on a number of platforms, juniper soon. some of us have actually
started validating route origins in the real network using rpki and
cisco and juniper (test) code.
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.
But this was done outside the Policy Development Process, which is
supposed to handle such things.
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.
I don't think so. Ultimately, it does not seem to be possible to get
this through the PDP.
The whole discussion is a bit odd: Even without RPKI, RIPE NCC already
has the power to directly influence global routing because it's
unreasonable to expect that the majority of their BGP peers employ
strict filtering. So they could inject more specifics as they see
fit, and thus blackhole pretty arbitrary chunks of address space.
However, so can most folks who of those who control routers in the
DFZ, and RPKI (or something similar) would change that at least.
Leaving aside technical matters, this is one of the more contentious
political issues with RPKI. RPKI is a tool which can be used to locally
influence routing decisions, but allows centralised control of prefix
authenticity. If this central point is influenced to invalidate a specific
prefix, then that will cause serious reachability problems for that prefix
on the Internet.
It will be difficult for politicians / legislators / LEAs to look at a
technology like this and not see its potential for implementing wide-area
Internet blocking. For sure, the LEAs currently looking at it are
extremely interested.
Leaving aside technical matters, this is one of the more contentious
political issues with RPKI. RPKI is a tool which can be used to locally
influence routing decisions, but allows centralised control of prefix
authenticity. If this central point is influenced to invalidate a specific
prefix, then that will cause serious reachability problems for that prefix
on the Internet.
To me that seems like the most obvious problem, but as Alex put it,
"Everyone has the ability to apply an override on data they do not trust,
or have a specific local policy for."
It will be difficult for politicians / legislators / LEAs to look at a
technology like this and not see its potential for implementing wide-area
Internet blocking.
For sure, the LEAs currently looking at it are extremely interested.
