- NANOG - lists.nanog.org

P.C Picks: Best of NANOG 84 👉WATCH NOW: N84 Full Webcast
by Nanog News 04 Mar '22

04 Mar '22

*VIDEO * *Do the Wrong Thing! w/ Keynote Radia Perlman * *Watch or rewatch: *brilliant Internet pioneer Radia Perlman lights up our NANOG 84 Keynote stage with her presentation: *Do the Wrong Thing! How Bad Industry Decisions Led to Good Technology Development.* *More info: *This presentation describes some technical decisions that the industry made that, although clearly “wrong”, wound up causing technologies to be invented that are quite wonderful. Radia presses the audience to not ask, “how can I use this thing?” But, instead “what problem am I solving, what are various ways of solving it, and which technical approach is the best?” *WATCH NOW <https://www.youtube.com/watch?v=5D1v42nw25E&list=PLO8DR5ZGla8iwcpODjNgf1faB…>* *PC Picks: Best of NANOG 84* *Programming Committee Picks Favorite Talks from our Last Meeting* Want to catch up on all the NANOG 84 talks, but don't know where to start? The NANOG Programming Committee (PC) has your back. Read the "Best of NANOG 84" curated by our own panel of experts, then tell us your favorites! *READ NOW * <https://www.nanog.org/stories/pc-picks-best-of-nanog-84/> *VIDEO | NANOG 84 Talks Available Online * *Watch Full Webcast on Youtube * The full webcast of our last meeting is available in the "NANOG 84 playlist" <https://www.youtube.com/watch?v=TeokK85-Usc&list=PLO8DR5ZGla8iwcpODjNgf1faB…> on our YouTube channel. <https://www.youtube.com/channel/UCIvcN8QNgRGNW9osYLGsjQQ> Please make sure you are subscribed to our channel to be notified when new content is released! Enjoy hours of insights from some of the brightest minds in network engineering, operations, + architecture. *THANK YOU* A huge thank you to host sponsor Quantum Loophole, <https://mail.google.com/mail/u/0/#inbox/FMfcgzGmvLQgtShZbDHdNJQXTTcmmgKn?co…> as well as, all sponsors, <https://www.nanog.org/events/nanog-84/our-sponsors/> attendees, Hackathon participants + speakers. We truly appreciate your time and energy in helping us build the Internet of tomorrow.

1 0

Ukraine request yikes
by George Herbert 04 Mar '22

04 Mar '22

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… -george Sent from my iPhone

24 34

Saw 40-45% packet loss on both Lumen and ATT MPLS backbones
by Shahid Shafi 04 Mar '22

04 Mar '22

Wondering anyone else noticed it and the loss lasted approx 10 mins. I am wondering if one of our routers misbehaved or was there an actual SP loss?

1 0

Starlink terminal visual camouflage tests vs improvised fabric materials
by Eric Kuhnke 03 Mar '22

03 Mar '22

