Re: Automated Abuse Reports

[Matt Palmer]

On Mon, Oct 07, 2019 at 05:28:08PM -0700, Matt Corallo wrote:
> Because people seem to include “you tried three to log
> in three times and got the password wrong” in their definition of abuse,
> I’ve had to provide bogus abuse contacts (and include actual abuse
> comments in the comments section).  I’ve tried reaching out to other
> operators suggesting that they cut it out, as they are the reason many
> operators do not provide functional abuse contacts, usually with a
> response of “so stop attacking my serverz!!!1one”.

Fight fire with fire, and report their abuse of your abuse contact as abuse
to their (or their upstream's) abuse contact?  More seriously, though, if
someone insists on reporting (automatically or otherwise) seriously bogus
"abuse" a couple of times, I don't think it's unreasonable to block / filter
that specific reporter from further calls on your attention.

What would also be reasonable, I think, is to require automatically
generated abuse reports to themselves be automatically processable.  That
requires some way of *detecting* automatic generation, of course, but it
might encourage a few people to adopt machine-readable abuse reports.

> Is it time to have ARIN add a “abuse contact available only after captcha”
> option?

I'd prefer if it wasn't, because it seems somewhat of a "baby/bathwater"
solution, just to deal with a few GWFs (GsWF?).

> On the flip side, I run a Tor exit node (as well as bridge nodes, which
> appear to be used exclusively by Chinese, Russian, and Iranian IPs,
> indicating Tor is, contrary to popular belief, used in large part for its
> intended purpose).

[Rearranging this paragraph because it is a side-bar from the main issue]

I suspect that if you checked the stats on your guard nodes (if you have
any) the stats would be somewhat different.  Bridges, by their nature, are
less likely to be used by miscreants because they're harder to get (have to
ask BridgeDB) and nobody gets all of them.  If you're just out to anaonymise
your source IP and you're in a location that doesn't imprison and torture
you for reading the news, it's a lot easier to just use a regular
guard/middle/exit circuit.

I'm not calling this out because I'm a Tor-hater; on the contrary, I too run
Tor nodes (bridges and relays; no exit nodes).  It's just that it's somewhat
misleading to suggest that Tor isn't the tool of choice for people who'd
prefer to cause mischief without anyone knowing what they're up to.  I
support Tor because the benefits outweigh the unpleasantness it
(necessarily) permits.

- (Another) Matt

Re: IPv6 Pain Experiment

[bzs]

Well if you all really want your heads to explode I was invited to
give a talk a few years ago in Singapore at the local HackerSpace.

It called for something creative and different, not really an IETF
sort of crowd.

So I proposed we dump numeric addresses entirely and use basically
URLs in IP packets and elsewhere.

I really meant something like 'IP://www.TheWorld.com' in the
source/dest addr, possibly more specific for multiple interfaces but
whatevs.

Leave out the implied 'IP://' and my example is 16 chars just like
IPv6.

Routers could of course do what they like with those internally such
as maintain a hash table to speed look-ups. Not anyone outside of
router software developers' problem.

If one agreed on a standard hash algorithm further performance
improvements could be realized (e.g., inter-router comm could add the
hashes, who cares, implementation nit.)

So the question is how long would these be on average and even if it
was a little longer would anyone care? Is a nanosecond saved really a
nanosecond earned?

We're already kind of committed to IP addresses not really meaning
anything (that is, no routing info implied), they are mostly only a
way to pick the next interface to push the packet out of and only need
to be unique, sort of, with exceptions (umm, multicast.)

BITS IS BITS. They're just bits either way. And in my proposal pretty
easy to remember bits.

And Look Ma! No more DNS! Or a much reduced role.

I'd agree the idea is several RFCs short of an internet but hey it's
something to think about.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: IPv6 Pain Experiment

[Joel Halpern]

Folks should be aware that if you do not assume extreme pressure (which 
is what it is taking to get IPv6 deployed), it turns out to be quite 
hard to get the deployment incentives and structures for a 
map-and-encaps scheme to actually work for Internet-wide deployment.  It 
does work for a range of special cases.


Yours,
Joel

On 10/7/2019 10:58 PM, Michel Py wrote:

William Herrin wrote :
I was out to prove a point. I needed a technique that, at least in theory, 
would start working as a result of software
  upgrades alone, needing no configuration changes or other operator 
intervention. If I couldn't do that, my debate
opponent was right -- a greenfield approach to IPv6 made more sense despite the 
deployment challenge.


I think that, 12 years ago, you had the best mouse trap.


Map-encap, where you select a decapsulator (consult the map) and then send a 
tunneled packet (encapsulated) does
some cool stuff, but it's a pretty significant change to the network 
architecture. Definitely not configuration-free.


I am so painfully aware of this.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> Owen DeLong wrote :
> Well… I don’t run into this very often any more, but I guess if you have a 
> poorly run DNS environment, it might be more of an issue.

About half of my devices, including all the VOIP phones, do not have DNS. I 
just cannot afford to lose the phones if there is a DNS failure. They have 
DHCP, but not DNS.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

RE: IPv6 Pain Experiment

[Michel Py]

> William Herrin wrote :
> I was out to prove a point. I needed a technique that, at least in theory, 
> would start working as a result of software
>  upgrades alone, needing no configuration changes or other operator 
> intervention. If I couldn't do that, my debate
> opponent was right -- a greenfield approach to IPv6 made more sense despite 
> the deployment challenge.

I think that, 12 years ago, you had the best mouse trap.

> Map-encap, where you select a decapsulator (consult the map) and then send a 
> tunneled packet (encapsulated) does
> some cool stuff, but it's a pretty significant change to the network 
> architecture. Definitely not configuration-free.

I am so painfully aware of this.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: IPv6 Pain Experiment

[Karl Auer]

On Mon, 2019-10-07 at 18:02 -0700, Owen DeLong wrote:
> It certainly would have been a higher level of pain in the short run,
> but it also would have led to a much shorter period of pain.

There's a thing in (biological) evolution that says a species cannot
become less fit, even if that is the best or only path to greater
fitness.

We operate as intelligent entities only as individuals. As a group, we
are as dumb as any bacterium.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 8D08 9CAA 649A AFEF E862 062A 2E97 42D4 A2A0 616D
Old fingerprint: A0CD 28F0 10BE FC21 C57C 67C1 19A6 83A4 9B0B 1D75

Re: IPv6 Pain Experiment

[Owen DeLong]

