Question on 7.0.0.0/8

Anybody know if 7.0.0.0/8 is or is not allocated to DoD?
The data at IANA and ARIN is kind-of confusing...

------------------------------------------------------------
---
7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint
            7.0.0.0 - 7.255.255.255 ## Bogon (unallocated)
ip range
------------------------------------------------------------
---
ht
tp://www.iana.org/assignments/ipv4-address-space
007/8   Apr 95   IANA - Reserved
------------------------------------------------------------
---
[IPv4 whois information for 7.0.0.1 ]
[whois.arin.net]

OrgName:    DoD Network Information Center
OrgID:      DNIC
Address:    3990 E. Broad Street
City:       Columbus
StateProv:  OH
PostalCode: 43218
Country:    US

NetRange:   7.0.0.0 - 7.255.255.255
CIDR:       7.0.0.0/8
NetName:    DISANET7
NetHandle:  NET-7-0-0-0-1
Parent:
NetType:    Direct Allocation
Comment:
RegDate:    1997-11-24
Updated:    2006-04-28

OrgTechHandle: MIL-HSTMST-ARIN
OrgTechName:   Network DoD
OrgTechPhone:  +1-800-365-3642
OrgTechEmail:  HOSTMASTERnic.mil

-- 
William Leibzon
Elan Networks
williamelan.net

CYMRU has 7/8 listed as a bogon:
	http://w
ww.cymru.com/Documents/bogon-dd.html

Their list is more or less authoritative, so I would believe
that you should never see traffic from that netblock. This
is also consistent with Sprint blackholeing it as a bogon in
your original post.

That said, it doesn't mean that the netblock is unused. Most
likely it is a netblock that DoD actually uses, but it is
only routed on DoD's private backbone and never on the
Internet.

If you are seeing traffic to/from that netblock, there are
two possibilities that come to mind:
    1) Spoofed source IPs on UDP and ICMP traffic.
    2) If it is TCP traffic, then probably someone has
hijacked the netblock and is publishing BGP routes to it.
Hijacking unallocated netblocks has been a common spamming
technique for at least 10 years -- although with today's
botnets it does not appear to be as commonly used (IMHO).
Also, the spammers usually try to hide within smaller
unallocated netblocks (< /16) of allocated netblocks (a
little less obvious and less likely to be blackholed).

If you are seeing traffic to/from this netblock, PLEASE do a
traceroute back to that IP -- in fact do several from
different networks -- to make it easier for law enforcement
to trace back to the hijacker. Also, try using something
more smarter than standard traceoute, such as:
	http://www.paris-tra
ceroute.net/

If you are seeing traffic from hijacked netblocks, contact
your local InfraGuard group -- I know the FBI will be VERY
interested in that information.

Jon Kibler



william(at)elan.net wrote:
> 
> 
> Anybody know if 7.0.0.0/8 is or is not allocated to
DoD?
> The data at IANA and ARIN is kind-of confusing...
> 
>
------------------------------------------------------------
---
> 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint
>            7.0.0.0 - 7.255.255.255 ## Bogon
(unallocated) ip range
>
------------------------------------------------------------
---
> ht
tp://www.iana.org/assignments/ipv4-address-space
> 007/8   Apr 95   IANA - Reserved
>
------------------------------------------------------------
---
> [IPv4 whois information for 7.0.0.1 ]
> [whois.arin.net]
> 
> OrgName:    DoD Network Information Center
> OrgID:      DNIC
> Address:    3990 E. Broad Street
> City:       Columbus
> StateProv:  OH
> PostalCode: 43218
> Country:    US
> 
> NetRange:   7.0.0.0 - 7.255.255.255
> CIDR:       7.0.0.0/8
> NetName:    DISANET7
> NetHandle:  NET-7-0-0-0-1
> Parent:
> NetType:    Direct Allocation
> Comment:
> RegDate:    1997-11-24
> Updated:    2006-04-28
> 
> OrgTechHandle: MIL-HSTMST-ARIN
> OrgTechName:   Network DoD
> OrgTechPhone:  +1-800-365-3642
> OrgTechEmail:  HOSTMASTERnic.mil
> 

-- 
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
(843) 849-8214

On Sat, 14 Apr 2007, Jon R. Kibler wrote:

> CYMRU has 7/8 listed as a bogon:
> 	http://w
ww.cymru.com/Documents/bogon-dd.html
>
> Their list is more or less authoritative, so I would
believe that you should 
> never see traffic from that netblock. This is also
consistent with Sprint 
> blackholeing it as a bogon in your original post.

