--- 1/draft-ietf-opsec-ip-security-04.txt 2010-12-16 17:14:37.000000000 +0100 +++ 2/draft-ietf-opsec-ip-security-05.txt 2010-12-16 17:14:37.000000000 +0100 @@ -1,20 +1,20 @@ Operational Security Capabilities F. Gont for IP Network Infrastructure UK CPNI -(opsec) October 21, 2010 +(opsec) December 16, 2010 Internet-Draft Intended status: Informational -Expires: April 24, 2011 +Expires: June 19, 2011 Security Assessment of the Internet Protocol version 4 - draft-ietf-opsec-ip-security-04.txt + draft-ietf-opsec-ip-security-05.txt Abstract This document contains a security assessment of the IETF specifications of the Internet Protocol version 4, and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). Status of this Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 24, 2011. + This Internet-Draft will expire on June 19, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -58,21 +58,21 @@ 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 3.3.2.1. Differentiated Services field . . . . . . . . . . 12 3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14 - 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 15 + 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16 3.5.1. Some Workarounds Implemented by the Industry . . . . . 16 3.5.2. Possible security improvements . . . . . . . . . . . . 17 3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17 3.5.2.2. Connectionless Transport Protocols . . . . . . . 18 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 21 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 22 3.8.1. Fingerprinting the operating system in use by the source host . . . . . . . . . . . . . . . . . . . . . 24 3.8.2. Fingerprinting the physical device from which the @@ -87,21 +87,21 @@ 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 28 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 28 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 29 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.13.1. General issues with IP options . . . . . . . . . . . . 31 3.13.1.1. Processing requirements . . . . . . . . . . . . . 31 3.13.1.2. Processing of the options by the upper layer protocol . . . . . . . . . . . . . . . . . . . . 32 3.13.1.3. General sanity checks on IP options . . . . . . . 32 - 3.13.2. Issues with specific options . . . . . . . . . . . . . 33 + 3.13.2. Issues with specific options . . . . . . . . . . . . . 34 3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 34 3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 34 3.13.2.3. Loose Source and Record Route (LSRR) (Type=131) . . . . . . . . . . . . . . . . . . . 34 3.13.2.4. Strict Source and Record Route (SSRR) (Type=137) . . . . . . . . . . . . . . . . . . . 37 3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 39 3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 40 3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 40 3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 43 @@ -146,28 +146,28 @@ 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62 4.3.5. Broadcast/Multicast addresses, and Connection-Oriented Protocols . . . . . . . . . . . . 62 4.3.6. Broadcast and network addresses . . . . . . . . . . . 62 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 67 - Appendix A. Advice and guidance to vendors . . . . . . . . . . . 76 - Appendix B. Changes from previous versions of the draft . . . . . 76 - B.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 - B.2. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 - B.3. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 - B.4. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 - B.5. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 - B.6. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 + Appendix A. Changes from previous versions of the draft . . . . . 75 + A.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 + A.2. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 + A.3. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 + A.4. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 + A.5. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76 + A.6. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76 + A.7. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 1. Preface 1.1. Introduction The TCP/IP protocols were conceived in an environment that was quite different from the hostile environment in which they currently operate. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that, to some @@ -222,29 +222,29 @@ between that which provides correct advisory, and that which provides misleading advisory based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, discusses the possible countermeasures, and analyzes their respective effectiveness. This document is the result of an assessment of the IETF - specifications of the Internet Protocol (IP), from a security point - of view. Possible threats were identified and, where possible, - countermeasures were proposed. Additionally, many implementation - flaws that have led to security vulnerabilities have been referenced - in the hope that future implementations will not incur the same - problems. Furthermore, this document does not limit itself to - performing a security assessment of the relevant IETF specifications, - but also provides an assessment of common implementation strategies - found in the real world. + specifications of the Internet Protocol version 4 (IPv4), from a + security point of view. Possible threats were identified and, where + possible, countermeasures were proposed. Additionally, many + implementation flaws that have led to security vulnerabilities have + been referenced in the hope that future implementations will not + incur the same problems. Furthermore, this document does not limit + itself to performing a security assessment of the relevant IETF + specifications, but also provides an assessment of common + implementation strategies found in the real world. This document does not aim to be the final word on the security of the Internet Protocol (IP). On the contrary, it aims to raise awareness about many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the Internet Protocol (IP), but also provides insights about the security aspects of the Internet Protocol that may be of help to the Internet operations community. @@ -328,21 +328,22 @@ a building block for other transport services (reliable data transport services, etc.). o It represents the minimum network service assumption, which enables IP to be run over virtually any network technology. 3. Internet Protocol Header Fields The IETF specifications of the Internet Protocol define the syntax of the protocol header, along with the semantics of each of its fields. - Figure 1 shows the format of an IP datagram. + Figure 1 shows the format of an IP datagram, as specified in + [RFC0791]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -569,20 +570,24 @@ ECN is an end-to-end transport protocol mechanism based on notifications by routers through which a packet flow passes. To allow this interaction to happen on the fast path of routers, the ECN field is located at a fixed location in the IP header. However, its use must be negotiated at the transport layer, and the accumulated congestion notifications must be communicated back to the sending node using transport protocol means. Thus, ECN support must be specified per transport protocol. + [RFC6040] specifies how the explicit congestion notification (ECN) + field of the IP header should be constructed on entry to and exit + from any IP-in-IP tunnel. + The security implications of ECN are discussed in detail in a number of Sections of RFC 3168. Of the possible threats discussed in the ECN specification, we believe that one that can be easily exploited is that of a host falsely indicating ECN-Capability. An attacker could set the ECT codepoint in the packets it sends, to signal the network that the endpoints of the transport protocol are ECN-capable. Consequently, when experiencing moderate congestion, routers using active queue management based on RED would mark the packets (with the CE codepoint) rather than discard them. In this @@ -728,20 +733,23 @@ services of IP is connection-oriented or connection-less. 3.5.2.1. Connection-Oriented Transport Protocols To avoid the security implications of the information leakage described above, a pseudo-random number generator (PRNG) could be used to set the IP Identification field on a {Source Address, Destination Address} basis (for each connection-oriented transport protocol). + [RFC4086] provides advice on the generation of pseudo-random + numbers. + [Klein2007] is a security advisory that describes a weakness in the pseudo random number generator (PRNG) in use for the generation of the IP Identification by a number of operating systems. While in theory a pseudo-random number generator could lead to scenarios in which a given Identification number is used more than once in the same time-span for datagrams that end up getting fragmented (with the corresponding potential reassembly problems), in practice this is unlikely to cause trouble. @@ -782,22 +790,26 @@ o Applications will be used in environments in which packet reordering is very unlikely (such as Local Area Networks), as the transport protocol itself does not provide data sequencing. o The data transfer rates will be low enough that flow control will be unnecessary. o Packet loss is can be tolerated and/or is unlikely. With these assumptions in mind, the Identification field could still - be set according to a pseudo-random number generator (PRNG). In the - event a given Identification number was reused while the first + be set according to a pseudo-random number generator (PRNG). + + [RFC4086] provides advice on the generation of pseudo-random + numbers. + + In the event a given Identification number was reused while the first instance of the same number is still on the network, the first IP datagram would be reassembled before the fragments of the second IP datagram get to their destination. In the event this was not the case, the reassembly of fragments would result in a corrupt datagram. While some existing work [Silbersack2005] assumes that this error would be caught by some upper-layer error detection code, the error detection code in question (such as UDP's checksum) might not be able to reliably detect data corruption arising from the replacement of a complete @@ -835,24 +847,24 @@ standardization) o Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment o Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments The DF bit is usually set to implement the Path-MTU Discovery (PMTUD) mechanism described in [RFC1191]. However, it can also be exploited by an attacker to evade Network Intrusion Detection Systems. An attacker could send a packet with the DF bit set to a system - monitored by a NIDS, and depending on the Path-MTU to the intended - recipient, the packet might be dropped by some intervening router - (because of being too big to be forwarded without fragmentation), - without the NIDS being aware of it. + monitored by a Network Intrusion Detection System (NIDS), and + depending on the Path-MTU to the intended recipient, the packet might + be dropped by some intervening router (because of being too big to be + forwarded without fragmentation), without the NIDS being aware of it. +---+ | H | +---+ Victim host | Router A | MTU=1500 | +---+ +---+ +---+ | R |-----| R |---------| R | +---+ +---+ +---+ @@ -866,21 +878,21 @@ _ ___/---\______ Attacker / \_/ \_ +---+ / Internet |---------| H | \_ __/ +---+ \__ __ ___/ <------ \___/ \__/ 17914-byte packet DF bit set Figure 5: NIDS evasion by means of the Internet Protocol DF bit - In Figure 3, an attacker sends a 17914-byte datagram meant to the + In Figure 3, an attacker sends a 17914-byte datagram meant for the victim host in the same figure. The attacker's packet probably contains an overlapping IP fragment or an overlapping TCP segment, aiming at "confusing" the NIDS, as described in [Ptacek1998]. The packet is screened by the NIDS sensor at the network perimeter, which probably reassembles IP fragments and TCP segments for the purpose of assessing the data transferred to and from the monitored systems. However, as the attacker's packet should transit a link with an MTU smaller than 17914 bytes (1500 bytes in this example), the router that encounters that this packet cannot be forwarded without fragmentation (Router B) discards the packet, and sends an ICMP @@ -1035,26 +1047,27 @@ o Improving the security of applications that make use of the Internet Protocol (IP). o Limiting spread of packets. 3.8.1. Fingerprinting the operating system in use by the source host Different operating systems use a different default TTL for the packets they send. Thus, asserting the TTL with which a packet was originally sent will help heuristics to reduce the number of possible - operating systems in use by the source host. - - However, these defaults may be configurable (system-wide or per - protocol) and managed systems may employ such opportunities for - operational purposes and to defeat the capability of fingerprinting - heuristics. + operating systems in use by the source host. It should be noted that + since most systems use only a handful of different default values, + the granularity of OS fingerprinting that this technique provides is + negligible. Additionally, these defaults may be configurable + (system-wide or per protocol), and managed systems may employ such + opportunities for operational purposes and to defeat the capability + of fingerprinting heuristics. 3.8.2. Fingerprinting the physical device from which the packets originate When several systems are behind a middle-box such as a NAT or a load balancer, the TTL may help to count the number of systems behind the middle-box. If each of the systems behind the middle-box uses a different default TTL value for the packets it sends, or each system is located at different distances in the network topology, an attacker could stimulate responses from the devices being @@ -1338,20 +1351,25 @@ modules, both in hosts and gateways (i.e., end-systems and intermediate-systems). This means that the general rules for assembling, parsing, and processing of IP options must be implemented. RFC 791 defines a set of options that "must be understood", but this set has been updated by RFC 1122 [RFC1122], RFC 1812 [RFC1812], and other documents. Section 3.13.2 of this document describes for each option type the current understanding of the implementation requirements. IP systems are required to ignore options they do not implement. + It should be noted that while a number of IP options have been + specified, they are generally only used for troubleshooting + purposes (except for the Router Alert option and the different + Security options). + There are two cases for the format of an option: o Case 1: A single byte of option-type. o Case 2: An option-type byte, an option-length byte, and the actual option-data bytes. In Case 2, the option-length byte counts the option-type byte and the option-length byte, as well as the actual option-data bytes. @@ -1694,21 +1713,21 @@ provide a system-wide toggle to enable support for this option for those scenarios in which this option is required. Such system-wide toggle should default to "off" (or "disable"). [OpenBSD1998] is a security advisory about an improper implementation of such a system-wide toggle in 4.4BSD kernels. In the event processing of the SSRR option were explicitly enabled, the same sanity checks described for the LSRR option in Section 3.13.2.3 should be performed on the SSRR option. Namely, - sanity checks shoudl be performed on the option length (SSRR.Length) + sanity checks should be performed on the option length (SSRR.Length) and the pointer field (SSRR.Pointer). If the packet passes the aforementioned sanity checks, the receiving system should determine whether the Destination Address of the packet corresponds to one of its IP addresses. If does not, it should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet drop). Contrary to the IP Loose Source and Record Route (LSRR) option, the SSRR option does not allow in the route other routers than @@ -1980,20 +1999,25 @@ reflect the packet drop). A packet that contains a Router Alert option with an option value corresponding to functionality supported by an active module in the router will not go through the router's fast-path but will be processed in the slow path of the router, handing it over for closer inspection to the modules that has registered the matching option value. Therefore, this option may impact the performance of the systems that handle the packet carrying it. + [I-D.ietf-intarea-router-alert-considerations] analyzes the + security implications of the Router Alert option, and identifies + controlled environments in which the Router Alert option can be + used safely. + As explained in RFC 2113 [RFC2113], hosts should ignore this option. 3.13.2.9. Probe MTU (Type=11) (obsolete) This option was defined in RFC 1063 [RFC1063], and originally provided a mechanism to discover the Path-MTU. This option is obsolete, and therefore any packet that is received containing this option should be dropped, and this event should be logged (e.g., a counter could be incremented to reflect the packet @@ -2514,22 +2538,22 @@ create some free space in the fragment buffer, on the premise that this will allow for new and legitimate fragments to be processed by the IP module, thus letting communication survive the overwhelming situation. On the other hand, the idea of flushing a somewhat large portion of the buffer is to avoid flushing always the same set of packets. 4.1.2.3. A more selective fragment buffer flushing strategy One of the difficulties in implementing countermeasures for the - fragmentation attacks described in throughout Section 4.1 is that it - is difficult to perform validation checks on the received fragments. + fragmentation attacks described throughout Section 4.1 is that it is + difficult to perform validation checks on the received fragments. For instance, the fragment on which validity checks could be performed, the first fragment, may be not the first fragment to arrive at the destination host. Fragments can not only arrive out of order because of packet reordering performed by the network, but also because the system (or systems) that fragmented the IP datagram may indeed transmit the fragments out of order. A notable example of this is the Linux TCP/IP stack, which transmits the fragments in reverse order. @@ -2835,29 +2859,26 @@ 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 - number of implementations discard packets that contain a "Class" E - address as the Source Address or Destination Address. - - However, there exists ongoing work to reclassify the former Class E - (240/4) address block as usable unicast address spaces [Fuller2008a] - [I-D.fuller-240space] [I-D.wilson-class-e]. Therefore, we recommend - implementations to accept addresses in the 240/4 block as valid - addresses for the Source Address and Destination Address. + 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 @@ -2989,23 +3011,24 @@ 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 Joel Jaeggli, Warren Kumari, Bruno - Rohee, and Andrew Yourtchenko for providing valuable comments on - earlier versions of this document. + The author would like to thank Jari Arkko, 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. @@ -3087,38 +3110,44 @@ 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", Available at: http://www.ouah.org/fragma.html , 2001. [Arkin2000] Arkin, "IP TTL Field Value with ICMP (Oops - Identifying Windows 2000 again and more)", http:// ofirarkin.files.wordpress.com/2008/11/ @@ -3232,27 +3261,20 @@ broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, Phile #0x0c of 0x10 http://www.phrack.org/ issues.html?issue=60&id=12&mode=txt, 2002. [FIPS1994] FIPS, "Standard Security Label for Information Transfer", Federal Information Processing Standards Publication. FIP PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ fips188.pdf, 1994. - [Fuller2008a] - Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The - Future Begins Now", Routing SIG Meeting, 25th APNIC Open - Policy Meeting, February 25 - 29 2008, Taipei, Taiwan http - ://www.apnic.net/meetings/25/program/routing/ - fuller-240-future.pdf, 2008. - [Fyodor2004] Fyodor, "Idle scanning and related IP ID games", http://www.insecure.org/nmap/idlescan.html, 2004. [GIAC2000] GIAC, "Egress Filtering v 0.2", http://www.sans.org/y2k/egress.htm, 2000. [Gont2006] Gont, F., "Advanced ICMP packet filtering", @@ -3261,41 +3283,35 @@ [Haddad2004] Haddad, I. and M. Zakrzewski, "Security Distribution for Linux Clusters", Linux Journal http://www.linuxjournal.com/article/6943, 2004. [Humble1998] Humble, "Nestea exploit", http://www.insecure.org/sploits/linux.PalmOS.nestea.html, 1998. - [I-D.fuller-240space] - Fuller, V., "Reclassifying 240/4 as usable unicast address - space", draft-fuller-240space-02 (work in progress), - March 2008. + [I-D.ietf-intarea-router-alert-considerations] + Faucheur, F., "IP Router Alert Considerations and Usage", + draft-ietf-intarea-router-alert-considerations-02 (work in + progress), October 2010. [I-D.ietf-tcpm-icmp-attacks] Gont, F., "ICMP attacks against TCP", draft-ietf-tcpm-icmp-attacks-12 (work in progress), March 2010. [I-D.templin-mtuassurance] Templin, F., "Requirements for IP-in-IP Tunnel MTU Assurance", draft-templin-mtuassurance-02 (work in progress), October 2006. - [I-D.wilson-class-e] - Wilson, P., Michaelson, G., and G. Huston, "Redesignation - of 240/4 from "Future Use" to "Private Use"", - draft-wilson-class-e-02 (work in progress), - September 2008. - [IANA2006a] Ether Types, "http://www.iana.org/assignments/ethernet-numbers". [IANA2006b] IP Parameters, "http://www.iana.org/assignments/ip-parameters". [IANA2006c] Protocol Numbers, @@ -3503,76 +3518,66 @@ [Zakrzewski2002] Zakrzewski, M. and I. Haddad, "Linux Distributed Security Module", http://www.linuxjournal.com/article/6215, 2002. [daemon91996] daemon9, route, and infinity, "IP-spoofing Demystified (Trust-Relationship Exploitation)", Phrack Magazine, Volume Seven, Issue Forty-Eight, File 14 of 18 http:// www.phrack.org/issues.html?issue=48&id=14&mode=txt, 1988. -Appendix A. Advice and guidance to vendors - - Vendors are urged to contact CPNI (vulteam@cpni.gsi.gov.uk) if they - think they may be affected by the issues described in this document. - As the lead coordination center for these issues, CPNI is well placed - to give advice and guidance as required. - - CPNI works extensively with government departments and agencies, - commercial organizations and the academic community to research - vulnerabilities and potential threats to IT systems especially where - they may have an impact on Critical National Infrastructure's (CNI). - - Other ways to contact CPNI, plus CPNI's PGP public key, are available - at http://www.cpni.gov.uk . - -Appendix B. Changes from previous versions of the draft +Appendix A. Changes from previous versions of the draft This whole appendix should be removed by the RFC Editor before publishing this document as an RFC. -B.1. Changes from draft-ietf-opsec-ip-security-03 +A.1. Changes from draft-ietf-opsec-ip-security-03 + + o Addresses IESG review comments by Jari Arkko, Stewart Bryant, + Adrian Farrel, Peter Saint-Andre, and Sean Turner. + +A.2. Changes from draft-ietf-opsec-ip-security-03 o Addresses feedback received off-list by Warren Kumari. -B.2. Changes from draft-ietf-opsec-ip-security-02 +A.3. Changes from draft-ietf-opsec-ip-security-02 o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -B.3. Changes from draft-ietf-opsec-ip-security-01 +A.4. Changes from draft-ietf-opsec-ip-security-01 o Addresses rest of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Addresses feedback submitted by Joel Jaeggli (off-list) o Addresses feedback submitted (off-list) by Bruno Rohee. o Miscellaneous edits (centers expressions, fills missing graphics with ASCII-art, etc.) -B.4. Changes from draft-ietf-opsec-ip-security-00 +A.5. Changes from draft-ietf-opsec-ip-security-00 o Addresses part of the feedback received from Andrew Yourtchenko (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) -B.5. Changes from draft-gont-opsec-ip-security-01 +A.6. Changes from draft-gont-opsec-ip-security-01 o Draft resubmitted as draft-ietf, as a result of wg consensus on adopting the document as an opsec wg item. -B.6. Changes from draft-gont-opsec-ip-security-00 +A.7. Changes from draft-gont-opsec-ip-security-00 o Fixed author's affiliation. o Added Figure 6. o Fixed a few typos. o (no technical changes) Author's Address