> On Oct 5, 2019, at 13:36 , b...@theworld.com wrote:
> 
> 
> On October 4, 2019 at 15:26 o...@delong.com (Owen DeLong) wrote:
>> 
>> OK… Let’s talk about how?
>> 
>> How would you have made it possible for a host that only understands 32-bit 
>> addresses to exchange traffic with a host that only has a 128-bit address?
> 
> A bit in the header or similar (version field) indicating extending
> addressing (what we call IPv6, or similar) is in use for this packet.
> 

This still requires you to basically rewrite the L3 stack to accommodate the 
new addresses.

> They may not be able to talk but rather than a whole new stack it
> would have just been an extension of the commonly used IPv4 stack,
> more like a (e.g.) new ICMP option.

Uh, no, it would still have required reimplementing the entire L3 stuff at 
pretty much the same
work level as the current IPv6 mechanism. You would still have needed to update:

All L4->L3 binding code
All Name Resolution code

You’d still be faced with all the really hard problems that came with 
IPv4->IPv6 transition:

Updating your applications to understand 128-bit addresses in logs, etc.
Updating your provisioning systems to track 128-bit addresses.
etc.

> Or even an octet indicating how many octets in this address, default
> would be four (or even a nybble indicating how many 16-bit words.)

This doesn’t make transition any easier and it makes ASIC processing of
packet forwarding a heck of a lot harder.

