Re: Contacts at Three.co.uk

[Cynthia Revström]

Maybe ask on UKNOF? https://www.uknof.org.uk/

- Cynthia

On Tue, 8 Oct 2019, 21:58 John Von Essen,  wrote:

> I know this is a North America list, but anyone here connected with Three
> or have a contact there?
>
> I am investigating an issue related to the default adult filter settings
> that are becoming more common (maybe required now?) in the UK on mobile
> data networks.
>
> I work at a large search engine, not Google or Bing, but like #4 or 5 in
> the world, and a portion of our site is being blocked by Three - and we’ve
> determined its related to their adult filter settings on mobile or mifi
> devices. We’d like to get in contact with them to understand how/why it was
> blocked and what we can do to resolve it.
>
> Thanks
> John Von Essen

Re: Chicago Equinix IX LAN oddity

[Erik Sundberg]

Equinix renumber the IP Block from a /24 to a /23 and everyone was suppose to 
be off the old block I think around a year ago. I am sure some providers did 
not migrate everything off that IP Block. Everyone that was a member at that 
time was given a new IP Address on the /23 subnet, I believe the last octet of 
the address stayed the same.

They might just be emailing of an old email template for peering.

Also, Here is that peers new IP block assuming it's AS19016.
208.115.136.119   0 19016  853824  755885 38249848700 8w5d 
20

Erik


From: NANOG  on behalf of JASON BOTHE via NANOG 

Sent: Tuesday, October 8, 2019 1:57 PM
To: James Cornman 
Cc: nanog@nanog.org 
Subject: Re: Chicago Equinix IX LAN oddity

Got it, thanks for that. I’ll have to give the big E a call and see how to sort 
this one out.

J~

On Oct 8, 2019, at 13:55, James Cornman  wrote:


There was a subnet expansion/migration there earlier this year (maybe late last 
year?)

We have an old and new address on our interface.. The 208.x is the new range 
(aka bigger)

 ip address 206.223.119.124/24
 ip address 208.115.136.124/23

-James

On Tue, Oct 8, 2019 at 2:47 PM JASON BOTHE via NANOG 
mailto:nanog@nanog.org>> wrote:
Hi all

I realize this might not be the right list but I have a request to peer on the 
Chicago Equinix IX to a 206.223.119 IP but we and many others are on the 
208.115.137 network. While I await a response from the peering partner, I’d 
curious to know if this is an error, perhaps there was a renumber at one time 
or I’m flat out just missing something.

Cheers!

J~


--

James Cornman

jcorn...@atlanticmetro.net
212.792.9950

Atlantic Metro Communications

4 Century Drive, Parsippany NJ  07054

Cloud Hosting • Colocation • Network Connectivity • Managed Services

Follow us on Twitter: @atlanticmetro • Like 
us on Facebook
www.atlanticmetro.net



CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

RE: Update to BCP-38?

[Keith Medcalf]

You would still be better served by forgetting about hiding the
webserver vendor name and using that money to buy an IDS/IPS that works
properly by detecting the actual exploit attempt rather than looking for
"a spike of errors in the log" in order to block the originating
address, especially since a "spike of errors in the log" can have quite
a few causes other than exploit attempts -- in fact such a "spike in
errors" is more likely to occur for reasons other than attempts to find
a vulnerability.  Furthermore, it is quite possible for the first
exploit attempt to be successful despite having hidden the banner, in
which case the entire thing was merely nothing more than security
theatre.  This is especially true when you consider "many" systems using
this method of protection and millions of attempted exploits per second.

Furthermore, why on earth would an opportunistic attacker use two
requests when one would suffice?  There is nothing to be gained by
probing only to discover "Oh, I am getting all wet cuz this is a juicy
target" when one would merely send the exploit and see what happens --
it either works or it does not -- and probing first adds no value -- in
just makes each attempt expend more resources.  In the time you have
probed a server and gotten a response, you could have simply sent the
exploit to a dozen servers.  So clearly probing for a "good target" is
just a waste of time.

This is why most dirty e-mail spammers just "blast" out their spam
without waiting for the appropriate responses from the SMTP server, and
why having the SMTP server insist on strict RFC compliance (and test
that the connected MTA is RFC compliant) works so well at getting rid of
95% of spam.

So given a choice between:
(1) Spending money hiding the headers and using software to reconfigure
the firewall based on errors in the log; or,
(2) Spending money on an IDS/IPS that can detect and drop an exploit
dynamically

