Re: DoD IP Space

[John Lee]

It is the DISA DOD NIC at:

https://disa.mil/About/Contact

Which will give you the DISA help desk phone number.

John Lee

On Mon, Nov 4, 2019 at 3:57 AM Chris Knipe  wrote:

> Hi Guys,
>
> Except for the email on ARIN's details, does anyone else have a contact
> for the DoD?
>
> We are experiencing a situation with a 3rd party (direct peer), wanting to
> advertise DoD address space to us, and we need to confirm whether they are
> allowed to do so or not.
>
> Range in question is the 22.0.0.0/8 network, which according to ARIN is
> actively assigned to the DoD (US).
>
> --
>
> Regards,
> Chris Knipe
>

Re: DoD IP Space

[Doug Barton]

I used to help large companies rearchitect their addressing, implement 
IPv6, etc. for a living, so no one is more sympathetic than I am about 
how difficult it can be to make these changes. However, I have to ask, 
how far backwards do we want to bend for those that refuse to migrate?


There have already been at least two lines in the sand that the IETF has 
backed down from. Is it even useful for us to keep saying "IPv6 is the 
way forward" any more?



On 1/20/21 7:26 AM, Fred Baker wrote:

I recently had a discussion with an Asian ISP that was asking the IETF to 
PLEASE re-declare DoD space to be private space so that they could use it. This 
particular ISP uses IPv6 extensively (a lot of their services are in fact 
IPv6-only) but has trouble with its enterprise customers. Frankly, enterprise 
use of IPv6 is a problem; they seem to push back pretty hard against using IPv6.

I find this thread highly appropriate.

Re: USENET peers?!

[bzs]

On January 20, 2021 at 16:06 nanog@nanog.org (Grant Taylor via NANOG) wrote:
 > On 1/20/21 3:50 PM, b...@theworld.com wrote:
 > > Around 300MB/day.
 > 
 > Interesting.
 > 
 > I see 50-70 MB / day for text only newsgroups.
 > 
 > Perhaps I want to step up to more than text only on some of my servers.

That might be a little overstated, I just took the spool size and
divided by the # of days of retention but there may be some expiration
leakage and we do expire some groups faster or slower. And of course
that's an average.

YMMV.

 > 
 > 
 > 
 > -- 
 > Grant. . . .
 > unix || die

Right now it's feeling like unix && die.

 > 
 > x[DELETED ATTACHMENT smime.p7s, application/pkcs7-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: DoD IP Space

[Randy Bush]

> due to it being so massive and unused for so long, certain large
> corporations that have run out of RFC1918, etc. space have started
> using it internally.

i first saw that on a traceroute from my hotel at ripe bologna in 2001.
i was told i was lng late to finding it.

randy

Re: USENET peers?!

[Grant Taylor via NANOG]

On 1/20/21 3:50 PM, b...@theworld.com wrote:

Around 300MB/day.


Interesting.

I see 50-70 MB / day for text only newsgroups.

Perhaps I want to step up to more than text only on some of my servers.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: USENET peers?!

[bzs]

On January 20, 2021 at 13:41 b...@herrin.us (William Herrin) wrote:
 > On Wed, Jan 20, 2021 at 12:40 PM  wrote:
 > > 2. Usenet is dead and besides a full feed is 20+TB/day because it's
 > > dead, but 20TB/day...
 > 
 > Hi Barry,
 > 
 > How much is it per day if you skip the groups distributing
 > finger-quote "linux isos"?

Around 300MB/day.

-- 
-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: USENET peers?!

[William Herrin]

On Wed, Jan 20, 2021 at 12:40 PM  wrote:
> 2. Usenet is dead and besides a full feed is 20+TB/day because it's
> dead, but 20TB/day...

Hi Barry,

How much is it per day if you skip the groups distributing
finger-quote "linux isos"?

Regards,
Bill Herrin

Re: DoD IP Space

[Owen DeLong]

> And don't get me wrong. I'm not advocating against v6. I'm merely explaining 
> how
> difficult it can be to migrate. In most large companies, the network is like 
> PG (the power utility California). If it works, nobody says well done. But 
> if
> the power is out, everyone gets angry and asks why we have fools operating the
> power grid. 

Indeed… It will be interesting to see how these CxOs with limited budges react
when backbones finally start turning off IPv4 and they discover that their 
network
is burning down because of years neglecting the IPv6 brush growing all around
them.

Owen

Re: DoD IP Space

[Bryan Fields]

On 1/20/21 12:52 PM, John Curran wrote:
> On 20 Jan 2021, at 12:17 PM, Bryan Fields 
> mailto:br...@bryanfields.net>> wrote:
>> 
>> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
>> network.
> 
>   While route hijacking isn't necessarily an ARIN issue, I will note 
> that several US law enforcement agencies (FBI & NCIS Cybercrime units) are 
> quite interested in such events and do investigate them looking for criminal 
> activity.
> 
> (See 
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>  for details.)

Can you ensure quoting is done properly?  I don't want more confusion between
what I wrote and the reply.

Nowhere did I state this was used to be for criminal or less than above board
use.  As soon as an entity decides to engage in criminal activities we're
beyond the question of what numbers they can run on their network.  I can't
think of a worse entity to hijack space from than the DOD.  Very few other
AS's have the ability to make it rain fire over a hijacker's NOC :-)

