Re: 202401100645.AYC Re: IPv4 address block

2024-01-10 Thread Michael Butler via NANOG

On 1/10/24 10:12, Tom Beecher wrote:

Karim-

Please be cautious about this advice, and understand the full context.

240/4 is still classified as RESERVED space. While you would certainly 
be able to use it on internal networks if your equipment supports it, 
you cannot use it as publicly routable space. There have been many 
proposals over the years to reclassify 240/4, but that has not happened, 
and is unlikely to at any point in the foreseeable future.


While you may be able to get packets from point A to B in a private 
setting, using them might also be .. a challenge.


There's a whole bunch of software out there that makes certain 
assumptions about allowable ranges. That is, they've been compiled with 
a header that defines ..


#define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf000) == 0xf000)

Michael



Re: New addresses for b.root-servers.net

2023-06-07 Thread Michael Butler via NANOG

On 6/7/23 15:13, Izaac wrote:

On Wed, Jun 07, 2023 at 09:30:36AM -0700, William Herrin wrote:

Data embedded in the binary is hard-coded. That's what hard-coded
means. If it makes you happier I'll qualify it as a "hard-coded
default," to differentiate it from settings the operator can't
override with configuration.


No.  I will not indulge your invention of terms.  "Hard-coded" means you
need to recompile to change it.  This is a default value.  A
configuration option takes precedence.


BIND-9.18.14 requires recompilation to update the embedded defaults ..

bin/named/config.c: 2001:500:200::b;# b.root-servers.net\n\
bin/named/config.c: 199.9.14.201;   # b.root-servers.net\n\
lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN  A 
199.9.14.201\n"
lib/dns/rootns.c:   "B.ROOT-SERVERS.NET. 360 IN   
2001:500:200::b\n"




It's an instance of https://cwe.mitre.org/data/definitions/344.html


No, it is not in any respect.  The code you grepped out generates a
default configuration hints file when one does not exist.

The CWE you cite specifically refers to default values for things like
cryptographic RNG seeds and salts and TCP sequence number generators and
the like.  Viz something like
https://www.debian.org/security/2008/dsa-1571 from 2008.


A quick search of https://cve.mitre.org/cve/search_cve_list.html shows
between 600 and 3700 CVEs related to default configurations that are
either directly insecure or unexpectedly become insecure when some but
not all of the defaults are changed by the operator. The vast majority
of these CVEs exhibit, as you say, no flaw in the computational logic.


You literally just gave me a link to the CVE search page, waved your
hand, and said, "See?"  Well, I'll admit to not being as good at
conducting CVE research as you.  So, as an expert on the topic: How many
of these "between 600 and 3700 CVEs" are related to a violating the
baseless expectation of confidentially in a protocol which does not
guarantee confidentiality?  Somewhere between 0 and 2000?

But you know what, go ahead.  Submit the CVE.  Be the hero that you
believe yourself to be.





Re: Scanning the Internet for Vulnerabilities

2022-06-20 Thread Michael Butler via NANOG
I treat these folk with the same respect they afford me. Not once in 30 
years of having a connected network (v4 or v6) has any entity asked "is 
it OK if we .. ?".


To my mind, it seems rather idiotic and self-defeating to have the 
plumbing congested with packets intended to measure congestion :-(


Michael

On 6/20/22 09:46, Mel Beckman wrote:

Carsten,

No, it’s more like 50,000 furnace guys who show up several times a day to 
rattle doorknobs, attempt to push slim Jim’s into window latches, hack your 
garage door opener, sneak into your back garden, and fly drones around your 
home to see what valuables you might have. Yes, some of them are altruistic, 
but some are self-righteous officious boobs, and the vast majority are career 
criminals that will rob your house, drain your retirement account, and kill 
your family with a spoofed SWAT raid.

  -mel beckman


On Jun 20, 2022, at 4:20 AM, Carsten Bormann  wrote:
On 2022-06-20, at 04:18, Mel Beckman  wrote:


When researchers, or whoever, claim their scanning an altruistic service, I ask 
them if they would mind someone coming to their home and trying to open all the 
doors and windows every night.


Well, it is more like the guy who comes once a year and checks that your 
central heating is not going to blow up.

(Disclaimer: I have supervised students who designed and executed benign 
mass-scans of the IPv4 Internet in order to validate hypotheses about market 
penetration of certain security updates, and I definitely would do that again 
if there is a good reason to perform such a scan.)

Grüße, Carsten




Re: DoD IP Space

2021-04-25 Thread Michael Butler via NANOG

On 4/25/21 12:32 PM, Randy Bush wrote:

john,

my altzheimer's device tells me that some years back there was a
documented written agreement between arin and the dod along the lines of
dod getting a large swath of ipv6 space[0] in exchange for agreeing to
return[1] or otherwise put into public use a half dozen ipv4 /8s.

could you refresh my memory, e.g. with the document, please?  thanks.

randy

--

[0] which they are still trying to figure out how to use; bit isn't half
 the internet in a similar pinch. :)

[1] since the dod probably did not get the space from arin, 'return' is
 probably not a good term.


The footnote (11) on page 7 of https://www.gao.gov/assets/gao-20-402.pdf 
seems to be most relevant ..


"We are not aware of any statutory requirements that directly address 
the ability of a government agency to transfer or sell IP addresses to a 
third party, but DOD would face legal and policy constraints to any 
potential sale or transfer of the addresses to a third party outside of 
the government. Among other things, this is because DOD entered into an 
agreement with the American Registry for Internet Numbers. Specifically, 
this agreement states the department must return unused addresses to the 
registry."


imb