RFC 6274
Security Assessment of the Internet Protocol Version 4
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.
[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>.
[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.
[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>.
[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>.
[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>.
[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.
[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/>.
[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