you are probably better served by (2) than by (1).  The software that
monitors the log is most useful to send a notification that there is an
excessive error rate (since that is what it is detecting).

Of the millions of ransomware attacks per second, the 617 victims so far
this year probably relied on method (1) and in hindsight wished they had
been a little smarter and used method (2) instead.

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

>-Original Message-
>From: Mark Collins 
>Sent: Tuesday, 8 October, 2019 12:17
>To: Keith Medcalf ; nanog@nanog.org
>Subject: Re: Update to BCP-38?
>
>Any additional effort put in by an attacker will increase the chance of
>an attack being detected before it is successful. COnsider the
following
>two scenerios.
>
>Scenerio 1 is a webserver that makes no effort to obfuscate:
>
>
>1. Attacker does HEAD request on /, which is a legitmate request,
and
>sees the webserver vendor name
>
>2. Attacker does a quick search, and finds there is a vulnerabilty
in
>webserver
>3. Attacker exploits vulnerability
>
>
>Now, consider scenerio 2, where the server is configured to hide the
>webserver vendor and has an IDS/IPS system in place
>
>
>1. Attacker does HEAD request on /, which is a legitmate request,
but
>there is no usable information in the respone.
>2. Attacker does a probe on the webserver to try a number of
attacks,
>which generate a number of 403, 404, 500 etc errors in the webserver
logs
>3. IDS/IPS sees the sudden spike in errors from a single IP address
and
>blocks the source IP
>
>The act of obfuscation made it possible for the IDS/IPS to detect the
>probe, preventing the attack. WIll this block every attack? Probably
not,
>but it increases the effectiveness of the security by forcing the
>attacker to take additional (detectable) actions when trying to break
in.
>
>The lock on your front door can be picked by anyone with a $10 lockpick
>set in under 5 minutes, does that mean you shouldn't bother locking
your
>doors?
>
>Mark
>
>
>
>From: NANOG  on
>behalf of Keith Medcalf 
>Sent: 08 October 2019 18:53
>To: nanog@nanog.org 
>Subject: RE: Update to BCP-38?
>
>
>On Tuesday, 8 October, 2019 11:03, William Herrin 
wrote:
>
>>Limiting the server banner so it doesn't tell an adversary the exact
OS-
>>specific binary you're using has a near-zero cost and forces an
>adversary
>>to expend more effort searching for a vulnerability. It doesn't
>magically
>>protect you from hacking on its own. As you say, your security must
not
>>be breached just because the adversary figures out what version you're
>>running. But viewed as one layer in an overall plan, limiting that
>>information enhances your security at negligible cost. That's security
>>smart.
>
>I think your analysis is incorrect.
>
>There are two cases which are relevant:
>(1) The attack is non-targetted (that is, it is opportunistic)
>(2) The attack is targetted at you specifically.
>
>In 

Re: IPv6 Pain Experiment

[Masataka Ohta]

Nicholas Warren wrote:


It's not 1990 any more, a TB of RAM now costs a few thousand dollars


Maybe.


and is dropping rapidly (similar for fancy router RAM),


Definitely not. It's not 2010 any more.

Masataka Ohta

Re: IPv6 Pain Experiment

[Masataka Ohta]

William Herrin wrote:


The point of TCP use IP address for identification is hosts can
confirm IP address is true by 3 way handshaking.


Yeah, but that touches one of the central flaws of the design of IP,
v4 and v6.


We are talking about design of TCP, not IP.


No part of identifying and authenticating communication
should reside at layer 3.


That's why we have port numbers for TCP, though you may
call something equivalent to them SPIs for IPsec.


The IP address shouldn't identify anything.
It should reflect only the host's current position in the network.


You are saying IP address should identify current position in
the network.


The address should be as ephemerally attached to the endpoint as the
layer 2 MAC address and as quickly changeable. Without disrupting
upper layer communication. It would be a crying shame to replace the
layer 4 protocols without doing something about that flaw.


Just say "IP mobility". And it's layer 3 issue.


I actually came up with a solution to BGP scalability. If you
abandon stability of the layer 3 address, just throw it out the
window, it turns out to be relatively easy to build a routing
protocol which constructs ephemeral address hierarchies that
represent the current state of connections in the network even though
the physical network itself is still a general graph. The ephemeral
hierarchies aggregate well reducing the worldwide routing table to a
few tens of thousands of routes.