> Something simple like that could have, at least in the early stages
> (which we're still in w/ IPv6 unfortunately), have been entirely
> handled in userspace in the software.

Nope… It really couldn’t and that would actually be worse… Right now, the 
biggest hurdles
to IPv6 adoption aren’t the kernel level changes for a new stack, they’re the 
legacy application
changes needed to support bigger addresses.

> IPv4? Do the usual. Extended addressing? Hand to a userspace
> library. A minor poke to the drivers plus the userspace software. In
> many cases wouldn't even require a reboot to install, but at worst a
> quick reboot to install the low-level driver that knows to switch
> extended addressing packets to userspace.

I think you’re very confused about where the pain points with IPv6 are and what 
it would
take to actually implement what you are suggesting here.

> Particularly if the low 32 bits indicated the same IPv4 interface w/in
> a campus so primarily only the routers needed to interpret the rest of
> the address.

Uh, so a packet arrives at your 32-bit only application and you can’t tell 
whether you
need to reply to the student’s laptop on the other side of the room or the 
linear
accelerator 3,000 miles away because that’s all included in the 96 bits you 
didn’t even
see that got spirited away to some user-space translator layer.

What am I missing?

> So it'd get to the right router who'd hand it off to the right
> (32-bit) host. Only a problem if your campus happened to have 4B+
> hosts (or maybe 2B+), not likely.

Or if you need to communicate both within and outside of your campus (far more 
likely).

> It's similar to IPv4v6 stacks but the host would return the full
> address in the (extended) IP packet.

How’s the host supposed to do that if the host hasn’t been updated to handle 
extended
addressing? If the host has been updated, then there’s no difference from the 
current
situation with IPv6… The need to update every host (and these days, more 
relevant,
the need to update every application).

> In current IPv4v6 stacks (NAT et al) the router has to keep track and
> interpolate by rewriting the packets or similar. In what I describe
> that's not necessary as each packet retains the full address as it
> passes through the host.

Yeah, except, you’re assuming every host gets updated with the necessary 
software to
handle essentially IPv6 addressing without adding the IPv6 stack. This sounds 
like more
pain for less gain to me.

> Well, basically your question asks for a complete stack design right
> here right now, is that really where we want to go?

My point is that the changes to implement IPv6 on a given host (at the kernel 
level) are
not significantly more than the changes you are proposing to do what you want. 
Difference
is that they’ve mostly been done for the vast majority of hosts for IPv6 
whereas yours would
be a new implementation.

It still doesn’t yield any greater compatibility because you’ve still got the 
difficulty of coping
with the applications that simply can’t understand a larger internet (which is 
the biggest hurdle
with IPv6 right now).

> But the sort of thing I suggest was suggested.

And did not gain consensus for the same reasons I outline above, I suspect.

> Some of the considerations as to why not do it this way were good,
> such as get some other bugs/limitations out of IPv4. And some not so
> good like bit-level performance and compatibilty considerations that
> have changed 

Re: IPv6 Pain Experiment

[William Herrin]

On Mon, Oct 7, 2019 at 5:31 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> William Herrin wrote:
>
> > I was out to prove a point. I needed a technique that, at least in
> theory,
> > would start working as a result of software upgrades alone, needing no
> > configuration changes or other operator intervention.
>
> I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P,
> which is obviously fully operational with existing IPv4 backbone, is
> better.


Not a fan of port numbers.  If we're going to replace TCP and UDP, initiate
the link with a name (e.g. dns name), negotiate a connection ID and
continue with the connection ID.

No ports, no port scanning.

QUIC comes pretty close to getting it right.

-Bill


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: IPv6 Pain Experiment

[Masataka Ohta]

William Herrin wrote:


I was out to prove a point. I needed a technique that, at least in theory,
would start working as a result of software upgrades alone, needing no
configuration changes or other operator intervention.


I think TCPng/UDPng with 32/48 bit port numbers combined with NAT/A+P,
which is obviously fully operational with existing IPv4 backbone, is
better.

Masataka Ohta

Automated Abuse Reports

[Matt Corallo]

How do people view the automated generation of abuse reports? I’ve seen lots of 
(understandable) moaning about large providers not handling abuse reports, and 
lots of (understandable) suggestions that ARIN test for the reachability of 
abuse contacts.

On the flip side, I run a Tor exit node (as well as bridge nodes, which appear 
to be used exclusively by Chinese, Russian, and Iranian IPs, indicating Tor is, 
contrary to popular belief, used in large part for its intended purpose). 
Because people seem to include “you tried three to log in three times and got 
the password wrong” in their definition of abuse, I’ve had to provide bogus 
abuse contacts (and include actual abuse comments in the comments section). 
I’ve tried reaching out to other operators suggesting that they cut it out, as 
they are the reason many operators do not provide functional abuse contacts, 
usually with a response of “so stop attacking my serverz!!!1one”.

Is it time to have ARIN add a “abuse contact available only after captcha” 
option?

Matt

Re: IPv6 Pain Experiment

[William Herrin]

On Mon, Oct 7, 2019 at 3:32 PM Michel Py  wrote:
> >> Michel Py wrote :
> >> When did you write this ? I read it before, just can't remember how
long ago.
>
> > William Herrin wrote :
> > 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread
titled "The myth of IPv6-IPv4 interoperation."
> > On one side of the argument, folks saying that the need to manage two
configurations impairs IPv6's deployment.
> > On the other, an individual  whose thesis was the IPv6 could not have
been designed to be backwards compatible
> > with IPv4 in a way that required no new configuration, just
incremental, backward-compatible software upgrades.
>
> Why did you choose this route, instead of encapsulating the packet with
the extended address into an IPv4 packet ?

I was out to prove a point. I needed a technique that, at least in theory,
would start working as a result of software upgrades alone, needing no
configuration changes or other operator intervention. If I couldn't do
that, my debate opponent was right -- a greenfield approach to IPv6 made
more sense despite the deployment challenge.

Map-encap, where you select a decapsulator (consult the map) and then send
a tunneled packet (encapsulated) does some cool stuff, but it's a pretty
significant change to the network architecture. Definitely not
configuration-free.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

RE: IPv6 Pain Experiment

[Michel Py]

>> Michel Py wrote :
>> When did you write this ? I read it before, just can't remember how long ago.

> William Herrin wrote :
> 2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread titled 
> "The myth of IPv6-IPv4 interoperation."
> On one side of the argument, folks saying that the need to manage two 
> configurations impairs IPv6's deployment.
> On the other, an individual  whose thesis was the IPv6 could not have been 
> designed to be backwards compatible
> with IPv4 in a way that required no new configuration, just incremental, 
> backward-compatible software upgrades.

Why did you choose this route, instead of encapsulating the packet with the 
extended address into an IPv4 packet ?

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: AWS issues with 172.0.0.0/12

[Mehmet Akcin]

To close the loop here (in case if someone has this type of issue in the
future), I have spoken to AT instead of trying to work it out with AWS
Hosted Vendor, Reolink.

AT Changed my public IP, and now I am no longer in that 172.x.x.x block,
everything is working fine.

mehmet

On Thu, Oct 3, 2019 at 2:54 PM Javier J  wrote:

> Auto generated VPC in AWS use RFC1819 addresses. This should not interfere
> with pub up space.
>
> What is the exact issue? If you can't ping something in AWS chances are
> it's a security group blocking you.
>
>
>
> On Tue, Oct 1, 2019, 7:00 PM Jim Popovitch via NANOG 
> wrote:
>
>> On October 1, 2019 9:39:03 PM UTC, Matt Palmer 
>> wrote:
>> >On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
>> >wrote:
>> >> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
>> >> > possible that this is various AWS customers making
>> >iptables/firewall mistakes?
>> >> >"block that pesky rfc1918 172/12 space!!"
>> >>
>> >> AWS also uses some 172/12 space on their internal network (e.g. the
>> >network
>> >> that sits between EC2 instances and the AWS external firewalls)
>> >
>> >Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
>> >different
>> >things, after all.
>> >
>>
>> I don't know their entire operations, but they do use some 172.16.0.0/12
>> addresses internally. And yes, that is very different than 172/12, sorry
>> for the confusion.
>>
>> -Jim P.
>>
>>

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: IPv6 Pain Experiment

[William Herrin]

On Mon, Oct 7, 2019 at 11:34 AM Michel Py  wrote:
> > William Herrin wrote :
> > I want to divert from the current flame war to make my biennial
semi-serious reminder that it was at least theoretically possible to
> > expand the IPv4 address space rather than make a whole new protocol.
That we did not do so was a failure of imagination.
> > http://bill.herrin.us/network/ipxl.html
>
> That could have worked. Eventually, some form of IPv4 with "just" more
bits could surface, but it will take a decade or more.
> When did you write this ? I read it before, just can't remember how long
ago.

2007. Half of IPv6's lifetime ago. It came out of an ARIN PPML thread
titled "The myth of IPv6-IPv4 interoperation." On one side of the argument,
folks saying that the need to manage two configurations impairs IPv6's
deployment. On the other, an individual whose thesis was the IPv6 could not
have been designed to be backwards compatible with IPv4 in a way that
required no new configuration, just incremental, backward-compatible
software upgrades.

-Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: dns cache beyond ttl - viasat / exede

[William Herrin]

On Mon, Oct 7, 2019 at 11:56 AM Brielle  wrote:
> On 10/7/2019 12:15 PM, William Herrin wrote:
> > This is the action of the TCP accelerator. TCP has a "long fat pipe"
> > problem where high-delay links (like a trip to geostationary orbit and
> > back) demolish throughput. To combat this, satellite protocols translate
> > TCP flows to a non-TCP or modified TCP protocol for transmission through
> > the satellite and then back to TCP in the modem.
>
> Yeah, its just one of those things that really messes with you when you
> are trying to diagnose obscure error messages and application behavior.
>
> Usually I'd be in a place 50+ miles from nearest town with cell service,
> only accessible via jetboat...  stuck on Iridium sat phone at $5/min
> with the Sat company, their utterly useless first level support that
> refuses to actually get a network engineer involved...
>
> I'm a patient, tolerant woman normally with tech support, but the sat
> internet providers push you into a red zone so quickly with their
support...

You don't happen to have some documented examples of this do you? I could
use examples of stuff that broke and was hard to diagnose and fix due to
unexpected proxying behavior for an argument I'm having elsewhere.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Poor mans TAP

[Nick Hilliard]

Dovid Bender wrote on 07/10/2019 18:10:
The issue is that the traffic coming in, is coming from a Juniper switch 
where the traffic has vlan tags on the packets.


you might want to disable it on the entire vlan.

Nick

Re: This DNS over HTTP thing

[David Conrad]

On Oct 7, 2019, at 10:45 AM, Jim  wrote:
> My suggestion would be ultimately that DNS Clients implement DNSSEC

> validation themself to avoid tampering by a malicious client on their network
> for phishing purposes or a malicious recursive DNS Resolver server

Yep. That is (IMHO) the right (only) answer to actually fix the ‘lying’ problem 
instead of making it “someone else’s problem", although that turns lies into 
DoS when all you get back from your resolver is unvalidatable answers.

To solve this problem, browser vendors really should implement validation in 
their stub resolvers. This would have the benefit that if validation fails, a 
useful error message could be presented to the user (e.g., “the website name 
you looked up has been tampered with!”).  Instead, they have chosen to rely on 
their “trusted recursive resolvers” to not lie to them and use agreements 
rather than code.

This, of course, doesn’t stop the snooping/metadata collection problem.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: dns cache beyond ttl - viasat / exede

[Brielle]

On 10/7/2019 12:15 PM, William Herrin wrote:
On Mon, Oct 7, 2019 at 10:13 AM Brielle > wrote:


* Responding to three way handshake before the other end actually does
(nmap -sT remote host ends up with every port being 'open' but closing
connection right away)


This is the action of the TCP accelerator. TCP has a "long fat pipe" 
problem where high-delay links (like a trip to geostationary orbit and 
back) demolish throughput. To combat this, satellite protocols translate 
TCP flows to a non-TCP or modified TCP protocol for transmission through 
the satellite and then back to TCP in the modem.



Yeah, its just one of those things that really messes with you when you 
are trying to diagnose obscure error messages and application behavior.


Usually I'd be in a place 50+ miles from nearest town with cell service, 
only accessible via jetboat...  stuck on Iridium sat phone at $5/min 
with the Sat company, their utterly useless first level support that 
refuses to actually get a network engineer involved...


I'm a patient, tolerant woman normally with tech support, but the sat 
internet providers push you into a red zone so quickly with their support...




--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

RE: This DNS over HTTP thing

[Kevin McCormick]

So a malicious or rogue DNS operator... 1.1.1.1 or 8.8.8.8 is going to tell 
your application to use the locally configured DNS for domain lookups rather 
give an normal response? Not sure how this malice would really affect you as 
your local DNS should be functional. The idea to make DoH and DoT, or even 
unencrypted DNS with external DNS servers play nicely with environments that 
require internal users to local DNS for local domains.

The point is having a record to tell severs like 1.1.1.1 and 8.8.8.8 when they 
should not respond normally to specific clients from a specific source for 
specific domains.

You will always have malicious cases and scenarios, but a browser configured to 
use DoH or Dot to 1.1.1.1 and 8.8.8.8, I do not see how they would be affected 
when they do use DNSSEC.

Worst case would a user configured network DNS manually rather than using DHCP, 
but still they would be broken as the would be getting a non-working external 
address for a local server.

Thank you,

Kevin McCormick


-Original Message-
From: Jim  
Sent: Monday, October 7, 2019 12:45 PM
To: Kevin McCormick 
Cc: Brandon Martin ; nanog@nanog.org
Subject: Re: This DNS over HTTP thing

On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick  wrote:
>
> If the DNS request comes from an IP in matching a CIDR network address in the 
> ULS record, then the server would respond with an error message telling the 
> application to use the configured local DNS server.

All if this is ultimately falsifiable by a malicious or rogue DNS operator.

My suggestion would be ultimately that DNS Clients implement DNSSEC validation 
themself to avoid tampering by a malicious client on their network for phishing 
purposes or a malicious recursive DNS Resolver server ---  Such a DNS proxy 
service in a home router corrupted by malware that modifies DNS resposes for an 
attacker,  or  those rogue DNS servers of ISPs that typically sometimes replace 
NXDOMAIN replies with A records attempting to collect typo queries for 
advertising or that redirect A records to other hosts designed to intercept and 
monitor or proxy traffic with advertisements inserted.

A secure administrative selection of local DNS server could be supported by 
allowing a TXT record to be placed in the reverse DNS zone for the IP address 
which is the IP address configured on the client's IP network interface 
alongside PTR records.

The client software would then be required to perform a DNSSEC signature check 
to ensure that the reverse DNS zone is signed and has the proper chain of 
signed DS records ultimately coming from the IP6.ARPA  or IN-ADDR.ARPA zone.

*
Clients using RFC1918 IP addresses would not be able to support this;  Because, 
there is no way of  establishing WHO is authorized to sign locally on behalf of 
the "operator" of a RFC1918 or link-local IP address...

The latter seems more like a system administration problem however --

The DHCP software running on a client ought to have some way of indicating 
whether the network being connected to is  Secure and "Managed" by the same 
entity that owns and configures the client device:

I.E.  Same company manages the LAN and the entire path up to recursive
DNS servers are secure,Or whether the PC is owned and managed by
different entities --  such as a  mobile PC user connected to someone else's 
network, or a Home user connected to their own ISP,  and the network is, 
therefore, untrusted.

(Untrusted in the sense that DNS Servers are controlled by a 3rd party who is 
not the owner or operator of the personal computer or client device which is 
connecting for the supposed purpose of accessing the public internet  --- 
therefore no legitimate authority exists for having clients tolerate tampering 
with private traffic between that device and another internet host, content in 
DNS or other IP traffic content, and so on)

> Thoughts?
> Thank you,
> Kevin McCormick
--
-JH

Re: IPv6 Pain Experiment

[Denis Fondras]

On Sun, Oct 06, 2019 at 05:58:39PM -0400, Valdis Klētnieks wrote:
> 8.8.4.5.13.9/40
> 8.8.4.5.17.168/40
> 

This is so unreadable to me :/
My brain keeps on wondering if this is an "IPv4+" or a phone number or a typo...

RE: IPv6 Pain Experiment

[Michel Py]

> William Herrin wrote :
> I want to divert from the current flame war to make my biennial semi-serious 
> reminder that it was at least theoretically possible to
> expand the IPv4 address space rather than make a whole new protocol. That we 
> did not do so was a failure of imagination.
> http://bill.herrin.us/network/ipxl.html

That could have worked. Eventually, some form of IPv4 with "just" more bits 
could surface, but it will take a decade or more.
When did you write this ? I read it before, just can't remember how long ago.

Michel.

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: dns cache beyond ttl - viasat / exede

[William Herrin]

On Mon, Oct 7, 2019 at 10:13 AM Brielle  wrote:

> * Responding to three way handshake before the other end actually does
> (nmap -sT remote host ends up with every port being 'open' but closing
> connection right away)
>

This is the action of the TCP accelerator. TCP has a "long fat pipe"
problem where high-delay links (like a trip to geostationary orbit and
back) demolish throughput. To combat this, satellite protocols translate
TCP flows to a non-TCP or modified TCP protocol for transmission through
the satellite and then back to TCP in the modem.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: dns cache beyond ttl - viasat / exede

[William Herrin]

On Mon, Oct 7, 2019 at 9:08 AM Mike  wrote:

> My dns TTL's are all 300 seconds, and I have noticed that once I
> update the A records with the new addresses, most (but not all) web
> clients begin using the new address within 5 minutes or so. However,
> there is a persistent set of stragglers who continue accessing the
> site(s) on their old addresses for far in excess of this - up to a week
> in fact. And, what I have noted, all of these clients have something in
> common - they all appear to be satellite users of viasat/exede.  This is
> based on whois lookups of the ip addresses of the clients. Note, I am
> NOT expecting 'turn on a time' - just looking for clients to refresh
> within a reasonable time.
>

Hi Mike,

You may be looking at a web browser "feature" called "DNS pinning." This is
used to defeat the "DNS rebinding" attack on javascript that would allow a
web site to instruct a browser to scan the interior behind its user's
firewall by having an attacker rotate the IP addresses used for
Javascript's allowed server name.

Depending on the implementation, DNS pinned browsers may not recognize a
change to your IP address until the browser is stopped and restarted.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

RE: Poor mans TAP

[Kevin Burke]

Netscout has some EoL ones that are on the cheap these days.  These are cheap 
enough to forget at a customer’s site.

https://www.ebay.com/sch/i.html?&_nkw=Netscout+280-0160
Netscout 280-0160

And yes a SPAN port on a switch is where I start sniffing.

Kevin Burke
802-540-0979
Burlington Telecom
200 Church St, Burlington, VT

From: NANOG  On Behalf Of Dovid Bender
Sent: Monday, October 07, 2019 10:17 AM
To: NANOG 
Subject: Poor mans TAP

WARNING!! This message originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.
Hi,

Funds at my 9-5 are limited. Has anyone tried this and how well does it work? 
We plan on mirroring about 800 megs of traffic at peak. 
https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp

TIA.

Dovid

Re: IPv6 Pain Experiment

[William Herrin]

On Fri, Oct 4, 2019 at 4:48 PM Michel Py  wrote:

> > Owen DeLong wrote :
> > How would you have made it possible for a host that only understands
> 32-bit addresses to exchange traffic with a host that only has a 128-bit
> address?
>
> With some kind of NAT mechanism, naturally.
>

I want to divert from the current flame war to make my biennial
semi-serious reminder that it was at least theoretically possible to expand
the IPv4 address space rather than make a whole new protocol. That we did
not do so was a failure of imagination.

http://bill.herrin.us/network/ipxl.html



> > How would you have made a 128-bit address more human-readable? Does it
> really matter?
>
> Everyone gets the numbers.
>

Everyone thinks they get numbers. Until they try to compute a netmask or
perform any other non-rote IP networking task. The people who get hex tend
to actually get numbers. Both ways. If you want to know for sure whether
the other person understood you, explain it in hex.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: This DNS over HTTP thing

[Jim]

On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick  wrote:
>
> If the DNS request comes from an IP in matching a CIDR network address in the 
> ULS record, then the server would respond with an error message telling the 
> application to use the configured local DNS server.

All if this is ultimately falsifiable by a malicious or rogue DNS operator.

My suggestion would be ultimately that DNS Clients implement DNSSEC
validation themself to avoid tampering by a malicious client on their network
for phishing purposes or a malicious recursive DNS Resolver server ---  Such
a DNS proxy service in a home router corrupted by malware that
modifies DNS resposes
for an attacker,  or  those rogue DNS servers of ISPs that typically sometimes
replace NXDOMAIN replies with A records attempting to collect typo queries
for advertising or that redirect A records to other hosts designed to intercept
and monitor or proxy traffic with advertisements inserted.

A secure administrative selection of local DNS server could be supported by
allowing a TXT record to be placed in the reverse DNS zone for the IP address
which is the IP address configured on the client's IP network
interface alongside
PTR records.

The client software would then be required to perform a DNSSEC
signature check to
ensure that the reverse DNS zone is signed and has the proper chain of signed
DS records ultimately coming from the IP6.ARPA  or IN-ADDR.ARPA zone.

*
Clients using RFC1918 IP addresses would not be able to support this;  Because,
there is no way of  establishing WHO is authorized to sign locally on
behalf of the "operator" of a RFC1918 or link-local IP address...

The latter seems more like a system administration problem however --

The DHCP software running on a client ought to have some way of
indicating whether the network being connected to is  Secure and
"Managed" by the same entity that owns and configures the client device:

I.E.  Same company manages the LAN and the entire path up to recursive
DNS servers are secure,Or whether the PC is owned and managed by
different entities --  such as a  mobile PC user connected to someone
else's network,
or a Home user connected to their own ISP,  and the network is, therefore,
untrusted.

(Untrusted in the sense that DNS Servers are controlled by
a 3rd party who is not the owner or operator of the personal computer
or client device which is connecting for the supposed purpose of
accessing the public internet  --- therefore no legitimate authority
exists for having clients tolerate tampering with private traffic
between that device and another internet host, content in DNS or other
IP traffic content, and so on)

> Thoughts?
> Thank you,
> Kevin McCormick
--
-JH

Re: IPv6 Pain Experiment

[bzs]

I think we're basically on the same page. But what I described
wouldn't use port numbers to fake extended addressing, just a flag and
some extra IP header for the extended addr bits.

On October 6, 2019 at 21:12 li...@packetflux.com (Forrest Christian (List 
Account)) wrote:
 > I've been ignoring this discussion because I feel this ship sailed many years
 > ago, and IPv6, like it or hate it, is the best way forward we have.
 > 
 > But, assuming you're expanding the address space, the simplest solution is to
 > add the additional bits addresses at the end.
 > 
 > I.E. every existing /32 gets an additional 64K addresses.   Or how many
 > correspond to the additional number of bits.
 > 
 > You can then add this without making any changes to the core of the 
 > internet. 
 >  It's all routed just like it is today, only paying attention to the first 
 > /32
 > of the address.     The remaining /16 or /32 or whatever is then only handled
 > internally by each network/ASN.     Heck, you might be able to this without
 > changing IP at all - instead, you could probably add an extension address 
 > layer
 > between IP and TCP.   So it's TCP/EXPADDR/IP.   
 > 
 > The motivation to upgrade can then come from the endpoints.   For a lot of
 > applications, one only would have to update the customer-end software (i.e. 
 > web
 > browsers), and the server end.   So if you're a google and are tired of 
 > trying
 > to obtain more and more addresses, you just get the main browser vendors to 
 > add
 > support for "IP Extended addressing" and then you add it on your servers.   
 > The
 > internet in the middle doesn't care.    As a host, all you need is a single /
 > 32.  At some point, eyeball networks could start handing out the extended
 > addresses or using them for NAT, also alleviating their need for IP's.
 > 
 > On the other hand, this sure seems similar to what we do today with CGNAT and
 > similar today since there are already 64K endpoints in both TCP and UDP per 
 > ./
 > 32 of IP 
 > 
 > On Sun, Oct 6, 2019 at 3:59 PM Valdis Klētnieks 
 > wrote:
 > 
 > On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said:
 > 
 > > All a strictly IPv4 only host/router would need to understand in that
 > > case is the IHL, which it does already, and how to interpret whatever
 > > flag/option is used to indicate the presence of additional address
 > > bits mostly to ignore it or perhaps just enough to know to drop it if
 > > it's not implemented.
 > 
 > So... how would a strict IPv4 router handle the case where 
 > 8.8.4.5.13.9/40
 > should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via
 > Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes
 > because there's yet another peering war and nobody's baked a cake yet, so
 > sending packets for either route to the wrong link will cause 
 > blackholing?
 > 
 > 
 > 
 > 
 > --
 > - Forrest

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: IPv6 Pain Experiment

[bzs]

I didn't quite say nothing would need to be changed, only that the
changes would be by and large very minimal, some new cases in the
existing IPv4 stacks, rather than an entirely new stack. Particularly
for hosts, if this bit (flag, whatever) is set be sure to copy the
entire IP packet into your dest headers.

The extended addressing I describe could probably be mostly
implemented in hosts as a new ICMP option for extended addressing.

On October 6, 2019 at 17:58 valdis.kletni...@vt.edu (Valdis Klētnieks) wrote:
 > On Sun, 06 Oct 2019 17:47:24 -0400, b...@theworld.com said:
 > 
 > > All a strictly IPv4 only host/router would need to understand in that
 > > case is the IHL, which it does already, and how to interpret whatever
 > > flag/option is used to indicate the presence of additional address
 > > bits mostly to ignore it or perhaps just enough to know to drop it if
 > > it's not implemented.
 > 
 > So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40
 > should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via
 > Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes
 > because there's yet another peering war and nobody's baked a cake yet, so
 > sending packets for either route to the wrong link will cause blackholing?
 > 
 > x[DELETED ATTACHMENT , application/pgp-signature]

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: dns cache beyond ttl - viasat / exede

[Sabri Berisha]

Hi Mike,

The UT uses a combination of caching, prefetching, and spoofing to accelerate 
web traffic for users. On the terrestrial side, there is a cluster of 
accelerators that also take part in that process. 

What is the "lag" time that you have observed? Also, do you know if your 
clients are on the Viasat-1 or Viasat-2 satellite? The infrastructure behind 
both satellites differs significantly.

I used to work for Viasat and have forwarded your mail to a few of my former 
colleagues.

Thanks, 

Sabri

- On Oct 7, 2019, at 9:08 AM, Mike mike-na...@tiedyenetworks.com wrote:

> Hello,
> 
> 
>    I am moving a number of web sites from one colo to another,
> re-numbering them in the process, and I have run into an interesting
> issue I'd like to solicit feedback on.
> 
>    My dns TTL's are all 300 seconds, and I have noticed that once I
> update the A records with the new addresses, most (but not all) web
> clients begin using the new address within 5 minutes or so. However,
> there is a persistent set of stragglers who continue accessing the
> site(s) on their old addresses for far in excess of this - up to a week
> in fact. And, what I have noted, all of these clients have something in
> common - they all appear to be satellite users of viasat/exede.  This is
> based on whois lookups of the ip addresses of the clients. Note, I am
> NOT expecting 'turn on a time' - just looking for clients to refresh
> within a reasonable time.
> 
>   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.
> 
> 
> Thanks.
> 
> 
> MIke-

Re: dns cache beyond ttl - viasat / exede

[Brielle]

On 10/7/2019 10: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.



From experience with Wildblue and a few other Sat internet providers 
when I did wilderness ranch installs, I can tell you that those modems 
do lots of weird fuckery with packets.


* Intercepting DNS packets and doing caching like what you are describing

* Responding to three way handshake before the other end actually does 
(nmap -sT remote host ends up with every port being 'open' but closing 
connection right away)


* Hijacking http and https connections and sending them through a 
tunneling proxy or caching proxy.


* Multiple layers of NAT

Due to the RTT being so high, the providers do everything in their power 
to make it seem like you aren't on as an agonizingly slow connection as 
you are.


--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Poor mans TAP

[Dovid Bender]

Yup, Tried that. Incoming interface is set as:
interface Ethernet1/37
  switchport mac-learn disable
  description tor-31-1 ge-0/0/44 SPAN
  switchport mode trunk
  switchport trunk allowed vlan 2,999
  ip access-group DROP out

Outbound interfaces are set to:

interface Ethernet1/46
  description MON1
  switchport access vlan 999

The issue is that the traffic coming in, is coming from a Juniper switch
where the traffic has vlan tags on the packets.


On Mon, Oct 7, 2019 at 1:07 PM Nick Hilliard  wrote:

> Dovid Bender wrote on 07/10/2019 17:56:
> > We used cisco in the past. The issue we have is the switches that will
> > mirror to more than one port  have fans pushing the heat into the cold
> > isle. From what I was able to see Cisco does not have any AFO switches
> > that will mirror to more than one port.
>
> um, really?  Have you tried disabling mac learning?  This will cause all
> traffic to be unicast flooded to multiple ports.
>
> Nick
>

Re: Poor mans TAP

[Dovid Bender]

John,

We used cisco in the past. The issue we have is the switches that will
mirror to more than one port  have fans pushing the heat into the cold
isle. From what I was able to see Cisco does not have any AFO switches that
will mirror to more than one port.



On Mon, Oct 7, 2019 at 10:29 AM John Kristoff  wrote:

> On Mon, 7 Oct 2019 14:16:31 +
> Dovid Bender  wrote:
>
> > Funds at my 9-5 are limited. Has anyone tried this and how well does
> > it work? We plan on mirroring about 800 megs of traffic at peak.
> >
> https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp
>
> I don't know if it still works on modern switches, but many years ago I
> was able to have Cisco LAN switches configured such that a single L2
> MAC address could be statically associated with multiple interfaces
> (i.e. router interface).  This made it possible to duplicate all
> traffic to destined to one station to appear on two (maybe more?) ports.
> You might try this also if you have an unused and available switch.
>
> John
>

RE: This DNS over HTTP thing

[Kevin McCormick]

The simple fix is to add a new DNS record.

Call it ULS, Use Local Server or something else relevant.

The record would contain the CIDR network addresses of clients that need to use 
the internal DNS servers.

If the DNS request comes from an IP in matching a CIDR network address in the 
ULS record, then the server would respond with an error message telling the 
application to use the configured local DNS server.

Thoughts?

Thank you,

Kevin McCormick

-Original Message-
From: NANOG  On Behalf Of Brandon Martin
Sent: Monday, September 30, 2019 10:57 PM
To: nanog@nanog.org
Subject: Re: This DNS over HTTP thing

On 9/30/19 10:25 PM, Jay R. Ashworth wrote:
> Is there an official name for it I should be searching for?

Aside from "DoH" (smacks Homer's head), you might find searching for the 
Mozilla (et. al.) "canary domain" useful.

It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least) will go back 
to using your local DNS server list as per usual.
--
Brandon Martin

RE: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Keith Medcalf]

