Re: Texas internet connectivity declining due to blackouts

[Stephen Satchell]

When I lived in Oklahoma, the mantra of the locals was "if you don't 
like the weather, wait five minutes."  As a member of a Boy Scout troop 
in the northern part of the Sooner State, we were told, repeatedly, to 
expect anything from broiling to deep freeze on our campouts.


One such outing was on fallow farmland.  Because the campsite was in the 
middle of nowhere, we were a small group, and came in three cars.  We 
pitched four tents.  During the night, a gullywasher came through and 
dropped several inches of water in one hour.  Three of the tents were 
inundated with water, and the campers ended up sleeping in the cars.  My 
tent was dry inside, because my tent-mate and I had seen the storm 
clouds, dug a trench around the tent, and loosened the ropes.  It helped 
that we had pitched the tent on a slight mound.


Some disasters are unavoidable, like tornados.  Others allow for 
mitigation by the thoughtful.


On 2/22/21 9:18 AM, Rich Kulawiec wrote:

On Tue, Feb 16, 2021 at 12:23:22PM +, Bret Clark wrote:

Texas doesn't generally experience this type of extreme cold.


That was then; this is now.

As scientist Jeff Masters put it most of a decade ago:

The atmosphere I grew up with no longer exists.  My new motto
with regards to the weather is, "expect the unprecedented."

In the years since he's said that we've seen a number of unprecedented
events: Sandy, Harvey, California wildfires, last year's midwest derecho,
and so on.  This event in Texas is just another one; there will be more;
they'll get worse.

We should probably get ready for that.

---rsk

BGP38 egress filter on Ubuntu Server

[Stephen Satchell]

Before I re-invent the wheel, has anyone come up with blackhole route 
specifications for netplan in Ubuntu servers?  Such a capability would 
perform the egress blocking for an edge server.


The table of blackhole routes I would set up:
IPv4
Address block   Scope   Description
0.0.0.0/8   SoftwareCurrent network (only valid as
source address).
10.0.0.0/8  Private network Used for local communications
within a private network.
100.64.0.0/10   Private network Shared address space[3] for
communications between a service
provider and its subscribers
when using a carrier-grade NAT.
127.0.0.0/8 HostUsed for loopback addresses to
the local host.
169.254.0.0/16  Subnet  Used for link-local addresses
between two hosts on a single
link when no IP address is
otherwise specified, such as
would have normally been
retrieved from a DHCP server.
172.16.0.0/12   Private network Used for local communications
within a private network.
192.0.0.0/24Private network IETF Protocol Assignments.
192.0.2.0/24Documentation   Assigned as TEST-NET-1,
documentation and examples.
192.88.99.0/24  InternetReserved. Formerly used for
IPv6 to IPv4 relay
192.168.0.0/16  Private network Used for local communications
within a private network.
198.18.0.0/15   Private network Used for benchmark testing of
inter-network communications
between two separate subnets.
198.51.100.0/24 Documentation   Assigned as TEST-NET-2,
documentation and examples.
203.0.113.0/24  Documentation   Assigned as TEST-NET-3,
documentation and examples.
224.0.0.0/4 InternetIn use for IP multicast.
240.0.0.0/4 InternetReserved for future use.
255.255.255.255/32  Subnet  Reserved for the "limited
broadcast" destination address.

IPv6
Address block   Usage   Purpose
::/0Routing Default route.
::/128  SoftwareUnspecified address.
::1/128 HostLoopback address to local host.
:::0:0/96   SoftwareIPv4 mapped addresses.
:::0:0:0/96 SoftwareIPv4 translated addresses.
64:ff9b::/96Global Internet IPv4/IPv6 translation.
100::/64Routing Discard prefix.
2001::/32   Global Internet Teredo tunneling.
2001:20::/28SoftwareORCHIDv2.
2001:db8::/32   Documentation   Addresses used in documentation
and example source code.
2002::/16   Global Internet The 6to4 addressing scheme
fc00::/7Private network Unique local address.
fe80::/10   LinkLink-local address.
ff00::/8Global Internet Multicast address.

BCP38 on public-facing Ubuntu servers

[Stephen Satchell]

Not every uplink service implements BCP38.  When putting up servers 
connected more-or-less directly to the Internet through these uplinks, 
it would be nice if the servers themselves were able to implement 
ingress and egress filtering according to BCP38.  (Sorry about the typo 
in the subject lines of my previous message -- not everyone can get a 
BGP feed.)


(Or, when using Ubuntu server edition to implement edge routers.)

My earlier query was asking if anyone has encoded the blackhole routes 
in YAML for inserting in netplan(5).  My prior message contains the 
routes to be blackholed.  That takes care of egress routing.


(I think I can write a Python program to take my list and convert it to 
the YAML that netplan(5) wants to see.  That way, the routes are 
inserted when the public interface is up, and removed when the public 
interface is down.)


Ingress routing appears to be one-line addition.  IPTABLES can be told 
to weed out packets with unroutable source addresses.  My experiments 
will add something like this line to the firewall:


# iptables -A INPUT -m addrtype -i enp1s0 --src-type BLACKHOLE -j DROP

THIS HAS NOT BEEN VERIFIED.  I'm building a web server that will 
integrate this idea, and try it out.

Re: BCP38 on public-facing Ubuntu servers

[Stephen Satchell]

On 6/8/21 2:38 PM, Fran via NANOG wrote:

Hey,

to my knowledge there is no IPv6 equivalent for 
net.ipv4.conf.all.rp_filter.


Therefore I use netfilter to do the RP filtering for both address families.

ip(6)tables -t raw -I PREROUTING -m rpfilter --invert -j DROP

Using the raw tables less resources are used, but you could also choose 
other tables.

Details abour rpfilter can be found here [1].

This can also be achieved using nftables [2].


I've been in discussions on how to filter packets with bad source 
addresses on several mailing lists, including this one.  For the last 
few weeks, I've been search for all the information I can find for how 
Linux implements rp_filter...which appears to have some holes.


Looking at /proc/sys/net/ipv6, there is no knob for rp_filter, so if 
your system is IPv6 enabled you have to use the built-in firewall.


For IPv4, I found kernel documentation, but it doesn't tell the whole 
story.  For that, I had to comb the kernel sources to find out all the 
details of rp_filter.  I've prepared a RFC letter of what I think I 
found, to be sent to the kernel developers.  Here is the text of what 
I'll be sending, with any constructive criticism I get from here:


Letter begins:

After looking at the source that appears to implement rp_filter
linux/net/ipv4/fib_frontend.c
I believe that I now understand the tests rp_filter performs to
validate the source address when net.ipv4.conf.*.rp_filter is
set to one or two for a given interface.

Does the new paragraph I have written accurately reflect what
happens?  If so, then I find out how to submit a patch to add the
clarification to the kernel document.

Description of rp_filter from
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

rp_filter - INTEGER
0 - No source validation.
1 - Strict mode as defined in RFC3704 Strict Reverse Path
Each incoming packet is tested against the FIB and if the
interface is not the best reverse path the packet check will
fail. By default failed packets are discarded.
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against
the FIB and if the source address is not reachable via any
interface the packet check will fail.

[*new text here]

Current recommended practice in RFC3704 is to enable strict mode
to prevent IP spoofing from DDos attacks. If using asymmetric
routing or other complicated routing, then loose mode is
recommended.

The max value from conf/{all,interface}/rp_filter is used
when doing source validation on the {interface}.

Default value is 0. Note that some distributions enable it
in startup scripts.


Recommended addition where marked with "[*new text here]":
rp_filter will examine the source address of an incoming IP
packet by performing an FIB lookup.  In loose mode (value 2),
the packet is rejected if the source address is neither
UNICAST nor LOCAL nor IPSEC.  For strict mode (value 1) the
interface indicated by the FIB entry must also match the
interface on which the packet arrived.

A crazy idea

[Stephen Satchell]

First, I know this isn't the right place to propose this; need a pointer 
to where to propose an outlandish idea.


PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem 
that limits deployment of IPv6 fully:  reverse PTR records in the 
".in6.arpa." zones.


(Now that I think about it, this may very well be a network operator 
issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)


I've been going 'round and 'round with AT&T about "static" IPv6 
addresses.  In particular, I can't get a PTR record in the ip6.arpa. 
zone to save my life.  Now, the problem is not really ripe yet, because 
the big reason for PTR records is for mail servers -- best practice 
calls for /PTR agreement, just like for IPv4 the best practice is 
for A/PTR agreement.


The existing DNS providers can support delegation domains, so that I 
don't have to have DNS servers of my own if I don't want to.  It could 
be that one would need to "buy" the delegation domain, but that's a 
front-office consideration.  Personally, I use register.com for my 
domain DNS zones.  I believe strongly that other registrars that offer 
customer zone editing, plus DNS service providers, can support reverse 
delegation zones with a minimum of hassle, and without charging an arm 
and a leg for the service.


From the customers' viewpoint, a GUI would make the maintenance 
relatively painless.


(Keying the information below took a long time.  Any rational DNS admin 
and DNS service provider would have automation in place to take out the 
painful work.)


What would the domain names look like?  Let's take my current IP/IPv6 
assignments from AT&T:


  2600:1700:79b0:ddc0::/64
  99.65.194.96/29

The IPv6 delegation would be easy:


0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.


because the delegation would always be on a /64 boundary. The customer 
assignments would be straightforward.  In my BIND9 zone file, it would 
look something like this:



$ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
@ IN SOA ...
@ NS my-DNS-server-1.
@ NS my-DNS-server-2.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com. 
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com. 


Delegations for the IP range, not being on an octet boundary, would be a 
little more problematic:


> 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
> 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $ 
IN CNAME $.96-103.194.65.99.in-addr.arpa.


In my BIND9 zone file, it would look something like this:


$ORIGIN 96-103.194.65.99.in-addr.arpa.
@ SOA ...
@ NS my-dns-server-1.
@ NS my-dns-server-2.
96 IN PTR server1.example.com.
97 IN PTR server2.example.com.


The advantage to this system to the number providers is they would have 
one administrative record per customer, instead of having to deal with 
each PTR record individually.  The advantage to customers is they don't 
have to beg and snivel to get PTR records, just beg and snivel once to 
get the delegation.  The advantage to DNS server providers is they have 
something else to sell.


Want to encourage IPv6 adoption?  This would help.

Re: A crazy idea

[Stephen Satchell]

On 7/19/21 5:41 AM, Feldman, Mark wrote:

What you propose is not outlandish; some ISPs have been dual stack
and providing some combination of these services for years.  They
already provide IPv6 ip6.arpa delegations should their business
customers want them.  Some even provide at least a /56 so customers
can have multiple /64 subnets.  And we, I mean they, can also provide
RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.


The part that is missing isn't the "some ISPs", it's "all ISPs".  Also, 
I don't know of any DNS service provider that offers a product to handle 
delegations from the IN-ADDR.ARPA and IP6.ARPA trees.


I'm focusing on the SOHO customer market with my proposal.

The allocation of IPv6 space with prefixes shorter than /64 is indeed a 
consideration for bigger administrative domains like country 
governments, but on the other end, SOHO customers would be happy with 
/96, /104 or even /112 allocations if they could get them.  (Just how 
many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs 
have?)  I would *not* like to see "us" make the same mistake with IPv6 
that was made with IPv4, handing out large blocks of space like so many 
pieces of M&M or Skittles candy.

Re: ATT Microcell in Austin, TX

[Stephen Satchell]

There is power backup and then there is power backup.

The former is a small power pack (batteries, supercapacitors, whatever) 
that will allow the microcell to weather a short blackout or brownout. 
We are talking seconds, to bridge switching transits.  To be useful in a 
deployment, such a holdover battery needs to be very low maintenance. 
(Think about cars that use supercapacitors as a battery replacement -- 
good for short needs like a single engine start.)


The latter is longer-life power to keep the microcell going for days or 
weeks.  It's debatable whether this is mandatory.

Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

[Stephen Satchell]

On 3/8/20 9:59 AM, Damian Menscher via NANOG wrote:

In the robocall case, there*is*  something the end user can do to fight the
abuse: answer every call, and keep them on the line as long as possible.
They are paying for connected calls, for the connection duration, and for
the humans to scam people.  If everyone tarpitted them, the business model
would fail.


+1

When I recognize the name and number on caller ID, I'll answer in the 
usual manner.


I answer calls when I don't recognize the name or number, but say 
nothing.  The caller then drops the connection, usually in 10 seconds -- 
and I hear the disconnect -- and usually my cordless phone's base 
station notices the disconnect as well.  (Yes, I still have a standard 
POTS line.)


What if it's an unknown person but otherwise valid and not robo-call? 
They will notice the ringback tone stopping and will say "Hello, hello?" 
at which point I can have a conversation.  (Some robocallers will notice 
the ringback tone stopping and start their automated spew, at which 
point I press "Off.")


This helps keep my blood pressure low, keeps my answering machine from 
filling up with useless calls, and I feel good that someone just spent a 
nickle for nothing.

Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

[Stephen Satchell]

On 3/8/20 4:00 PM, b...@theworld.com wrote:

As I've said before what would likely work is if every time one of us
(in the US anyhow) got a junk call we immediately called our
congressional and/or senate office(s) and simply said "just got
another junk call! (optionally add description.)"


Doesn't work.  I've been complaining both House and Senate offices every 
time CMS (Medicare billing arm) overcharges me $800 for my premiums. 
It's to the point that my elected officials will listen, then say "write 
a letter" (which I have done several times) and blow me off.


Nothing ever gets fixed.

BBB has told me they don't take complaints about government entities.

Re: Abuse Desks

[Stephen Satchell]

On 4/29/20 8:41 AM, Mel Beckman wrote:

Is there any reason to have a root-enabled (or any) ssh server
exposed to the bare Internet? Any at all? Can you name one? I can’t.
That’s basically pilot error.


Remember HeartBleed?  That didn't require a rout-enabled SSH server.  It 
didn't require SSH server.


That said, I use TCPWRAPPER to limit access to SSH to specific IP 
addresses.  I process my LogWatch messages manually.  I pull the fire 
alarm for showshoe probes, and excessive number of probes (over 30 in a 
24-hour period).  No registered abuse@ address in the WHOIS?  The 
offending netblock goes into my edge router ACL, because I have learned 
that ne'er-do-wells without working abuse@ usually have other bad habits.


And I disclose this practice to all who use my network.

(Blackmail emails are another set-and-forget trigger, but that's a 
subject for NANAE newsgroup.)

Re: Abuse Desks

[Stephen Satchell]

On 4/29/20 9:24 AM, Mukund Sivaraman wrote:

If there's a lock on my door, and someone tries to pick it, you can call
me at fault for having a lock on my door facing outside all you
want. But the thief picking it has no business doing so, and will be
guilty of a crime if caught.


This is a good start to an analogy.  Let's build on it, courtesy to 
YouTube's "Lock Picking Lawyer".  In a video, the host shows how to 
improve the security of a common easily-picked home lock: drill holes in 
the lock body, such that if someone picks the lock and tries to turn the 
keyway, the pins will fall into those carefully-placed holes and foil 
The Bad Guy(tm).


In the networking world, we use an Access Control List to limit access 
to the service.  Unlike the simple modification shown in LPL's video, 
the "lock" is still usable by users from authorized IP addresses.  Or, 
we require the use of certificates to validate access within the SSHD 
server itself.


Here's the deal:  just blocking access or requiring certificate-based 
access is intrusion prevention.  Having a log event when there are 
unsuccessful probes is intrusion [attempt] detection.  Sure, the 
ne'er-do-well is kept out in the prevention cycle, but a persistent 
cracker lives by the axiom "if at first you don't succeed, try something 
else."  You really want to stop an attacker from making a large number 
of attempts, such as with a Joe script.