Then, you need two sets of IP addresses, one for physical network
another for virtual network. Former needs large routing table.

With IP mobility, the latter needs no routing table or BGP.

Only to replace well known port numbers by well known connection 
IDs and port scanning by connection ID scanning?


Easy to make this impractical. QUIC has.


It can be made so by sparsely populated port number space.

So, when all what needed are more bits for address and port, don't
try to put all the complicated features someone might have thought
useful.

Masataka Ohta

Contacts at Three.co.uk

[John Von Essen]

I know this is a North America list, but anyone here connected with Three or 
have a contact there?

I am investigating an issue related to the default adult filter settings that 
are becoming more common (maybe required now?) in the UK on mobile data 
networks.

I work at a large search engine, not Google or Bing, but like #4 or 5 in the 
world, and a portion of our site is being blocked by Three - and we’ve 
determined its related to their adult filter settings on mobile or mifi 
devices. We’d like to get in contact with them to understand how/why it was 
blocked and what we can do to resolve it.

Thanks
John Von Essen

Re: IPv6 Pain Experiment

[bzs]

On October 8, 2019 at 19:12 nwar...@barryelectric.com (Nicholas Warren) wrote:
 > Sweet deals, would you kindly share your vendor?
 > 
 > 
 > It's not 1990 any more, a TB of RAM now costs a few thousand dollars
 > and is dropping rapidly (similar for fancy router RAM), we have
 > processor chips with 64 cores available practically off the shelf for
 > under $10K (32-core literally off the shelf, try any Microcenter),
 > etc. etc. etc.

https://www.amazon.com/Corsair-Vengeance-128GB-3000MHz-Memory/dp/B019X5RN84

128GB DDR4 3000MHZ, $614.99, 8x (for 1TB) $5534.91

https://www.newegg.com/p/N82E16819113581?item=N82E16819113581=region_mc=knc-googleadwords-pc_mmc=knc-googleadwords-pc-_-pla-_-processors+-+server-_-N82E16819113581=CjwKCAjw5_DsBRBPEiwAIEDRW9nFdIuUnfGyEWeXuDb77ndDA-phHT2-eUYIHkFNiPoOzzQ7cwgoLxoC1WMQAvD_BwE=aw.ds

Newegg, 64-core, AMD/EPYC, $7522.

-- 
-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]

On October 8, 2019 at 12:04 b...@herrin.us (William Herrin) wrote:
 > On Tue, Oct 8, 2019 at 12:01 PM  wrote:
 > 
 > My main point is, as I said, Bits is Bits, whether they're human
 > readable (for some value of "human") like URLs or long hex strings
 > which perhaps are less human readable.
 > 
 > 
 > Bits aren't just bits. Bits with useful properties (such as aggregability 
 > which
 > coincides with the routing structure) are better bits.

Yet somehow we manage to start with URLs (for example.)

My point is whatever is used it can be mapped to something perhaps
more efficient given some design goals, such as the DNS does. And for
that matter route lookup tables w/in routers.

So at the end of the day all that is absolutely needed is (reasonable)
unambiguity because in general ambiguity can't be fixed, the packet
has to go somewhere.

Different schemes might present different design opportunities but
they all need to be unambiguous as routing endpoints.

-- 
-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

[Valdis Klētnieks]

On Tue, 08 Oct 2019 19:12:30 -, Nicholas Warren said:

> Sweet deals, would you kindly share your vendor?

Well, I just type "128G DIMM" into google, and the very first hit tells me that 
I can
get a 128G DIMM for $1,398, that and 8 DiMM slots gets me to 1T just over $11K.

If I have 16 DIMM slots like a decent server-class board should have, I can do 
64G cards
for $308 and I'm done for under $5k.

I didn't dig further, because I already had evidence to support the claim:

> It's not 1990 any more, a TB of RAM now costs a few thousand dollars
> and is dropping rapidly (similar for fancy router RAM)

> processor chips with 64 cores available practically off the shelf for
> under $10K (32-core literally off the shelf, try any Microcenter),

AMD 32-core Ryzen Threadripper is $1,799.   Find a 2-socket motherboard and
you're at 64 cores for well under $5K for the chipsets.

https://www.newegg.com/amd-ryzen-threadripper-2990wx/p/N82E16819113541


pgphvPywfuB9w.pgp
Description: PGP signature

