Re: IPv6 Thought Experiment

It appears in your thought experiment, a stick is dressed up like a carrot. I’m not a fan of deploying purely punitive strategies to promote adoption; technologies should stand on their own and be able to convince the potential users based on their merit, not based on penalties.

Re: Elad Cohen (was: Re: Cogent sales reps who actually respond)

It would be good to see some receipts, offered by the selling party.

Re: new BGP hijack & visibility tool “BGPalerter”

Hi Ryan, Alarig, > On 14/08/2019 19:06, Ryan Hamel wrote: > > I appreciate the effort and the intent behind this project, but why > > should the community contribute to an open source project on GitHub > > that is mainly powered by a closed source binary? > On Wed, Aug 14, 2019 at 07:13:47PM

new BGP hijack & visibility tool “BGPalerter”

Dear NANOG, Recently NTT investigated how to best monitor the visibility of our own and our subsidiaries’ IP resources in the BGP Default-Free Zone. We were specifically looking how to get near real-time alerts funneled into an actionable pipeline for our NOC & Operations department when BGP

Re: RPKI adoption

Dear all, On Wed, Aug 14, 2019 at 10:36:44AM +, John Curran wrote: > On 14 Aug 2019, at 2:26 AM, Matthew Petach wrote: > > ... > > Now, at the risk of bringing down the ire of the community on my > > head...ARIN could consider tying the elements together, at least for > > ARIN members. Add

Re: 44/8

On Fri, Jul 19, 2019 at 3:16 AM Adam Korab wrote: > > On 07/18/2019 at 23:08, Job Snijders wrote: > > A potential upside is that hamnet operators maybe have access to some RPKI > > services now! > > OK, I'll bitehow do you mean? Ah, let me clarify, I didn't mean t

Re: 44/8

A potential upside is that hamnet operators maybe have access to some RPKI services now!

Re: Performance metrics used in commercial BGP route optimizers

On Tue, Jul 16, 2019 at 01:24:11PM -0500, Mike Hammett wrote: > All of the same tragedy can happen without BGP optimizers, and does. I disagree. You are skipping over crucial distinction we should make between common 'route leaks' (incorrect propagation of valid routing information), and the

Re: Performance metrics used in commercial BGP route optimizers

On Tue, Jul 16, 2019 at 6:10 PM Ryan Hamel wrote: > > Nowhere near the number as an engineer fat fingering a route. How are you able to make that assertion? > There are ISPs that accept routes all the way to /32 or /128, for traffic > engineering with ease, and/or RTBH. This strikes me as a

Re: Performance metrics used in commercial BGP route optimizers

On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett wrote: > More like do whatever you want in your own house as long as you don't > infringe upon others. > That's where the rub is; when using "BGP optimisers" to influence public Internet routing, you cannot guarantee you won't infringe upon others.

Re: Level3/CenturyLink IRR Contact

I will ping you off list with contact details. Kind regards, Job On Mon, Jul 8, 2019 at 6:20 PM Joe Nelson wrote: > > Does anyone know who to contact to have old information removed from > Level3/CenturyLink's IRR. My ASN still shows in their registry with stale > information from an old

Re: CloudFlare issues?

> Anyway, you can now enjoy https://rpki.net/s/rpki-test even more! :-) my apologies, I fumbled the ball on typing in that URL, I intended to point here: https://www.ripe.net/s/rpki-test

Re: CloudFlare issues?

On Thu, Jul 4, 2019 at 8:46 PM Francois Lecavalier wrote: > It's been close to 3 hours now since I dropped them - radio silence. I am going to assume that "radio silence" for you means that your network is fully functional and none of your customers have raised issues! :-) > Whoever fears

Re: CloudFlare issues?

