Re: Financial services BGP hijack last week?
On Wed, May 3, 2017 at 1:39 PM, Compton, Rich A wrote: > The servers where the RPKI data is published (the Trust Anchor and the > CAs) are referred to using a single URI, meaning that any > sure, but even with rrdp there's just one URI you'd follow, which translates to some hostname + path. > sort of geographic redundancy or failover has to be handled via external > means (anycast, load balancing, etc.) but rsync isn’t well-suited for this > sort of implementation. > why's that? it seems to work fine for many free software repositories, for instance. Yes, updates to that repository would have to be 'managed' but that's also the case for rrdp, or any other 'more than one copy' solutions of publicly available data, right? https://github.com/google/rpki-mgmt/ does some of the lifting to sort out the 'how to get my updates to all the copies of my repository'... it doesn't yet support RRDP, but it's not hard to see where to stick that in the config/setup.
Re: Financial services BGP hijack last week?
The servers where the RPKI data is published (the Trust Anchor and the CAs) are referred to using a single URI, meaning that any sort of geographic redundancy or failover has to be handled via external means (anycast, load balancing, etc.) but rsync isn’t well-suited for this sort of implementation. [cid:DE8A0963-605D-4E57-8A58-E154EF0E790C] Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr,Englewood, CO80112 From: mailto:christopher.mor...@gmail.com>> on behalf of Christopher Morrow mailto:morrowc.li...@gmail.com>> Date: Tuesday, May 2, 2017 at 6:34 PM To: Compton Rich A mailto:rich.comp...@charter.com>> Cc: Job Snijders mailto:j...@ntt.net>>, Nikos Leontsinis mailto:nikosi...@gmail.com>>, NANOG list mailto:nanog@nanog.org>> Subject: Re: Financial services BGP hijack last week? On Tue, May 2, 2017 at 11:21 AM, Compton, Rich A mailto:rich.comp...@charter.com>> wrote: That¹s the million dollar question. I think that there will be more adoption from the Internet at large when some big players adopt it. Right now the use of rsync in RPKI is preventing a lot of large ISPs from implementing it (too difficult to provide redundancy with rsync). There is how is it hard to provide redundancy with rsync? E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Re: Financial services BGP hijack last week?
> the use of rsync in RPKI is preventing a lot of large ISPs from > implementing it (too difficult to provide redundancy with > rsync). uh, at least the DRL implementation supports caches feeding off of caches in (if you are silly enough) an arbitrarily complex graph. some years back, our research group actually used large clusters to emulate large deployments with multi-level caching and found it quite efficient. see Olaf Maennel, Iain Phillips, Debbie Perouli, Randy Bush, Rob Austein, and Askar Jaboldinov, "Towards a Framework for Evaluating BGP Security," CSET'12, 5th Workshop on Cyber Security Experimentation and Test. https://www.usenix.org/system/files/conference/cset12/cset12-final19.pdf randy
Re: Financial services BGP hijack last week?
On Tue, May 2, 2017 at 11:21 AM, Compton, Rich A wrote: > That¹s the million dollar question. I think that there will be more > adoption from the Internet at large when some big players adopt it. Right > now the use of rsync in RPKI is preventing a lot of large ISPs from > implementing it (too difficult to provide redundancy with rsync). There is > how is it hard to provide redundancy with rsync?
Re: Financial services BGP hijack last week?
>> it only proves the need for wider RPKI adoption > How can we actually encourage RPKI adoption? http://certification-stats.ripe.net/ tim, oleg, alex, ..., the ripe/ncc team, and the ripe community have worked very hard to make it easy, and the numbers show their success. lacnic even more so when looked at as a percentage (not shown at the above url); i.e. they have approximately 25% coverage; also due to solid policy, community, and technical work. arin has made it very difficult for a large and important segment of their membeship, and the numbers show their negative success. the other regions are asleep. but the rpki is only part of the equation. to be pedantic, The RPKI is the X.509 based hierarchy [rfc 6481] with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in all five administrative regions. RPKI-based Origin Validation [rfc 6811] uses the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it should prevent the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakistani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from many vendors. Path validation, a downstream technology just finishing standardisation, uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truly authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. one blocker for origin validation deployment today is lack of solid testing of vendors' implementations; and one is known to be sorely mis-implemented. there is work to be done. as stephane pointed out, if you want to be overwhelmed with tweets or email, subscribe to the feed of mis- originations at andree's http://bgpmon.net/. as the sea level rises, maybe we'll do more about this problem. randy
Re: Financial services BGP hijack last week?
Lower cost router platforms don't have RPKI capability. Mikrotik claims that v7 will... whenever that comes out. AFAIK, Ubiquiti doesn't support it either. Both have submitted and acknowledged feature requests for it. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Job Snijders" To: "Nikos Leontsinis" Cc: nanog@nanog.org Sent: Tuesday, May 2, 2017 7:27:29 AM Subject: Re: Financial services BGP hijack last week? On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: > it only proves the need for wider RPKI adoption How can we actually encourage RPKI adoption? Kind regards, Job
Re: Financial services BGP hijack last week?
That¹s the million dollar question. I think that there will be more adoption from the Internet at large when some big players adopt it. Right now the use of rsync in RPKI is preventing a lot of large ISPs from implementing it (too difficult to provide redundancy with rsync). There is a protocol called RPKI Repository Delta Protocol (RRDP) https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-08 which will alleviate these concerns but it is still in draft. I think once that becomes an RFC we will see more adoption of RPKI. Rich Compton | Principal Eng | 314.596.2828 14810 Grasslands Dr,Englewood, CO80112 On 5/2/17, 6:27 AM, "NANOG on behalf of Job Snijders" wrote: >On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: >> it only proves the need for wider RPKI adoption > >How can we actually encourage RPKI adoption? > >Kind regards, > >Job E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
Re: Financial services BGP hijack last week?
On Tue, May 02, 2017 at 08:29:32AM +0100, Nikos Leontsinis wrote: > it only proves the need for wider RPKI adoption How can we actually encourage RPKI adoption? Kind regards, Job
Re: Financial services BGP hijack last week?
On Tue, May 02, 2017 at 01:49:04AM -0400, valdis.kletni...@vt.edu wrote a message of 29 lines which said: > I didn't see any mention of this here. You should susbcribe to @bgpstream on Twitter, and read BGPmon blog :-) https://twitter.com/bgpstream https://bgpmon.net/bgpstream-and-the-curious-case-of-as12389/ (five days ago)
Re: Financial services BGP hijack last week?
On Mon, May 1, 2017, at 10:49 PM, valdis.kletni...@vt.edu wrote: > I didn't see any mention of this here. Any comments? > > [...] > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ Governments mopping up signals and data isn't a new concept, and certainly not unique to the Russian Federation. Personally I'm more concerned about important people giving up passwords so easily to spearfishers. . . -- Regards, S
Re: Financial services BGP hijack last week?
it only proves the need for wider RPKI adoption On 2 May 2017 at 06:49, wrote: > I didn't see any mention of this here. Any comments? > > "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, > and more than two dozen other financial services companies were briefly routed > through a Russian government-controlled telecom under unexplained > circumstances > that renew lingering questions about the trust and reliability of some of the > most sensitive Internet communications." > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/
Re: Financial services BGP hijack last week?
All know. Nobody care. On 02.05.17 08:49, valdis.kletni...@vt.edu wrote: > I didn't see any mention of this here. Any comments? > > "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, > and more than two dozen other financial services companies were briefly routed > through a Russian government-controlled telecom under unexplained > circumstances > that renew lingering questions about the trust and reliability of some of the > most sensitive Internet communications." > > https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ >
Financial services BGP hijack last week?
I didn't see any mention of this here. Any comments? "On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian government-controlled telecom under unexplained circumstances that renew lingering questions about the trust and reliability of some of the most sensitive Internet communications." https://arstechnica.com/security/2017/04/russian-controlled-telecom-hijacks-financial-services-internet-traffic/ pgpRIGdmt6oRJ.pgp Description: PGP signature