On Monday, 7 October, 2019 08:55, Rich Kulawiec  wrote:

>On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote:

>> Otherwise, an impressive amount of WTF. My favorite: "while
>> communication by servers ___on the ground___ might take hundreds of
>> milliseconds, in the cloud the same operation may take only one
>> millisecond from one machine to another"

>My favorite: "The researchers expect their cloud-based system will be
>more secure than the Internet is today [...]"  Apparently they're
blissfully
>unaware that there is no such thing as "cloud security".

I would be interested to know how one connects to their "cloud"?  Do I
need an "Evaporation Adapter" for my computer to send to their cloud?
And do I need a "Rain Collector" to receive from it?  I suppose I also
need the computer to be outside exposed to the elements -- putting it
under a brolly would interfere with incoming rain from the cloud ...
Plus I suppose it would not work very well at all in the desert, but
downloading would be very high bandwidth in the rainforest (or during
monsoon season).

:)

--
The fact that there's a Highway to Hell but only a Stairway to Heaven
says a lot about anticipated traffic volume.

Re: dns cache beyond ttl - viasat / exede

[Andrew Kerr]

  I've seen similar issues (years ago) where some ISPs didn't honour DNS
TTLs, and would instead cache the results a LOT longer.

On Mon, Oct 7, 2019 at 9:08 AM Mike  wrote:

