Re: Small Internet border router options?

[Rubens Kuhl]

Used/Refurbished Cisco ASR 900 or 1000 family, perhaps ?

Rubens

On Mon, May 13, 2024 at 3:53 PM Tom Samplonius  wrote:
>
>
>   What are using for small campus border routers?  So four to eight 10G ports 
> with a FIB for full scale L3?
>
>
> Tom
>
>

Re: route: 0.0.0.0/32 in LEVEL3 IRR

[Rubens Kuhl]

DoD's /8s are usually squatted by networks that run out of private IPv4 space.
Even though it is very risky to steal resources from an organization
that can deploy a black helicopter or a nuclear warhead over you, for
some reason like it not appearing in the DFZ people seem to like it.


Rubens

On Tue, Jan 30, 2024 at 11:40 PM Dave Taht  wrote:
>
> That's pretty cool, actually. I keep wondering when someone will offer
> up a 0.0.0.0/8...
>
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-0-00.html
>
> There must be more people out there than just amazon and google that
> ran out of 10/8.
>
> On Tue, Jan 30, 2024 at 11:29 AM Frank Habicht  wrote:
> >
> > Hi,
> >
> > I got 2 bounces for the email addresses seen below for an email similar
> > to the below...
> >
> > Anyone want to remove this IRR entry before anyone notices...???   ;-)
> >
> > Frank
> >
> >
> > I believe that the entry of
> > route:  0.0.0.0/32
> >
> > does not serve any good purpose?
> >
> > I was surprised to see it in a list of prefixes from bgpq4 and the very
> > good https://irrexplorer.nlnog.net/prefix/0.0.0.0 guided me that it's in
> > "Level3".
> >
> > I'm wondering how many auto-generated filters contain this unnecessary
> > prefix
> >
> > PS: Oh, just seen - it's from TODAY. Maybe remove before anyone sees it...?
> >
> > Thanks for looking into this,
> > Frank
> >
> >
> > [frank@fisi ~]$ whois -h rr.level3.com 0.0.0.0/32
> > [Querying rr.level3.com]
> > [rr.level3.com]
> > route:  0.0.0.0/32
> > origin: AS10753
> > mnt-by: TCCGlobalNV-MNT
> > changed:ankita.gre...@lumen.com
> > source: LEVEL3
> > last-modified:  2024-01-30T11:04:49Z
> >
> >
> > [frank@fisi ~]$ whois -h rr.level3.com TCCGlobalNV-MNT
> > [Querying rr.level3.com]
> > [rr.level3.com]
> > mntner: TCCGlobalNV-MNT
> > descr:  TCC Global N.V.
> > auth:   CRYPT-PW DummyValue  # Filtered for security
> > upd-to: ripehostmas...@eu.centurylink.net
> > tech-c: LTHM
> > admin-c:LTHM
> > mnt-by: TCCGlobalNV-MNT
> > changed:ankita.gre...@lumen.com
> > source: LEVEL3
> > last-modified:  2024-01-30T11:01:52Z
> >
>
>
> --
> 40 years of net history, a couple songs:
> https://www.youtube.com/watch?v=D9RGX6QFm5E
> Dave Täht CSO, LibreQos

Re: Networks ignoring prepends?

[Rubens Kuhl]

You can use the ultimate BOFH BGP tool, which is to include the
network you don't want those announcements to go in the AS Path.
Let's say your ASN is 65000, and the target you want to not route
through that path is 65001.

For the path you want that network to route to, announce this AS Path:
65000 65000 65000 65000 65000

For the path you don't want that network to route to, announce this AS Path:
65000 65001 65000

So your announcements still have your AS as first AS and peer AS. But
65001 loop detection will kill that announcement, regardless of local
preference or AS Path size.


Rubens



On Mon, Jan 22, 2024 at 9:50 AM William Herrin  wrote:
>
> Howdy,
>
> Does anyone have suggestions for dealing with networks who ignore my
> BGP route prepends?
>
> I have a primary ingress with no prepends and then several distant
> backups with multiple prepends of my own AS number. My intention, of
> course, is that folks take the short path to me whenever it's
> reachable.
>
> A few years ago, Comcast decided it would prefer the 5000 mile,
> five-prepend loop to the short 10 mile path. I was able to cure that
> with a community telling my ISP along that path to not advertise my
> route to Comcast. Today it's Centurylink. Same story; they'd rather
> send the packets 5000 miles to the other coast and back than 10 miles
> across town. I know they have the correct route because when I
> withdraw the distant ones entirely, they see and use it. But this time
> it's not just one path; they prefer any other path except the one I
> want them to use. And Centurylink is not a peer of those ISPs, so
> there doesn't appear to be any community I can use to tell them not to
> use the route.
>
> I hate to litter the table with a batch of more-specifics that only
> originate from the short, preferred link but I'm at a loss as to what
> else to do.
>
> Advice would be most welcome.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: Any clue as to when bgp.he.net will be back?

[Rubens Kuhl]

It might be due to usage of a new gTLD like .tools. A number of new
gTLDs use heavy discounting and this is a magnet for abusive
registrations, unfortunately.

Rubens

On Wed, Jan 17, 2024 at 2:15 PM Tim Burke  wrote:
>
> +1 for bgp.tools, it is a superior tool. Sadly, the corporate IT-forced DNS 
> filtering at work for “cybersecurity” (Mimecast) thinks it is a compromised 
> website for some reason, so bgp.he.net ends up being used while I am at the 
> office.
>
> On Jan 16, 2024, at 8:44 AM, Ian Chilton  wrote:
>
> Hi,
>
> Not a direct answer to your question, but if you're not aware of it, 
> https://bgp.tools/ is a great tool and shows the same info.
>
> Ian
>
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Rubens Kuhl]

What I've found missing were references to packet loss impact on
performance. It seems to assume cable/fiber environments with little
to no packet loss, while Wi-Fi and 3G/4G/5G  are not like that.

Rubens


