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

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/