My comment was in terms of what a private network can do inside their own
network, or as part of a multi-entity network that is separate from the
"Internet".  The bigger question is, should you do this?  The answer is no for
a host of reasons, as networks rarely stay private.  Even the GRX went through
a big cleanup relating to this, and as of the last 6 years (maybe more)
requires space used to be allocated via the RIR's and not RFC1918 space.  IIRC
they still allow private ASN's.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: DoD IP Space

[Eric Kuhnke]

Additionally, examples of impersonating a corporate entity to acquire
unused IP space (Erie Forge and Steel's /16, anyone?) undoubtedly fall
under existing, pre-internet interstate commerce fraud laws...

http://web.mit.edu/net-security/Camp/2003/DBowie_IP_Hijacking.pdf

https://www.wired.com/images_blogs/threatlevel/files/edited-iphd-2.ppt



On Wed, Jan 20, 2021 at 9:54 AM John Curran  wrote:

> On 20 Jan 2021, at 12:17 PM, Bryan Fields  wrote:
>
>
> AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
> network.
>
>
>   While route hijacking isn't necessarily an ARIN issue, I will
> note that several US law enforcement agencies (FBI & NCIS Cybercrime units)
> are quite interested in such events and do investigate them looking for
> criminal activity.
>
> (See
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>  for
> details.)
>
> FYI,
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>

Re: DoD IP Space

[Eric Kuhnke]

Organizations that I have seen doing as you describe, because they ran out
of RFC1918 IP space, are also often using their existing private IP space
wastefully in the first place. Rather than using DoD /8s internally, if
they absolutely need to support v4-only equipment on their internal
management networks, they might be better served by considering that maybe
every POP doesn't need its own /24.

I'm talking about things I've seen where all of the management/monitoring
IPs of the equipment at a site might fit very comfortably in a v4 /27. But
that would be a labor intensive IP space and management address auditing
process of renumbering things, fixing internal DNS and rDNS, and updating
any myriad of things that might have the direct IP addresses of stuff
hardcoded into configuration files.

Rather than doing all of the above, they simply go "hey here's a /8 that's
highly unlikely our management network will ever need to talk to it in a
global routing table", and continue on with their /24 plan per tiny POP.



On Wed, Jan 20, 2021 at 8:38 AM Dorn Hetzel  wrote:

> I am aware of some companies that have used parts of a DoD /8 internally
> to address devices in the field that are too old to ever support IPV6.
> Those devices also never interact with the public internet, and never will,
> so for them, I guess the only risk would be that some other internal system
> that wants to talk to those devices would not also be able to talk to any
> endpoint on the public internet that wound up using space allocated from
> that block, some time in the future.  Is that about right or am I missing
> some key failure point?
>
> On Wed, Jan 20, 2021 at 9:59 AM j k  wrote:
>
>> My question becomes, what level of risk are these companies taking on by
>> using the DoD ranges on their internal networks? And have they
>> quantified the costs of this outage against moving to IPv6?
>>
>> Joe Klein
>>
>> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene
>> 1)
>> "*I skate to where the puck is going to be, not to where it has been."
>> -- *Wayne Gretzky
>> "I never lose. I either win or learn" - Nelson Mandela
>>
>>
>> On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:
>>
>>> Indeed.
>>> /John
>>>
>>> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
>>> >
>>> > But if you do this, make sure you keep track of where you might have
>>> put policies like this in, in case the DoD sells some the space or whatever
>>> in the future.
>>>
>>>

USENET peers?!

[bzs]

Through a coincidence of hardware failures "out there", which should
come back soon, and admittedly some inattentiveness as peers went
away, The World finds itself looking for some Usenet peers.

Not a full feed, we can talk.

1. OT? Feel free to point me to a better place which anyone is likely
reading.

2. Usenet is dead and besides a full feed is 20+TB/day because it's
dead, but 20TB/day...

-- 
-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: DoD IP Space

[Sabri Berisha]

- On Jan 20, 2021, at 6:58 AM, j k  wrote: 

Hi,

> My question becomes, what level of risk are these companies taking on by using
> the DoD ranges on their internal networks? And have they quantified the costs
> of this outage against moving to IPv6?

Not so long ago, while working for a large enterprise, my team was considering
the use of non-advertised public IP space when we realized we were close to 
running out of RFC1918 space. Eventually we decided against it as we had enough
options to reclaim unused RFC1918 from within the company. However, we had a
number of arguments against the use of public ranges:

- The risk of owners deciding to advertise their space. If so, since we operated
  a popular ecommerce site, there would be a huge risk of users encountering
  issues.
- The risk of inadvertent security issues. People using RFC1918 space, even the
  most network-illiterate dev, know that RFC1918 space is not accessible from
  the big bad internet. This (perceived) safety is absent when using public
  IP space.