Re: Update to BCP-38?

[Valdis Klētnieks]

On Tue, 08 Oct 2019 11:53:33 -0600, "Keith Medcalf" said:

> So while the cost of doing the thing may be near-zero, it is not zero.

And in fact, there's more than just the costs of doing it. There's also the 
costs
of having done it.

Obfuscating your OpenSSH versions is a *really* good way to make your security
scanners that flag backleveled systems fail to flag the systems.

Which can cause a really uncomfortable conversation with the CIO about why the
local newspaper's front page is running a story about how your organization got
totally pwned via a backleveled OpenSSH on one cluster of 5 servers.



pgpES4WWnZrxq.pgp
Description: PGP signature

Re: IPv6 Pain Experiment

[Nicholas Warren]

Sweet deals, would you kindly share your vendor?


It's not 1990 any more, a TB of RAM now costs a few thousand dollars
and is dropping rapidly (similar for fancy router RAM), we have
processor chips with 64 cores available practically off the shelf for
under $10K (32-core literally off the shelf, try any Microcenter),
etc. etc. etc.

Re: IPv6 Pain Experiment

[William Herrin]

On Tue, Oct 8, 2019 at 12:01 PM  wrote:

> My main point is, as I said, Bits is Bits, whether they're human
> readable (for some value of "human") like URLs or long hex strings
> which perhaps are less human readable.
>

Bits aren't just bits. Bits with useful properties (such as aggregability
which coincides with the routing structure) are better bits.

Regards,
Bill Herrin


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

Re: IPv6 Pain Experiment

[William Herrin]

On Mon, Oct 7, 2019 at 11:59 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> William Herrin wrote:
> > If we're going to replace TCP and UDP, initiate
> > the link with a name (e.g. dns name),
>
> The point of TCP use IP address for identification is hosts
> can confirm IP address is true by 3 way handshaking.

Yeah, but that touches one of the central flaws of the design of IP, v4 and
v6. No part of identifying and authenticating communication should reside
at layer 3.
The IP address shouldn't identify anything. It should reflect only the
host's current position in the network. The address should be as
ephemerally attached to the endpoint as the layer 2 MAC address and as
quickly changeable. Without disrupting upper layer communication. It would
be a crying shame to replace the layer 4 protocols without doing something
about that flaw.

I actually came up with a solution to BGP scalability. If you abandon
stability of the layer 3 address, just throw it out the window, it turns
out to be relatively easy to build a routing protocol which constructs
ephemeral address hierarchies that represent the current state of
connections in the network even though the physical network itself is still
a general graph. The ephemeral hierarchies aggregate well reducing the
worldwide routing table to a few tens of thousands of routes.


> Only to replace well known port numbers by well known connection
> IDs and port scanning by connection ID scanning?

Easy to make this impractical. QUIC has.

Regards,
Bill Herrin

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

Re: IPv6 Pain Experiment

[bzs]

On October 7, 2019 at 23:13 o...@delong.com (Owen DeLong) wrote:
 > 
 > 
 > > On Oct 7, 2019, at 20:16 , b...@theworld.com wrote:
 > > 
 > > 
 > > 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.
 > 
 > It doesn’t break my brain, but it really doesn’t make a lot of sense when 
 > you get down to it.

No, doesn't break your brain, but then you proceed to look at an
electric car and protest "but where do you put the gasoline?!" (i.e.,
describe current routing architecture.)

Yes, Owen, given my admittedly off-beat (isn't that how I introduced
it?) proposal some things would have to change, as I said in the note
you were responding to, more than once.

>There’s also the issue that prefixes of that address format don’t tend to 
>aggregate well.
>
>I’m betting that not all of the WWW addresses go to the same ASN.

Perhaps you have noticed in your vast travels that domain names'
significance is generally read right to left not left to right like IP
addresses?

I did finish with:

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

My main point is, as I said, Bits is Bits, whether they're human
readable (for some value of "human") like URLs or long hex strings
which perhaps are less human readable.

The only non-negotiable criteria is whether a given bitstring choice
is sufficiently unique to indicate routing endpoints.

It's not 1990 any more, a TB of RAM now costs a few thousand dollars
and is dropping rapidly (similar for fancy router RAM), we have
processor chips with 64 cores available practically off the shelf for
under $10K (32-core literally off the shelf, try any Microcenter),
etc. etc. etc.

