4.3. Addressing
4.3.1. Unreachable Addresses
It is important to understand that while there are some addresses
that are supposed to be unreachable from the public Internet (such as
the private IP addresses described in RFC 1918 [RFC1918], or the
"loopback" address), there are a number of tricks an attacker can
perform to reach those IP addresses that would otherwise be
unreachable (e.g., exploit the LSRR or SSRR IP options). Therefore,
when applicable, packet filtering should be performed at the private
network boundary to assure that those addresses will be unreachable.
Similarly, link-local unicast addresses [RFC3927] and multicast
addresses with limited scope (link- and site-local addresses) should
not be accessible from outside the proper network boundaries and not
be passed across these boundaries.
[RFC5735] provides a summary of special use IPv4 addresses.
4.3.2. Private Address Space
The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets:
o 10.0.0.0 - 10.255.255.255 (10/8 prefix)
o 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Use of these address blocks is described in RFC 1918 [RFC1918].
Where applicable, packet filtering should be performed at the
organizational perimeter to assure that these addresses are not
reachable from outside the private network where such addresses are
employed.
4.3.3. Former Class D Addresses (224/4 Address Block)
The former Class D addresses correspond to the 224/4 address block
and are used for Internet multicast. Therefore, if a packet is
received with a "Class D" address as the Source Address, it should be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop). Additionally, if an IP
packet with a multicast Destination Address is received for a
connection-oriented protocol (e.g., TCP), the packet should be
dropped (see Section 4.3.5), and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop).
4.3.4. Former Class E Addresses (240/4 Address Block)
The former Class E addresses correspond to the 240/4 address block,
and are currently reserved for experimental use. As a result, a most
routers discard packets that contain a "Class" E address as the
Source Address or Destination Address. If a packet is received with
a 240/4 address as the Source Address and/or the Destination Address,
the packet should be dropped and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop).
It should be noted that the broadcast address 255.255.255.255 still
must be treated as indicated in Section 4.3.7 of this document.
4.3.5. Broadcast/Multicast Addresses and Connection-Oriented Protocols
For connection-oriented protocols, such as TCP, shared state is
maintained between only two endpoints at a time. Therefore, if an IP
packet with a multicast (or broadcast) Destination Address is
received for a connection-oriented protocol (e.g., TCP), the packet
should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).
4.3.6. Broadcast and Network Addresses
Originally, the IETF specifications did not permit IP addresses to
have the value 0 or -1 (shorthand for all bits set to 1) for any of
the Host number, network number, or subnet number fields, except for
the cases indicated in Section 4.3.7. However, this changed
fundamentally with the deployment of Classless Inter-Domain Routing
(CIDR) [RFC4632], as with CIDR a system cannot know a priori what the
subnet mask is for a particular IP address.
Many systems now allow administrators to use the values 0 or -1 for
those fields. Despite that according to the original IETF
specifications these addresses are illegal, modern IP implementations
should consider these addresses to be valid.
4.3.7. Special Internet Addresses
RFC 1812 [RFC1812] discusses the use of some special Internet
addresses, which is of interest to perform some sanity checks on the
Source Address and Destination Address fields of an IP packet. It
uses the following notation for an IP address:
{ <Network-prefix>, <Host-number> }
where the length of the network prefix is generally implied by the
network mask assigned to the IP interface under consideration.
RFC 1122 [RFC1122] contained a similar discussion of special
Internet addresses, including some of the form { <Network-prefix>,
<Subnet-number>, <Host-number> }. However, as explained in
Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number
is clearly an extension of the network prefix and cannot be
distinguished from the remainder of the prefix.
{0, 0}
This address means "this host on this network". It is meant to be
used only during the initialization procedure, by which the host
learns its own IP address.
If a packet is received with 0.0.0.0 as the Source Address for any
purpose other than bootstrapping, the corresponding packet should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). If a packet is
received with 0.0.0.0 as the Destination Address, it should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).
{0, Host number}
This address means "the specified host, in this network". As in the
previous case, it is meant to be used only during the initialization
procedure by which the host learns its own IP address. If a packet
is received with such an address as the Source Address for any
purpose other than bootstrapping, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If a packet is received with such an
address as the Destination Address, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
{-1, -1}
This address is the local broadcast address. It should not be used
as a source IP address. If a packet is received with 255.255.255.255
as the Source Address, it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
Some systems, when receiving an ICMP echo request, for example,
will use the Destination Address in the ICMP echo request packet
as the Source Address of the response they send (in this case, an
ICMP echo reply). Thus, when such systems receive a request sent
to a broadcast address, the Source Address of the response will
contain a broadcast address. This should be considered a bug,
rather than a malicious use of the limited broadcast address.
{Network number, -1}
This is the directed broadcast to the specified network. As
recommended by RFC 2644 [RFC2644], routers should not forward
network-directed broadcasts. This avoids the corresponding network
from being utilized as, for example, a "smurf amplifier" [CERT1998a].
As noted in Section 4.3.6 of this document, many systems now allow
administrators to configure these addresses as unicast addresses for
network interfaces. In such scenarios, routers should forward these
addresses as if they were traditional unicast addresses.
In some scenarios, a host may have knowledge about a particular IP
address being a network-directed broadcast address, rather than a
unicast address (e.g., that IP address is configured on the local
system as a "broadcast address"). In such scenarios, if a system can
infer that the Source Address of a received packet is a network-
directed broadcast address, the packet should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
As noted in Section 4.3.6 of this document, with the deployment of
CIDR [RFC4632], it may be difficult for a system to infer whether a
particular IP address that does not belong to a directly attached
subnet is a broadcast address.
{127.0.0.0/8, any}
This is the internal host loopback address. Any packet that arrives
on any physical interface containing this address as the Source
Address, the Destination Address, or as part of a source route
(either LSRR or SSRR), should be dropped.
For example, packets with a Destination Address in the 127.0.0.0/8
address block that are received on an interface other than loopback
should be silently dropped. Packets received on any interface other
than loopback with a Source Address corresponding to the system
receiving the packet should also be dropped.
In all the above cases, when a packet is dropped, this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop).
5. Security Considerations
This document discusses the security implications of the Internet
Protocol (IP) and a number of implementation strategies that help to
mitigate a number of vulnerabilities found in the protocol during the
last 25 years or so.
6. Acknowledgements
The author wishes to thank Alfred Hoenes for providing very thorough
reviews of earlier versions of this document, thus leading to
numerous improvements.
The author would like to thank Jari Arkko, Ron Bonica, Stewart
Bryant, Adrian Farrel, Joel Jaeggli, Warren Kumari, Bruno Rohee, and
Andrew Yourtchenko for providing valuable comments on earlier
versions of this document.
This document was written by Fernando Gont on behalf of the UK CPNI
(United Kingdom's Centre for the Protection of National
Infrastructure), and is heavily based on the "Security Assessment of
the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.
The author would like to thank Randall Atkinson, John Day, Juan
Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka
Savola, and Christos Zoulas for providing valuable comments on
earlier versions of [CPNI2008], on which this document is based.
The author would like to thank Randall Atkinson and Roque Gagliano,
who generously answered a number of questions.
Finally, the author would like to thank UK CPNI (formerly NISCC) for
their continued support.
7. References
7.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC1038] St. Johns, M., "Draft revised IP security option",
RFC 1038, January 1988.
[RFC1063] Mogul, J., Kent, C., Partridge, C., and K. McCloghrie, "IP
MTU discovery options", RFC 1063, July 1988.
[RFC1108] Kent, S., "U.S", RFC 1108, November 1991.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393,
January 1993.
[RFC1770] Graff, C., "IPv4 Option for Sender Directed Multi-
Destination Delivery", RFC 1770, March 1995.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", BCP 34, RFC 2644, August 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[Paxson2001]
Paxson, V., Handley, M., and C. Kreibich, "Network
Intrusion Detection: Evasion, Traffic Normalization, and
End-to-End Protocol Semantics", USENIX Conference, 2001.
[Ptacek1998]
Ptacek, T. and T. Newsham, "Insertion, Evasion and Denial
of Service: Eluding Network Intrusion Detection", 1998,
<http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
[RFC0815] Clark, D., "IP datagram reassembly algorithms", RFC 815,
July 1982.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, July 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
[RFC5559] Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", RFC 5559, June 2009.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)",
RFC 5570, July 2009.
[RFC5670] Eardley, P., "Metering and Marking Behaviour of PCN-
Nodes", RFC 5670, November 2009.
[RFC5696] Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
RFC 5696, November 2009.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