Their list is no more "authoritative" then mine
and I suspect they simply 
did not look into this netblock case before. Another bogon
tracking
system http://www.cidr-re
port.org/#Bogons does not list it as bogon 
even though it does see same 7.1.1.0/24 announcement by
Sprint.

I'm also curious to know why you think that Sprintlink is
blackholing it?

-----

In case you're wondering they do route this block, here is
where my
traceroute ends:
...
11  sl-bb20-rly-12-0.sprintlink.net (144.232.7.249)  79.181
ms  76.106 ms 
77.925 ms
12  sl-bb20-tuk-11-0.sprintlink.net (144.232.20.137)  97.675
ms  97.748 ms 
98.021 ms
13  sl-bb21-tuk-15-0.sprintlink.net (144.232.20.133)  97.672
ms  97.579 ms 
280.387 ms
14  sl-bb21-lon-14-0.sprintlink.net (144.232.19.70)  168.667
ms  169.151 
ms  179.363 ms
15  sl-bb23-lon-14-0.sprintlink.net (213.206.128.54) 
168.879 ms  168.922 
ms  168.716 ms
16  sl-bb21-ams-3-0.sprintlink.net (213.206.129.142) 
161.711 ms  161.816 
ms  180.609 ms
17  sl-bb20-ham-14-0.sprintlink.net (213.206.129.50) 
167.782 ms  167.884 
ms  167.716 ms
18  sl-gw2-ham-0-0-0.sprintlink.net (217.147.96.100) 
167.770 ms  167.928 
ms  168.193 ms
19  * * *

Last hop is in Germany which is a bit suspicious for
supposed US DoD block 
but there are some military bases there after all...

Also there are some interesting messages about this netblock
that one can
find on the net, like say:
  http://www.monkey.org/openbsd/archive/misc/0207/msg
01215.html
  http://irisheagle.blogspot.com/2006_03_01_irish
eagle_archive.html

> That said, it doesn't mean that the netblock is unused.
Most likely it is
> a netblock that DoD actually uses, but it is only
routed on DoD's private 
> backbone and never on the Internet.

If that is the case and they started using it in the days of
J Postel
with his permission, then its not a bogon. Conflicting
information at
ARIN and especially that their info was updated in 2006
leads me to 
believe that's the case. Add to it that I have several
copies of old
DoD hosts table and they all list it as
"EDN-TEMP", but what it refers
to and if the block should or should not still be in use I
don't know.

Unfortunately all of this does not mean you should allow (or
deny) traffic 
from 7.0.0.0/8, but it also does not mean that if you do see
any traffic 
that its necessarily unauthorized.

> william(at)elan.net wrote:
>> 
>> Anybody know if 7.0.0.0/8 is or is not allocated to
DoD?
>> The data at IANA and ARIN is kind-of confusing...
>> 
>>
------------------------------------------------------------
---
>> 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint
>>            7.0.0.0 - 7.255.255.255 ## Bogon
(unallocated) ip range
>>
------------------------------------------------------------
---
>> ht
tp://www.iana.org/assignments/ipv4-address-space
>> 007/8   Apr 95   IANA - Reserved
>>
------------------------------------------------------------
---
>> [IPv4 whois information for 7.0.0.1 ]
>> [whois.arin.net]
>> 
>> OrgName:    DoD Network Information Center
>> OrgID:      DNIC
>> Address:    3990 E. Broad Street
>> City:       Columbus
>> StateProv:  OH
>> PostalCode: 43218
>> Country:    US
>> 
>> NetRange:   7.0.0.0 - 7.255.255.255
>> CIDR:       7.0.0.0/8
>> NetName:    DISANET7
>> NetHandle:  NET-7-0-0-0-1
>> Parent:
>> NetType:    Direct Allocation
>> Comment:
>> RegDate:    1997-11-24
>> Updated:    2006-04-28
>> 
>> OrgTechHandle: MIL-HSTMST-ARIN
>> OrgTechName:   Network DoD
>> OrgTechPhone:  +1-800-365-3642
>> OrgTechEmail:  HOSTMASTERnic.mil

On Sat, Apr 14, 2007, william(at)elan.net wrote:

> If that is the case and they started using it in the
days of J Postel
> with his permission, then its not a bogon. Conflicting
information at
> ARIN and especially that their info was updated in 2006
leads me to 
> believe that's the case. Add to it that I have several
copies of old
> DoD hosts table and they all list it as
"EDN-TEMP", but what it refers
> to and if the block should or should not still be in
use I don't know.
> 
> Unfortunately all of this does not mean you should
allow (or deny) traffic 
> from 7.0.0.0/8, but it also does not mean that if you
do see any traffic 
> that its necessarily unauthorized.

.. you can always check the RIPE BGP announcement history to
see whether
its been announced forever or is a recent addition, no? Are
they still
running that project?


Adrian

On 14-apr-2007, at 11:56, william(at)elan.net wrote:

>> CYMRU has 7/8 listed as a bogon:
>> 	http://w
ww.cymru.com/Documents/bogon-dd.html

>> Their list is more or less authoritative, so I
would believe that  
>> you should never see traffic from that netblock.
This is also  
>> consistent with Sprint blackholeing it as a bogon
in your original  
>> post.

> Their list is no more "authoritative" then
mine and I suspect they  
> simply did not look into this netblock case before.

I would think IANA is authoritative...

(Note that the ARIN whois server will not complain about
searches for  
a prefix, but it won't match anything, you need to search on
an IP  
address.)

Another interesting case:

025/8   Jan 95   UK Ministry of Defense             
(Updated - Jan 06)


# whois -h whois.arin.net 25.0.0.0 | more
OrgName:    DINSA, Ministry of Defence
OrgID:      DMD-16
Address:    DINSA, HQ DCSA
Address:    H4, Copenacre
City:       Corsham
StateProv:  Wiltshire
PostalCode: SN13 9NR
Country:    GB

NetRange:   25.0.0.0 - 25.255.255.255
CIDR:       25.0.0.0/8
NetName:    RSRE-EXP
NetHandle:  NET-25-0-0-0-1
Parent:
NetType:    Direct Assignment
NameServer: NS1.CS.UCL.AC.UK
NameServer: RELAY.MOD.UK
Comment:
RegDate:    1985-01-28
Updated:    2005-09-06


# whois -h whois.ripe.net 25.0.0.0 | more
inetnum:        25.0.0.0 - 25.255.255.255
netname:        UK-MOD-19850128
descr:          UK Ministry of Defence
country:        GB
org:            ORG-DMoD1-RIPE
admin-c:        MOD123-RIPE
tech-c:         MOD123-RIPE
status:         ALLOCATED PA
mnt-by:         RIPE-NCC-HM-MNT


I tried emailing RIPE and ARIN. hostmasterripe.net
returned my  
message unread and I have no idea what other email adddress
to use,  
hostmasterarin.net talked at length about cleaning up the
legacy A  
space without actually addressing the issue. Good times.

Iljitsch van Beijnum wrote:
[..]
> Another interesting case:
> 
> 025/8   Jan 95   UK Ministry of Defense             
(Updated - Jan 06)
[..]
> I tried emailing RIPE and ARIN. hostmasterripe.net
returned my message
> unread and I have no idea what other email adddress to
use,
> hostmasterarin.net talked at length about cleaning
up the legacy A
> space without actually addressing the issue. Good
times.

Use ripe-dbmripe.net for all RIPE whois (DataBase Manager - dbm)
related issues.

Greets,
 Jeroen

Hi, team.

We checked with IANA, ARIN, and the US DoD regarding
7.0.0.0/8.  We  
were told that this netblock should not see the light of
day, though  
there is some debate about its allocation status.  We're
waiting for  
all of those parties to issue a consistent statement before
we make  
any changes.

Thanks,
Rob, for Team Cymru.
-- 
Rob Thomas
Team Cymru
http://www.cymru.com/
cmn_err(do_panic, "Out of coffee!");

Hi,

On Apr 14, 2007, at 12:47 PM, Rob Thomas wrote:
> We checked with IANA, ARIN, and the US DoD regarding
7.0.0.0/8.  We  
> were told that this netblock should not see the light
of day,

Right.  Packets sourced out of 7.0.0.0/8 should never be
seen on the  
Internet.

> though there is some debate about its allocation
status.

Not really.  The debate is about how that status should be
reflected  
in the IPv4 registry maintained by IANA. The ARIN data is,
as far as  
I am aware, accurate.

> We're waiting for all of those parties to issue a
consistent  
> statement before we make any changes.

When we tried to update the IANA registry to reflect what
was in the  
ARIN database, we were told not to.  We tried to explain the
 
registration information was already public via ARIN, but
were told  
not to update the IANA registry.  IANA and ARIN are working
out  
something to resolve this issue.

Rgds,
-drc