draft-ietf-opsec-ip-security-01.txt   draft-ietf-opsec-ip-security-02.txt 
Operational Security Capabilities F. Gont Operational Security Capabilities F. Gont
for IP Network Infrastructure UK CPNI for IP Network Infrastructure UK CPNI
(opsec) August 20, 2009 (opsec) February 20, 2010
Internet-Draft Internet-Draft
Intended status: Informational Intended status: Informational
Expires: February 21, 2010 Expires: August 24, 2010
Security Assessment of the Internet Protocol version 4 Security Assessment of the Internet Protocol version 4
draft-ietf-opsec-ip-security-01.txt draft-ietf-opsec-ip-security-02.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 Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 42
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 21, 2010. This Internet-Draft will expire on August 24, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document contains a security assessment of the IETF described in the BSD License.
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).
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7
1.3. Organization of this document . . . . . . . . . . . . . . 6 1.3. Organization of this document . . . . . . . . . . . . . . 7
2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 3. Internet Protocol header fields . . . . . . . . . . . . . . . 8
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 9
3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Differentiated Services field . . . . . . . . . . . . . . 10
3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Explicit Congestion Notification (ECN) . . . . . . . . . . 11
3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11 3.5. Total Length . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.1. Some workarounds implemented by the industry . . . . . 12 3.6. Identification (ID) . . . . . . . . . . . . . . . . . . . 13
3.5.2. Possible security improvements . . . . . . . . . . . . 12 3.6.1. Some workarounds implemented by the industry . . . . . 14
3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6.2. Possible security improvements . . . . . . . . . . . . 14
3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 16 3.7. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 17 3.8. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 18
3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 19
3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 22 3.9.1. Fingerprinting the operating system in use by the
3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 22 source host . . . . . . . . . . . . . . . . . . . . . 20
3.12. Destination Address . . . . . . . . . . . . . . . . . . . 23 3.9.2. Fingerprinting the physical device from which the
3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 23 packets originate . . . . . . . . . . . . . . . . . . 20
3.13.1. General issues with IP options . . . . . . . . . . . . 24 3.9.3. Locating the source host in the network topology . . . 20
3.13.1.1. Processing requirements . . . . . . . . . . . . . 24 3.9.4. Evading Network Intrusion Detection Systems . . . . . 22
3.13.1.2. Processing of the options by the upper layer 3.9.5. Improving the security of applications that make
protocol . . . . . . . . . . . . . . . . . . . . 25 use of the Internet Protocol (IP) . . . . . . . . . . 22
3.13.1.3. General sanity checks on IP options . . . . . . . 25 3.10. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.13.2. Issues with specific options . . . . . . . . . . . . . 27 3.11. Header Checksum . . . . . . . . . . . . . . . . . . . . . 24
3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 27 3.12. Source Address . . . . . . . . . . . . . . . . . . . . . . 24
3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27 3.13. Destination Address . . . . . . . . . . . . . . . . . . . 25
3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27 3.14. Options . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.13.2.4. Strict Source and Record Route (SSRR) (Type = 3.14.1. General issues with IP options . . . . . . . . . . . . 26
137) . . . . . . . . . . . . . . . . . . . . . . 30 3.14.1.1. Processing requirements . . . . . . . . . . . . . 26
3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34 3.14.1.2. Processing of the options by the upper layer
3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 35 protocol . . . . . . . . . . . . . . . . . . . . 27
3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36 3.14.1.3. General sanity checks on IP options . . . . . . . 27
3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39 3.14.2. Issues with specific options . . . . . . . . . . . . . 29
3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40 3.14.2.1. End of Option List (Type = 0) . . . . . . . . . . 29
3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40 3.14.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 29
3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40 3.14.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 29
3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 40 3.14.2.4. Strict Source and Record Route (SSRR) (Type =
3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 41 137) . . . . . . . . . . . . . . . . . . . . . . 32
3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 3.14.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34
3.14.2.6. Stream Identifier (Type = 136) . . . . . . . . . 36
3.14.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36
3.14.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39
3.14.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40
3.14.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40
3.14.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40
3.14.2.12. DoD Basic Security Option (Type = 130) . . . . . 41
3.14.2.13. DoD Extended Security Option (Type = 133) . . . . 42
3.14.2.14. Commercial IP Security Option (CIPSO) (Type =
134) . . . . . . . . . . . . . . . . . . . . . . 42 134) . . . . . . . . . . . . . . . . . . . . . . 42
3.13.2.15. Sender Directed Multi-Destination Delivery 3.14.2.15. Sender Directed Multi-Destination Delivery
(Type = 149) . . . . . . . . . . . . . . . . . . 43 (Type = 149) . . . . . . . . . . . . . . . . . . 43
3.14. Differentiated Services field . . . . . . . . . . . . . . 43 3.15. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.15. Explicit Congestion Notification (ECN) . . . . . . . . . . 44
4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45
4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45
4.1.1. Problems related with memory allocation . . . . . . . 46 4.1.1. Security Implications of Fragment Reassembly . . . . . 46
4.1.2. Problems that arise from the length of the IP 4.1.1.1. Problems related with memory allocation . . . . . 46
Identification field . . . . . . . . . . . . . . . . . 48 4.1.1.2. Problems that arise from the length of the IP
4.1.3. Problems that arise from the complexity of the Identification field . . . . . . . . . . . . . . 48
reassembly algorithm . . . . . . . . . . . . . . . . . 49 4.1.1.3. Problems that arise from the complexity of
4.1.4. Problems that arise from the ambiguity of the the reassembly algorithm . . . . . . . . . . . . 48
reassembly process . . . . . . . . . . . . . . . . . . 49 4.1.1.4. Problems that arise from the ambiguity of the
4.1.5. Problems that arise from the size of the IP reassembly process . . . . . . . . . . . . . . . 49
fragments . . . . . . . . . . . . . . . . . . . . . . 50 4.1.1.5. Problems that arise from the size of the IP
4.1.6. Possible security improvements . . . . . . . . . . . . 50 fragments . . . . . . . . . . . . . . . . . . . . 50
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 56 4.1.2. Possible security improvements . . . . . . . . . . . . 50
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 56 4.1.2.1. Memory allocation for fragment reassembly . . . . 50
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 57 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 51
4.1.2.3. A more selective fragment buffer flushing
strategy . . . . . . . . . . . . . . . . . . . . 52
4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 54
4.1.2.5. Counter-measure for some IDS evasion
techniques . . . . . . . . . . . . . . . . . . . 55
4.1.2.6. Counter-measure for firewall-rules bypassing . . 55
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 55
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 56
4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58
4.3.2. Private address space . . . . . . . . . . . . . . . . 59 4.3.2. Private address space . . . . . . . . . . . . . . . . 58
4.3.3. Class D addresses (224/4 address block) . . . . . . . 59 4.3.3. Class D addresses (224/4 address block) . . . . . . . 59
4.3.4. Class E addresses (240/4 address block) . . . . . . . 59 4.3.4. Class E addresses (240/4 address block) . . . . . . . 59
4.3.5. Broadcast and multicast addresses, and 4.3.5. Broadcast and multicast addresses, and
connection-oriented protocols . . . . . . . . . . . . 60 connection-oriented protocols . . . . . . . . . . . . 59
4.3.6. Broadcast and network addresses . . . . . . . . . . . 60 4.3.6. Broadcast and network addresses . . . . . . . . . . . 60
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60
5. Security Considerations . . . . . . . . . . . . . . . . . . . 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 62
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Normative References . . . . . . . . . . . . . . . . . . . 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 63
7.2. Informative References . . . . . . . . . . . . . . . . . . 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Advice and guidance to vendors . . . . . . . . . . . 72 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 72
Appendix B. Changes from previous versions of the draft (to Appendix B. Changes from previous versions of the draft (to
be removed by the RFC Editor before publishing be removed by the RFC Editor before publishing
this document as an RFC) . . . . . . . . . . . . . . 73 this document as an RFC) . . . . . . . . . . . . . . 73
B.1. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73 B.1. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 73
B.2. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73 B.2. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73
B.3. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73 B.3. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73
B.4. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 73
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 they currently operate in. different from the hostile environment they currently operate in.
However, the effectiveness of the protocols led to their early However, the effectiveness of the protocols led to their early
adoption in production environments, to the point that, to some adoption in production environments, to the point that, to some
skipping to change at page 7, line 24 skipping to change at page 8, line 24
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding | | Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Internet Protocol header format Figure 1: Internet Protocol header format
Even when the minimum IP header size is 20 bytes, an IP module might Even when the minimum IP header size is 20 bytes, an IP module might
be handed an (illegitimate) "datagram" of less than 20 bytes. be handed an (illegitimate) "datagram" of less than 20 bytes.
Therefore, before doing any processing of the IP header fields, the Therefore, before doing any processing of the IP header fields, the
following check should be performed by the IP module on the packets following check should be performed by the IP module on the packets
handed by the link layer: handed by the link layer:
LinkLayer.PayloadSize >= 20 LinkLayer.PayloadSize >= 20
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
The following subsections contain further sanity checks that should The following subsections contain further sanity checks that should
be performed on IP packets. be performed on IP packets.
3.1. Version 3.1. Version
skipping to change at page 8, line 45 skipping to change at page 9, line 47
silently dropped, and this event should be logged (e.g., a counter silently dropped, and this event should be logged (e.g., a counter
could be incremented reflecting the packet drop). could be incremented reflecting the packet drop).
3.2. IHL (Internet Header Length) 3.2. IHL (Internet Header Length)
The IHL (Internet Header Length) indicates the length of the internet The IHL (Internet Header Length) indicates the length of the internet
header in 32-bit words (4 bytes). As the minimum datagram size is 20 header in 32-bit words (4 bytes). As the minimum datagram size is 20
bytes, the minimum legal value for this field is 5. Therefore, the bytes, the minimum legal value for this field is 5. Therefore, the
following check should be enforced: following check should be enforced:
IHL >= 5 IHL >= 5
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
For obvious reasons, the Internet header cannot be larger than the For obvious reasons, the Internet header cannot be larger than the
whole Internet datagram it is part of. Therefore, the following whole Internet datagram it is part of. Therefore, the following
check should be enforced: check should be enforced:
IHL * 4 <= Total Length IHL * 4 <= Total Length
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
The above check allows for Internet datagrams with no data bytes in The above check allows for Internet datagrams with no data bytes in
the payload that, while nonsensical for virtually every protocol that the payload that, while nonsensical for virtually every protocol that
runs over IP, it is still legal. runs over IP, it is still legal.
3.3. TOS 3.3. Differentiated Services field
Figure 2 shows the syntax of the Type of Service field, defined by The Differentiated Services Architecture is intended to enable
RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. scalable service discrimination in the Internet without the need for
per-flow state and signaling at every hop [RFC2475]. RFC 2474
[RFC2474] defines a Differentiated Services Field (DS Field), which
is intended to supersede the original Type of Service field. Figure
5 shows the format of the field.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
Figure 2: Structure of the DS Field
The DSCP ("Differentiated Services CodePoint").is used to select the
treatment the packet is to receive within the Differentiated Services
Domain. The CU ("Currently Unused") field was, at the time the
specification was issued, reserved for future use. The DSCP field is
used to select a PHB, by matching against the entire 6-bit field.
Considering that the DSCP field determines how a packet is treated
within a DS domain, an attacker send packets with a forged DSCP field
to perform a theft of service or even a Denial of Service attack. In
particular, an attacker could forge packets with a codepoint of the
type '11x000' which, according to Section 4.2.2.2 of RFC 2474
[RFC2474], would give the packets preferential forwarding treatment
when compared with the PHB selected by the codepoint '000000'. If
strict priority queuing were utilized, a continuous stream of such
pockets could perform a Denial of Service to other flows which have a
DSCP of lower relative order.
As the DS field is incompatible with the original Type of Service
field, both DS domains and networks using the original Type of
Service field should protect themselves by remarking the
corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be taken so that packets
received with an unrecognized DSCP do not cause the handling system
to malfunction.
3.4. Explicit Congestion Notification (ECN)
RFC 3168 [RFC3168] specifies a mechanism for routers to signal
congestion to hosts sending IP packets, by marking the offending
packets, rather than discarding them. RFC 3168 defines the ECN
field, which utilizes the CU unused field of the DSCP field described
in Section 3.14 of this document. Figure 6 shows the syntax of the
ECN field, together with the DSCP field used for Differentiated
Services.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | C | 0 | | DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 2: Type of Service field Figure 3: The Differentiated Services and ECN fields in IP
+----------+----------------------------------------------+ As such, the ECN field defines four codepoints:
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+
Table 1: TOS bits +-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
+-----+-----------------+ Table 1: ECN codepoints
| 111 | Network Control |
+-----+-----------------+
| 110 | Internetwork |
+-----+-----------------+
| 101 | CRITIC/ECP |
+-----+-----------------+
| 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+
Table 2: Precedence field 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 host falsely indicating ECN-Capability.
The Type of Service field can be used to affect the way in which the An attacker could set the ECT codepoint in the packets it sends, to
packet is treated by the systems of a network that process it. signal the network that the endpoints of the transport protocol are
Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 ECN-capable. Consequently, when experiencing moderate congestion,
("Weak TOS") of this document describe the security implications of routers using active queue management based on RED would mark the
the Type of Service field in the forwarding of packets. packets (with the CE codepoint) rather than discard them. In the
same scenario, packets of competing flows that do not have the ECT
codepoint set would be dropped. Therefore, an attacker would get
better network service than the competing flows.
3.4. Total Length However, if this moderate congestion turned into heavy congestion,
routers should switch to drop packets, regardless of whether the
packets have the ECT codepoint set or not.
A number of other threats could arise if an attacker was a man in the
middle (i.e., was in the middle of the path the packets travel to get
to the destination host). For a detailed discussion of those cases,
we urge the reader to consult Section 16 of RFC 3168.
3.5. Total Length
The Total Length field is the length of the datagram, measured in The Total Length field is the length of the datagram, measured in
bytes, including both the IP header and the IP payload. Being a 16- bytes, including both the IP header and the IP payload. Being a 16-
bit field, it allows for datagrams of up to 65535 bytes. RFC 791 bit field, it allows for datagrams of up to 65535 bytes. RFC 791
[RFC0791] states that all hosts should be prepared to receive [RFC0791] states that all hosts should be prepared to receive
datagrams of up to 576 bytes (whether they arrive as a whole, or in datagrams of up to 576 bytes (whether they arrive as a whole, or in
fragments). However, most modern implementations can reassemble fragments). However, most modern implementations can reassemble
datagrams of at least 9 Kbytes. datagrams of at least 9 Kbytes.
Usually, a host will not send to a remote peer an IP datagram larger Usually, a host will not send to a remote peer an IP datagram larger
than 576 bytes, unless it is explicitly signaled that the remote peer than 576 bytes, unless it is explicitly signaled that the remote peer
is able to receive such "large" datagrams (for example, by means of is able to receive such "large" datagrams (for example, by means of
TCP's MSS option). However, systems should assume that they may be TCP's MSS option). However, systems should assume that they may be
sent datagrams larger than 576 bytes, regardless of whether they sent datagrams larger than 576 bytes, regardless of whether they
signal their remote peers to do so or not. In fact, it is common for signal their remote peers to do so or not. In fact, it is common for
NFS [RFC3530]implementations to send datagrams larger than 576 bytes, NFS [RFC3530]implementations to send datagrams larger than 576 bytes,
even without explicit signaling that the destination system can even without explicit signaling that the destination system can
receive such "large" datagram. receive such "large" datagram.
Additionally, see the discussion in Section 4.1 "Fragment reassembly" o Additionally, see the discussion in Section 4.1 "Fragment
regarding the possible packet sizes resulting from fragment reassembly" regarding the possible packet sizes resulting from
reassembly. fragment reassembly.
Implementations should be aware that the IP module could be handed a Implementations should be aware that the IP module could be handed a
packet larger than the value actually contained in the Total Length packet larger than the value actually contained in the Total Length
field. Such a difference usually has to do with legitimate padding field. Such a difference usually has to do with legitimate padding
bytes at the link-layer protocol, but it could also be the result of bytes at the link-layer protocol, but it could also be the result of
malicious activity by an attacker. Furthermore, even when the malicious activity by an attacker. Furthermore, even when the
maximum length of an IP datagram is 65535 bytes, if the link-layer maximum length of an IP datagram is 65535 bytes, if the link-layer
technology in use allows for payloads larger than 65535 bytes, an technology in use allows for payloads larger than 65535 bytes, an
attacker could forge such a large link-layer packet, meaning it for attacker could forge such a large link-layer packet, meaning it for
the IP module. If the IP module of the receiving system were not the IP module. If the IP module of the receiving system were not
skipping to change at page 11, line 26 skipping to change at page 13, line 17
unexpected failure might occur. Therefore, the memory buffer used by unexpected failure might occur. Therefore, the memory buffer used by
the IP module to store the link-layer payload should be allocated the IP module to store the link-layer payload should be allocated
according to the payload size reported by the link-layer, rather than according to the payload size reported by the link-layer, rather than
according to the Total Length field of the IP packet it contains. according to the Total Length field of the IP packet it contains.
The IP module could also be handled a packet that is smaller than the The IP module could also be handled a packet that is smaller than the
actual IP packet size claimed by the Total Length field. This could actual IP packet size claimed by the Total Length field. This could
be used, for example, to produce an information leakage. Therefore, be used, for example, to produce an information leakage. Therefore,
the following check should be performed: the following check should be performed:
LinkLayer.PayloadSize >= Total Length LinkLayer.PayloadSize >= Total Length
If this check fails, the IP packet should be dropped, and this event If this check fails, the IP packet should be dropped, and this event
should be logged (e.g., a counter could be incremented reflecting the should be logged (e.g., a counter could be incremented reflecting the
packet drop). As the previous expression implies, the number of packet drop). As the previous expression implies, the number of
bytes passed by the link-layer to the IP module should contain at bytes passed by the link-layer to the IP module should contain at
least as many bytes as claimed by the Total Length field of the IP least as many bytes as claimed by the Total Length field of the IP
header. header.
[US-CERT2002] is an example of the exploitation of a forged IP Total o [US-CERT2002] is an example of the exploitation of a forged IP
Length field to produce an information leakage attack. Total Length field to produce an information leakage attack.
3.5. Identification (ID) 3.6. Identification (ID)
The Identification field is set by the sending host to aid in the The Identification field is set by the sending host to aid in the
reassembly of fragmented datagrams. At any time, it needs to be reassembly of fragmented datagrams. At any time, it needs to be
unique for each set of {Source Address, Destination Address, unique for each set of {Source Address, Destination Address,
Protocol}. Protocol}.
In many systems, the value used for this field is determined at the In many systems, the value used for this field is determined at the
IP layer, on a protocol-independent basis. Many of those systems IP layer, on a protocol-independent basis. Many of those systems
also simply increment the IP Identification field for each packet also simply increment the IP Identification field for each packet
they send. they send.
skipping to change at page 12, line 22 skipping to change at page 14, line 14
transmitting information. Later, [Sanfilippo1998b] described how a transmitting information. Later, [Sanfilippo1998b] described how a
system with such an implementation can be used to perform a stealth system with such an implementation can be used to perform a stealth
port scan to a third (victim) host. [Sanfilippo1999] explained how port scan to a third (victim) host. [Sanfilippo1999] explained how
to exploit this implementation strategy to uncover the rules of a to exploit this implementation strategy to uncover the rules of a
number of firewalls. [Bellovin2002] explains how the IP number of firewalls. [Bellovin2002] explains how the IP
Identification field can be exploited to count the number of systems Identification field can be exploited to count the number of systems
behind a NAT. [Fyodor2004] is an entire paper on most (if not all) behind a NAT. [Fyodor2004] is an entire paper on most (if not all)
the ways to exploit the information provided by the Identification the ways to exploit the information provided by the Identification
field of the IP header. field of the IP header.
3.5.1. Some workarounds implemented by the industry 3.6.1. Some workarounds implemented by the industry
As the IP Identification field is only used for the reassembly of As the IP Identification field is only used for the reassembly of
datagrams, some operating systems (such as Linux) decided to set this datagrams, some operating systems (such as Linux) decided to set this
field to 0 in all packets that have the DF bit set. This would, in field to 0 in all packets that have the DF bit set. This would, in
principle, avoid any type of information leakage. However, it was principle, avoid any type of information leakage. However, it was
detected that some non-RFC-compliant middle-boxes fragmented packets detected that some non-RFC-compliant middle-boxes fragmented packets
even if they had the DF bit set. In such a scenario, all datagrams even if they had the DF bit set. In such a scenario, all datagrams
originally sent with the DF bit set would all result in fragments originally sent with the DF bit set would all result in fragments
that would have an Identification field of 0, which would lead to that would have an Identification field of 0, which would lead to
problems ("collision" of the Identification number) in the reassembly problems ("collision" of the Identification number) in the reassembly
process. process.
Linux (and Solaris) later set the IP Identification field on a per- Linux (and Solaris) later set the IP Identification field on a per-
IP-address basis. This avoids some of the security implications of IP-address basis. This avoids some of the security implications of
the IP Identification field, but not all. For example, systems the IP Identification field, but not all. For example, systems
behind a load balancer can still be counted. behind a load balancer can still be counted.
3.5.2. Possible security improvements 3.6.2. Possible security improvements
Contrary to common wisdom, the IP Identification field does not need Contrary to common wisdom, the IP Identification field does not need
to be system-wide unique for each packet, but has to be unique for to be system-wide unique for each packet, but has to be unique for
each {Source Address, Destination Address, Protocol} tuple. each {Source Address, Destination Address, Protocol} tuple.
For instance, the TCP specification defines a generic send() function o For instance, the TCP specification defines a generic send()
which takes the IP ID as one of its arguments. function which takes the IP ID as one of its arguments.
We provide an analysis of the possible security improvements that We provide an analysis of the possible security improvements that
could be implemented, based on whether the protocol using the could be implemented, based on whether the protocol using the
services of IP is connection-oriented or connection-less. services of IP is connection-oriented or connection-less.
Connection-oriented protocols Connection-oriented 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).
[Klein2007] is a security advisory that describes a weakness in the o [Klein2007] is a security advisory that describes a weakness in
pseudo random number generator (PRNG) in use for the generation of the pseudo random number generator (PRNG) in use for the
the IP Identification by a number of operating systems. generation of the IP Identification by a number of operating
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.
By default, most implementations of connection-oriented protocols, By default, most implementations of connection-oriented protocols,
such as TCP, implement some mechanism for avoiding fragmentation such as TCP, implement some mechanism for avoiding fragmentation
(such as the Path-MTU Discovery mechanism described in [RFC1191]). (such as the Path-MTU Discovery mechanism described in [RFC1191]).
skipping to change at page 14, line 30 skipping to change at page 16, line 23
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 be intended to detect single question (such as UDP's checksum) might be intended to detect single
bit errors, rather than data corruption arising from the replacement bit errors, rather than data corruption arising from the replacement
of a complete data block (as is the case in corruption arising from of a complete data block (as is the case in corruption arising from
collision of IP Identification numbers). collision of IP Identification numbers).
In the case of UDP, unfortunately some systems have been known to not o In the case of UDP, unfortunately some systems have been known to
enable the UDP checksum by default. For most applications, packets not enable the UDP checksum by default. For most applications,
containing errors should be dropped. Probably the only application packets containing errors should be dropped. Probably the only
that may benefit from disabling the checksum is streaming media, to application that may benefit from disabling the checksum is
avoid dropping a complete sample for a single-bit error. streaming media, to avoid dropping a complete sample for a single-
bit error.
In general, if IP Identification number collisions become an issue In general, if IP Identification number collisions become an issue
for the application using the connection-less protocol, then use of a for the application using the connection-less protocol, then use of a
different transport protocol (which hopefully avoids fragmentation) different transport protocol (which hopefully avoids fragmentation)
should be considered. should be considered.
It must be noted that an attacker could intentionally exploit It must be noted that an attacker could intentionally exploit
collisions of IP Identification numbers to perform a Denial of collisions of IP Identification numbers to perform a Denial of
Service attack, by sending forged fragments that would cause the Service attack, by sending forged fragments that would cause the
reassembly process to result in a corrupt datagram that would either reassembly process to result in a corrupt datagram that would either
be dropped by the transport protocol, or would incorrectly be handed be dropped by the transport protocol, or would incorrectly be handed
to the corresponding application. This issue is discussed in detail to the corresponding application. This issue is discussed in detail
in section 4.1 ("Fragment Reassembly"). in section 4.1 ("Fragment Reassembly").
3.6. Flags 3.7. Flags
The IP header contains 3 control bits, two of which are currently The IP header contains 3 control bits, two of which are currently
used for the fragmentation and reassembly function. used for the fragmentation and reassembly function.
As described by RFC 791, their meaning is: As described by RFC 791, their meaning is:
Bit 0: reserved, must be zero Bit 0: reserved, must be zero
Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment
Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments 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 NIDS, and depending on the Path-MTU to the intended
recipient, the packet might be dropped by some intervening router recipient, the packet might be dropped by some intervening router
(because of being too big to be forwarded without fragmentation), (because of being too big to be forwarded without fragmentation),
without the NIDS being aware of it. without the NIDS being aware of it.
skipping to change at page 15, line 25 skipping to change at page 17, line 18
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 NIDS, and depending on the Path-MTU to the intended
recipient, the packet might be dropped by some intervening router recipient, the packet might be dropped by some intervening router
(because of being too big to be forwarded without fragmentation), (because of being too big to be forwarded without fragmentation),
without the NIDS being aware of it. without the NIDS being aware of it.
(still to be added) (still to be added)
(See Figure 3 in Page 13 of the CPNI document) (See Figure 3 in Page 13 of the CPNI document)
Figure 3: NIDS evasion by means of the Internet Protocol DF bit Figure 4: 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 to 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
"fragmentation needed and DF bit set" error message to the source "fragmentation needed and DF bit set" error message to the source
host. In this scenario, the NIDS may remain unaware that the host. In this scenario, the NIDS may remain unaware that the
screened packet never reached the intended destination, and thus get screened packet never reached the intended destination, and thus get
an incorrect picture of the data being transferred to the monitored an incorrect picture of the data being transferred to the monitored
systems. systems.
[Shankar2003] introduces a technique named "Active Mapping" that o [Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at the network being monitored, to assess which packets will arrive
the intended recipient, and how they will be interpreted by it. at the intended recipient, and how they will be interpreted by it.
Some firewalls are known to drop packets that have both the MF (More Some firewalls are known to drop packets that have both the MF (More
Fragments) and the DF (Don't fragment) bits set. While in principle Fragments) and the DF (Don't fragment) bits set. While in principle
such a packet might seem nonsensical, there are a number of reasons such a packet might seem nonsensical, there are a number of reasons
for which non-malicious packets with these two bits set can be found for which non-malicious packets with these two bits set can be found
in a network. First, they may exist as the result of some middle-box in a network. First, they may exist as the result of some middle-box
processing a packet that was too large to be forwarded without processing a packet that was too large to be forwarded without
fragmentation. Instead of simply dropping the corresponding packet fragmentation. Instead of simply dropping the corresponding packet
and sending an ICMP error message to the source host, some middle- and sending an ICMP error message to the source host, some middle-
boxes fragment the packet (copying the DF bit to each fragment), and boxes fragment the packet (copying the DF bit to each fragment), and
also send an ICMP error message to the originating system. Second, also send an ICMP error message to the originating system. Second,
some systems (notably Linux) set both the MF and the DF bits to some systems (notably Linux) set both the MF and the DF bits to
implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should implement Path-MTU Discovery (PMTUD) for UDP. These scenarios should
be taken into account when configuring firewalls and/or tuning be taken into account when configuring firewalls and/or tuning
Network Intrusion Detection Systems (NIDS). Network Intrusion Detection Systems (NIDS).
3.7. Fragment Offset 3.8. Fragment Offset
The Fragment Offset is used for the fragmentation and reassembly of The Fragment Offset is used for the fragmentation and reassembly of
IP datagrams. It indicates where in the original datagram the IP datagrams. It indicates where in the original datagram the
fragment belongs, and is measured in units of eight bytes. As a fragment belongs, and is measured in units of eight bytes. As a
consequence, all fragments (except the last one), have to be aligned consequence, all fragments (except the last one), have to be aligned
on an 8-byte boundary. Therefore, if a packet has the MF flag set, on an 8-byte boundary. Therefore, if a packet has the MF flag set,
the following check should be enforced: the following check should be enforced:
(Total Length - IHL * 4) % 8 == 0 (Total Length - IHL * 4) % 8 == 0
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
Given that Fragment Offset is a 13-bit field, it can hold a value of Given that Fragment Offset is a 13-bit field, it can hold a value of
up to 8191, which would correspond to an offset 65528 bytes within up to 8191, which would correspond to an offset 65528 bytes within
the original (non-fragmented) datagram. As such, it is possible for the original (non-fragmented) datagram. As such, it is possible for
a fragment to implicitly claim to belong to a datagram larger than a fragment to implicitly claim to belong to a datagram larger than
65535 bytes (the maximum size for a legitimate IP datagram). Even 65535 bytes (the maximum size for a legitimate IP datagram). Even
when the fragmentation mechanism would seem to allow fragments that when the fragmentation mechanism would seem to allow fragments that
could reassemble into such large datagrams, the intent of the could reassemble into such large datagrams, the intent of the
specification is to allow for the transmission of datagrams of up to specification is to allow for the transmission of datagrams of up to
65535 bytes. Therefore, if a given fragment would reassemble into a 65535 bytes. Therefore, if a given fragment would reassemble into a
datagram of more than 65535 bytes, the resulting datagram should be datagram of more than 65535 bytes, the resulting datagram 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 reflecting the packet drop). To detect such a case, the incremented reflecting the packet drop). To detect such a case, the
following check should be enforced on all packets for which the following check should be enforced on all packets for which the
Fragment Offset contains a non-zero value: Fragment Offset contains a non-zero value:
Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535 Fragment Offset * 8 + (Total Length - IHL * 4) <= 65535
In the worst-case scenario, the reassembled datagram could have a In the worst-case scenario, the reassembled datagram could have a
size of up to 131043 bytes. size of up to 131043 bytes.
Such a datagram would result when the first fragment has a Fragment o Such a datagram would result when the first fragment has a
Offset of 0 and a Total Length of 65532, and the second (and last) Fragment Offset of 0 and a Total Length of 65532, and the second
fragment has a Fragment Offset of 8189 (65512 bytes), and a Total (and last) fragment has a Fragment Offset of 8189 (65512 bytes),
Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 and a Total Length of 65535. Assuming an IHL of 5 (i.e., a header
bytes), the reassembled datagram would be 65532 + (65535 - 20) = length of 20 bytes), the reassembled datagram would be 65532 +
131047 bytes. (65535 - 20) = 131047 bytes.
Additionally, the IP module should implement all the necessary Additionally, the IP module should implement all the necessary
measures to be able to handle such illegitimate reassembled measures to be able to handle such illegitimate reassembled
datagrams, so as to avoid them from overflowing the buffer(s) used datagrams, so as to avoid them from overflowing the buffer(s) used
for the reassembly function. for the reassembly function.
[CERT1996c] and [Kenney1996] describe the exploitation of this issue o [CERT1996c] and [Kenney1996] describe the exploitation of this
to perform a Denial of Service (DoS) attack. issue to perform a Denial of Service (DoS) attack.
3.8. Time to Live (TTL) 3.9. Time to Live (TTL)
The Time to Live (TTL) field has two functions: to bind the lifetime The Time to Live (TTL) field has two functions: to bind the lifetime
of the upper-layer packets (e.g., TCP segments) and to prevent of the upper-layer packets (e.g., TCP segments) and to prevent
packets from looping indefinitely in the network. packets from looping indefinitely in the network.
Originally, this field was meant to indicate maximum time a datagram Originally, this field was meant to indicate maximum time a datagram
was allowed to remain in the internet system, in units of seconds. was allowed to remain in the internet system, in units of seconds.
As every internet module that processes a datagram must decrement the As every internet module that processes a datagram must decrement the
TTL by at least one, the original definition of the TTL field became TTL by at least one, the original definition of the TTL field became
obsolete, and it must now be interpreted as a hop count. obsolete, and it must now be interpreted as a hop count.
skipping to change at page 17, line 45 skipping to change at page 19, line 41
The TTL field has a number of properties that are interesting from a The TTL field has a number of properties that are interesting from a
security point of view. Given that the default value used for the security point of view. Given that the default value used for the
TTL is usually a power of eight, chances are that, unless the TTL is usually a power of eight, chances are that, unless the
originating system has been explicitly tuned to use a non-default originating system has been explicitly tuned to use a non-default
value, if a packet arrives with a TTL of 60, the packet was value, if a packet arrives with a TTL of 60, the packet was
originally sent with a TTL of 64. In the same way, if a packet is originally sent with a TTL of 64. In the same way, if a packet is
received with a TTL of 120, chances are that the original packet had received with a TTL of 120, chances are that the original packet had
a TTL of 128. a TTL of 128.
This discussion assumes there was no protocol scrubber, transparent o This discussion assumes there was no protocol scrubber,
proxy, or some other middle-box that overwrites the TTL field in a transparent proxy, or some other middle-box that overwrites the
non-standard way, between the originating system and the point of the TTL field in a non-standard way, between the originating system
network in which the packet was received. and the point of the network in which the packet was received.
Asserting the TTL with which a packet was originally sent by the Asserting the TTL with which a packet was originally sent by the
source system can help to obtain valuable information. Among other source system can help to obtain valuable information. Among other
things, it may help in: things, it may help in:
o Fingerprinting the operating system being used by the source host. o Fingerprinting the operating system being used by the source host.
o Fingerprinting the physical device from which the packets o Fingerprinting the physical device from which the packets
originate. originate.
o Locating the source host in the network topology. o Locating the source host in the network topology.
Additionally, it can be used to perform functions such as: Additionally, it can be used to perform functions such as:
o Evading Network Intrusion Detection Systems. o Evading Network Intrusion Detection Systems.
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).
Fingerprinting the operating system in use by the source host 3.9.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 to reduce the number of possible operating originally sent will help to reduce the number of possible operating
systems in use by the source host. systems in use by the source host.
Fingerprinting the physical device from which the packets originate 3.9.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 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 use a middle-box. If each of the systems behind the middle-box use a
different default TTL for the packets they send, or they are located different default TTL for the packets they send, or they are located
in a different place of the network topology, an attacker could in a different place of the network topology, an attacker could
stimulate responses from the devices being fingerprinted, and each stimulate responses from the devices being fingerprinted, and each
response that arrives with a different TTL could be assumed to come response that arrives with a different TTL could be assumed to come
from a different device. from a different device.
Of course, there are many other and much more precise techniques to o Of course, there are many other and much more precise techniques
fingerprint physical devices. Among drawbacks of this method, while to fingerprint physical devices. Among drawbacks of this method,
many systems differ in the default TTL they use for the packets they while many systems differ in the default TTL they use for the
send, there are also many implementations which use the same default packets they send, there are also many implementations which use
TTL. Additionally, packets sent by a given device may take different the same default TTL. Additionally, packets sent by a given
routes (e.g., due to load sharing or route changes), and thus a given device may take different routes (e.g., due to load sharing or
packet may incorrectly be presumed to come from a different device, route changes), and thus a given packet may incorrectly be
when in fact it just traveled a different route. presumed to come from a different device, when in fact it just
traveled a different route.
Locating the source host in the network topology 3.9.3. Locating the source host in the network topology
The TTL field may also be used to locate the source system in the The TTL field may also be used to locate the source system in the
network topology [Northcutt2000]. network topology [Northcutt2000].
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| A |-----| R |------| R |----| R |-----| R | | A |-----| R |------| R |----| R |-----| R |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
/ | / \ / | / \
/ | / \ / | / \
/ | / +---+ / | / +---+
skipping to change at page 19, line 27 skipping to change at page 21, line 27
+---+ +---+ +---+ \ +---| +---+ +---+ +---+ \ +---|
| R |----------| R |-- \ | R |----------| R |-- \
+---+ +---+ \ \ +---+ +---+ \ \
| \ / \ +---+| +---+ | \ / \ +---+| +---+
| \ / ----| R |------| R | | \ / ----| R |------| R |
| \ / +---+ +---+ | \ / +---+ +---+
+---+ \ +---+ +---+ +---+ \ +---+ +---+
| B | \| R |----| C | | B | \| R |----| C |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 4: Tracking a host by means of the TTL field Figure 5: Tracking a host by means of the TTL field
Consider network topology of Figure 4. Assuming that an attacker Consider network topology of Figure 5. Assuming that an attacker
("F" in the figure) is performing some type of attack that requires ("F" in the figure) is performing some type of attack that requires
forging the Source Address (such as a TCP-based DoS reflection forging the Source Address (such as a TCP-based DoS reflection
attack), and some of the involved hosts are willing to cooperate to attack), and some of the involved hosts are willing to cooperate to
locate the attacking system. locate the attacking system.
Assuming that: Assuming that:
o All the packets A gets have a TTL of 61. o All the packets A gets have a TTL of 61.
o All the packets B gets have a TTL of 61. o All the packets B gets have a TTL of 61.
skipping to change at page 20, line 33 skipping to change at page 22, line 33
large for the information to be useful. large for the information to be useful.
o The attacker may be using a non-default TTL value, or, what is o The attacker may be using a non-default TTL value, or, what is
worse, using a pseudo-random value for the TTL of the packets it worse, using a pseudo-random value for the TTL of the packets it
sends. sends.
o The packets sent by the attacker may take different routes, as a o The packets sent by the attacker may take different routes, as a
result of a change in network topology, load sharing, etc., and result of a change in network topology, load sharing, etc., and
thus may lead to an incorrect analysis. thus may lead to an incorrect analysis.
Evading Network Intrusion Detection Systems 3.9.4. Evading Network Intrusion Detection Systems
The TTL field can be used to evade Network Intrusion Detection The TTL field can be used to evade Network Intrusion Detection
Systems. Depending on the position of a sensor relative to the Systems. Depending on the position of a sensor relative to the
destination host of the examined packet, the NIDS may get a different destination host of the examined packet, the NIDS may get a different
picture from that got by the intended destination system. As an picture from that of the intended destination system. As an example,
example, a sensor may process a packet that will expire before a sensor may process a packet that will expire before getting to the
getting to the destination host. A general counter-measure for this destination host. A general counter-measure for this type of attack
type of attack is to normalize the traffic that gets to an is to normalize the traffic that gets to an organizational network.
organizational network. Examples of such traffic normalization can Examples of such traffic normalization can be found in [Paxson2001].
be found in [Paxson2001].
Improving the security of applications that make use of the Internet 3.9.5. Improving the security of applications that make use of the
Protocol (IP) Internet Protocol (IP)
In some scenarios, the TTL field can be also used to improve the In some scenarios, the TTL field can be also used to improve the
security of an application, by restricting the hosts that can security of an application, by restricting the hosts that can
communicate with the given application. For example, there are communicate with the given application . For example, there are
applications for which the communicating systems are typically in the applications for which the communicating systems are typically in the
same network segment (i.e., there are no intervening routers). Such same network segment (i.e., there are no intervening routers). Such
an application is the BGP (Border Gateway Protocol) between utilized an application is the BGP (Border Gateway Protocol) between utilized
by two peer routers. by two peer routers.
If both systems use a TTL of 255 for all the packets they send to If both systems use a TTL of 255 for all the packets they send to
each other, then a check could be enforced to require all packets each other, then a check could be enforced to require all packets
meant for the application in question to have a TTL of 255. meant for the application in question to have a TTL of 255.
As all packets sent by systems that are not in the same network As all packets sent by systems that are not in the same network
segment will have a TTL smaller than 255, those packets will not pass segment will have a TTL smaller than 255, those packets will not pass
the check enforced by these two cooperating peers. This check the check enforced by these two cooperating peers. This check
reduces the set of systems that may perform attacks against the reduces the set of systems that may perform attacks against the
protected application (BGP in this case), thus mitigating the attack protected application (BGP in this case), thus mitigating the attack
vectors described in [NISCC2004] and [Watson2004]. vectors described in [NISCC2004] and [Watson2004].
This same check is enforced for related ICMP error messages, with the o This same check is enforced for related ICMP error messages, with
intent of mitigating the attack vectors described in [NISCC2005] and the intent of mitigating the attack vectors described in
[I-D.ietf-tcpm-icmp-attacks]. [NISCC2005] and [I-D.ietf-tcpm-icmp-attacks].
The TTL field can be used in a similar way in scenarios in which the The TTL field can be used in a similar way in scenarios in which the
cooperating systems either do not use a default TTL of 255, or are cooperating systems either do not use a default TTL of 255, or are
not in the same network segment (i.e., multi-hop peering). In that not in the same network segment (i.e., multi-hop peering). In that
case, the following check could be enforced: case, the following check could be enforced:
TTL >= 255 - DeltaHops TTL >= 255 - DeltaHops
This means that the set of hosts from which packets will be accepted This means that the set of hosts from which packets will be accepted
for the protected application will be reduced to those that are no for the protected application will be reduced to those that are no
more than DeltaHops away. While for obvious reasons the level of more than DeltaHops away. While for obvious reasons the level of
protection will be smaller than in the case of directly-connected protection will be smaller than in the case of directly-connected
peers, the use of the TTL field for protecting multi-hop peering peers, the use of the TTL field for protecting multi-hop peering
still reduces the set of hosts that could potentially perform a still reduces the set of hosts that could potentially perform a
number of attacks against the protected application. number of attacks against the protected application.
This use of the TTL field has been officially documented by the IETF This use of the TTL field has been officially documented by the IETF
under the name "Generalized TTL Security Mechanism" (GTSM) in under the name "Generalized TTL Security Mechanism" (GTSM) in
[RFC5082]. [RFC5082].
Some protocol scrubbers enforce a minimum value for the TTL field of Some protocol scrubbers enforce a minimum value for the TTL field of
the packets they forward. It must be understood that depending on the packets they forward. It must be understood that depending on
the minimum TTL being enforced, and depending on the particular the minimum TTL being enforced, and depending on the particular
network setup, the protocol scrubber may actually help attackers to network setup, the protocol scrubber may actually help attackers to
fool the GTSM, by "raising" the TTL of the attacking packets. fool the GTSM, by "raising" the TTL of the attacking packets.
3.9. Protocol 3.10. Protocol
The Protocol field indicates the protocol encapsulated in the The Protocol field indicates the protocol encapsulated in the
internet datagram. The Protocol field may not only contain a value internet datagram. The Protocol field may not only contain a value
corresponding to an implemented protocol within the system, but also corresponding to an implemented protocol within the system, but also
a value corresponding to a protocol not implemented, or even a value a value corresponding to a protocol not implemented, or even a value
not yet assigned by the IANA [IANA2006c]. not yet assigned by the IANA [IANA2006c].
While in theory there should not be security implications from the While in theory there should not be security implications from the
use of any value in the protocol field, there have been security use of any value in the protocol field, there have been security
issues in the past with systems that had problems when handling issues in the past with systems that had problems when handling
packets with some specific protocol numbers [Cisco2003] [CERT2003]. packets with some specific protocol numbers [Cisco2003] [CERT2003].
3.10. Header Checksum 3.11. Header Checksum
The Header Checksum field is an error detection mechanism meant to The Header Checksum field is an error detection mechanism meant to
detect errors in the IP header. While in principle there should not detect errors in the IP header. While in principle there should not
be security implications arising from this field, it should be noted be security implications arising from this field, it should be noted
that due to non-RFC-compliant implementations, the Header Checksum that due to non-RFC-compliant implementations, the Header Checksum
might be exploited to detect firewalls and/or evade network intrusion might be exploited to detect firewalls and/or evade network intrusion
detection systems (NIDS). detection systems (NIDS).
[Ed3f2002] describes the exploitation of the TCP checksum for [Ed3f2002] describes the exploitation of the TCP checksum for
performing such actions. As there are internet routers known to not performing such actions. As there are internet routers known to not
check the IP Header Checksum, and there might also be middle-boxes check the IP Header Checksum, and there might also be middle-boxes
(NATs, firewalls, etc.) not checking the IP checksum allegedly due to (NATs, firewalls, etc.) not checking the IP checksum allegedly due to
performance reasons, similar malicious activity to the one described performance reasons, similar malicious activity to the one described
in [Ed3f2002] might be performed with the IP checksum. in [Ed3f2002] might be performed with the IP checksum.
3.11. Source Address 3.12. Source Address
The Source Address of an IP datagram identifies the node from which The Source Address of an IP datagram identifies the node from which
the packet originated. the packet originated.
Strictly speaking, the Source Address of an IP datagram identifies o Strictly speaking, the Source Address of an IP datagram identifies
the interface of the sending system from which the packet was sent, the interface of the sending system from which the packet was
(rather than the originating "system"), as in the Internet sent, (rather than the originating "system"), as in the Internet
Architecture there's no concept of "node". Architecture there's no concept of "node".
Unfortunately, it is trivial to forge the Source Address of an Unfortunately, it is trivial to forge the Source Address of an
Internet datagram. This has been exploited in the past for Internet datagram. This has been exploited in the past for
performing a variety of DoS (Denial of Service) attacks [NISCC2004] performing a variety of DoS (Denial of Service) attacks [NISCC2004]
[RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as [RFC4987] [CERT1996a] [CERT1996b] [CERT1998a], and to impersonate as
other systems in scenarios in which authentication was based on the other systems in scenarios in which authentication was based on the
Source Address of the sending system [daemon91996]. Source Address of the sending system [daemon91996].
The extent to which these attacks can be successfully performed in The extent to which these attacks can be successfully performed in
the Internet can be reduced through deployment of ingress/egress the Internet can be reduced through deployment of ingress/egress
filtering in the internet routers. [NISCC2006] is a detailed guide filtering in the internet routers. [NISCC2006] is a detailed guide
on ingress and egress filtering. [RFC3704] and [RFC2827] discuss on ingress and egress filtering. [RFC3704] and [RFC2827] discuss
ingress filtering. [GIAC2000] discusses egress filtering. ingress filtering. [GIAC2000] discusses egress filtering.
Even when the obvious field on which to perform checks for ingress/ o Even when the obvious field on which to perform checks for
egress filtering is the Source Address and Destination Address fields ingress/egress filtering is the Source Address and Destination
of the IP header, there are other occurrences of IP addresses on Address fields of the IP header, there are other occurrences of IP
which the same type of checks should be performed. One example is addresses on which the same type of checks should be performed.
the IP addresses contained in the payload of ICMP error messages, as One example is the IP addresses contained in the payload of ICMP
discussed in [I-D.ietf-tcpm-icmp-attacks] and [Gont2006]. error messages, as discussed in [I-D.ietf-tcpm-icmp-attacks] and
[Gont2006].
There are a number of sanity checks that should be performed on the There are a number of sanity checks that should be performed on the
Source Address of an IP datagram. Details can be found in Section Source Address of an IP datagram. Details can be found in Section
4.2 ("Addressing"). 4.2 ("Addressing").
Additionally, there exist freely available tools that allow Additionally, there exist freely available tools that allow
administrators to monitor which IP addresses are used with which MAC administrators to monitor which IP addresses are used with which MAC
addresses [LBNL2006]. This functionality is also included in many addresses [LBNL2006]. This functionality is also included in many
Network Intrusion Detection Systems (NIDS). Network Intrusion Detection Systems (NIDS).
It is also very important to understand that authentication should It is also very important to understand that authentication should
never rely on the Source Address of the communicating systems. never rely on the Source Address of the communicating systems.
3.12. Destination Address 3.13. Destination Address
The Destination Address of an IP datagram identifies the destination The Destination Address of an IP datagram identifies the destination
host to which the packet is meant to be delivered. host to which the packet is meant to be delivered.
Strictly speaking, the Destination Address of an IP datagram o Strictly speaking, the Destination Address of an IP datagram
identifies the interface of the destination network interface, rather identifies the interface of the destination network interface,
than the destination "system", as in the Internet Architecture rather than the destination "system", as in the Internet
there's no concept of "node". Architecture there's no concept of "node".
There are a number of sanity checks that should be performed on the There are a number of sanity checks that should be performed on the
Destination Address of an IP datagram. Details can be found in Destination Address of an IP datagram. Details can be found in
Section 4.2 ("Addressing"). Section 4.2 ("Addressing").
3.13. Options 3.14. Options
According to RFC 791, IP options must be implemented by all IP According to RFC 791, IP options must be implemented by all IP
modules, both in hosts and gateways (i.e., end-systems and modules, both in hosts and gateways (i.e., end-systems and
intermediate-systems). intermediate-systems).
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
skipping to change at page 24, line 39 skipping to change at page 26, line 40
o 2 = debugging and measurement. o 2 = debugging and measurement.
o 3 = reserved for future use. o 3 = reserved for future use.
This format allows for the creation of new options for the extension This format allows for the creation of new options for the extension
of the Internet Protocol (IP). of the Internet Protocol (IP).
Finally, the option number identifies the syntax of the rest of the Finally, the option number identifies the syntax of the rest of the
option. option.
3.13.1. General issues with IP options 3.14.1. General issues with IP options
The following subsections discuss security issues that apply to all The following subsections discuss security issues that apply to all
IP options. The proposed checks should be performed in addition to IP options. The proposed checks should be performed in addition to
any option-specific checks proposed in the next sections. any option-specific checks proposed in the next sections.
3.13.1.1. Processing requirements 3.14.1.1. Processing requirements
Router manufacturers tend to do IP option processing on the main Router manufacturers tend to do IP option processing on the main
processor, rather than on line cards. Unless special care is taken, processor, rather than on line cards. Unless special care is taken,
this may be a security risk, as there is potential for overwhelming this represents Denial of Service (DoS) risk, as there is potential
the router with option processing. for overwhelming the router with option processing.
To reduce the impact of these packets on the system performance, a To reduce the impact of these packets on the system performance, a
few counter-measures could be implemented: few counter-measures could be implemented:
o Rate-limit the number of packets with IP options that are o Rate-limit the number of packets with IP options that are
processed by the system. processed by the system.
o Enforce a limit on the maximum number of options to be accepted on o Enforce a limit on the maximum number of options to be accepted on
a given internet datagram. a given internet datagram.
The first check avoids a flow of packets with IP options to overwhelm The first check avoids a flow of packets with IP options to overwhelm
the system in question. The second check avoids packets with the system in question. The second check avoids packets with
multiple IP options to affect the performance of the system. multiple IP options to affect the performance of the system.
3.13.1.2. Processing of the options by the upper layer protocol 3.14.1.2. Processing of the options by the upper layer protocol
Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options Section 3.2.1.8 of RFC 1122 [RFC1122] states that all the IP options
received in IP datagrams must be passed to the transport layer (or to received in IP datagrams must be passed to the transport layer (or to
ICMP processing when the datagram is an ICMP message). Therefore, ICMP processing when the datagram is an ICMP message). Therefore,
care in option processing must be taken not only at the internet care in option processing must be taken not only at the internet
layer, but also in every protocol module that may end up processing layer, but also in every protocol module that may end up processing
the options included in an IP datagram. the options included in an IP datagram.
3.13.1.3. General sanity checks on IP options 3.14.1.3. General sanity checks on IP options
There are a number of sanity checks that should be performed on IP There are a number of sanity checks that should be performed on IP
options before further option processing is done. They help prevent options before further option processing is done. They help prevent
a number of potential security problems, including buffer overflows. a number of potential security problems, including buffer overflows.
When these checks fail, the packet carrying the option should be When these checks fail, the packet carrying the option 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).
RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem" RFC 1122 [RFC1122] recommends to send an ICMP "Parameter Problem"
message to the originating system when a packet is dropped because of message to the originating system when a packet is dropped because of
skipping to change at page 26, line 12 skipping to change at page 28, line 12
Option length Option length
Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must Section 3.2.1.8 of RFC 1122 explicitly states that the IP layer must
not crash as the result of an option length that is outside the not crash as the result of an option length that is outside the
possible range, and mentions that erroneous option lengths have been possible range, and mentions that erroneous option lengths have been
observed to put some IP implementations into infinite loops. observed to put some IP implementations into infinite loops.
For options that belong to the "Case 2" described in the previous For options that belong to the "Case 2" described in the previous
section, the following check should be performed: section, the following check should be performed:
option-length >= 2 option-length >= 2
The value "2" accounts for the option-type byte, and the option- o The value "2" accounts for the option-type byte, and the option-
length byte. length byte.
This check prevents, among other things, loops in option processing This check prevents, among other things, loops in option processing
that may arise from incorrect option lengths. that may arise from incorrect option lengths.
Additionally, while the option-length byte of IP options of "Case 2" Additionally, while the option-length byte of IP options of "Case 2"
allows for an option length of up to 255 bytes, there is a limit on allows for an option length of up to 255 bytes, there is a limit on
legitimate option length imposed by the syntax of the IP header. legitimate option length imposed by the syntax of the IP header.
For all options of "Case 2", the following check should be enforced: For all options of "Case 2", the following check should be enforced:
option-offset + option-length <= IHL * 4 option-offset + option-length <= IHL * 4
Where option-offset is the offset of the first byte of the option Where option-offset is the offset of the first byte of the option
within the IP header, with the first byte of the IP header being within the IP header, with the first byte of the IP header being
assigned an offset of 0. assigned an offset of 0.
If a packet does not pass these checks, the corresponding packet If a packet does not pass these checks, the corresponding packet
should be dropped, and this event should be logged (e.g., a counter should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). could be incremented to reflect the packet drop).
The aforementioned check is meant to detect forged option-length The aforementioned check is meant to detect forged option-length
skipping to change at page 27, line 5 skipping to change at page 29, line 6
Data types Data types
Many IP options use pointer and length fields. Care must be taken as Many IP options use pointer and length fields. Care must be taken as
to the data type used for these fields in the implementation. For to the data type used for these fields in the implementation. For
example, if an 8-bit signed data type were used to hold an 8-bit example, if an 8-bit signed data type were used to hold an 8-bit
pointer, then, pointer values larger than 128 might mistakenly be pointer, then, pointer values larger than 128 might mistakenly be
interpreted as negative numbers, and thus might lead to unpredictable interpreted as negative numbers, and thus might lead to unpredictable
results. results.
3.13.2. Issues with specific options 3.14.2. Issues with specific options
3.13.2.1. End of Option List (Type = 0) 3.14.2.1. End of Option List (Type = 0)
This option is used to indicate the "end of options" in those cases This option is used to indicate the "end of options" in those cases
in which the end of options would not coincide with the end of the in which the end of options would not coincide with the end of the
Internet Protocol Header. Internet Protocol Header.
IP systems are required to ignore those options they do not IP systems are required to ignore those options they do not
implement. Therefore, even in those cases in which this option is implement. Therefore, even in those cases in which this option is
required, but is missing, IP systems should be able to process the required, but is missing, IP systems should be able to process the
remaining bytes of the IP header without any problems. remaining bytes of the IP header without any problems.
3.13.2.2. No Operation (Type = 1) 3.14.2.2. No Operation (Type = 1)
The no-operation option is basically meant to allow the sending The no-operation option is basically meant to allow the sending
system to align subsequent options in, for example, 32-bit system to align subsequent options in, for example, 32-bit
boundaries. boundaries.
This option does not have security implications. This option does not have security implications.
3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) 3.14.2.3. Loose Source Record Route (LSRR) (Type = 131)
This option lets the originating system specify a number of This option lets the originating system specify a number of
intermediate systems a packet must pass through to get to the intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option. The receiving host (end-system) must use the recorded in the option. The receiving host (end-system) must use the
reverse of the path contained in the received LSRR option. reverse of the path contained in the received LSRR option.
The LSSR option can be of help in debugging some network problems. The LSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP. support for this option in the routers within the peer of the ISP.
skipping to change at page 27, line 50 skipping to change at page 30, line 4
o Bypass firewall rules o Bypass firewall rules
o Reach otherwise unreachable internet systems o Reach otherwise unreachable internet systems
o Establish TCP connections in a stealthy way o Establish TCP connections in a stealthy way
o Learn about the topology of a network o Learn about the topology of a network
o Perform bandwidth-exhaustion attacks o Perform bandwidth-exhaustion attacks
Of these attack vectors, the one that has probably received least Of these attack vectors, the one that has probably received least
attention is the use of the LSRR option to perform bandwidth attention is the use of the LSRR option to perform bandwidth
exhaustion attacks. The LSRR option can be used as an amplification exhaustion attacks. The LSRR option can be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker method for performing bandwidth-exhaustion attacks, as an attacker
could make a packet bounce multiple times between a number of systems could make a packet bounce multiple times between a number of systems
by carefully crafting an LSRR option. by carefully crafting an LSRR option.
This is the IPv4-version of the IPv6 amplification attack that was o This is the IPv4-version of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is that widely publicized in 2007 [Biondi2007]. The only difference is
the maximum length of the IPv4 header (and hence the LSRR option) that the maximum length of the IPv4 header (and hence the LSRR
limits the amplification factor when compared to the IPv6 counter- option) limits the amplification factor when compared to the IPv6
part. counter-part.
While the LSSR option may be of help in debugging some network While the LSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use. problems, its security implications outweigh any legitimate use.
All systems should, by default, drop IP packets that contain an LSRR All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event (e.g., a counter could be option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should incremented to reflect the packet drop). However, they should
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 implementation [OpenBSD1998] is a security advisory about an improper
of such a system-wide in 4.4BSD kernels. implementation of such a system-wide toggle in 4.4BSD kernels.
Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to Section 3.3.5 of RFC 1122 [RFC1122] states that a host may be able to
act as an intermediate hop in a source route, forwarding a source- act as an intermediate hop in a source route, forwarding a source-
routed datagram to the next specified hop. We strongly discourage routed datagram to the next specified hop. We strongly discourage
host software from forwarding source-routed datagrams. host software from forwarding source-routed datagrams.
If processing of source-routed datagrams is explicitly enabled in a If processing of source-routed datagrams is explicitly enabled in a
system, the following sanity checks should be performed. system, the following sanity checks should be performed.
RFC 791 states that this option should appear, at most, once in a RFC 791 states that this option should appear, at most, once in a
skipping to change at page 28, line 50 skipping to change at page 31, line 5
Therefore, hosts and routers should discard packets that contain more Therefore, hosts and routers should discard packets that contain more
than one LSRR option. Additionally, if a packet were found to have than one LSRR option. Additionally, if a packet were found to have
both LSRR and SSRR options, it should be dropped, and this event both LSRR and SSRR options, it should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the should be logged (e.g., a counter could be incremented to reflect the
packet drop). packet drop).
As many other IP options, the LSSR contains a Length field that As many other IP options, the LSSR contains a Length field that
indicates the length of the option. Given the format of the option, indicates the length of the option. Given the format of the option,
the Length field should be checked to be at least 3 (three): the Length field should be checked to be at least 3 (three):
LSRR.Length >= 3 LSRR.Length >= 3
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Additionally, the following check should be performed on the Length Additionally, the following check should be performed on the Length
field: field:
LSRR.Offset + LSRR.Length < IHL *4 LSRR.Offset + LSRR.Length < IHL *4
This check assures that the option does not overlap with the IP This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, and this event should does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet be logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
The Pointer is relative to this option. Thus, the minimum legal The Pointer is relative to this option. Thus, the minimum legal
value is 4. Therefore, the following check should be performed. value is 4. Therefore, the following check should be performed.
LSRR.Pointer >= 4 LSRR.Pointer >= 4
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). Additionally, the Pointer field should be reflect the packet drop). Additionally, the Pointer field should be
a multiple of 4. Consequently, the following check should be a multiple of 4. Consequently, the following check should be
performed: performed:
LSRR.Pointer % 4 == 0 LSRR.Pointer % 4 == 0
If a packet does not pass this check, it should be dropped, and this If a packet does not pass this check, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
When a system receives an IP packet with the LSRR route option, it When a system receives an IP packet with the LSRR route option, it
should check whether the source route is empty or not. The option is should check whether the source route is empty or not. The option is
empty if: empty if:
LSRR.Pointer > LSRR.Length LSRR.Pointer > LSRR.Length
In that case, routing should be based on the Destination Address In that case, routing should be based on the Destination Address
field, and no further processing should be done on the LSRR option. field, and no further processing should be done on the LSRR option.
[Microsoft1999] is a security advisory about a vulnerability arising o [Microsoft1999] is a security advisory about a vulnerability
from improper validation of the LSRR.Pointer field. arising from improper validation of the LSRR.Pointer field.
If the address in the Destination Address field has been reached, and If the address in the Destination Address field has been reached, and
the option is not empty, the next address in the source route the option is not empty, the next address in the source route
replaces the address in the Destination Address field. replaces the address in the Destination Address field.
The IP address of the interface that will be used to forward this The IP address of the interface that will be used to forward this
datagram should be recorded into the LSRR. However, before writing datagram should be recorded into the LSRR. However, before writing
in the route data area, the following check should be performed: in the route data area, the following check should be performed:
LSRR.Length - LSRR.Pointer >= 3 LSRR.Length - LSRR.Pointer >= 3
This assures that there will be at least 4 bytes of space in which to This assures that there will be at least 4 bytes of space in which to
record the IP address. If the packet does not pass this check, it record the IP address. If the packet does not pass this check, it
should be dropped, and this event should be logged (e.g., a counter should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). could be incremented to reflect the packet drop).
An offset of "1" corresponds to the option type, that's why the o An offset of "1" corresponds to the option type, that's why the
performed check is LSRR.Length - LSRR.Pointer >=3, and not performed check is LSRR.Length - LSRR.Pointer >=3, and not
LSRR.Length - LSRR.Pointer >=4. LSRR.Length - LSRR.Pointer >=4.
The LSRR must be copied on fragmentation. This means that if a The LSRR must be copied on fragmentation. This means that if a
packet that carries the LSRR is fragmented, each of the fragments packet that carries the LSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the LSRR will have to go through the list of systems specified in the LSRR
option. option.
3.13.2.4. Strict Source and Record Route (SSRR) (Type = 137) 3.14.2.4. Strict Source and Record Route (SSRR) (Type = 137)
This option allows the originating system to specify a number of This option allows the originating system to specify a number of
intermediate systems a packet must pass through to get to the intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination host (end-system) must recorded in the option, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option. use the reverse of the path contained in the received SSRR option.
This option is similar to the Loose Source and Record Route (LSRR) This option is similar to the Loose Source and Record Route (LSRR)
option, with the only difference that in the case of SSRR, the route option, with the only difference that in the case of SSRR, the route
specified in the option is the exact route the packet must take specified in the option is the exact route the packet must take
(i.e., no other intervening routers are allowed to be in the route). (i.e., no other intervening routers are allowed to be in the route).
The SSSR option can be of help in debugging some network problems. The SSSR option can be of help in debugging some network problems.
Some ISP (Internet Service Provider) peering agreements require Some ISP (Internet Service Provider) peering agreements require
support for this option in the routers within the peer of the ISP. support for this option in the routers within the peer of the ISP.
The SSRR option has well-known security implications. Among other The SSRR option has the same security implications as the LSRR
things, the option can be used to: option. Please refer to Section Section 3.14.2.3 for a discussion of
such security implications.
o Bypass firewall rules
o Reach otherwise unreachable internet systems
o Establish TCP connections in a stealthy way
o Learn about the topology of a network
o Perform bandwidth-exhaustion attacks
Of these attack vectors, the one that has probably received least
attention is the use of the SSRR option to perform bandwidth
exhaustion attacks. The SSRR option can be used as an amplification
method for performing bandwidth-exhaustion attacks, as an attacker
could make a packet bounce multiple times between a number of systems
by carefully crafting an LSRR option.
This is the IPv4-version of the IPv6 amplification attack that was
widely publicized in 2007 [Biondi2007]. The only difference is that
the maximum length for the IPv4 header (and hence the SSRR option)
limits the amplification factor when compared to the IPv6 counter-
part.
While the SSSR option may be of help in debugging some network As with the LSRR, while the SSSR option may be of help in debugging
problems, its security implications outweigh any legitimate use of some network problems, its security implications outweigh any
it. legitimate use of it.
All systems should, by default, drop IP packets that contain an LSRR All systems should, by default, drop IP packets that contain an LSRR
option, and should log this event (e.g., a counter could be option, and should log this event (e.g., a counter could be
incremented to reflect the packet drop). However, they should incremented to reflect the packet drop). However, they should
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 implementation [OpenBSD1998] is a security advisory about an improper
of such a system-wide 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,
there are some sanity checks that should be performed. the same sanity checks described for the LSRR option in
Section 3.14.2.3 should be performed on the SSRR option. Namely,
sanity checks shoudl be performed on the option length (SSRR.Length)
and the Pointer field (SSRR.Pointer).
RFC 791 states that this option should appear, at most, once in a If the packet passes the aforementioned sanity checks, the receiving
given packet. Thus, if a packet is found to have more than one SSRR system should determine whether the Destination Address of the packet
option, it should be dropped, and this event should be logged (e.g., corresponds to one of its IP addresses. If does not, it should be
a counter could be incremented to reflect the packet drop). Also, if dropped, and this event should be logged (e.g., a counter could be
a packet contains a combination of SSRR and LSRR options, it should
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).
As the SSRR option is meant to specify the route a packet should Contrary to the IP Loose Source and Record Route (LSRR) option,
follow from source to destination, use of more than one SSRR option the SSRR option does not allow in the route other routers than
in a single packet would be nonsensical. Therefore, hosts and those contained in the option. If the system implements the weak
routers should check the IP header and discard the packet if it end-system model, it is allowed for the system to receive a packet
contains more than one SSRR option, or a combination of LSRR and SSRR destined to any of its IP addresses, on any of its interfaces. If
options. the system implements the strong end-system model, a packet
destined to it can be received only on the interface that
As with many other IP options, the SSRR option contains a Length corresponds to the IP address contained in the Destination Address
field that indicates the length of the option. Given the format of field [RFC1122].
the option, the length field should be checked to be at least 3:
SSRR.Length >= 3
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
Additionally, the following check should be performed on the length
field:
SSRR.Offset + SSRR.Length < IHL *4
This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop).
The Pointer field is relative to this option, with the minimum legal
value being 4. Therefore, the following check should be performed:
SSRR.Pointer >= 4
If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
Additionally, the Pointer field should be a multiple of 4.
Consequently, the following check should be performed:
SSRR.Pointer % 4 == 0
If a packet does not pass this check, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
If the packet passes the above 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 those
contained in the option. If the system implements the weak end-
system model, it is allowed for the system to receive a packet
destined to any of its IP addresses, on any of its interfaces. If
the system implements the strong end-system model, a packet destined
to it can be received only on the interface that corresponds to the
IP address contained in the Destination Address field [RFC1122].
If the packet passes this check, the receiving system should If the packet passes this check, the receiving system should
determine whether the source route is empty or not. The option is determine whether the source route is empty or not. The option is
empty if: empty if:
SSRR.Pointer > SSRR.Length SSRR.Pointer > SSRR.Length
In that case, if the address in the destination field has not been In that case, if the address in the destination field has not been
reached, the packet should be dropped, and this event should be reached, the packet 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
drop). drop).
[Microsoft1999] is a security advisory about a vulnerability arising [Microsoft1999] is a security advisory about a vulnerability
from improper validation of the SSRR.Pointer field. arising from improper validation of the SSRR.Pointer field.
If the option is not empty, and the address in the Destination If the option is not empty, and the address in the Destination
Address field has been reached, the next address in the source route Address field has been reached, the next address in the source route
replaces the address in the Destination Address field. This IP replaces the address in the Destination Address field. This IP
address must be reachable without the use of any intervening router address must be reachable without the use of any intervening router
(i.e., the address must belong to any of the networks to which the (i.e., the address must belong to any of the networks to which the
system is directly attached). If that is not the case, the packet system is directly attached). If that is not the case, the packet
should be dropped, and this event should be logged (e.g., a counter should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). could be incremented to reflect the packet drop).
The IP address of the interface that will be used to forward this The IP address of the interface that will be used to forward this
datagram should be recorded into the SSRR. However, before doing datagram should be recorded into the SSRR. However, before doing
that, the following check should be performed: that, the following check should be performed:
SSRR.Length - SSRR.Pointer >=3 SSRR.Length - SSRR.Pointer >=3
An offset of "1" corresponds to the option type, that's why the An offset of "1" corresponds to the option type, that's why the
performed check is SSRR.Length - SSRR.Pointer >=3, and not performed check is SSRR.Length - SSRR.Pointer >=3, and not
SSRR.Length - SSRR.Pointer >=4. SSRR.Length - SSRR.Pointer >=4.
This assures that there will be at least 4 bytes of space on which to This assures that there will be at least 4 bytes of space on which to
record the IP address. If the packet does not pass this check, it record the IP address. If the packet does not pass this check, it
should be dropped, and this event should be logged (e.g., a counter should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop). could be incremented to reflect the packet drop).
The SSRR option must be copied on fragmentation. This means that if The SSRR option must be copied on fragmentation. This means that if
a packet that carries the SSRR is fragmented, each of the fragments a packet that carries the SSRR is fragmented, each of the fragments
will have to go through the list of systems specified in the SSRR will have to go through the list of systems specified in the SSRR
option. option.
3.13.2.5. Record Route (Type = 7) 3.14.2.5. Record Route (Type = 7)
This option provides a means to record the route that a given packet This option provides a means to record the route that a given packet
follows. follows.
The option begins with an 8-bit option code, which must be equal to The option begins with an 8-bit option code, which must be equal to
7. The second byte is the option length, which includes the option- 7. The second byte is the option length, which includes the option-
type byte, the option-length byte, the pointer byte, and the actual type byte, the option-length byte, the pointer byte, and the actual
option-data. The third byte is a pointer into the route data, option-data. The third byte is a pointer into the route data,
indicating the first byte of the area in which to store the next indicating the first byte of the area in which to store the next
route data. The pointer is relative to the option start. route data. The pointer is relative to the option start.
RFC 791 states that this option should appear, at most, once in a RFC 791 states that this option should appear, at most, once in a
given packet. Therefore, if a packet has more than one instance of given packet. Therefore, if a packet has more than one instance of
this option, it should be dropped, and this event should be logged this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop). (e.g., a counter could be incremented to reflect the packet drop).
Given the format of the option, the Length field should be checked to The same sanity checks performed for the Length field and the Pointer
be at least 3: field of the LSRR and the SSRR options should be performed on the
Length field (RR.Length) and the Pointer field (RR.Pointer) of the RR
RR.Length >= 3 option. And, as with the LSRR and SSRR options, if the packet does
not pass these checks it should be dropped, and this event should be
If the packet does not pass this check, it should be dropped, and logged (e.g., a counter could be incremented to reflect the packet
this event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
Additionally, the following check should be performed on the Length
field:
RR.Offset + RR_Length < IHL *4
This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
The pointer field is relative to this option, with the minimum legal
value being 4. Therefore, the following check should be performed:
RR.Pointer >= 3
If the packet does not pass this check, it should be silently
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).
Additionally, the Pointer field should be a multiple of 4.
Consequently, the following check should be performed:
RR.Pointer % 4 == 0
When a system receives an IP packet with the Record Route option, it When a system receives an IP packet with the Record Route option, it
should check whether there is space in the option to store route should check whether there is space in the option to store route
information. The option is full if: information. The option is full if:
RR.Pointer > RR.Length RR.Pointer > RR.Length
If the option is full, the datagram should be forwarded without If the option is full, the datagram should be forwarded without
further processing of this option. If not, the following check further processing of this option. If not, the following check
should be performed before writing any route data into the option: should be performed before writing any route data into the option:
RR.Pointer - RR.Length >= 3 RR.Pointer - RR.Length >= 3
If the packet does not pass this check, the packet should be If the packet does not pass this check, the packet should be
considered in error, and therefore should be dropped, and this event considered in error, and therefore should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the should be logged (e.g., a counter could be incremented to reflect the
packet drop). packet drop).
If the option is not full (i.e., RR.Pointer <= RR.Length), but If the option is not full (i.e., RR.Pointer <= RR.Length), but
RR.Pointer - RR.Length < 4, it means that while there's space in the RR.Pointer - RR.Length < 4, it means that while there's space in
option, there is not not enough space to store an IP address. It is the option, there is not not enough space to store an IP address.
fair to assume that such an scenario will only occur when the packet It is fair to assume that such an scenario will only occur when
has been crafted. the packet has been crafted.
If the packet passes this check, the IP address of the interface that If the packet passes this check, the IP address of the interface that
will be used to forward this datagram should be recorded into the will be used to forward this datagram should be recorded into the
area pointed by the RR.Pointer, and RR.Pointer should then be area pointed by the RR.Pointer, and RR.Pointer should then be
incremented by 4. incremented by 4.
This option is not copied on fragmentation, and thus appears in the This option is not copied on fragmentation, and thus appears in the
first fragment only. If a fragment other than the one with offset 0 first fragment only. If a fragment other than the one with offset 0
contains the Record Route option, it should be dropped, and this contains the Record Route option, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
3.13.2.6. Stream Identifier (Type = 136) 3.14.2.6. Stream Identifier (Type = 136)
The Stream Identifier option originally provided a means for the 16- The Stream Identifier option originally provided a means for the 16-
bit SATNET stream Identifier to be carried through networks that did bit SATNET stream Identifier to be carried through networks that did
not support the stream concept. not support the stream concept.
However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this However, as stated by Section 4.2.2.1 of RFC 1812 [RFC1812], this
option is obsolete. Therefore, it should be ignored by the option is obsolete. Therefore, it should be ignored by the
processing systems. processing systems.
In the case of legacy systems still using this option, the length In the case of legacy systems still using this option, the length
field of the option should be checked to be 4. If the option does field of the option should be checked to be 4. If the option does
not pass this check, it should be dropped, and this event should be not pass this check, it 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
drop). drop).
RFC 791 states that this option appears at most once in a given RFC 791 states that this option appears at most once in a given
datagram. Therefore, if a packet contains more than one instance of datagram. Therefore, if a packet contains more than one instance of
this option, it should be dropped, and this event should be logged this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop). (e.g., a counter could be incremented to reflect the packet drop).
3.13.2.7. Internet Timestamp (Type = 68) 3.14.2.7. Internet Timestamp (Type = 68)
This option provides a means for recording the time at which each This option provides a means for recording the time at which each
system processed this datagram. The timestamp option has a number of system processed this datagram. The timestamp option has a number of
security implications. Among them are: security implications. Among them are:
o It allows an attacker to obtain the current time of the systems o It allows an attacker to obtain the current time of the systems
that process the packet, which the attacker may find useful in a that process the packet, which the attacker may find useful in a
number of scenarios. number of scenarios.
o It may be used to map the network topology, in a similar way to o It may be used to map the network topology, in a similar way to
skipping to change at page 36, line 47 skipping to change at page 37, line 11
The option begins with an option-type byte, which must be equal to The option begins with an option-type byte, which must be equal to
68. The second byte is the option-length, which includes the option- 68. The second byte is the option-length, which includes the option-
type byte, the option-length byte, the pointer, and the overflow/flag type byte, the option-length byte, the pointer, and the overflow/flag
byte. The minimum legal value for the option-length byte is 4, which byte. The minimum legal value for the option-length byte is 4, which
corresponds to an Internet Timestamp option that is empty (no space corresponds to an Internet Timestamp option that is empty (no space
to store timestamps). Therefore, upon receipt of a packet that to store timestamps). Therefore, upon receipt of a packet that
contains an Internet Timestamp option, the following check should be contains an Internet Timestamp option, the following check should be
performed: performed:
IT.Length >= 4 IT.Length >= 4
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Additionally, the following check should be performed on the option Additionally, the following check should be performed on the option
length field: length field:
IT.Offset + IT.Length < IHL *4 IT.Offset + IT.Length < IHL *4
This check assures that the option does not overlap with the IP This check assures that the option does not overlap with the IP
payload (i.e., it does not go past the IP header). If the packet payload (i.e., it does not go past the IP header). If the packet
does not pass this check, it should be dropped, and this event should does not pass this check, it should be dropped, and this event should
be logged (e.g., a counter could be incremented to reflect the packet be logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
The pointer byte points to the first byte of the area in which the The pointer byte points to the first byte of the area in which the
next timestamp data should be stored. As its value is relative to next timestamp data should be stored. As its value is relative to
the beginning of the option, its minimum legal value is 5. the beginning of the option, its minimum legal value is 5.
Consequently, the following check should be performed on a packet Consequently, the following check should be performed on a packet
that contains the Internet Timestamp option: that contains the Internet Timestamp option:
IT.Pointer >= 5 IT.Pointer >= 5
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The flag field has three possible legal values: The flag field has three possible legal values:
o 0: Record time stamps only, stored in consecutive 32-bit words. o 0: Record time stamps only, stored in consecutive 32-bit words.
o 1: Record each timestamp preceded with the internet address of the o 1: Record each timestamp preceded with the internet address of the
registering entity. registering entity.
o 3: The internet address fields of the option are pre-specified. o 3: The internet address fields of the option are pre-specified.
An IP module only registers its timestamp if it matches its own An IP module only registers its timestamp if it matches its own
address with the next specified internet address. address with the next specified internet address.
Therefore the following check should be performed: Therefore the following check should be performed:
IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3 IT.Flag == 0 || IT.Flag == 1 || IT.Flag == 3
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The timestamp field is a right-justified 32-bit timestamp in The timestamp field is a right-justified 32-bit timestamp in
milliseconds since UT. If the time is not available in milliseconds, milliseconds since UT. If the time is not available in milliseconds,
or cannot be provided with respect to UT, then any time may be or cannot be provided with respect to UT, then any time may be
inserted as a timestamp, provided the high order bit of the timestamp inserted as a timestamp, provided the high order bit of the timestamp
is set, to indicate this non-standard value. is set, to indicate this non-standard value.
skipping to change at page 38, line 16 skipping to change at page 38, line 31
be initialized to zero, or internet address/zero pairs. However, be initialized to zero, or internet address/zero pairs. However,
internet systems should be able to handle non-zero values, possibly internet systems should be able to handle non-zero values, possibly
discarding the offending datagram. discarding the offending datagram.
When an internet system receives a packet with an Internet Timestamp When an internet system receives a packet with an Internet Timestamp
option, it decides whether it should record its timestamp in the option, it decides whether it should record its timestamp in the
option. If it determines that it should, it should then determine option. If it determines that it should, it should then determine
whether the timestamp data area is full, by means of the following whether the timestamp data area is full, by means of the following
check: check:
IT.Pointer > IT.Length IT.Pointer > IT.Length
If this condition is true, the timestamp data area is full. If not, If this condition is true, the timestamp data area is full. If not,
there is room in the timestamp data area. there is room in the timestamp data area.
If the timestamp data area is full, the overflow byte should be If the timestamp data area is full, the overflow byte should be
incremented, and the packet should be forwarded without inserting the incremented, and the packet should be forwarded without inserting the
timestamp. If the overflow byte itself overflows, the packet should timestamp. If the overflow byte itself overflows, the packet should
be dropped, and this event should be logged (e.g., a counter could be 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).
If timestamp data area is not full, then further checks should be If timestamp data area is not full, then further checks should be
performed before actually inserting any data. performed before actually inserting any data.
If the IT.Flag byte is 0, the following check should be performed: If the IT.Flag byte is 0, the following check should be performed:
IT.Length - IT.Pointer >= 3 IT.Length - IT.Pointer >= 3
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If the packet passes this check, there is reflect the packet drop). If the packet passes this check, there is
room for at least one 32-bit timestamp. The system's 32-bit room for at least one 32-bit timestamp. The system's 32-bit
timestamp should be inserted at the area pointed by the pointer byte, timestamp should be inserted at the area pointed by the pointer byte,
and the pointer byte should be incremented by four. and the pointer byte should be incremented by four.
If the IT.Flag byte is 1, then the following check should be If the IT.Flag byte is 1, then the following check should be
performed: performed:
IT.Length - IT.Pointer >= 7 IT.Length - IT.Pointer >= 7
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If the packet does pass this check, it reflect the packet drop). If the packet does pass this check, it
means there is space in the timestamp data area to store at least one means there is space in the timestamp data area to store at least one
IP address plus the corresponding 32-bit timestamp. The IP address IP address plus the corresponding 32-bit timestamp. The IP address
of the system should be stored at the area pointed to by the pointer of the system should be stored at the area pointed to by the pointer
byte, followed by the 32-bit system timestamp. The pointer byte byte, followed by the 32-bit system timestamp. The pointer byte
should then be incremented by 8. should then be incremented by 8.
If the flag byte is 3, then the following check should be performed: If the flag byte is 3, then the following check should be performed:
IT.Length - IT.Pointer >= 7 IT.Length - IT.Pointer >= 7
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). If it does, it means there is space in the reflect the packet drop). If it does, it means there is space in the
timestamp data area to store an IP address and store the timestamp data area to store an IP address and store the
corresponding 32-bit timestamp. The system's timestamp should be corresponding 32-bit timestamp. The system's timestamp should be
stored at the area pointed by IT.Pointer + 4. Then, the pointer byte stored at the area pointed by IT.Pointer + 4. Then, the pointer byte
should be incremented by 8. should be incremented by 8.
[Kohno2005] describes a technique for fingerprinting devices by [Kohno2005] describes a technique for fingerprinting devices by
measuring the clock skew. It exploits, among other things, the measuring the clock skew. It exploits, among other things, the
timestamps that can be obtained by means of the ICMP timestamp timestamps that can be obtained by means of the ICMP timestamp
request messages [RFC0791]. However, the same fingerprinting method request messages [RFC0791]. However, the same fingerprinting method
could be implemented with the aid of the Internet Timestamp option. could be implemented with the aid of the Internet Timestamp option.
3.13.2.8. Router Alert (Type = 148) 3.14.2.8. Router Alert (Type = 148)
The Router Alert option is defined in RFC 2113 [RFC2113]. It has the The Router Alert option is defined in RFC 2113 [RFC2113]. It has the
semantic "routers should examine this packet more closely". A packet semantic "routers should examine this packet more closely". A packet
that contains a Router Alert option will not go through the router's that contains a Router Alert option will not go through the router's
fast-path and will be processed in the router more slowly than if the fast-path and will be processed in the router more slowly than if the
option were not set. Therefore, this option may impact the option were not set. Therefore, this option may impact the
performance of the systems that handle the packet carrying it. performance of the systems that handle the packet carrying it.
According to the syntax of the option as defined in RFC 2113, the According to the syntax of the option as defined in RFC 2113, the
following check should be enforced: following check should be enforced:
RA.Length == 4 RA.Length == 4
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). Furthermore, the following check should be reflect the packet drop). Furthermore, the following check should be
performed on the Value field: performed on the Value field:
RA.Value == 0 RA.Value == 0
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
As explained in RFC 2113, hosts should ignore this option. As explained in RFC 2113, hosts should ignore this option.
3.13.2.9. Probe MTU (Type =11) 3.14.2.9. Probe MTU (Type =11)
This option is defined in RFC 1063 [RFC1063], and originally provided This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU. 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
drop). drop).
3.13.2.10. Reply MTU (Type = 12) 3.14.2.10. Reply MTU (Type = 12)
This option is defined in RFC 1063 [RFC1063], and originally provided This option is defined in RFC 1063 [RFC1063], and originally provided
a mechanism to discover the Path-MTU. 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
drop). drop).
3.13.2.11. Traceroute (Type = 82) 3.14.2.11. Traceroute (Type = 82)
This option is defined in RFC 1393 [RFC1393], and originally provided This option is defined in RFC 1393 [RFC1393], and originally provided
a mechanism to trace the path to a host. a mechanism to trace the path to a host.
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
drop). drop).
3.13.2.12. DoD Basic Security Option (Type = 130) 3.14.2.12. DoD Basic Security Option (Type = 130)
This option is used by end-systems and intermediate systems of an This option is used by end-systems and intermediate systems of an
internet to [RFC1108]: internet to [RFC1108]:
o Transmit from source to destination in a network standard o Transmit from source to destination in a network standard
representation the common security labels required by computer representation the common security labels required by computer
security models, security models,
o Validate the datagram as appropriate for transmission from the o Validate the datagram as appropriate for transmission from the
source and delivery to the destination, and, source and delivery to the destination, and,
o Ensure that the route taken by the datagram is protected to the o Ensure that the route taken by the datagram is protected to the
level required by all protection authorities indicated on the level required by all protection authorities indicated on the
datagram. datagram.
It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038 It is specified by RFC 1108 [RFC1108] (which obsoletes RFC 1038
[RFC1038]). [RFC1038]).
RFC 791 [RFC0791] defined the "Security Option" (Type = 130), which o RFC 791 [RFC0791] defined the "Security Option" (Type = 130),
used the same option type as the DoD Basic Security option discussed which used the same option type as the DoD Basic Security option
in this section. The "Security Option" specified in RFC 791 is discussed in this section. The "Security Option" specified in RFC
considered obsolete by Section 4.2.2.1 of RFC 1812, and therefore the 791 is considered obsolete by Section 4.2.2.1 of RFC 1812, and
discussion in this section is focused on the DoD Basic Security therefore the discussion in this section is focused on the DoD
option specified by RFC 1108 [RFC1108]. Basic Security option specified by RFC 1108 [RFC1108].
Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement Section 4.2.2.1 of RFC 1812 states that routers "SHOULD implement
this option". this option".
The DoD Basic Security Option is currently implemented in a number of The DoD Basic Security Option is currently implemented in a number of
operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008], operating systems (e.g., [IRIX2008], [SELinux2008], [Solaris2008],
and [Cisco2008]), and deployed in a number of high-security networks. and [Cisco2008]), and deployed in a number of high-security networks.
RFC 1108 states that the option should appear at most once in a RFC 1108 states that the option should appear at most once in a
datagram. Therefore, if more than one DoD Basic Security option datagram. Therefore, if more than one DoD Basic Security option
(BSO) appears in a given datagram, the corresponding datagram should (BSO) appears in a given datagram, the corresponding datagram should
be dropped, and this event should be logged (e.g., a counter could be 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).
RFC 1108 states that the option Length is variable, with a minimum RFC 1108 states that the option Length is variable, with a minimum
option Length of 3 bytes. Therefore, the following check should be option Length of 3 bytes. Therefore, the following check should be
performed: performed:
BSO.Length >= 3 BSO.Length >= 3
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Systems that belong to networks in which this option is in use should Systems that belong to networks in which this option is in use should
process the DoD Basic Security option contained in each packet as process the DoD Basic Security option contained in each packet as
specified in [RFC1108]. specified in [RFC1108].
Current deployments of the DoD Security Options have motivated the o Current deployments of the DoD Security Options have motivated the
proposal of a "Common Architecture Label IPv6 Security Option proposal of a "Common Architecture Label IPv6 Security Option
(CALIPSO)" for the IPv6 protocol. [RFC1038]. (CALIPSO)" for the IPv6 protocol. [RFC1038].
3.13.2.13. DoD Extended Security Option (Type = 133) 3.14.2.13. DoD Extended Security Option (Type = 133)
This option permits additional security labeling information, beyond This option permits additional security labeling information, beyond
that present in the Basic Security Option (Section 3.13.2.12), to be that present in the Basic Security Option (Section 3.13.2.12), to be
supplied in an IP datagram to meet the needs of registered supplied in an IP datagram to meet the needs of registered
authorities. It is specified by RFC 1108 [RFC1108]. authorities. It is specified by RFC 1108 [RFC1108].
This option may be present only in conjunction with the DoD Basic This option may be present only in conjunction with the DoD Basic
Security option. Therefore, if a packet contains a DoD Extended Security option. Therefore, if a packet contains a DoD Extended
Security option (ESO), but does not contain a DoD Basic Security Security option (ESO), but does not contain a DoD Basic Security
option, it should be dropped, and this event should be logged (e.g., option, it should be dropped, and this event should be logged (e.g.,
a counter could be incremented to reflect the packet drop). It a counter could be incremented to reflect the packet drop). It
should be noted that, unlike the DoD Basic Security option, this should be noted that, unlike the DoD Basic Security option, this
option may appear multiple times in a single IP header. option may appear multiple times in a single IP header.
RFC 1108 states that the option Length is variable, with a minimum RFC 1108 states that the option Length is variable, with a minimum
option Length of 3 bytes. Therefore, the following check should be option Length of 3 bytes. Therefore, the following check should be
performed: performed:
ESO.Length >= 3 ESO.Length >= 3
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented to this event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Systems that belong to networks in which this option is in use, Systems that belong to networks in which this option is in use,
should process the DoD Extended Security option contained in each should process the DoD Extended Security option contained in each
packet as specified in RFC 1108 [RFC1108]. packet as specified in RFC 1108 [RFC1108].
3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 134) 3.14.2.14. Commercial IP Security Option (CIPSO) (Type = 134)
This option was proposed by the Trusted Systems Interoperability This option was proposed by the Trusted Systems Interoperability
Group (TSIG), with the intent of meeting trusted networking Group (TSIG), with the intent of meeting trusted networking
requirements for the commercial trusted systems market place. It is requirements for the commercial trusted systems market place. It is
specified in [CIPSO1992] and [FIPS1994]. specified in [CIPSO1992] and [FIPS1994].
The TSIG proposal was taken to the Commercial Internet Security o The TSIG proposal was taken to the Commercial Internet Security
Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an Option (CIPSO) Working Group of the IETF [CIPSOWG1994], and an
Internet-Draft was produced [CIPSO1992]. The Internet-Draft was Internet-Draft was produced [CIPSO1992]. The Internet-Draft was
never published as an RFC, and the proposal was later standardized by never published as an RFC, and the proposal was later standardized
the U.S. National Institute of Standards and Technology (NIST) as by the U.S. National Institute of Standards and Technology (NIST)
"Federal Information Processing Standard Publication 188" [FIPS1994]. as "Federal Information Processing Standard Publication 188"
[FIPS1994].
It is currently implemented in a number of operating systems (e.g., It is currently implemented in a number of operating systems (e.g.,
IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris IRIX [IRIX2008], Security-Enhanced Linux [SELinux2008], and Solaris
[Solaris2008]), and deployed in a number of high-security networks. [Solaris2008]), and deployed in a number of high-security networks.
[Zakrzewski2002] and [Haddad2004] provide an overview of a Linux o [Zakrzewski2002] and [Haddad2004] provide an overview of a Linux
implementation. implementation.
According to the option syntax specified in [CIPSO1992] the following According to the option syntax specified in [CIPSO1992] the following
validation check should be performed: validation check should be performed:
CIPSO.Length >= 6 CIPSO.Length >= 6
If a packet does not pass this check, it should be dropped, and this If a packet does not pass this check, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
Systems that belong to networks in which this option is in use should Systems that belong to networks in which this option is in use should
process the CIPSO option contained in each packet as specified in process the CIPSO option contained in each packet as specified in
[CIPSO1992]. [CIPSO1992].
3.13.2.15. Sender Directed Multi-Destination Delivery (Type = 149) 3.14.2.15. Sender Directed Multi-Destination Delivery (Type = 149)
This option is defined in RFC 1770 [RFC1770], and originally provided This option is defined in RFC 1770 [RFC1770], and originally provided
unreliable UDP delivery to a set of addresses included in the option. unreliable UDP delivery to a set of addresses included in the option.
This option is obsolete. If a received packet contains this option, This option is obsolete. If a received packet contains this option,
it should be dropped, and this event should be logged (e.g., a it should be dropped, 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).
3.14. Differentiated Services field 3.15. TOS
The Differentiated Services Architecture is intended to enable
scalable service discrimination in the Internet without the need for
per-flow state and signaling at every hop [RFC2475]. RFC 2474
[RFC2474] defines a Differentiated Services Field (DS Field), which
is intended to supersede the original Type of Service field. Figure
5 shows the format of the field.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
Figure 5: Structure of the DS Field
The DSCP ("Differentiated Services CodePoint").is used to select the
treatment the packet is to receive within the Differentiated Services
Domain. The CU ("Currently Unused") field was, at the time the
specification was issued, reserved for future use. The DSCP field is
used to select a PHB, by matching against the entire 6-bit field.
Considering that the DSCP field determines how a packet is treated
within a DS domain, an attacker send packets with a forged DSCP field
to perform a theft of service or even a Denial of Service attack. In
particular, an attacker could forge packets with a codepoint of the
type '11x000' which, according to Section 4.2.2.2 of RFC 2474
[RFC2474], would give the packets preferential forwarding treatment
when compared with the PHB selected by the codepoint '000000'. If
strict priority queuing were utilized, a continuous stream of such
pockets could perform a Denial of Service to other flows which have a
DSCP of lower relative order.
As the DS field is incompatible with the original Type of Service
field, both DS domains and networks using the original Type of
Service field should protect themselves by remarking the
corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be taken so that packets
received with an unrecognized DSCP do not cause the handling system
to malfunction.
3.15. Explicit Congestion Notification (ECN)
RFC 3168 [RFC3168] specifies a mechanism for routers to signal Figure 2 shows the syntax of the Type of Service field, as defined by
congestion to hosts sending IP packets, by marking the offending RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. We provide a
packets, rather than discarding them. RFC 3168 defines the ECN discussion of this obsoleted definition, legacy implementations might
field, which utilizes the CU unused field of the DSCP field described still be using these semantics.
in Section 3.14 of this document. Figure 6 shows the syntax of the
ECN field, together with the DSCP field used for Differentiated
Services.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD | | PRECEDENCE | D | T | R | C | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Figure 6: The Differentiated Services and ECN fields in IP Figure 6: Type of Service field
As such, the ECN field defines four codepoints:
+-----------+-----------+
| ECN field | Codepoint |
+-----------+-----------+
| 00 | Not-ECT |
+-----------+-----------+
| 01 | ECT(1) |
+-----------+-----------+
| 10 | ECT(0) |
+-----------+-----------+
| 11 | CE |
+-----------+-----------+
Table 3: ECN codepoints +----------+----------------------------------------------+
| Bits 0-2 | Precedence |
+----------+----------------------------------------------+
| Bit 3 | 0 = Normal Delay, 1 = Low Delay |
+----------+----------------------------------------------+
| Bit 4 | 0 = Normal Throughput, 1 = High Throughput |
+----------+----------------------------------------------+
| Bit 5 | 0 = Normal Reliability, 1 = High Reliability |
+----------+----------------------------------------------+
| Bit 6 | 0 = Normal Cost, 1 = Minimize Monetary Cost |
+----------+----------------------------------------------+
| Bits 7 | Reserved for Future Use (must be zero) |
+----------+----------------------------------------------+
The security implications of ECN are discussed in detail in a number Table 2: TOS bits
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 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 | 111 | Network Control |
ECN-capable. Consequently, when experiencing moderate congestion, +-----+-----------------+
routers using active queue management based on RED would mark the | 110 | Internetwork |
packets (with the CE codepoint) rather than discard them. In the +-----+-----------------+
same scenario, packets of competing flows that do not have the ECT | 101 | CRITIC/ECP |
codepoint set would be dropped. Therefore, an attacker would get +-----+-----------------+
better network service than the competing flows. | 100 | Flash Override |
+-----+-----------------+
| 011 | Flash |
+-----+-----------------+
| 010 | Immediate |
+-----+-----------------+
| 001 | Priority |
+-----+-----------------+
| 000 | Routine |
+-----+-----------------+
However, if this moderate congestion turned into heavy congestion, Table 3: Precedence field
routers should switch to drop packets, regardless of whether the
packets have the ECT codepoint set or not.
A number of other threats could arise if an attacker was a man in the The Type of Service field can be used to affect the way in which the
middle (i.e., was in the middle of the path the packets travel to get packet is treated by the systems of a network that process it.
to the destination host). For a detailed discussion of those cases, Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3
we urge the reader to consult Section 16 of RFC 3168. ("Weak TOS") of this document describe the security implications of
the Type of Service field in the forwarding of packets.
4. Internet Protocol Mechanisms 4. Internet Protocol Mechanisms
4.1. Fragment reassembly 4.1. Fragment reassembly
To accommodate networks with different Maximum Transmission Units To accommodate networks with different Maximum Transmission Units
(MTUs), the Internet Protocol provides a mechanism for the (MTUs), the Internet Protocol provides a mechanism for the
fragmentation of IP packets by end-systems (hosts) and/or fragmentation of IP packets by end-systems (hosts) and/or
intermediate systems (routers). Reassembly of fragments is performed intermediate systems (routers). Reassembly of fragments is performed
only by the end-systems. only by the end-systems.
[Cerf1974] provides the rationale for which packet reassembly is not o [Cerf1974] provides the rationale for which packet reassembly is
performed by intermediate systems. not performed by intermediate systems.
During the last few decades, IP fragmentation and reassembly has been During the last few decades, IP fragmentation and reassembly has been
exploited in a number of ways, to perform actions such as evading exploited in a number of ways, to perform actions such as evading
Network Intrusion Detection Systems (NIDS), bypassing firewall rules, Network Intrusion Detection Systems (NIDS), bypassing firewall rules,
and performing Denial of Service (DoS) attacks. and performing Denial of Service (DoS) attacks.
[Bendi1998] and [Humble1998] are examples of the exploitation of o [Bendi1998] and [Humble1998] are examples of the exploitation of
these issues for performing Denial of Service (DoS) attacks. these issues for performing Denial of Service (DoS) attacks.
[CERT1997] and [CERT1998b] document these issues. [Anderson2001] is [CERT1997] and [CERT1998b] document these issues. [Anderson2001]
a survey of fragmentation attacks. [US-CERT2001] is an example of is a survey of fragmentation attacks. [US-CERT2001] is an example
the exploitation of IP fragmentation to bypass firewall rules. of the exploitation of IP fragmentation to bypass firewall rules.
[CERT1999] describes the implementation of fragmentation attacks in [CERT1999] describes the implementation of fragmentation attacks
Distributed Denial of Service (DDoS) attack tools. in Distributed Denial of Service (DDoS) attack tools.
The problem with IP fragment reassembly basically has to do with the The problem with IP fragment reassembly basically has to do with the
complexity of the function, in a number of aspects: complexity of the function, in a number of aspects:
o Fragment reassembly is a stateful operation for a stateless o Fragment reassembly is a stateful operation for a stateless
protocol (IP). The IP module at the host performing the protocol (IP). The IP module at the host performing the
reassembly function must allocate memory buffers both for reassembly function must allocate memory buffers both for
temporarily storing the received fragments, and to perform the temporarily storing the received fragments, and to perform the
reassembly function. Attackers can exploit this fact to exhaust reassembly function. Attackers can exploit this fact to exhaust
memory buffers at the system performing the fragment reassembly. memory buffers at the system performing the fragment reassembly.
skipping to change at page 46, line 34 skipping to change at page 46, line 15
o The fragment reassembly algorithm, as described by the IETF o The fragment reassembly algorithm, as described by the IETF
specifications, is ambiguous, and allows for a number of specifications, is ambiguous, and allows for a number of
interpretations, each of which has found place in different TCP/IP interpretations, each of which has found place in different TCP/IP
stack implementations. stack implementations.
o The reassembly process is somewhat complex. Fragments may arrive o The reassembly process is somewhat complex. Fragments may arrive
out of order, duplicated, overlapping each other, etc. This out of order, duplicated, overlapping each other, etc. This
complexity has lead to numerous bugs in different implementations complexity has lead to numerous bugs in different implementations
of the IP protocol. of the IP protocol.
4.1.1. Problems related with memory allocation 4.1.1. Security Implications of Fragment Reassembly
4.1.1.1. Problems related with memory allocation
When an IP datagram is received by an end-system, it will be When an IP datagram is received by an end-system, it will be
temporarily stored in system memory, until the IP module processes it temporarily stored in system memory, until the IP module processes it
and hands it to the protocol machine that corresponds to the and hands it to the protocol machine that corresponds to the
encapsulated protocol. encapsulated protocol.
In the case of fragmented IP packets, while the IP module may perform In the case of fragmented IP packets, while the IP module may perform
preliminary processing of the IP header (such as checking the header preliminary processing of the IP header (such as checking the header
for errors and processing IP options), fragments must be kept in for errors and processing IP options), fragments must be kept in
system buffers until all fragments are received and are reassembled system buffers until all fragments are received and are reassembled
skipping to change at page 47, line 11 skipping to change at page 46, line 43
amount of time that should be waited for the other fragments to amount of time that should be waited for the other fragments to
arrive. Therefore, the specifications recommend to wait for a period arrive. Therefore, the specifications recommend to wait for a period
of time that will be acceptable for virtually all the possible of time that will be acceptable for virtually all the possible
network scenarios in which the protocols might operate. network scenarios in which the protocols might operate.
Specifically, RFC 1122 [RFC1122] states that the reassembly timeout Specifically, RFC 1122 [RFC1122] states that the reassembly timeout
should be a fixed value between 60 and 120 seconds. If after waiting should be a fixed value between 60 and 120 seconds. If after waiting
for that period of time the remaining fragments have not yet arrived, for that period of time the remaining fragments have not yet arrived,
all the received fragments for the corresponding packet are all the received fragments for the corresponding packet are
discarded. discarded.
The original IP Specification, RFC 791 [RFC0791], states that systems o The original IP Specification, RFC 791 [RFC0791], states that
should wait for at least 15 seconds for the missing fragments to systems should wait for at least 15 seconds for the missing
arrive. Systems that follow the "Example Reassembly Procedure" fragments to arrive. Systems that follow the "Example Reassembly
described in Section 3.2 of RFC 791 may end up using a reassembly Procedure" described in Section 3.2 of RFC 791 may end up using a
timer of up to 4.25 minutes, with minimum of 15 seconds. Section reassembly timer of up to 4.25 minutes, with minimum of 15
3.3.2 ("Reassembly") of RFC 1122 corrected this advice, stating that seconds. Section 3.3.2 ("Reassembly") of RFC 1122 corrected this
the reassembly timeout should be a fixed value between 60 and 120 advice, stating that the reassembly timeout should be a fixed
seconds. value between 60 and 120 seconds.
However, the longer the system waits for the missing fragments to However, the longer the system waits for the missing fragments to
arrive, the longer the corresponding system resources must be tied to arrive, the longer the corresponding system resources must be tied to
the corresponding packet. The amount of system memory is finite, and the corresponding packet. The amount of system memory is finite, and
even with today's systems, it can still be considered a scarce even with today's systems, it can still be considered a scarce
resource. resource.
An attacker could take advantage of the uncomfortable situation the An attacker could take advantage of the uncomfortable situation the
system performing fragment reassembly is in, by sending forged system performing fragment reassembly is in, by sending forged
fragments that will never reassemble into a complete datagram. That fragments that will never reassemble into a complete datagram. That
skipping to change at page 48, line 18 skipping to change at page 48, line 5
reached, all further IP packets that arrive would be discarded, reached, all further IP packets that arrive would be discarded,
until some fragments time out and free memory is available again. until some fragments time out and free memory is available again.
o If the system enforces limits on the amount memory that can be o If the system enforces limits on the amount memory that can be
allocated for the reassembly of fragments (in addition to allocated for the reassembly of fragments (in addition to
enforcing a limit for the IP module as a whole), then, when this enforcing a limit for the IP module as a whole), then, when this
limit is reached, all further fragments that arrive would be limit is reached, all further fragments that arrive would be
discarded, until some fragment(s) time out and free memory is discarded, until some fragment(s) time out and free memory is
available again. available again.
4.1.2. Problems that arise from the length of the IP Identification 4.1.1.2. Problems that arise from the length of the IP Identification
field field
The Internet Protocols are currently being used in environments that The Internet Protocols are currently being used in environments that
are quite different from the ones in which they were conceived. For are quite different from the ones in which they were conceived. For
instance, the availability of bandwidth at the time the Internet instance, the availability of bandwidth at the time the Internet
Protocol was designed was completely different from the availability Protocol was designed was completely different from the availability
of bandwidth in today's networks. of bandwidth in today's networks.
The Identification field is a 16-bit field that is used for the The Identification field is a 16-bit field that is used for the
fragmentation and reassembly function. In the event a datagram gets fragmentation and reassembly function. In the event a datagram gets
fragmented, all the corresponding fragments will share the same fragmented, all the corresponding fragments will share the same
skipping to change at page 49, line 11 skipping to change at page 48, line 46
establish a flow of fragments with different IP Identification establish a flow of fragments with different IP Identification
numbers, to trash all or part of the IP Identification space. As a numbers, to trash all or part of the IP Identification space. As a
result, the receiving system would use the attacker's fragments for result, the receiving system would use the attacker's fragments for
the reassembly of legitimate datagrams, leading to corrupted packets the reassembly of legitimate datagrams, leading to corrupted packets
which would later (and hopefully) get dropped. which would later (and hopefully) get dropped.
In most cases, use of a long fragment timeout will benefit the In most cases, use of a long fragment timeout will benefit the
attacker, as forged fragments will keep the IP Identification space attacker, as forged fragments will keep the IP Identification space
trashed for a longer period of time. trashed for a longer period of time.
4.1.3. Problems that arise from the complexity of the reassembly 4.1.1.3. Problems that arise from the complexity of the reassembly
algorithm algorithm
As IP packets can be duplicated by the network, and each packet may As IP packets can be duplicated by the network, and each packet may
take a different path to get to the destination host, fragments may take a different path to get to the destination host, fragments may
arrive not only out of order and/or duplicated, but also overlapping. arrive not only out of order and/or duplicated, but also overlapping.
This means that the reassembly process can be somewhat complex, with This means that the reassembly process can be somewhat complex, with
the corresponding implementation being not specifically trivial. the corresponding implementation being not specifically trivial.
[Shannon2001] analyzes the causes and attributes of fragment traffic [Shannon2001] analyzes the causes and attributes of fragment traffic
measured in several types of WANs. measured in several types of WANs.
During the years, a number of attacks have exploited bugs in the During the years, a number of attacks have exploited bugs in the
reassembly function of a number of operating systems, producing reassembly function of a number of operating systems, producing
buffer overflows that have led, in most cases, to a crash of the buffer overflows that have led, in most cases, to a crash of the
attacked system. attacked system.
4.1.4. Problems that arise from the ambiguity of the reassembly process 4.1.1.4. Problems that arise from the ambiguity of the reassembly
process
Network Intrusion Detection Systems (NIDSs) typically monitor the Network Intrusion Detection Systems (NIDSs) typically monitor the
traffic on a given network with the intent of identifying traffic traffic on a given network with the intent of identifying traffic
patterns that might indicate network intrusions. patterns that might indicate network intrusions.
In the presence of IP fragments, in order to detect illegitimate In the presence of IP fragments, in order to detect illegitimate
activity at the transport or application layers (i.e., any protocol activity at the transport or application layers (i.e., any protocol
layer above the network layer), a NIDS must perform IP fragment layer above the network layer), a NIDS must perform IP fragment
reassembly. reassembly.
skipping to change at page 50, line 30 skipping to change at page 50, line 17
As originally discussed by [Ptacek1998], these issues can be As originally discussed by [Ptacek1998], these issues can be
exploited by attackers to evade intrusion detection systems. exploited by attackers to evade intrusion detection systems.
There exist freely available tools to forcefully fragment IP There exist freely available tools to forcefully fragment IP
datagrams so as to help evade Intrusion Detection Systems. Frag datagrams so as to help evade Intrusion Detection Systems. Frag
router [Song1999] is an example of such a tool; it allows an attacker router [Song1999] is an example of such a tool; it allows an attacker
to perform all the evasion techniques described in [Ptacek1998]. to perform all the evasion techniques described in [Ptacek1998].
Ftester [Barisani2006] is a tool that helps to audit systems Ftester [Barisani2006] is a tool that helps to audit systems
regarding fragmentation issues. regarding fragmentation issues.
4.1.5. Problems that arise from the size of the IP fragments 4.1.1.5. Problems that arise from the size of the IP fragments
One approach to fragment filtering involves keeping track of the One approach to fragment filtering involves keeping track of the
results of applying filter rules to the first fragment (i.e., the results of applying filter rules to the first fragment (i.e., the
fragment with a Fragment Offset of 0), and applying them to fragment with a Fragment Offset of 0), and applying them to
subsequent fragments of the same packet. The filtering module would subsequent fragments of the same packet. The filtering module would
maintain a list of packets indexed by the Source Address, Destination maintain a list of packets indexed by the Source Address, Destination
Address, Protocol, and Identification number. When the initial Address, Protocol, and Identification number. When the initial
fragment is seen, if the MF bit is set, a list item would be fragment is seen, if the MF bit is set, a list item would be
allocated to hold the result of filter access checks. When packets allocated to hold the result of filter access checks. When packets
with a non-zero Fragment Offset come in, look up the list element with a non-zero Fragment Offset come in, look up the list element
with a matching Source Address/Destination Address/Protocol/ with a matching Source Address/Destination Address/Protocol/
Identification and apply the stored result (pass or block). When a Identification and apply the stored result (pass or block). When a
fragment with a zero MF bit is seen, free the list element. fragment with a zero MF bit is seen, free the list element.
Unfortunately, the rules of this type of packet filter can usually be Unfortunately, the rules of this type of packet filter can usually be
bypassed. [RFC1858] describes the details of the involved technique. bypassed. [RFC1858] describes the details of the involved technique.
4.1.6. Possible security improvements 4.1.2. Possible security improvements
Memory allocation for fragment reassembly 4.1.2.1. Memory allocation for fragment reassembly
A design choice usually has to be made as to how to allocate memory A design choice usually has to be made as to how to allocate memory
to reassemble the fragments of a given packet. There are basically to reassemble the fragments of a given packet. There are basically
two options: two options:
o Upon receipt of the first fragment, allocate a buffer that will be o Upon receipt of the first fragment, allocate a buffer that will be
large enough to concatenate the payload of each fragment. large enough to concatenate the payload of each fragment.
o Upon receipt of the first fragment, create the first node of a o Upon receipt of the first fragment, create the first node of a
linked list to which each of the following fragments will be linked list to which each of the following fragments will be
skipping to change at page 51, line 45 skipping to change at page 51, line 34
Furthermore, the IP module should keep a different buffer for IP Furthermore, the IP module should keep a different buffer for IP
fragments than for complete IP datagrams. This will basically fragments than for complete IP datagrams. This will basically
separate the effects of fragment attacks on non-fragmented traffic. separate the effects of fragment attacks on non-fragmented traffic.
Most TCP/IP implementations, such as that in Linux and those in BSD- Most TCP/IP implementations, such as that in Linux and those in BSD-
derived systems, already implement this. derived systems, already implement this.
[Jones2002] contains an analysis about the amount of memory that may [Jones2002] contains an analysis about the amount of memory that may
be needed for the fragment reassembly buffer depending on a number of be needed for the fragment reassembly buffer depending on a number of
network characteristics. network characteristics.
Flushing the fragment buffer 4.1.2.2. Flushing the fragment buffer
In the case of those attacks that aim to consume the memory buffers In the case of those attacks that aim to consume the memory buffers
used for fragments, and those that aim to cause a collision of IP used for fragments, and those that aim to cause a collision of IP
Identification numbers, there are a number of counter-measures that Identification numbers, there are a number of counter-measures that
can be implemented. can be implemented.
The IP module should enforce a limit on the amount of memory that can The IP module should enforce a limit on the amount of memory that can
be allocated for IP fragments, as well as a limit on the number of be allocated for IP fragments, as well as a limit on the number of
fragments that at any time will be allowed in the system. This will fragments that at any time will be allowed in the system. This will
basically limit the resources spent on the reassembly process, and basically limit the resources spent on the reassembly process, and
skipping to change at page 53, line 7 skipping to change at page 52, line 44
fragments that, when reached, triggers a fragment-buffer flush. Some fragments that, when reached, triggers a fragment-buffer flush. Some
systems flush 1/2 of the fragment buffer when the threshold is systems flush 1/2 of the fragment buffer when the threshold is
reached. As mentioned before, the idea of flushing the buffer is to reached. As mentioned before, the idea of flushing the buffer is to
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.
A more selective fragment buffer flushing strategy 4.1.2.3. A more selective fragment buffer flushing strategy
One of the difficulties in implementing counter-measures for the One of the difficulties in implementing counter-measures for the
fragmentation attacks described in this document is that it is fragmentation attacks described in this document is that it 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.
This means that we cannot enforce checks on the fragments for which o This means that we cannot enforce checks on the fragments for
we allocate reassembly resources, as the first fragment we receive which we allocate reassembly resources, as the first fragment we
for a given packet may be some other fragment than the first one (the receive for a given packet may be some other fragment than the
one with an Fragment Offset of 0). first one (the one with an Fragment Offset of 0).
However, at the point in which we decide to free some space in the However, at the point in which we decide to free some space in the
fragment buffer, some refinements can be done to the flushing policy. fragment buffer, some refinements can be done to the flushing policy.
The first thing we would like to do is to stop different types of The first thing we would like to do is to stop different types of
traffic from interfering with each other. This means, in principle, traffic from interfering with each other. This means, in principle,
that we do not want fragmented UDP traffic to interfere with that we do not want fragmented UDP traffic to interfere with
fragmented TCP traffic. In order to implement this traffic fragmented TCP traffic. In order to implement this traffic
separation for the different protocols, a different fragment buffer separation for the different protocols, a different fragment buffer
would be needed, in principle, for each of the 256 different would be needed, in principle, for each of the 256 different
protocols that can be encapsulated in an IP datagram. protocols that can be encapsulated in an IP datagram.
skipping to change at page 54, line 42 skipping to change at page 54, line 30
fragments in reverse order. In such cases, at the point of flushing fragments in reverse order. In such cases, at the point of flushing
the fragment buffer, legitimate fragments will receive the same the fragment buffer, legitimate fragments will receive the same
treatment as the possible forged fragments. treatment as the possible forged fragments.
This refined flushing policy provides an increased level of This refined flushing policy provides an increased level of
protection against this type of resource exhaustion attack, while not protection against this type of resource exhaustion attack, while not
making the situation of out-of-order IPsec-secured traffic worse than making the situation of out-of-order IPsec-secured traffic worse than
with the simplified flushing policy described in the previous with the simplified flushing policy described in the previous
section. section.
Reducing the fragment timeout 4.1.2.4. Reducing the fragment timeout
RFC 1122 [RFC1122] states that the reassembly timeout should be a RFC 1122 [RFC1122] states that the reassembly timeout should be a
fixed value between 60 and 120 seconds. The rationale behind these fixed value between 60 and 120 seconds. The rationale behind these
long timeout values is that they should accommodate any path long timeout values is that they should accommodate any path
characteristics, such as long-delay paths. However, it must be noted characteristics, such as long-delay paths. However, it must be noted
that this timer is really measuring inter-fragment delays, or, more that this timer is really measuring inter-fragment delays, or, more
specifically, fragment jitter. specifically, fragment jitter.
If all fragments take paths of similar characteristics, the inter- If all fragments take paths of similar characteristics, the inter-
fragment delay will usually be, at most, a few seconds. fragment delay will usually be, at most, a few seconds.
skipping to change at page 55, line 17 skipping to change at page 55, line 5
excessive. excessive.
Some systems have already reduced the fragment timeout to 30 seconds Some systems have already reduced the fragment timeout to 30 seconds
[Linux2006]. The fragment timeout could probably be further reduced [Linux2006]. The fragment timeout could probably be further reduced
to approximately 15 seconds; although further research on this issue to approximately 15 seconds; although further research on this issue
is necessary. is necessary.
It should be noted that in network scenarios of long-delay and high- It should be noted that in network scenarios of long-delay and high-
bandwidth (usually referred to as "Long-Fat Networks"), using a long bandwidth (usually referred to as "Long-Fat Networks"), using a long
fragment timeout would likely increase the probability of collision fragment timeout would likely increase the probability of collision
of IP ID numbers. Therefore, in such scenarios it is mandatory to of IP ID numbers. Therefore, in such scenarios it is highly
avoid the use of fragmentation with techniques such as PMTUD desirable to avoid the use of fragmentation with techniques such as
[RFC1191] or PLPMTUD [RFC4821]. PMTUD [RFC1191] or PLPMTUD [RFC4821].
Counter-measure for some IDS evasion techniques 4.1.2.5. Counter-measure for some IDS evasion techniques
[Shankar2003] introduces a technique named "Active Mapping" that [Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it. the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort [Novak2005] describes some techniques that are applied by the Snort
NIDS to avoid evasion. NIDS to avoid evasion.
Counter-measure for firewall-rules bypassing 4.1.2.6. Counter-measure for firewall-rules bypassing
One of the classical techniques to bypass firewall rules involves One of the classical techniques to bypass firewall rules involves
sending packets in which the header of the encapsulated protocol is sending packets in which the header of the encapsulated protocol is
fragmented. Even when it would be legal (as far as the IETF fragmented. Even when it would be legal (as far as the IETF
specifications are concerned) to receive such a packets, the MTUs of specifications are concerned) to receive such a packets, the MTUs of
the network technologies used in practice are not that small to the network technologies used in practice are not that small to
require the header of the encapsulated protocol to be fragmented. require the header of the encapsulated protocol to be fragmented.
Therefore, the system performing reassembly should drop all packets Therefore, the system performing reassembly should drop all packets
which fragment the upper-layer protocol header, and this event should which fragment the upper-layer protocol header, and this event should
be logged (e.g., a counter could be incremented to reflect the packet be logged (e.g., a counter could be incremented to reflect the packet
skipping to change at page 57, line 30 skipping to change at page 57, line 16
match" routes there are only routes with non-default type of services match" routes there are only routes with non-default type of services
which do not match the TOS contained in the received packet, to use a which do not match the TOS contained in the received packet, to use a
route with any other TOS. While this route would most likely not be route with any other TOS. While this route would most likely not be
able to address the type of service requested by packet, it would, at able to address the type of service requested by packet, it would, at
least, provide a "best effort" service. least, provide a "best effort" service.
It must be noted that Section 5.3.2 of RFC 1812 allows for routers It must be noted that Section 5.3.2 of RFC 1812 allows for routers
for not honoring the TOS field. Therefore, the proposed alternative for not honoring the TOS field. Therefore, the proposed alternative
behavior is still compliant with the IETF specifications. behavior is still compliant with the IETF specifications.
While officially specified in the RFC series, TOS-based routing is o While officially specified in the RFC series, TOS-based routing is
not widely deployed in the Internet. not widely deployed in the Internet.
4.2.3. Address Resolution 4.2.3. Address Resolution
In the case of broadcast link-layer technologies, in order for a In the case of broadcast link-layer technologies, in order for a
system to transfer an IP datagram it must usually first map an IP system to transfer an IP datagram it must usually first map an IP
address to the corresponding link-layer address (for example, by address to the corresponding link-layer address (for example, by
means of the ARP protocol [RFC0826]) . This means that while this means of the ARP protocol [RFC0826]) . This means that while this
operation is being performed, the packets that would require such a operation is being performed, the packets that would require such a
mapping would need to be kept in memory. This may happen both in the mapping would need to be kept in memory. This may happen both in the
case of hosts and in the case of routers. case of hosts and in the case of routers.
skipping to change at page 58, line 21 skipping to change at page 58, line 6
network service. network service.
One counter-measure to this problem would be to drop, at the point One counter-measure to this problem would be to drop, at the point
the mapping function times out all the packets destined to the the mapping function times out all the packets destined to the
address that timed out. In addition, a "negative cache entry" might address that timed out. In addition, a "negative cache entry" might
be kept in the module performing the matching function, so that for be kept in the module performing the matching function, so that for
some amount of time, the mapping function would return an error when some amount of time, the mapping function would return an error when
the IP module requests to perform a mapping for some address for the IP module requests to perform a mapping for some address for
which the mapping has recently timed out. which the mapping has recently timed out.
A common implementation strategy for routers is that when a packet is o A common implementation strategy for routers is that when a packet
received that requires an ARP request to be performed before the is received that requires an ARP request to be performed before
packet can be forwarded, the packet is dropped and the router is then the packet can be forwarded, the packet is dropped and the router
engaged in the ARP procedure. is then engaged in the ARP procedure.
4.2.4. Dropping packets 4.2.4. Dropping packets
In some scenarios, it may be necessary for a host or router to drop In some scenarios, it may be necessary for a host or router to drop
packets from the output queue. In the event one of such packets packets from the output queue. In the event one of such packets
happens to be an IP fragment, and there were other fragments of the happens to be an IP fragment, and there were other fragments of the
same packet in the queue, those other fragments should also be same packet in the queue, those other fragments should also be
dropped. The rationale for this policy is that it is nonsensical to dropped. The rationale for this policy is that it is nonsensical to
spend system resources on those other fragments, because, as long as spend system resources on those other fragments, because, as long as
one fragment is missing, it will be impossible for the receiving one fragment is missing, it will be impossible for the receiving
skipping to change at page 59, line 6 skipping to change at page 58, line 40
It is important to understand that while there are some addresses It is important to understand that while there are some addresses
that are supposed to be unreachable from the public Internet (such as that are supposed to be unreachable from the public Internet (such as
those described in RFC 1918 [RFC1918], or the "loopback" address), those described in RFC 1918 [RFC1918], or the "loopback" address),
there are a number of tricks an attacker can perform to reach those there are a number of tricks an attacker can perform to reach those
IP addresses that would otherwise be unreachable (e.g., exploit the IP addresses that would otherwise be unreachable (e.g., exploit the
LSRR or SSRR IP options). Therefore, when applicable, packet LSRR or SSRR IP options). Therefore, when applicable, packet
filtering should be performed at organizational network boundary to filtering should be performed at organizational network boundary to
assure that those addresses will be unreachable. assure that those addresses will be unreachable.
[RFC5735] provides a summary of special use IPv4 addresses.
4.3.2. Private address space 4.3.2. Private address space
The Internet Assigned Numbers Authority (IANA) has reserved the The Internet Assigned Numbers Authority (IANA) has reserved the
following three blocks of the IP address space for private internets: following three blocks of the IP address space for private internets:
o 10.0.0.0 - 10.255.255.255 (10/8 prefix) 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 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) o 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Use of these address blocks is described in RFC 1918 [RFC1918]. Use of these address blocks is described in RFC 1918 [RFC1918].
Where applicable, packet filtering should be performed at the Where applicable, packet filtering should be performed at the
organizational perimeter to assure that these addresses are not organizational perimeter to assure that these addresses are not
reachable from outside the enterprise network. reachable from outside the enterprise network.
4.3.3. Class D addresses (224/4 address block) 4.3.3. Class D addresses (224/4 address block)
skipping to change at page 60, line 39 skipping to change at page 60, line 29
4.3.7. Special Internet addresses 4.3.7. Special Internet addresses
RFC 1812 [RFC1812] discusses the use of some special internet RFC 1812 [RFC1812] discusses the use of some special internet
addresses, which is of interest to perform some sanity checks on the addresses, which is of interest to perform some sanity checks on the
Source Address and Destination Address fields of an IP packet. It Source Address and Destination Address fields of an IP packet. It
uses the following notation for an IP address: uses the following notation for an IP address:
{ <Network-prefix>, <Host-number> } { <Network-prefix>, <Host-number> }
RFC 1122 [RFC1122] contained a similar discussion of special internet o RFC 1122 [RFC1122] contained a similar discussion of special
addresses, including some of the form { <Network-prefix>, <Subnet- internet addresses, including some of the form { <Network-prefix>,
number>, <Host-number> }. However, as explained in Section 4.2.2.11 <Subnet-number>, <Host-number> }. However, as explained in
of RFC 1812, in a CIDR world, the subnet number is clearly an Section 4.2.2.11 of RFC 1812, in a CIDR world, the subnet number
extension of the network prefix and cannot be interpreted without the is clearly an extension of the network prefix and cannot be
remainder of the prefix. interpreted without the remainder of the prefix.
{0, 0} {0, 0}
This address means "this host on this network". It is meant to be This address means "this host on this network". It is meant to be
used only during the initialization procedure, by which the host used only during the initialization procedure, by which the host
learns its own IP address. learns its own IP address.
If a packet is received with 0.0.0.0 as the Source Address for any 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 purpose other than bootstrapping, the corresponding packet should be
silently dropped, and this event should be logged (e.g., a counter silently dropped, and this event should be logged (e.g., a counter
skipping to change at page 61, line 32 skipping to change at page 61, line 22
reflect the packet drop). reflect the packet drop).
{-1, -1} {-1, -1}
This address is the local broadcast address. It should not be used 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 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 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 logged (e.g., a counter could be incremented to reflect the packet
drop). drop).
Some systems, when receiving an ICMP echo request, for example, will o Some systems, when receiving an ICMP echo request, for example,
use the Destination Address in the ICMP echo request packet as the will use the Destination Address in the ICMP echo request packet
Source Address of the response they send (in this case, an ICMP echo as the Source Address of the response they send (in this case, an
reply). Thus, when such systems receive a request sent to a ICMP echo reply). Thus, when such systems receive a request sent
broadcast address, the Source Address of the response will contain a to a broadcast address, the Source Address of the response will
broadcast address. This should be considered a bug, rather than a contain a broadcast address. This should be considered a bug,
malicious use of the limited broadcast address. rather than a malicious use of the limited broadcast address.
{Network number, -1} {Network number, -1}
This is the directed broadcast to the specified network. As This is the directed broadcast to the specified network. As
recommended by RFC 2644 [RFC2644], routers should not forward recommended by RFC 2644 [RFC2644], routers should not forward
network-directed broadcasts. This avoids the corresponding network network-directed broadcasts. This avoids the corresponding network
from being utilized as, for example, a "smurf amplifier" [CERT1998a]. from being utilized as, for example, a "smurf amplifier" [CERT1998a].
As noted in Section 4.3.6 of this document, many systems now allow As noted in Section 4.3.6 of this document, many systems now allow
administrators to configure these addresses as unicast addresses for administrators to configure these addresses as unicast addresses for
skipping to change at page 62, line 16 skipping to change at page 62, line 5
address being a network-directed broadcast address, rather than a address being a network-directed broadcast address, rather than a
unicast address (e.g., that IP address is configured on the local unicast address (e.g., that IP address is configured on the local
system as a "broadcast address"). In such scenarios, if a system can system as a "broadcast address"). In such scenarios, if a system can
infer the Source Address of a received packet is a network-directed infer the Source Address of a received packet is a network-directed
broadcast address, the packet should be dropped, and this event broadcast address, the packet should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the should be logged (e.g., a counter could be incremented to reflect the
packet drop). packet drop).
As noted in Section 4.3.6 of this document, with the deployment of 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 CIDR [RFC4632], it may be difficult for a system to infer whether a
particular IP address is a broadcast address. particular IP address that does not belong to a directly attached
subnet is a broadcast address.
{127, any} {127, any}
This is the internal host loopback address. Any packet that arrives This is the internal host loopback address. Any packet that arrives
on any physical interface containing this address as the Source on any physical interface containing this address as the Source
Address, the Destination Address, or as part of a source route Address, the Destination Address, or as part of a source route
(either LSRR or SSRR), should be dropped, and this event should be (either LSRR or SSRR), 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
drop). drop).
skipping to change at page 62, line 45 skipping to change at page 62, line 35
5. Security Considerations 5. Security Considerations
This document discusses the security implications of the Internet This document discusses the security implications of the Internet
Protocol (IP), and discusses a number of implementation strategies Protocol (IP), and discusses a number of implementation strategies
that help to mitigate a number of vulnerabilities found in the that help to mitigate a number of vulnerabilities found in the
protocol during the last 25 years or so. protocol during the last 25 years or so.
6. Acknowledgements 6. Acknowledgements
The author would like to thank Andrew Yourtchenko for providing The author would like to thank Alfred Hoenes, Joel Jaeggli, Bruno
valuable comments on earlier versions of this document. 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 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 Centre for the the Internet Protocol" [CPNI2008] published by the UK Centre for the
Protection of National Infrastructure (CPNI). Protection of National Infrastructure (CPNI).
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
skipping to change at page 64, line 24 skipping to change at page 64, line 17
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", BCP 34, RFC 2644, August 1999. in Routers", BCP 34, RFC 2644, August 1999.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[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.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 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.
[Barisani2006] [Barisani2006]
Barisani, A., "FTester - Firewall and IDS testing tool", Barisani, A., "FTester - Firewall and IDS testing tool",
Available at: http://dev.inversepath.com/trac/ftester , Available at: http://dev.inversepath.com/trac/ftester ,
2001. 2001.
skipping to change at page 67, line 41 skipping to change at page 67, line 39
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.fuller-240space]
Fuller, V., "Reclassifying 240/4 as usable unicast address Fuller, V., "Reclassifying 240/4 as usable unicast address
space", draft-fuller-240space-02 (work in progress), space", draft-fuller-240space-02 (work in progress),
March 2008. March 2008.
[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-05 (work in progress), draft-ietf-tcpm-icmp-attacks-10 (work in progress),
June 2009. January 2010.
[I-D.stjohns-sipso] [I-D.stjohns-sipso]
StJohns, M., "Common Architecture Label IPv6 Security StJohns, M., "Common Architecture Label IPv6 Security
Option (CALIPSO)", draft-stjohns-sipso-11 (work in Option (CALIPSO)", draft-stjohns-sipso-11 (work in
progress), March 2009. progress), March 2009.
[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.
skipping to change at page 70, line 25 skipping to change at page 70, line 25
July 1982. July 1982.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003. (NFS) version 4 Protocol", RFC 3530, April 2003.
skipping to change at page 71, line 32 skipping to change at page 71, line 39
list http://www.kyuzz.org/antirez/papers/dumbscan.html, list http://www.kyuzz.org/antirez/papers/dumbscan.html,
1998. 1998.
[Sanfilippo1999] [Sanfilippo1999]
Sanfilippo, S., "more ip id", Post to Bugtraq mailing- Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
list http://www.kyuzz.org/antirez/papers/moreipid.html, list http://www.kyuzz.org/antirez/papers/moreipid.html,
1999. 1999.
[Shankar2003] [Shankar2003]
Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS Shankar, U. and V. Paxson, "Active Mapping: Resisting NIDS
EvasionWithout Altering Traffic", Evasion Without Altering Traffic",
http://www.icir.org/vern/papers/activemap-oak03.pdf, http://www.icir.org/vern/papers/activemap-oak03.pdf,
2003. 2003.
[Shannon2001] [Shannon2001]
Shannon, C., Moore, D., and K. Claffy, "Characteristics of Shannon, C., Moore, D., and K. Claffy, "Characteristics of
Fragmented IP Traffic on Internet Links", 2001. Fragmented IP Traffic on Internet Links", 2001.
[Silbersack2005] [Silbersack2005]
Silbersack, M., "Improving TCP/IP security through Silbersack, M., "Improving TCP/IP security through
randomization without sacrificing interoperability", randomization without sacrificing interoperability",
skipping to change at page 73, line 5 skipping to change at page 73, line 12
vulnerabilities and potential threats to IT systems especially where vulnerabilities and potential threats to IT systems especially where
they may have an impact on Critical National Infrastructure's (CNI). they may have an impact on Critical National Infrastructure's (CNI).
Other ways to contact CPNI, plus CPNI's PGP public key, are available Other ways to contact CPNI, plus CPNI's PGP public key, are available
at http://www.cpni.gov.uk . at http://www.cpni.gov.uk .
Appendix B. Changes from previous versions of the draft (to be removed Appendix B. Changes from previous versions of the draft (to be removed
by the RFC Editor before publishing this document as an by the RFC Editor before publishing this document as an
RFC) RFC)
B.1. Changes from draft-ietf-opsec-ip-security-00 B.1. 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.2. 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.2. Changes from draft-gont-opsec-ip-security-01 B.3. 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.3. Changes from draft-gont-opsec-ip-security-00 B.4. Changes from draft-gont-opsec-ip-security-00
o Fixed author's affiliation. o Fixed author's affiliation.
o Added Figure 4. o Added Figure 5.
o Fixed a few typos. o Fixed a few typos.
o (no technical changes) o (no technical changes)
Author's Address Author's Address
Fernando Gont Fernando Gont
UK Centre for the Protection of National Infrastructure UK Centre for the Protection of National Infrastructure
 End of changes. 178 change blocks. 
599 lines changed or deleted 563 lines changed or added

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