- The risk of misconfiguring firewalls. Obviously, most of the policies cover
  RFC1918 space. Introducing non-RFC1918 space encourages human error.
- The risk of looking like fools if we would accidentally leak. Let's be honest.
  There are two groups of people on this list. Those who have accidentally 
leaked
  and those who will. I learned from my mistake(s).

As for IPv6: I know I sound like a broken record but one does not simply walk
into Mordor and migrate to IPv6. In a large enterprise, especially with one
using a lot of old code to support a highly popular webapp, it is easier to 
move a mountain than it is to get all nosed aligned. The network group(s),
corp, lab, DC, backbone, may all be ready, but that does not mean that your
cloud, kubernetes, frontend, backend, operations, and billing groups are
ready. Migrating to IPv6 is a cost, as there is no ROI. It is a cost center,
not an investment. Surely, we all on this list know that it is a mandatory
expense to ensure future delivery of services, but explain that to a VP with
limited budgets. Are they going for the short term win of new features, or for
the long term "win" of retaining revenue? We all know what their bonuses are
based on.

And don't get me wrong. I'm not advocating against v6. I'm merely explaining how
difficult it can be to migrate. In most large companies, the network is like 
PG (the power utility California). If it works, nobody says well done. But if
the power is out, everyone gets angry and asks why we have fools operating the
power grid. 

Thanks, 

Sabri

Re: DoD IP Space

[Jim Young via NANOG]

> On  Wednesday, January 20, 2021 13:48, Owen DeLong <...> wrote:
> 
> Do you think this still holds true if DoD were to (e.g.) sell that space
> to $CLOUD_PROVIDER or $ISP or $SUPPLIER or…?
> 
> I don’t have any knowledge of any events surrounding this space
> currently, but I do know that press releases and congress have
> discussed that possibility, so it cannot be ruled out.

There's this old blog post from 2010: T-Mobile: Clever or Insane?

https://blog.wireshark.org/2010/04/t-mobile-clever-or-insane/

Best regards,

Jim Y.

Re: DoD IP Space

[Brandon Martin]

On 1/20/21 1:48 PM, Owen DeLong wrote:

Do you think this still holds true if DoD were to (e.g.) sell that space to 
$CLOUD_PROVIDER or $ISP or $SUPPLIER or…?

I don’t have any knowledge of any events surrounding this space currently, but 
I do know that press releases and congress have discussed that possibility, so 
it cannot be ruled out.


This is a risk you take when using squad space of any form.  DoD space 
is somewhat uniquely "safe" in this regard but not immune to such things.


Honestly I'd be just about as worried as a potential legitimate non-DoD 
public Internet user of that space about reachability issues as I would 
as someone squatting on it internally within my network about it 
becoming a part of the common global routing table.


I also suspect your typical large corporate environment cares less about 
broad, global reachability than other Internet users in many cases.

--
Brandon Martin

Re: DoD IP Space

[Owen DeLong]

> On Jan 20, 2021, at 07:11 , Brandon Martin  wrote:
> 
> On 1/20/21 9:58 AM, j k wrote:
>> My question becomes, what level of risk are these companies taking on by 
>> using the DoD ranges on their internal networks? And have they quantified 
>> the costs of this outage against moving to IPv6?
> 
> Honestly I can't think of much unless maybe they're a defense contractor that 
> would potentially end up with DoD ranges (non-isolated/classified networks) 
> in their view of the global routing table.  Appropriately treating it like 
> "my networks" and/or RFC1918 in your routing policies (not exporting it, not 
> accepting routes for it, etc.) would be required to properly ensure network 
> stability of course.

Do you think this still holds true if DoD were to (e.g.) sell that space to 
$CLOUD_PROVIDER or $ISP or $SUPPLIER or…?

I don’t have any knowledge of any events surrounding this space currently, but 
I do know that press releases and congress have discussed that possibility, so 
it cannot be ruled out.

Owen

Re: DoD IP Space

[John Curran]

Brandon - 

Agreed – the key phrase being "within a more limited scope” …

/John

> On 20 Jan 2021, at 1:26 PM, Brandon Martin  wrote:
> 
> On 1/20/21 12:52 PM, John Curran wrote:
>> 
>>   While route hijacking isn't necessarily an ARIN issue, I will 
>> note that several US law enforcement agencies (FBI & NCIS Cybercrime units) 
>> are quite interested in such events and do investigate them looking for 
>> criminal activity.   
>> 
>> (See 
>> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>>  for details.) 
>> 
> 
> I think the difference is semantic but a very important one nonetheless.
> 
> Announcing a netblock that isn't yours and that you don't have authorization 
> to use to others under the same terms and assumptions as you announce those 
> to which you do hold legitimate rights or otherwise purporting to be a 
> legitimate user of them on what we know as the "public Internet", that is the 
> Internet where numbers are managed by IANA and the relevant RIRs is a "big 
> deal".
> 
> Using numbers in a manner contrary to how they are assigned on the "public 
> Internet" within a more limited scope where everybody agrees that the use of 
> such numbers may be contrary to IANA and relevant RIR assignments is more 
> along the lines of "you operate your network however you want".
> 
> Other things would fall under the same purview.  For example "alternate root" 
> DNS hierarchies with extra TLDs or even TLDs used in contrast to ICANN 
> recommendations would have similar considerations.
> -- 
> Brandon Martin