On Fri, Dec 1, 2023 at 7:23 AM Dave Taht  wrote:
>
> Over here:
>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> Us bufferbloat folk have been putting together a response to the FCC's
> NOI (notice of inquiry) asking for feedback as to increasing the
> broadband speeds beyond 100/20 Mbit.
>
> "Calls for further bandwidth increases are analogous to calling for
> cars to have top speeds of 100, 200, or 500 miles per hour. Without
> calling also for better airbags, bumpers, brakes, or steering wheels,
> (or roads designed to minimize travel delay), these initiatives will
> fail (and are failing) to meet the needs of present and future users
> of the internet."
>
> Comments (and cites) welcomed also! The text is still somewhat in flux...
>
>
> --
> :( My old R campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos

Re: Advantages and disadvantages of legacy assets

[Rubens Kuhl]

On Mon, Nov 20, 2023 at 4:15 PM Lukas Tribus  wrote:
>
> On Mon, 20 Nov 2023 at 20:08, Rubens Kuhl  wrote:
> >
> > You can get IRR from RADB or AltDB.
>
> Which is not going to be useful forever ... see [1]:
>
> > Please note that 'route' and 'route6' objects created after 2023-Aug-15
> > in non-authoritative registries like RADB, NTTCOM, ALTDB won't be
> > processed.
>
>
>
>
> [1] https://lg.as6453.net/doc/cust-routing-policy.html

First time I see a Tier-1 complaining about non-authoritative IRR. I
wonder what they do with IRR sources that do validate although not
being run by a RIR/NIR, like TC.


Rubens

Re: Advantages and disadvantages of legacy assets

[Rubens Kuhl]

You can get IRR from RADB or AltDB.

Rubens

Em seg., 20 de nov. de 2023, 16:00, Eric Dugas via NANOG 
escreveu:

> Greetings!
>
> Let's say you inherit legacy assets (ASN & IPv4 netblock), what are the
> first advantages that come to mind (beside not having to pay annual fees).
>
> Any disadvantages? The ones I can think of is the lack of RIR routing
> security services (in the ARIN region at least). No IRR, no RPKI at all.
>
> Eric
>

Re: .US Harbors Prolific Malicious Link Shortening Service

[Rubens Kuhl]

On Thu, Nov 2, 2023 at 5:46 PM William Herrin  wrote:
>
> On Thu, Nov 2, 2023 at 1:30 PM goemon--- via NANOG  wrote:
> > https://krebsonsecurity.com/2023/10/us-harbors-prolific-malicious-link-shortening-service/
> >
> > What hope is there when registrars are actively aiding and abeting criminal 
> > enterprises?
>
> I'm confused. Does .com/.net/.org have a different/better
> vulnerability profile to these third party link shorteners?

This is likely related to NTIA ongoing consultation on redacting .us
WHOIS. Everytime such a movement happens, a number of reports showing
the world will end because of that appear.

Rubens

Re: RPKI unknown for superprefixes of existing ROA ?

[Rubens Kuhl]

On Sun, Oct 22, 2023 at 5:47 PM Job Snijders via NANOG  wrote:
>
> On Sun, 22 Oct 2023 at 17:42, Amir Herzberg  wrote:
>>
>> Bill, thanks! You explained the issue much better than me. Yes, the problem 
>> is that, in my example, the operator was allocated  1.2.4/22 but the 
>> attacker is announcing  1.2.0/20, which is larger than the allocation, so 
>> the operator cannot issue ROA for it (or covering it). Of course, the RIR 
>> _could_ do it (but I don't think they do, right?). So this `superprefix 
>> hijack' may succeed in spite of all the ROAs that the operator could publish.
>>
>> I'm not saying this is much of a concern, as I never heard of such attacks 
>> in the wild, but I guess it _could_ happen in the future.
>
>
>
> How is “success” measured here?
>
> The attacker won’t be drawing traffic towards itself destined for addresses 
> in the /22, because of LPM
> https://en.wikipedia.org/wiki/Longest_prefix_match
>
> Attackers don’t hijack IP traffic by announcing less-specifics. It don’t work 
> that way.


Even for positive ROAs (not AS 0 ROAs), that depends on how much of a
region's routers have full-routes or use partial routes.
In Brazil there are still many Mikrotik devices being used by
BGP-speaking networks that fumble on full-routes, and the offending
announcement might not have a LPM to choose from.

That might be yet more prevalent in routers connecting to IXPs,
because even default-route networks would see those announcements
without a LPM to follow.



Rubens

Re: Discord contacts

[Rubens Kuhl]

This issue is also happening with services other than Discord, so
pointing to a Cloudflare issue.

Discord may be just the canary in the coal mine.


Rubens

On Fri, Sep 29, 2023 at 9:34 AM Drew Weaver  wrote:
>
> Any contacts from Discord here? Just started seeing cloudflare blocking 
> 250,000 IP addresses.
>
>
>
> Thanks,
>
> -Drew
>
>

Re: AFRINIC placed in receivership

[Rubens Kuhl]

> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual text 
> of their bylaws attempted
> to revoke CI space and created major disruptions to a number of networks in 
> the process. Had CI
> not received the injunctions they got from the courts, likely the disruption 
> would have been much
> worse and caused some pretty wide-spread outages.

If a car is stolen and then used to provide ride sharing services,
when the repo man comes along, it will cause disruption to those ride
sharing services.


Rubens

Re: AFRINIC placed in receivership

[Rubens Kuhl]

On Fri, Sep 15, 2023 at 9:04 AM John Curran  wrote:
>
> Indeed - AFRINIC has been going through quite a bit over the few months – 
> including loss of their governing board – but the receiver appointment 
> actually provides a fairly straightforward path towards resolution.
>
> See the NRO statement on this matter for specifics.


I don't see the appointment of a technical advisor to the receiver
related to the party which is suing AFRINIC as positive.
Sounds more like a conflict of interest to me.


Rubens

Re: it's mailman time again

[Rubens Kuhl]

What cleartext ? Opportunistic encryption and/or DANE FTW.

Rubens

On Fri, Sep 1, 2023 at 2:19 PM Randy Bush  wrote:
>
> and i just have to wonder about sending passords over the net in
> cleartext in 2023.  really?
>
> randy

Re: Someone (with clue) from GoDaddy, please pick up the red courtesy phone?

[Rubens Kuhl]

On Thu, Aug 31, 2023 at 2:07 PM Dan Mahoney (Gushi)
 wrote:
>
> Hey there.
>
> I hate that I only use NANOG for this, but it seems right now
> that my day job can't add an additional nameserver to our NS-set.
>
> There's no email support or ticket system, and I've been told several
> untrue things about how the DNS and SRS work in text-based chat, and I
> Need An Adult.

Does that include stating that Premium DNS is required to add DS
records to parent delegations even with no GoDaddy DNS servers
involved ?


Rubens

Re: Dodgy AS327933 ...?

[Rubens Kuhl]

On Tue, Aug 15, 2023 at 6:30 PM Mike Hammett  wrote:

> Most people I know don't even use the CLI. They use Winbox.
>
>
Actually, Winbox used to crash configuring BGP due to displaying full
routes if the router gets them.
So there is saying in Mikrotik communities to use CLI for BGP, while
keeping overall admin via Winbox.


Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

So little deployment that has 3500 occurrences according to shodan.io.
With such few choices, It should be hard to find suitable options.

Rubens




Em ter., 8 de ago. de 2023 13:02, Mel Beckman  escreveu:

> I’m familiar with NTS, which is pointedly not NTP.  That’s like saying
> “TCP port 80 can be made secure,: just use a VPN!” Perhaps when NTS is
> widely deployed it will be an option. As the RFC was only approved in 2020,
> that will probably take a decade. Or more. (I’m talking about you, IPv6 :)
> Not to mention the complexity or NTS for hardware implementation in network
> elements, a primary application (https://tinyurl.com/ntsishard).
>
>  -mel
>
> > On Aug 8, 2023, at 8:26 AM, Rubens Kuhl  wrote:
> >
> > On Tue, Aug 8, 2023 at 12:12 PM Mel Beckman  wrote:
> >>
> >> Until the Internet NTP network can be made secure, no.
> >
> > Internet NTP can be made secure, it's called NTS.
> > https://developers.cloudflare.com/time-services/nts/ describes it with
> > links to the RFC, and describes one of the many NTP servers that is
> > available with NTS, time.cloudflare.com. I already mentioned 5 others,
> > and there are many more than those 6.
> >
> >
> > Rubens
>

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

On Tue, Aug 8, 2023 at 12:12 PM Mel Beckman  wrote:
>
> Until the Internet NTP network can be made secure, no.

Internet NTP can be made secure, it's called NTS.
https://developers.cloudflare.com/time-services/nts/ describes it with
links to the RFC, and describes one of the many NTP servers that is
available with NTS, time.cloudflare.com. I already mentioned 5 others,
and there are many more than those 6.


Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

The paper suggests the compromise of critical infrastructure. So, besides
not using NTP, why not stop using DNS ? Just populate a hosts file with all
you need.

BTW, the stratum-0 source you suggested is known to have been manipulated
in the past (https://www.gps.gov/systems/gps/modernization/sa/), so you
need to bet on that specific state actor not returning to old habits.

OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you
can keep using GPS as well. If GPS goes bananas on timing, that source will
just be disregarded (one of the features of the NTP architecture that has
been pointed out over and over in this thread and you keep ignoring it).

Rubens



Rubens



On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  wrote:

> Or one can read recent research papers that thoroughly document the
> incredible fragility of the existing NTP hierarchy and soberly consider
> their recommendations for remediation:
>
> [image: preview.png]
>
> ndss2021_1A-2_24302_paper
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
> PDF Document · 1.7 MB
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
>
> <https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1A-2_24302_paper.pdf>
>
> Or simply use non-Internet NTP servers based on a Stratum-0 GPS source for
> mission-critical network timing.
>
> Until then, we may all wake up one morning and discover massive data
> breaches traced to an unfounded reliance on insecure public NTP servers.
> Then the game truly will be over, but not in our favor.
>
>  -mel
>
> On Aug 6, 2023, at 2:35 PM, Rubens Kuhl  wrote:
>
> Or one can select NTS-capable NTP servers, like those 5:
> a.st1.ntp.br
> b.st1.ntp.br
> c.st1.ntp.br
> d.st1.ntp.br
> gps.ntp.br
>
> Or any other NTP server that has NTS deployed. Game-over for NTP
> impersonation.
>
>
> Rubens
>
> On Sun, Aug 6, 2023 at 4:41 PM Mel Beckman  wrote:
>
>
> In a nutshell, no. Refer to my prior cites for detailed explanations. For
> a list of real-world attack incidents, see
>
>
> https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse#
>
>
>
> -mel
>
>
> On Aug 6, 2023, at 12:03 PM, Royce Williams 
> wrote:
>
>
> 
>
> Naively, instead of abstaining ;) ... isn't robust diversity of NTP
> peering a reasonable mitigation for this, as designed?
>
>
> Royce
>
>
> On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman  wrote:
>
>
> William,
>
>
> Due to flaws in the NTP protocol, a simple UDP filter is not enough. These
> flaws make it trivial to spoof NTP packets, and many firewalls have no
> specific protection against this. in one attack the malefactor simply fires
> a continuous stream of NTP packets with invalid time at your firewall. When
> your NTP client queries the spoofed server, the malicious packet is the one
> you likely receive.
>
>
> That’s just one attack vector. There are several others, and all have
> complex remediation. Why should people bother being exposed to the risk at
> all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve
> already described. Having suffered through such attacks more than once, I
> can say from personal experience that you don’t want to risk it.
>
>
>

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

> > The paper suggests the compromise of critical infrastructure. So, besides 
> > not using NTP, why not stop using DNS ? Just populate a hosts file with all 
> > you need.
>
> Well DNS can be cryptographically secured.  There really isn’t any good 
> reasons to not sign your zones today.  The majority of responses from 
> authoritative servers are validated today so if you sign the responses will 
> be checked.  Unfortunately most to those validations still result in insecure 
> instead of secure because people are not signing their zones.

So does NTP, with NTS.

https://datatracker.ietf.org/doc/html/rfc8915


Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

On Sun, Aug 6, 2023 at 11:36 PM Mel Beckman  wrote:
>
> GPS Selective Availability did not disrupt the timing chain of GPS, only the 
> ephemeris (position information).  But a government-disrupted timebase 
> scenario has never occurred, while hackers are a documented threat.
>
> DNS has DNSSec, which while not deployed as broadly as we might like, at 
> least lets us know which servers we can trust.

NTP has NTS, which all 5 servers I mentioned have, and many more also have.

> Your own atomic clocks still have to be synced to a common standard to be 
> useful. To what are they sync’d? GPS, I’ll wager.

Nope, they are synced to the reference atomic clock of National
Observatory, pretty similar to USNO but local.

Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

On Sun, Aug 6, 2023 at 8:20 PM Mel Beckman  wrote:

> Or one can read recent research papers that thoroughly document the
> incredible fragility of the existing NTP hierarchy and soberly consider
> their recommendations for remediation:
>

The paper suggests the compromise of critical infrastructure. So, besides
not using NTP, why not stop using DNS ? Just populate a hosts file with all
you need.

BTW, the stratum-0 source you suggested is known to have been manipulated
in the past (https://www.gps.gov/systems/gps/modernization/sa/), so you
need to bet on that specific state actor not returning to old habits.

OTOH, 4 of the 5 servers I suggested have their own atomic clock, and you
can keep using GPS as well. If GPS goes bananas on timing, that source will
just be disregarded (one of the features of the NTP architecture that has
been pointed out over and over in this thread and you keep ignoring it).

Rubens

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

Or one can select NTS-capable NTP servers, like those 5:
a.st1.ntp.br
b.st1.ntp.br
c.st1.ntp.br
d.st1.ntp.br
gps.ntp.br

Or any other NTP server that has NTS deployed. Game-over for NTP impersonation.


Rubens

On Sun, Aug 6, 2023 at 4:41 PM Mel Beckman  wrote:
>
> In a nutshell, no. Refer to my prior cites for detailed explanations. For a 
> list of real-world attack incidents, see
>
> https://en.m.wikipedia.org/wiki/NTP_server_misuse_and_abuse#
>
>
>  -mel
>
> On Aug 6, 2023, at 12:03 PM, Royce Williams  wrote:
>
> 
> Naively, instead of abstaining ;) ... isn't robust diversity of NTP peering a 
> reasonable mitigation for this, as designed?
>
> Royce
>
> On Sun, Aug 6, 2023 at 10:21 AM Mel Beckman  wrote:
>>
>> William,
>>
>> Due to flaws in the NTP protocol, a simple UDP filter is not enough. These 
>> flaws make it trivial to spoof NTP packets, and many firewalls have no 
>> specific protection against this. in one attack the malefactor simply fires 
>> a continuous stream of NTP packets with invalid time at your firewall. When 
>> your NTP client queries the spoofed server, the malicious packet is the one 
>> you likely receive.
>>
>> That’s just one attack vector. There are several others, and all have 
>> complex remediation. Why should people bother being exposed to the risk at 
>> all? Simply avoid Internet-routed NTP. there are many solutions, as I’ve 
>> already described. Having suffered through such attacks more than once, I 
>> can say from personal experience that you don’t want to risk it.
>>

Re: NTP Sync Issue Across Tata (Europe)

[Rubens Kuhl]

If the path has simmetric one way latencies you don't have to pick a lower
latency faulty one. Perhaps creating a selection at startup and then using
that collection ?

Rubens

Em sáb., 5 de ago. de 2023 12:42, Mark Tinka  escreveu:

> Hi all.
>
> I have NTP servers in Europe that are choosing Tata (6453) to get to
> 0.freebsd.pool.ntp.org which lives on 197.224.66.40:
>
> traceroute -I 0.freebsd.pool.ntp.org
> traceroute to 0.freebsd.pool.ntp.org (197.224.66.40), 64 hops max, 48
> byte packets
>  1  ae-2-24.er-01-ams.nl.seacomnet.com (105.26.64.13)  0.300 ms  0.301
> ms  0.215 ms
>  2  ce-0-0-11.cr-01-mrs.fr.seacomnet.com (105.16.8.201)  22.163 ms
> 22.370 ms  22.084 ms
>  3  ce-0-0-3.br-01-mrs.fr.seacomnet.com (105.16.32.254)  20.230 ms
> 20.243 ms  20.139 ms
>  4  ix-hge-0-0-0-28.ecore3.emrs2-marseille.as6453.net (80.231.165.52)
> 21.875 ms  21.679 ms  21.762 ms
>  5  * if-be-3-2.ecore2.emrs2-marseille.as6453.net (195.219.175.0)  42.751
> ms *
>  6  if-ae-25-2.tcore1.ldn-london.as6453.net (195.219.175.5)  43.509 ms
> 43.280 ms  43.353 ms
>  7  195.219.83.158 (195.219.83.158)  203.310 ms  203.452 ms  203.209 ms
>  8  196.20.225.84 (196.20.225.84)  208.289 ms  208.637 ms  208.374 ms
>  9  197.226.230.13 (197.226.230.13)  209.657 ms  209.658 ms  209.830 ms
> 10  197.224.66.40 (197.224.66.40)  208.638 ms  208.632 ms  208.712 ms
>
> NTP is not sync'ing to that address, and sessions stay in an Init state.
>
> Other NTP servers I have in Africa are reaching the same address via local
> Anycast hosters, and sync'ing just fine.
>
> Anyone else seeing this particular issue across Tata in Europe?
>
> Mark.
>

Re: IP range for lease

[Rubens Kuhl]

> Too much grey area with respect to property rights (or lack thereof) as they 
> relate to INRs. Until there is more concrete case law on the matter, which 
> isn't likely to happen in most of our careers, monetizing it will be the rule.

Hopefully IPv4 becomes irrelevant (although still used) before that
happens. That said, the history of other US high courts decisions on
critical resources (domains + numbers) is of very reasoned decisions,
so if one comes along, it will likely not be what "monetizers" would
prefer.


Rubens

Re: Your input sought on PeeringDB's Network Type field

[Rubens Kuhl]

Clarify: sure.
Remove: don't remove. Please. Pretty please.


Rubens

On Wed, Jun 14, 2023 at 12:18 PM Leo Vegoda  wrote:
>
> Hi,
>
> PeeringDB's Product Committee wants your input on whether the Network
> Type field is useful. Should it go? Should it change?
>
> We have published a very short blog post describing the options and
> linking to the survey.
>
> https://docs.peeringdb.com/blog/network_type_your_input_sought/
>
> Your input will influence our decision.
>
> Thanks,
>
> Leo Vegoda for PeeringDB's Product Committee

Re: Dominican Republic Landing Station

[Rubens Kuhl]

https://www.submarinecablemap.com/ lists 4 CLS in Dominican Republic:
Haina, Macao Beach, Puerto Plata and Punta Cana.

Rubens




On Thu, May 18, 2023 at 9:15 PM Robert DeVita 
wrote:

> Does anyone have the address to the Cable Landing Station in Dominican
> Republic. I am told there is only 1 and I believe its in Punta Cana. Yes I
> spent 25 minutes trying to google it. Any help would be appreciated
>
>
>
> Thanks
>
>
>
> *Robert DeVita**​**​**​**​*
>
> *CEO and Founder*
>
> t: (469) 581-2160 <(469)%20581-2160>
>
>  |
>
> m: (469) 441-8864 <(469)%20441-8864>
>
> e: radev...@mejeticks.com
>
>  |
>
> w: mejeticks.com 
>
> a:
>
> 3100 Carlisle St
>
> ,
>
> Dallas
>
> ,
>
> 75204
>
> 
>
> 
>
> 
>
>
>

Re: Can rr.ntt.net have a AAAA record please?

[Rubens Kuhl]

TC (bgp.net.br) has both A and  records and will gladly respond to
anything that it mirrors.

Rubens

On Sun, Feb 5, 2023 at 3:36 PM Willy Manga  wrote:
>
> Hi,
>
> Dear admin of rr.ntt.net ,
>
> I'm not one of your customers, but can you please enable IPv6 on your
> routing registry?
>
> I have to ask because (at least) those using tools like bgpq4 query by
> default your registry. And if you are using IPv6, your registry is only
> reachable if I enable a transition technique.
>
> Thank you in advance :)
>
> --
> Willy Manga
> @ongolaboy
> https://ongola.blogspot.com/

Fwd: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Rubens Kuhl]

(forwarded to break thread since this is a different topic)
What's the group's current thought on emergence or prevalence of
IPv6-only hosts ? Will they exist soon, in some time or in a very long
time?


Rubens


-- Forwarded message -
From: 
Date: Mon, Nov 21, 2022 at 8:02 PM
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
To: NANOG 



My suggestion is ignore anyone who says it would be too difficult to
get people to adopt a change or take too long. Someone always says
that, a reasonable riposte is "what would be a reasonable number of
people / years?" Surely they must have some numbers in mind, no?

We've been trying to get people to adopt IPv6 widely for 30 years with
very limited success so perhaps that's a pretty time to shoot for, for
example. Anything less than 30 years would be an improvement.

I suppose some might leap on that as evidence of the above cautions
but it's really not. It's just being argumentative. It feels like a
reasonable argument pattern but it's not because it ignores why that
previous attempt mostly failed and tries to equate them (we failed for
30 years so therefore you will fail for 30 years???)

That said, what's needed is a working demo preferably within both a
simulation environment and live because the devil is always in the
details and the only way to vet that is by testing working code.

A mere proposal is of some value, one can glance at it and try to spot
any fatal flaws for example. But it's only a tiny step along the path.

However, that it might take a while to become adopted is, to me, like
saying forget trying to mitigate climate change, it'll take decades
and require hundreds of govts, thousands of industries, and billions
of people to change their behavior which is all true but hardly an
argument as to why not to try.

Aside: A pretty good rule of thumb with replacement technologies is
that something has to be 10x better than what it replaces to get wide
adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
certainly not introduce impediments to its own adoption and use.

On November 21, 2022 at 12:00 beec...@beecher.cc (Tom Beecher) wrote:
 > As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 >
 >
 > Some friendly feedback. The phrase "all that needs to be done" , is
 > exceptionally reductive, and in the case of internet standards, also always
 > going to end up being wrong.
 >
 > On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  wrote:
 >
 > Dear Mark:
 >
 > 0) Thanks for the clarification. I understand. A short message through
 > the cyberspace, especially between parties who have never met can be
 > easily skewed. I am glad that I asked you, instead of taking it
 > negatively without raising my hand.
 >
 > 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
 > ": Since EzIP is still being further refined, it may not be clear in our
 > documentation about how much work is required to get the IPv4 out of the
 > current depletion mode. As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 > In fact, we have found examples that this means commenting out one line
 > code that searches for then discards packets with 240/4 addressing. It
 > seems to me that there is no easier task than this.
 >
 > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
 >
 > Regards,
 >
 > Abe (2022-11-21 11:18 EST)
 >
 >
 >
 > On 2022-11-20 23:56, Mark Tinka wrote:
 > >
 > >
 > > On 11/20/22 19:02, Abraham Y. Chen wrote:
 > >
 > >> Dear Mark:
 > >>
 > >> 0)  I am surprised at your apparently sarcastic opinion.
 > >>
 > >> 1)  The EzIP proposal as referenced by my last MSG is the result of
 > >> an in-depth system engineering effort. Since the resultant schemes do
 > >> not rely on any protocol development, IETF does not need be involved.
 > >> Especially, its first step of disabling one line of existing
 > >> networking program code empowers any party to begin deploying EzIP
 > >> stealthily for mitigating the IPv4 address pool depletion issues.
 > >> Note that EzIP is a generic solution applicable to everyone, not
 > >> limited to Africa.
 > >>
 > >> 2)  Of course, constructive criticism is always appreciated. However,
 > >> unspecific comments that confuse and distract the readers only
 > >> provide dis-service to those disadvantaged population who are
 > >> enduring the handicaps of being the late-comers to the Internet.
 > >
 > > My comment was not directed at you. Sorry.
 > >
 > > I have nothing against the EzIP proposal. It just 

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Rubens Kuhl]

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen  wrote:
>
> Dear Mark:
>
> 0)  I am surprised at your apparently sarcastic opinion.
>
> 1)  The EzIP proposal as referenced by my last MSG is the result of an
> in-depth system engineering effort. Since the resultant schemes do not
> rely on any protocol development, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12
versions of your Internet draft to IETF ?
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/

