Re: NANOG Security Track: Route Security
Hi all, Speaking as presenter in this track, I’d be fine with video recording and online distribution. In fact, I’d encourage it, I don’t assume any secrecy or confidentiality in this meeting. Perhaps for the NANOG74 meeting it is too late to organize video recording, but going forward I’m a proponent of recording everything. It creates more value for both the presenters and the global community. Kind regards, Job
Re: NANOG Security Track: Route Security
Agreed, especially if they’re an active member of the organization and doesn’t seem to be synonymous with NANOGs Charter. Jason On Sep 30, 2018, at 22:41, Brian Kantor wrote: >> To ensure unimpeded information sharing and discussion, the >> Security Track will not be broadcast or recorded. > > I fail to understand how making the presentations secret from all > except those attending in person promotes information sharing. > Could whoever made this seemingly contradictory decision explain > the reasoning behind it? >- Brian >
Re: NANOG Security Track: Route Security
> To ensure unimpeded information sharing and discussion, the > Security Track will not be broadcast or recorded. I fail to understand how making the presentations secret from all except those attending in person promotes information sharing. Could whoever made this seemingly contradictory decision explain the reasoning behind it? - Brian
RE: NANOG Security Track: Route Security
Just like how all the email threads on NANOG are archived, all talks should be archived as well. Ryan Hamel From: NANOG On Behalf Of Krassimir Tzvetanov Sent: Sunday, September 30, 2018 3:31 PM To: Sam Oduor Cc: NANOG mailing list Subject: Re: NANOG Security Track: Route Security Sam, To ensure unimpeded information sharing and discussion, the Security Track will not be broadcast or recorded. I apologise for the inconvenience. Regards, Krassimir On Sun, Sep 30, 2018, 1:05 PM Sam Oduor mailto:sam.od...@gmail.com>> wrote: Hi Any online link available for remote participation or viewing ? On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov mailto:mailli...@krassi.biz>> wrote: Hello Everyone, I wanted to attract your attention to the Security Track this coming NANOG. We'll be meeting on Tuesday morning and the line up looks like this: * Andre Toonk - examples of hijacks, other ideas * Alexander Azimov - State of BGP Security * David Wishnick - ARIN TAL * Job Snijders - Routing security roadmap * Chris Morrow - So I need to start filtering routes from peers...' and 'hey guess who needs to update their IRR data?' Time permitting at the end of the time slot we'll have a panel and time for duscussion as well. Regards, Krassi -- Samson Oduor
Re: NANOG Security Track: Route Security
Sam, To ensure unimpeded information sharing and discussion, the Security Track will not be broadcast or recorded. I apologise for the inconvenience. Regards, Krassimir On Sun, Sep 30, 2018, 1:05 PM Sam Oduor wrote: > Hi > > Any online link available for remote participation or viewing ? > > On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov > wrote: > >> Hello Everyone, >> >> I wanted to attract your attention to the Security Track this coming >> NANOG. We'll be meeting on Tuesday morning and the line up looks like this: >> * Andre Toonk - examples of hijacks, other ideas >> * Alexander Azimov - State of BGP Security >> * David Wishnick - ARIN TAL >> * Job Snijders - Routing security roadmap >> * Chris Morrow - So I need to start filtering routes from peers...' and >> 'hey guess who needs to update their IRR data?' >> >> Time permitting at the end of the time slot we'll have a panel and time >> for duscussion as well. >> >> Regards, >> Krassi >> >> > > -- > Samson Oduor >
Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)
Folks - Perhaps it would be helpful to confirm that we have common goals in the network operator community regarding RPKI, and then work from those goals on the necessary plans to achieve them. It appears that many network operators would like to improve the integrity of their network routing via RPKI deployment. The Regional Internet Registries (RIRs) have all worked to support RPKI services, and while there are different opinions among operators regarding the cost/benefit tradeoffs of RPKI Route Origin Validation (ROV), it is clear that we have to collectively work together now if we are ever to have overall RPKI deployment sufficient to create the network effects that will ensure compelling long-term value for its deployment. Let’s presume that we’ve achieved that very outcome at some point in future; i.e. we’re have an Internet where nearly all network operators are publishing Route Origin Authorizations (ROAs) via RIR RPKI services and are using RPKI data for route validation. It is reasonable to presume that over the next decade the Internet will become even more pervasive in everyday life, including being essential for many connected devices to function, and relied upon for everything from daily personal communication and conducting business to even more innovative uses such as payment & sale systems, delivery of medical care, etc. Recognizing that purpose of RPKI is improve integrity of routing, and not add undo fragility to the network, it is reasonable to expect that many network operators will take due care with the introduction of route validation into their network routing, including best practices such as falling back successfully in the event of unavailability of an RIR RPKI Certificate Authority (CA) and resulting cache timeouts. It is also reasonable expect that RIR RPKI CA services are provisioned with appropriate robustness of systems and controls that befit the highly network-critical nature of these services. Presuming we all share this common goal, the question that arises is whether we have a common vision regarding what should happen when something goes wrong in this wonderful RPKI-rich Internet of the future… More than anyone, network operators realize that even with excellent systems, procedures, and redundancy, outages can (and do) still occur. Hopefully, these are quite rare, and limited to occasions where Murphy’s Law has somehow resulted in nearly unimaginable patterns of coincident failures, but it would irresponsible to not consider the “what if” scenarios for RPKI failure and whether there is shared vision of the resulting consequences. In particular, it would be good to consider the case of an RIR RPKI CA system failure, one sufficient to result in widespread cache expirations for relying parties. Ideally, we will never have to see this scenario when RPKI is widely deployed, but it also not completely inconceivable that an RIR RPKI CA experience such an outage [1]. For network operators following reasonable deployment practices, an RIR RPKI CA outage should result in a fallback to unvalidated network routing data and no significant network impacts. However, it’s likely not a reasonable assumption that all network operators will have properly designed and implemented best practices in this regard, so there will very likely be some networks that experience significant impacts consequential to any RIR RPKI CA outage. Even if this is only 1 or 2 percent of network operators with such configuration issues, it will mean hundreds of ISP outages occurring simultaneously throughout the Internet and millions of customers (individuals and businesses) effected globally. While the Internet is the world’s largest cooperative endeavor, there inevitably will be many folks impacted of a RIR RPKI outage, including some asking (appropriately) the question of “who should bear responsibility” for the harm that they suffered. It is worth understanding what the network community believes is the most appropriate answer to this question, since a common outlook on this question can be used to guide implementation details to match. Additionally, a common understanding on this question will provide real insight into how the network community intends risk of the system to be distributed among the participants. There are several possible options worth considering: A) The most obvious answer for the party that should be held liable for the impacts that result from an RPKI CA failure would be the respective RIR that experienced the outage. This seems rather straightforward until one considers that the RIRs are providing these services specifically noting that they may not be (despite all precautions) available 100% percent of the time, and clearly documented expectations that those relying on RPKI CA information for routing origin validation should be fallback to routing with not validated state [2]. The impacted
Re: NANOG Security Track: Route Security
Hi Any online link available for remote participation or viewing ? On Sun, Sep 30, 2018 at 7:46 PM Krassimir Tzvetanov wrote: > Hello Everyone, > > I wanted to attract your attention to the Security Track this coming > NANOG. We'll be meeting on Tuesday morning and the line up looks like this: > * Andre Toonk - examples of hijacks, other ideas > * Alexander Azimov - State of BGP Security > * David Wishnick - ARIN TAL > * Job Snijders - Routing security roadmap > * Chris Morrow - So I need to start filtering routes from peers...' and > 'hey guess who needs to update their IRR data?' > > Time permitting at the end of the time slot we'll have a panel and time > for duscussion as well. > > Regards, > Krassi > > -- Samson Oduor
Re: NANOG Security Track: Route Security
Hello Everyone, I wanted to attract your attention to the Security Track this coming NANOG. We'll be meeting on Tuesday morning and the line up looks like this: * Andre Toonk - examples of hijacks, other ideas * Alexander Azimov - State of BGP Security * David Wishnick - ARIN TAL * Job Snijders - Routing security roadmap * Chris Morrow - So I need to start filtering routes from peers...' and 'hey guess who needs to update their IRR data?' Time permitting at the end of the time slot we'll have a panel and time for duscussion as well. Regards, Krassi