I turn off root SSH access, pinhole 22/tcp to a limited number of IP 
addresses, and monitor failed SUDO attempts.  As I build up my new 
firewall, I'll turn off public SSH access completely, and instead use a 
robust VPN implementation.  (Which has its own issues.)

Re: Abuse Desks

[Stephen Satchell]

On 4/29/20 9:57 AM, Mike Hammett wrote:

My routers have ACLs, but my servers for the most part do not.


I'm not trying to argue, but...what servers do you have that don't have 
sysadmin-definable firewalls and tun-able knobs?  My edge routers are 
Linux boxes (CentOS 8 for the one I'm now building).  Moreover, I can 
have NetworkManager fire off a script that modifies the firewall 
settings as interfaces go up and down.



It's kind of counter productive to put ACLs on SMTP, POP3, IMAP, and
HTTP\S ports, now isn't it? SIP, FTP, and SSH may or may not make
sense, depending on the type and volume of users.
I was taught by my networking betters that you need to block certain 
types of public inbound packets, always, that match any of:


1.  WAN packets with local/LAN source address
2.  WAN packets with local/LAN broadcast/net src-dst address
3.  WAN packets with known broadcast/net src-dst address
4.  WAN packets with local/LAN small services
5.  WAN packets with local/LAN unimplemented services
6.  WAN packets with blackholed source address

On EVERY device with a public IP address.  WITHOUT FAIL.

I have these blocks on every single public-facing mail server I build. 
I have these blocks on every single public-facing Web server I build. 
Indeed, I can't fathom why I would *not* have these in place for every 
single public-facing device.  I don't necessarily log every occurance, 
but I do drop matching packets on the floor, unceremoniously.


This is the foundation upon which I build custom additions, such as 
allowing 22/tcp only from specific IP addresses.


I don't depend on the edge router to catch all the cases, because each 
server has specific services it provides.  So, for example, my DNS 
servers not only implement all six basics, but also incorporates request 
rate limiting, to avoid participating in DDOS events.  Ditto NTP 
servers.  80/tcp and 443/tcp?  Dropped on the floor.


Sorry to preach, but I'm in the process of building a NFTABLE-based 
firewall and this happens to be part of the specs for it.

Re: Mystery CDN

[Stephen Satchell]

On 6/17/20 8:29 AM, Clinton Work wrote:

I'm struggling to determine which CDN owns the servers in CenturyLink prefix 
8.240.0.0/12.   During the Call of Duty Season 4 update on June 11th from 06:00 
UTC until 08:30 UTC, we had 240 Gbps of traffic steaming into our network from 
CenturyLink prefix 8.240.0.0/12.   We originally thought it was Akamai, but 
they swear up and down that the servers don't belong to them.

Here are some of the HTTP/HTTPS servers in 8.240.0.0/12:
8.253.151.248
8.251.135.126
8.240.167.126
8.240.228.126
8.240.168.126
8.240.126.254
8.240.191.254


You might ask Level3.

Re: The great Netflix vpn debacle! (geofeeds)

[Stephen Satchell]

On 9/3/21 6:54 AM, Mark Tinka wrote:
Everyone that I know who spends most of their time writing code can't 
get enough screens :-).


Size matters, too.  For example, I have a 54" screen.  My record is 
twelve open (tiled) code windows.  Usually, I have three or four code 
windows and a LibreWriter window with the specifiations and requirements.

Re: Never push the Big Red Button

[Stephen Satchell]

In the data centers I've worked in over the decades, those Big Red 
Buttons would activate a normally-closed contactor in a breaker panel. 
When pushed, the contactor would open, and turn off all the circults in 
said breaker panel.  Not affected are lights, convenience outlets, door 
locks, and other non-data loads.  Resetting the contactor to the working 
position was done after throwing all the breakers to the off position, 
and then turn on each breaker, one at a time.


The only noise that I have ever heard when the Big Red Button was pushed 
was the loud BANG as the contactor operated.  You hear a similar bang in 
movies in scenes where lights in a large area are turned on and off.


Nothing like the BANG of a 600-amp 3-phase breaker tripping -- 
experienced that at University of Illinois Center for Advanced 
Computation.  You immediately look for the person holding a gun.

Re: IPv6 woes - RFC

[Stephen Satchell]

I concur that the problem is not a routing hardware problem.  It's a 
perception problem with the various ISPs.  I have fiber service with AT&T.


My little server farm endpoints all have IPv6 addresses, including the 
edge router.  I also have a plan to allocate IPv6 addresses to my LAN 
devices, and to protect the LAN devices from outside interference by 
rules in the NFTABLES firewall that include connection tracking on 
outbound requests.  (IPv4 will still use NAT to keep nefarious people 
from probing my internals.)


Specifically, when I was doing my mail server refresh (moving from Red 
Hat to Canonical) I decided it was time to offer IPv6 connectivity in 
the mail server to "future proof" my setup.  That included adding  
records in my DNS zone files.  Failure!  The issues:


1.  I learned that there are no "static addresses" in IPv6, as far as 
AT&T was concerned.  By all appearances, though, the IPv6 /64 is 
relatively static, for now, similar to the way that early cable modem 
deployments kept the same IPv4 addresses.  (Until the cable people 
started forcing changes on DHCP lease renewal, that is.)


2.  My request for PTR records was denied, which means I can't satisfy 
Best Practices for a mail server in the IPv6 space.  No PTR records, no 
redirection of ip6.apra space, nothing.  I include AT&T's refusal below.


3.  I don't know how to get an IPv6 allocation from ARIN, how to request 
AT&T to route it, or how to deal with the DNS server issues.  Oh, I know 
how to configure BIND9; I would prefer using a 24/7/365 provider.  For 
example, my master zone files are with Register.com, so if my circuit 
goes down the name resolution still happens.  Register.com appears not 
to provide reverse-DNS PTR zone support (in6.arpa).  A Google search 
turned up NOTHING for in6.arpa hosting.


That tells me that IPv6 is not "Internet Ready" for small users.  Given 
the level of FU responses I get trying to work with it, I will stop 
banging my head against the wall.


So I stick with IPv4, because that will be the "standard" until the day 
I die, as far as I can tell.


(I removed the  record, so as not to confuse mail server that DO 
operate IPv6.)



Subject: RE: Need IPv6 PTR record for my IPv6 mail server
Date: Mon, 19 Jul 2021 12:52:53 +
From: Prov-DNS 
To: Prov-DNS , a...@satchell.net 


Hello 
We don't process DNS request on IPv6 addresses. We only process DNS

request on IPv4 static assigned addresses.  If you would like us to
process a DNS request for you on a IPv4 address please provide the
following information.

IPv4 address you would like the record created for Host name you would > like that IP address pointed to 

>

Thanks
Michael AT&T Prov-DNS

-Original Message-
From: Stephen Satchell 
Sent: Friday, July 16, 2021 5:42 PM
To: DNSUpdates cB 
Subject: Need IPv6 PTR record for my IPv6 mail server

Here is the record I need inserted into your ip6.arpa DNS zone:



2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. 0 
IN PTR smtp.satchell.net.


This is the result from the question section of a dig(1) request for the PTR 
record for my IPv6 address 2600:1700:79b0:ddc0::32, and the fully-qualified 
domain name of the server.

You can verify the information using dig smtp.satchell.net  and 
checking the reverse.


This is the only server in my collection that needs the IPv6 pointer.

Re: IPv6 woes - RFC

[Stephen Satchell]

On 9/18/21 8:58 PM, Owen DeLong wrote:

I haven’t tried the PTR thing yet, but I do have a small business client that has 
AT&T business internet and they were able to get a static /56 (For some reason, 
AT&T refused to do a /48, but we did push them on it.)


When I checked, there were NO options for ANY static IPv6.  Perhaps the 
devil is in the details of my particular "business Internet" package. 
If "package" is the right term; I use them only for upstream 
connectivity and rental of IP (and IPv6) addresses.


If it turns out they won’t do PTR or more likely NS for our ip6.arpa zone, then we’ll probably start looking for an alternative provider 


That's the problem with a facilities-based ISP, there are no alternative 
providers.  Oh, sure, I could get Spectrum here.  Indeed, I had a 
circuit: when I had their business service I had even more problems with 
them than I do with this one.



or get an HE /48 over a tunnel which will do PTR or NS records appropriately.


Hurricane Electric?  Seriously?  I had them when I was working at a web 
host company quite a while ago.  Have they improved their service desk? 
The downside is that I would have a serial pair of points of failure for 
my connectivity.


IPv6 was supposed to SOLVE the problems, not create more problems.

I look back longingly to that product from the 80s:  Internet-in-a-box.

I also remember the birth of Interop, when I visited Telebit at a 
session to work out the interoperability snags in PPP implementations 
among a handful of vendors.

Re: IPv6 woes - RFC

[Stephen Satchell]

On 9/18/21 11:20 PM, Masataka Ohta wrote:

Mark Andrews wrote:

 > There is nothing at the protocol level stopping AT&T offering a
 > similar level of service.

Setting up reverse DNS lookup for 16B address is annoying,
which may stop AT&T offering it.


How many mail servers are on the Internet today?  I don't know.  How  
many business customers (large and small) does AT&T have?  I don't know,  
and don't expect ever to know.  I assume by "16B" you mean "16 billion";  
if so, why did you select that value?


Based on the routing tables on my edge router for my existing  
connection-based allocation, I have a IPv6 address block with a /60  
prefix.  The AT&T SBCIS allocation for IPv6 is 2600:1700::/28  
(4.294.967.296 /60 prefixes), and the parent range is /12.  (In a prior  
message, someone mentioned that their customer was able to obtain a  
static /56 IPv6 address block.  Don't know how they did that, unless  
they are tunneling to a different provider like HE.)


AT&T does offer PTR records for IPv4 static addresses -- I have a set of  
static IPv4 addresses (which I pay for monthly) and one associated  
IN-ADDR.ARPA PTR record.  (I used to have *two* sets of static IP IPv4  
addresses -- both paid for monthly -- and two associated IN-ADDR.ARPA  
PTR records, but I released one of those sets when I discontinued my  
long-time DSL service with AT&T.)


From the AT&T community forum, from two years ago, a moderator says  
this:  "IPv6 Its [sic] are assigned to your connection; IPv4 static IP  
blocks are assigned to you. This is why they still don't offer reverse  
PTR delegation."


What's missing?  A static prefix of IPv6, and one IP6.ARPA PTR record.  
I'm willing to pay for IPv6 static addresses, as long as I can get the  
one IP6.ARPA PTR record for my mail server.  Connection-based prefix  
would be fine, but I still need the PTR record to satisfy the Best  
Practices requirements for mail servers.


(Why do I run my own mail server?  When I started out with DSL many  
years ago, I used Pacific Bell's mail servers.  The IP reputation was to  
the point that mail from my systems was blocked by so many mail servers  
around the 'Net.  So, Postfix locally.  Never looked back.)

Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland)

[Stephen Satchell]

On 3/18/19 11:17 PM, Ronald F. Guilmette wrote:
> I am not sure that there is any other way that a lone outsider can or
> could engage either OVH or DigitalOcean in a way that would actually
> cause either company to take action on the issues I've reported on.
> Complaints from ordinary Internet end-lusers about this, which both
> companies must surely be drowing in by now, don't seem to be doing the
> job.
> 

I have sent reports to DigitalOcean and Microsoft about the abuse
reported to me that appears on my network.  The only response I'm
interested in is the end of said abuse.

When abuse continues to be seen on a DigitalOcean allocation, that
allocation goes into a file-and-forget ACL.

I investigate further only when a customer reports a problem connecting
with a DigitalOcean netblock.  No such reports yet, by the way.

I respond to abuse reports promptly and completely.  I expect others to
do so, just as promptly and completely.  "Pretty please" is not in my
netadmin vocabulary.

Re: GPS WNRO April 6th at GPS Midnight

[Stephen Satchell]

On 4/3/19 3:32 PM, brutal8z via NANOG wrote:
> I've not seen any mention of this here, so it might be off-topic, if so,
> sorry in advance. If you use GPS for time synchronization, this might be
> important.The Juniper ACX500 series and the Cisco 819 both have an
> embedded GPS receivers, for example.
> 
> At 23:59:42 UTC on 4/6/2019 (Midnight GPS time, which differs by 18
> leap-seconds  from UTC) , the
> 10-bit GPS Week Number broadcast by the constellation will reset to zero
> for the second time since the beginning of GPS on 1/6/1980.

There was a mention of this a couple of weeks ago, as a "heads-up".

When it first appeared up here, I checked with the vendor of my GPS time
appliances.  The vendor told me that the testing they did of their
product showed no issues with the roll-over for specific ranges of
serial numbers.  Mine is within one of the ranges.

The proof of the pudding will be what happens at 5pm PDT on my birthday,
April 6, and what ntpq reports on my edge server.

Re: Comcast storing WiFi passwords in cleartext?

[Stephen Satchell]

On 4/24/19 7:24 AM, Tom Beecher wrote:
> This is why, in my opinion, people should avoid modem/router combo units
> whenever possible. Any information/configuration entered into such a device
> could be accessible to the MSO (intentionally or otherwise) , as is
> happening here. I'm sure they would come back and say this is necessary to
> provide support for customers who pay them for WiFi service, but it clearly
> shows they don't turn off that functionality for customers who don't.
> 
> Treat you cable modems as foreign network elements. Cause that's what they
> are.

+1.  Encountered this with an AT&T install.  AT&T provided router/wifi
combo.  After the installer was done, first thing I did was to turn the
combo's wifi off, and hook up the access point the customer has been
using for years.  Verified that the MAC filtering was still correct
during the post-install.  Customer is happy.

The next step is to build a Protectli firewall to go between the AT&T
modem and the access point.  Block any chance of AT&T using SNMP to
sniff the access point.  (Moved the Access Point's IP address for
management and gateway, too.)

Re: Comcast storing WiFi passwords in cleartext?

[Stephen Satchell]

On 4/24/19 9:32 PM, Mike Bolitho wrote:
>>
>> "than the relatively low risk of a database compromise leading to a
>> miscreant getting ahold of their wireless password and using their access
>> point as free wifi."
>>
> 
> And this is the thing, not only does someone have to 'hack' the database,
> they also need to drive up to your house and sit in your driveway to get
> free Internet. Of all the things to worry about, this is way down on my
> list.

Sounds like you live in a single-family home, in a low-density
neighborhood.  I live in an apartment complex, and WiFi Analyzer shows
more than 20 beacons visible from my kitchen.  Before I implemented MAC
filtering, my DHCP server logs showed connections by rogue equipment.
(And before you ask, my password is not a simple one.)

When I leave town for an extended period, I pull the plug on the wireless.

In an industrial park, I see the same dense tangle of beacons.  Let
alone those wireless systems that have disabled beacons.

If that database of wireless passwords also has the physical location of
the device, then the risks go up.

So the simple solution is to use your own AP, block SNMP access from the
worlds at your edge router, and the risk falls to zero.

Re: NTP question

[Stephen Satchell]

One word of caution when using a low-priced NTP appliance: your network
activity could overwhelm the TCP/IP stack of the poor thing, especially
if you want to sync your entire shop to it.  In the case of the networks
I set up, I set up a VLAN specific to the NTP appliance and to the two
servers that sync up with it.  Everything else in the network is
configured to talk to the two servers, but NOT on the three-device "NTP
Appliance VLAN".