Rubens

Re: ipv4/25s and above

[Rubens Kuhl]

On Sat, Nov 19, 2022 at 5:13 PM Douglas Fischer
 wrote:
>
> I do not like mikrotik, but I need to say that RouterOS does support /31.
>
> All that you need to do, beyond set /31 at address for netmask, is check if 
> the other address is defined at the network address.


Is /31 supported only in bleeding-edge versions such as v7 or in the
more conventional RouterOS versions ?


Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 12:45 PM William Herrin  wrote:
>
> On Thu, Sep 15, 2022 at 9:09 PM Rubens Kuhl  wrote:
> > On Fri, Sep 16, 2022 at 11:55 AM William Herrin  wrote:
> > > No, the best option for me right now is that I just don't participate
> > > in RPKI and the system has one less participant. And that's a shame.
> >
> > That's only true in the current environment where RPKI is only used to
> > invalidate bogus routes. When any reachability for RPKI-unknowns is
> > lost, that will change.
>
> Hi Rubens,
>
> If you want to bet me on folks ever deciding to discard RPKI-unknowns
> down in the legacy class C's I'll be happy to take your money.

I don't think people will look at even the class, and definitively not
to legacy or non-legacy partitions.
They will either drop it all, or not drop it at all.

Note that when the only IP blocks that spammers and abusers can inject
in the system are non-signed ones, those blocks will get bad
reputations pretty fast. So the legacy holders use case for RPKI might
come sooner than you think.

> Anyway, the risk/reward calculation for NOT signing the LRSA right now
> is really a no-brainer. It's just unfortunate that means I won't get
> an early start on RPKI.

Discarding RPKI-invalids is something you can do right now and that
doesn't come with a price tag. Good BCP38 and RPKI-invalid hygiene is
the thankless gift you can give to the community.


Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 11:55 AM William Herrin  wrote:
>
> On Thu, Sep 15, 2022 at 8:51 PM Rubens Kuhl  wrote:
> > On Fri, Sep 16, 2022 at 10:56 AM William Herrin  wrote:
> > > Well, I'm one of the people who'd publish RPKI records for my /23 if I
> > > had the ability to do so and I definitely would NOT pay merit $595/yr
> > > (let alone $1k or $2k) to gain that ability. YMMV but I'm willing to
> > > bet there's not enough money out there to fund it with direct user
> > > fees and even if there was, the level of participation in the presence
> > > of more than trivial user fees would be too low to be worth the
> > > effort.
> >
> > Your /23 is worth only USD 30k, so you are definitely not in a
> > position to find that affordable.
> > It seems ARIN LRSA with the current fees and caps would be the best
> > option, and that option has a time limit.
>
> No, the best option for me right now is that I just don't participate
> in RPKI and the system has one less participant. And that's a shame.

That's only true in the current environment where RPKI is only used to
invalidate bogus routes. When any reachability for RPKI-unknowns is
lost, that will change. But it will be too late then to join the
system, so you just sell it for USD 50k and start using NAT.

Just a calculation: current LRSA fee is USD 150, cap is 25 USD per
year increase. 2X-Small is USD 500 per year, so it will take 14 years
to reach that level. Pick your poison, NAT or LRSA.


Rubens



Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 10:56 AM William Herrin  wrote:
>
> On Thu, Sep 15, 2022 at 7:46 PM Rubens Kuhl  wrote:
> > Legacy holders are sitting on millions or billions worth of assets.
> > RADB USD 595 a year is pennies in comparison, and USD 1k or 2k a year
> > for the RPKI service would still be 1E-10 of the asset value.
>
> Hi Rubens,
>
> Well, I'm one of the people who'd publish RPKI records for my /23 if I
> had the ability to do so and I definitely would NOT pay merit $595/yr
> (let alone $1k or $2k) to gain that ability. YMMV but I'm willing to
> bet there's not enough money out there to fund it with direct user
> fees and even if there was, the level of participation in the presence
> of more than trivial user fees would be too low to be worth the
> effort.


Your /23 is worth only USD 30k, so you are definitely not in a
position to find that affordable.
It seems ARIN LRSA with the current fees and caps would be the best
option, and that option has a time limit.


Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 10:41 AM William Herrin  wrote:
>
> On Thu, Sep 15, 2022 at 7:32 PM Rubens Kuhl  wrote:
> > On Fri, Sep 16, 2022 at 9:46 AM William Herrin  wrote:
> > > On Thu, Sep 15, 2022 at 4:07 PM Randy Bush  wrote:
> > > > > You could try suggesting IANA/PTI/ICANN to have a different RPKI trust
> > > > > anchor and provide such services to legacy block holders.
> > > >
> > > > the rpki design cabal assumed the iana would be the rpki root.  rir
> > > > power players blocked that.  so each rir is 0/0.  brilliant, eh?
> > >
> > > Which means that all you'd need is a volunteer group with "street
> > > cred" to set up an RPKI for legacy holders and then convince folks to
> > > use their trust anchor too. Or have I missed something?
> >
> > Merit, perhaps ?
> >
> > But they would need to do a much stricter validation that they
> > currently have in RADB, which is more like Sledgehammer motto "Trust
> > me, I know what I'm doing".
>
> Hi Rubens,
>
> Last I checked, Merit was -really- expensive for RADB. I don't really
> see getting more than about 5 figures total per year out of the legacy
> registrants for RPKI, if that much. I think it'd have to be a
> volunteer effort or something funded by someone who finds it to their
> advantage that the legacy registrants publish RPKI records. Like the
> way Letsencrypt is funded.


Legacy holders are sitting on millions or billions worth of assets.
RADB USD 595 a year is pennies in comparison, and USD 1k or 2k a year
for the RPKI service would still be 1E-10 of the asset value.

Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 9:46 AM William Herrin  wrote:
>
> On Thu, Sep 15, 2022 at 4:07 PM Randy Bush  wrote:
> > > You could try suggesting IANA/PTI/ICANN to have a different RPKI trust
> > > anchor and provide such services to legacy block holders.
> >
> > the rpki design cabal assumed the iana would be the rpki root.  rir
> > power players blocked that.  so each rir is 0/0.  brilliant, eh?
>
> Which means that all you'd need is a volunteer group with "street
> cred" to set up an RPKI for legacy holders and then convince folks to
> use their trust anchor too. Or have I missed something?

Merit, perhaps ?

But they would need to do a much stricter validation that they
currently have in RADB, which is more like Sledgehammer motto "Trust
me, I know what I'm doing".


Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

On Fri, Sep 16, 2022 at 7:07 AM Randy Bush  wrote:
>
> > You could try suggesting IANA/PTI/ICANN to have a different RPKI trust
> > anchor and provide such services to legacy block holders.
>
> the rpki design cabal assumed the iana would be the rpki root.  rir
> power players blocked that.  so each rir is 0/0.  brilliant, eh?

I'm not fond of that decision either, but at this point it is how it
is. We already have the operation of inter-RIR reverse DNS
synchronization since each /8 is not single-RIR anymore, and I believe
a similar mechanism could have allowed for a single RPKI root.

But I note that the 0/0 trust anchors preceded IANA transition to PTI,
and that even after the transition, we still have an organization that
doesn't have jurisdictional immunity in the US to prevent possible
petty challenges to the system. So the world at large still benefits
from the multiple trust anchor design, when all trade-offs are
accounted for.


Rubens

Re: [External] Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 Decembe

[Rubens Kuhl]

You could try suggesting IANA/PTI/ICANN to have a different RPKI trust
anchor and provide such services to legacy block holders. As you
mentioned, that would probably have a price tag attached to it to
cover the costs for such operations, but a contract could stay away
from ownership issues and not either say the blocks are yours or that
the blocks could be taken from you. Pay for the services, get RPKI;
don't pay them, RPKI ROAs expire.

I have a feeling that the recurring cost would be higher than using
the scale that the RIR system has in providing those services, and
that doing RIR-shopping (like what was already suggested here, moving
the resources to RIPE) is simpler and more cost effective. But this
would at least expose the real costs without making the RIR-allocated
resource holders subsidize legacy resource holders, which is the good
thing I see in the direction ARIN is going.

Rubens

