tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6274

 
 
 

Security Assessment of the Internet Protocol Version 4

Part 5 of 5, p. 61 to 75
Prev RFC Part

 


prevText      Top      Up      ToC       Page 61 
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)

Top      Up      ToC       Page 62 
   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).

Top      Up      ToC       Page 63 
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).

Top      Up      ToC       Page 64 
   {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-

Top      Up      ToC       Page 65 
   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.

Top      Up      ToC       Page 66 
   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.

Top      Up      ToC       Page 67 
   [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.

Top      Up      ToC       Page 68 
   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
              Pignataro, "The Generalized TTL Security Mechanism
              (GTSM)", RFC 5082, October 2007.

   [RFC5350]  Manner, J. and A. McDonald, "IANA Considerations for the
              IPv4 and IPv6 Router Alert Options", RFC 5350,
              September 2008.

   [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
              BCP 153, RFC 5735, January 2010.

   [RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
              Notification", RFC 6040, November 2010.

7.2.  Informative References

   [Anderson2001]
              Anderson, J., "An Analysis of Fragmentation Attacks",
              2001, <http://www.ouah.org/fragma.html>.

   [Arkin2000]
              Arkin, "IP TTL Field Value with ICMP (Oops - Identifying
              Windows 2000 again and more)", 2000,
              <http://ofirarkin.files.wordpress.com/2008/11/
              ofirarkin2000-06.pdf>.

   [Barisani2006]
              Barisani, A., "FTester - Firewall and IDS testing tool",
              2001, <http://dev.inversepath.com/trac/ftester>.

   [Bellovin1989]
              Bellovin, S., "Security Problems in the TCP/IP Protocol
              Suite", Computer Communication Review Vol. 19, No. 2, pp.
              32-48, 1989.

   [Bellovin2002]
              Bellovin, S., "A Technique for Counting NATted Hosts",
              IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.

   [Bendi1998]
              Bendi, "Bonk exploit", 1998,
              <http://www.insecure.org/sploits/
              95.NT.fragmentation.bonk.html>.

Top      Up      ToC       Page 69 
   [Biondi2007]
              Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
              CanSecWest 2007 Security Conference, 2007,
              <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.

   [CERT1996a]
              CERT, "CERT Advisory CA-1996-01: UDP Port Denial-of-
              Service Attack", 1996,
              <http://www.cert.org/advisories/CA-1996-01.html>.

   [CERT1996b]
              CERT, "CERT Advisory CA-1996-21: TCP SYN Flooding and IP
              Spoofing Attacks", 1996,
              <http://www.cert.org/advisories/CA-1996-21.html>.

   [CERT1996c]
              CERT, "CERT Advisory CA-1996-26: Denial-of-Service Attack
              via ping", 1996,
              <http://www.cert.org/advisories/CA-1996-26.html>.

   [CERT1997] CERT, "CERT Advisory CA-1997-28: IP Denial-of-Service
              Attacks", 1997,
              <http://www.cert.org/advisories/CA-1997-28.html>.

   [CERT1998a]
              CERT, "CERT Advisory CA-1998-01: Smurf IP Denial-of-
              Service Attacks", 1998,
              <http://www.cert.org/advisories/CA-1998-01.html>.

   [CERT1998b]
              CERT, "CERT Advisory CA-1998-13: Vulnerability in Certain
              TCP/IP Implementations", 1998,
              <http://www.cert.org/advisories/CA-1998-13.html>.

   [CERT1999] CERT, "CERT Advisory CA-1999-17: Denial-of-Service Tools",
              1999, <http://www.cert.org/advisories/CA-1999-17.html>.

   [CERT2003] CERT, "CERT Advisory CA-2003-15: Cisco IOS Interface
              Blocked by IPv4 Packet", 2003,
              <http://www.cert.org/advisories/CA-2003-15.html>.

   [CIPSO1992]
              CIPSO, "COMMERCIAL IP SECURITY OPTION (CIPSO 2.2)", Work
              in Progress, 1992.

Top      Up      ToC       Page 70 
   [CIPSOWG1994]
              CIPSOWG, "Commercial Internet Protocol Security Option
              (CIPSO) Working Group", 1994, <http://www.ietf.org/
              proceedings/94jul/charters/cipso-charter.html>.

   [CPNI2008] Gont, F., "Security Assessment of the Internet Protocol",
              2008, <http://www.cpni.gov.uk/Docs/InternetProtocol.pdf>.

   [Cerf1974] Cerf, V. and R. Kahn, "A Protocol for Packet Network
              Intercommunication", IEEE Transactions on
              Communications Vol. 22, No. 5, May 1974, pp. 637-648,
              1974.

   [Cisco2003]
              Cisco, "Cisco Security Advisory: Cisco IOS Interface
              Blocked by IPv4 packet", 2003, <http://www.cisco.com/en/
              US/products/
              products_security_advisory09186a00801a34c2.shtml>.

   [Cisco2008]
              Cisco, "Cisco IOS Security Configuration Guide, Release
              12.2", 2003, <http://www.cisco.com/en/US/docs/ios/12_2/
              security/configuration/guide/scfipso.html>.

   [Clark1988]
              Clark, D., "The Design Philosophy of the DARPA Internet
              Protocols", Computer Communication Review Vol. 18, No. 4,
              1988.

   [Ed3f2002] Ed3f, "Firewall spotting and networks analysis with a
              broken CRC", Phrack Magazine, Volume 0x0b, Issue
              0x3c, Phile #0x0c of 0x10, 2002, <http://www.phrack.org/
              issues.html?issue=60&id=12&mode=txt>.

   [FIPS1994] FIPS, "Standard Security Label for Information Transfer",
              Federal Information Processing Standards Publication. FIP
              PUBS 188, 1994, <http://csrc.nist.gov/publications/fips/
              fips188/fips188.pdf>.

   [Fyodor2004]
              Fyodor, "Idle scanning and related IP ID games", 2004,
              <http://www.insecure.org/nmap/idlescan.html>.

   [GIAC2000] GIAC, "Egress Filtering v 0.2", 2000,
              <http://www.sans.org/y2k/egress.htm>.

   [Gont2006] Gont, F., "Advanced ICMP packet filtering", 2006,
              <http://www.gont.com.ar/papers/icmp-filtering.html>.

Top      Up      ToC       Page 71 
   [Haddad2004]
              Haddad, I. and M. Zakrzewski, "Security Distribution for
              Linux Clusters", Linux Journal, 2004,
              <http://www.linuxjournal.com/article/6943>.

   [Humble1998]
              Humble, "Nestea exploit", 1998,
              <http://www.insecure.org/sploits/
              linux.PalmOS.nestea.html>.

   [IANA_ET]  IANA, "Ether Types",
              <http://www.iana.org/assignments/ethernet-numbers>.

   [IANA_IP_PARAM]
              IANA, "IP Parameters",
              <http://www.iana.org/assignments/ip-parameters>.

   [IANA_PROT_NUM]
              IANA, "Protocol Numbers",
              <http://www.iana.org/assignments/protocol-numbers>.

   [IRIX2008] IRIX, "IRIX 6.5 trusted_networking(7) manual page", 2008,
              <http://techpubs.sgi.com/library/tpl/cgi-bin/
              getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/
              cat7/trusted_networking.z>.

   [Jones2002]
              Jones, R., "A Method Of Selecting Values For the
              Parameters Controlling IP Fragment Reassembly", 2002,
              <ftp://ftp.cup.hp.com/dist/networking/briefs/
              ip_reass_tuning.txt>.

   [Kenney1996]
              Kenney, M., "The Ping of Death Page", 1996,
              <http://www.insecure.org/sploits/ping-o-death.html>.

   [Kent1987] Kent, C. and J. Mogul, "Fragmentation considered harmful",
              Proc. SIGCOMM '87 Vol. 17, No. 5, October 1987, 1987.

   [Klein2007]
              Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
              Predictable IP ID Vulnerability", 2007,
              <http://www.trusteer.com/files/
              OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP
              _ID_Vulnerability.pdf>.

Top      Up      ToC       Page 72 
   [Kohno2005]
              Kohno, T., Broido, A., and kc. Claffy, "Remote Physical
              Device Fingerprinting", IEEE Transactions on Dependable
              and Secure Computing Vol. 2, No. 2, 2005.

   [LBNL2006] LBNL/NRG, "arpwatch tool", 2006, <http://ee.lbl.gov/>.

   [Linux]    Linux Kernel Organization, "The Linux Kernel Archives",
              <http://www.kernel.org>.

   [Microsoft1999]
              Microsoft, "Microsoft Security Program: Microsoft Security
              Bulletin (MS99-038). Patch Available for "Spoofed Route
              Pointer" Vulnerability", 1999, <http://www.microsoft.com/
              technet/security/bulletin/ms99-038.mspx>.

   [NISCC2004]
              NISCC, "NISCC Vulnerability Advisory 236929: Vulnerability
              Issues in TCP", 2004, <http://www.cpni.gov.uk>.

   [NISCC2005]
              NISCC, "NISCC Vulnerability Advisory 532967/NISCC/ICMP:
              Vulnerability Issues in ICMP packets with TCP payloads",
              2005, <http://www.gont.com.ar/advisories/index.html>.

   [NISCC2006]
              NISCC, "NISCC Technical Note 01/2006: Egress and Ingress
              Filtering", 2006, <http://www.cpni.gov.uk>.

   [Northcutt2000]
              Northcut, S. and Novak, "Network Intrusion Detection - An
              Analyst's Handbook", Second Edition New Riders Publishing,
              2000.

   [Novak2005]
              Novak, "Target-Based Fragmentation Reassembly", 2005,
              <http://www.snort.org/assets/165/target_based_frag.pdf>.

   [OpenBSD-PF]
              Sanfilippo, S., "PF: Scrub (Packet Normalization)", 2010,
              <ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf>.

   [OpenBSD1998]
              OpenBSD, "OpenBSD Security Advisory: IP Source Routing
              Problem", 1998,
              <http://www.openbsd.org/advisories/sourceroute.txt>.

Top      Up      ToC       Page 73 
   [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.

Top      Up      ToC       Page 74 
   [ROUTER-ALERT]
              Le Faucheur, F., Ed., "IP Router Alert Considerations and
              Usage", Work in Progress, June 2011.

   [SELinux2009]
              NSA, "Security-Enhanced Linux",
              <http://www.nsa.gov/research/selinux/>.

   [Sanfilippo1998a]
              Sanfilippo, S., "about the ip header id", Post to Bugtraq
              mailing-list, Mon Dec 14 1998,
              <http://www.kyuzz.org/antirez/papers/ipid.html>.

   [Sanfilippo1998b]
              Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
              1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.

   [Sanfilippo1999]
              Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
              list, 1999,
              <http://www.kyuzz.org/antirez/papers/moreipid.html>.

   [Shankar2003]
              Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS
              Evasion Without Altering Traffic", 2003,
              <http://www.icir.org/vern/papers/activemap-oak03.pdf>.

   [Shannon2001]
              Shannon, C., Moore, D., and K. Claffy, "Characteristics of
              Fragmented IP Traffic on Internet Links", 2001.

   [Silbersack2005]
              Silbersack, M., "Improving TCP/IP security through
              randomization without sacrificing interoperability",
              EuroBSDCon 2005 Conference, 2005,
              <http://www.silby.com/eurobsdcon05/eurobsdcon_slides.pdf>.

   [Snort]    Sourcefire, Inc., "Snort", <http://www.snort.org>.

   [Solaris2007]
              Oracle, "ORACLE SOLARIS WITH TRUSTED EXTENSIONS", 2007, <h
              ttp://www.oracle.com/us/products/servers-storage/solaris/
              solaris-trusted-ext-ds-075583.pdf>.

   [Song1999] Song, D., "Frag router tool",
              <http://www.monkey.org/~dugsong/fragroute/>.

Top      Up      ToC       Page 75 
   [SpooferProject]
              MIT ANA, "Spoofer Project", 2010,
              <http://spoofer.csail.mit.edu/index.php>.

   [US-CERT2001]
              US-CERT, "US-CERT Vulnerability Note VU#446689: Check
              Point FireWall-1 allows fragmented packets through
              firewall if Fast Mode is enabled", 2001,
              <http://www.kb.cert.org/vuls/id/446689>.

   [US-CERT2002]
              US-CERT, "US-CERT Vulnerability Note VU#310387: Cisco IOS
              discloses fragments of previous packets when Express
              Forwarding is enabled", 2002.

   [Watson2004]
              Watson, P., "Slipping in the Window: TCP Reset Attacks",
              CanSecWest Conference, 2004.

   [Zakrzewski2002]
              Zakrzewski, M. and I. Haddad, "Linux Distributed Security
              Module", 2002, <http://www.linuxjournal.com/article/6215>.

   [daemon91996]
              daemon9, route, and infinity, "IP-spoofing Demystified
              (Trust-Relationship Exploitation)", Phrack Magazine,
              Volume Seven, Issue Forty-Eight, File 14 of 18, 1988, <htt
              p://www.phrack.org/issues.html?issue=48&id=14&mode=txt>.

Author's Address

   Fernando Gont
   UK Centre for the Protection of National Infrastructure

   EMail: fernando@gont.com.ar
   URI:   http://www.cpni.gov.uk