March 2022 - NANOG - lists.nanog.org

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