Dear Francois, On Thu, Jul 04, 2019 at 03:22:23PM +, Francois Lecavalier wrote: > Following that Verizon debacle I got onboard with ROV, after a couple > research I stopped my choice on the drum roll CloudFlare GoRTR > (https://github.com/cloudflare/gortr). If you trust them enough

BGP filtering study resources (Was: CloudFlare issues?)

Dear Stephen, On Tue, Jun 25, 2019 at 07:04:12AM -0700, Stephen Satchell wrote: > On 6/25/19 2:25 AM, Katie Holly wrote: > > Disclaimer: As much as I dislike Cloudflare (I used to complain > > about them a lot on Twitter), this is something I am absolutely > > agreeing with them. Verizon failed

Re: CloudFlare issues?

On Mon, Jun 24, 2019 at 08:18:27AM -0400, Tom Paseka via NANOG wrote: > a Verizon downstream BGP customer is leaking the full table, and some more > specific from us and many other providers. It appears that one of the implicated ASNs, AS 33154 "DQE Communications LLC" is listed as customer on

Re: Traffic ratio of an ISP

On Thu, Jun 20, 2019 at 4:21 PM Steller, Anthony J wrote: > because it really don’t matter in the whole scheme of things. Indeed, it doesn't matter. The "traffic ratio" field in PeeringDB probably should be deprecated, there is no formal definition nor is are there any operational consequences

Re: provider email maintenance standard

Dear Matt, See this URL instead: https://github.com/jda/maintnote-std/blob/master/standard.md NTT / AS 2914’s NOC follows this process to keep customers and partners informed about maintenances. Kind regards, Job On Mon, Jun 17, 2019 at 15:32 Matt Harris wrote: > On Mon, Jun 17, 2019 at

Re: someone is using my AS number

On Sat, Jun 15, 2019 at 4:45 PM Owen DeLong wrote: > > On Jun 15, 2019, at 5:43 AM, Job Snijders wrote: > >> On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote: > > owen> >> What I heard you say is: “I’m not going to offer a solution to your problem, but you

Re: someone is using my AS number

On Sat, Jun 15, 2019 at 09:31:03AM -0400, Jon Lewis wrote: > On Sat, 15 Jun 2019, Job Snijders wrote: > > There is no signal from the remote ASN (the one that receive the > > route announcement) to the Originator ASN about the remote ASN's > > loop detection policies. Ther

Re: someone is using my AS number

On Sat, Jun 15, 2019 at 05:32:21AM -0700, Owen DeLong wrote: > > What is the principal harm of doing this? Honest question. I'm not > > advocating for anything, just curious. > > > > Excellent question. > > > > 1/ We can’t really expect on the loop detection to work that way at > > the “jacked”

Re: someone is using my AS number

On Sat, Jun 15, 2019 at 2:38 PM Owen DeLong wrote: > Job, > > Permit me to apply some reflective listening to your statement: > > What I heard you say is: “I’m not going to offer a solution to your problem, > but you shouldn’t use the one you have that currently works because some > things my

Re: someone is using my AS number

On Thu, Jun 13, 2019 at 11:18 Warren Kumari wrote: > On Thu, Jun 13, 2019 at 9:59 AM Joe Abley wrote: > > > > Hey Joe, > > > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > > >> Send abuse complaint to the upstreams

Re: someone is using my AS number

Hi Joe, On Thu, Jun 13, 2019 at 9:59 Joe Abley wrote: > Hey Joe, > > On 12 Jun 2019, at 12:37, Joe Provo wrote: > > > On Wed, Jun 12, 2019 at 04:10:00PM +, David Guo via NANOG wrote: > >> Send abuse complaint to the upstreams > > > > ...and then name & shame publicly. AS-path forgery "for

Re: someone is using my AS number

Indeed, I do not see this in the our current version of the Default-Free Zone, so there may not be a problem for us to solve at this moment. I think your reaching out to NANOG or other operator forums is the correct action. Someone is bound to know someone who knows someone who can help. Kind

Re: someone is using my AS number

Can you share more details? Perhaps we can put the human social network to good use. Other than that this is annoying - are right now operationally impacted? Kind regards, Job On Wed, Jun 12, 2019 at 12:24 Filip Hruska wrote: > I would contact upstreams of the upstream then. This is quite a

Re: Networks enforcing RPKI validation

Dear Eric, If you don't mind me showering you with some study resources... here we go! On Fri, Jun 07, 2019 at 10:58:48AM -0400, Eric Dugas wrote: > I was wondering if there was a list of networks that enforce RPKI > validation and dropping invalids. The last list that was compiled is available

Re: Cisco Crosswork Network Insights - or how to destroy a useful service

On Wed, May 15, 2019 at 11:52:16AM +, Mann, Jason via NANOG wrote: > ?Is BGPmon going away? Yes, see https://bgpmon.net/wp-content/uploads/2019/01/BGPMon.net-EOL-EOS-faq.pdf Kind regards, Job

Re: Cisco Crosswork Network Insights - or how to destroy a useful service

On Wed, May 15, 2019 at 11:37:57AM +0100, Carlos Friaças wrote: > It relies *exclusively* on "RIPE RIS Live", or does it also use other > sources? The first useful version will rely exclusively on the "RIS Live" interface. In a later stage we can consider adding something like the NLNOG Looking

Re: Cisco Crosswork Network Insights - or how to destroy a useful service

Hi, I recognise the issue you describe, and I'd like to share with you that we're going down another road. Nowadays, RIPE NCC offers a streaming API ("RIS Live") which has the data needed to analyse and correlate BGP UPDATES seen in the wild to business rules you as operator define. NTT folks

Re: Seeking Feedback on Mitigation of New BGP-driven Attack

Dear Jared, This was a very interesting read. Thank you for sharing it with us. The paper contained new information for me, if I hope I summarize it correctly: by combining AS_PATH poisoning and botnets, the botnet’s firing power can be more precisely aimed at a specific target. Can you clarify

Re: Routing issues to AWS environment.

Dear Nick, I sympathize with you plight, network debugging can be quite a test of character at times. I am snipping some text as I can't comment on on specific details in this case, but you do raise two excellent questions which I can maybe help with. On Thu, May 09, 2019 at 03:05:43PM +,

Re: Routing issues to AWS environment.

Hi Chuck, On Thu, May 09, 2019 at 06:34:21AM -0400, Chuck Church wrote: > Are you sure the problem isn’t NTT? My buddy’s WISP peers with Spirit > and had a boatload of problems with random packet loss affecting > initially just SIP and RTP (both UDP). Spirit was blaming NTT. > Problems went away

Re: NTP for ASBRs?

Dear Lars, On Wed, May 08, 2019 at 09:56:33AM +0200, Lars Prehn wrote: > do you NTP sync your AS boundary routers? yes > If so, what are incentives for doing so? Are there incentives, e.g. > security considerations, not to do it? The major advantage of NTP syncing your routers is that it

Re: NTP question

Dear Mehmet, On Wed, May 01, 2019 at 03:22:57PM -0400, Mehmet Akcin wrote: > I am trying to buy a GPS based NTP server like this one > > https://timemachinescorp.com/product/gps-time-server-tm1000a/ > > but I will be placing this inside a data center, do these need an > actual view of a sky to

Re: Packetstream - how does this not violate just about every provider's ToS?

Dear Anne, On Wed, Apr 24, 2019 at 11:07:51PM -0600, Anne P. Mitchell, Esq. wrote: > How can this not be a violation of the ToS of just about every major > provider? Can you perhaps cite ToS excerpts from one or more major providers to support your assertion? > Anne P. Mitchell, > Attorney

Re: SOLVED (was Re: request for help: 192.139.135.0/24)

Hi all, On Wed, Apr 03, 2019 at 10:59:18AM -0400, Jay Borkenhagen wrote: > I urge folks facing similar problems to publish RPKI ROAs for their IP > resources. [snip] the verifiable statements in RPKI ROAs can be > attributed to you as the actual resource holder, thus helping folks > base their

Re: request for help: 192.139.135.0/24

Ack for NTT On Mon, Apr 1, 2019 at 21:36 Christopher Morrow wrote: > (from offline chat and pokery) > > It looks like 701/1239/3356 are permitting 4837 to announce this prefix > because: > $ whois -h whois.radb.net 192.139.135.0 > route: 192.139.135.0/24 > descr: managedway company >

Re: Was wrong Re: Did IPv6 between HE and Google ever get resolved?

A careful observer will note multiple fractures/rifts in the ipv6 default-free zone. It’s not as meshed as ipv4, unfortunately. Kind regards, Job

Re: Advertisement of Equinix Chicago IX Subnet

On Wed, Mar 27, 2019 at 09:36:20PM +, Graham Johnston wrote: > This afternoon at around 12:17 central time today we began learning > the subnet for the Equinix IX in Chicago via a transit provider; we > are on the IX as well. The subnet in question is 208.115.136.0/23. > Using stat.ripe.net I

Re: Advertisement of Equinix Chicago IX Subnet

On Thu, Mar 28, 2019 at 02:59:43PM +0100, Niels Bakker wrote: > * christopher.morrell.na...@gmail.com (Christopher Morrell) [Thu 28 Mar 2019, > 14:35 CET]: > > I've been bit by this in the past at two different exchanges. I too > > have a policy applied to deny IXP LANs from upstreams and peers.

Re: well-known Anycast prefixes

On Thu, Mar 21, 2019 at 06:59:18PM +0300, Frank Habicht wrote: > On 20/03/2019 21:05, James Shank wrote: > > I'm not clear on the use cases, though. What are the imagined use cases? > > > > It might make sense to solve 'a method to request hot potato routing' > > as a separate problem. (Along

Re: FB? / AS 200020 leak

Hi, On Thu, Mar 14, 2019 at 02:04:39PM +, Jeroen Wunnink wrote: > The route-leak was something different that seems to have mainly hit > west-Europe between 16:52 UTC to 17:08 UTC. There’s a few people in > the *NOG communities still digging at the complete details of that > right now, but it

Re: Best practices for BGP Communities

On Wed, Mar 6, 2019 at 8:32 Smith, Courtney wrote: > On 3/5/19, 6:04 PM, "NANOG on behalf of Job Snijders" > j...@instituut.net> wrote: > > On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > > A while back I read somewhere that tra

Re: Best practices for BGP Communities

On Sun, Mar 03, 2019 at 08:42:02PM -0500, Joshua Miller wrote: > A while back I read somewhere that transit providers shouldn't delete > communities unless the communities have a specific impact to their > network, but my google-fu is failing me and I can't find any sources. > > Is this still the

Re: 2FA, was A Deep Dive on the Recent Widespread DNS Hijacking

Keith, On Tue, Feb 26, 2019 at 6:00 AM Keith Medcalf wrote: > >https://twofactorauth.org/#domains gives a good view of the domain > >management landscape regarding 2FA. > > Seems to require the unfettered execution of third-party code ... > > Are you offering an indemnity in case that code is

Re: OT/venting: RIPE legal - please stop this madness!

Dear Markus, I think you are better off taking a deep breath, perhaps removing some strongly worded sentences, and bring up the topic on one of the RIPE mailing lists: https://www.ripe.net/participate/mail/ripe-mailing-lists/ripe-list Kind regards, Job On Fri, Feb 15, 2019 at 9:47 Mel Beckman

Re: AT/as7018 now drops invalid prefixes from peers

On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster wrote: > On Tue, 12 Feb 2019 at 16:05, Nick Hilliard wrote: >> Matthew Walster wrote on 12/02/2019 14:50: >> > For initial deployment, this can seem attractive, but remember that one >> > of the benefits an ROA gives is specifying the maximum

Re: AT/as7018 now drops invalid prefixes from peers

On Tue, Feb 12, 2019 at 6:40 PM Owen DeLong wrote: > > To be clear, I don’t believe they are dropping all routes which don’t > validate (have no ROAs), only routes where the prefix matches an existing ROA > and the origin AS in the AS PATH does not match. Small addition: routes are not only

Analysing traffic in context of rejecting RPKI invalids using pmacct

Dear all, Whether to deploy RPKI Origin Validation with an "invalid == reject" policy really is a business decision. One has to weigh the pros and cons: what are the direct and indirect costs of accepting misconfigurations or hijacks for my company? what is the cost of deploying RPKI? What is the

Re: AT/as7018 now drops invalid prefixes from peers

On Tue, Feb 12, 2019 at 3:06 PM Nick Hilliard wrote: > > Matthew Walster wrote on 12/02/2019 14:50: > > For initial deployment, this can seem attractive, but remember that one > > of the benefits an ROA gives is specifying the maximum prefix length. > > This means that someone can't hijack a /23

Re: AT/as7018 now drops invalid prefixes from peers

Dear Jay, AT, On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote: > The AT/as7018 network is now dropping all RPKI-invalid route > announcements that we receive from our peers. Thanks for filtering us! :-) AT doing origin validation combined with the peerlock-style AS_PATH filters