It might be reasonable to think about how we might take advantage of
what we've learned in 30 years, particularly starting with the premise
that IPv6 adoption isn't doing very well. Perhaps we can do better.

I'm not quite sure the knee-jerk reaction "but we're neck deep in the
big muddy, we must continue forward! look at how long and how much
trouble it took us to get even neck deep!" should be dispositive.

P.S. My prediction?

The world's major telcos et al, having had enough of various problems,
from address exhaustion to non-stop security disasters, and the
chaotic responses, propose and begin implementing an alternative. And
that won't be through the IETF or similar.

Something I have learned about telcos and other vast business and govt
enterprises is they are willing to sit back, for decades if necessary,
and watch the pioneers break sod, find and grow the markets, take the
hits, fight range wars among themselves, etc.

And only then when what can be gained, and how, becomes clear they
move in with their vast capitalization and organizational skills.

"...now we stand outcast and starving 'mid the wonders we have made",
old union song.

-- 
-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: Chicago Equinix IX LAN oddity

[JASON BOTHE via NANOG]

Got it, thanks for that. I’ll have to give the big E a call and see how to sort 
this one out.  

J~

> On Oct 8, 2019, at 13:55, James Cornman  wrote:
> 
> 
> There was a subnet expansion/migration there earlier this year (maybe late 
> last year?)
> 
> We have an old and new address on our interface.. The 208.x is the new range 
> (aka bigger)
> 
>  ip address 206.223.119.124/24
>  ip address 208.115.136.124/23
> 
> -James
> 
>> On Tue, Oct 8, 2019 at 2:47 PM JASON BOTHE via NANOG  wrote:
>> Hi all
>> 
>> I realize this might not be the right list but I have a request to peer on 
>> the Chicago Equinix IX to a 206.223.119 IP but we and many others are on the 
>> 208.115.137 network. While I await a response from the peering partner, I’d 
>> curious to know if this is an error, perhaps there was a renumber at one 
>> time or I’m flat out just missing something. 
>> 
>> Cheers!
>> 
>> J~
> 
> 
> -- 
> James Cornman
> jcorn...@atlanticmetro.net
> 212.792.9950
> 
> Atlantic Metro Communications
> 4 Century Drive, Parsippany NJ  07054
> 
> Cloud Hosting • Colocation • Network Connectivity • Managed Services
> Follow us on Twitter: @atlanticmetro • Like us on Facebook
> www.atlanticmetro.net

Chicago Equinix IX LAN oddity

[JASON BOTHE via NANOG]

Hi all

I realize this might not be the right list but I have a request to peer on the 
Chicago Equinix IX to a 206.223.119 IP but we and many others are on the 
208.115.137 network. While I await a response from the peering partner, I’d 
curious to know if this is an error, perhaps there was a renumber at one time 
or I’m flat out just missing something. 

Cheers!

J~

RE: IPv6 Pain Experiment

[bzs]

On October 8, 2019 at 03:00 michel...@tsisemi.com (Michel Py) wrote:
 > > 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.

Considering the audience here configuration, maintenance, and repair
might involve entering numeric IP addresses.

Not the average user? I don't know, define average, how many tens of
millions of sites out there have more than just edge routers? How many
have adequate educational and reference materials in their native
language? etc.

-- 
-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: Update to BCP-38?

[Keith Medcalf]

On Tuesday, 8 October, 2019 11:03, William Herrin  wrote:

>Limiting the server banner so it doesn't tell an adversary the exact OS-
>specific binary you're using has a near-zero cost and forces an adversary
>to expend more effort searching for a vulnerability. It doesn't magically
>protect you from hacking on its own. As you say, your security must not
>be breached just because the adversary figures out what version you're
>running. But viewed as one layer in an overall plan, limiting that
>information enhances your security at negligible cost. That's security
>smart.

I think your analysis is incorrect.

There are two cases which are relevant:
(1) The attack is non-targetted (that is, it is opportunistic)
(2) The attack is targetted at you specifically.

In the former (1) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  The script either works or it 
does not.  Even if the "banner" says "Beyond this point there be monsters" will 
make absolutely not one whit of difference.

In the latter (2) case, it does not matter whether the "banner" identifies the 
specific OS binary or not as it is irrelevant.  You have been targetted.  All 
possible exploits will be attempted until success is achieved or the vat of 
exploits to try runs dry.