NOTE: Don't depend on the appliance to provide VLAN capability; use a
configuration in a connected switch.  How you wire from the appliance to
a port on your network leaves you with a lot of options to reach a
window with good satellite visibility, as CAT 5 at 10 megabits/s can
extend a long way successfully.  Watch your cable dress, particularly
splices and runs against metal. (Or through rooms with MRI machines --
I'm not joking.)

The two servers in question also sync up with NTP servers in the cloud
using whatever baseband or VLANs (other than the "NTP VLAN") you
configure.  Ditto clients using the two servers as time sources.

The goal here is to minimize the amount of traffic in the "NTP Appliance
VLAN".  What killed one installation I did was the huge amount of ARP
traffic that the appliance had to discard; it wasn't up to the deluge.

Learn from my mistakes.

Re: Charter and Cox contacts

[Stephen Satchell]

On 5/13/19 12:11 PM, dan...@pyranah.com wrote:
> Does anyone have contacts at Charter (Spectrum) and Cox? For some reason,
> our IP has been blocked by them and our customers are unable to send email
> via their charter/cox accounts. Thanks


Would you be talking about port 25/tcp outbound?  Lots of ISPs will
block port 25 as a rule; you have to call to have it opened.  At the
same time, you can request the PTR record you need to keep big mail
receivers happy.

Re: CloudFlare issues?

[Stephen Satchell]

On 6/25/19 2:25 AM, Katie Holly wrote:
> Disclaimer: As much as I dislike Cloudflare (I used to complain about
> them a lot on Twitter), this is something I am absolutely agreeing with
> them. Verizon failed to do the most basic of network security, and it
> will happen again, and again, and again...

I used to be a quality control engineer in my career, so I have a
question to ask from the perspective of a QC guy:  what is the Best
Practice for minimizing, if not totally preventing, this sort of
problem?  Is there a "cookbook" answer to this?

(I only run edge networks now, and don't have BGP to worry about.  If my
current $dayjob goes away -- they all do -- I might have to get back
into the BGP game, so this is not an idle query.)

Somehow "just be careful and clueful" isn't the right answer.

Re: FCC workshop: Security vulnerabilities within our communications networks

[Stephen Satchell]

On 6/26/19 2:17 PM, Scott Weeks wrote:
> 
> --- s...@donelan.com wrote:
> From: Sean Donelan 
> 
> If they come up with a better idea, that's great.  I'll 
> take good ideas  from anywere.

In my experience, "design by committee" is most successful when one or
two people take the bull by the horns and flesh out a solution, and the
rest of the bunch nod their heads and say, "Huzza".

Intermittent "bad gateway"

[Stephen Satchell]

Are we having another BGP problem this morning?

Re: 44/8

[Stephen Satchell]

On 7/22/19 12:15 PM, Naslund, Steve wrote:
> 1.  A lot of existing code base does not know how to handle those
> addresses and may refuse to route them or will otherwise mishandle
> them.

Not to mention all the legacy devices that barely do IPv4 at all, and
know nothing about IPv6.  Legacy devices that are orphaned by their
developing companies going out of busiess or dropping all support for
the products.

I'm looking at YOU, MasterSwitch.

Re: Feasibility of using Class E space for public unicast (was re: 44/8)

[Stephen Satchell]

On 7/27/19 2:18 PM, Randy Bush wrote:
> something is broken on the nanog list.  usually we have this discussion
> twice a year.  this time it may have been a couple of years gap.  what
> broke?


44/8.  Sucked up all the oxygen.

Re: really amazon?

[Stephen Satchell]

On 7/31/19 12:04 PM, Valdis Klētnieks wrote:
> On Wed, 31 Jul 2019 16:36:08 -, Richard Williams via NANOG said:
> 
>>  To contact AWS SES about spam or abuse the correct email address is 
>> ab...@amazonaws.com
> 
> You know that, and I know that, but why doesn't the person at AWS whose job it
> is to keep the ARIN info correct and up to date know that?

C'mon, you already know the answer to this:  there is no such person.
Someone gets a mail once a year and MIGHT, JUST MIGHT, pass it on to
someone who knows what to do.

Re: really amazon?

[Stephen Satchell]

On 7/31/19 1:28 PM, Brian J. Murrell wrote:
> On Wed, 2019-07-31 at 23:13 +0300, Scott Christopher wrote:
>>
>> Because it will get spammed if publicly listed in WHOIS.
> 
> I will take that at *least* as ironic as you meant it.

I don't know about your network, but I have five role mail accounts, and
all five get spam, even with spam filters enabled.  Oh, forgot about
abuse@, which has no filter but LOTS of spam.  What's fun is to let it
sit a couple of days, then sort by subject.  Delete the "conversations".

That gets down to the zero or one piece of ham.  But then again, I've
locked down my network so abuse doesn't get out, even when someone
manages to get by the MAC filters on the wireless router.

Re: User Unknown (WAS: really amazon?)

[Stephen Satchell]

On 8/3/19 9:15 PM, John Curran wrote:
> As I have noted previously, I have zero doubt in the enforceability
> of the ARIN registration services agreements in this regard – so
> please carefully consider proposed policy both from the overall
> community benefit being sought, and from the implications faced as a
> number resource holder having to comply oneself with the new
> obligations.

Actually, I would re-write the last part of the last sentence as "...and
from the implications faced as a number resource holder having to comply
oneself with the long-standing and well-known obligations of all network
operators."

I'm a small network operator that has been around and following "the
rules" for many years.  I do understand why you are constrained by the
legal authority you have.  In some respects, I (and others) pine for the
old NSFNET days, when negligence -- particularly willful negligence --
was rewarded with disconnection.

"The rules" have been around for years, and are codified in the RFCs
that are widely published and available to all at zero cost.  (That
wasn't always true, as it wasn't until the DDN Protocol Handbook volumes
were published in 1985 that the RFCs were available to everyone.  I seem
to recall there was an FTP site that provided the RFC documents before
that, but my memory is hazy on that.)  I had access to all the RFCs at
the University of Illinois Center for Advanced Computation, as I was
working at the place as a worker on ARPAnet.

During my career as a web server admin, mail admin, and network admin, I
followed "the rules" strictly.   As the main abuse contact during my
time at a web hosting company, my postmaster@ and abuse@ contact
addresses were according to Hoyle, and published with the company ASN,
netblock, and domain registration records.  It took a little convincing
for the owner of the shop to buy in, and to back up my responses to
abuse reports.

I would have expected any ARIN contracts to include by reference the
RFCs that constituted "the rules".  I have never seen the contracts, so
I don't know how they are formulated.  That said, I would have expected
legacy space to fall under "the rules", particularly with respect to
role electronic mail addresses.

I don't have a dog in this fight.  Currently, I don't "own" any IPv4
address space, nor am I running BGP.

Re: User Unknown (WAS: really amazon?)

[Stephen Satchell]

On 8/9/19 4:03 PM, Matthew Petach wrote:
> ...apparently Amazon has become a public utility
> now?
> 
> I look forward with bemusement to the PUC
> tariff filings for AWS pricing.  ^_^;;

Don't scoff too hard.  How do you think that telephone service became a
utility?  Utilities didn't grow on trees, they became utilities when
some bureaucrats convinced legislators to "promote" successful service
providers to utility status.  Especially when such providers are
providing a service as a monopoly.  Particularly a "natural" monopoly.
AWS has competitors,  but if the number of providers remains small (like
fingers of one hand) the politicians wil step in.

And it wouldn't be the PUC, as Amazon is a company national in scope.
It would be something like the FCC.  Public Utility Commissions are at
the local (usually county) or state level.

Re: User Unknown (WAS: really amazon?)

[Stephen Satchell]

On 8/13/19 3:10 PM, Matthew Petach wrote:
> With a global company, there's no such thing
> as a local natural monopoly in play; how would
> you assign oversight to a global entity?  Which
> "public" would be the ones being protected?
> The city of Seattle, WA, where Amazon is
> headquartered?  The State of Washington?
> The United States, at a federal level?   What
> about the "public" that uses Amazon in all
> the other countries of the world?

Consider how radio, television, and telephony grew and became regulated.
 (For a moment there, it felt like a discussion that I would have on the
CyberTelecomm mailing list.)  Each country would regulate the monopoly
in the manner best suited for that country.  Amazon would need to set up
divisions in each country, or union of countries such as the EU.

> There's no way to make a global entity a
> regulated public utility; we don't have an
> organization that has that level of oversight
> across country boundaries, unless you start
> thinking about entities that can enforce *treaties*
> between countries.

Actually, you'd be surprised to learn we already have infrastructure in
place to do exactly that.  The International Telecommunication Union is
a fine example of how this could be done.  Study up on it.  From my
experience in the telco and modem world, the individual countries have
working parties for each element.  The working parties develop Standards
(the initial cap is intentional) within each country.  The output from
the working parties in each country send their recommendations to a
government bureau -- in the United States, that would be a working party
associated with the State Department.  (For example, my work on in-band
modem control went through TIA/EIA TR-29, which then was passed on to
Study Group D, which went to the ITU.)

> And I'm not sure I'd want our Ambassadors
> being the ones at the table deciding how best
> to regulate Amazon.   :/

That's just the point.  The regulation would *not* be done by
ambassadors.  The treaties, rule, regulations, and procedures are
*already* in place to smooth the process through people that are not
political appointees.

Regulation of Amazon would probably be broken into parts: technical,
policy, managment, auditing, perhaps more.  Policy would originate in
the USA with Congress, with help from the industry.  Other parts would
be parceled out to the people better (not necessarily the best) equipped
to do the job.

And that's my pair-o-pennies on the subject.  Other people may have
differing opinions.

DNS cache hold of SERVFAIL responses

[Stephen Satchell]

This is for any Google admin on this list:

When you receive a SERVFAIL from a name server listed as authoritative
for a given domain, how long is that negative look-up cached?

When you receive a SERVFAIL from the root servers, how long is that
negative lookup cached?

Does Google follow RFC 2308?

Is there a common cache for all resolvers, or do each resolver in your
DNS server corps maintain a local cache?

When a SOA (when you see one) says 14400 for the minimum TTL (or
negative cache TTL) does Google honor that hold time?

Re: Weekly Routing Table Report

[Stephen Satchell]

On 9/2/19 4:40 PM, Seth Mattinen wrote:
> May the world come to an end if someone dares to have an independent 
> thought or shares original information that can't be backed up by at 
> least 50 crosschecked references.
Actually, independent thought or original information is welcome to
anyone with a brain, as long as the author shows his/her work such that
it can be verified and reproduced by others.  You don't need a ton of
references to the work (and conclusions) of others if you do a complete
job yourself.

There is a reason for the joke publication _The Journal of
Irreproducible Results_, started in 1955.  So many "scientific"
publications have this little tiny problem: no one can duplicate the work.

Re: Elad Cohen, show us!

[Stephen Satchell]

On 9/19/19 2:47 AM, Elad Cohen wrote:
> It is not related to nefarious activity as you wrote, FDCServers
> policy is to stop routing any ranges which is in Spamhaus SBL (no
> matter what), due to the phear from Spamhaus to list all of
> FDCServers ranges in SBL, which was told to us in a documented phone
> call, listing all of the ranges by Spamhaus is a known agrressive and
> bullying tactic by Spamhaus as you can find in many webpages online.
Do you think Spamhaus uses "aggressive and bullying tactic[s]"?  You
never lived under the sword of SPEWS.

> https://en.wikipedia.org/wiki/Spam_Prevention_Early_Warning_System

As a former abuse and mail admin in a web hosting company with (at the
time) 3000 domains serviced, I found Spamhaus to be a firm but fair
organization.  Respond quickly and effectively to abuse complaints,
stoping the spam flow, Spamhaus delisted -- sometimes without being
asked to.

Note: this list is of and for network operators.  Spamhaus and other
DNSBLs are the subject for a mailing list of and for mail admins.

Elad Cohen, show us!

[Stephen Satchell]

On 9/19/19 2:47 AM, Elad Cohen wrote:
> It is not related to nefarious activity as you wrote, FDCServers
> policy is to stop routing any ranges which is in Spamhaus SBL (no
> matter what), due to the phear from Spamhaus to list all of
> FDCServers ranges in SBL, which was told to us in a documented phone
> call, listing all of the ranges by Spamhaus is a known agrressive and
> bullying tactic by Spamhaus as you can find in many webpages online.
Do you think Spamhaus uses "aggressive and bullying tactic[s]"?  You
never lived under the sword of SPEWS.

> https://en.wikipedia.org/wiki/Spam_Prevention_Early_Warning_System

As a former abuse and mail admin in a web hosting company with (at the
time) 3000 domains serviced, I found Spamhaus to be a firm but fair
organization.  Respond quickly and effectively to abuse complaints,
stoping the spam flow, Spamhaus delisted -- sometimes without being
asked to.

Note: this list is of and for network operators.  Spamhaus and other
DNSBLs are the subject for a mailing list of and for mail admins.

Re: IPv6 Thought Experiment

[Stephen Satchell]

On 10/2/19 9:33 AM, Antonios Chariton wrote:
> Dear list,
> First of all, let me apologize if this post is not allowed by the
> list. To my best interpretation of the guidelines [1] it is allowed, but
> may be in a gray area due to rule #7.
> 
> I would like to propose the following thought experiment about IPv6,
> and I would like your opinion on what you believe would happen in such a
> case. Feel free to reply on or off list.
> 
> What if, globally, and starting at January 1st, 2020, someone 
> (imagine a government or similar, but with global reach) imposed an 
> IPv4 tax. For every IPv4 address on the Global Internet Routing
> Table, you had to pay a tax. Let’s assume that this can be imposed,
> must be paid, and cannot be avoided using some loophole. Let’s say
> that this tax would be $2, and it would double, every 3 or 6 months.

Who exactly would be paying this tax?  The IPv4 address "owner"?  The
SWIP?  The end user who gets IPv4 via DHCP from his provider?

Tax paid to whom?

> What do you think would happen? Would it be the only way to reach 
> 100% IPv6 deployment, or even that wouldn’t be sufficient?
Well, a lot of money would change hands.  Somebody would be enriched by
the tax revenues.

> And for bonus points, consider the following: what if all
> certification bodies of equipment, for certifications like FCC’s or CE
> in Europe, for applications after Jan 1st 2023 would include a “MUST
> NOT support IPv4”..

So how would that affect users trying to access IPv4 resources?

> What I am trying to understand is whether deploying IPv6 is a pure
> financial problem. If it is, in this scenario, it would very very soon
> become much more pricey to not deploy it.

First, there are equipment issues -- not all gear "plays nice" with
IPv6, especially older gear still in use.  There is a capital cost
associated with upgrading gear, and not all organizations and people can
afford the hit.

There are policies in place, beyond the RFCs, by companies and
governments that would need to be updated, and the tax you suggest
doesn't even begin to attack the problems.

> I know there are a lot of gaps in this, for example who imposes this,
> what is the "Global Internet Routing Table", etc. but let’s try to
> see around them, to the core idea behind them.
Has BCP-38 been updated to include IPv6?
https://tools.ietf.org/html/bcp38

All the examples are IPv4.  Additionally, one of the reference is this:
Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.

If people are serious about IPv6, isn't it time to update the Best
Practices documents, particularly BCP-38 et al, to address IPv6 as well
as IPv4?

Update to BCP-38?

[Stephen Satchell]

Is anyone working on an update to include IPv6?

Re: Update to BCP-38?

[Stephen Satchell]

On 10/2/19 9:51 PM, Mark Andrews wrote:
> What part of BCP-38 do you think needs to be updated to support IPv6?
> 
> Changing the examples to use IPv6 documentation prefixes instead of IPv4
> documentation prefixes?

For a start, *add* IPv6 examples in parallel with the IPv4 examples.  As
RFCs are peer reviewed, if the examples expose a hole or problem then
the hole can be filled or the problem resolved.

BCP-38 should be reviewed in whole for "IPv6" completeness, and the
preamble of BCP-38 add that the Best Practices include complete
recommendations for both IPv4 and IPv6.

One specific example:

BCP-38 currently references RFC1812, _Requirements for IP Version 4
Routers_.

It appears that the only parallel paper for IPv6 is
draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which
currently carries a copyright of 2018.  It's a shame that this document
is still in limbo; witness this quote:  "It is inappropriate to use
Internet-Drafts as reference material or to cite them other than as
'work in progress.'

Someone else mentioned that "IPv6 has been around for 25 years, and why
is it taking so long for everyone to adopt it?"  I present as evidence
the lack of a formally-released requirements RFC for IPv6.  It suggests
that the "science" of IPv6 is not "settled" yet.  That puts the
deployment of IPv6 in the category of "experiment" and not "production".

Is that really true?

There may be more issues.  And, yes, I understand that a new BCP paper
may result -- I don't care how it's labeled, as long as it's done.  Or
has such a BCP document already been released?  If so, why do I not see
any references to it here on NANOG, or anywhere else?

Why do I care, you ask.  I'm working on a BCP-38 module proposal for
firewalld, one that can be peer-reviewed for accuracy and completeness.
Servers running that firewall package can then be easily configured to
conform to the requirements of BCP-38 and can easily become good
net-citizens in their own right.

So I call for draft-ietf-v6ops-ipv6rtr-reqs-04 to be finished and
released as a formal RFC, and that BCP-38 be updated to refer to that
finished RFC.

Until that is done, my BCP-38 module will have to carry a "work in
progress" disclaimer.

Re: Update to BCP-38?

[Stephen Satchell]

On 10/3/19 8:42 AM, Fred Baker wrote:
> 
> 
>> On Oct 3, 2019, at 9:51 AM, Stephen Satchell  wrote:
>>
>> Someone else mentioned that "IPv6 has been around for 25 years, and why
>> is it taking so long for everyone to adopt it?"  I present as evidence
>> the lack of a formally-released requirements RFC for IPv6.  It suggests
>> that the "science" of IPv6 is not "settled" yet.  That puts the
>> deployment of IPv6 in the category of "experiment" and not "production".
> 
> And, of course, we now have companies like T-Mobile and others
> turning IPv4 off. If that's an experiment, wow.
The cellular data industry appears to have embraced IPv6 in one form or
another.  I would expect that the network engineers have done some work
to keep IPv4 off their *internal* networks, but provide IPv4 access at
the edge.  (Isn't a netblock within IPv6 intended to enable bridging to
IPv4?)  The applications on the phon could be configured to search DNS
for  addresses first.

My AT&T cell phone has both IPv4 and IPv6 addresses.  The IPv4 address
is from my access point; the IPv6 address appears to be a public address.

I would like to move to IPv6.  I just don't want to shoot myself in the
foot, or cause trouble for other people, by being sure my edge router
"follows all the rules."

Re: Update to BCP-38?

[Stephen Satchell]

On 10/3/19 8:22 AM, Fred Baker wrote:
> Speaking as v6ops chair and the editor of record for 1812.
> draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be
> an 1812-like document and adopted as such, but many of the
> "requirements" that came out of it were specific to the author's
> operation and not common to other operators. So it ultimately didn't happen.

Sympathies.  I've been involved in Standards-setting committees, so I
know how that works.  Is there any further work being done?  And just
how much of the current draft can be generalized?

> There is no demand until further IPv4 deployment no longer suffices.
> I would say that there was no real market demand until after January
> 2011, and probably 2012 or 2013.>
> At this point, there is fairly wide deployment among the ISP and CDN
> operators, and vendor implementations are fairly complete. Google,
> APNIC, and Akamai report on traffic levels; Google says that they see
> at least 5% of the requests they receive from 61 countries use IPv6,
> and from one country a tad more that half of the requests they
> receive use IPv6.>
> So we see IPv6 in broadband, in ISPs, and in telephone networks. To
> give you an anecdote, my kids have teased me about IPv6 for years,
> and each now have IPv6 service from their various ISPs and telephone
> networks despite themselves - and use it for the majority of their
> accesses.>
> What is visibly lacking is enterprise deployment.

Interesting you should mention that.  One reason I wanted to do an
IPv6-aware BGP-38 module for firewalld was to help break that logjam.
Enterprises are risk-adverse, which is why adoption meets such strong
resistance.

> And on lists like this, I am told that there is no deployment - that
> nobody wants it, and anyone that disagrees with that assessment has
> lost his or her mind. That all leaves me wondering which of us
> doesn't quite have their eye on the ball.
For the reasons you provided in your original message, the learning
curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" --
is steep and uncertain.

And I think you may be misunderstanding the problem.  It's not that
people don't want it.  They lack the zen of it, they don't see the four
corners of the thing, something that people took years to learn in IPv4.
 (I had a leg up, being involved in the original ARPAnet, so I got to
watch it grow.  Still have the 1984 DDN handbooks, too.)

Re: Update to BCP-38?

[Stephen Satchell]

On 10/3/19 2:07 PM, Mark Andrews wrote:
> Now IPv6 examples are nice but getting several 1000’s people to read draft 
> that
> just add addresses in the range 2001:DB8::/32 instead of 11.0.0.0/8, 
> 12.0.0.0/8
> and 204.69.207.0/24, then to get the RFC editor to publish it is quite frankly
> is a waste of time.

Long ago, I was working on Network Graphics Protocol and the draft RFC
for it.  My boss said that I needed to write a couple of paragraphs
about fixed-point binary fractions, which the protocol used, "because
that's not a common thing in the world".  How bad was this?  The person
who was writing the generator of the NGP stream used *floating point*
because that person didn't understand that 7FFF was interpreted as a
bitty-point less than 1.0, and 8001 was a bitty-point less that -1.0
-- and that trying to shoehorn this into IEEE floating-point format
almost worked.  What my poor boss didn't realize is that exactly 1.0 and
-1.0 were not defined.  The specification didn't make that clear.

When I'm doing technical writing, I find all sorts of corner cases that
were missed by the designers and the QA people.  It makes me very
unpopular.  But it also makes for a better product, in the end.

So making everything crystal clear and obvious is definitely not "a
waste of time."  You have no idea what undiscovered bugs may become
obvious when you go through the exercise and show all your work.

You still need a IPv6 version of RFC 1812.  Make it as clean as
possible.  Use an ax instead of a XACTO knife on the current draft.
What is the minimum necessary things that a generic IPv6 router MUST do?

Re: Update to BCP-38?

[Stephen Satchell]

On 10/3/19 10:13 PM, Fred Baker wrote:
> There is one thing in 1122/1123 and 1812 that is not in those kinds
> of documents that I miss; that is essentially "why". Going through
> 1122/1123 and 1812, you'll ind several sections that say "we require
> X", and follow that with a "discussion" section that says "we thought
> about X, Y, and Z, there were proponents of each, the arguments were
> X', Y', and Z', and we chose X for this reason". I would presume that
> what you're really looking for in a 1812-for-IPv6 is not "we require
> X" as much as "for this reason". Correct me if I'm wrong.

Ah.  What I'm looking for is a list of check-boxes to include in an
implementation specification for an edge router.  It can be references
to a whole bunch of RFCs and "packaged" as a BCP.  The discussions you
describe are better in the individual papers.

Side note: I'm used to rationales being included in Standards, and
welcome them, as long as they are normative and clearly marked so.

> I can kick the idea around in the IETF if its important to you. I'll
> be looking for a LOT of operational input.

It could well me that the data is there, we just need a document to
index it all.  That's what I thought a BPC was supposed to be.  It would
be like an article in ACM Computing Surveys, which references the
existing literature, as opposed to being created from whole cloth.

I think I steered everyone wrong when I was talking about some of the
exposition in the text, specifically the examples.  That kind of
material really belongs in an RFC.  My apologies.

Re: IPv6 Pain Experiment

[Stephen Satchell]

On 10/7/19 4:37 AM, Valdis Klētnieks wrote:
> On Mon, 07 Oct 2019 03:03:45 -0400, Rob McEwen said:
>> Likewise for spam filtering - spam filtering would be knocked back to
>> the stone ages if IPv4 disappeared overnight. IPv6 is a spam sender's
>> dream come true, since IPv6 DNSBLs are practically worthless.
> 
> Riddle me this:  Why then have spammers not abandoned IPv4 and moved to
> IPv6 where we're totally powerless to stop their floods of spam?
> 
> I'm tired of hearing the excuse "We can't move to IPv6 because then we 
> couldn't
> stop the spam" - if that were true, then every organization that *has* moved
> to IPv6 would be drowning in spam.

Spammers haven't abandoned IPv4 for IPv6 because some significant
percentage of mail servers are still IPv4 only.  I know mine is, and
will most likely stay that way for the reasons that Rob points out.  Any
link between an IPv6 spammer and an IPv4 mail server would have to
undergo NAT of some form, and the IPv4 address of NAT would then be
subject to blocking action.

The BOFH model from the old NFS days won't work anymore.

Re: dns cache beyond ttl - viasat / exede

[Stephen Satchell]

On 10/7/19 9:08 AM, Mike wrote:
>    I am wondering if perhaps this is due to some kind of (known?)
> bug in the embedded dns cache/client in the client satellite modem, or
> if there is another plausible explanation I am not seeing. It compounds
> my problem slightly since I have to continue running the web sites at
> both the old and new addresses while these things time out I guess and
> it's just inconvenient.

Back when I was the mail/DNS/network admin at a hosting company, and we
would have to renumber, I saw the same thing.  This was back in the days
when the cable companies had small pipes to the Internet.  Their DNS
servers would impose a minimum 1 week TTL on all DNS requests, so that
the vast majority would be resolved "locally" without having to resort
to the root servers.

Other answers point to satellite companies doing something similar, to
combat the long RTD that DNS resolution would require without aggressive
caching.

Almost all of the Web servers I managed used Linux, so I was able to
play games in the firewall to let both numbers get to the Web servers
without having a convoluted configuration in Apache.  The three
Windows/ISS hosts were not that difficult to do, but was tiresome.

Those games stopped when the hosting company got its own /21 allocation.

Re: California public safety power shutdowns

[Stephen Satchell]

On 10/10/19 8:46 PM, Javier J wrote:
> I have an alternative view. the more generators are running, the more
> trucks semt to refuel the tanks, the more moving parts, the more likely an
> accident is prone to happen somewhere. It's thr same reason you turn your
> vehicles engine off when you fill up at the gas station.
> 
> Diesel doesn't combust easily without conpression, but I'm pretty sure you
> can find incidents where diesel engines catch fire. maybe the roof of a
> datacenter is not a risk factor, but in thinking remote antennas on the top
> of a mountain anything can happen.

When I was between jobs in IT, I worked as a security guard for a year.
 During that year, the company I worked for supplied on-prem security
for a bankrupt casino at Lake Tahoe.

When one of the cell phone companies requested access to their equipment
located on the roof of the parking garage (space they leased) the
request went all the way to the Court.  The reason for access?  They ran
the electronics on bottled propane (NOT mains power AC) and they needed
to swap full tanks for the empties.  This was several months into my
stint on that site.

Not all generators run on diesel, I learned.

Re: California public safety power shutdowns

[Stephen Satchell]

On 10/11/19 8:01 AM, Ethan O'Toole wrote:
>> request went all the way to the Court.  The reason for access?  They ran
>> the electronics on bottled propane (NOT mains power AC) and they needed
>> to swap full tanks for the empties.  This was several months into my
>> stint on that site.
>> Not all generators run on diesel, I learned.
> 
> You can drive a gasoline generator with natural gas and propane, there
> is just less energy so it takes more of those fuels to get the same
> energy output.
> 
> There are also fuel cells that take LPG.
> 
> Was this a really tiny microcell? I wouldn't think they could run for
> months on bottled LPG if there is any kind of real load at the site.
> 
>     - Ethan

Not a tiny microcell.  The casino in question is located in Incline
Village, on the shore of Lake Tahoe and in prime ski country.  The
downside of ski country is that you have fairly frequent power outages
in winter due to weather, plus the long haul through mountains of fair
capacity transmission lines.

Now I could be mistaken, and the propane was for a stand-by generator.

Request comment: list of IPs to block outbound

[Stephen Satchell]

The following list is what I'm thinking of using for blocking traffic
between an edge router acting as a firewall and an ISP/upstream.  This
table is limited to address blocks only; TCP/UDP port filtering, and IP
protocol filtering, is a separate discussion.  This is for an
implementation of BCP-38 recommendations.

I'm trying to decide whether the firewall should just blackhole these
addresses in the routing table, or use rules in NFTABLES against source
and destination addresses, or some combination.  If NFTABLES, the best
place to put the blocks (inbound and outbound) would be in the FORWARD
chain, both inbound and outbound.  (N.B. for endpoint boxes, they go
into the OUTPUT chain.)

In trying to research what would constitute "best practice", the papers
I found were outdated, potentially incomplete (particularly with
reference to IPv6), or geared toward other applications.  This table
currently does not have exceptions -- some may need to be added as a
specific "allow" route or list.

The Linux rp_filter knob is effective for endpoint servers and
workstations, and I turn it on religiously (easy because it's the
default).  For a firewall router without blackhole routes, it's less
effective because, for incoming packets, a source address matching one
of your inside netblocks will pass.  A subset of the list would be
useful in endpoint boxes to relieve pressure on the upstream edge router
-- particularly if a ne'er-do-well successfully hijacks the endpoint box
to participate in a DDoS flood.

IPv4
Address block   Scope   Description
0.0.0.0/8   SoftwareCurrent network (only valid as
source address).
10.0.0.0/8  Private network Used for local communications
within a private network.
100.64.0.0/10   Private network Shared address space[3] for
communications between a service
provider and its subscribers
when using a carrier-grade NAT.
127.0.0.0/8 HostUsed for loopback addresses to
the local host.
169.254.0.0/16  Subnet  Used for link-local addresses
between two hosts on a single
link when no IP address is
otherwise specified, such as
would have normally been
retrieved from a DHCP server.
172.16.0.0/12   Private network Used for local communications
within a private network.
192.0.0.0/24Private network IETF Protocol Assignments.
192.0.2.0/24Documentation   Assigned as TEST-NET-1,
documentation and examples.
192.88.99.0/24  InternetReserved. Formerly used for
IPv6 to IPv4 relay
192.168.0.0/16  Private network Used for local communications
within a private network.
198.18.0.0/15   Private network Used for benchmark testing of
inter-network communications
between two separate subnets.
198.51.100.0/24 Documentation   Assigned as TEST-NET-2,
documentation and examples.
203.0.113.0/24  Documentation   Assigned as TEST-NET-3,
documentation and examples.
224.0.0.0/4 InternetIn use for IP multicast.
240.0.0.0/4 InternetReserved for future use.
255.255.255.255/32  Subnet  Reserved for the "limited
broadcast" destination address.

IPv6
Address block   Usage   Purpose
::/0Routing Default route.
::/128  SoftwareUnspecified address.
::1/128 HostLoopback address to local host.
:::0:0/96   SoftwareIPv4 mapped addresses.
:::0:0:0/96 SoftwareIPv4 translated addresses.
64:ff9b::/96Global Internet IPv4/IPv6 translation.
100::/64Routing Discard prefix.
2001::/32   Global Internet Teredo tunneling.
2001:20::/28SoftwareORCHIDv2.
2001:db8::/32   Documentation   Addresses used in documentation
and example source code.
2002::/16   Global Internet The 6to4 addressing scheme
fc00::/7Private network Unique local address.
fe80::/10   LinkLink-local address.
ff00::/8Global Internet Multicast address.

Re: Request comment: list of IPs to block outbound

[Stephen Satchell]

On 10/13/19 9:08 AM, Florian Brandstetter wrote:
> Hi,
> 
> sorry - but why would you want to block Teredo?

I know nothing about Terendo tunneling.

> In computer networking, Teredo is a transition technology that gives
> full IPv6 connectivity for IPv6-capable hosts that are on the IPv4
> Internet but have no native connection to an IPv6 network. Unlike
> similar protocols such as 6to4, it can perform its function even from
> behind network address translation (NAT) devices such as home routers.
> 
> Teredo operates using a platform independent tunneling protocol that provides 
> IPv6 (Internet Protocol version 6) connectivity by encapsulating IPv6 
> datagram packets within IPv4 User Datagram Protocol (UDP) packets. Teredo 
> routes these datagrams on the IPv4 Internet and through NAT devices. Teredo 
> nodes elsewhere on the IPv6 network (called Teredo relays) receive the 
> packets, un-encapsulate them, and pass them on. 

Are you saying that Terendo should come off the list?  Is this useful
between an ISP and an edge firewall fronting an internal network?  Would
I see inbound packets with a source address in the 2001::/32 netblock?

> sorry - but why would you want to block 6to4?
In my research, this is marked as deprecated.  Would I see packets with
a source address in the 2002::/16 netblock?

Request comment: list of IPs to block outbound

[Stephen Satchell]

After reviewing the comments from people on NANOG and some other
locations, I have updated my list of routes to blackhole.  The
information at the end of this contribution is taken from the
RHEL/CentOS NetworkManager dispatcher.d source file, which I use to
install and remove the blackhole routes when the WAN interface is
started and stopped.

First, let me expand on what I'm trying to do.  The NetFilter NFTABLES
includes in its tests the ability to determine if the source address of
a packet is routeable, and further classifies the result as LOCAL,
BROADCAST, UNICAST, BLACKHOLE, and PROHIBITED, among others, as well as
the interface that would be selected.

By using the routing table in this way, maintaining the configuration of
the firewall is simplified, particularly when interfaces are brought up
or taken down.  There is no coding change to the firewall.

The fact that I can't send packets upstream with bad destinations is not
the goal here.  The goal is to detect packets inbound with bad source
addresses that would affect my network, as well as ensuring that
outbound packets have good source addresses.

Herewith is the revised information for your constructive criticism:

> # Default IPv6 routing table (sorted by ipv6 address):
> # 
> # $ route -n6
> # Kernel IPv6 routing table
> # DestinationNext Hop Flag Met Ref Use If
> # --   --- --- --- ---
> # ::/0   ::   !n   -1  1 0 lo
> # ::/0   ::   !n   -1  1 0 lo
> # ::1/128::   U256 1 0 lo
> # ::1/128::   Un   0   4 0 lo
> # fe80::/64  ::   U256 1 0 enp37s0
> # fe80::7285:c2ff:fec0:bdff/128  ::   Un   0   2 0 enp37s0
> # ff00::/8   ::   U256 6 0 enp37s0
> 
> # [-] -- not included in blacklist, part of default routes
> # [#] -- not included in blacklist, policy
> 
> # investigate https://www.team-cymru.com/bogon-reference-http.html
> # need to better understand Terendo tunneling
> # rp_filter does the same at nftables source routing check
> 
> 
> nets=" 
> 0.0.0.0/8   SoftwareCurrent network (only valid as \
> source address).
> 10.0.0.0/8  Private network Used for local communications \
> within a private network.
> -100.64.0.0/10  Private network Shared address space for \
> communications between a \
> service provider and its \
> subscribers when using a \
> carrier-grade NAT.
> 127.0.0.0/8 HostUsed for loopback addresses \
> to the local host.
> 169.254.0.0/16  Subnet  Used for link-local addresses \
> between two hosts on a single \
> link when no IP address is \
> otherwise specified, such as \
> would have normally been \
> retrieved from a DHCP server.
> 172.16.0.0/12   Private network Used for local communications \
> within a private network.
> 192.0.0.0/24Private network IETF Protocol Assignments.
> 192.0.2.0/24Documentation   Assigned as TEST-NET-1, \
> documentation and examples.
> 192.88.99.0/24  InternetReserved. Formerly used for \
> IPv6 to IPv4 relay (2002::/16).
> 192.168.0.0/16  Private network Used for local communications \
> within a private network.
> 198.18.0.0/15   Private network Used for benchmark testing of \
> inter-network communications \
> between two separate subnets.
> 198.51.100.0/24 Documentation   Assigned as TEST-NET-2, \
> documentation and examples.
> 203.0.113.0/24  Documentation   Assigned as TEST-NET-3, \
> documentation and examples.
> 224.0.0.0/4 InternetIn use for IP multicast. \
> (Former Class D network).
> 240.0.0.0/4 InternetReserved for future use. \
> (Former Class E network).
> 255.255.255.255/32  Subnet  Reserved for the 'limited \
> broadcast' destination address.
> -::/0   Routing Default route.
> ::/128  SoftwareUnspecified address.  
> -::1/128HostLoopback add

Re: Request comment: list of IPs to block outbound

[Stephen Satchell]

On 10/22/19 10:11 PM, Grant Taylor via NANOG wrote:
> The explicit nature of RFC 6598 is on purpose so that there is no chance
> that it will conflict with RFC 1918.  This is important because it means
> that RFC 6598 can /safely/ be used for Carrier Grade NAT by ISPs without
> any fear of conflicting with any potential RFC 1918 IP space that
> clients may be using.
> 
> RFC 6598 ∉ RFC 1918 and RFC 1918 ∉ RFC 6598
> RFC 6598 and RFC 1918 are mutually exclusive of each other.
> 
> Yes, you can run RFC 6598 in your home network.  But you have nobody to
> complain to if (when) your ISP starts using RFC 6598 Shared Address
> Space to support Carrier Grade NAT and you end up with an IP conflict.
> 
> Aside from that caveat, sure, use RFC 6598.

So, to the reason for the comment request, you are telling me not to
blackhole 100.64/10 in the edge router downstream from an ISP as a
general rule, and to accept source addresses from this netblock.  Do I
understand you correctly?

FWIW, I think I've received this recommendation before.  The current
version of my NetworkManager dispatcher-d-bcp38.sh script has the
creation of the blackhole route already disabled; i.e., the netblock is
not quarantined.

Re: Request comment: list of IPs to block outbound

[Stephen Satchell]

On 10/23/19 8:18 AM, Grant Taylor via NANOG wrote:
> I suspect things like NetworkManager are somewhat at a disadvantage in
> that they are inherently machine local and don't have visibility beyond
> the directly attached network segments.  As such, they can't /safely/
> filter something that may be on the other side of a router.  Thus they
> play it safe and don't do so.

You are 100 percent correct about NetworkManager.  The facility only
manages interfaces (including VPN and bridges).  What I've done is added
the ability to install and remove null routes when the upstream
interface comes on-line and goes off-line.

So this is only the first stage of filtering.  Using NetFilter (in
CentOS 8 case, NFTABLES), I will be adding rules to implement my
policies on each system I have.  What exactly will be accepted, what
will be forwarded, what will be rejected, and what will be ignored.

What adding the null routes does is let me use the FIB test commands so
that the firewall files don't have to know the exact configuration of
networking, or have monster lists that have to be maintained.  Consider
that one suggestion from this group is to look at using
https://www.team-cymru.com/bogon-reference-http.html and doing periodic
updates of the null routes based on the information there.  (With caution.)

This is specific to Linux.  The idea is to let the computer do all the
bookkeeping work, so I don't have to.  Even if I have automation to "help".

The first application of this work will be to replace my existing
firewall router with up-to-date software and comprehensive rules to
handle NAT and DNAT, on a local network with quite a number of VLANs.

Anyone from NTT America here?

[Stephen Satchell]

Routing loop

>  11.|-- 129.250.24.196 0.0% 1   28.9  28.9  28.9  28.9   0.0
>  12.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0   0.0
>  13.|-- 129.250.130.2530.0% 1   29.4  29.4  29.4  29.4   0.0
>  14.|-- 129.250.130.2540.0% 1   29.6  29.6  29.6  29.6   0.0
>  15.|-- 129.250.130.2530.0% 1   28.5  28.5  28.5  28.5   0.0
>  16.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0   0.0
>  17.|-- 129.250.130.2530.0% 1   28.6  28.6  28.6  28.6   0.0
>  18.|-- 129.250.130.2540.0% 1   27.9  27.9  27.9  27.9   0.0
>  19.|-- 129.250.130.2530.0% 1   28.4  28.4  28.4  28.4   0.0
>  20.|-- 129.250.130.2540.0% 1   27.9  27.9  27.9  27.9   0.0
>  21.|-- 129.250.130.2530.0% 1   28.2  28.2  28.2  28.2   0.0
>  22.|-- 129.250.130.2540.0% 1   29.0  29.0  29.0  29.0   0.0
>  23.|-- 129.250.130.2530.0% 1   27.9  27.9  27.9  27.9   0.0
>  24.|-- 129.250.130.2540.0% 1   28.6  28.6  28.6  28.6   0.0
>  25.|-- 129.250.130.2530.0% 1   28.7  28.7  28.7  28.7   0.0

Re: Disney+ Streaming

[Stephen Satchell]

CAVAET: I don't have a dog in this hunt.

On 11/13/19 6:46 AM, Mel Beckman wrote:

This is silly off-topic. You don’t have to go home, but you can’t
stay here, according to NANOG guidelines.



https://www.nanog.org/resources/usage-guidelines/ > 
https://www.nanog.org/bylaws/


"The NANOG mailing list was established in 1994 to provide an open forum 
for the exchange of technical information, and lively discussion of 
SPECIFIC IMPLEMENTATION CHALLENGES (emphasis mine) that require 
cooperation among network service providers.


"Posts to NANOG’s mailing list should be focused on operational and 
technical content only, as described by the NANOG Bylaws."


Yes, some of the Disney Plus thread has strayed outside the four corners 
of the rules of the mailing list, but the bulk of the thread has to do 
with two things: geolocation inaccuracies, and traffic capacity shifts. 
 For some network operators on this list, the discussion does not 
describe issues on their networks.  But "some" is not "all".

Re: Elephant in the room - Akamai

[Stephen Satchell]

On 12/5/19 6:02 PM, Valdis Klētnieks wrote:

(I also admit having no idea what percentage of the intermediate routers in the
ISP's networks have gotten de-bloating code.


For SP-grade routers, there isn't "code" that needs to be added to 
combat buffer bloat.  All an admin has to do is cut back on the number 
of packet buffers on each interface -- an interface setting, you see.


The reason that comsumer-grade devices can contribute to buffer bloat is 
because the vendor doesn't expose a knob to adjust buffering.  At least 
in most instances with Best Buy and Office Depot routers.

Expect (was: Software Defined Networks)

[Stephen Satchell]

I (and another programmer, now at Amazon) migrated our automation from 
TCL/Expect to Python/pexpect.  I've had to write code for those portions 
of Expect that didn't carry over into pexpect.


I also had to build a framework that allowed me to do rule-based 
programming in the same flavor as Expect's "expect" statement, which 
isn't hard but tedious as all get-out.  Maintenance of the code using 
the framework is head and shoulders better than the same tasks in 
Expect.  Particularly when Cisco makes little changes in their 
operations as you move up the revision chain.


On 12/12/19 6:53 PM, Quan Zhou wrote:
I do still use expect(tcl) whole lot at work, it is truly an 
underappreciated tool ever.


On 12/13/19 10:47, Large Hadron Collider wrote:

Tcl still exists, though I don't think they use it for this anymore.

On 19-12-05 10 h 17, Bryan Holloway wrote:


On 12/5/19 6:16 PM, Patrick W. Gilmore wrote:

I tell everyone we had SDNs in the 90s.

But we called it “expect scripts”.

:-)

--
TTFN,
patrick



I miss TCL ...

Re: power to the internet

[Stephen Satchell]

On 12/25/19 6:29 PM, Michael Thomas wrote:
Yes, this is exactly right. My point here isn't to assign blame, but to 
ask what the hell we're going to do about it. Trying to score political 
points is disgusting.


Do you live in California?  Do you have your business in California? 
Take a look at neighboring states.  I did.  California madness is why I 
now live in Nevada.


Our ecology doesn't have the Austrailian plant Eucalyptus.  We do have 
tumbleweeds which pose their own fire risk.  Place like Lake Tahoe is 
heavily forested -- the difference is that in Nevada there is active 
fuel control and controlled burns, so we have fewer burn-to-the-ground 
fires in populated areas.


I used to make a living as a freelance writer.  A GOOD living.  In 
Nevada I'm outside the reach of CA AB 5 should I want to give up 
$DAYJOB.  When I have to subcontract freelance work, I won't hire a 
California resident, because I don't want to be controlled by any 
"long-reach" laws.  Because the law and Calufornia court decisions are 
currently silent about C, S, and LLC writers, I avoid them until the 
climate becomes clearer.


Do I experience power outages?  Yes.  Longest duration?  Several hours, 
when high winds cause damage (but that damage doesn't start wildfires). 
One very nice thing is that where I am, we have a geothermal power plant 
close by (on the order of 15 miles).  No pre-emptive wide-area 
shutdowns, though.


NV Energy has photoelectric arrays that are part of the utility, not 
only on private roof-tops.

Re: power to the internet

[Stephen Satchell]

On 12/26/19 10:55 AM, Michael Thomas wrote:
Here in California, you're going to need a lot more than 8 hours. We had 
one that lasted 3 days, followed by about 8 hours of power, followed by 
2 days of no power. If this is the new normal, and I'm afraid that it 
is, that's probably going to require some pretty hefty backup. Not to 
mention expensive.


The one "good" thing that PG&E did is expose all of these 
vulnerabilities. Every neighborhood probably knows whether their carrier 
is naughty or nice now.


Here in Nevada, specifically at Lake Tahoe, power is less reliable 
because of heavy snow and sliding trucks (the power equivalent to a 
backhoe disconnect).  One of the cell sites is on the top level of a 
casino parking garage.  I found out about this when the casino went 
bankrupt, the parking garage was blocked off, and I joined the security 
guard crew to protect the on-site gaming equipment.  Months into the 
project, the cell company in question begged the bankruptcy court for 
access -- to replace the empty propane cylinders in their shack.  That's 
right, no mains tap at all.  When the casino lost power because of bill 
non-payment, the cell site stayed up.


A network operator will need to look at the total cost, including labor, 
of backing up mains power. versus using local genertion exclusively -- 
or using mains power as the backup!  Factor in any upcoming fines for 
service outage, re 911.  (Try to avoid piped natural gas as the fuel for 
onsite generation.)


Longer term, review your backhauls and interconnects.  Dark fiber would 
be preferred here, because you would be controlling backup power at both 
ends, and not depending on intermediate nodes.

Re: Cloudflare, dirty networks and politricks

[Stephen Satchell]

On 07/28/2016 10:17 AM, J. Oquendo wrote:

While many are chanting: #NetworkLivesMatter, I have yet
to see, read, or hear about any network provider being
the first to set precedence by either de-peering, or
blocking traffic from Cloudflare. There is a lot of
keyboard posturing: "I am mad and I am not going to take
it anymore" hooplah but no one is lifting a finger to
do anything other than regurgitate "I am mad... This is
criminal."


Let's supposed someone did indeed de-peer or otherwise block Cloudflare 
from their entire network.


Which of y'all would be the first to say to that network operator, "Hope 
you enjoy your intranet"?

Re: Handling of Abuse Complaints

[Stephen Satchell]

On 08/29/2016 08:55 AM, Jason Lee wrote:

NANOG Community,

I was curious how various players in this industry handle abuse complaints.
I'm drafting a policy for the service provider I'm working for about
handing of complaints registered against customer IP space. In this example
I have a customer who is running an open resolver and have received a few
complaints now regarding it being used as part of a DDoS attack.

My initial response was to inform the customer and ask them to fix it. Now
that its still ongoing over a month later, I'd like to take action to
remediate the issue myself with ACLs but our customer facing team is
pushing back and without an idea of what the industry best practice is,
management isn't sure which way to go.

I'm hoping to get an idea of how others handle these cases so I can develop
our formal policy on this and have management sign off and be able to take
quicker action in the future.


It depends on the nature of the complaint.  If it's an amplification 
attack of some kind, figure out how the perp is doing it, and block it 
as appropriate.  For example, do you filter incoming packets with source 
address of subnet network and broadcast (shorter than /30) and allnet 
(255.255.255.255) broadcast, and filter packets outbound with 
destinations of allnet broadcast?


DNS and NTP can be tricked into generating packet storms.  In 
particular, you may want to block excessive large DNS requests inbound 
using deep packet inspection at your edge.


Not all abuse problems are the fault of the customer.  You have to do 
your part as well.

Status of IPv6 on Charter Communications

[Stephen Satchell]

Would someone at Charter Communications who is on this list indicate the 
roll-out schedule for IPv6 to business customers using cable modems as 
opposed to fiber links?

Re: One more thing to watch out for at data centers - fire drills

[Stephen Satchell]

On 09/17/2016 02:43 PM, Larry Sheldon wrote:

My experiences were back in the days of washing-machine class disc
drives and they were a 4-hour fire-wall away, but I don't remember them
being impacted. (I can't believe that I was allowed to conduct a test
with them running, but I don't remember shutting them down.)

I wonder if orientation mattered--mine were all platters parallel to the
floor, I wonder if the damaged ones were parallel to the wave front.


If you watched the video of the guy who screamed at his disk drives to 
cause temporary faults, the JBOD had its platters horizontal to the floor.


One of the reason the washing-machine-sized CDC Storage Module Drives 
weren't affected by high noise level is the sheer beefy mass of the head 
assembly and the voice coil.  Also, the track spacing on the platters of 
those drives was far less dense, so any noise-induced mis-tracking would 
be minuscule, and easily handled by said voice-coil's position-error 
system.  The heads were larger, as well as the head arms.  In this 
situation, mass is your friend.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Stephen Satchell]

On 09/25/2016 07:32 AM, Jay R. Ashworth wrote:

From: "Jay Farrell via NANOG" 
> And of course Brian Krebs has a thing or two to say, not the least is which
> to push for BCP38 (good luck with that, right?).
>
> https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/

Well, given how few contributions we've gotten at bcp38.info in the last,
what, 4 years, yeah, I guess so...



Yeah, right.  I looked at BCP38.info, and there is very little concrete 
information.  I've been slogging through the two RFCs, 2827 and 3794, 
and find it tough sledding to extract the nuggets to put into my 
firewall and routing table.  One of the more interesting new additions 
to my systems is this, to the routing tables:


ip route add blackhole 0.0.0.0/32   # broadcast (deprecated)
ip route add blackhole 0.0.0.0/8# “this”
ip route add blackhole 10.0.0.0/8   # private network
ip route add blackhole 100.64.0.0/10# carrier-grade NAT
ip route add blackhole 127.0.0.0/8  # loopback
ip route add blackhole 169.254.0.0/16   # link-local
ip route add blackhole 172.16.0.0/12# private network
ip route add blackhole 192.0.0.0/24 # IANA special purpose registry
ip route add blackhole 192.0.2.0/24 # TEST-NET
ip route add blackhole 192.88.99.0/24   # 6to4 anycast relay (optional)
ip route add blackhole 192.168.0.0/16   # private network
ip route add blackhole 198.18.0.0/15# inter-network testing
ip route add blackhole 198.51.100.0/24  # TEST-NET-2
ip route add blackhole 203.0.113.0/24   # TEST-NET-3
ip route add blackhole 224.0.0.0/4  # Multicast
(all the implied routes from interface definitions that are inserted 
automatically into the routing table by the operating system)

ip route add  via  dev 
ip route add  via  dev 

(Has this been published anywhere before?  I haven't found any yet.)

Notice I've omitted 255.255.255.255, because I have quite a bit of 
software that uses this broadcast address, and it needs to get onto my 
intranets; I just have to be sure that the edge link doesn't let it out 
to the world.  One such program that uses broadcast is Dropbox.


This routing table addition forms the nucleus from which I can derive 
most of the source-address input packet filtering (adding 
255.255.255.255), as well as destination-address output filtering with 
code, instead of having to compile the rules by hand.


Then there are other packet filters:
* TCP “Lamp test/XMAS” et. al.  (mask, set)
--tcp-flags FIN,SYN,RST,PSH,ACK,URG   NONE
--tcp-flags FIN,SYN,RST,ACK,URG   FIN,SYN,RST,ACK,URG
--tcp-flags FIN,SYN,RST,PSH,ACK,URG   FIN,PSH,URG
--tcp-flags FIN,ACK  FIN
--tcp-flags PSH,ACK  PSH
--tcp-flags URG,ACK  URG
--tcp-flags SYN,FIN  SYN,FIN
--tcp-flags SYN,RST  SYN,RST
--tcp-flags FIN,RST  FIN,RST
* DNS flood
* DNS amplification
* NTP flood
* NTP amplification
* ICMP flood
* IGRP flood
* protocol/port “small services” connections

And I'm just getting started.  It helps that I have a few books talking 
about the design of firewalls that discuss some of these filters.


For DNS amplification, I'm using these IPTABLES rules:


# Limit UDP DNS "root NS" queries (must come before generic stream ACCEPT)
#  
01210001020001
-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string 
"|01210001020001|" --algo bm --from 20 --to 1550 -m recent 
--set --name dnsrootquery --rsource
-A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string 
"|01210001020001|" --algo bm --from 20 --to 1550 -m recent --rcheck 
--seconds 20 --hitcount 3 --name dnsrootquery --rsource -m comment --comment "UDP DNS ROOT 
flood" -j DROP


(Another possibility would be to read the DNS hints file for all the 
root servers, and impose rate-limiting to those IP addresses...but I 
didn't think of that before and so it's not part of the current DNS 
server firewall.  But the filters above seem to work quite well -- it's 
been a long time since my ISP upstream's uplink has been nailed up solid.)


In short, I have yet to see a "cookbook" for BGP38 filtering, for ANY 
filtering system -- BSD, Linux, Cisco.

Request for comment -- BCP38

[Stephen Satchell]

Is this an accurate thumbnail summary of BCP38 (ignoring for the moment 
the issues of multi-home), or is there something I missed?



The basic philosophy of BCP38 boils down to two axioms:

Don't let the "bad stuff" into your router
Don't let the "bad stuff" leave your router

The original definition of "bad stuff" is limited to source-
address grooming both inbound and outbound.  I've expanded on the
original definition by including rule generation to control
broadcast address abuse.

Re: Request for comment -- BCP38

[Stephen Satchell]

On 09/26/2016 07:11 AM, Paul Ferguson wrote:

No -- BCP38 only prescribes filtering outbound to ensure that no
packets leave your network with IP source addresses which are not
from within your legitimate allocation.


So, to beat that horse to a fare-thee-well, to be BCP38 compliant I 
need, on every interface sending packets out to the internet, to block 
any source address matching a subnet in the BOGON list OR not matching 
any of my routeable network subnets?  Plus add null-route entries for 
all the BOGONs in my routing table so I don't send a bad destination 
packet to my upstream?

is someone with BCP38.info update privs summarizing this discussion?

[Stephen Satchell]

I think some pretty good information has surfaced, that would be 
WONDERFUL to have on that site.

Re: Request for comment -- BCP38

[Stephen Satchell]

I'm trying to come up with a simple picture that embraces all the 
comments I've seen thus far on the definition of BCP38.  The example 
scenario I'm about to paint may be over-simplified -- but I like to 
start simple.


Given a single local inside network with:
  * multiple uplink providers (typical multi-home situation)
  * multiple edge routers, each connected to an upstream via a public 
routeable /30, and each further connected to the downstream inside network
  * 50 subnets (to pick a number) of routeable IP address space 
downstream from the edge routers, with routing announcements to the 
world that direct packets back to the edge routers


BCP38 demands that ANY packet leaving ANY edge router to the upstream 
MUST have a source address:

  * within the 50 inside public route-able subnets, or
  * within a list of "my" addresses in the public /30 subnets.

True statement?

What am I missing here?

(In this simplified view, I'm divorcing the BCP38 aspects from the 
practical effects of any policy or input filtering done by the 
upstreams, as I think that's a separate discussion -- important but 
off-topic right now for my understanding of BCP38 at its core.  Those 
practical aspects can be added later, AFTER describing the basics.)

BCP38 adoption "incentives"?

[Stephen Satchell]

Does anyone know if any upstream and tiered internet providers include 
in their connection contracts a mandatory requirement that all 
directly-connected routers be in compliance with BCP38?


Does anyone know if large ISPs like Comcast, Charter, or AT&T have put 
in place internal policies requiring 
retail/business-customer-aggregating routers to be in compliance with BCP38?


Does any ISP, providing business Internet connectivity along with a 
block of IP addresses, include language in their contracts that any 
directly connected router must be in compliance with BCP38?


I've seen a lot of moaning and groaning about how BCP38 is pretty much 
being ignored.  Education is one way to help, but that doesn't hit 
anyone in the wallet.  You have to motivate people to go out of their 
way to *learn* about BCP38; most business people are too busy with 
things that make them money to be concerned with "Internet esoterica" 
that doesn't add to the bottom line.  You have to make their ignorance 
SUBTRACT from the bottom line.


Contracts, properly enforced, can make a huge dent in the problem of 
BCP38 adoption.  At a number of levels.


Equipment manufacturers not usually involved in this sort of thing (home 
and SOHO market) would then have market incentive to provide equipment 
at the low end that would provide BCP38 support.  Especially equipment 
manufacturers that incorporate embedded Linux in their products.  They 
can be creative in how they implement their product; let creativity blossom.


I know, I know, BCP38 was originally directed at Internet Service 
Providers at their edge to upstreams.  I'm thinking that BCP38 needs to 
be in place at any point -- every point? -- where you have a 
significant-sized collection of systems/devices aggregated to single 
upstream connections.  Particular systems/devices where any source 
address can be generated and propagated -- including compromised desktop 
computers, compromised light bulbs, compromised wireless routers, 
compromised you-name-it.


(That is one nice thing about NAT -- the bad guys can't build spoofed 
packets.  They *can* build, um, "other" packets...which is a different 
subject entirely.)


(N.B.:  Now you know why I'm trying to get the simplest possible 
definition of BCP38 into words.  The RFCs don't contain "executive 
summaries".)

BCP38 -- disabusing misinformation in this discussion

[Stephen Satchell]

"BCP38 applies only to egress filtering"

INCORRECT.

The title of the update to BCP38/RFC2827, BCP84/RFC2074, exposes the 
balderdash on its face.  That title?  "Ingress Filtering for Multihomed 
Networks."  Oops.  This is a short snipping from the Introduction:



RFC 2827 recommends that ISPs police their customers' traffic by
dropping traffic entering their networks that is coming from a source
address not legitimately in use by the customer network.


ENTERING, not LEAVING.  QED

(Although I can understand some of the confusion.  Some people might 
IMPLEMENT BCP38 using egress filtering, relying on the infamous "as-if" 
rule.  Indeed, in my implementation of BCP38, I implement it on both 
INPUT and OUTPUT, so that it traps nasty traffic generated within the 
four corners of the system on which the firewall runs.  This works for 
servers, particularly servers with multiple virtual guests.)


..

Looking at RFC 2827  (I couldn't sleep, so here I am in the middle of 
the dark reading RFCs) Section 3, this paragraph appears:



In the example above, the attacker resides within 204.69.207.0/24,
which is provided Internet connectivity by ISP D.  An input traffic
filter on the ingress (input) link of "router 2", which provides
connectivity to the attacker's network, restricts traffic to allow
only traffic originating from source addresses within the
204.69.207.0/24 prefix, and prohibits an attacker from using
"invalid" source addresses which reside outside of this prefix range.



In other words, the ingress filter on "router 2" above would check:

IFpacket's source address from within 204.69.207.0/24
THEN  forward as appropriate

IFpacket's source address is anything else
THEN  deny packet

   Network administrators should log information on packets which are
   dropped. This then provides a basis for monitoring any suspicious
   activity.


(Note that "router 2" in the diagram is the router to which the attacker 
is talking, not a router on upstream ISPs A, B, C, and D.  Although I 
guess router 2 could be owned by the ISP...)


So, if I'm reading the RFC correctly, my original assertion that BCP 
mandates routers block "the bad stuff" on output, but ALSO on input.  In 
fact, I don't see any discussion of output filtering in the RFC -- show 
me where it does, please.


Now getting back to the discussion of uRPF (Unicast Reverse Path 
Forwarding), the RFC also talks about this:



... The method
suggested is to look up source addresses to see that the return path
to that address would flow out the same interface as the packet
arrived upon. With the number of asymmetric routes in the Internet,
this would clearly be problematic.


That description roughly corresponds with Cisco's definition of 
"strict".  My question is whether my simplified example in a prior rock 
would correspond with Cisco's definition of "loose" -- you allow any 
source address in any downstream or local subnet the router knows about.


.

Just to show that I do read entire RFCs, here is this little nugget, 
from RFC 2827, Section 5:



If ingress filtering is used in an environment where DHCP or BOOTP is
used, the network administrator would be well advised to ensure that
packets with a source address of 0.0.0.0 and a destination of
255.255.255.255 are allowed to reach the relay agent in routers when
appropriate.  The scope of directed broadcast replication  should be
controlled, however, and not arbitrarily forwarded.


In the SOHO environment, the problem is moot because the DHCP is usually 
provided on the first router.  (That's true in my home, and in 
businesses where I have installed networking.)  In larger networks, or 
with ISPs that insist on doing DHCP upstream from a router, this is an 
issue.

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Stephen Satchell]

On 09/28/2016 12:33 AM, Eliot Lear wrote:

It's not just consumers that need to understand this.  Manufacturers of
Things are right now on a steep learning curve.  Consider that
thermostat, for just a moment.  In The Gold Old Days, before it had a
network interface, the manufacturer cared about a handful of things like
at what temperature to turn the heat or A/C on maybe with some
adjustments for time of day or day or week.  And that was it.  That is
their domain of expertise.  Not security.

Now the Internet looks like a new shiny object that promises to provide
some cool new world capabilities, like letting people adjust the temp
while they're away, or using weather forecasts to manage hysteresis
effects.  And so, the manufacturer initially thinks, we'll add an
interface to the product, and a little bit of code, and we're done.  Now
the manufacturer has stepped outside their domain of expertise, and
doesn't have a full understanding of the risks that need to be
addressed.  We as experts in this domain can help by informing
manufacturers of those risks.


Many manufacturers will outsource the Internet portion of their product 
to a software provider, not build from scratch "in house".  The people 
we really need to get to are the ones that *provide* those packages the 
manufacturers use.


In the case of embedded Linux solutions, the discussion need only be 
about what knobs to turn, and how far.

Re: Request for comment -- BCP38

[Stephen Satchell]

On 10/01/2016 06:39 PM, Jay R. Ashworth wrote:

You *can* do BCP38 egress filtering on your network, but that filter
would *be in control of the Bad Guys* whom we're trying to kill off.


I don't see how you arrive at this conclusion.  For an aggregating 
router, the Bad Guys(tm) don't get anywhere near the control plane of 
the thing.  Besides, my security training (such as it is) demands that 
one implement defence in depth.  Specifically, if the Bad Guys(tm) find 
a way around my ingress filtering, the egress filtering will bump 'em off.


Where egress filtering really makes sense is with tunnels over SSH.  I 
haven't found where I can "hook into" a SSH tunnel with Linux.  I can 
turn off shell (and do), but the inbound packets look like local 
origination to the NetFilter.  And (at this early time) The Rules(sm) 
say that you always ACCEPT packets to and from "lo".  I've learned from 
hard experience that violating that rule breaks a lot of stuff.


Then there is the web server case.  The Bad Guys(tm) have access to PHP, 
or Perl, or even a user-level shell, but again NO ACCESS TO THE CONTROL 
PLANE.  Do we really want web-generated packets to get a bye?


(I want to put BGP egress filters on my mail servers, my FTP servers, my 
time servers, my *anything* servers.  It's easy, and it means the 
defence gets as close to the source as I can get it.)



The filtering needs to be on the other side of the administrative
span of control fence.


No reason NOT to have filtering on BOTH sides of that fence...

Legislative proposal sent to my Congressman

[Stephen Satchell]

In thinking over the last DDos involving IoT devices, I think we don't 
have a good technical solution to the problem.  Cutting off people with 
defective devices they they don't understand, and have little control 
over, is an action that makes sense, but hurts the innocent.  "Hey, 
Grandma, did you know your TV set is hurting the Internet?"


It's the people who foist bad stuff on the people who need to take the 
responsibility.  Indeed, with enough moxie, we could avoid the net 
saturation problem in the first place.


My proposal, as I sent it to my US House Representative:


Fixing the security of the Internet of Things: Now we have had
several distributed denial of service attacks — generating
eye-popping amounts of network traffic to bury a web site or gamer —
arguably traced to botnets-for-sale of "hacked" common devices with
Internet connectivity. It's time to look at the problem bad product
design can cause. Not being "computers", many of those devices —
cameras, televisions, light bulbs, to name a few — don't have
tough-enough security moxie baked in. And it's not enough to solve
today's attacks, they have to survive new attacks down the road.

Some of these household items didn't conform to today's Best
Practices, taught in Security 101, with the rules learned (painfully)
over the last 30 years. And then there is the question of installing
security fixes: "Hey, Joe, you have to install an update to your
thermostat and washing machine." Right.

This is nothing new. What is new is the tsunami of Internet-capable
devices hitting the market and the Internet...and doing it badly. By
sheer numbers, the situation rises to a whole new level of risk to the
nation's communications infrastructure. The magnitude of the problem?
Think how many light bulbs are in the typical house or apartment, and
you get the idea.

This note comes a little late to the game, but I thought that one
wayto stem the flood of garbage from compromised household stuff is to
treat vulnerabilities that cause spew as design defects, defects as
serious as the exploding batteries in the Samsung Galaxy Note 7. So,
looking at the procedures already in place for dealing with merchandise
that can cause harm, this suggestion.

Proposed: GIVEN

 * any Internet-connected device,
 * "pwned" by cybercriminals,
 * that cause significant harm,
 * the manufacturer received notice of the defect, and
 * did not, or cannot, provide a timely, zero-cost update

THEREFORE the Consumer Product Safety Commission shall require that
the manufacturer provide a security update to the device within 30 day
of first notice; or failing that, to issue a complete recall of the
defective devices.

I don't care if it's a television, camera, refrigerator, light bulb,
thermostat, washing machine, wireless access router, smart phone,
desktop computer, server, you-name-it...if it's broke, and can't (or
won't) be fixed, it gets recalled.

That's the only way manufacturers will take Internet security
seriously. If they have to upgrade the stuff they sell, without
exception, the manufacturers will find a method that will keep their
expense for upgrades down. Upgrades should not be charged to the
customer — the manufacturer screwed up, they should fix the problem, at
their expense. I further suggest that security testing should be
specifically permitted under law, not be considered part of "reverse
engineering", or other shrink-wrap or copyright restriction.

The CSPC should develop guidelines for product with embedded computers
that connect to the Internet at large, either directly or indirectly.

There are a number of things to consider, when building such a
regulation, that come into play that complicated things

 * orphaned devices,
 * devices made by companies that have gone out of business,
 * imported stuff,
 * methods of notification, and
 * enforcement

This is an off-the-top-of-my-head idea. I think it's worth
consideringover other "solutions" I've seen proposed.


There is precedent for this with radio and the FCC.  According to 
current law, the owner/operator of the radio equipment is ultimately 
responsible for non-interference by any transmitter used in the United 
States.  This includes so-called unlicensed transmitters.  To help the 
people who are not radio gurus, the FCC also has a type acceptance 
program, in which radios have to meet certain requirements as built by 
the manufacturer.


There is another possible wrinkle:  if there were legal consequences 
with selling IoT equipment, businesses making the stuff would take out 
insurance against claims against them.  The underwriters would then take 
notice, and require that policyholders meet some minimum standards. 
Remember, we are talking about the "underwriters" who form the first 
part of the name "Underwriters Laboratories".  From UL's web page:



UL is a global independent safety science company with more than a
century of expertise innovating safety solutio

Re: Legislative proposal sent to my Congressman

[Stephen Satchell]

On 10/05/2016 09:46 AM, jim deleskie wrote:
> Can we please not get the government ( who's gov ) involved. I fully agree
> that it will not only not help, but will make some things worse.  This is
> why we can't have nice things.

I would be in favor of your pleas if you would accompany it with your
proposal for eliminating exploitable devices from accessing the Internet
and being the source of damaging traffic.

This IS the NANOG mailing list.  So far, the "solutions" I've seen put
foreward are like requiring government ID at polling places.

Re: IoT security, was Krebs on Security booted off Akamai network

[Stephen Satchell]

On 10/09/2016 07:31 AM, Mel Beckman wrote:
> remote RF temperature sensor hub for home, the GW-1000U.
> ...
> The device accepts TCP connections on 22, 80, and 443.  Theoretically
> I can't see why it ever needs ongoing inbound connections, so this
> seems to be a security concession made by the maker. Also, it appears
> to support SSL, but uses plaintext. Why? Because it's easier to debug
> in the early deployments, I'll wager. But the thing has been out for
> years and they're still not using encryption, even though the device
> apparently has the ability.

I could see one reason, and one reason only:  to allow the customer to
use a "control panel" with a local computer, smartphone app, or tablet
app to set capabilities, options, and preferences.  That said, the
manufacturer probably thought that the sensor would be shielded from the
Internet by a Wireless Access Point with NAT, so that there would be no
direct exposure (in theory) to inbound connections from the outside world.

For IPv4, this is barely tolerable.  For IPv6, not so much.

As a developer, I can tell you that "easier to debug in the early
deployments" means that the later deployments won't be locked down until
the manufacturer gets a fine, judgement, or other monetary hit.

Would you put this thing on a DMZ?  I thought not...   :)

Re: Death of the Internet, Film at 11

[Stephen Satchell]

On 10/22/2016 05:34 AM, Mike Hammett wrote:
> "taken all necessary steps to insure that none of the numerous specific types 
> of CCVT thingies that Krebs and others identified" 
> 
> Serious question... how? 
> 

Network operators can only do so much.  By the time traffic enters into
an ISP's traffic aggregation point, any flow monitoring and throttling
would have a minimal effect.  Not saying that it shouldn't be
considered.  The correct answer includes throttling the traffic much
closer to the source.

The obvious answer is that the device that bridges IoT to the upstream
link in the home or office have the capability of rate-limiting upstream
traffic.  Perhaps on a per-MAC basis.  When does a thermostat, light
bulb, or refrigerator need 1-megabyte/s uplink channels?  For that
matter, how many computers -- especially laptops -- need that kind of
upstream capacity?

(Yes, yes, YouTube publishers and VLAN links to the office, to name two,
will need that kind of channel; see below.  Gamers need small,
low-latency channels, so the throttling can't be too aggressive.
Public-access storage, web and mail servers, obviously.  IP-connected
Web cameras need some upstream capacity, but not a full-bore one.  The
uplink throttle can take into consideration "reasonable" upstream rates
for cameras.)

For wireless access points, the place to start would be with the OpenWRT
package, to serve as a model for what *can* be done.  Once we have a
proof of concept, it would raise the bar for "commercial"
implementations.  THAT would then provide an opportunity for the
three-letter Federal agencies to specify reasonable regulations, should
Congress so decide this is necessary.  It's much easier for regulatory
bodies to say "this software does it, why can't yours?" instead of
saying "you [manufacturer] go figure it out".

The ripple effect throughout the world would go a long way to curbing
the problem.  Especially if other regulatory administrations follow
suit, so that the enabling crap routers are weeded out.

What about the exceptions?  For those rare cases where one needs a
high-rate upstream channel for a node on the wireless network (or wired
network, for that matter), the firmware in the traffic aggregating
device can allow for specific exceptions to the rate-limit rules.  One
method is to tie exceptions to the device MAC address, or range of MAC
addresses.  Another is to tie exceptions to ports, with WiFi being a
single "port" in this context.  Generators of high-speed upstream
traffic would, for example, need a wired connection in order to do this.
 This would *not* affect most WiFi-connected peripherals, like printers,
because the AP would limit upstream traffic, not downstream.

The ISP would then have something to sell to the customer, to replace
the local POS router/WAP that the customer is currently using.

Hmmm...something to thing about as I build the Linux IPTABLES Firewall
Rule Generator Mk III...

Re: Death of the Internet, Film at 11

[Stephen Satchell]

That's what VPNs are for.

On 10/22/2016 10:04 AM, jim deleskie wrote:
> It is also likely the desired use case.  In my office I like to be able to
> login when needed when on the road, when the alarm company calls me at 2am
> for a false alarm so I don't have to get someone else out of bed to have
> them dispatched to check on the site.
> 
> -jim
> 
> On Sat, Oct 22, 2016 at 1:42 PM, Chris Boyd  wrote:
> 
>>
>>> On Oct 22, 2016, at 7:34 AM, Mike Hammett  wrote:
>>>
>>> "taken all necessary steps to insure that none of the numerous specific
>> types of CCVT thingies that Krebs and others identified"
>>>
>>> Serious question... how?
>>
>> Putting them behind a firewall without general Internet access seems to
>> work for us.  We have a lot of cheap IP cameras in our facility and none of
>> them can reach the net.  But this is probably a bit beyond the capabilities
>> of the general home user.
>>
>> —Chris
>>
>>

Re: Death of the Internet, Film at 11

[Stephen Satchell]

On 10/23/2016 04:19 PM, Ronald F. Guilmette wrote:
> I guess that's just an example of what somebody else already noted here,
> i.e. that providers don't care to spend the time and/or effort and/or
> money necessary to actually -do- anything about compromised boxes, and
> anyway, they don't want to lose a paying customer.

That was a lesson well-learned in the e-mail community, that the
majority of providers don't care as long as the actions of "target"
admins amount to nothing.  Hell, they used to spam themselves!  That's
why the DNSBLs became so popular.

So, bottom line, nothing is going to happen until the cost to those
negligent provides rises so high as to affect profits.  Period.

Larger eyeball operators could help, by shutting down entire subnets
infested with botted computers and things.

Re: Death of the Internet, Film at 11

[Stephen Satchell]

On 10/23/2016 07:02 PM, David Conrad wrote:
> On October 23, 2016 at 6:52:05 PM, Stephen Satchell (l...@satchell.net) wrote:
> So, bottom line, nothing is going to happen until the cost to those 
> negligent provides rises so high as to affect profits. Period. 
> Yep.  Or government intervention.
> 
> Larger eyeball operators could help, by shutting down entire subnets 
> infested with botted computers and things. 
> 
> Shut down subnets of your own customers? 

I was thinking NetFlix, the search engines, Amazon, Facebook, and
twitter, to name a few.

Should abuse mailboxes have quotas?

[Stephen Satchell]

For the last couple of weeks, every single abuse mail I've tried to send
to networks in a very short list of countries has bounced back with
"mailbox exceeds quota".  I take this to mean that there isn't someone
actively reading, acting on, and deleting e-mail from abuse@.

So my new rule is this:  bounce an abuse e-mail message, sent to an
abuse address announced for the netrange, and the ENTIRE NETRANGE gets
put in my "reject forever" firewall.  I've ask all my customers about
this action, and all agree that it's reasonable, because an
administration with an active abuse desk shouldn't ever have their abuse
mailbox overflow.  (Especially in this day of terabyte disks.)

Or they need more people on their abuse desk.

Or they need to eliminate the problem that generates so many abuse
e-mails that it fills up their should-be-enormous mail queue.

I'm tired of blatantly uncaring administrations.

Re: Should abuse mailboxes have quotas?

[Stephen Satchell]

On 10/27/2016 01:30 PM, J wrote:
> I'm in the camp of not replying to every report.

I was in that camp, too, when I was mail admin for a web host company.
I wanted to spend my time fixing the flood, without having to take the
time to reply.

I figure the best reply is when the spamming stops.  I have about 30
mail endpoints of my own that I monitor, so it becomes obvious real
quick when someone takes action.  :)

Re: Spitballing IoT Security -- Dancing around a solution

[Stephen Satchell]

I've been following the discussion with quite a bit of interest.  What
had become crystal clear to me is that nobody here has been looking at
the problem from the perspective of the manufacturer, particularly how
they actually get product to marked.  A la "Dilbert".

The engineer's credo:  "Why build it when you can buy it?"  I doubt very
seriously that manufacturers are starting completely from scratch when
they design their IoT product.  They buy this piece, they buy that
piece, they buy this hunk of software, they buy these hardware
components.  Slap them together, and you have your product.

That being the case, the question of "what happens when the company goes
bankrupt" becomes less of an issue so long at the company who supplied
the IP stack is still around.  By government implementing some
not-unpleasant rules, the companies can outsource the IP stack portion,
including updates.  Then the manufacturers can concentrate on the value
add stuff.

For durable goods like refrigerators and thermostats, you could require
that the IP-capable part be in a plug-replaceable module, so that all
the customer needs to do is go to Home Depot or wherever and get a
replacement module.  Instant update!  The back end of the module would
be a well-defined API so the manufacturer can do his product, divorced
from the Net stuff.  Indeed, it wouldn't take long for the various
industry associations to codify what the modules should look like, both
physically and electrically.

The semiconductor industry did this big time in the TTL days.  There is
precedent.

So what if your washing machine is working perfectly well 15 years into
its lifecycle.  You replace the network module and get the latest and
greatest security updates.

Light bulbs are harder, but even then there is an opportunity for
someone to market an "industry standard" interface that can be upgraded
easily and cheaply.  By the original software vendor.

Can someone say "IoTsoft"?

Re: Should abuse mailboxes have quotas?

[Stephen Satchell]

On 10/27/2016 05:36 PM, Jimmy Hess wrote:
> If you get a SMTP reject, then call the the Abuse POC of the organization you
> need to report abuse from.

Not when the mailbox-full bounce is from a network in China, or India,
or Pakistan, or Russia.  Or a couple of other countries that seem to be
spam havens.

What is my ROI on the cost of the phone call.  MUCH cheaper to put in
netrange blocks, and less time, not to mention the language barriers.  I
can't run a telephone call through Google Translate...

It's NOT MY JOB to accept packets from people who can't seem to follow
the accepted rules of the Internet.  I pine for the old NSF days, when a
sysadmin had to be a BOFH to keep the local network connected to the
'Net at large.  I don't want to suppress innovation as much as the next
guy, but not at the expense of having to deal with childish morons and
greedy bastards who think they can do what they want.  Because no one
disconnects them, they are sent the wrong message about what's permissible.

(I'm grumpy because a couple of days ago I got tangled up in some
medical gear, and ended up slamming my knee squarely into a marble
floor.  It hurts, it does.)

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Stephen Satchell]

On 10/28/2016 04:32 PM, Mark Andrews wrote:
> It's not the RIR's job.  They already provide the framework for
> ISP's to do the job of policing route announcements themselves.
> ISP's just need to use that framework.

Link to documentation on how to use that framework?

Re: Spitballing IoT Security

[Stephen Satchell]

On 10/28/2016 10:14 PM, b...@theworld.com wrote:
> Thus far the goal just seems to be mayhem.

Thus far, the goal on the part of the botnet opearators is to make
money.  The goal of the CUSTOMERS of the botnet operators?  Who knows?

Port 2323/tcp

[Stephen Satchell]

I've been seeing a lot of rejections in my logs for 2323/tcp.  According
to the Storm Center, this is what the Mirai botnet scanner uses to look
for other target devices.

Is it worthwhile to report sightings to the appropriate abuse addresses?
 (That assumes there *is* an abuse address associated with the IPv4
address that is the source.)  Would administrations receiving these
notices do anything with them?

Alternatively, is there anyone collecting this information from people
like me to expose the IP addresses of possible infections?

I am toying with the idea of setting up a honey-pot, but I'm so far
behind with $DAYJOB that such a project will have to wait a bit.

I want to be a good net citizen.  I also want to make sure I'm not
wasting my time.

Today's crop:

> 1.34.169.183
> 12.221.236.2
> 14.138.22.12
> 14.169.142.30
> 14.174.71.158
> 14.177.197.101
> 31.168.146.33
> 31.168.212.174
> 36.71.224.179
> 36.72.253.206
> 37.106.18.86
> 42.115.187.189
> 42.117.254.248
> 42.119.228.222
> 43.225.195.180
> 46.59.6.249
> 49.114.192.91
> 58.11.238.146
> 58.186.231.59
> 59.8.136.21
> 59.49.191.4
> 59.57.68.56
> 59.126.35.47
> 59.126.242.70
> 59.127.104.67
> 59.127.242.8
> 60.251.125.125
> 61.219.165.38
> 73.84.152.194
> 78.179.113.148
> 78.186.61.30
> 78.189.169.142
> 78.226.222.234
> 79.119.74.255
> 81.16.8.193
> 81.101.233.14
> 81.214.121.43
> 81.214.134.133
> 81.214.137.197
> 82.77.68.189
> 83.233.40.141
> 85.96.202.199
> 85.99.121.41
> 85.238.103.111
> 86.121.225.48
> 87.251.252.22
> 88.249.224.167
> 89.122.87.239
> 89.151.128.198
> 90.177.91.201
> 92.53.52.235
> 92.55.231.90
> 94.31.239.178
> 94.254.41.152
> 94.255.162.90
> 95.78.245.54
> 95.106.34.92
> 95.161.236.182
> 96.57.103.19
> 101.0.43.13
> 108.203.68.245
> 110.55.108.215
> 110.136.233.10
> 112.133.69.176
> 112.165.93.130
> 112.186.42.216
> 113.5.224.110
> 113.161.64.11
> 113.169.18.153
> 113.171.98.158
> 113.172.4.204
> 113.183.204.112
> 113.188.44.246
> 114.32.28.219
> 114.32.87.32
> 114.32.189.5
> 114.34.29.167
> 114.34.170.10
> 114.35.153.123
> 114.226.53.133
> 115.76.127.118
> 116.73.65.248
> 116.100.170.92
> 117.0.7.77
> 117.1.26.234
> 117.195.254.3
> 118.32.44.99
> 118.42.15.21
> 118.43.112.120
> 118.100.64.159
> 118.163.191.208
> 119.199.160.207
> 119.202.78.47
> 120.71.215.81
> 121.129.203.22
> 121.178.104.129
> 121.180.53.143
> 122.117.245.28
> 123.9.72.86
> 123.16.78.77
> 123.23.49.149
> 123.24.108.10
> 123.24.250.187
> 123.25.74.209
> 123.27.159.13
> 123.240.245.72
> 124.66.99.251
> 124.131.28.38
> 125.166.193.206
> 125.227.138.132
> 138.204.203.66
> 171.97.245.221
> 171.224.7.147
> 171.226.20.220
> 171.232.118.93
> 171.248.210.120
> 171.249.223.213
> 171.250.26.209
> 173.56.21.67
> 175.138.81.130
> 175.203.202.232
> 175.207.137.139
> 175.211.251.156
> 177.207.49.108
> 177.207.67.170
> 177.223.52.193
> 178.222.246.96
> 179.4.140.63
> 179.235.55.39
> 179.253.163.107
> 180.73.117.62
> 180.254.224.10
> 182.37.156.98
> 182.180.80.75
> 182.180.123.43
> 183.46.49.216
> 183.144.245.235
> 186.19.48.158
> 186.69.170.130
> 186.219.1.156
> 187.104.248.17
> 187.211.63.51
> 188.209.153.15
> 189.101.220.244
> 189.234.9.147
> 191.103.35.250
> 191.180.198.31
> 191.249.21.41
> 196.207.83.23
> 197.224.37.108
> 201.243.225.103
> 210.178.250.121
> 211.7.146.51
> 211.216.202.191
> 213.5.216.213
> 213.14.195.100
> 213.170.76.149
> 217.129.243.48
> 218.161.121.178
> 218.186.43.224
> 220.85.169.133
> 220.132.111.124
> 220.133.24.142
> 220.133.198.71
> 220.133.234.229
> 220.134.132.200
> 220.134.193.133
> 220.135.64.43
> 221.145.147.78
> 221.159.105.17
> 221.167.64.53
> 222.254.238.188
> 223.154.223.159

BCP38 and Red Hat

[Stephen Satchell]

https://bugzilla.redhat.com/show_bug.cgi?id=1370963

Just a reminder that I have a feature request outstanding with Red Hat
to add support for BCP38, as well as measures for certain protocol-based
amplification reflection attacks.  My intent for making the suggestion
is to stiffen firewalld(8) in Red Hat Enterprise and clones,
particularly when an RHEL-based box is used as an edge router or
firewall box.

I've looked at firewalld, and it would be easy to add *some* of BCP38
into it rather quickly...assuming that the developers step up to the
plate.  There are parts of BCP38 that won't be so easy to do, given the
architecture of the package.

In my spare time, by the way, I'm working on a BCP-compilant firewall
generator for IPTABLES.  Spare time?  Well, that *is* a bit of a laugh...

Re: South Carolina attempts to repeal Rule 34

[Stephen Satchell]

On 12/19/2016 11:39 PM, Jay Hennigan wrote:
> Break out the popcorn.
> 
> http://www.charlotteobserver.com/news/local/article121673402.html
> 

"A bill pre-filed this month by state Rep. Bill Chumley would require
sellers to install digital blocking capabilities on computers and other
devices that access the internet to prevent the viewing of obscene content."

1.  Buy computer without the $20 tax
2.  Erase operating system
3.  Install Linux Mint (or one's favourite distribution)
4.  PROFIT!

"The bill would fine manufacturers that sell a device without the
blocking system..."

How about if the manufacturer doesn't install an operating system?

Getting this vaguely back to NANOG territory, this is a far greater
improvement over the "plan" to have ISPs block the traffic on their side
of the customer/ISP interface.  THAT is just an invitation to pick up a
mallet and play whack-a-mole...

(N.B.: if this were extended to other states, like Nevada, then stores
like Suzie's in Reno would only increase their business selling porn DVDs.)

Re: Is WHOIS going to go away?

[Stephen Satchell]

On 04/25/2018 07:10 AM, ke...@contoocook.net wrote:

Well, personally for me, I use secret registration because I was tired of all 
the spam I got. Spammers scrape whois data for email addresses. I not trying to 
hide my identity on the web, I just don't like spam. I'm not some dark evil 
force.
Cheers, Keith



What I find interesting is that I didn't get all that much spam from my 
small collection of domains.  Of course, the e-mail addresses associated 
with those domains is "ad...@satchell.net" (and "ab...@satchell.net"). 
Indeed, abuse is completely ignored by spammers, while admin gets a 
couple of pieces of Far East spam a week.  That's right, a week.


I bought privacy service now, as well as renewal protection.  I've lost 
three domains, and don't want to lose any more.

Re: Remote power cycle recommendations

[Stephen Satchell]

I've worked with APC, Synaccess, and a couple other brands of power 
controllers.  One constant:  the IP stack implementations tend to be a 
bit fragile.  This is not restricted to power controllers; I have a GPS 
NTP appliance that is affected by the same sorts of things.


I'll stick with APC and Synaccess, because I currently work with those. 
You want to avoid presenting these conditions to the embedded stack:


1.  ARP storms
2.  Lots of layer 2 and layer 3 broadcast traffic
3.  Probes for ports not implemented in the stack
4.  Too much traffic (SNMP in particular)

I like keeping all such devices on a single management VLAN dedicated to 
embedded-stack devices.  The Ethernet hardware tends to be competent at 
filtering packets not intended for the device, so you don't have to go 
overboard with VLANs.  It's the software behind the hardware that is 
easy to overwhelm if you throw too many packets at it.


(But you knew this already)

Re: Remote power cycle recommendations

[Stephen Satchell]

On 04/30/2018 10:05 AM, William Herrin wrote:

On Mon, Apr 30, 2018 at 12:19 PM, Brielle Bruns  wrote:

In particular, if at all possible, do not use the AP9606 era cards with the
APCs.  They are 10BaseT and take fragile to a whole new level.  I usually
have to manually force the port to 10 on the switch or put it on a cheap
dumb older switch.

They're fragile but they're not_that_  fragile. A switch that can't
figure out 10 mbps half duplex... now that's fragile.


Personally, I've not run into THAT problem in years.  What I have run 
into is when you have a 10base-T target and you connect it to a 
100base-T (or faster) infrastructure, the switch as part of the rate 
changing will tend to flood the poor embedded stack if your application 
layer isn't very, very careful to space out packets.


At best your embedded-stack device will lose packets.  At worst, you 
will have to power-cycle the poor dear in order to get it to start 
listening to the network again.


Let me repeat, this observation is not restricted to the AP9606 cards; 
it seems to be an issue with embedded-stack devices in general.


Subject change:  one other thing about the AP9606 cards:  they have a 
battery on them, and you do have to change that battery every decade or 
so...

Re: DSL Operators Mailing List?

[Stephen Satchell]

On 05/08/2018 07:12 AM, Mike Hammett wrote:

I made a Facebook group for xLEC-related things.



(Not useful for those of us not on Facebook.)

Re: DSL Operators Mailing List?

[Stephen Satchell]

In other words, status quo ante?

On 05/08/2018 10:16 AM, Mike Hammett wrote:

Then don't participate and move on?
 
-

Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -

From: "Stephen Satchell" 
To: nanog@nanog.org
Sent: Tuesday, May 8, 2018 11:19:30 AM
Subject: Re: DSL Operators Mailing List?

On 05/08/2018 07:12 AM, Mike Hammett wrote:

I made a Facebook group for xLEC-related things.



(Not useful for those of us not on Facebook.)

Re: Email security: PGP/GPG & S/MIME vulnerability drop imminent

[Stephen Satchell]

On 05/15/2018 02:34 AM, Rich Kulawiec wrote:

On Mon, May 14, 2018 at 01:47:50PM +0530, Suresh Ramasubramanian wrote:

TL;DR = Don't use HTML email [snip]


That's enough right there.  HTML markup in email is used exclusively
by three kinds of people: (1) ignorant newbies who don't know any
better (2) ineducable morons who refuse to learn (3) spammers.
There are no exceptions.


Yes, there are exceptions.  Particularly, chemists (and chemical 
engineers) and physicists who need to embed formulas into their e-mail. 
They use HTML because it's fast and easy, instead of using the preferred 
method of building a PDF and sending that.


(I had a long, unfruitful argument with my brother the chem engineer at 
the time my mail server rejected all incoming HTML mail.  I had to change.)


Another exception is that most webmail is HTML and plaintext in MIME format.

I get around the problem of triggering code in Thunderbird by only using 
the plain text view, dropping to "simplified HTML" view only when 
necessary, and only when I know the sender.

Re: Whois vs GDPR, latest news

[Stephen Satchell]

In a related note, I received a note from my registrar this morning 
telling me that, per current ICANN rules, I need to verify all the 
personal identifying information for the domains I control.


1.  I checked WHOIS for all my domains, and they point to the proxy 
service that my registrar offers.  So, I have no PII visible via WHOIS.


2.  I checked the contact information page, and all my (hidden) PII is 
correct.


So, at least for my domains, everything is GDPR compliant as far as 
public display is concerned.  The question about the proxy service 
providing an anonymous tunnel for, say, abuse e-mail is open to 
question.  As well as all the other bells and whistles I've seen discussed.


By the way, setting up the proxy service just takes money, not time, in 
the old school.


The fines are heavy enough that the registrars can consider forcing 
proxy service on all domains, and figure out how to recoup the costs 
later.  Months?  I don't think so.


But then again, I'm not a registrar, only a customer of those folks.

On 05/17/2018 08:29 AM, Niels Bakker wrote:

* br...@ampr.org (Brian Kantor) [Thu 17 May 2018, 16:23 CEST]:

An article in The Register on the current status of Whois and the GDPR.

https://www.theregister.co.uk/2018/05/16/whois_privacy_shambles/


My registrar already does all the things listed in this article that 
registrars supposedly don't yet do.


American companies that think they have a need, or even the right, to 
see the billing address for my personal domain can go pound sand.



 -- Niels.

Re: Curiosity about AS3356 L3/CenturyLink network resiliency (in general)

[Stephen Satchell]

On 05/18/2018 04:20 AM, Tom Hill wrote:

On 17/05/18 14:24, Mike Hammett wrote:

There's some industry hard-on with having a few ginormous routers instead of 
many smaller ones.


"Industry hard-on", ITYM "Greedy vendors".


I think this view (both versions) are a little over the top.  "Never 
attribute to malice that which can be explained by stupidity."


The "stupidity" in this instance is poor market analysis, perhaps with 
the market research folks concentrating on large service provider 
customers at the expense of enterprise customers with very, very large 
data traffic needs but fewer ports per location.


They could also be concentrating on the very large providers working on 
the theory that the rate of return on boxes requiring a fork lift to 
install is higher than the rate of return on the 1U or 2U variety.



Try finding a 'small' router with a lot of ports (1 & 10GE) for your
customers, and the right features/TCAM/CP performance, for a price that
permits you to buy a lot of them.


What happened when you sent out your last RPQ to the vendors with these 
requirements?

Re: Whois vs GDPR, latest news

[Stephen Satchell]

On 05/23/2018 09:09 AM, Anne P. Mitchell Esq. wrote:

Also, don't forget the private right of action.  Anyone can file
anything in the U.S. courts... you  may get it dismissed (although
then again you may not) but either way, it's going to be time and
money out of your pocket fighting it.  MUCH better to just get
compliant than to end up a test case.


And that's why my domains use Register.com's proxy service.  I'm 
risk-adverse, especially with the revenue (pennies) my domains earn. 
Better to just bite the bullet.


That said, I have abuse contacts listed for my domains.  You just have 
to ask the proxy for them.


(In 15 years, the only abuse mail I've received is mail from people who 
HATED what I said on NANAE newsgroup...and I've not used USENET for 10 
of those years.)

Re: Whois vs GDPR, latest news

[Stephen Satchell]

On 05/27/2018 12:54 PM, niels=na...@bakker.net wrote:
> You have this the wrong way around.  You'll need permission to store
> their IP address in logs that you keep and to inform third parties about
> their visits to your site.  And that is because that information belongs
> to the visitor, not to you.

This is going to run afoul of some data retention laws currently on the
books in some places.  You *have* to keep logs, WITH IP addresses...

Re: Whois vs GDPR, latest news

[Stephen Satchell]

This is really off-topic for NANOG.  Is there a better place where this
discussion can be found?