I have just completed some very unscientific tests of DIY camouflage materials vs a starlink terminal. Obviously there is a lot of possible discussion that is possible about spectrum analyzers, direction finding, jammers, etc within the context of what's going on in Ukraine right now. All very valid concerns. That said, there's also some DIY possibilities for making a starlink terminal much less noticeable from the air or casual observation, such as if installed on top of a mid rise apartment building in any Ukrainian city. I would wager that the ratio of portable Ku/Ka-band spectrum analyzers with horn antennas to invasion foot soldiers/armored vehicle soldiers is rather low at present. Terminal is the same as the following RIPE atlas probe location: https://atlas.ripe.net/probes/1001821 Terminal is a v1 from Jan. 2021. Fabrics have been draped flat over the Starlink terminal. What effect this will have vs. suspended in the air a meter or so above it on some sort of improvised framework is a question I can't really answer right now (if we have any inflatable or fabric radome specialists here, please chime in). Average of multiple speedtest.net CLI runs to server ID 11329 in Seattle. In general any of the well-peered speedtest.net servers in Seattle have the same results, the bottleneck is the starlink last-mile performance at any given point in time, and not any terrestrial network factors. *Baseline terminal with no material above it. I do have a slight tree obstruction in 1/12th of its field of view to the northeast.* 152.48 Mbps down x 8.23 Mbps up, 3.17% loss (note this averages more like 0.43% loss over 3 to 10 hour periods to its gateway in Seattle, I believe the loss during the particular time period this data was gathered to be an aberration). *Tent rain fly, synthetic nylon material, dry* 162.02 Mbps down x 7.14 Mbps up, 1.43% loss *Two layers cotton bed sheet, doubled over on itself, thoroughly soaked in tap water* 55.79 Mbps down x 3.70 Mbps up, 0.77% loss *One layer cotton bed sheet, dry* 158.78 Mbps down x 7.16 Mbps up, 0.9% loss *Two layers thin polypropylene tarpaulin, doubled over on itself, approximately simulating the thickness of a single layer heavy duty tarp.* 152.77 Mbps down x 9.70 Mbps up, 1.41% loss

2 1

Anyone have contacts for Akamai GeoIP
by Christopher Munz-Michielin 03 Mar '22

03 Mar '22

Hey All, Hoping someone has a contact at Akamai who can assist. As part of my day job I run a DNS network and we've been having issues with Akamai mis-locating the geolocation of some of our revolvers. The most egregious example is our resolver in Frankfurt being classified as Australian, but there are some other instances as well. This is an issue because we run fully recursive revolvers, so when a customer queries our DNS server, we attempt to resolve the domain directly against the authoritative name servers (Akamai in this case). Because Akamai has mis-located our IPs, we get handed an IP in the wrong hemisphere and our customers experience 200+ ms latency to sites that should be regional. We've tried reaching out via a couple of channels but have not gotten anything back, wondering if anyone on the list knows a contact address for Akamai GeoIP we can submit corrections to. Cheers,

2 1

RIR IRR interfaces
by Jon Lewis 02 Mar '22

02 Mar '22

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&click&paste. 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_________

2 1

Authoritative Resources for Public DNS Pinging
by Mike Hammett 01 Mar '22

01 Mar '22

Yes, pinging public DNS servers is bad. Googling didn't help me find anything. Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP

33 85

Certificates for DoT and DoH?
by Bjørn Mork 01 Mar '22

01 Mar '22