On Fri, Sep 16, 2022 at 5:18 AM Tom Krenn via NANOG  wrote:
>
> Speaking from the enterprise / end site perspective I would bet there are a 
> lot of legacy holders that other than maybe updating their reverse DNS 
> records once or twice haven’t looked at ARIN policies or their allocation 
> since the late 1980s. In most cases there really is not strong technical 
> reason to, the stuff just keeps working.
>
> We are put in kind of an awkward place by the current policies. On one hand 
> some of us would like to be good Internet citizens and implement things like 
> IRR and RPKI for our resources to help the larger community. But show the 
> RSA/LRSA to your lawyers with the justification that "I would like to 
> implement RPKI, but everything will keep working even if we don't." You can 
> bet they will never jump on board. On one hand there is a push from ARIN and 
> the larger community to use these advanced services, but on the other hand 
> the fees and risk far outweigh the benefits. (Heck the fees aren’t even that 
> big of a deal, just the risk of loosing control of our legacy allocations.)
>
> Tom Krenn
> Network Architect
> Enterprise Architecture - Information Technology
>
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of John 
> Curran
> Sent: Thursday, September 15, 2022 3:35 PM
> To: John Gilmore 
> Cc: North American Network Operators' Group 
> Subject: [External] Re: Normal ARIN registration service fees for LRSA 
> entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the 
> Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)
>
> CAUTION: This email was sent from outside of Hennepin County. Unless you 
> recognize the sender and know the content, do not click links or open 
> attachments.
>
> John -
>
> Your summary is not inaccurate; I will note that ARIN’s approach is the 
> result of aiming for a different target – that more specifically being the 
> lowest possible fees administered on an equitable basis for _all resource 
> holders_ in the region.
>
> For more than two decades legacy resource holders have been provided the 
> opportunity to normalize their relations with ARIN by entry into an LRSA - 
> thus receiving the same services on the same terms and conditions as all 
> others in the region (and also with a favorable fee cap applied to their 
> total annual registry fees.)  While many folks have taken advantage of that 
> offer over the years, it’s quite possible that all of those interested have 
> already considered the matter and hence going forward we are returning to the 
> refrain of the entire community in seeking the lowest fees applied equitably 
> to all in the region.
>
> As we’ve recently added more advanced services that may be of interest to 
> many in the community (RPKI and authenticated IRR) and also have just made a 
> favorable simplification to the RSA in section 7 (an area that has been 
> problematic for some organizations in the past), it is important that ARIN 
> not subset availability of the legacy fee cap without significant notice, as 
> there many be a few folks out there who were unaware of LRSA with fee cap 
> availability and/or haven’t recently taken a look at the various tradeoffs.
>
> In any case, legacy resource holders who don’t care for these advanced 
> services (whose development and maintenance is paid for by the ARIN 
> community) can simply continue to maintain their legacy resources in the ARIN 
> registry.  They do not have to do anything, as ARIN is continuing to provide 
> basic registration services to the thousands of non-contracted legacy 
> resource holders (including online updates to your resources, reverse DNS 
> services,
> etc.) without fee or contract.
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
> > On 15 Sep 2022, at 3:41 PM, John Gilmore  wrote:
> >
> > John Curran wrote:
> >>> We strongly encourage all legacy resource holders who have not yet
> >>> signed an LRSA to cover their legacy resources to
> >
> > Randy Bush  wrote:
> 

Re: End of Cogent-Sprint peering wars?

[Rubens Kuhl]

Yes, and the new administration will force more depeering for those
that peers with Sprint but not with Cogent. So the net result will be
negative.

Rubens


On Wed, Sep 7, 2022 at 5:47 PM Sean Donelan  wrote:
>
>
> Are Sprint AS1239 and Cogent AS174 finally going to settle their peering
> disputes?
>
> T-Mobile sells legacy Sprint wireline business to Cogent for $1, expects
> hefty charge
> https://www.reuters.com/markets/deals/cogent-communications-acquire-t-mobiles-wireline-business-2022-09-07/
>
> 1,400 customers
> 1,300 employees
>
> 19,000 long-haul route miles
> 1,300 metro route miles
> 16,800 leased route miles
>
>

Re: cogent and henet not peering

[Rubens Kuhl]

OTOH, knowing that Cogent loves splitting the global Internet is one
good reason to not contract their services.
I think they sell traffic to their private Intranet. Which is huge,
but doesn't encompass the whole Internet.


Rubens

On Fri, Aug 19, 2022 at 12:04 PM VOLKAN KIRIK  wrote:
>
> lets just say cogent gives 400GE in each pop they have in common with he.net 
> for free.
>
> BUT they will rate-limit he.net links to previous month's 95th percentile 
> upload or download (which is minimum) rate (each month)
>
> to make ratio 1:1... to make downstream and upstream traffics fair...
>
> okay?
>
> fine?
>
> come on people,
>
> segmentation is bad.

Re: Allegedly Tier 1s in Wikipedia

[Rubens Kuhl]

On Mon, Aug 1, 2022 at 3:19 PM Geoff Huston  wrote:
>
>
>
> > On 1 Aug 2022, at 11:10 am, Tom Paseka via NANOG  wrote:
> >
> > Paying for "peering", doesn't stop you being a tier-1.
> >
> > Being a Tier-1 means you are "transit free" (technical term, not 
> > commercial). No one is transiting your routes to other Tier-1 providers.
> >
>
> There are a lot of potential interpretations of “Tier 1” and often folk use 
> the one that benefits their own classification (obviously!). The one I think 
> corresponds to the conventional interpretation is "I’m a Tier 1 because I 
> have a SKA peering agreement with other Tier 1 networks and I pay no other 
> network for transit or peering”, or more informally, “I’m a Tier 1 because I 
> pay nobody and everyone pays me, except for my peers.”

This conventional interpretation is the one I'm applying in this question.

> I suspect that what goes on is “I’m a Tier 1 because I say so, and noone has 
> contradicted me yet!" :-)

Which is unfortunately what some operators serving my region try
applying. And after being contradicted, they move to "regional Tier-1"
speech, which is something nobody ever defined.


Rubens

Allegedly Tier 1s in Wikipedia

[Rubens Kuhl]

Hi.

Looking at the article on Tier 1 networks, I found one that I know for a
fact that pays for some transit (12956) and some I usually don't associate
to Tier 1 status, like 6762.

Is there a list of such transit relationships by those bragging about being
Tier 1 ?


Rubens

HE.net and BGP Communities

[Rubens Kuhl]

The last mention I found on NANOG about HE.net and BGP communities for
traffic engineering is from April 2021 and said they provided none.

Is that still the case a year later ?


Rubens

Re: ICANN

[Rubens Kuhl]

If you believe in everything an email says, I have an island to sell
that you might be interested in.

That said, ICANN has a compliance department:
https://www.icann.org/compliance/complaint


Rubens

On Fri, Jul 8, 2022 at 12:22 PM Keith Medcalf  wrote:
>
>
> Does anyone have contact information (or address for service of legal
> documents) for ICANN?  There web site does not appear to contain contact
> information.
>
> ICANN apparently promulgates a policy which requires clickage on spam
> links in e-mail.  I intend to sue them for trillions of dollars for this
> policy.
>
>
> --
> (CAUTION) You are advised that if you attack my person or property, you
> will be put down in accordance with the provisions of section 34 & 35 of
> the Criminal Code respectively.  If you are brandishing (or in
> possession) of a weapon then lethal force will be applied to your person
> in accordance with the law.  This means that your misadventures may end
> in your death.  Consider yourself cautioned and govern your actions
> appropriately.
>
>
>
>

Re: Carrier Options in Bogota

[Rubens Kuhl]

Besides EdgeUno, already mentioned, Tivit bought what used to be Synapsis
and before that, Diveo. Could also be an option, either for colocation
or a VM (called "One Cloud" by Tivit).

Rubens


On Fri, Jul 1, 2022 at 10:47 AM nanoguser99 via NANOG 
wrote:

> Nanog,
>
> I need good connectivity to local eyeball networks there.  I've explored
> Cogent, Lumen, and a local clled Telxius and results are all over the map.
> Is there a provider that's 'well peered' with all the locals?  Hoping this
> formats correctly but here's the results of ping tests on various looking
> glasses to prefixes of the various locals.
>
> Local Carriers IP Prefix Telxius Lumen Cogent
> COLOMBIA TELECOMUNICACIONES S.A. ESP 152.200.0.0/14 22.025 ms 164ms 115 ms
> Telmex Colombia S.A. (Claro) 190.144.0.0/14 14.319 ms 63ms 115 ms
> Empresas Públicas de Medellín E.S.P. 201.220.30.0/23 94.264 ms 126 ms 102
> ms
> Movistar Colombia 186.116.14.0/24 38.894 ms 193ms 118 ms
> ETB - Colombia 186.154.0.0/16 5.340 ms 130ms 2.21 ms
> Columbus Networks Colombia 138.121.12.0/24 60.212 ms 99ms 89.8 ms
> Metrotel Colombia 190.1.128.0/19 20.989 ms 148ms 90.5 ms
> Any advice?
>
> -Nanoguser99
>
> Sent with Proton Mail  secure email.
>

Re: irrd or ...?

[Rubens Kuhl]

On Sun, Jun 19, 2022 at 6:07 PM Randy Bush  wrote:
>
> >> It will also take much less RAM if you turn RPKI validation off.
> >
> > oh dear ghod.  do i need to turn the dancing donkeys off too?
> >
> > "Make each program do one thing well. To do a new job, build afresh
> > rather than complicate old programs by adding new "features"."
> > -- ken thompson - unix philosophy
> >
> > a good side to a bit of economic contraction might be a side effect of
> > code bloat and featuritis contraction.
>
> to be clearer, i now run a 4GB VM with irrd2, rancid, nfsen, and a wiki.
> so i will stick with irrd2.


Yeap, we tried installing IRRd 4 in a similar VM that used to run TC
and it was a catastrophic failure. Although it was 4.0beta2 and some
changes we are made since (IRRd4 is now at 4.2.4), I don't think they
were enough to change the outcome.


Rubens

Re: irrd or ...?

[Rubens Kuhl]

On Sat, Jun 18, 2022 at 3:22 PM Randy Bush  wrote:
>
> > At least 32GB RAM

It runs fine now with 16GB RAM, after a code change.  It will also
take much less RAM if you turn RPKI validation off.

This is from TC at this moment, which mirrors 5.5 million records from
other IRRs and do RPKI validation of its own objects:

free -g
  totalusedfree  shared  buff/cache   available
Mem: 31  12   5   6  13  11
Swap: 3   0   3


> > At least 4 CPU cores

We run with 2 CPU cores, and indeed you might want to use 3 or 4:

top - 18:27:59 up  4:24,  1 user,  load average: 2.24, 2.19, 3.04

> > At least 150GB of disk space (SSD recommended)

Possibly less than that, we provisioned 100GB and it uses half of it.
The host system indeed uses SSD, but it hosts many more VMs. An iostat
of the VM as of now:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  21.590.002.970.430.00   75.01

Device tpskB_read/skB_wrtn/skB_dscd/s
kB_readkB_wrtnkB_dscd
(...)
sda 135.40  1356.78  3650.10 0.00
21898122   58912032  0


Rubens

Re: irrd or ...?

[Rubens Kuhl]

On Sat, Jun 18, 2022 at 2:37 PM Randy Bush  wrote:
>
> i have been running irrd for some years.  am about to dump that
> (virtual) server and move from freebsd to bullseye.  is there
> anything more modern, and _simpler_, than irrd at which i should
> take a look?


While IRRd4 fails the simpler criteria, it passes the more modern
criteria of your question. And since both irrd-legacy and RWS (RIPE)
seem to not be maintained, I believe it to be the only code that can
be labeled as modern.

What I can say from the experience of running TC IRR (32k objects) is
that you need lots of RAM and vCPUs, much more than IRRd 2.9/3.x.
https://github.com/irrdnet/irrd


Rubens

Re: Question re prevention of enumeration with DNSSEC (NSEC3, etc.)

[Rubens Kuhl]

> It's perfectly reasonable to claim a database right in the WHOIS data,
> but the offense is scraping WHOIS, not enumerating the DNS zone.
>
> I could enumerate the DNS zone twice a day every day and so long as I stayed
> away from WHOIS, nobody would notice or care.


The zone file could be seen as an accessory to the database rip-off.
For instance, it would be hard to see such a dependency on Alexa 1M
top domains, since they are already enumerated. But some spam actors
deliberately compared zone file editions to single out additions, and
then harass the owners of newly registered domains, both by e-mail and
phone.

A wrench can be a tool or a weapon, depending on how one uses it.


Rubens

Re: Question re prevention of enumeration with DNSSEC (NSEC3, etc.)

[Rubens Kuhl]

> Is there any case law where someone has asserted a database right for a DNS 
> zone?

German law has something to goes somewhat near it, although closer to
a mandate rather than a right:
https://www.denic.de/en/faqs/faqs-for-domain-holders/#code-154


Rubens

Re: Geolocation data management practices?

[Rubens Kuhl]

Besides geofeed, there are also geoidx records in IRRs but whether
geolocation services actually use geofeed or geoidx remains to be
seen. You can see some geoidx: at this IRR entry in TC:
https://bgp.net.br/whois/?q=-s%20TC%20-i%20mnt-by%20MAINT-AS271761

Regarding LACNIC, what LACNIC, NIC.mx and NIC.br do is to select which
RIR or NIR services requests depending on the organisation's country.


Rubens

On Thu, Apr 21, 2022 at 9:53 AM Shawn  wrote:
>
> Aloha NANOG,
>
> What is the best practice (or peoples preferred methods) to
> update/correct/maintain geolocation data?
> Do most people start with description field info in route/route6 objects?
>
>
> Also, thoughts and considerations on using IPv4 space from one RIR in
> countries belonging to another RIR?
>
> With IPv4 exhaustion and inter-RIR IPv4 transfers, and geolocation data, it
> seems less applicable than it had been (a decade ago).  The IP's will be
> used for CDN, not by end-users/subscribers.
> Context: trying to work through an administrative "challenge" with LACNIC
> regarding an IPv4 transfer, considering transferring to ARIN and then using
> in LACNIC (then once resolved, transfer from ARIN to LACNIC).  Or just using
> existing ARIN space in Brazil.
> LACNIC is making things more difficult than they need to be.  I know this is
> NANOG... but seeking advice, working on a global network, US HQ, currently
> no active "registration" in LACNIC (except Brazil), but we operate in 5
> countries in the region (data center/colo).  We would use Brazil, but very
> hesitant to use their NIC (nic.br); LACNIC is saying we cannot maintain our
> relationship with them using our Brazil organization (our only formal
> subsidiary in the region).  LACNIC does not really define the "entity"
> operating in their region well. We use our US entity with RIPE and APNIC,
> simply showing documentation (contracts) that we operate in their region.
> Maybe I am not using the magic word?
>
>

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[Rubens Kuhl]