> Hello,
>
>
> I am moving a number of web sites from one colo to another,
> re-numbering them in the process, and I have run into an interesting
> issue I'd like to solicit feedback on.
>
> My dns TTL's are all 300 seconds, and I have noticed that once I
> update the A records with the new addresses, most (but not all) web
> clients begin using the new address within 5 minutes or so. However,
> there is a persistent set of stragglers who continue accessing the
> site(s) on their old addresses for far in excess of this - up to a week
> in fact. And, what I have noted, all of these clients have something in
> common - they all appear to be satellite users of viasat/exede.  This is
> based on whois lookups of the ip addresses of the clients. Note, I am
> NOT expecting 'turn on a time' - just looking for clients to refresh
> within a reasonable time.
>
>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.
>
>
> Thanks.
>
>
> MIke-
>
>

dns cache beyond ttl - viasat / exede

[Mike]

Hello,


    I am moving a number of web sites from one colo to another,
re-numbering them in the process, and I have run into an interesting
issue I'd like to solicit feedback on.

    My dns TTL's are all 300 seconds, and I have noticed that once I
update the A records with the new addresses, most (but not all) web
clients begin using the new address within 5 minutes or so. However,
there is a persistent set of stragglers who continue accessing the
site(s) on their old addresses for far in excess of this - up to a week
in fact. And, what I have noted, all of these clients have something in
common - they all appear to be satellite users of viasat/exede.  This is
based on whois lookups of the ip addresses of the clients. Note, I am
NOT expecting 'turn on a time' - just looking for clients to refresh
within a reasonable time.

   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.


