RE: Correcting national address databases?
On May 30, 2024, at 10:12 AM, Christopher Paul via NANOG
wrote:
>
> I propose that there be a national LDAP service, with OUs for each zipcode
> (ou=20500,dc=us,dc=gov). A household could register at USPS.gov and then be
> given
> write access to a household OU ("ou=1600 Pennsylvania Ave
> NW,ou=20500,dc=us,dc=gov").
> The household OU could then create inetOrgPersons under that, each of which
> would have
> self-write access.
Your schema is probably good for 99% of the population. I do wonder though if
USPS is the right / sole agency to maintain. Having 911 dependent on an
incomplete database seems unwise. Or is it ALI? Not sure if it was Verizon's
front end or back end that was the real problem there.
The first time I encountered the problems of living in a place with no postal
delivery I had a related challenge which was to obtain a new driver's license
(along with updating vehicle registration and voter registration). New Mexico
requires two proofs of current residential address which for good reasons
cannot be a PO Box. The house I was renting was fairly new and I don't think
USPS knew it even existed. There were no road signs or house numbers posted.
The first time that I visited it the landlord rode along and gave me
turn-by-turn directions. There was an address on the lease I signed, but I had
no way to verify it corresponded to the property I visited. In fact later I
learned that the lease was copied from a template and the address had not been
updated (when even property owner gets it wrong, what hope does a bureaucrat
have?)
It took multiple trips to the MVD to obtain a license, being turned away
several times for insufficient paperwork. I had no utility bills for an
off-grid home with no postal delivery. In the end they accepted a copy of the
lease (which I had to photoshop to show the correct address) and a statement
from the bank. But wait... where did the bank get my address? I gave it to them
verbally and they accepted it as fact. Some time after getting my ID I found a
document issued by the county that assigned a street address to the house for
emergency/law enforcement purposes. To my knowledge that is the one and only
official documentation of the address.
It was around this time (2012) I first became aware of an impending REAL ID
requirement that the state was rushing to meet. The paradox of having to
manipulate the system to prove my actual residence to obtain a more secure &
state-mandated ID card was not lost on me. I never did try to update 911
location when I lived there.
This situation of USPS vs 911 vs DMV vs. bank vs. insurer vs. county
assessor/elections vs. ? reminds me a little of "Gay marriage: the database
engineering perspective" (
https://web.archive.org/web/20170118114056/https://qntm.org/gay ) and if I were
tasked with creating a grand unified address database all those entities could
use I'd be studying it and probably also Wes Kussmal's "The Sex Life of Tables:
What happens when databases about you MATE?"
Can I have two entries for two residences? How/who decides which is "primary"
for income tax purposes then? Can I have zero entries for being unhoused but
have a cell phone and potentially need 911 services? If I'm paranoid can I
opt-out of that for mental health reasons? Can I delete an entry my parents
added after I'm disowned, preferably without setting up a forwarding entry?
I guess the current state of REAL ID should quash any hopes I have for
resolving even the relatively simpler problem of 911 USPS location dependency.
https://www.theatlantic.com/ideas/archive/2024/05/real-id-deadline-will-never-arrive/678370/
RE: Correcting national address databases?
That postal database is especially problematic for those who live in rural areas with no postal delivery. We need a better database system than the one that USPS maintains because it affects a wider range of services. Two years ago I moved to a house with no postal service, so I got a PO box in town for regular postal mail. I am able to get FedEx, UPS and other non-USPS package deliveries to my residence. Google Maps knows right where I live. For most purposes, this arrangement is fine. But not all The first thing I noticed is that Verizon Wireless was unable to update my 911 location to my physical address because they are pulling from the postal database. I tried working through Verizon support a couple different ways but no one knew how to fix it. I finally complained to the FCC and after a couple months someone at Verizon went in and manually updated my address. I'm sure other people are in the same boat. Yeah, hopefully E911 gets a fix in an emergency but I'm not counting on it, especially when I'm inside and I see the Maps application on my phone putting my location at a nearby cell tower. The next issue is that it is impossible to apply for credit cards and probably other loans online. The banks (more than one I've tried) use the postal database and do not recognize my street address and do not accept PO Box input. Another issue is that Amazon (and possibly other online retailers) are charging me and my neighbors excess sales tax based on the ZIP code associated with a town I do not live in. There's a way to complain and have it reversed for every single purchase. I know this is out of our hands as network operators, but maybe some day one of you will be in a position to help. > On May 29, 2024, at 7:14 PM, Aaron C. de Bruyn via NANOG > wrote: > > > I'm guessing someone in the community has experience dealing with this. > > About 3 years ago my street got typo'd in some sort of national database of > addresses. Two characters were transposed. i.e. "Mian St" vs "Main St". > > It's causing no end of issues with ordering online, pretty much every shipper > has picked up the bad address, and some of the mapping tools too. Google and > OSM appear to be the exceptions. > > Any idea where to go to get this fixed? > > -A
RE: Meta outage
On Tue, 05 Mar 2024 12:17 -0700, Michael Rathbun wrote: > What I found intriguing was that I was logged out by Google Docs at the same > moment FB logged me out. Downdetector showed a number of other supposedly > unrelated services with large outage report spikes at roughly the same time. I was logged out of Honeywell's Total Connect Comfort site (remote thermostat control) at the same time FB logged me out. I'm not using OAUTH logins anywhere. I had recently changed SSID and the thermostat wasn't accepting remote commands. I thought maybe the SSID change had broken it and had just deleted the device from the TCC site to try adding it back when I was logged out. It's funny timing because earlier today I was telling an employee how we don't like to have our maintenance overlap with vendor's maintenance/repair window because when something breaks while we are making changes we can't always tell who is at fault.
RE: Strange IPSEC traffic
I can confirm we started seeing this on Nov 9th at 19:10 UTC across all markets from a variety of sources. If you want to filter it with ingress ACLs they need to include subnet base and broadcast addresses in addition to interface address, so a router at 192.168.1.1/30 with a customer potentially running IPSEC at 192.168.1.2 would require all this to silence the log messages: access-list 100 deny esp any host 192.168.1.0 access-list 100 deny esp any host 192.168.1.1 access-list 100 deny esp any host 192.168.1.3 access-list 100 permit ip any any I started with an ACL only on the interface address and then noticed I was still getting logs on base/broadcast addresses. Could be recon for the IKEv2 vulnerability in this: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-ravpn-auth-8LyfCkeC https://blogs.cisco.com/security/akira-ransomware-targeting-vpns-without-multi-factor-authentication Or zero day. Even though the devices they are hitting are not configured for IPSEC we are filtering it anyway (and for good measure " no crypto isakmp enable"). Mike
Re: TACACS+ server recommendations?
> We are using Okta's RADIUS service for 2fa to network gear currently, > but looking to switch to tacacs+ for many reasons. Would prefer to > implement tacacs+ with two-factor if possible. tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has LDAP and PAM backends, among others, so I believe you can implement 2FA through them. I haven't implemented this yet but it's on my to-do list (and I'm also warily watching passkey developments and wondering how much effort I should put into something that likely won't be best practice in another year or two). I see Marc Huber is also promoting/supporting tacacs+ extension for SSH public key auth https://github.com/MarcJHuber/event-driven-servers/wiki/TACACS_PLUS---SSH-Public-Key-Authentication
Re: TACACS+ server recommendations?
> https://www.shrubbery.net/tac_plus/ That tac_plus has python 2 dependencies and so has been removed from Debian packages. That's not surprising given the last update was 2015 and Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/ Currently I favor this one which is still being actively developed: https://www.pro-bono-publico.de/projects/tac_plus.html
Remote code execution bug in FreeBSD's ping (CVE-2022-23093)
Ooof. https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc Some hope here: "The ping process runs in a capability mode sandbox on all affected versions of FreeBSD and is thus very constrainted in how it can interact with the rest of the system at the point where the bug can occur." Lots of other things are based on FreeBSD and may be affected, including firewalls like pfsense and OPNsense and possibly Junos. At the least I expect host discovery is ramping up by now.
RE: SATCOM terminals under attack in Europe
Precedent? https://blog.codinghorror.com/revisiting-the-black-sunday-hack/
RE: Authoritative Resources for Public DNS Pinging
> Do you know if this was codified prior to 1.1.1.1 being taken over by > Cloudflare? Yes, I'm sure it was.
RE: Authoritative Resources for Public DNS Pinging
On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband interface by default, and it is apparently not user modifiable. So, not only can these devices never use 1.1.1.1 for name resolution, but attempts to determine "is the circuit up" by pinging it will always return bad information. To really pour salt on the wound, this device has no physical outbound interface (likely why the UI doesn't allow changing it). Bug report filed. I don't really want to use it for either purpose, but hopefully a fix saves someone else the headache. And it really chaps my when public addresses get used this way.
RE: Authoritative Resources for Public DNS Pinging
> What else is like that and easy to remember and isn’t 1.1.1.1 ? 4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1. Muscle memory still favors it. I think 4.2.2.2 might be anycast the same but never really looked hard at it.
RE: Authoritative Resources for Public DNS Pinging
Anyone swinging a clue-by-four it going to hit Meraki real hard. https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491
RE: Anyone from Level3/CenturyLink/Lumen, possibly Comcast around?
I can confirm this issue exists at several sites in the Denver area with this same IPSEC issue, all routing between Level3/Lumen and Comcast. I was told by one customer that it resolved late yesterday afternoon but I haven't been able to confirm that. Mike -Original Message- From: NANOG On Behalf Of Brie Sent: Thursday, October 14, 2021 10:43 AM To: nanog@nanog.org Subject: Anyone from Level3/CenturyLink/Lumen, possibly Comcast around? Hi all, So, having a... frustrating issue going on. Long wall of text ahead as I explain. 1 x CenturyLink/Lumen fiber in Boise 1 x CenturyLink/Lumen fiber in Cheyenne 1 x Comcast biz fiber in Denver IPsec VPN tunnels between all three sites, w/ OSPF for routing failover (which unfortunately doesn't help in this situation). Two days ago, Cheyenne to Denver (.196) traffic (both tcp and udp) were an issue initially. Failed over to routing Cheyenne VPN through Boise while we opened ticket with CL. Yesterday, Boise to Denver (.196) traffic started having exact same issue. Tests from another CL fiber in Boise (my own circuit, with legacy IP space and BGP) to Denver (.196) did not show same issues. Path appeared clean. Traceroutes from Office Boise to Denver (.196) had a noticeable difference from Personal Boise to Denver (.196): Office Boise -> Denver (.196) -- 3: sea-edge-15.inet.qwest.net 4: lag-4.ear3.Seattle1.Level3.net 5: ae-2-52.ear2.seattle1.level3.net <-- This hop 6: be-203-pe01.seattle.wa.ibone.comcast.net Personal Boise -> Denver (.196) -- 4: sea-edge-15.inet.qwest.net 5: lag-25.ear2.Seattle1.Level3.net 6: be-203-pe01.seattle.wa.ibone.comcast.net On a whim, tracerouted to another Denver router IP address (.199, IP alias on same interface) from Boise Office, and traceroute matched the traceroute from Personal Boise to Denver (.196) traceroute. No packet loss. Swapped VPN tunnels over to using another ip on same router (.199), same interface physical and logical, in Denver, and VPN was working again normally. This morning though, Cheyenne to Denver (.199) is having problems, while Boise to Denver (.199) isn't (for now). Already spent most of last night working with my partner in Denver replacing nearly everything on the Denver side with no change. Tests from the router above the main Denver VPN endpoint (.196) do not show any kind of issues or packet loss to it, so it doesn't appear the problem is inside of our network. I'm not inclined to think this is a Comcast issue, but I can't be sure. This sounds almost like a load balancing hashing issue, with one link in the bond group having issues, somewhere in one of our upstream's networks. We'll be opening a ticket in a bit through normal channels with CenturyLink/Lumen, but we're worried they're just going to close the ticket as not being their issue. Anyone know of an engineer at CenturyLink/Lumen/Level3 or even Comcast that might want to take a stab at this? I can provide a lot more detail. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
