Recommendation to update RPKI validators

Hi all, About eight months ago I discovered a number of issues in the validation procedure of most RPKI validator softwares (including the RIPE NCC Validator, Routinator, and OctoRPKI). The impact of improper verification of Manifests (and associated aspects of the X.509 system) in the RPKI can ha

Re: plea for comcast/sprint handoff debug help

On Thu, Oct 29, 2020 at 09:14:16PM +0100, Alex Band wrote: > In fact, we argue that it's actually a bad idea to do so: > > https://blog.nlnetlabs.nl/why-routinator-doesnt-fall-back-to-rsync/ > > We're interested to hear views on this from both an operational and > security perspective. I don't se

RPKI over RSYNC vs RRDP (Was: plea for comcast/sprint handoff debug help)

On Fri, Oct 30, 2020 at 12:47:44PM +0100, Alex Band wrote: > > On 30 Oct 2020, at 01:10, Randy Bush wrote: > > i'll see your blog post and raise you a peer reviewed academic paper > > and two rfcs :) > > For the readers wondering what is going on here: there is a reason > there is only a vague me

Re: plea for comcast/sprint handoff debug help

On Mon, Nov 02, 2020 at 09:13:16AM +0100, Tim Bruijnzeels wrote: > On the other hand, the fallback exposes a Malicious-in-the-Middle > replay attack surface for 100% of the prefixes published using RRDP, > 100% of the time. This allows attackers to prevent changes in ROAs to > be seen. This is a m

Re: Newbie Questions: How-to remove spurious IRR records (and keep them out for good)?

Dear Pirawat, On Mon, Oct 26, 2020 at 08:13:19PM +0700, Pirawat WATANAPONGSE wrote: > I am seeking advice concerning someone else announcing IRR records on > resources belonging to me. Change is underway in the IRR ecosystem! The situation we are all used to is that it is rather cumbersome to get

inspecting RPKI data: console.rpki-client.org

Dear all, I'd like to introduce another tool to inspect RPKI data... the rpki-client console! Comes with an authentic 90s look & feel :-) The Frontpage - http://console.rpki-client.org/ --- On the front page you can see stdout + stderr of the most recen

Re: inspecting RPKI data: console.rpki-client.org

On Fri, Nov 20, 2020 at 12:02:04PM -0500, Tom Beecher wrote: > In before snark of "OMG "http" links to RPKI info HURF BLURF!" But Tom, that is exactly the whole point of the RPKI :-) It's funny, but true! You really can safely use the RPKI data from the console website in your own production envi

Fw: [lacnog] Update on LACNIC's IRR: Near-Real-Time Mirroring Now Available