Re: RADB contact needed

[Ostap Efremov]

Hi,

I posted my initial e-mail 24 hours ago to NANOG but the moderation took a
while and RADB has since removed all entries for this now unallocated /14.
They deleted an incredible 408 records. Thanks a lot for this action RADB!
However, seems like isp's are already making new RADB entries for..
unallocated ipv4 space... created today.. 20210120
https://www.radb.net/query?advanced_query=1=-M+196.52.0.0%2F14&-T+option=_option=&-i+option==RADB
There is also a bunch of RIPE-NONAUTH and ARIN-NONAUTH that is awaiting
cleanup by RIPE and ARIN, they have been notified.

For a little background on this now revoked 196.52.0.0/14
https://afnog.org/pipermail/afnog/2020-December/004056.html
https://krebsonsecurity.com/2019/12/the-great-50m-african-ip-address-heist/
However this doesn't matter to me, I'm merely trying to get ~350
unallocated prefixes that are currently routed by ~70 ASNs.
This has nothing to do with " attempts to lockdown African Internet access
by various political factions, for example the situation in Uganda."
I believe that since 20 December 2020, a little bit after RFG's afrinic
post, the whois on that prefix changed and included a note:

> inetnum:196.52.0.0 - 196.55.255.255
> netname:LogicWeb-Inc
> descr:  LogicWeb Inc.
> descr:  3003 Woodbridge Ave
> descr:  Edison, NJ 08837
> country:ZA
> remarks:REMARK
> remarks:The custodianship of this IP prefix is presently
> remarks:in dispute. A police investigation is on-going
> remarks:and AFRINIC reserves the right to
> remarks:reclaim this IP prefix at anytime.
> remarks:REMARK
>
However due to AFRINIC and their lack of "last-modified", i don't know when
exactly  And about 4 days ago it got revoked by AFRINIC and became
UNALLOCATED.
Many other /14's also got this note recently.
And yes Matt Harris, parts of this /14 were announced by logicweb
themselves, but parts were also being leased out to end users for prices as
low as 35$ per month for a /24.
I doubt that even 1% of this /14 was ever announced in the AFRINIC region.
LogicWeb is now sending the following reply to their ip-lease customers and
the isp's were they directly announce, including strange claims such as
"The original LOA we provided you is valid." while it's literally
unallocated.
https://pastebin.com/raw/BUvY003C

Greetings,
Ostap

On Wed, Jan 20, 2021 at 9:14 PM Matt Harris  wrote:

> Matt Harris
> | Infrastructure Lead Engineer
> 816‑256‑5446
> | Direct
> Looking for something?
> *Helpdesk Portal* <https://help.netfire.net/>
> | *Email Support* 
> | *Billing Portal* <https://my.netfire.net/>
> We build and deliver end‑to‑end IT solutions.
> On Wed, Jan 20, 2021 at 10:56 AM Mel Beckman  wrote:
>
>> Ostap,
>>
>> Why was this prefix revoked? And what is your interest in the matter?  I
>> ask because, of late, there have been attempts to lockdown African Internet
>> access by various political factions, for example the situation in Uganda.
>>
>>  -mel
>>
>
> It's looking like this block had been (probably fraudulently) parceled out
> and sold in small chunks to legitimate-but-gullible companies? The first
> /24 out of it and another latter /24 are advertised by a rural Nebraska
> WISP with a single-homed upstream to a company that I know to be legitimate
> who had added their entry to RADB for their customer. Most of the other
> chunks look to be advertised by random seemingly-legitimate organizations
> too.
>
> When this space stops routing, there's going to be a big mess and I'm
> pretty sure a lot of lawsuits.
>
> Ooof.
>
>

Re: DoD IP Space

[Brandon Martin]

On 1/20/21 12:52 PM, John Curran wrote:
> 
>   While route hijacking isn't necessarily an ARIN issue, I will note 
> that several US law enforcement agencies (FBI & NCIS Cybercrime units) are 
> quite interested in such events and do investigate them looking for criminal 
> activity.   
> 
> (See 
> https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
>  for details.) 
> 

I think the difference is semantic but a very important one nonetheless.

Announcing a netblock that isn't yours and that you don't have authorization to 
use to others under the same terms and assumptions as you announce those to 
which you do hold legitimate rights or otherwise purporting to be a legitimate 
user of them on what we know as the "public Internet", that is the Internet 
where numbers are managed by IANA and the relevant RIRs is a "big deal".

Using numbers in a manner contrary to how they are assigned on the "public 
Internet" within a more limited scope where everybody agrees that the use of 
such numbers may be contrary to IANA and relevant RIR assignments is more along 
the lines of "you operate your network however you want".

Other things would fall under the same purview.  For example "alternate root" 
DNS hierarchies with extra TLDs or even TLDs used in contrast to ICANN 
recommendations would have similar considerations.
-- 
Brandon Martin

Re: DoD IP Space

[John Curran]