For the inclusion of proxy objects in ALTDB for ARIN-NONAUTH, this is
the current state of objects among known IRRs:


 source  total obj rt objaut-num obj

 AFRINIC127024  99313   2116
 ALTDB   29342  21385   1481
 APNIC  879374 572495  17737
 ARIN   151087  61535   2461
 ARIN-NONAUTH34334  29291932(* Final
mirror obtained April 4 *)
 BBOI 1200869 57
 BELL29827  29613105
 CANARIE  1832   1425177
 HOST2  0  1
 IDNIC9301   4886   1845
 JPIRR   13404  11398425
 LACNIC   8008   4742   1039
 LEVEL3 111542  90593300
 NESTEGG 8  4  2
 NTTCOM 453257 444518548
 OPENFACE   25 17  1
 PANIX  42 40  1
 RADB  15943761397813   9077
 REACH   20280  18177  2
 RGNET  80 43  6
 RIPE  1394165 379711  37475
 RIPE-NONAUTH57851  54281   2140
 TC  29936  12207   3703
 WCGDB   65135  62849773None


Rubens

On Mon, Apr 4, 2022 at 12:57 PM Job Snijders via NANOG  wrote:
>
> Dear all,
>
> On Sat, Apr 02, 2022 at 09:09:58PM +, John Curran wrote:
> > As previously reported here, ARIN will be shutting down the
> > ARIN-NONAUTH IRR database on Monday, 4 April 2022 at 12:00 PM ET.
> >
> > It is quite likely that some network operators will see different
> > route processing as a result of this change, as validation against the
> > ARIN-NONAUTH IRR database will not longer be possible.
> >
> > Please be aware of this upcoming event and make alternative
> > arrangements if you are presently relying on upon routing objects in
> > the ARIN-NONAUTH IRR database.
>
> I ran an analysis just now in which I created an intersection between
> prefixes observed in the BGP default-free zone and exactly matching
> route:/route6: objects in ARIN-NONAUTH. I then substracted exact
> matching objects found in the RADB, ALTDB, TC, NTTCOM, LEVEL3, RIPE, and
> APNIC IRR sources. The result is a list of routes which might
> experience service disruptions due to missing IRR objects.
>
> The below 2,749 Prefix + Origin AS pairings are at risk as a result of
> ARIN shutting down the ARIN-NONAUTH IRR database. Any potential effects
> are likely to manifest themselves in the coming 24 - 32 hours. Prior to
> this announcement, ARIN consulted with its community on the future of
> its IRR service.
>
> I voiced objection and raised concerns about (what appeared to be)
> limited visibility into what exactly the effects of such a database
> shutdown would mean for the Internet: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001237.html
> Other community members also shared concerns: 
> https://lists.arin.net/pipermail/arin-consult/2021-February/001195.html
> A number of graceful alternative mechanisms were proposed, but not
> acted upon: 
> https://lists.arin.net/pipermail/arin-consult/2021-March/001240.html
>
> One might argue "well, folks had more than a year to move their
> objects!", but on the other hand, it is entirely possible not all the
> right people were reached, or in cases where affected parties did
> receive a communication from ARIN, they perhaps were unable to
> understand the message.
>
> Please check if any of your prefixes are on the below list, and if so,
> double check whether your IRR administration is able to overcome the
> disappearance of ARIN-NONAUTH. Godspeed!
>
> This tool might be useful: https://irrexplorer.nlnog.net/
>
> Kind regards,
>
> Job
>
> Prefix OriginAS
> 100.42.100.0/24 33353
> 100.42.101.0/24 33353
> 100.42.102.0/24 33353
> 100.42.104.0/24 33353
> 100.42.105.0/24 33353
> 100.42.106.0/23 33353
> 100.42.108.0/24 33353
> 100.42.109.0/24 33353
> 100.42.96.0/23 33353
> 100.42.98.0/24 33353
> 103.11.202.0/24 33517
> 103.13.12.0/24 38057
> 103.13.135.0/24 51830
> 103.15.168.0/23 55532
> 103.196.22.0/23 7489
> 103.219.78.0/24 55256
> 103.219.79.0/24 55256
> 103.232.224.0/24 125
> 103.250.176.0/24 134795
> 103.250.177.0/24 134795
> 103.250.178.0/24 134795
> 103.250.179.0/24 134795
> 103.35.217.0/24 125
> 103.47.244.0/24 55256
> 103.88.172.0/24 136271
> 103.88.173.0/24 136271
> 103.88.174.0/24 136271
> 104.128.96.0/20 19233
> 104.142.128.0/23 33353
> 104.142.130.0/23 33353
> 104.142.136.0/22 33353
> 104.142.140.0/23 33353
> 104.142.144.0/24 33353
> 

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[Rubens Kuhl]

On Mon, Apr 4, 2022 at 5:06 PM Kenneth Finnegan
 wrote:
>
> Howdy All,
>
> While I agree that it might be politically entertaining to let this
> one blow up as a demonstration of how ARIN conducts business, this
> list of networks includes too many small networks who likely don't
> have a savy networking engineering team.
>
> In my opinion, they are not acceptable collateral damage to
> demonstrate ARIN's lack of regard for the community in shutting this
> down without a transition plan for the RPSL objects, so as one of the
> admins for the ALTDB IRR database, I've taken it upon myself to create
> proxy registrations for all of these prefixes in ALTDB.

While I won't discuss the issue of proxy registrations, the key here
is the responsiveness in removing such proxy registrations if/when
asked to do so.

> Like any proxy registration, asset owners are welcome to contact the
> maint POC, and if no response from them, db-ad...@altdb.net,
> requesting that stale records be deleted, but please also note that

If you as the maint POC is willing to commit to responsiveness in
doing that, great.

> ALTDB automatically deletes any route objects which conflict with a
> publishes RPKI ROA, so the most effective way to clean up stale IRR
> records is to publish RPKI ROAs for your address space.

Which only would clear up proxy regs with wrong origin AS, not with
right origin AS but wrong maintainer.

Rubens

Re: V6 still not supported

[Rubens Kuhl]

> Are you ready for that, or should we wait another 80 years with dual stack 
> and gigantic stateful NATs?

That's what this network is going to do:
https://www.aa.net.uk/etc/news/ipv6-end-of-trial/

There is something odd about the day this was published, though.


Rubens

Re: Cogent pulled out of Russia based on risk analysis

[Rubens Kuhl]

https://www.youtube.com/watch?v=l_x2LQZOzF8=500s

Rubens

On Fri, Mar 25, 2022 at 9:51 AM Mike Hammett  wrote:
>
> Timestamp?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> 
> From: "Lady Benjamin Cannon of Glencoe, ASCE" 
> To: "NANOG Group" 
> Sent: Friday, March 25, 2022 7:37:22 AM
> Subject: Cogent pulled out of Russia based on risk analysis
>
> Confirmation from their CEO that Cogent shut down service in Russia due to 
> increased use of the connections for cyberattacks, and because only $10m in 
> rev came from Russia.
>
> Cogent had no equipment in Russia.
>
> Details: https://youtu.be/l_x2LQZOzF8
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>

Re: Cogent cutting links to Russia?

[Rubens Kuhl]

> With the sanctions in place, how would Cogent get paid for providing service?

Even considering that payments are still flowing, there is still a
risk of running afoul of sanctions. This supply chain is formally
excluded from the sanctions, but the uncertainty around them made it
stop doing business with Russia anyways:
https://edition.cnn.com/2022/03/03/investing/russia-oil-sanctions-ukraine/index.html


Rubens

Re: Cogent cutting links to Russia?

[Rubens Kuhl]

Cogent already does not provide access to the Internet, only to parts
of the Internet, so this just changes the perimeter of their Intranet.

That said, it's more likely they are afraid of sanctions and/or not
getting paid for services than ideologically motivated.


Rubens

On Fri, Mar 4, 2022 at 3:52 PM Michael Thomas  wrote:
>
>
> I know the link is paywalled, but it's super high level so not much is
> lost. But what does everybody think of this? I imagine that just Cogent
> cutting them off isn't going to make much difference.
>
> https://www.washingtonpost.com/technology/2022/03/04/russia-ukraine-internet-cogent-cutoff/
>
> Mike
>

Re: RIR IRR interfaces

[Rubens Kuhl]

I hope more IRRs deploying IRRd 4.2 or later will increase API support
and API similarity among IRRs.
TC is one IRR actively supporting those APIs, which have both RPSL
format and JSON format options (although the request itself is a JSON
object regardless of format).


Rubens

On Wed, Mar 2, 2022 at 6:37 PM Jon Lewis  wrote:
>
> I wonder, do the RIR's "talk" to each other about UI?
> I'm in the middle of duplicating (moving) a bunch of route objects from
> 3rd party IRRdbs to the appropriate RIR ones, which, so far, has meant
> creating route objects in the RIRs run by APNIC, ARIN, and RIPE.
>
> User experience-wise, I'm sad to say RIPE rates last so far.
>
> I figured out how to talk to ARIN's API first so creating objects wouldn't
> have to be a whole bunch of point  It "works" and accepts
> rpsl format text for objects.
>
> Next I did some APNIC route objects, and was amazed by their route object
> import tool.  It looks at presumably a full view of the Internet and
> offers to auto-create route objects for your prefixes found in the
> table...including a checkbox for "would you like RPKI ROAs with that?"
>
> Finally I got to RIPE.  No auto-import tool.  There is an API, but it
> doesn't accept data in rpsl format, so if I want to explore it farther,
> I'll have to write something to convert rpsl route objects to either xml
> or json.
>
> --
>   Jon Lewis, MCP :)   |  I route
>   StackPath, Sr. Neteng   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Ukraine request yikes

[Rubens Kuhl]

On Tue, Mar 1, 2022 at 5:17 AM George Herbert  wrote:
>
> Posted by Bill Woodcock on Twitter… 
> https://twitter.com/woodyatpch/status/1498472865301098500?s=21
>
> https://pastebin.com/DLbmYahS
>
> Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
> address delegations, and turn off TLDs for Russia.
>
> Seems… instability creating…


While not happening at scale at this time, we might have to consider
some measures to deter cyberwarfare if it escalates to that. And this
is not done by revoking IP addresses or TLDs, but by shutting down
actual network ports.

As long as the war keeps being kinetic and information/propaganda, the
network is probably a better part of the solution.


Rubens

Re: Ukraine request yikes

[Rubens Kuhl]

> More or less.  The Government Advisory Committee member from Ukraine has 
> asked ICANN to:
> - Revoke .RU, .рф, and .SU (all Russian-managed ccTLDs)
>
> As the GAC member undoubtedly knows, that’s not how ICANN works. Barring a 
> court/executive order in ICANN’s jurisdiction (and even then, it gets a bit 
> sticky see 
> https://www.washingtonpost.com/news/volokh-conspiracy/wp/2014/11/13/dc-court-rules-that-top-level-domain-not-subject-to-seizure/),
>  ICANN essentially treats ccTLDs as national sovereign resources. A third 
> party, no matter how justified, requesting a change of this nature will not 
> go anywhere. Simply put, ICANN is NOT a regulator in the forma sense, it is a 
> private entity incorporated in California. The powers that it has are the 
> result of mutual contractual obligations and it’s a bit unlikely the Russian 
> government has entered into any contracts with ICANN, particularly those that 
> would allow ICANN to unilaterally revoke any of the Russian ccTLDs.

I wonder how ICANN would react to ISO removing RU/RUS from ISO 3166-2/3.


Rubens

Re: enom giving Google a bad name

[Rubens Kuhl]

> > Because they used URL redirection services, right ? Domains under
> > management are unlikely to be affected unless the registrant needs a
> > domain update.
>
>  From what I see enom's nameservers are down.

"We also discovered resolution problems that impact a few hundred domains"

Tucows group, which includes a few registrars including eNom, had more
than 12 million domains under management by September 2021 (last set
of statistics published by ICANN). So we are talking 0,01% of
customers affected, tops.


Rubens

Re: enom giving Google a bad name

[Rubens Kuhl]

On Sun, Jan 16, 2022 at 2:38 PM Hank Nussbacher  wrote:
>
> Many of you might be following the enom weekend fiasco:
>
> https://twitter.com/enomsupport/status/1482621466151571456
>
> https://twitter.com/enomsupport/status/1482707275529678849
>
> https://enomstatus.com/
>
> Thousands of domains have been knocked out.

Because they used URL redirection services, right ? Domains under
management are unlikely to be affected unless the registrant needs a
domain update.

> But I just found out that Google is an enom reseller:
>
> https://help.enom.com/hc/en-us/articles/115005222367-My-Domain-was-registered-through-G-Suite-Google-Apps
>
> "Google handles all of the billing and renewals of your domain name,
> while Enom offers technical support to manage your domain."
>
>
> So who takes responsibility when a fiasco happens like this: Google or Enom?

I would imagine Google only uses Enom for TLDs that they don't carry
thru Google Domains, their own registrar.
And Google would also use its own URL redirection services, not Enom's.

Rubens

Re: questions about ARIN ipv6 allocation

[Rubens Kuhl]

I strongly encourage my competitors to turn off IPv6, so I hope you
convince one of them to do so. ;-)