.net/LACNIC.CURRENTSERIAL NRTM Host: irr.lacnic.net NRTM Port:43 When LACNIC enables NRTM in the coming days, other IRRs such as RADB and NTT will begin mirroring the LACNIC source. We would also like to thank the DashCare team (https://dashcare.nl/), Job Snijders (NTT) and the RADB team for

Re: what is the policy about sharing email offlist?

Dear all, On Mon, Jan 18, 2021 at 11:17:06AM -0700, Anne P. Mitchell, Esq. wrote: > Either Alexandria Ocasio-Cortez' office is on the NANOG list or > someone is forwarding NANOG email to AOC's press office (in which case > either spoofed as the original sender or AOC's office sends an ack to > eve

Re: Issues with NANOG mailing list operations and subscriptions

Hi Sean, Will, group, On Sun, Jan 17, 2021 at 03:01:22PM -0800, William Herrin wrote: > On Sun, Jan 17, 2021 at 1:37 PM Sean Donelan wrote: > > Some people think its funny to ghost subscribe email addresses, and > > the NANOG mailing list auomation doesn't catch them in the verification > > proce

Re: Dual Homed BGP

Dear Brian, On Fri, 24 Jan 2020 at 17:40, Brian wrote: > Hello all. I am having a hard time trying to articulate why a Dual Home > ISP should have full tables. My understanding has always been that full > tables when dual homed allow much more control. Especially in helping to > prevent Async ro

Re: Rogue objects in routing databases

Hi! This came up on our radar somewhere in the last 24 hours too. It indeed does look very curious. Thank you for your analysis and report. NTT is taking steps to figure out what is behind this. Our current working theories are that perhaps the IRR maintainer account was compromised, or some kind

Re: Microsoft mail delivery issue

Dear Paul, I recommend subscribing and reaching out to the “mailop” mailing list. You may not see replies from the big mail operators in the archives, but I suspect a lot of relevant people pay attention to this specific list. https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop Kind rega

new tool: rpki-ov-checker

Dear ops, I wrote a simple tool to figure out what kind of invalid a rpki invalid is, this can aid people in understanding the impact of "invalid == reject" routing policies. Only "invalid_unreachable" routes present an operational issue in my opinion, IP addresses covered by "notfound" or "valid"

Re: new tool: rpki-ov-checker

Oops, I see a fat typo slipped in - the correct URL is https://github.com/job/rpki-ov-checker :-) Kind regards, Job On Thu, Feb 6, 2020 at 20:35 Job Snijders wrote: > Dear ops, > > I wrote a simple tool to figure out what kind of invalid a rpki invalid > is, this can a

Re: akamai yesterday - what in the world was that

> Any word on what the update was for? It caused quite a jump in traffic on our > network. On twitter "68 GB" was trending https://twitter.com/search?q=%2268%20GB%22&src=trend_click Kind regards, Job

Re: RADB account deletions

On Tue, Mar 03, 2020 at 11:22:35AM -0700, Clinton Work wrote: > It looks like the former Allstream RADB account (MAINT-AS15290) and > all associated route objects were removed from RADB today. The > deletion mainly impacts Canadian route objects registered by the > former Allstream (now Zayo).

Re: AT&T is suspending broadband data caps for home internet customers due to coronavirus

On Tue, Mar 17, 2020, at 19:38, Dan White wrote: > By "ahead of us", I'm hoping to glean some operational experience from > European, or networks in larger cities with a more impactful lock > down. It is all fairly new here too. Some of the things that have come to mind so far: - the supply chain

Re: Need help removing a old/outdated/incorrect proxy route object

I can help! Will follow-up off list. For future reference: db-ad...@rr.ntt.net is also a good place to direct any questions about NTT's IRR service "NTTCOM" Kind regards, Job On Tue, Mar 17, 2020, at 20:54, Sadiq Saif wrote: > Hi all, > > I am looking for help with removal of a old/outdated/i

Re: interesting troubleshooting

On Fri, Mar 20, 2020 at 05:33:31PM -0400, Nimrod Levy wrote: > With the increase in remote workers and VPN traffic that won't hash across > multiple paths, I thought this anecdote might help someone else track down > a problem that might not be so obvious. Do we know which specific VPN technologie

Re: interesting troubleshooting

On Fri, Mar 20, 2020 at 05:57:19PM -0400, Jared Mauch wrote: > You also need to watch out to ensure you’re not on some L2VPN type > product that bumps up against a barrier. I know it’s a stressful time > for many networks and systems people as traffic shifts. A few years ago we did a presentatio

NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

Dear group, Exciting news! Today NTT's Global IP Network (AS 2914) enabled RPKI based BGP Origin Validation on virtually all EBGP sessions, both customer and peering edge. This change positively impacts the Internet routing system. The use of RPKI technology is a critical component in our efforts

RPKI OV implementation in route-map

Dear Mark, group, On Tue, Mar 31, 2020 at 03:50:23PM +0200, Mark Tinka wrote: > On 31/Mar/20 15:21, Dorian Kim wrote: > > Unfortunately we don’t have any testing done or experience with RPKI > > on XE or Classic boxes as we don’t have any deployed outside of OOB > > infrastructure. > > Cherish you

Re: "Is BGP safe yet?" test

On Mon, Apr 20, 2020, at 21:54, Amir Herzberg wrote: > Randy said, > From a practical standpoint, this doesn't actually tell > the whole truth > > > > indeed. route origin validation, while a good thing, does not make > > bgp safe from attack. this marketing fantasy is being propagated; > > but i

Re: Update your ARIN IRR data access methods (was: Fwd: [arin-announce] New Internet Routing Registry Release)

Dear John, group, On Wed, Jun 10, 2020 at 06:51:53PM +, John Curran wrote: > ARIN has released its updated IRR system - if you are relying on > ARIN’s IRR data, please refer to details below and update access > methods accordingly. Ack - NTT has done so. The 'rr.ntt.net' instance now carries

Re: Partial vs Full tables

On Tue, Jun 9, 2020, at 08:04, Mark Tinka wrote: > On 5/Jun/20 18:49, Saku Ytti wrote: > > The comparison isn't between full or default, the comparison is > > between static default or dynamic default. Of course with any default > > scenario there are more failure modes you cannot route around. But

academic paper on Peerlock BGP protection mechanism

Dear colleagues,

Reactive RPKI ROV (Was: Hurricane Electric has reached 0 RPKI INVALIDs)

Dear Mike, Ytti, others, First of all and most importantly: congratulations Mike! I thank you and your team for having constructed a great mechanism that helps honor the routing intentions everyone publishes in the RPKI. On Tue, Jun 16, 2020 at 09:08:41AM +0300, Saku Ytti wrote: > On Tue, 16 Jun

Re: Reactive RPKI ROV (Was: Hurricane Electric has reached 0 RPKI INVALIDs)

Dear Baldur, On Wed, Jun 17, 2020 at 01:42:36PM +0200, Baldur Norddahl wrote: > Lets say someone makes an announcement that creates a RPKI invalid and > it is determined to be a mistake. They then go back and add ROA > objects to fix the problem. With this reactive RPKI approach then > continue to

Re: Mikrotik RPKI Testing

Dear all, > I noticed that Mikrotik has added RPKI into their very much beta v7 > branch. I would like to ask those of you that know RPKI well to check > it out and offer Mikrotik feedback on what they've done > right\wrong\broken. Our hero Massimiliano Stucchi in Switzerland started doing the l

Re: Hurricane Electric has reached 0 RPKI INVALIDs in our routing table

Dear Jon, group, On Wed, Jun 17, 2020 at 10:25:14AM -0400, Jon Lewis wrote: > On Mon, 15 Jun 2020, Mike Leber via NANOG wrote: > > > I'm pleased to announce Hurricane Electric has completed our RPKI > > INVALID filtering project and we now have 0 RPKI INVALIDs in our routing > > table. > > > > H

Re: BGP route hijack by AS10990

On Thu, Jul 30, 2020 at 07:09:07PM +0200, Patrick Schultz wrote: > so, bgp optimizers... again? We should stop calling them 'optimizers'... perhaps "BGP Polluters"? Kind regards, Job

Re: BGP route hijack by AS10990

On Fri, Jul 31, 2020 at 03:34:47PM +0200, Mark Tinka wrote: > On 31/Jul/20 03:57, Aftab Siddiqui wrote: > > Not a single prefix was signed, what I saw. May be good reason for > > Rogers, Charter, TWC etc to do that now. It would have stopped the > > propagation at Telia. > > If none of the prefixes

Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

On Sat, Aug 01, 2020 at 06:50:55AM -0700, Ca By wrote: > I am not normally supporting a heavy hand in regulation, but i think it is > fair to say Noction and similar BGP optimizers are unsafe at any speed and > the FTC or similar should ban them in the USA. They harm consumers and are > a risk to n

Re: BGP route hijack by AS10990

On Mon, Aug 03, 2020 at 02:36:25PM +0200, Alex Band wrote: > According to the information I received from the community[1], you > should read PR1461602 and PR1309944 before deploying. > > [1] https://rpki.readthedocs.io/en/latest/rpki/router-support.html My take on PR1461602 is that it can be ign

Re: Issue with Noction IRP default setting (Was: BGP route hijack by AS10990)

Dear Ryan, I have come to believe this is a Noction IRP specific issue. On Sat, Aug 01, 2020 at 01:29:59PM -0700, Ryan Hamel wrote: > I disagree on the fact that it is not fair to the BGP implementation > ecosystem, to enforce a single piece of software to activate the > no-export community by de

Re: RPKI TAs

On Mon, Aug 03, 2020 at 08:17:55AM -0500, John Kristoff wrote: > On Sun, 2 Aug 2020 18:52:11 + > Randy Bush wrote: > > > not to mention the ARIN stupidity > > Notwithstanding the RPA, downloading ARIN's TAL is straightforward: > > As documented here: > >

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

On Tue, Aug 25, 2020 at 07:27:33AM -0400, K. Scott Helms wrote: > I think a fairly easy thing to do is see what other large retail ISPs > have done. Comcast, as an example, lists all of the ports they block > and 0 is blocked. I do recommend that port 0 be blocked by all of the > ISPs I work with

Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

On Tue, Aug 25, 2020 at 08:27:24AM -0400, K. Scott Helms wrote: > Comcast is blocking it. From the table on that page. > > "Port 0 is a reserved port, which means it should not be used by > applications. Network abuse has prompted the need to block this port." The 'Transport' column seems to ind

Re: Centurylink having a bad morning?

I believe from this moment forward things are converging back to normal. Kind regards, Job

Re: how would draft-ymbk-opsawg-finding-geofeeds work in noam

On Tue, Sep 15, 2020 at 01:52:05PM -0700, Randy Bush wrote: > perchance is RDAP implemented by all RIRs? Yes, but in 5 slightly different ways :-) Kind regards, Job

Re: SPAM for nanog@ senders

Dear Łukasz, others, Can you please send any suspecious emails (including headers) to the mailing list admin team at ge...@nanog.org? We'll try to figure out if it happens through an existing subscription. Kind regards, Job (hat: NANOG geeks) On Mon, Sep 21, 2020 at 12:51:44PM +0200, Octolus D

Re: CIDR cleanup

On Thu, Oct 01, 2020 at 02:15:01PM -0300, Marcos Manoni wrote: > Check https://github.com/job/aggregate6 (thank you, Job) Marco Marzetti (PCCW) wrote an even faster compression tool! https://github.com/lamehost/aggregate-prefixes Both these python implementations are meant as replacements fo

Re: CIDR cleanup

On Fri, Oct 02, 2020 at 03:39:00AM -0700, Randy Bush wrote: > > Marco Marzetti (PCCW) wrote an even faster compression tool! > > https://github.com/lamehost/aggregate-prefixes > > > > Both these python implementations are meant as replacements for ISC's > > vintage 'aggregate' Unix utility, with t

Re: IRR Explorer Error/Issue

Dear Kevin, I am the maintainer of NLNOG's IRRexplorer and can help. On Wed, Oct 07, 2020 at 08:37:00PM +, Kevin McCormick wrote: > There seems to an issue with IRR Explorer. > > I check the following prefix and I get the message, “The server > encountered an internal error and was unable to

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 th

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. I

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 c

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: 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 > o

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 res

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 at

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 b

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 allows

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 w

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 +, Ni

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 w

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 are

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 Gl

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: 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: 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 s

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 reg

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 T

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

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 fr

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 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.

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 shoul

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 8:27

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 to

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 Noc

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 to

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 th

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 imple

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: 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 cus

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: 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 bi

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 pois

Re: 44/8

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

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

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 t

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 hijac

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 +0200

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: 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: Anyone from NTT America here?

Dear Stephen, I’ll work with you off-list to investigate! :-) Kind regards, Job NTT / AS 2914 On Wed, Oct 23, 2019 at 14:23 Ross Tajvar wrote: > What was the source/destination? > > On Wed, Oct 23, 2019, 2:10 PM Stephen Satchell wrote: > >> Routing loop >> >> > 11.|-- 129.250.24.196