On 20 Jan 2021, at 12:17 PM, Bryan Fields 
mailto:br...@bryanfields.net>> wrote:

AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
network.

  While route hijacking isn't necessarily an ARIN issue, I will note 
that several US law enforcement agencies (FBI & NCIS Cybercrime units) are 
quite interested in such events and do investigate them looking for criminal 
activity.

(See 
https://pc.nanog.org/static/published/meetings/NANOG77/2108/20191028_Elverson_Your_As_Is_v1.pdf
 for details.)

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

Re: DoD IP Space

[Bryan Fields]

On 1/20/21 10:05 AM, Dorn Hetzel wrote:
> I am aware of some companies that have used parts of a DoD /8 internally to
> address devices in the field that are too old to ever support IPV6.  Those
> devices also never interact with the public internet, and never will, so
> for them, I guess the only risk would be that some other internal system
> that wants to talk to those devices would not also be able to talk to any
> endpoint on the public internet that wound up using space allocated from
> that block, some time in the future.  Is that about right or am I missing
> some key failure point?

You're free to use any IP space you want internally, no one is going to tell
you what to do inside your network.  Most providers will not route it for you
though.  There are some exceptions to this, the GRX being one, but that's it's
own VPN and separate network from the global Internet.  IIRC, here was some
VPN provider using 5/8 before that was assigned.

AFAIK IANA and the RIR's cannot enforce use of IP space assignments on any
network.
-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: RADB contact needed

[Matt Harris]

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
On Wed, Jan 20, 2021 at 10:56 AM Mel Beckman  wrote:

> Ostap,
>
> Why was this prefix revoked? And what is your interest in the matter?  I
> ask because, of late, there have been attempts to lockdown African Internet
> access by various political factions, for example the situation in Uganda.
>
>  -mel
>

It's looking like this block had been (probably fraudulently) parceled out
and sold in small chunks to legitimate-but-gullible companies? The first
/24 out of it and another latter /24 are advertised by a rural Nebraska
WISP with a single-homed upstream to a company that I know to be legitimate
who had added their entry to RADB for their customer. Most of the other
chunks look to be advertised by random seemingly-legitimate organizations
too.

When this space stops routing, there's going to be a big mess and I'm
pretty sure a lot of lawsuits.

Ooof.

Re: RADB contact needed

[Mel Beckman]

Ostap,

Why was this prefix revoked? And what is your interest in the matter?  I ask 
because, of late, there have been attempts to lockdown African Internet access 
by various political factions, for example the situation in Uganda.

 -mel 

> On Jan 20, 2021, at 8:33 AM, Ostap Efremov  wrote:
> 
> Hello,
> 
> I'm in need off a RADB contact.
> I have reached out to them multiple times the past 72 hours requesting urgent 
> removal of all IRR records for a recently revoked afrinic /14
> However they did not reply and did not remove any records which belong to 
> this unallocated ip space.
> This concerns 196.52.0.0/14, this massive block got revoked by afrinic 
> approximately 4 days ago and is now unallocated.
> Nothing in this /14 should be routed.
> However, about 350 prefixes of various sizes inside this /14 are still 
> announced.
> If RADB removes all these IRR's, the routability of these 350 ip hijacks will 
> greatly be reduced.
> https://www.radb.net/query?advanced_query=1=-M+196.52.0.0%2F14&-T+option=_option=&-i+option==RADB
>  
> 
> 
> Greetings,
> Ostap Efremov
> 

Re: DoD IP Space

[Dorn Hetzel]

Yeah, definitely talking about use that is deep behind multiple layers of
firewalls, or maybe even air-gapped with respect to routable protocols.  I
won't say what sort of industry runs large piles of ancient gear, but you
could probably guess...

On Wed, Jan 20, 2021 at 10:13 AM Brandon Martin 
wrote:

> On 1/20/21 9:58 AM, j k wrote:
> > My question becomes, what level of risk are these companies taking on by
> > using the DoD ranges on their internal networks? And have they
> > quantified the costs of this outage against moving to IPv6?
>
> Honestly I can't think of much unless maybe they're a defense contractor
> that would potentially end up with DoD ranges (non-isolated/classified
> networks) in their view of the global routing table.  Appropriately
> treating it like "my networks" and/or RFC1918 in your routing policies
> (not exporting it, not accepting routes for it, etc.) would be required
> to properly ensure network stability of course.
>
> Some OSes treat RFC1918 space as inherently "special" (extra trusted,
> etc.) and wouldn't treat the DoD ranges as such, but those behaviors are
> typically undesirable or at least not relied on on a network of that
> scale, anyway.
>
> Not that I'd recommend it.
> --
> Brandon Martin
>

Re: DoD IP Space

[Dorn Hetzel]

I am aware of some companies that have used parts of a DoD /8 internally to
address devices in the field that are too old to ever support IPV6.  Those
devices also never interact with the public internet, and never will, so
for them, I guess the only risk would be that some other internal system
that wants to talk to those devices would not also be able to talk to any
endpoint on the public internet that wound up using space allocated from
that block, some time in the future.  Is that about right or am I missing
some key failure point?