Re: Comcast - NTT seeing congestion in Chicago at 350 Cermak

Hi, I'll follow up off list. Kind regards, Job On Sat, Feb 09, 2019 at 03:05:22AM +, Erik Sundberg wrote: > Comcast\NTT, > > I am seeing a bit of congestion between the NTT and Comcast connection in > Chicago. Can you guys take a look at this? > > > Normally this is a sub 10ms path, it

Re: [Community bleaching on edge] RTBH no_export

Hi Adam, On Wed, Feb 06, 2019 at 01:53:48PM -, adamv0...@netconsultings.com wrote: > This "RTBH no_export" thread made me wonder what is the latest view on > BGP community bleaching at the edge (in/out). At NTT/AS 2914 we took a look at BGP community bleaching recently. We intend to deploy

Re: Verizon(AS701) announcing Comcast(AS7922) subnet 68.80.240.0/24

Dear Courtney, (This suggestion does not address the immediate issue at hand) On Mon, Jan 28, 2019 at 06:47:29PM +, Smith, Courtney wrote: > Verizon (AS701) is currently originating 68.80.240.0/24. This is part > of 68.80.0.0/13 allocated to Comcast (AS7922). We have reached out to >

Re: BGP Experiment

Dear Ben, all, I'm not sure this experiment should be canceled. On the public Internet we MUST assume BGP speakers are compliant with the BGP-4 protocol. Broken BGP-4 speakers are what they are: broken. They must be fixed, or the operator must accept the consequences. "Get a sandbox like every