Any recommendations for a CA with a published policy allowing an IP address SAN (Subject Alternative Name)? Preferably someone using ACME with a simple RFC 8738 reference. Let's Encrypt had this in their TODO list for a while, but it was removed and the project was put on hold: https://github.com/letsencrypt/boulder/pull/4920#issuecomment-832104881 https://community.letsencrypt.org/t/planned-rfc-8738-support-pulled/152057 And I've been unable to find any other CAs with RFC 8738 support either. Most of them don't even bother documenting it as unsupported. All I've found is this answer from Buypass: https://community.buypass.com/t/h7hm76w/buypass-support-for-rfc-8738 So what do people use for DoT and DoH? I see that Google got a certificate from their own CA. No surprise... Version: 3 (0x2) Serial Number: 9c:d9:a2:0f:fe:dd:2b:0a:12:00:00:00:00:03:6f:0b Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 Validity Not Before: Feb 17 11:34:59 2022 GMT Not After : May 12 11:34:58 2022 GMT Subject: CN = dns.google Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:ec:43:69:7c:2b:7d:99:d5:f3:79:d7:b8:54:bd: 6e:61:7b:8d:50:c5:bb:86:6c:a3:60:27:3e:22:c6: 45:00:68:a2:d2:2e:c9:c2:8f:8e:58:0e:93:0a:a4: ff:2d:5c:71:d9:0a:5b:f3:1c:ce:79:d2:71:5c:20: 4a:34:21:c1:fa:c3:92:bd:e8:7e:bd:93:79:ef:ad: 0b:74:e0:21:f6:22:4e:9c:39:01:48:49:bc:a0:db: 98:0b:ab:4c:df:99:b1:30:92:09:0d:f8:ea:0f:7f: 85:65:55:e7:9f:ba:88:4a:ca:93:04:71:8d:13:f7: 3b:e3:36:ee:fc:b7:b9:fc:e5:5a:a8:7b:22:ce:0a: dd:4b:36:ee:d9:8f:09:d4:2e:3f:48:5e:f8:7c:71: 2d:65:26:29:67:b9:c7:b2:77:8a:60:20:4f:dd:74: 00:49:c5:6f:3b:19:d0:ea:f8:78:ef:86:02:37:be: 3d:2e:d1:14:18:22:22:e6:94:65:bb:9d:37:b8:61: 8b:2c:fc:85:bc:04:01:56:74:04:b9:86:dc:59:9a: 75:9d:de:d9:65:67:5d:9f:75:f3:6d:8a:4f:61:d2: c5:b5:e1:dd:2e:54:78:8a:a8:39:ab:d1:0c:97:4d: bc:7d:f2:64:cb:d3:21:5a:f0:70:03:08:a6:f4:21: 4c:63 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: critical CA:FALSE X509v3 Subject Key Identifier: A6:21:3C:08:17:99:1E:DE:2D:F5:EB:C8:90:C9:71:D2:E9:53:1D:EE X509v3 Authority Key Identifier: keyid:8A:74:7F:AF:85:CD:EE:95:CD:3D:9C:D0:E2:46:14:F3:71:35:1D:27 Authority Information Access: OCSP - URI:http://ocsp.pki.goog/gts1c3 CA Issuers - URI:http://pki.goog/repo/certs/gts1c3.der X509v3 Subject Alternative Name: DNS:dns.google, DNS:dns.google.com, DNS:*.dns.google.com, DNS:8888.google, DNS:dns64.dns.google, IP Address:8.8.8.8, IP Address:8.8.4.4, IP Address:2001:4860:4860:0:0:0:0:8888, IP Address:2001:4860:4860:0:0:0:0:8844, IP Address:2001:4860:4860:0:0:0:0:6464, IP Address:2001:4860:4860:0:0:0:0:64 X509v3 Certificate Policies: Policy: 2.23.140.1.2.1 Policy: 1.3.6.1.4.1.11129.2.5.3 X509v3 CRL Distribution Points: Full Name: URI:http://crls.pki.goog/gts1c3/zdATt0Ex_Fk.crl [cut] But this is not an option for anyone else according to https://pki.goog/faq/#faq-29 : How can I get a certificate from Google Trust Services? At this time, the only way to get a certificate from Google Trust Services is via an Alphabet or Google product. I guess it's easy to push for DoT and DoH when you can create rules like that. Both Quad9 and Cloudflare got their certificates from DigiCert: Version: 3 (0x2) Serial Number: 05:45:06:fe:17:98:52:bb:fa:c1:a7:3d:cd:80:39:7b Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Jul 27 00:00:00 2021 GMT Not After : Aug 4 23:59:59 2022 GMT Subject: C = US, ST = California, L = Berkeley, O = Quad9, CN = *.quad9.net Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:7d:8b:d7:1d:03:85:0d:18:25:b3:34:1c:29:a1: 27:d4:ac:01:25:48:8a:a0:f1:ea:02:b9:d8:51:2c: 08:6a:ac:72:56:ec:fa:3d:a6:a0:9f:49:09:55:8e: ac:fe:b9:73:17:5c:02:fb:78:cc:24:91:94:6f:43: 23:89:0e:1d:66 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 7F:A9:12:A5:D7:C6:8B:48:02:C7:3D:2A:45:6E:40:1E:40:60:F4:97 X509v3 Subject Alternative Name: DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE [cut] Version: 3 (0x2) Serial Number: 0f:75:a3:6d:32:c1:6b:03:c7:ca:5f:5f:71:4a:03:70 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1 Validity Not Before: Oct 25 00:00:00 2021 GMT Not After : Oct 25 23:59:59 2022 GMT Subject: C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:fb:29:44:f2:98:3f:d8:bd:82:56:d3:2c:bd:8e: 09:9f:31:2b:98:26:9e:22:96:8d:7b:4b:fc:da:c5: 7b:7b:29:aa:8e:35:6c:9c:0a:48:05:6c:89:73:ed: 20:0e:cd:46:21:f0:ec:4d:b3:a5:e9:af:1b:38:99: e5:f4:da:f1:84 ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:0A:BC:08:29:17:8C:A5:39:6D:7A:0E:CE:33:C7:2E:B3:ED:FB:C3:7A X509v3 Subject Key Identifier: 19:45:1B:23:18:F8:74:DA:22:14:CB:46:6B:E2:13:B3:60:15:82:40 X509v3 Subject Alternative Name: DNS:cloudflare-dns.com, DNS:*.cloudflare-dns.com, DNS:one.one.one.one, IP Address:1.1.1.1, IP Address:1.0.0.1, IP Address:162.159.36.1, IP Address:162.159.46.1, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001, IP Address:2606:4700:4700:0:0:0:0:64, IP Address:2606:4700:4700:0:0:0:0:6400 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl Full Name: URI:http://crl4.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crl X509v3 Certificate Policies: Policy: 2.23.140.1.2.2 CPS: http://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crt X509v3 Basic Constraints: critical CA:FALSE CT Precertificate SCTs: [cut] Does this mean that DigiCert is the only alternative? And do they really have this offer for ordinary users, or is this also some special arrangement for big players only? I see that a CSR with a DNS name, an IPv4 address and an IPv6 address is accepted by https://www.digicert.com/ssltools/view-csr/ But when I test the same CSR on their order page, only the DNS name is extracted into the order form. Leaving me confused and worried about the addresses being ignored. And their documentation sucks. Like all CAs, I might add. There is no mention of how you are supposed to demonstraete IP address control on https://docs.digicert.com/manage-certificates/demonstrate-control-over-doma… Searchin for RFC 8738 on https://docs.digicert.com/search/?query=8738 returns "No results found for 8738". Even if they do have ACME support for automated certificate management. So I guess automated certificate management of certificates with IP address SANs is out of the question. That's a bummer. I really, really do not want to go back to semi-manual certificate management hell and the resulting periodical breakage. https://www.digicert.com/tls-ssl/multi-domain-ssl-certificates looks like a bad joke: The  Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single TLS/SSL certificate That does make me wonder how they verify that I'm the rightful owner of "sites, IP addresses, common names, etc.". In particular, "etc" :-) Or you could ask yourself if you trust a CA with such an offer... Yes, I'm frustrated. Why is a business that is mostly about selling policies so afraid of actually publishing those policies? Bjørn

4 7

New minimum speed for US broadband connections
by Sean Donelan 28 Feb '22

28 Feb '22

What should be the new minimum speed for "broadband" in the U.S.? This is the list of past minimum broadband speed definitions by year year speed 1999 200 kbps in both directions (this was chosen as faster than dialup/ISDN speeds) 2000 200 kbps in at least one direction (changed because too many service providers had 128 kbps upload) 2010 4 mbps down / 1 mbps up 2015 25 Mbps down / 3 Mbps up (wired) 5 Mbps down / 1 Mbps up (wireless) 2021 ??? / ??? (some Senators propose 100/100 mbps) Not only in major cities, but also rural areas Note, the official broadband definition only means service providers can't advertise it as "broadband" or qualify for subsidies; not that they must deliver better service.

68 256

EPL to Bangalore
by Mark Robinson 28 Feb '22

28 Feb '22

Hunting for E-Line;/EPL provider from Los Angeles to Bangalore India. Anyone have recommendations? Thanks, Mark

2 1