Rubens

On Mon, Dec 6, 2021 at 2:59 PM Owen DeLong  wrote:
>
>
>
> > On Dec 5, 2021, at 7:41 AM, Gary Buhrmaster  
> > wrote:
> >
> > On Sun, Dec 5, 2021 at 2:23 PM Owen DeLong via NANOG  
> > wrote:
> >
> >> The double billing (had it been present at the time) would have prevented 
> >> me from signing the LRSA for my IPv4 resources.
> >
> > There were some community participants that suggested
> > that having a formal relationship with the ARIN organization
> > by signing the LRSA was good for the resource holders,
> > and good for the overall commons.   There were other
> > members that suggested that signing the LRSA would be
> > potentially disadvantageous at some future time.
> >
> > While I still believe that having a formal relationship is the
> > better approach, even if it costs a bit more(*), I do
> > understand that some people may feel vindicated about
> > not signing a LRSA, or have changed their opinion about
> > whether they should have signed, or suggested others do
> > so.  Perhaps there are lessons to be learned here.
> >
> >
> >
> > (*) If the number resources no longer have value
> > exceeding their fees for an organization, I understand
> > there is a robust transfer market available :-)
>
> The situation is such that the current economic incentives would be most 
> advantageous to me to preserve my LRSA and abandon my RSA, which would 
> involve simply turning off IPv6.
>
> Obviously, I would rather not have to do that, but more importantly, I really 
> dislike the idea that ARIN is once again creating financial disincentives for 
> the adoption or continued use of IPv6.
>
> Owen
>

Re: questions about ARIN ipv6 allocation

[Rubens Kuhl]

On Sun, Dec 5, 2021 at 12:00 AM Owen DeLong via NANOG  wrote:
>
> I would be more than happy to consilolidate my ipv6 addresses under my lrsa, 
> but ARIN will not allow it.


And they are right in doing so. You can't have your cake and eat it too.

Rubens

Re: Questions about IRR best practices

[Rubens Kuhl]

On Fri, Nov 12, 2021 at 9:56 PM George Michaelson  wrote:

> Wouldn't it be cool if we had a cryptographic mechanism to sign an
> authority to the IRR publisher to eject old data.
>
> Some way you could prove you have control of the asset, and the  let the
> RADB people know you repudiated some old data, made under somebody else's
> authority which you can't remove directly, even though it's probably stale.
>
> Something like a PKI tagged with your addresses and/or ASN.
>
>>
>>
That only helps with wrong origin IRR records. While this is the case at
hand, a lot of proxy objects have correct origin attributes,  and are just
managed by the wrong person.

That said, TC IRR is currently using RPKI validation and the curious result
is that most RPKI-triggered removals are objects sent by the own AS, but
with a more specific prefix that what's published in RPKI.

Rubens

Re: DNS hijack?

[Rubens Kuhl]

>
>
>
>
> DNSSEC would help here.   NetSol's rogue nameserver wouldn't be able to
> produce
> the signed zone if validation were required.
>
>
Nope, they could just remove the DS since they are the registrar for that
domain. DNSSEC only protects against a DNS provider going rogue, not your
own hired registrar.


Rubens

Re: ROA mirror to IRR?

[Rubens Kuhl]

TC(bgp.net.br) is using IRRd 4.2, which has an RPKI pseudo-source with
exactly that. ROAs are downloaded from NTT. You can see how they look
like at:
https://bgp.net.br/whois/?q=-s%20RPKI%20200.160.0.0/20

But this is not used to create route(6) objects in the TC source, only
to invalidate route(6) objects that users create at TC. Mirrored IRRs
like RADB are not subject to RPKI validation, only to scope filter
(private IP addresses, private ASNs).


Rubens

On Tue, Oct 26, 2021 at 5:29 PM Shawn  wrote:
>
> Curious if any IRR databases are mirroring/importing ROA data - creating
> route|6 objects from ROA?
>
> LACNIC requires a route object to be created when creating a ROA.
> APNIC you create a route object, then may generate a ROA during that
> process.
> Other RIR's, curious if anything tries to bring the two together?
>
> Applicable for networks that only use IRR data (do not yet validate RPKI),
> they could benefit.
>
> IRR questions:
> How do most large networks maintain (automate) their IRR records?
> Is it standard practice to accept more specifics (append IPv4 "le /24" and
> IPv6 "le /48")?
>  Or is it expected to have one IRR route per BGP announcement?
>
>

Re: [routing-wg] Relative size of IRR registries

[Rubens Kuhl]

You are right on all counts but (3). IRRd 4.2 has a feature called
scope filter, and the results below had the following in effect:

scopefilter:

prefixes:

- 10.0.0.0/8

- 172.16.0.0/12

- 192.168.0.0/16

asns:

- 23456

- 64496-64511

So they already excluded those easy to detect unassigned blocks. It
doesn't exclude blocks that are assigned by IANA but not yet by a
RIR/NIR (like Team Cymru bogon feeds), but is good enough.


Rubens

On Sat, Oct 23, 2021 at 2:43 PM Aliaksei Sheshka  wrote:
>
> To understand the impact of the non-auth registries one need to
> eliminate from their obj count 1) route/AS-SET objects which are also
> present in the authoritative registries 2) prefixes which can be
> derived from the RPKI ROA data 3) outright wrong data like private and
> invalid ranges.
> Additionally to eliminate 4) stale data, which is more challenging yet
> possible to estimate. Remove 5) non-cooperative registries.
>
> After all that I found that for my cases non-authoritative registries
> are more burden than help.
>
> Your mileage may vary.
>
>
>
>
>
>
> On Sat, 23 Oct 2021 09:48:40 -0300
> Rubens Kuhl  wrote:
>
> > Recent discussions about ARIN-NONAUTH made me wonder what would be the
> > impact of discontinuing *-NONAUTH IRR registries. These are the
> > current size of all IRR registries I was able to mirror, ordered by
> > the number of aut-num objects.
> >
> >
> > source | total obj | rt obj | aut-num obj
> > RIPE 948401 368596 37284
> > APNIC 879374 572495 17737
> > RADB 1533619 1344618 8787
> > TC 21423 8531 3412
> > ARIN 134512 50543 2211
> > RIPE-NONAUTH 58436 54807 2163
> > AFRINIC 121639 94734 2057
> > IDNIC 8541 4574 1713
> > ALTDB 25598 18319 1395
> > LACNIC 8008 4742 1039
> > ARIN-NONAUTH 67715 62471 939
> > WCGDB 65135 62849 773
> > NTTCOM 453257 444518 548
> > JPIRR 13404 11398 425
> > LEVEL3 111770 91524 299
> > CANARIE 1869 1455 177
> > BELL 29827 29613 105
> > BBOI 1291 924 56
> > RGNET 74 40 6
> > NESTEGG 8 4 2
> > REACH 20310 18207 2
> > HOST 2 0 1
> > OPENFACE 25 17 1
> > PANIX 42 40 1
> >
>

Relative size of IRR registries

[Rubens Kuhl]

Recent discussions about ARIN-NONAUTH made me wonder what would be the
impact of discontinuing *-NONAUTH IRR registries. These are the
current size of all IRR registries I was able to mirror, ordered by
the number of aut-num objects.


source | total obj | rt obj | aut-num obj
RIPE 948401 368596 37284
APNIC 879374 572495 17737
RADB 1533619 1344618 8787
TC 21423 8531 3412
ARIN 134512 50543 2211
RIPE-NONAUTH 58436 54807 2163
AFRINIC 121639 94734 2057
IDNIC 8541 4574 1713
ALTDB 25598 18319 1395
LACNIC 8008 4742 1039
ARIN-NONAUTH 67715 62471 939
WCGDB 65135 62849 773
NTTCOM 453257 444518 548
JPIRR 13404 11398 425
LEVEL3 111770 91524 299
CANARIE 1869 1455 177
BELL 29827 29613 105
BBOI 1291 924 56
RGNET 74 40 6
NESTEGG 8 4 2
REACH 20310 18207 2
HOST 2 0 1
OPENFACE 25 17 1
PANIX 42 40 1

Re: Questions about IRR best practices

[Rubens Kuhl]

> 2. On the ARIN side, when ARIN-NONAUTH goes away next year, does that do away 
> with our ability to do proxy route objects? Do we need to require all of our 
> BGP customers to set up their own IRRs?

Not only ARIN. LACNIC and TC (the two IRRs covering the LAC region, TC
for Brazil, LACNIC for Mexico and other Latin American countries) have
strict non-proxy policies, and there is no -NONAUTH scape route.

> 3. On the RADb side, if we're turning up a new customer that doesn't have an 
> IRR, and another ISP already has a proxy registration for that customer, is 
> it sufficient for us to add that customer's AS to our customer AS-SET?

The problem with that is all of sudden the covering object could disappear.


Rubens

Re: Facebook post-mortems...

[Rubens Kuhl]

The FB one seems to be from a previous event. Downtime doesn't match,
visible flaw effects don't either.


Rubens


On Mon, Oct 4, 2021 at 9:59 PM  wrote:
>
> Fairly abstract - Facebook Engineering - 
> https://m.facebook.com/nt/screen/?params=%7B%22note_id%22%3A10158791436142200%7D=%2Fnotes%2Fnote%2F&_rdr
>
> Also, Cloudflare’s take on the outage - 
> https://blog.cloudflare.com/october-2021-facebook-outage/
>
> FYI,
> /John
>

Re: IRR for IX peers

[Rubens Kuhl]

Some IX'es set communities telling which member announced that prefix;
if SIX is one of those, that can be used to automate origin
verification.


Rubens