Re: SP 800-189 (Draft), Resilient Interdomain Traffic Exchange

Dear Douglas, Thanks for sharing the link. This is an impressive effort! Can you share with the group what the best way is to share feedback to effect changes in the document? Is there a difference between just emailing you or are there official channels to be considered? Kind regards, Job On

A new open source RPKI CA solution: NLnet Labs' Krill

Dear fellow network operators, It appears Santa brought presents early this year! I'd like to draw attention to the below forwarded message and provide my take on it. Some of you represent organisations that interact with multiple RIRs, and have concluded it can be challenging to figure out the R

Re: Comcast & NTT packet loss today

Hi all, We are following up off-list! This may be a good moment to mention that the excellent people at the NTT NOC are always available at n...@ntt.net, or the phone numbers listed in PeeringDB. :-) Kind regards, Job On Tue, Dec 3, 2019 at 23:19 Ben Cannon wrote: > We’re trying to figure ou

Re: Starting to Drop Invalids for Customers

Dear Arturo, group, On Tue, Dec 10, 2019 at 20:51 Arturo Servin wrote: > > Invalid according to RPKI or IRR? Or both? > In this context the use of the word “invalid” refers to the result of validation procedure described in RFC 6811 - which is to match received BGP updates to the RPKI and attac

Re: Holiday route leak

