Reserved IP Address Space Reminder

Published: 2012-05-16. Last Updated: 2012-05-17 02:58:11 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

As we are running out of IPv4 address space, many networks, instead of embracing IPv6, stretch existing IPv4 space via multiple levels of NAT. NAT then uses "reserved" IP address space. However, there are more address ranges reserved then listed in RFC1918, and not all of them should be used in internal networks. Here is a (probably incomplete) list of address ranges that are reserved, and which once are usable inside your network behind a NAT gateway.

List of Reserved IPv4 Address ranges
Address Range RFC Suitable for Internal Network
0.0.0.0/8 RFC1122 no ("any" address)
10.0.0.0/8 RFC1918 yes
100.64.0.0/10 RFC6598 yes (with caution: If you are a "carrier")
127.0.0.0/8 RFC1122 no (localhost)
169.254.0.0/16 RFC3927 yes (with caution: zero configuration)
172.16.0.0/12 RFC1918 yes
192.0.0.0/24 RFC5736 no (not used now, may be used later)
192.0.2.0/24 RFC5737 yes (with caution: for use in examples)
192.88.99.0/24 RFC3068 no (6-to-4 anycast)
192.168.0.0/16 RFC1918 yes
198.18.0.0/15 RFC2544 yes (with caution: for use in benchmark tests)
198.51.100.0/24 RFC5737 yes (with caution: test-net used in examples)
203.0.113.0/24 RFC5737 yes (with caution: test-net used in examples)
224.0.0.0/4 RFC3171 no (Multicast)
240.0.0.0/4 RFC1700 no (or "unwise"? reserved for future use)

Most interesting in this context is RFC6598 (100.64.0.0/10), which was recently assigned to provide ISPs with a range for NAT that is not going to conflict with their customers NAT networks. It has been a more and more common problem that NAT'ed networks once connected with each other via for example a VPN tunnel, have conflicting assignments.

Which networks did I forget? I will update the table for a couple days as comments come in.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: nat rfc1918
8 comment(s)
New Version of Google Chrome released (19.0.1084.46)
Microsoft released an update for its Enhanced Mitigation Experience Tool (EMET) http://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx

Got Packets? Odd duplicate DNS replies from 10.x IP Addresses

Published: 2012-05-16. Last Updated: 2012-05-16 11:48:23 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

This is a clarification to Dan's diary from yesterday. We are interested to hear, if anybody else is seeing DNS replies from RFC1918 non-routable IP addresses, in particular from 10.0.0.0/8. So far, we only have one report, and we are trying to figure out if this is something wide spread, or something unique to this user.

This reader first noticed the problem when the firewall reported more dropped packets from 10.x addresses. Two example queries that caused the problem are A queries for 25280.ftp.download.akadns.net and adfarm.mplx.akadns.net. The reader receives two responses: One "normal" response from the IP address the query was sent to, and a second response from the 10.x address. As a result, the problem would go unnoticed even if the 10.x response is dropped. Both responses provide the same answer, so this may not be an attack, but more of a misconfiguration.

As a side note, initially the DNS protocol specifically allowed for replies to arrive from an IP address different then the one the query was sent to:

"Some name servers send their responses from different addresses than the one used to receive the query. That is, a resolver cannot rely that a response will come from the same address which it sent the corresponding query to. This name server bug is typically encountered in UNIX systems." (RFC1035)

However, later in RFC2181, this requirement was removed:

"Most, if not all, DNS clients, expect the address from which a reply is received to be the same address as that to which the query  eliciting the reply was sent.  This is true for servers acting as clients for the purposes of recursive query resolution, as well as simple resolver clients.  The address, along with the identifier (ID) in the reply is used for disambiguating replies, and filtering  spurious responses.  This may, or may not, have been intended when the DNS was designed, but is now a fact of life." (RFC2181)

But we are NOT looking for responses that are coming from the wrong source, but duplicate responses. Once from the correct and once from the incorrect address.

Here an example "stray" packet submitted by the reader (slightly modified for privacy reasons and to better fit the screen)

 

Internet Protocol Version 4, Src: 10.17.x.y, Dst: ---removed---
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 
    Total Length: 84
    Identification: 0x2a7e (10878)
    Flags: 0x00
    Fragment offset: 0
    Time to live: 59
    Protocol: UDP (17)
    Header checksum: correct
User Datagram Protocol, Src Port: domain (53), Dst Port: antidotemgrsvr (2247)

Domain Name System (response)
    Transaction ID: 0xb326
    Flags: 0x8400 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer not authenticated
        .... .... ...0 .... = Non-authenticated data: Unacceptable
        .... .... .... 0000 = Reply code: No error (0)

    Questions: 1
    Answer RRs: 1
    Authority RRs: 0
    Additional RRs: 0

    Queries

        ads.adsonar.akadns.net: type A, class IN
            Name: ads.adsonar.akadns.net
            Type: A (Host address)
            Class: IN (0x0001)

    Answers

        ads.adsonar.akadns.net: type A, class IN, addr 207.200.74.25
            Name: ads.adsonar.akadns.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 5 minutes
            Data length: 4
            Addr: 207.200.74.25 (207.200.74.25)

 

 

http://www.faqs.org/rfcs/rfc1035.html
http://www.faqs.org/rfcs/rfc2181.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: dns rfc1035 rfc2181
1 comment(s)
ISC StormCast for Wednesday, May 16th 2012 http://isc.sans.edu/podcastdetail.html?id=2536

Comments


Diary Archives