Thanks.


MIke-

Equipment needed plea!

[James Laszko via NANOG]

Probably gonna get yelled at for this, but does anyone by chance have a Cisco 
N5548P-FAN module in the Atlanta area? We have a customer with critical 
infrastructure down and can’t find one anywhere!

Any assistance would be appreciated. 


Thanks,

James Laszko
Mythos Technology Inc
jam...@mythostech.com

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Hank Nussbacher]

On 07/10/2019 17:42, Stephane Bortzmeyer wrote:

On Fri, Oct 04, 2019 at 03:52:26PM -0400,
  Phil Pishioneri  wrote
  a message of 9 lines which said:


Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’

Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)


Centralized Internet routing - sounds like DoH for BGP.

What could possibly go wrong?!

-Hank

Re: IPv6 Pain Experiment

[Rob McEwen]

On 10/7/2019 7: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.


(1) as Stephen Satchell said... because a huge percentage of mailboxes 
(perhaps the vast majority?) are still behind servers that (wisely!) 
only listen on IPv4 for non-auth connections, so spammers would have to 
make extremely large deletions to their distribution list if they only 
sent to emails where the mail server only listened on IPv6.


(2) For my own commercial anti-spam blacklist, I've had SEVERAL new 
subscribers this past year who specifically complained about spams that 
my anti-spam blacklists (AND all the other ones like Spamhaus, etc!) 
were NOT blocking. I requested more information about the ones that 
weren't getting blocked... and they were almost all IPv6-sent spams. I 
simply explained to them that they do NOT have to do this, and that most 
of that spam will go away the moment that their server only listens on 
IPv4 (at least, for non-SMTP-AUTH email - they can still listen for IPv6 
authenticated email without these problems). I also explained to them 
that there hadn't been a situation in the history of the world where an 
email didn't make it to a server that only listened on IPv4 for 
non-authenticated email.