Re: Announcing Peering-LAN prefixes to customers

On Wed, Jan 16, 2019 at 19:40 Christoffer Hansen wrote: > On 16/01/2019 15:55, John Kristoff wrote: > > In Randy's presentation there is the suggestion to develop an IX filter > > list. Nearly 20 years later that actually happened. > > > > > > > > This

Re: Announcing Peering-LAN prefixes to customers

On Wed, Jan 16, 2019 at 15:24 Randy Bush wrote: > > Do you use AS0 as origin on the RPKI objects for said exchange point > > LAN(s) to prevent route propagation? > > but as0 does not exactly do that as it can be overridden by a different > roa for the same prefix. as0 is pretty useless. Why

Re: Announcing Peering-LAN prefixes to customers

On Wed, Jan 16, 2019 at 14:49 Mark Tinka wrote: > On 16/Jan/19 11:38, Christoffer Hansen wrote: > > > Do you use AS0 as origin on the RPKI objects for said exchange point > > LAN(s) to prevent route propagation? > > I don't operate any exchange points anymore, but I am not aware of any > such

Re: Announcing Peering-LAN prefixes to customers

On Wed, Jan 16, 2019 at 12:39 Christoffer Hansen wrote: > > On 16/01/2019 08:56, Mark Tinka wrote: > > Running a few exchange points in Africa since 2002, the news was that > > the exchange point LAN should not be visible anywhere on the Internet. > > Do you use AS0 as origin on the RPKI objects