So while the cost of doing the thing may be near-zero, it is not zero.  All 
those near-zero cost things you do that have no actual advantage can add up to 
quite a huge total and it will be more advantageous to spend that somewhere 
where it will, in fact, make a difference.

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

Re: Update to BCP-38?

[William Herrin]

On Tue, Oct 8, 2019 at 6:51 AM Rich Kulawiec  wrote:
> On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote:
> > You've ignored step 1 - identifying critical information that needs
> > protecting. It makes sense to protect information that needs protecting
and
> > don't lose sleep over information that doesn't need protecting. Not
many of
> > us are planning an invasion of a Nazi-infected Europe any time soon.
>
> We are heading toward a restatement of Kerckhoff's principle/Shannon's
maxim,
> the latter of which can be paraphrased as "design systems assuming that
> your adversary will know as much about them as you do".

They aren't mutually exclusive concepts. A strong security architecture has
multiple layers an adversary must penetrate. No layer has to be sufficient
on its own, it just has to reduce vulnerability more than it increases cost.

Limiting the server banner so it doesn't tell an adversary the exact
OS-specific binary you're using has a near-zero cost and forces an
adversary to expend more effort searching for a vulnerability. It doesn't
magically protect you from hacking on its own. As you say, your security
must not be breached just because the adversary figures out what version
you're running. But viewed as one layer in an overall plan, limiting that
information enhances your security at negligible cost. That's security
smart.

Regards,
Bill Herrin


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

RE: IPv6 Pain Experiment

[Michel Py]

> Owen DeLong wrote :
> I’m not sure how giving them DNS names makes them less resilient to DNS 
> failures.

How do you resolve the IP address of the PBX ? I hard-code (in the master 
config).

The PBX does not have a DNS name. I want my support staff to know its IP on the 
top of their head.
DNS failures do not happen often, but they do happen. Fat fingers change or 
delete the entry, the zone gets corrupted or partially corrupted, that kind of 
stuff.
There are things that redundant hardware and network will not solve. If the PBX 
address becomes unresolvable, the SIP registrations will timeout and I'm going 
to lose phones.
Granted, it would not take that much time to troubleshoot, but just the 
possibility, not matter how remote, that it could happen makes it a non-option.
If DHCP fails, I have a 169.254 secondary address. It may not be elegant, but 
it is resilient.

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: Update to BCP-38?

[Keith Medcalf]

>Not everyone attacking your systems is going to have the skills or
>knowledge to get in though - simple tricks (like hiding what web server
>you use) can prevent casual attacks from script kiddies and others who
>aren't committed to targeting you, freeing your security teams to focus
>on the serious threats.

And this is based on what evidence?  It also defies logic.  By
definition script-kiddies run scripts.  If you remove the identification
those scripts can no longer identify what is running, and therefore will
continue to attack it.  What would be useful is to replace that with
alternative "disinformation" headers so that the script-kiddies scripts
will get a positive result, but that result will not be what they are
looking for, so they will go away.  Until having disinformation headers
gets the same "old wives tale" status as "remove the identifying
headers".  At which point either course of either action is a waste of
effort and $$$ because the script-kiddies will just ignore it as it will
be just as cost effective to run the exploit and see what happens.

In other words, simple tricks are exactly that.  They usually do exactly
the opposite of what the "simple tricker" thought they were doing, or do
nothing useful at all.  Which means that effort and $$$ have been
expended at best on a useless endeavour, and at worst one which
increased the very activity it was designed to thwart.  One would have
been far better off putting the $$$ in the slush-fund and using it when
some particularly persistent script-kiddie showed up so you could afford
to add a filter to the firewall.

--
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

[Brielle]

On 10/7/2019 3:23 PM, William Herrin wrote:


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.


I'll see what I can dig up from my notes.  Its been around 7-8 years 
since I've been directly involved.



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

Re: dns cache beyond ttl - viasat / exede

[William Herrin]

On Tue, Oct 8, 2019 at 4:22 AM Tony Finch  wrote:
> William Herrin  wrote:
> > Depending on the implementation, DNS pinned browsers may not recognize a
> > change to your IP address until the browser is stopped and restarted.
>
> I thought DNS pinning was only for the lifetime of the web page, so
> closing the tab (or all tabs open on the site...) should be enough, if a
> reload isn't.

It depends on the implementation. There are a bunch of things the browser
can do to be smart about it. Which leaves behind a few stragglers that
weren't smart about it.