(3) Many IPv6 mail servers have had to invest/expend significantly more 
resources per mailbox.


(4) trying to get everyone to move too quickly to IPv6 POTENTIALLY 
actually damages email and harms OTHER's spam filtering. Why? Because it 
enables listwashing. A spammer can literally send to 10s of thousands of 
email addresses each from a separate /64 block, with a one-to-one 
relationship between the /64 block and the recipient email address. Then 
they can listwash spamtrap addresses based on which of those /64 blocks 
get blacklisted. It ALSO harms email because shady marketers get the 
idea that there are endless new IPs to burn through, and that only 
emboldens them. So when it comes to email, it turns out that IPv4 
scarcity (for non-auth connections) is a feature not a bug! But, if 
desired, you can STILL have massive amounts of IPv6 clients sending via 
SMTP authentication - so this won't limit your ability for your 
refrigerator to send authenticated email to you! (so that greatly 
minimizes the "but we're running out" longer-term argument - besides the 
fact that this isn't really a HUGE problem anyways - since IPv6 clients 
already are already able to connect to IPv4 servers)


--
Rob McEwen
https://www.invaluement.com

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Clayton Zekelman]

He adds that while communication by servers on 
the ground might take hundreds of milliseconds, 
in the cloud the same operation may take only 
one millisecond from one machine to another. 
“It’s orders of magnitude faster, and in the 
cloud we can easily afford more bandwidth 
resources, too. The photons have less distance 
to travel in the cloud than on the ground. All 
these factors make outsourcing the 
decision-making to the cloud more advantageous.” 
The researchers say this new approach of 
enabling interdomain routing as a service is “a 
radically different approach compared to today’s practice.”