On Wed, Jan 20, 2021 at 9:59 AM j k  wrote:

> My question becomes, what level of risk are these companies taking on by
> using the DoD ranges on their internal networks? And have they
> quantified the costs of this outage against moving to IPv6?
>
> Joe Klein
>
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> "*I skate to where the puck is going to be, not to where it has been."
> -- *Wayne Gretzky
> "I never lose. I either win or learn" - Nelson Mandela
>
>
> On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:
>
>> Indeed.
>> /John
>>
>> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
>> >
>> > But if you do this, make sure you keep track of where you might have
>> put policies like this in, in case the DoD sells some the space or whatever
>> in the future.
>>
>>

Revoked AFRINIC block resulting in more than 350 bogon prefixes

[Ostap Efremov]

Hi,

196.52.0.0/14 was recently revoked by AFRINIC.
However, more than 350 prefixes inside of this /14 are currently still
announced.
This is all unallocated and should not be routed at all.
Example
https://bgp.he.net/net/196.54.129.0/24#_netinfo
Here is a full list of them https://pastebin.com/raw/MHaW3nPe

Greetings,
Ostap Efremov

RADB contact needed

[Ostap Efremov]

Hello,

I'm in need off a RADB contact.
I have reached out to them multiple times the past 72 hours requesting 
urgent removal of all IRR records for a recently revoked afrinic /14
However they did not reply and did not remove any records which belong 
to this unallocated ip space.
This concerns 196.52.0.0/14, this massive block got revoked by afrinic 
approximately 4 days ago and is now unallocated.

Nothing in this /14 should be routed.
However, about 350 prefixes of various sizes inside this /14 are still 
announced.
If RADB removes all these IRR's, the routability of these 350 ip hijacks 
will greatly be reduced.
https://www.radb.net/query?advanced_query=1=-M+196.52.0.0%2F14&-T+option=_option=&-i+option==RADB 



Greetings,
Ostap Efremov

Upcoming operational changes to ARIN services (was: Fwd: [arin-announce] Reminder--Upcoming Security Improvements and Change to RDAP URL)

[John Curran]

Folks –

Please note upcoming TLS 1.1 deprecation and RDAP URL changes – if you need to 
update your systems, please start this process sufficiently early to avoid 
impacts.

Thanks!
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] Reminder--Upcoming Security Improvements and Change to 
RDAP URL
Date: 20 January 2021 at 10:09:03 AM EST
To: "arin-annou...@arin.net" 
mailto:arin-annou...@arin.net>>

This announcement is to remind you of previously-announced changes that ARIN is 
making, including the following:

- security improvements for Whois-RWS, RDAP, and 
www.arin.net, scheduled for on or about 19 February 2021
- change of address to the Registration Data Access Protocol (RDAP) bootstrap 
server, scheduled for on or about 30 June 2021

More information is provided in this announcement.

*Security Improvements for WhoWhois-RWS, RDAP, and 
www.arin.net*

As announced on 22 October 2020 and 2 December 2020, upcoming security 
improvements for Whois-RWS, RDAP, and www.arin.net are 
scheduled to be completed on or around 19 February 2021. The following 
information is from the previous announcement:

Earlier this year, ARIN implemented security enhancements that included ending 
support for TLS 1.0 for Whois-RWS and RDAP services and improving ciphers used 
in www.arin.net. As part of our continuing effort to 
improve security, on or around 19 February 2021, we will end support for TLS 
1.1 and weak Diffie-Hellman (DH) key exchange parameters on 
www.arin.net, Whois-RWS, and RDAP. We will also update the 
ciphers available on Whois-RWS and RDAP to match those on www and 
reg.arin.net. The removal of TLS 1.1 may impact the way 
you interface programmatically with ARIN to query and retrieve information from 
Whois-RWS and RDAP.

Changes in our supported versions of TLS are due to well-known security issues 
with this protocol. More information is available at 
https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/  . ARIN 
continues to support TLS 1.2. The cipher update satisfies ACSP Suggestion 
2015.15: Improvements to SSL Security for whois.arin.net.

We are providing you advance notice of these changes, as you may need to make 
configuration or code changes on your clients that interface with Whois-RWS and 
RDAP services. We encourage you to make these changes so you will have no 
operational impact when we disable the vulnerable transport protocol version.

*RDAP Bootstrap Server Change of Address*

As announced on 21 November 2020 and 16 December 2020, the ARIN Registration 
Data Access Protocol (RDAP) Bootstrap server address is changing. The following 
information is from the previous announcement:

ARIN is changing the address of our Registration Data Access Protocol (RDAP) 
bootstrap server from https://rdap.arin.net/bootstrap to 
https://rdap-bootstrap.arin.net/bootstrap. A bootstrap server is used to 
forward queries from users seeking registration data for Internet resources to 
another server that can provide more detailed registration information about 
that resource. The address of the bootstrap server is used in the “query URL” 
sent from a client application or entered into a command-line query by a user.

