If only there were a global system, with consistent and verifiable security
properties, to permit address holders to declare the set of AS's authorized
to announce their prefixes, and routers anywhere on the Internet to
independently verify the corresponding validity of received announcements.
*cough https://www.nanog.org/meetings/abstract?id=2846 cough*
Scott and Doug,
The problem with a new automated enforcement system is that it hobbles both agility and innovation. ISPs have enjoyed simple BGP management, entirely self-regulated, for decades. A global enforcement system, besides being dang hard to do correctly, brings the specter of government interference, since such a system could be overtaken by government entities to manhandle free speech.
In my opinion, the community hasn't spent nearly enough time discussing the danger aspect. Being engineers, we focus on technical means, ignoring the fact that we're designing our own guillotine.
-mel beckman
Mel,
If you are speaking of RPKI based origin validation, I am not sure
"automated / global enforcement system" is a useful description. It does
provide a consistent means for address holders to declare AS's authorized
to announce prefixes, and a means for remote ASs to compare received
updates vs such declarations. What the receiving AS does with the
validation information is strictly a local policy matter.
Frankly, this is no more a "new automated enforcement system" than
IRR-based route filtering has been for 20 years. The only difference is
that there is a consistent security model across all 5 RIRs as to who can
make such declarations and it is tightly tied to the address allocation
business process.
I have seen a lot of FUD about the specter of interference, but not a lot
of serious thought / discussion. Having a serious technical discussion of
potential risks and mitigations in the system would be useful.
dougm
I got to think about this (dangerous thing 
Ideally, law enforcement should have the smarts and tools to get
involved in DDoS and other similar situations and have the power to
compell upstream provider(s) to shut service to a suspect.
The current situation appears to be more of a wild-west situation where
everyone takes the law into their own hands. It sort of works but
everyone knows this lead lead to abuses.
If you start to tolerate falsifying BGP, it will likely lead to regular
abuses (including intelligence agencies who stad to gain by redirecting
traffic to their servers) as well as corporate spies etc. So mechanisms
to enforce 0 tolerance are perhaps necessary, even if this means that a
few legitimate BGP tricks to save customers from a failing ISP will no
longer work.
Falsifying BGP can be done by one person without any sanity checks.
There is no check for evidence or whether this action is warranted. On
the other hand, there is a sanity check if you have to convince an
upstream provider to cut access to one of their customers.
Problem is, RPKI does not work for people with legacy blocks who will not sign
a Legacy RSA. ARIN doesn't own or have any say on how we use it, and we're
sure as heck not going to sign a legally binding contract saying they do 
I'm a bit ambivalent about BGP hijacking as a DDOS mitigation strategy.
Really there is no authority to say it's wrong. If your peers are cool with
it, and their peers are cool with it who's to say it's wrong?
>
> Yes, RPKI. That's what I was waiting for. Now we can get to
> a real discussionProblem is, RPKI does not work for people with legacy blocks who will not
sign
a Legacy RSA. ARIN doesn't own or have any say on how we use it, and we're
sure it does, move your registration to ripe.
<http://www.iepg.org/2016-04-03-ietf95/160403.iepg-transfer.pdf>
(this was also given at nanog or ripe or something, I couldn't remember
which was the right one)
sure as heck not going to sign a legally binding contract saying they do
don't have to... see preso.
Doug,
I was basing my comments on your statement "If only there were a global system.." However you slice or dice it, the tyranny implications have not yet been addressed. That certainly needs to be in front of any technical idea such as RPKI.
Although I haven't participated in the OT&E, nothing I've read in RFC 6810 talks about these issues. It talks about authentication and transport security, but doesn't talk about the potential for government interference.
-mel beckman
Mel,
If you are speaking of RPKI based origin validation, I am not sure "automated / global enforcement system" is a useful description. It does provide a consistent means for address holders to declare AS's authorized to announce prefixes, and a means for remote ASs to compare received updates vs such declarations. What the receiving AS does with the validation information is strictly a local policy matter.
Frankly, this is no more a "new automated enforcement system" than IRR-based route filtering has been for 20 years. The only difference is that there is a consistent security model across all 5 RIRs as to who can make such declarations and it is tightly tied to the address allocation business process.
I have seen a lot of FUD about the specter of interference, but not a lot of serious thought / discussion. Having a serious technical discussion of potential risks and mitigations in the system would be useful.
dougm
Scott and Doug,
The problem with a new automated enforcement system is that it hobbles both agility and innovation. ISPs have enjoyed simple BGP management, entirely self-regulated, for decades. A global enforcement system, besides being dang hard to do correctly, brings the specter of government interference, since such a system could be overtaken by government entities to manhandle free speech.
In my opinion, the community hasn't spent nearly enough time discussing the danger aspect. Being engineers, we focus on technical means, ignoring the fact that we're designing our own guillotine.
-mel beckman
Meeting abuse with abuse never works out. It's tempting (and even
trendy these days in portions of the security world which advocate
striking back at putative attackers, never mind that attack attribution
is almost entirely an unsolved problem in computing). It's emotionally
satisfying. It's sometimes momentarily effective.
But all it really does it open up still more attack vectors and accelerate
the spiral to the bottom. Object lesson: Verizon's deployment of SAV
as an alleged anti-spam measure ~15 years ago. It didn't take long for
attackers to figure out how to leverage it to their advantage, which of
course they did.
So don't do it. It may take 5 minutes or 5 years, but it will eventually
become apparent that it's a really bad idea. And when it does, you won't
be able to get those 5 minutes or 5 years back, nor will you be able to
undo the damage.
---rsk
Ah, the global system I was referring to was the RPKI as distributed
repository of routing information. With consistent properties (data
formats, security models, data validation techniques, etc) across all 5
RIRs.
What an ISP does with the RPKI data, interns of route filtering, is always
a local policy decision. Somehow "global enforcement system" sounded
like a vision where ISPs don't have a choice of how and where to use the
system. Maybe I read too much into the phrasing.
In the end, I think the issues boils down to if the community has the
desire and will to address the route hijack issue. If the answer is no,
then no further discussion is needed. If the answer is yes, then it is
best to discuss and compare real proposals / mechanisms to address the
issue at scale.
I am still interested in some detail on the "tyranny implications". We
can't address them until we know what they are and how they compare to any
other solution that tries to address the same problem.
dougm
Doug,
Although RPKI is voluntary and decisions are local, those decisions are also automated. DNS is voluntary, and decisions are local as well, yet the government has been able to leverage DNS to unilaterally seize domain names without due process. Like Maxwell's Demons, it's theoretically possible for ISPs everywhere to notice government malfeasance and rush to a unified decision to counter it. But in practice this never happens.
Preventing government manhandling needs to be a design goal.
-mel beckman
Ah, the global system I was referring to was the RPKI as distributed repository of routing information. With consistent properties (data formats, security models, data validation techniques, etc) across all 5 RIRs.
What an ISP does with the RPKI data, interns of route filtering, is always a local policy decision. Somehow "global enforcement system" sounded like a vision where ISPs don't have a choice of how and where to use the system. Maybe I read too much into the phrasing.
In the end, I think the issues boils down to if the community has the desire and will to address the route hijack issue. If the answer is no, then no further discussion is needed. If the answer is yes, then it is best to discuss and compare real proposals / mechanisms to address the issue at scale.
I am still interested in some detail on the "tyranny implications". We can't address them until we know what they are and how they compare to any other solution that tries to address the same problem.
dougm
Doug,
I was basing my comments on your statement "If only there were a global system.." However you slice or dice it, the tyranny implications have not yet been addressed. That certainly needs to be in front of any technical idea such as RPKI.
Although I haven't participated in the OT&E, nothing I've read in RFC 6810 talks about these issues. It talks about authentication and transport security, but doesn't talk about the potential for government interference.
-mel beckman
Mel,
If you are speaking of RPKI based origin validation, I am not sure "automated / global enforcement system" is a useful description. It does provide a consistent means for address holders to declare AS's authorized to announce prefixes, and a means for remote ASs to compare received updates vs such declarations. What the receiving AS does with the validation information is strictly a local policy matter.
Frankly, this is no more a "new automated enforcement system" than IRR-based route filtering has been for 20 years. The only difference is that there is a consistent security model across all 5 RIRs as to who can make such declarations and it is tightly tied to the address allocation business process.
I have seen a lot of FUD about the specter of interference, but not a lot of serious thought / discussion. Having a serious technical discussion of potential risks and mitigations in the system would be useful.
dougm
Scott and Doug,
The problem with a new automated enforcement system is that it hobbles both agility and innovation. ISPs have enjoyed simple BGP management, entirely self-regulated, for decades. A global enforcement system, besides being dang hard to do correctly, brings the specter of government interference, since such a system could be overtaken by government entities to manhandle free speech.
In my opinion, the community hasn't spent nearly enough time discussing the danger aspect. Being engineers, we focus on technical means, ignoring the fact that we're designing our own guillotine.
-mel beckman
Can you proffer some potential solutions or directions to look?
At the end of the day the ISP or DNS operator or Enterprise is subject to
local law enforcement action(s), so I'm not sure there's a remedy to your
design goal.
Chris -
To be clear, he would still end up bound to an agreement which provides that they
indemnify the RIR regarding their RPKI usage (which was the complaint expressed
in the NANOG community regarding ARIN’s RPKI terms and conditions) -
<https://www.ripe.net/manage-ips-and-asns/resource-management/certification/legal/ripe-ncc-certification-service-terms-and-conditions>
"The Member shall indemnify the RIPE NCC against any and all third party claims filed against the RIPE NCC in relation to the Member’s use of the RIPE NCC Certification Service or the Certificate.”
FYI,
/John
John Curran
President and CEO
ARIN
(caution! I don't really think arin is evil!)
>
>
>>>
>>> Yes, RPKI. That's what I was waiting for. Now we can get to
>>> a real discussion
>> ...
>> sure as heck not going to sign a legally binding contract saying they
do
>>
> don't have to... see press.Chris -
To be clear, he would still end up bound to an agreement which provides
that they
indemnify the RIR regarding their RPKI usage (which was the complaint
expressed
in the NANOG community regarding ARIN’s RPKI terms and conditions) -
maybe, but his point was that the evil (evile?) arin would not be putting
their clutches on his ip-address-spaces... Sure he's trading ARIN for RIPE
here, but I diidn't think the RPA bit was his concern as much as the LRSA
and 'now that you agree these are ip blocks are subject to the legacy
registry services agreement, we (arin - with twisty mustasche) might decide
to wrest them away from you!!!<muahahahahaa!>'
I may have misinterpreted his issue, or not completed his unwritten thought
about the RPA.
<https://www.ripe.net/manage-ips-and-asns/resource-management/certification/
(caution! I don't really think arin is evil!)
Nor do I… (but I will remind folks that organizations evolve based on participation,
so ongoing diligence and involvement is definitely warranted.)
To be clear, he would still end up bound to an agreement which provides
that they
indemnify the RIR regarding their RPKI usage (which was the complaint
expressed
in the NANOG community regarding ARIN’s RPKI terms and conditions) -maybe, but his point was that the evil (evile?) arin would not be putting
their clutches on his ip-address-spaces... Sure he's trading ARIN for RIPE
here, but I diidn't think the RPA bit was his concern as much as the LRSA
and 'now that you agree these are ip blocks are subject to the legacy
registry services agreement, we (arin - with twisty mustasche) might decide
to wrest them away from you!!!<muahahahahaa!>’
A distinct possibly, but much improved in the current LRSA (and RSA, which
are the same document at this point.) Unless he’s planning to not pay the
annual maintenance fee and ignore the notices and letters that follow over
the next 120 days, or if going to make a serious misrepresentation in the
process of claiming the rights to the address block, he’s fairly safe... for
example, ARIN now specifically disclaims revocation for lack of utilization.
(Furthermore, if ARIN breaches its obligations, the status of the address
block reverts to the same prior to entry the LRSA – this is definitely less
than RIPE provides, which is effectively exit at any time, but far better than
the original LRSA.)
If you want to just use your legacy address block (wth the same services that
where in place at ARIN’s formation), then you don’t need to enter into an LRSA –
but please do still update your registration in the ARIN registry to have current
contact data, as this helps deter potential hijackers. If you want to have those
services that were developed since ARIN’s formation, then I’d suggest reviewing
the actual current LRSA agreement, as it is significantly improved over earlier
versions.
Thanks!
/John
John Curran
President and CEO
[Evil?] ARIN
>
> (caution! I don't really think arin is evil!)Nor do I… (but I will remind folks that organizations evolve based on
participation,
so ongoing diligence and involvement is definitely warranted.)>
>> To be clear, he would still end up bound to an agreement which provides
>> that they
>> indemnify the RIR regarding their RPKI usage (which was the complaint
>> expressed
>> in the NANOG community regarding ARIN’s RPKI terms and conditions) -
>>
>>
> maybe, but his point was that the evil (evile?) arin would not be putting
> their clutches on his ip-address-spaces... Sure he's trading ARIN for
RIPE
> here, but I diidn't think the RPA bit was his concern as much as the LRSA
> and 'now that you agree these are ip blocks are subject to the legacy
> registry services agreement, we (arin - with twisty mustasche) might
decide
> to wrest them away from you!!!<muahahahahaa!>’A distinct possibly, but much improved in the current LRSA (and RSA, which
are the same document at this point.) Unless he’s planning to not pay the
annual maintenance fee and ignore the notices and letters that follow over
the next 120 days, or if going to make a serious misrepresentation in the
process of claiming the rights to the address block, he’s fairly safe...
for
example, ARIN now specifically disclaims revocation for lack of
utilization.
(Furthermore, if ARIN breaches its obligations, the status of the address
block reverts to the same prior to entry the LRSA – this is definitely less
than RIPE provides, which is effectively exit at any time, but far better
than
the original LRSA.)If you want to just use your legacy address block (wth the same services
that
where in place at ARIN’s formation), then you don’t need to enter into an
LRSA –
but please do still update your registration in the ARIN registry to have
current
contact data, as this helps deter potential hijackers. If you want to
have those
services that were developed since ARIN’s formation, then I’d suggest
reviewing
the actual current LRSA agreement, as it is significantly improved over
earlier
versions.
and probably: "If you think there are still improvements, show up at arin
meetings and lobby for change"
yes?
...
If you want to just use your legacy address block (wth the same services that
where in place at ARIN's formation), then you don't need to enter into an LRSA -
but please do still update your registration in the ARIN registry to have current
contact data, as this helps deter potential hijackers. If you want to have those
services that were developed since ARIN's formation, then I'd suggest reviewing
the actual current LRSA agreement, as it is significantly improved over earlier
versions.
and probably: "If you think there are still improvements, show up at arin meetings and lobby for change"
yes?
Absolutely.
/John