On Mon, Oct 4, 2021 at 2:08 PM Randy Bush  wrote:
>
> so i have an AS (3130) which peers at the SIX (RSs and some direct).
>
> in the hope that leak detectors such as artemis would stop false
> positives when they see my prefixes announced customer cones of SIX
> peers, i want to add the SIX peers to my aut-num: policy.
>
> export:  toAS-SEATTLEIX-RS-CLIENTS  announce AS-RG-SEA
>
> seems clear and obvious.  but
>
> import:  from  AS-SEATTLEIX-RS-CLIENTS  accept AS-SEATTLEIX-RS-CLIENTS
>
> would seem to allow bill's bait and sushi to announce microsoft to me.
> and i am not sure that expansive `from` clause is actually allowed.
>
> what are others in this space doing?
>
> [ and let's not descend into the rat-hole of dissing the IRR.  i have
>   heard of this RPKI thing and might try it some day. ]
>
> randy
>
> ---
> ra...@psg.com
> `gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
> signatures are back, thanks to dmarc header butchery

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> > But you would need to be upfront with that, including mentioning that
> > your upstreams are not from Africa and your installations won't be in
> > Africa.
> > Otherwise you applied for number resources under false pretenses, and
> > will bear the risk of such.
>
> Again, fair enough. And what happens if the same hosting company is
> struggling and now decides to offer its services to other regions
> as well? Are they now out of compliance and at risk to have their
> precious number resources revoked?

If they will provide services to both the original region and
different regions, they should apply to number resources from a region
that does not have such restrictions, like the region where they
physically host servers, and divide their provisioning between
original regions and alternate regions.

> My point is not that you are wrong (your interpretation of the clause
> is very reasonable). My point is that different people have a different
> understanding of the plain language of that clause. And that is assuming
> that it applies, as I believe that CI is arguing that it does not.

And they might have a point there, but I don't see them living up to
whatever they wrote in their application for number resources.


> I regret the true human cost that Mark pointed out, yet I am fascinated
> by the case and the arguments on both sides. The court will have their
> work cut out for them.

That human cost came not from disagreement on the policies and
contract provisions, but from a vengeful action of financial bullying.

I saw my quota of questionable court decisions to automatically agree
with whatever is decided in this case, even if CI loses, but the
arguments from both sides will indeed be very interesting and useful
to close out loopholes in the system.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

On Tue, Aug 31, 2021 at 5:28 PM Sabri Berisha  wrote:
>
> - On Aug 31, 2021, at 8:40 AM, Jon Lewis jle...@lewis.org wrote:
>
> Hi,
>
> [ I'm not affiliated with CI in any way, just playing the Devil's Advocate ]
>
> > "5.4.6.2 AFRINIC resources are for AFRINIC service region and any use
> > outside the region should be solely in support of connectivity back to the
> > AFRINIC region."
>
> > AfriNIC's policy is not at all vague on the matter that their resources
> > are to be used in or to support connectivity in the AFRINIC region.
>
> In all fairness, that is as ambiguous as it can be. What constitutes "support
> of connectivity back to the AfriNIC region"?


I can try helping with that: in underserved regions it's not unusual
for network services for that population to be physically hosted out
of the region. For instance, if you have a hosting service that only
accepts South African rands and your language options are Afrikaans
and Zulu, you can credibly argue to AfriNIC that you are targeting its
service region and are eligible for AfriNIC number resources.

But you would need to be upfront with that, including mentioning that
your upstreams are not from Africa and your installations won't be in
Africa.
Otherwise you applied for number resources under false pretenses, and
will bear the risk of such.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

]
> AFRINIC has never approved IPv4 for purposes of leasing. There is a public 
> statement to this effect.
>
>
> Yes. Nonetheless, it does not change the fact that every LIR that is a 
> resource member of AFRINIC leases IPV4 addresses every day, nor does
> it change the fact that every allocation AFRINIC has ever issued to any LIR 
> has been for the purpose of leasing them to customers. It’s just one
> of many false public statements made by AFRINIC staff in the past several 
> years.


And yet, you still haven't answered whether the IPv4 application was
made informing AfriNIC that no connectivity services would be
provided.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> AFRINIC approves IPv4 for the purpose of leasing every day. It’s what ISPs 
> do. It’s the definition of an LIR.
>
> Yes, most LIRs are also in the connectivity business and provide addresses 
> (mostly/exclusively) to customers of their connectivity services.

Which is why CI informed AfriNIC in their request that they were going
to have no network and provide connectivity-less services to CI
customers, right ?

> However, there’s no such policy requirement in the AFRINIC governing 
> documents.

All RIRs were subject to RFC 2050, now RFC 7020, which states:
"1)  Allocation Pool Management: Due to the fixed lengths of IP
   addresses and AS numbers, the pools from which these resources
   are allocated are finite.  As such, allocations must be made in
   accordance with the operational needs of those running the
   networks that make use of these number resources and by taking
   into consideration pool limitations at the time of allocation."

If there is no network, there is no use of such number resources.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> I really, really don't want to upset Mel more than he already is, but Owen
> shared a link with an actual order of the court. After "consideration of the
> affidavit" the court allowed "up to" $50 million to be frozen. Whatever the
> merits of the affidavit are, it indicates that the court looked at the facts,
> made a determination and based on that ordered the asset freeze. That sounds
> like a (preliminary) ruling to me.

It has not. It's just an assessment that the assets involved can be
valued at that amount.

> I don't necessarily agree with it due to
> the implications it has on African internet operations, and, as Mark 
> rightfully
> brought up, all the employment that depends on it, but I have to respect it.

No need to agree or disagree with a court that hasn't made a decision
on this yet. And when a decision comes out some will agree, others
will disagree, and that will also be sorted out.


> And don't get me wrong: I am not informed enough as to the dispute itself so
> I'm unable to form an opinion on who is right and who is wrong here. People
> whom I deeply respect on this list are on opposite sides so that adds to the
> confusion. I am, however, concerned with the operational implications. That's
> why I donated to the keep-Afrinic-alive-fund.

There is another operational implication if RIRs are unable to enforce
deviations from the information provided when a resource holder
applied for them. Regardless of whether the business model is good or
bad, I don't see that party proving that they told AfriNIC at
application time of the usage they really did of the resources. But if
RIRs are unable to enforce those, they become book-keepers instead of
RIRs. All IPv4 allocation could be done with a single shared
spreadsheet for the whole world.


> I've ran an RBL for years, which many people used. It closed down more than
> a decade ago. Out of 100 DNS queries I logged just now with a quick tcpdump
> on one of my three DNS servers, I counted 51 for rbl.cluecentral.net. That's
> why I'm advocating to reconsider your carpet-bombing (filter into oblivion)
> recommendation. People don't remove them.

I understand the risk, but when choosing between that risk and the
systemic risk for the RIR system, the choice for me is very clear.
Kinda like removing a malignant tumor.

Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

On Mon, Aug 30, 2021 at 2:35 PM Sabri Berisha  wrote:
>
> - On Aug 30, 2021, at 6:29 AM, Rubens Kuhl rube...@gmail.com wrote:
>
> > And that's why carpet bombing those IP blocks might be needed so the next
>
> entity that ends up with those IP addresses long after CI has gone into
> oblivion will have its engineers debug odd routing issues for years. We all
> know that people regularly fail to update their manually entered filters on
> at least a few of their routers.

We already have IP blocks with so much "background radiation" that
RIRs prefer not allocating them, or only allocating them to people
with distributed traffic handling capacity, like 1.1.1.x. But the less
of those there are, the better.

> The learned people on this list do not strike me as the kind of person to
> go out and engage in vigilante justice if a court decides against them. The
> very fabric of our civilized society depends on us resolving our conflicts
> in court, not out on the (virtual) streets. You may disagree with a ruling
> but I implore you to respect it.

As previously mentioned, this is about something that doesn't involve
a court ruling, at least not yet, but a seizure request made by the
party to attack the sustainability of the RIR. Rulings that people
disagree have their own way inside the court system to be dealt with.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> You may not like Lu and/or his business model. I’m not a fan of his business 
> model myself, but it is technically permitted under existing policy. If the 
> community doesn’t like that fact, there is a process to change the policies. 
> Terminating a member based on rules which don’t actually exist, on the other 
> hand sets a very dangerous and corrupt precedent and is a threat to the trust 
> we all want to have in the RIR system.

I have no problem with business models I don't like, I just don't do
business with companies that use those. But this particular scumbag
went far beyond that. The net is a living organism, with an immune
system as well; if T-cells and lymphocytes are unable to deal with a
threat, natural killers come along.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

On Mon, Aug 30, 2021 at 3:39 AM Owen DeLong via NANOG  wrote:
>
>
>
> > On Aug 29, 2021, at 12:48 , Jay Hennigan  wrote:
> >
> > On 8/29/21 11:42, Constantine A. Murenin wrote:
> >
> >> It would seem reasonable to leave the whole issue up to the courts,
> >> instead of engaging in contempt of foreign courts, and to stop the
> >> vigilante justice against any of the parties, especially the end users
> >> who are not even a party to this whole dispute.
> >
> > The end users are an indirect party.
> >
> > Assume someone were in the business of stealing cars, forging their titles, 
> > and selling them to innocent third parties. A police officer pulling 
> > someone over for speeding might compare the VIN on the title to that on the 
> > car and discover that it was stolen. The stolen property would be returned 
> > to its owner and the end user purchaser would be out of luck other than 
> > having recourse against the thief.
> >
> > The same principle applies to someone who innocently accepts counterfeit 
> > money.
>
> Sure, but that’s not exactly what happened here. There’s a limit to what I 
> can say, but the already public facts show
> that:
>
> AFRINIC started this fight by threatening to revoke Cloud Innovations address 
> space.
>
> Cloud Innovation is disputing this revocation on the basis that it has not 
> violated the RSA, CPM, or Bylaws as they are written.
>
> AFRINIC has a history of making up process as they go along and violating 
> their own rules whenever it suits them.

Are you saying that there was no AFRINIC policy at allocation time
that prevented usage outside Africa ?


> AFRINIC has violated court orders and acted in bad faith at virtually every 
> opportunity in this process.

Nope, see Tom's message right before this one.

> As such, I think vigilante action and/or trying this case here on NANOG is 
> probably not the best idea. I realize it’s easy to sympathize with John and 
> he puts forth a good story, but there is more to the story than what John has 
> represented here.

It's not just John as you have seen by now. And besides the case
merits, the main issue is CI trying to win by suffocation. And that's
why carpet bombing those IP blocks might be needed so the next scumbag
doesn't try the same trick with someone else.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> %s/isolate/move/g functions. That equates to a leadership change. It may be 
> too soon to suggest that ICANN has any role other than risk analysis and 
> coordination of mitigation. I'm not even certain if that's their role seeing 
> how complicated the relationships between the RIR's and ICANN is.  I've seen 
> good summaries including John Currans and Milton Muellers. I've been leaning 
> towards Milton's view. He didn't pardon Afrinic, but he also didn't suggest 
> it's time to fold up shop there.
>
> A fight over crumbs: The Afrinic Crisis
>
> https://www.internetgovernance.org/2021/08/19/a-fight-over-crumbs-the-afrinic-crisis/

The problem with Milton's POV is that he is willing to pick and choose
which AfriNIC policies he likes and which he doesn't; this is not how
it works.
That community decided the policies, and it's our job in the other
regions to make sure that scum bags like the one currently trying to
suffocate AfriNIC fail miserably.


Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

On Fri, Aug 27, 2021 at 9:15 PM Baldur Norddahl
 wrote:
>
>
>
> On Sat, Aug 28, 2021 at 1:07 AM Bill Woodcock  wrote:
>>
>> > On Aug 28, 2021, at 12:48 AM, Baldur Norddahl  
>> > wrote:
>> > just to point out it is not just one guy but a whole region doing business 
>> > like that.
>>
>> You’re saying a whole region consists of parties who don’t route IP traffic?
>>
>
> None of the regions require that the IP allocations are used for routing IP 
> traffic. Aside from that, I am saying that RIPE no longer has a "need" policy 
> which means you can have as much IP space as you want without providing any 
> need to own this space. In addition we have IP brokers that expressly buys IP 
> blocks for the purpose of selling - not routing - the space.

I believe you were trying to say routing IP traffic on the Internet
DFZ. Because IP addresses are only needed for IP networks; and if the
allocation request specified Internet usage, then every RIR will hold
the requester to that promise.



Rubens

Re: An update on the AfriNIC situation

[Rubens Kuhl]

> I wish ARIN would stay out of this, it's not something that affects the ARIN
> region, and nothing said in this statement seems to refute any of the
> allegations against AFRINIC.  What it does seem to do is state Lu Heng/Cloud
> Innovation is a shady guy.  While this may be true, I'd expect a RIR to treat
> everyone the same, and that's the core of the legal complaint here.  I'd
> expect that for a court to freeze assets of AFRINIC there must be a very
> strong argument.


That's not the case in the Mauritius jurisdiction. Its law allows the
complainant to bear the burden of executing the freeze without the
court analysis.
So, it's not like an injunction like in some other jurisdictions.


Rubens

Re: [EXTERNAL] Re: An update on the AfriNIC situation

[Rubens Kuhl]

But that doesn't prevent the other RIRs issuing those since all TAs sign
0/0.


Rubens

Em sex, 27 de ago de 2021 13:56, Jay Hennigan  escreveu:

> On 8/27/21 09:45, Compton, Rich A wrote:
> > Can't AfriNIC just create ROAs for the prefixes and point them to AS0?
> That would pretty much make the prefixes unusable since most tier 1's are
> doing ROV now.
>
> Technically they can, but the whole situation is tied up in litigation
> so legally they may not be able to do so.
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

[Rubens Kuhl]

Currently RPKI can only validate origin, not paths. If/when a path
validation solution is available, then one easy way to know that
network A really means to peer with network B is to publish a path
validation that B can use and/or forward A's announcements.

Rubens

On Wed, Aug 18, 2021 at 7:53 PM Sabri Berisha  wrote:
>
> - On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patr...@ianai.net wrote:
>
> Hi,
>
> > Those networks would be ones that do not peer. Which seems pretty obvious 
> > to me
> > - it is literally in the name.
>
> I have an AS, I advertise IP space to the world. I want to be a Good Netizen 
> and
> register my BGP peers. Your definition of BGP peering is different from mine, 
> at
> least in this context.
>
> > I guess you are right, the _Peering_DB does not register “certain” networks.
>
> Which was my point. I'm glad you agree. My little AS is not allowed to play 
> with
> the big kids.
>
> If you only want to register settlement-free peering, that's totally fine 
> with me.
> Your database, your rules.
>
> But, the fact stays that you can have an AS, advertise your prefixes to the 
> world,
> and not be permitted to register with peeringdb. Which means it can't be used 
> as
> a single source of truth. Which would have been a shame because with a little 
> bit
> of automation it would be feasible to "score" advertisements. That would help
> determine the likelihood of an advertisement to be erroneous (whether by 
> accident
> or malice).
>
> For example, if I were to register my peers (53356 and 136620) and AS5524 
> would
> all of a sudden start to advertise my AS as behind it, you'd be able to flag 
> that.
>
> But again, your database, your rules.
>
> Thanks,
>
> Sabri

Re: Cogent x RPKI

[Rubens Kuhl]

> >> Someone that poses as a Tier-1 and doesn't even plan to sign their
> >> announcements ? How much more depeering will make them reconsider ?
>
> Please keep in mind that sound technical, administrative, or financial
> reasons can exist that hamper one's ability to create RPKI ROAs.
>
> For example, if the IP space is LEGACY, and not covered by a 'LRSA'
> (ARIN) or 'Legacy Agreement' (RIPE), then RPKI certificate issuance
> services simply are not available for that IP space. Without an
> agreement with a RIR to arrange RPKI services, logically, one cannot
> create ROAs.

In the case at hand, the IP block is not legacy, it was an ARIN
allocation from the start. Cogent does have a number of legacy blocks
but AFAIK they wouldn't need to bring them to an LRSA in order to
issue ROAs for the non-legacy blocks.

>
> Perhaps in your case, if RPKI is a requirement, you are better off
> bringing your own (RPKI capable) IP space?

With IPv4 depleted at most RIRs, getting someone's own IPv4 space is
not happening anytime soon.


Rubens

Cogent x RPKI

[Rubens Kuhl]

>From a Cogent support ticket:
"Hello,

Please see the attached LOA.

Regarding the RPKI ROA, for now, we don't create ROA for our prefixes
nor for prefixes that we assign to our customers and we don't plan to
do it. Unfortunately, this is not an option."

Someone that poses as a Tier-1 and doesn't even plan to sign their
announcements ? How much more depeering will make them reconsider ?

Rubens

TC x IRRd 4.2

[Rubens Kuhl]

Hi all.

TC IRR, an IRR operator focused on Brazilian networks, just changed to IRRd
4.2.
The new version allowed TC to deploy RPKI validation (thanks NTT for
sponsoring that development) and expose HTTPS endpoints for WHOIS and
submission that we hope will foster innovation around the database.

Every precaution was taken for this migration to be seamless for other IRR
operators, including matching of serial numbers. Every IRR server that
mirrored TC and supported -j status query was verified that it followed and
still correctly follows database journals.

But if anything appears broken, please let me know or e-mail
db-ad...@bgp.net.br.

Thanks,
Rubens

Re: Pinging Lumen and RADB (was: Notice to IRRd operators)

[Rubens Kuhl]

Just to inform you that both RADB and Lumen are now in sync with TC again.
Thanks to those who either contacted me or silently resolved the issue.


Rubens


On Mon, Apr 12, 2021 at 7:06 PM Rubens Kuhl  wrote:

>
> After the change, NTT IRR is correctly mirroring the new IP address
> (thanks for that), but rr.level3.net and radb.net seem to be stuck with
> the old IP, and since the old IP address is non-authoritative (flag N),
> replication to those IRRs has in effect stopped.
>
> So, if those two IRR operators could act on it, it would be nice.
>
> Thanks,
> Rubens (on behalf of TC)
>
>
> On Sat, Apr 10, 2021 at 4:27 PM Rubens Kuhl  wrote:
>
>>
>> Hi there.
>> TC, a large IRR database focused on Brazilian networks, just changed its
>> IP addresses. In most IRRd implementations it's necessary to sighup the
>> daemon to move to the new IP addresses, so we kindly ask those running
>> public and private IRR instances to sighup in order to move to the new IP
>> addresses.
>>
>> The new addresses of bgp.net.br are:
>> bgp.net.br has address 177.128.210.126
>> bgp.net.br has IPv6 address 2804:890:0:102::102
>> bgp.net.br mail is handled by 10 bgp.net.br.
>>
>> The old machine will be up and serving mirroring requests until we see
>> most, if not all, of requests being served by the new machine.
>>
>> Thanks,
>> TC
>>
>>

Pinging Lumen and RADB (was: Notice to IRRd operators)

[Rubens Kuhl]

After the change, NTT IRR is correctly mirroring the new IP address (thanks
for that), but rr.level3.net and radb.net seem to be stuck with the old IP,
and since the old IP address is non-authoritative (flag N), replication to
those IRRs has in effect stopped.

So, if those two IRR operators could act on it, it would be nice.

Thanks,
Rubens (on behalf of TC)


On Sat, Apr 10, 2021 at 4:27 PM Rubens Kuhl  wrote:

>
> Hi there.
> TC, a large IRR database focused on Brazilian networks, just changed its
> IP addresses. In most IRRd implementations it's necessary to sighup the
> daemon to move to the new IP addresses, so we kindly ask those running
> public and private IRR instances to sighup in order to move to the new IP
> addresses.
>
> The new addresses of bgp.net.br are:
> bgp.net.br has address 177.128.210.126
> bgp.net.br has IPv6 address 2804:890:0:102::102
> bgp.net.br mail is handled by 10 bgp.net.br.
>
> The old machine will be up and serving mirroring requests until we see
> most, if not all, of requests being served by the new machine.
>
> Thanks,
> TC
>
>

Notice to IRRd operators

[Rubens Kuhl]

Hi there.
TC, a large IRR database focused on Brazilian networks, just changed its IP
addresses. In most IRRd implementations it's necessary to sighup the daemon
to move to the new IP addresses, so we kindly ask those running public and
private IRR instances to sighup in order to move to the new IP addresses.

The new addresses of bgp.net.br are:
bgp.net.br has address 177.128.210.126
bgp.net.br has IPv6 address 2804:890:0:102::102
bgp.net.br mail is handled by 10 bgp.net.br.

The old machine will be up and serving mirroring requests until we see
most, if not all, of requests being served by the new machine.

Thanks,
TC

Re: dumb question: are any of the RIR's out of IPv4 addresses?

[Rubens Kuhl]

On Tue, Feb 16, 2021 at 8:06 PM Michael Thomas  wrote:

>
> Basically are there places that you can't get allocations? If so, what
> is happening?
>
>
In LAC region (LACNIC, NIC.br and NIC.mx), the controlled depletion phases
are now complete and the RIR reached 0 available IPv4 addresses, regardless
of request type (new entrants or not, small or large allocations). There is
a continuous reclaim process that from time to time reallocates previously
allocated addresses, or blocks that might come from IANA reclaim process.
For the requests made in 2020(only new entrants up to /22 allowed), odds
are all got or will get their block this year. For the ones requesting this
year, the outlook is not so favorable and it might take years. Or possibly
never.


Rubens

Re: Past policies versus present and future uses

[Rubens Kuhl]

On Mon, Jan 25, 2021 at 1:28 PM Rob McEwen  wrote:

>
> A take on the 1979 movie "When A Stranger Calls" - "have you checked the
> children?" becomes "have you checked the IP registration?"
>
> [image: Have you checked the IP registration?]
>
>
> The vast majority of the time, Ron Guilmette does "the Lord's work" - but
> THIS time - it looks to me like he put his political biases ahead of legit
> anti-abuse, and it's no surprise that we now have a trail of destruction
> left behind, along with much "innocent bystander" collateral damage.
>
> Is DDoS-Guard without blame? Probably not, but them hosting some
> occasional criminals is NOT UNLIKE EVERY OTHER GLOBAL NETWORK! So like
> other large and diversity global networks, anti abuse should focus on
> removing their worst criminals/spammers. By these SAME standards, many
> other large and famous networks should lose most or much of their IPs too!
>
> So here we are, with many OTHER networks now legitimately freaked out
> about losing their IPs, and with massive potential collateral damage that
> might hurt many "innocent bystanders" each time that is done!
>
>
They are not losing IPs because of hosting questionable content. It's very
reassuring to see RIR policies being enforced; there is a sentiment of lack
of accountability in IP allocations and that changing is positive for all
the ecosystem.


Rubens

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

[Rubens Kuhl]

YMMV, but my take:
1 - You should worry a little, but not much. Filters allowing unwanted
announcements might be created using these erroneous IRR records, but
they won't do any damage by themselves. An actual wrong BGP
announcement is required for any damage to happen, and even without
those IRR records, a wrong announcement will cause some havoc since
not everyone builds filters based on IRR and not everyone runs RPKI
validation.
2 - Most IRR databases will take reports from the RIR-registered
contact of the block seriously. Some databases will react faster than
others; for instance, in TC any such objects will be removed upon
knowledge and if the maintainer recreates those objects, the
maintainer may be permanently excluded from the database.
3 - Unfortunately there is not much you can do since this is caused by
relaxed submission filtering at IRR databases, The RIR-connected IRR
databases are usually very good in preventing such, but the
independent ones usually are not. IRRd versions prior to v4 (thanks
NTT for v4) are also more prone to accept non-compliant records and
can only eliminate them after inclusion.


Rubens



On Fri, Oct 30, 2020 at 10:11 PM Pirawat WATANAPONGSE  wrote:
>
>
> Dear Guru(s),
>
>
> I am seeking advice concerning someone else announcing IRR records on 
> resources belonging to me.
> [I was referred to this mailing list from the DNS-OARC community.]
>
> Context:
> I have already registered all my IP address blocks with ROA/RPKI
> [evidence: 
> https://stat.ripe.net/widget/as-routing-consistency#w.resource=AS9411]
> However, HE reports a lot of spurious IRR records on my resources
> [example: https://bgp.he.net/net/158.108.0.0/16#_irr]
>
> Question #1:
> Should I worry about those spurious records [Yes | No | Depends]?
> My fear is that other sites might accept those records without checking and 
> thus be misled somewhere else, since ROV is not yet the behavior-in-majority.
> My other reasoning is that, if we are not going to keep accurate records, why 
> bother keeping them at all anyway.
>
> Question #2:
> What can I do about it [in case the answer to Question #1 is Yes]?
> Should I notify those Database Admins? Will they consider me a nuisance?
> And most importantly: Will they erase those records for me, or will they just 
> ignore me?
>
> Question #3:
> Did I not do something that can prevent those spurious records from happening 
> in the first place?
> And, anything I can do now to prevent it from ever happening again?
>
>
> Thanks in advance for your advice(s),
>
> Pirawat.
>

Re: Does anyone actually like CenturyLink?

[Rubens Kuhl]

The only ones that like CL are the ones with no options. CL is now an
operational threat to the whole Internet due to their hours-long time
to withdraw routes, something that having other providers or not being
a direct customer doesn't prevent.

The outage that happened, while long, was the type that every big
enough infrastructure will face one day or another. But their
inability to process BGP messages is unacceptable, and it has been
like that for a long time.


Rubens

On Sun, Aug 30, 2020 at 12:03 PM Ross Tajvar  wrote:
>
> I've never heard a single positive word about them, and I've had my fair 
> share of issues myself (as an indirect customer). But it seems that lots of 
> people put them in their transit blend. Other than lack of options, why would 
> anyone use them? To me, it just seems like asking for trouble...but maybe I'm 
> missing something?

Re: atmark trading

[Rubens Kuhl]

On Sat, Aug 22, 2020 at 5:45 PM Mike Hale  wrote:
>
> I've found it useful to email management if certain sales people refuse to 
> stop contacting you.


My experience is that management of spammer companies tries arguing
it's not spam instead of changing practices.
And this includes so-called reputation providers.

Rubens

Re: SaoPaolo to Frankfurt

[Rubens Kuhl]

On Mon, Jul 13, 2020 at 12:01 PM Mark Tinka  wrote:

>
>
> On 12/Jul/20 17:19, Rubens Kuhl wrote:
>
>
>
> Alternative routes before EllaLink comes into operation would be one of
> the Brazil-Africa cables (one to Cameroon, the other to Angola) and then to
> Europe.
>
>
> Are you talking about SAex?
>
> There is SACS as well.
>
>
Brazil-Angola cable is SACS, which for an European route would be paired
with WACS to go from Angola to Portugal.
Brazil-Cameroon cable is SAIL, which to get to Europe would be paired with
ACE to go from Cameroon to Portugal or France.


Rubens

Re: SaoPaolo to Frankfurt

[Rubens Kuhl]

On Sun, Jul 12, 2020 at 12:06 PM Max Tulyev  wrote:

> Hi All!
>
> Who can provide a VLAN from SaoPaolo to Frankfurt for remote IX.BR
> participation? Please contact me off-list.
>
> I see there is only one undersea cable going directly from Brazil to
> Europe. Why?
>

And this single cable, Atlantis-2, has very little capacity so its usage is
mostly voice traffic.
There is a new cable in construction called EllaLink (https://ella.link/)
that when installed will add plenty of capacity to this route, but most
Brazil - Germany traffic goes thru the US nowadays.

Alternative routes before EllaLink comes into operation would be one of the
Brazil-Africa cables (one to Cameroon, the other to Angola) and then to
Europe.


Rubens

Re: Layer 3 Switches

[Rubens Kuhl]

>
> I've liked the price of the Ubiquiti switches I've seen, but haven't gotten
> to play with them, and based on their EdgeRouter line, am not sure about
> their maturity either.
>
>
A switch's maturity is much more dependent on hardware while a router is
much more dependent on software, so I suggest assessing a switch on their
own merits, regardless of bad experiences with that vendor in the router
realm.


Rubens

Re: RDAP snapshots

[Rubens Kuhl]

I don't see any RIR approving a bulk WHOIS request on a weekend alone, but
the way is like this:
https://www.arin.net/reference/research/bulkwhois/

Rubens

On Sat, Jun 27, 2020 at 3:43 PM Lars Prehn  wrote:

> Hi everyone,
>
> Is there a "fast" way to obtain a snapshot of the RDAP databases from
> each RIR (e.g., http://rdap.db.ripe.net/) for local use? I saw some
> presentations on proposals for RDAP monitoring, but couldn't find any
> working implementations. I want to run a massive amount of requests
> against it (for a research project) and would like to keep the load on
> the RIR APIs low.
>
> Unfortunately, our deadline is Monday night. Therefore "fast" really
> boils down to 'till tomorrow'.
>
> Thanks for answers in advance!
>
> Best regards,
>
> Lars
>
>

Re: 60 ms cross-continent

[Rubens Kuhl]

> > This is a nice plot for a movie, but not how HFT is really done. It's so
> > much easier to colocate on the same datacenter of the exchange and run
> > algorithms from there; while those algorithms need humans to guide their
> > strategy, the human thought process takes a couple of seconds anyways. So
> > the real HFTs keep using the defined strategy while the human controller
> > doesn't tell it otherwise.
>
> For faster access to one exchange, yes, absolutely, colocate at the
> exchange.  But there's more then one exchange.
>

Yes, but to do real HFT you will need to colocate at each exchange.
Otherwise your competitors have a head start on you.


>
> As one example, many index futures trade in Chicago.  The stocks that
> make up those indices mostly trade in New York.  There's money to be
> made on the arbitrage, if your Chicago algorithms get faster
> information from New York (and vice versa) than everyone else's
> algorithms.
>

Most traded index futures are longer than just that day closing, usually
months to a year in advance.
They are influenced mostly by traders perception on economic futures, and
the current stocks valuation is a poor proxy for it.
There is more chance in reading the news feeds and speculating its impact
on perception than stocks.

Rubens