ARIN has set up a redirect to automatically route queries from the old URL to 
the new URL when support for the old URL is ended. The old URL will be retired 
on 30 June 2021, and the redirect will be active. However, it is important to 
note we can’t guarantee the redirect will be respected by all clients. In order 
to avoid any problems, queries should be changed to use the new URL, 
https://rdap-bootstrap.arin.net/bootstrap, as soon as possible.

More information about how the bootstrap URL works and this upcoming change can 
be found on TeamARIN at 
https://teamarin.net/2020/12/11/buckle-up-change-of-address-coming-for-arins-bootstrap-server/.
 If you have questions or comments about this change, please submit an Ask ARIN 
ticket using your ARIN Online account, or contact the Registration Services 
Help Desk by phone Monday through Friday, 7:00 AM to 7:00 PM ET at 
+1.703.227.0660.

Regards,

Mark Kosters
Chief Technology Officer
American Registry for Internet Numbers (ARIN)


___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List 
(arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: DoD IP Space

[Fred Baker]

I recently had a discussion with an Asian ISP that was asking the IETF to 
PLEASE re-declare DoD space to be private space so that they could use it. This 
particular ISP uses IPv6 extensively (a lot of their services are in fact 
IPv6-only) but has trouble with its enterprise customers. Frankly, enterprise 
use of IPv6 is a problem; they seem to push back pretty hard against using IPv6.

I find this thread highly appropriate.

> On Jan 20, 2021, at 6:58 AM, j k  wrote:
> 
> My question becomes, what level of risk are these companies taking on by 
> using the DoD ranges on their internal networks? And have they quantified the 
> costs of this outage against moving to IPv6?
> 
> Joe Klein
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> "I skate to where the puck is going to be, not to where it has been." -- 
> Wayne Gretzky
> "I never lose. I either win or learn" - Nelson Mandela
> 
> 
> 
> On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:
> Indeed.
> /John
> 
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
> >
> > But if you do this, make sure you keep track of where you might have put 
> > policies like this in, in case the DoD sells some the space or whatever in 
> > the future.
> 



signature.asc
Description: Message signed with OpenPGP

Re: DoD IP Space

[Brandon Martin]

On 1/20/21 9:58 AM, j k wrote:
My question becomes, what level of risk are these companies taking on by 
using the DoD ranges on their internal networks? And have they 
quantified the costs of this outage against moving to IPv6?


Honestly I can't think of much unless maybe they're a defense contractor 
that would potentially end up with DoD ranges (non-isolated/classified 
networks) in their view of the global routing table.  Appropriately 
treating it like "my networks" and/or RFC1918 in your routing policies 
(not exporting it, not accepting routes for it, etc.) would be required 
to properly ensure network stability of course.


Some OSes treat RFC1918 space as inherently "special" (extra trusted, 
etc.) and wouldn't treat the DoD ranges as such, but those behaviors are 
typically undesirable or at least not relied on on a network of that 
scale, anyway.


Not that I'd recommend it.
--
Brandon Martin

Re: DoD IP Space

[j k]

My question becomes, what level of risk are these companies taking on by
using the DoD ranges on their internal networks? And have they
quantified the costs of this outage against moving to IPv6?

Joe Klein

"inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
"*I skate to where the puck is going to be, not to where it has been."
-- *Wayne
Gretzky
"I never lose. I either win or learn" - Nelson Mandela


On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:

> Indeed.
> /John
>
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
> >
> > But if you do this, make sure you keep track of where you might have put
> policies like this in, in case the DoD sells some the space or whatever in
> the future.
>
>

Re: Hosting recommendations ... ?

[Bryan Holloway]

Thank you, everyone, for the advice, input, and suggestions, both on- 
and off-list.


Got a few sales pitches too, which was to be expected. :) All good.

Much appreciated, again.

Cheers,
- bryan



On 1/19/21 4:44 PM, Bryan Holloway wrote:

Hey gang ...