-Bill


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

RE: Update to BCP-38?

[Mark Collins]

Not everyone attacking your systems is going to have the skills or knowledge to 
get in though - simple tricks (like hiding what web server you use) can prevent 
casual attacks from script kiddies and others who aren't committed to targeting 
you, freeing your security teams to focus on the serious threats.

Mark

-Original Message-
From: NANOG  On Behalf Of Rich Kulawiec
Sent: 08 October 2019 14:51
To: nanog@nanog.org
Subject: Re: Update to BCP-38?

On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote:
> You've ignored step 1 - identifying critical information that needs
> protecting. It makes sense to protect information that needs
> protecting and don't lose sleep over information that doesn't need
> protecting. Not many of us are planning an invasion of a Nazi-infected Europe 
> any time soon.

We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim, 
the latter of which can be paraphrased as "design systems assuming that your 
adversary will know as much about them as you do".

Not that I'm advocating publishing all internal design documents, but systems 
whose security is predicated on the secrecy of those are brittle and likely to 
be badly compromised.  Better to assume that enemies know or can find out 
everything and design/build accordingly.

---rsk
This Email from Marie Stopes International and any attachments may contain 
information which is privileged or confidential. It is meant only for the 
individual(s) or entity named above. If you are not the intended recipient(s) 
of this Email or any part of it please notify the sender immediately on receipt 
and delete it from your system. Any opinion or other information in this email 
or its attachments that does not relate to the business of Marie Stopes 
International is personal to the sender and is not given or endorsed by Marie 
Stopes International.

Re: Update to BCP-38?

[Rich Kulawiec]

On Tue, Oct 08, 2019 at 01:35:16PM +0100, Mike Meredith via NANOG wrote:
> You've ignored step 1 - identifying critical information that needs
> protecting. It makes sense to protect information that needs protecting and
> don't lose sleep over information that doesn't need protecting. Not many of
> us are planning an invasion of a Nazi-infected Europe any time soon.

We are heading toward a restatement of Kerckhoff's principle/Shannon's maxim,
the latter of which can be paraphrased as "design systems assuming that
your adversary will know as much about them as you do".

Not that I'm advocating publishing all internal design documents, but systems
whose security is predicated on the secrecy of those are brittle and likely
to be badly compromised.  Better to assume that enemies know or can find out
everything and design/build accordingly.

---rsk

Re: Update to BCP-38?

[Mike Meredith via NANOG]

As an Evil Firewall Administrator™, I have an interest in this area ...

On Fri, 4 Oct 2019 15:05:29 -0700, William Herrin  may have
written:
> On Thu, Oct 3, 2019 at 2:28 PM Keith Medcalf  wrote
> > Anyone who says something like that is not a "security geek".  They are
> > a "security poser", interested primarily in "security by obscurity" and
> > "security theatre", and have no clue what they are talking about.

Hmm ... 'primarily in "security by obscurity"' ... that does tend to
indicate a severe case of cluelessness (and that's coming from someone who
doesn't let his right hand know what his left hand is up to without
justification that has been signed off in triplicate). To give a real world
example, removing headers from an Apache web server doesn't do much to
increase security (it's mostly to keep auditors happy) because automated
attacks will hit your exposed Apache servers anyway, and a sophisticated
attacker will note the removal and adopt the strategy of an automated
attack. 

> more important information you'd like to deny to him. There's a 5-step
> process used by the U.S. Military but the TL;DR version is: if you don't
> have to reveal something, don't.

You've ignored step 1 - identifying critical information that needs
protecting. It makes sense to protect information that needs protecting and
don't lose sleep over information that doesn't need protecting. Not many of
us are planning an invasion of a Nazi-infected Europe any time soon.
-- 
Mike Meredith, University of Portsmouth
Hostmaster, Security, and Chief Systems Engineer
 


pgpmEWhW6kP_b.pgp
Description: OpenPGP digital signature

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

[J. Hellenthal via NANOG]

See RFC 1149 & 2549 

;-)

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Oct 7, 2019, at 11:29, Keith Medcalf  wrote:
> 
> 
>> 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

[Tony Finch]

William Herrin  wrote:
>
> 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.

I thought DNS pinning was only for the lifetime of the web page, so
closing the tab (or all tabs open on the site...) should be enough, if a
reload isn't.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
democracy, participation, and the co-operative principle

