Re: "Defensive" BGP hijacking?
--- dougm.work@gmail.com wrote: From: Doug Montgomery <dougm.work@gmail.com> 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* ------------------------------------------------ Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-) scott
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
On Sep 14, 2016, at 12:10 AM, Scott Weeks <surfer@mauigateway.com> wrote:
--- dougm.work@gmail.com wrote: From: Doug Montgomery <dougm.work@gmail.com>
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* ------------------------------------------------
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-)
scott
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 On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <mel@beckman.org> wrote:
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
On Sep 14, 2016, at 12:10 AM, Scott Weeks <surfer@mauigateway.com> wrote:
--- dougm.work@gmail.com wrote: From: Doug Montgomery <dougm.work@gmail.com>
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* ------------------------------------------------
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-)
scott
-- DougM at Work
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 On Sep 14, 2016, at 8:22 AM, Doug Montgomery <dougm.work@gmail.com<mailto:dougm.work@gmail.com>> wrote: 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 On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: 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
On Sep 14, 2016, at 12:10 AM, Scott Weeks <surfer@mauigateway.com<mailto:surfer@mauigateway.com>> wrote:
--- dougm.work@gmail.com<mailto:dougm.work@gmail.com> wrote: From: Doug Montgomery <dougm.work@gmail.com<mailto:dougm.work@gmail.com>>
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* ------------------------------------------------
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-)
scott
-- DougM at Work
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 On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman <mel@beckman.org> wrote:
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
On Sep 14, 2016, at 8:22 AM, Doug Montgomery <dougm.work@gmail.com> wrote:
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
On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <mel@beckman.org> wrote:
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
On Sep 14, 2016, at 12:10 AM, Scott Weeks <surfer@mauigateway.com> wrote:
--- dougm.work@gmail.com wrote: From: Doug Montgomery <dougm.work@gmail.com>
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* ------------------------------------------------
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-)
scott
-- DougM at Work
-- DougM at Work
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 On Sep 16, 2016, at 8:32 AM, Doug Montgomery <dougm.work@gmail.com<mailto:dougm.work@gmail.com>> wrote: 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 On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: 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 On Sep 14, 2016, at 8:22 AM, Doug Montgomery <dougm.work@gmail.com<mailto:dougm.work@gmail.com>> wrote: 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 On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman <mel@beckman.org<mailto:mel@beckman.org>> wrote: 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
On Sep 14, 2016, at 12:10 AM, Scott Weeks <surfer@mauigateway.com<mailto:surfer@mauigateway.com>> wrote:
--- dougm.work@gmail.com<mailto:dougm.work@gmail.com> wrote: From: Doug Montgomery <dougm.work@gmail.com<mailto:dougm.work@gmail.com>>
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* ------------------------------------------------
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion... ;-)
scott
-- DougM at Work -- DougM at Work
On Fri, Sep 16, 2016 at 12:06 PM, Mel Beckman <mel@beckman.org> wrote:
Preventing government manhandling needs to be a design goal.
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.
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.
On 9/14/16 3:09 AM, Scott Weeks wrote:
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion
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? -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
On 9/14/16 3:09 AM, Scott Weeks wrote:
Yes, RPKI. That's what I was waiting for. Now we can get to a real discussion
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 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.
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?
-- Bryan Fields
727-409-1194 - Voice http://bryanfields.net
On Sep 14, 2016, at 4:59 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields <Bryan@bryanfields.net> wrote:
On 9/14/16 3:09 AM, Scott Weeks wrote:
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) - <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!) On Mon, Sep 19, 2016 at 1:16 PM, John Curran <jcurran@arin.net> wrote:
On Sep 14, 2016, at 4:59 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 14, 2016 at 4:04 PM, Bryan Fields <Bryan@bryanfields.net>
wrote:
On 9/14/16 3:09 AM, Scott Weeks wrote:
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/
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
On Sep 19, 2016, at 11:58 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
(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.)
On Mon, Sep 19, 2016 at 1:16 PM, John Curran <jcurran@arin.net> wrote:
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
On Tue, Sep 20, 2016 at 8:05 AM, John Curran <jcurran@arin.net> wrote:
On Sep 19, 2016, at 11:58 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
(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.)
On Mon, Sep 19, 2016 at 1:16 PM, John Curran <jcurran@arin.net> wrote:
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?
Thanks! /John
John Curran President and CEO [Evil?] ARIN
On Sep 20, 2016, at 10:48 AM, Christopher Morrow <morrowc.lists@gmail.com<mailto:morrowc.lists@gmail.com>> wrote: On Tue, Sep 20, 2016 at 8:05 AM, John Curran <jcurran@arin.net<mailto:jcurran@arin.net>> wrote: ... 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
On Wed, Sep 14, 2016 at 04:04:43PM -0400, Bryan Fields wrote:
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?
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
participants (8)
-
Bryan Fields -
Christopher Morrow -
Doug Montgomery -
Jean-Francois Mezei -
John Curran -
Mel Beckman -
Rich Kulawiec -
Scott Weeks