Dear all, On Fri, Dec 27, 2019 at 04:06:24PM -0500, Christopher Morrow wrote: > If there are AS46844 folk listening around their eggnog ... it'd be > nice if you would stop leaking prefixes: https://imgur.com/a/Js0YvP2 > > this from the current view at: https://bgp.he.net/AS15169#_graph6 > > I b

Re: Wikipedia drops support for old Android smartphones; mandates TLSv1.2 to read

On Tue, Dec 31, 2019 at 17:26 Seth Mattinen wrote: > On 12/31/19 8:10 AM, joel jaeggli wrote: > > Argumentation on the basis of a tu quoque fallacy doesn't really add > > much to the dicussion. Depreciating potentialy dangerous and definitely > > obsolete protocols does not make you a hypocrite.

Re: PeeringDB ?

Hi Marco, On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: > Whats happened totady at PeeringDB web site ? We ran out of peerings, but as we speak our service provider is printing new ones ;-) In all seriousness: our SP has issues with a storage array. The staff is aware and they a

Re: PeeringDB ?

On Tue, May 24, 2016 at 12:13:18PM +0200, Marco Paesani wrote: > Whats happened today at PeeringDB web site ? And PeeringDB is back in business! http://instituut.net/~job/screenshots/2f255c17a8aa9cb99121b448.png A post-mortem will be shared on the pdb-tech@ list later today. Kind regards, Job

Re: rfc 1812 third party address on traceroute

On Mon, May 30, 2016 at 10:03:33PM -0700, Randy Bush wrote: >.-. >| | >| B |- D > S -| A R| >| C |- (toward S) >|

Bogon ASN Filter Policy

and reaching out to impacted parties on a weekly basis. Kind regards, Job Contact persons: Job Snijders , Jared Mauch , NTT Communications NOC References: [1]: https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00 [2]: http://www.us.ntt.net/support/policy/routing.cfm#bogon [3]:

Re: intra-AS messaging for route leak prevention

On Mon, Jun 06, 2016 at 11:41:52AM +, Sriram, Kotikalapudi (Fed) wrote: > I am a co-author on a route-leak detection/mitigation/prevention draft > in the IDR WG in the IETF: > https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03 > > > Question: Are there other mean

Re: Bogon ASN Filter Policy

Dear Michael, On Wed, Jun 08, 2016 at 12:56:18PM +, Michael Hare wrote: > Upon examination on my view of the DFZ from AS3128 I see over 400 > upstream routes falling into this category, mostly in the 64512 - > 65534 range. Based on our flow bandwidth stats we chose to reach out > to several o

  1   2   3   4   5   6   >