I think this would work if you re-route the 
plasma conduits on deck 23 to the output of the main deflector dish.


At 03:52 PM 04/10/2019, Phil Pishioneri wrote:

[Came up in some digest summary I receive]

Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’

https://www.umass.edu/newsoffice/article/using-cloud-resources-dramatically-improve

-Phil


--

Clayton Zekelman
Managed Network Systems Inc. (MNSi)
3363 Tecumseh Rd. E
Windsor, Ontario
N8W 1H4

tel. 519-985-8410
fax. 519-985-8409

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Rich Kulawiec]

On Mon, Oct 07, 2019 at 04:42:11PM +0200, Stephane Bortzmeyer wrote:
> Otherwise, an impressive amount of WTF. My favorite: "while
> communication by servers ___on the ground___ might take hundreds of
> milliseconds, in the cloud the same operation may take only one
> millisecond from one machine to another" 

My favorite: "The researchers expect their cloud-based system will be more
secure than the Internet is today [...]"  Apparently they're blissfully
unaware that there is no such thing as "cloud security".

---rsk

Re: "Using Cloud Resources to Dramatically Improve Internet Routing"

[Stephane Bortzmeyer]

On Fri, Oct 04, 2019 at 03:52:26PM -0400,
 Phil Pishioneri  wrote 
 a message of 9 lines which said:

> Using Cloud Resources to Dramatically Improve Internet Routing
> UMass Amherst researchers to use cloud-based ‘logically centralized
> control’

Executive summary: it's SDN for BGP. Centralizing Internet routing,
what could go wrong? (As the authors say, "One reason is there is no
single entity that has a big picture of what is going on, no
manager". I wonder who will be Internet's manager.)

Otherwise, an impressive amount of WTF. My favorite: "while
communication by servers ___on the ground___ might take hundreds of
milliseconds, in the cloud the same operation may take only one
millisecond from one machine to another" I thought that universities
were full of serious people, but university of Massachusets may be an
exception?

RE: Poor mans TAP

[Ray Orsini]

Most smart switches do port mirroring. But I've had the predecessor to that tap 
for a few years. It has always worked well.


Ray Orsini
Chief Executive Officer
OIT, LLC
 305.967.6756 x1009 |  305.571.6272
 r...@oit.co |  www.oit.co
 oit.co/ray
-Original Message-
From: NANOG  On Behalf Of John Kristoff
Sent: Monday, October 7, 2019 10:29 AM
To: nanog@nanog.org
Subject: Re: Poor mans TAP

On Mon, 7 Oct 2019 14:16:31 +
Dovid Bender  wrote:

> Funds at my 9-5 are limited. Has anyone tried this and how well does 
> it work? We plan on mirroring about 800 megs of traffic at peak.
> https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Netwo
> rk/dp/B0055M5JL8?ref_=ast_bbp_dp

I don't know if it still works on modern switches, but many years ago I was 
able to have Cisco LAN switches configured such that a single L2 MAC address 
could be statically associated with multiple interfaces (i.e. router 
interface).  This made it possible to duplicate all traffic to destined to one 
station to appear on two (maybe more?) ports.
You might try this also if you have an unused and available switch.

John

Re: Poor mans TAP

[John Kristoff]

On Mon, 7 Oct 2019 14:16:31 +
Dovid Bender  wrote:

> Funds at my 9-5 are limited. Has anyone tried this and how well does
> it work? We plan on mirroring about 800 megs of traffic at peak.
> https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp

I don't know if it still works on modern switches, but many years ago I
was able to have Cisco LAN switches configured such that a single L2
MAC address could be statically associated with multiple interfaces
(i.e. router interface).  This made it possible to duplicate all
traffic to destined to one station to appear on two (maybe more?) ports.
You might try this also if you have an unused and available switch.

John

Poor mans TAP

[Dovid Bender]

Hi,

Funds at my 9-5 are limited. Has anyone tried this and how well does it
work? We plan on mirroring about 800 megs of traffic at peak.
https://www.amazon.com/Dualcomm-1000Base-T-Ethernet-Regeneration-Network/dp/B0055M5JL8?ref_=ast_bbp_dp

TIA.

Dovid

"Using Cloud Resources to Dramatically Improve Internet Routing"

[Phil Pishioneri]

[Came up in some digest summary I receive]

Using Cloud Resources to Dramatically Improve Internet Routing
UMass Amherst researchers to use cloud-based ‘logically centralized
control’

https://www.umass.edu/newsoffice/article/using-cloud-resources-dramatically-improve

-Phil

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: IPv6 Pain Experiment

[Valdis Klētnieks]

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.






pgp308XuGGKjm.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Rob McEwen]

On 10/7/2019 2:03 AM, Masataka Ohta wrote:

Forrest Christian (List Account) wrote:

I've been ignoring this discussion because I feel this ship sailed 
many years ago, and IPv6, like it or hate it, is the best way

forward we have.


A problem is that there is a cliff edge in front of you.



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. Yes, there 
are OTHER filtering techniques, but none that scale nearly so much with 
as extremely little resources required. And this is a problem for large 
and small organizations. Even the very largest email systems would be 
extremely disrupted if IPv4 DNSBLs (internal and/or 3rd party) were not 
available within the very near future. Solutions to this problem would 
then severely disrupt their business/financial models for those mail 
systems since the overhead costs per mailbox would significantly increase.


--
Rob McEwen
https://www.invaluement.com

Re: IPv6 Pain Experiment

[Masataka Ohta]

Forrest Christian (List Account) wrote:

I've been ignoring this discussion because I feel this ship sailed 
many years ago, and IPv6, like it or hate it, is the best way

forward we have.


A problem is that there is a cliff edge in front of you.

But, assuming you're expanding the address space, the simplest 
solution is to add the additional bits addresses at the end.


Sure.

> On the other hand, this sure seems similar to what we do today with
> CGNAT and similar today since there are already 64K endpoints in
> both TCP and UDP per ./32 of IP

The following draft makes it more explicit:

https://tools.ietf.org/html/draft-ymbk-aplusp-10
The A+P Approach to the IPv4 Address Shortage
R. Bush, Ed.

Instead of assigning a single IPv4 address to a
single customer device, we propose to extend the
address field by using bits from the port number
range in the TCP/UDP header as additional end point
identifiers,

A+P is equivalent to NAT with end to end transparency.

Masataka Ohta