Re: Announcing Peering-LAN prefixes to customers

On Wed, Jan 16, 2019 at 10:56 Mark Tinka wrote: > On 3/Jan/19 22:08, Andy Davidson wrote: > > > There are no stupid questions! It is a good idea to not BGP announce > and perhaps also to drop traffic toward peering LAN prefixes at > customer-borders, this was already well discussed in the

Re: BGP Experiment

On Wed, Jan 9, 2019 at 9:55 Randy Bush wrote: > >>> We plan to resume the experiments January 16th (next Wednesday), and > >>> have updated the experiment schedule [A] accordingly. As always, we > >>> welcome your feedback. > >> i did not realize that frr updates propagated so quickly. very

Re: BGP Experiment

OOn Tue, Jan 8, 2019 at 19:59 Tom Ammon wrote: > On Tue, Jan 8, 2019, 11:50 AM >> * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: >> >[A] https://goo.gl/nJhmx1 >> >> For the archives, since goo.gl will cease to exist soon, this links to >> >>

Re: Report on Legal Barriers to RPKI Adoption

Dear Christopher, David, NANOG community, Thank you for your research and report. I found the report quite readable (not having a legal background) and well structured. Definitely edifying and worth the read! In this mail I’ll reply specifically to a few points from the executive summary (and

Re: 192.208.19.0/24 hijack transiting 209, 286, 3320, 5511, 6461, 6762, 6830, 8220, 9002, 12956

Dear all, NTT / AS 2914 deployed explicit filters to block this BGP announcement from AS 4134. I recommend other operators to do the same. I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the /24 announcement so the counter measure is more effective. Kind regards, Job On

Re: Facebook doesn't have a route to my ISP's (Cogeco) IPv6 space?

At this moment it appears there are multiple rifts in the IPv6 default-free zone (that don’t exist in the IPv4 realm), between various organizations. Focusing on one particular partitioning may not help address the other issues. Kind regards, Job

Re: Announcing Peering-LAN prefixes to customers

Dear Dominic, On Thu, Dec 20, 2018 at 6:49 PM Dominic Schallert wrote: > this might be a stupid question but today I was discussing with a colleague > if Peering-LAN prefixes should be re-distributed/announced to direct > customers/peers. My standpoint is that in any case, Peering-LAN prefixes

Re: BGP Experiment

Dear Italo, Thanks for giving the community a heads-up on your plan! I think your announcement like these are the best anyone can do when trying legal but new BGP path attributes. I'll forward this message to other NOGs and make sure that our NOC adds it to their calendar. Kind regards, Job

Re: rfd

Dear Steve, No worries, I have not forgotten the transitive properties of the LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF modifications (and the attribute itself), are local to the Autonomous System in which they were set, but the effects of such settings can percolate

Re: rfd

Hi Steve, Lowering the LP would achieve the outcome you desire, provided there are (stable) alternative paths. What you advocate results in absolute outages in what may already be precarious situations (natural disasters?) - what Saku Ytti suggests like a less painful alternative with desirable

Re: rfd

On Tue, Dec 18, 2018 at 6:40 PM Randy Bush wrote: > > do you have rfd on? with what parms? I assume rfd in this context means "Route Flap Dampening". NTT / AS 2914 does *not* have Route Flap Dampening configured, as is documented here

progress report: modernizing OpenBGPD

Dear fellow BGP aficionados, Over the last few months we've spend considerable time modernizing the OpenBSD's BGP-4 implementation "OpenBGPD", with the explicit goal to offer more diversity in the IXP Route Server space. OpenBGPD now is faster, has RFC 8212 support, RFC 6811 Origin Validation

Re: IGP protocol

Let’s please stay on topic.

Re: IGP protocol

The war is over. In IETF the OSPF and ISIS working groups merged. Now all of it is “link-state routing”. https://datatracker.ietf.org/group/lsr/about/

Re: Amazon now controls 3.0.0.0/8

On Fri, Nov 9, 2018 at 0:54 Eric Kuhnke wrote: > https://news.ycombinator.com/item?id=18407173 > > Quoting from the post: > > " > > Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9. > > Previous owner was GE. > > Anecdotal reports across the Internet that AWS EIPs are now being

Re: Software installation tools retrieving ARIN TAL (was: Re: ARIN RPKI TAL deployment issues)

rote: > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > ... > > What I'm hoping for is that there is a way for the ARIN TAL to be > > included in software distributions, without compromising ARIN's > > legal position. > > > > Perhaps an exception

Re: Towards an RPKI-rich Internet (and the appropriate allocation of responsibility in the event an RIR RPKI CA outage)

Dear all, I'm very happy to see the direction this conversation has taken, seems we've moved on towards focussing on solutions and outcomes - this is encouraging. On Mon, Oct 01, 2018 at 05:44:17PM +0100, Nick Hilliard wrote: > John Curran wrote on 01/10/2018 00:21: > > There is likely some on

Re: NANOG Security Track: Route Security

Perhaps the moderator and the presenters for this track can figure out (off list!) if there is unanimous support to record the session and reconsider. Kind regards, Job

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

Re: ARIN RPKI TAL deployment issues

On Wed, Sep 26, 2018 at 11:07:49AM +, John Curran wrote: > > Let's Encrypt does not require an agreement from relying parties > > (i.e. browser users), whereas ARIN does. > > That is correct; I did not say that they were parallel situations, > only pointing out that the Let’s Encrypt folks

Re: ARIN RPKI TAL deployment issues

On Tue, Sep 25, 2018 at 09:17:56PM +, John Curran wrote: > On 25 Sep 2018, at 5:04 PM, Job Snijders wrote: > >> It would be informative to know how many organizations potentially > >> have concerns about the indemnification clause in the RPA but > >> already agr

Re: ARIN RPKI TAL deployment issues

Dear John, On Tue, Sep 25, 2018 at 08:28:54PM +, John Curran wrote: > On 25 Sep 2018, at 3:34 PM, Job Snijders wrote: > > > > On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: > >> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > >>> > &

Re: ARIN RPKI TAL deployment issues

On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote: > On Sep 25, 2018, at 1:30 PM, Job Snijders wrote: > > > >"""Using the data, we can also see that the providers that have not > >downloaded the ARIN TAL. Either because they were not aware

ARIN RPKI TAL deployment issues

Dear NANOG, I'd like to draw attention to a very concerning development: it appears that the ARIN TAL is not as widely deployed as other RPKI TALs (such as RIPE or APNIC's TAL). This means that ARIN members are needlessly put at higher risk. Ben Cartwright-Cox performed RPKI research a few weeks

Re: O365 IP space

On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote: > https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges I think it is cool that companies take the time and effort to publish such useful lists. Keep it up! Kind regards, Job

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

On Wed, Sep 19, 2018 at 01:07:42AM -0700, Christopher Morrow wrote: > > it is about whether it is acceptable that RIRs (and more > > specifically ARIN in this mailing list's context) notify affected > > parties of their prefixes that suffer from stale ROAs. > > This I still think is a bad plan..

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

On Tue, Sep 18, 2018 at 06:18:00PM -0700, Owen DeLong wrote: > That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24 > to update the route objects for it, then the word ONLY is effectively > present by the lack of any other route objects. Ah, so you are now applying the RPKI

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote: > ROAs are useful for one hop level validation. At the second AS hop > they are 100% useless. This conversation cannot be had without acknowledging there are multiple layers of defense in securing BGP. We should also acknowledge that

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote: > > "rir says owen can originate route FOO" > > "ROA for 157.130.1.0/24 says OWEN can originate" > > Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734) > can originate 192.159.10.0/24. I'd phrase slightly different

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote: > > Perhaps said another way: > > > > "How would you figure out what prefixes your bgp peer(s) should be sending > > you?" > >(in an automatable, and verifiable manner) > > In theory, that’s what IRRs are for. You may be

Re: Reaching out to ARIN members about their RPKI INVALID prefixes

Owen, On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote: > Personally, since all RPKI accomplishes is providing a > cryptographically signed notation of origin ASNs that hijackers should > prepend to their announcements in order to create an aura of > credibility, I think we should stop

Re: adding graphs for actually unreachable RPKI INVALID prefixes to RPKI Monitor?

On Mon, 17 Sep 2018 at 18:38, nusenu wrote: > Dear NIST RPKI Monitor Team, > > thanks for creating and maintaining the RPKI Monitor > https://rpki-monitor.antd.nist.gov/#rpki_adopters > I've seen your graphs in multiple routing security presentations :) > > What do you think about adding graphs

Re: tcp md5 bgp attacks?

On Tue, Aug 14, 2018 at 05:28:13PM -0600, Grant Taylor via NANOG wrote: > On 08/14/2018 03:38 PM, Randy Bush wrote: > > so we started to wonder if, since we started protecting our bgp > > sessions with md5 (in the 1990s), are there still folk trying to > > attack? > > n00b response here > > I

celebrating 10 years of routing insecurity

Dear all, Today marks the 10th anniversary of the famous Kapela-Pilosov Man-in-the-middle BGP attack! It is a fantastic and innovative attack that would be worthy of referencing in the next Mr Robot season. :-) video: https://www.youtube.com/watch?v=S0BM6aB90n8 slide:

Re: [Nanog] BGPMon RPKI Validation Failed (Code: 9)

Dear Michel, This question is probably best answered by Andree Toonk from the BGPMon project. I've CCed him. Kind regards, Job On Thu, Aug 2, 2018 at 10:27 PM, Michel Py wrote: > Hi Nanog, > > I received recently some of these messages, and I don't understand the logic > of them. > If there

Re: Confirming source-routed multicast is dead on the public Internet

On Tue, 31 Jul 2018 at 23:29, Sean Donelan wrote: > Its tought to prove a negative. I'm extremely confident the answer is yes, > public internet multicast is not viable. I did all the google searches, > check all the usual CAIDA and ISP sites. IP Multicast is used on private > enterprise

Re: NTT US contact

We are reaching out off list! Kind regards, Job On Mon, 30 Jul 2018 at 22:52, Christopher Morrow wrote: > job > > On Mon, Jul 30, 2018 at 4:49 PM Michel Py wrote: > > > Can someone from NTT US contact me off-list please ? > > Preferably someone with some RPKI clue. > > > > Thanks, > > > >

Re: deploying RPKI based Origin Validation

Dear Alex, On Thu, 26 Jul 2018 at 19:11, Alex Band wrote: > NLnet Labs recently committed to building a full RPKI Toolset, including a > (Delegated) Certificate Authority, a Publication Server and Relying Party > software. As an RP implementation was the easiest way to get going, we now >

Re: AS205869, AS57166: Featured Hijacker of the Month, July, 2018

On Wed, Jul 25, 2018 at 12:58:46PM +0200, Jérôme Nicolle wrote: > From your initial list, I can still see some prefixes with the NLnog ring : > > http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0 > http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0 >

Re: Question about bird RS config with BGP Community support

On Tue, Jul 24, 2018 at 11:36:21PM +0530, Anurag Bhatia wrote: > Thanks a lot for your advice. I was aware of IXP Manager and there > were certain issues we faced due to which we couldn't use it when we > tried last time (which was a few months ago before the latest stable > release). I wish to

  1   2   3   4   >