Re: Automated Abuse Reports

[Rich Kulawiec]

On Mon, Oct 07, 2019 at 05:28:08PM -0700, Matt Corallo wrote:
> Is it time to have ARIN add a ???abuse contact available only after 
> captcha??? option?

No.  Captchas are a worst practice and should never be used.

---rsk

Re: IPv6 Pain Experiment

[Masataka Ohta]

Owen DeLong wrote:


Separation between address and port is vague.


Explain that to ICMP packets.


Why do you think ICMP any different?

Just as usual IP packets, inner IP packets contained in
ICMPv4 error packets contain port numbers just after IP headers.

Moreover, unlike stupid ICMPv6, ICMPv4 error packets are
guaranteed to contain 8B of inner packet payload (enough
for 32 bit port number) after IP header.


If we're going to replace TCP and UDP, initiate
the link with a name (e.g. dns name),


The point of TCP use IP address for identification is hosts
can confirm IP address is true by 3 way handshaking.


And UDP?


Applications over UDP may or may not confirm by 3 way
handshaking or some other mechanism.

That's UDP.

That's very elementary explanations on ICMP and UDP.

Masataka Ohta

Re: IPv6 Pain Experiment

[Owen DeLong]

> On Oct 7, 2019, at 23:59 , Masataka Ohta  
> wrote:
> 
> William Herrin wrote:
> 
>>> 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.
> 
> Separation between address and port is vague.

Explain that to ICMP packets.

> 
>> If we're going to replace TCP and UDP, initiate
>> the link with a name (e.g. dns name),
> 
> The point of TCP use IP address for identification is hosts
> can confirm IP address is true by 3 way handshaking.

And UDP?

Owen

Re: IPv6 Pain Experiment

[Masataka Ohta]

William Herrin wrote:


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.


Separation between address and port is vague.


If we're going to replace TCP and UDP, initiate
the link with a name (e.g. dns name),


The point of TCP use IP address for identification is hosts
can confirm IP address is true by 3 way handshaking.


negotiate a connection ID and
continue with the connection ID.



No ports, no port scanning.


Only to replace well known port numbers by well known connection
IDs and port scanning by connection ID scanning?

> QUIC comes pretty close to getting it right.

It's another second system syndrome.

Keep using TCP/UDP as is except for port number length.

Masataka Ohta

Re: IPv6 Pain Experiment

[Owen DeLong]

> On Oct 7, 2019, at 20:16 , b...@theworld.com wrote:
> 
> 
> 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.

It doesn’t break my brain, but it really doesn’t make a lot of sense when you 
get down to it.

You’re basically producing a numeric address that is limited in character scope 
is all.

An octet can represent 8 bits of a binary address, period. It’s up to you 
whether you display
that to the human as ASCII characters (limited printable selection), Unicode 
(even more
overhead and wastage), numeric (current practice and zero waste in hex form), 
or otherwise.

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

Yeah, but it doesn’t tell the whole story because the domain name needs to map 
(in some
cases) to multiple on-the-wire addresses so you’re either going to have mass 
confusion
in that you’e got service names and service addresses that look like names 
underneath
that aren’t actually names, or, you’re going to be back to having addresses 
that could look
like names, but don’t for sanity’s sake and then you’re back to unreadable 
addresses.

> 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.

There’s also the issue that prefixes of that address format don’t tend to 
aggregate well.

I’m betting that not all of the WWW addresses go to the same ASN.

> 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?

In some applications, yes. In others, not so much.

> 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.)

Well, yes and no. In the theoretical world, sure. However, as a practical 
matter,
we depend a great deal on prefix aggregation and being able to carry only
summary routes for large chunks of address space in distal routing tables.

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

Until they aren’t because at some point, there needs to be a decoupling between 
the
human-readable form you give and the actual network hierarchy necessary for 
managing
a functional internet.

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

You say that as if it’s a good thing. I remain rather thoroughly unconvinced.

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

I suppose if one is attempting to find a way to drum up business for the NSAID
manufacturers, sure.

Owen

Re: IPv6 Pain Experiment

[Owen DeLong]

> On Oct 7, 2019, at 20:00 , Michel Py  wrote:
> 
>> 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.

I usually set these up with DHCP-registered DNS names for the phones. (Dynamic 
DNS)

It works pretty well.

I’m not sure how giving them DNS names makes them less resilient to DNS 
failures.

Owen