Looking for a reputable (i.e., no hosting of spammers or other 
ne'er-do-wells) hosting provider with possibly a global footprint. If 
not, US is #1 desire; EU #2.


Requirements, more or less:

* Desire to host 2-3 hypervisors, probably running something akin to 
Proxmox ...


* ~5-10TB storage with the possibility of expansion ...

* 1G hand-off / 100 Mbps or less commit ... i.e., low BW, but burstable.

* Bringing my own IP space and need to be able to peer BGP with vendor.

* Cross-DC redundancy or mirroring or somesuch desirable.

* Backups are of interest, although I can do my own if need be.

Any recommendations that are non-Amazonian? Feel free to reach out 
off-list if you prefer.


#1 requirement ... the reputability part ...

Thank you all in advance!

     - bryan

Spectrum Routing Contact

[Robert Blayzor]

I was wondering if someone from Spectrum engineering could hit me out of 
band. We have a customer in one of our data centers that is having some 
strange routing issues through Cogent and Spectrum AS's 7843 & 12271. 
Was wondering if someone could share some insight BGP looking glass type 
info with me so we can figure this out.


TIA

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: DoD IP Space

[John Curran]

Indeed.
/John 

> On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
> 
> But if you do this, make sure you keep track of where you might have put 
> policies like this in, in case the DoD sells some the space or whatever in 
> the future.

Re: DoD IP Space

[Cynthia Revström via NANOG]

I believe the DoD space might be a bit of a difficult one, because (correct
me if I am wrong here) due to it being so massive and unused for so long,
certain large corporations that have run out of RFC1918, etc. space
have started using it internally.

So my take on it is, don't consider it as a bogon from your upstreams, but
maybe have some questions if your downstream is attempting to announce it
as they are somewhat unlikely to be the DoD.
But if you do this, make sure you keep track of where you might have put
policies like this in, in case the DoD sells some the space or whatever in
the future.

-Cynthia


On Wed, Jan 20, 2021 at 2:39 PM John Curran  wrote:

> Tom –
>
> Most definitely: lack of routing history is not at all a reliable
> indicator of the potential for valid routing of a given IPv4 block in the
> future, so best practice suggest that allocated address space should not be
> blocked by others without specific cause.
>
> Doing otherwise opens one up to unexpected surprises when issued space
> suddenly becomes more active in routing and is yet is inexplicably
> unreachable for some destinations.
>
> /John
>
> On Nov 5, 2019, at 10:38 AM, Tom Beecher  wrote:
>
>
> Using the generally accepted definition of a bogon ( RFC 1918 / 5735 /
> 6598 + netblock not allocated by an RiR ), 22/8 is not a bogon and
> shouldn't be treated as one.
>
> The DoD does not announce it to the DFZ, as is their choice, but nothing
> says they may not change that position tomorrow. There are plenty of
> subnets out there that are properly allocated by an RiR, but the assignees
> do not send them to the DFZ because of $reasons.
>
> In my opinion, creating bogon lists that include allocated but not
> advertised prefixes is poor practice that is likely to end up biting an
> operator at one point or another.
>
> On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov 
> wrote:
>
>> Peace,
>>
>> On Tue, Nov 5, 2019, 4:55 PM David Conrad  wrote:
>> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG 
>> wrote:
>> >> This thread got me to wondering, is there any
>> >> legitimate reason to see 22/8 on the public
>> >> Internet?  Or would it be okay to treat 22/8
>> >> like a Bogon and drop it at the network edge?
>> >
>> > Given the transfer market for IPv4 addresses,
>> > the spot price for IPv4 addresses, and the need
>> > of even governments to find “free” (as in
>> > unconstrained) money, I’d think treating any
>> > legacy /8 as a bogon would not be prudent.
>>
>> It has been said before in this thread that the DoD actively uses this
>> network internally.  I believe if the DoD were to cut costs, they
>> would be able to do it much more effectively in many other areas, and
>> their IPv4 networks would be about the last thing they would think of
>> (along with switching off ACs Bernard Ebbers-style).  With that in
>> mind, treating the DoD networks as bogons now makes total sense to me.
>>
>> --
>> Töma
>>
>

Re: DoD IP Space

[John Curran]

Tom –

Most definitely: lack of routing history is not at all a reliable indicator of 
the potential for valid routing of a given IPv4 block in the future, so best 
practice suggest that allocated address space should not be blocked by others 
without specific cause.  

Doing otherwise opens one up to unexpected surprises when issued space suddenly 
becomes more active in routing and is yet is inexplicably unreachable for some 
destinations.

/John 

> On Nov 5, 2019, at 10:38 AM, Tom Beecher  wrote:
> 
> 
> Using the generally accepted definition of a bogon ( RFC 1918 / 5735 / 6598 + 
> netblock not allocated by an RiR ), 22/8 is not a bogon and shouldn't be 
> treated as one. 
> 
> The DoD does not announce it to the DFZ, as is their choice, but nothing says 
> they may not change that position tomorrow. There are plenty of subnets out 
> there that are properly allocated by an RiR, but the assignees do not send 
> them to the DFZ because of $reasons. 
> 
> In my opinion, creating bogon lists that include allocated but not advertised 
> prefixes is poor practice that is likely to end up biting an operator at one 
> point or another.
> 
>> On Tue, Nov 5, 2019 at 9:45 AM Töma Gavrichenkov  wrote:
>> Peace,
>> 
>> On Tue, Nov 5, 2019, 4:55 PM David Conrad  wrote:
>> > On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG  
>> > wrote:
>> >> This thread got me to wondering, is there any
>> >> legitimate reason to see 22/8 on the public
>> >> Internet?  Or would it be okay to treat 22/8
>> >> like a Bogon and drop it at the network edge?
>> >
>> > Given the transfer market for IPv4 addresses,
>> > the spot price for IPv4 addresses, and the need
>> > of even governments to find “free” (as in
>> > unconstrained) money, I’d think treating any
>> > legacy /8 as a bogon would not be prudent.
>> 
>> It has been said before in this thread that the DoD actively uses this
>> network internally.  I believe if the DoD were to cut costs, they
>> would be able to do it much more effectively in many other areas, and
>> their IPv4 networks would be about the last thing they would think of
>> (along with switching off ACs Bernard Ebbers-style).  With that in
>> mind, treating the DoD networks as bogons now makes total sense to me.
>> 
>> --
>> Töma