draft-ietf-opsec-ip-security-00.txt   draft-ietf-opsec-ip-security-01.txt 
Operational Security Capabilities F. Gont Operational Security Capabilities F. Gont
for IP Network Infrastructure UK CPNI for IP Network Infrastructure UK CPNI
(opsec) January 29, 2009 (opsec) August 20, 2009
Internet-Draft Internet-Draft
Intended status: Informational Intended status: Informational
Expires: August 2, 2009 Expires: February 21, 2010
Security Assessment of the Internet Protocol version 4 Security Assessment of the Internet Protocol version 4
draft-ietf-opsec-ip-security-00.txt draft-ietf-opsec-ip-security-01.txt
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 34
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 August 2, 2009. This Internet-Draft will expire on February 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document contains a security assessment of the IETF This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations. It mechanisms and policies in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI). for the Protection of National Infrastructure (CPNI).
Table of Contents Table of Contents
skipping to change at page 2, line 26 skipping to change at page 2, line 22
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 6
1.3. Organization of this document . . . . . . . . . . . . . . 6 1.3. Organization of this document . . . . . . . . . . . . . . 6
2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 6
3. Internet Protocol header fields . . . . . . . . . . . . . . . 7 3. Internet Protocol header fields . . . . . . . . . . . . . . . 7
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 8
3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 11
3.5.1. Some workarounds implemented by the industry . . . . . 11 3.5.1. Some workarounds implemented by the industry . . . . . 12
3.5.2. Possible security improvements . . . . . . . . . . . . 12 3.5.2. Possible security improvements . . . . . . . . . . . . 12
3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 15 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 16
3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 16 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 17
3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 22 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 22
3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 22 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 22
3.12. Destination Address . . . . . . . . . . . . . . . . . . . 23 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 23
3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.13.1. General issues with IP options . . . . . . . . . . . . 24 3.13.1. General issues with IP options . . . . . . . . . . . . 24
3.13.1.1. Processing requirements . . . . . . . . . . . . . 24 3.13.1.1. Processing requirements . . . . . . . . . . . . . 24
3.13.1.2. Processing of the options by the upper layer 3.13.1.2. Processing of the options by the upper layer
protocol . . . . . . . . . . . . . . . . . . . . 25 protocol . . . . . . . . . . . . . . . . . . . . 25
3.13.1.3. General sanity checks on IP options . . . . . . . 25 3.13.1.3. General sanity checks on IP options . . . . . . . 25
3.13.2. Issues with specific options . . . . . . . . . . . . . 27 3.13.2. Issues with specific options . . . . . . . . . . . . . 27
3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 27 3.13.2.1. End of Option List (Type = 0) . . . . . . . . . . 27
3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27 3.13.2.2. No Operation (Type = 1) . . . . . . . . . . . . . 27
3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27 3.13.2.3. Loose Source Record Route (LSRR) (Type = 131) . . 27
3.13.2.4. Strict Source and Record Route (SSRR) (Type = 3.13.2.4. Strict Source and Record Route (SSRR) (Type =
137) . . . . . . . . . . . . . . . . . . . . . . 30 137) . . . . . . . . . . . . . . . . . . . . . . 30
3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 33 3.13.2.5. Record Route (Type = 7) . . . . . . . . . . . . . 34
3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 34 3.13.2.6. Stream Identifier (Type = 136) . . . . . . . . . 35
3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 35 3.13.2.7. Internet Timestamp (Type = 68) . . . . . . . . . 36
3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 38 3.13.2.8. Router Alert (Type = 148) . . . . . . . . . . . . 39
3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 38 3.13.2.9. Probe MTU (Type =11) . . . . . . . . . . . . . . 40
3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 38 3.13.2.10. Reply MTU (Type = 12) . . . . . . . . . . . . . . 40
3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 39 3.13.2.11. Traceroute (Type = 82) . . . . . . . . . . . . . 40
3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 39 3.13.2.12. DoD Basic Security Option (Type = 130) . . . . . 40
3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 40 3.13.2.13. DoD Extended Security Option (Type = 133) . . . . 41
3.13.2.14. Commercial IP Security Option (CIPSO) (Type = 3.13.2.14. Commercial IP Security Option (CIPSO) (Type =
134) . . . . . . . . . . . . . . . . . . . . . . 40 134) . . . . . . . . . . . . . . . . . . . . . . 42
3.13.2.15. Sender Directed Multi-Destination Delivery 3.13.2.15. Sender Directed Multi-Destination Delivery
(Type = 149) . . . . . . . . . . . . . . . . . . 41 (Type = 149) . . . . . . . . . . . . . . . . . . 43
3.14. Differentiated Services field . . . . . . . . . . . . . . 41 3.14. Differentiated Services field . . . . . . . . . . . . . . 43
3.15. Explicit Congestion Notification (ECN)</t> . . . . . . . . 42 3.15. Explicit Congestion Notification (ECN) . . . . . . . . . . 44
4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 44 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 45
4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 44 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 45
4.1.1. Problems related with memory allocation . . . . . . . 45 4.1.1. Problems related with memory allocation . . . . . . . 46
4.1.2. Problems that arise from the length of the IP 4.1.2. Problems that arise from the length of the IP
Identification field . . . . . . . . . . . . . . . . . 46 Identification field . . . . . . . . . . . . . . . . . 48
4.1.3. Problems that arise from the complexity of the 4.1.3. Problems that arise from the complexity of the
reassembly algorithm . . . . . . . . . . . . . . . . . 47 reassembly algorithm . . . . . . . . . . . . . . . . . 49
4.1.4. Problems that arise from the ambiguity of the 4.1.4. Problems that arise from the ambiguity of the
reassembly process . . . . . . . . . . . . . . . . . . 48 reassembly process . . . . . . . . . . . . . . . . . . 49
4.1.5. Problems that arise from the size of the IP 4.1.5. Problems that arise from the size of the IP
fragments . . . . . . . . . . . . . . . . . . . . . . 49 fragments . . . . . . . . . . . . . . . . . . . . . . 50
4.1.6. Possible security improvements . . . . . . . . . . . . 49 4.1.6. Possible security improvements . . . . . . . . . . . . 50
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 54 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 56
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 55 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 57
4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 56 4.2.3. Address Resolution . . . . . . . . . . . . . . . . . . 57
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 57 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 58
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 57 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 57 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 58
4.3.2. Private address space . . . . . . . . . . . . . . . . 57 4.3.2. Private address space . . . . . . . . . . . . . . . . 59
4.3.3. Class D addresses (224/4 address block) . . . . . . . 58 4.3.3. Class D addresses (224/4 address block) . . . . . . . 59
4.3.4. Class E addresses (240/4 address block) . . . . . . . 58 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 . . . . . . . . . . . . 58 connection-oriented protocols . . . . . . . . . . . . 60
4.3.6. Broadcast and network addresses . . . . . . . . . . . 58 4.3.6. Broadcast and network addresses . . . . . . . . . . . 60
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 59 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 60
5. Security Considerations . . . . . . . . . . . . . . . . . . . 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 62
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Normative References . . . . . . . . . . . . . . . . . . . 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 63
7.2. Informative References . . . . . . . . . . . . . . . . . . 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 64
Appendix A. Advice and guidance to vendors . . . . . . . . . . . 70 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) . . . . . . . . . . . . . . 71 this document as an RFC) . . . . . . . . . . . . . . 73
B.1. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 71 B.1. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 73
B.2. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 71 B.2. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 73
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 71 B.3. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 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
extent, the current world's economy depends on them. extent, the current world's economy depends on them.
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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. 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
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
This is a 4-bit field that indicates the version of the Internet This is a 4-bit field that indicates the version of the Internet
Protocol (IP), and thus the syntax of the packet. For IPv4, this Protocol (IP), and thus the syntax of the packet. For IPv4, this
field must be 4. field must be 4.
skipping to change at page 8, line 33 skipping to change at page 8, line 35
However, in practice different versions of IP are identified by a However, in practice different versions of IP are identified by a
different "Protocol Type" number in the link-layer protocol header. different "Protocol Type" number in the link-layer protocol header.
For example, IPv4 datagrams are encapsulated in Ethernet frames using For example, IPv4 datagrams are encapsulated in Ethernet frames using
a "Protocol Type" field of 0x0800, while IPv6 datagrams are a "Protocol Type" field of 0x0800, while IPv6 datagrams are
encapsulated in Ethernet frames using a "Protocol Type" field of encapsulated in Ethernet frames using a "Protocol Type" field of
0x86DD [IANA2006a]. 0x86DD [IANA2006a].
Therefore, if an IPv4 module receives a packet, the Version field Therefore, if an IPv4 module receives a packet, the Version field
must be checked to be 4. If this check fails, the packet should be must be checked to be 4. If this check fails, the packet should be
silently dropped. silently dropped, and this event should be logged (e.g., a counter
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
this event should be logged (e.g., a counter could be incremented
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
this event should be logged (e.g., a counter could be incremented
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. TOS
Figure 2 shows the syntax of the Type of Service field, defined by Figure 2 shows the syntax of the Type of Service field, defined by
RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349]. RFC 791 [RFC0791], and updated by RFC 1349 [RFC1349].
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 11, line 8 skipping to change at page 11, line 28
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. As the If this check fails, the IP packet should be dropped, and this event
previous expression implies, the number of bytes passed by the link- should be logged (e.g., a counter could be incremented reflecting the
layer to the IP module should contain at least as many bytes as packet drop). As the previous expression implies, the number of
claimed by the Total Length field of the IP header. 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
header.
[US-CERT2002] is an example of the exploitation of a forged IP Total [US-CERT2002] is an example of the exploitation of a forged IP Total
Length field to produce an information leakage attack. Length field to produce an information leakage attack.
3.5. Identification (ID) 3.5. 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}.
skipping to change at page 16, line 9 skipping to change at page 16, line 27
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. 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
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. To detect such a case, the following check should be dropped, and this event should be logged (e.g., a counter could be
enforced on all packets for which the Fragment Offset contains a non- incremented reflecting the packet drop). To detect such a case, the
zero value: following check should be enforced on all packets for which the
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 Such a datagram would result when the first fragment has a Fragment
Offset of 0 and a Total Length of 65532, and the second (and last) Offset of 0 and a Total Length of 65532, and the second (and last)
fragment has a Fragment Offset of 8189 (65512 bytes), and a Total fragment has a Fragment Offset of 8189 (65512 bytes), and a Total
Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20 Length of 65535. Assuming an IHL of 5 (i.e., a header length of 20
skipping to change at page 25, line 31 skipping to change at page 25, line 31
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.13.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. dropped, and this event should be logged (e.g., a counter could be
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
a invalid value in a field, such as the cases discussed in the a invalid value in a field, such as the cases discussed in the
following subsections. Sending such a message might help in following subsections. Sending such a message might help in
debugging some network problems. However, it would also alert debugging some network problems. However, it would also alert
attackers about the system that is dropping packets because of the attackers about the system that is dropping packets because of the
invalid values in the protocol fields. invalid values in the protocol fields.
We advice that systems default to sending an ICMP "Parameter Problem" We advice that systems default to sending an ICMP "Parameter Problem"
skipping to change at page 26, line 32 skipping to change at page 26, line 33
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. should be dropped, and this event should be logged (e.g., a counter
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
values that might make an option overlap with the IP payload. This values that might make an option overlap with the IP payload. This
would be particularly dangerous for those IP options which request would be particularly dangerous for those IP options which request
the processing systems to write information into the option-data area the processing systems to write information into the option-data area
(such as the Record Route option), as it would allow the generation (such as the Record Route option), as it would allow the generation
of overflows. of overflows.
Data types Data types
skipping to change at page 28, line 19 skipping to change at page 28, line 19
This is the IPv4-version of the IPv6 amplification attack that was 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 that
the maximum length of the IPv4 header (and hence the LSRR option) the maximum length of the IPv4 header (and hence the LSRR option)
limits the amplification factor when compared to the IPv6 counter- limits the amplification factor when compared to the IPv6 counter-
part. 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. However, they should provide a system-wide toggle to enable option, and should log this event (e.g., a counter could be
support for this option for those scenarios in which this option is incremented to reflect the packet drop). However, they should
required. Such system-wide toggle should default to "off" (or provide a system-wide toggle to enable support for this option for
"disable"). those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").
[OpenBSD1998] is a security advisory about an improper implementation [OpenBSD1998] is a security advisory about an improper implementation
of such a system-wide in 4.4BSD kernels. of such a system-wide 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
given packet. Thus, if a packet is found to have more than one LSRR given packet. Thus, if a packet is found to have more than one LSRR
option, it should be dropped. Therefore, hosts and routers should option, it should be dropped, and this event should be logged (e.g.,
discard packets that contain more than one LSRR option. a counter could be incremented to reflect the packet drop).
Additionally, if a packet were found to have both LSRR and SSRR Therefore, hosts and routers should discard packets that contain more
options, it should be dropped. than one LSRR option. Additionally, if a packet were found to have
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
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. 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 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. 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 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. If the packet does not pass this check, it should be dropped, and
Additionally, the Pointer field should be a multiple of 4. this event should be logged (e.g., a counter could be incremented to
Consequently, the following check should be performed: reflect the packet drop). Additionally, the Pointer field should be
a multiple of 4. Consequently, the following check should be
performed:
LSRR.Pointer % 4 == 0 LSRR.Pointer % 4 == 0
If a packet does not pass this check, it should be dropped. 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).
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.
skipping to change at page 29, line 48 skipping to change at page 30, line 13
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. should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).
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 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.
skipping to change at page 31, line 10 skipping to change at page 31, line 24
widely publicized in 2007 [Biondi2007]. The only difference is that widely publicized in 2007 [Biondi2007]. The only difference is that
the maximum length for the IPv4 header (and hence the SSRR option) the maximum length for the IPv4 header (and hence the SSRR option)
limits the amplification factor when compared to the IPv6 counter- limits the amplification factor when compared to the IPv6 counter-
part. part.
While the SSSR option may be of help in debugging some network While the SSSR option may be of help in debugging some network
problems, its security implications outweigh any legitimate use of problems, its security implications outweigh any legitimate use of
it. 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. However, they should provide a system-wide toggle to enable option, and should log this event (e.g., a counter could be
support for this option for those scenarios in which this option is incremented to reflect the packet drop). However, they should
required. Such system-wide toggle should default to "off" (or provide a system-wide toggle to enable support for this option for
"disable"). those scenarios in which this option is required. Such system-wide
toggle should default to "off" (or "disable").
[OpenBSD1998] is a security advisory about an improper implementation [OpenBSD1998] is a security advisory about an improper implementation
of such a system-wide in 4.4BSD kernels. of such a system-wide 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. there are some sanity checks that 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
given packet. Thus, if a packet is found to have more than one SSRR given packet. Thus, if a packet is found to have more than one SSRR
option, it should be dropped. Also, if a packet contains a option, it should be dropped, and this event should be logged (e.g.,
combination of SSRR and LSRR options, it should be dropped. a counter could be incremented to reflect the packet drop). Also, if
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).
As the SSRR option is meant to specify the route a packet should As the SSRR option is meant to specify the route a packet should
follow from source to destination, use of more than one SSRR option follow from source to destination, use of more than one SSRR option
in a single packet would be nonsensical. Therefore, hosts and in a single packet would be nonsensical. Therefore, hosts and
routers should check the IP header and discard the packet if it routers should check the IP header and discard the packet if it
contains more than one SSRR option, or a combination of LSRR and SSRR contains more than one SSRR option, or a combination of LSRR and SSRR
options. options.
As with many other IP options, the SSRR option contains a Length As with many other IP options, the SSRR option contains a Length
field that indicates the length of the option. Given the format of field that indicates the length of the option. Given the format of
the option, the length field should be checked to be at least 3: the option, the length field should be checked to be at least 3:
SSRR.Length >= 3 SSRR.Length >= 3
If the packet does not pass this check, it should be dropped. 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 Additionally, the following check should be performed on the length
field: field:
SSRR.Offset + SSRR.Length < IHL *4 SSRR.Offset + SSRR.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. 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 The Pointer field is relative to this option, with the minimum legal
value being 4. Therefore, the following check should be performed: value being 4. Therefore, the following check should be performed:
SSRR.Pointer >= 4 SSRR.Pointer >= 4
If the packet does not pass this check, it should be dropped. 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. Additionally, the Pointer field should be a multiple of 4.
Consequently, the following check should be performed: Consequently, the following check should be performed:
SSRR.Pointer % 4 == 0 SSRR.Pointer % 4 == 0
If a packet does not pass this check, it should be dropped. 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 If the packet passes the above checks, the receiving system should
determine whether the Destination Address of the packet corresponds determine whether the Destination Address of the packet corresponds
to one of its IP addresses. If does not, it should be dropped. 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 Contrary to the IP Loose Source and Record Route (LSRR) option, the
SSRR option does not allow in the route other routers than those SSRR option does not allow in the route other routers than those
contained in the option. If the system implements the weak end- contained in the option. If the system implements the weak end-
system model, it is allowed for the system to receive a packet 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 destined to any of its IP addresses, on any of its interfaces. If
the system implements the strong end-system model, a packet destined the system implements the strong end-system model, a packet destined
to it can be received only on the interface that corresponds to the to it can be received only on the interface that corresponds to the
IP address contained in the Destination Address field [RFC1122]. 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. reached, the packet should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
[Microsoft1999] is a security advisory about a vulnerability arising [Microsoft1999] is a security advisory about a vulnerability arising
from improper validation of the SSRR.Pointer field. 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. should be dropped, and this event should be logged (e.g., a counter
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. should be dropped, and this event should be logged (e.g., a counter
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.13.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. this option, it should be dropped, and this event should be logged
(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 Given the format of the option, the Length field should be checked to
be at least 3: be at least 3:
RR.Length >= 3 RR.Length >= 3
If the packet does not pass this check, it should be dropped. 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 Additionally, the following check should be performed on the Length
field: field:
RR.Offset + RR_Length < IHL *4 RR.Offset + RR_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. 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 The pointer field is relative to this option, with the minimum legal
value being 4. Therefore, the following check should be performed: value being 4. Therefore, the following check should be performed:
RR.Pointer >= 3 RR.Pointer >= 3
If the packet does not pass this check, it should be silently If the packet does not pass this check, it should be silently
dropped. 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. Additionally, the Pointer field should be a multiple of 4.
Consequently, the following check should be performed: Consequently, the following check should be performed:
RR.Pointer % 4 == 0 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 silently dropped. considered in error, and therefore should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
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 the
option, there is not not enough space to store an IP address. It is option, there is not not enough space to store an IP address. It is
fair to assume that such an scenario will only occur when the packet fair to assume that such an scenario will only occur when the packet
has been crafted. 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. contains the Record Route option, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
3.13.2.6. Stream Identifier (Type = 136) 3.13.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. 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).
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. this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop).
3.13.2.7. Internet Timestamp (Type = 68) 3.13.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.
skipping to change at page 36, line 4 skipping to change at page 36, line 48
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.
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 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. 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 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. 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 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. 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 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.
According to RFC 791, the initial contents of the timestamp area must According to RFC 791, the initial contents of the timestamp area must
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
skipping to change at page 37, line 19 skipping to change at page 38, line 24
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. be dropped, and this event should be logged (e.g., a counter could be
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. If the If the packet does not pass this check, it should be dropped, and
packet passes this check, there is room for at least one 32-bit this event should be logged (e.g., a counter could be incremented to
timestamp. The system's 32-bit timestamp should be inserted at the reflect the packet drop). If the packet passes this check, there is
area pointed by the pointer byte, and the pointer byte should be room for at least one 32-bit timestamp. The system's 32-bit
incremented by four. timestamp should be inserted at the area pointed by the pointer byte,
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. If the If the packet does not pass this check, it should be dropped, and
packet does pass this check, it means there is space in the timestamp this event should be logged (e.g., a counter could be incremented to
data area to store at least one IP address plus the corresponding 32- reflect the packet drop). If the packet does pass this check, it
bit timestamp. The IP address of the system should be stored at the means there is space in the timestamp data area to store at least one
area pointed to by the pointer byte, followed by the 32-bit system IP address plus the corresponding 32-bit timestamp. The IP address
timestamp. The pointer byte should then be incremented by 8. 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
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. If it If the packet does not pass this check, it should be dropped, and
does, it means there is space in the timestamp data area to store an this event should be logged (e.g., a counter could be incremented to
IP address and store the corresponding 32-bit timestamp. The reflect the packet drop). If it does, it means there is space in the
system's timestamp should be stored at the area pointed by IT.Pointer timestamp data area to store an IP address and store the
+ 4. Then, the pointer byte should be incremented by 8. corresponding 32-bit timestamp. The system's timestamp should be
stored at the area pointed by IT.Pointer + 4. Then, the pointer byte
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.13.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
skipping to change at page 38, line 27 skipping to change at page 39, line 38
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. If the packet does not pass this check, it should be dropped, and
Furthermore, the following check should be performed on the Value this event should be logged (e.g., a counter could be incremented to
field: reflect the packet drop). Furthermore, the following check should be
performed on the Value field:
RA.Value == 0 RA.Value == 0
If the packet does not pass this check, it should be dropped. 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).
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.13.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. containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
3.13.2.10. Reply MTU (Type = 12) 3.13.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. containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
3.13.2.11. Traceroute (Type = 82) 3.13.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. containing this option should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
3.13.2.12. DoD Basic Security Option (Type = 130) 3.13.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,
skipping to change at page 39, line 49 skipping to change at page 41, line 22
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. be dropped, and this event should be logged (e.g., a counter could be
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. 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).
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 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.13.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. It should be noted that, unlike the option, it should be dropped, and this event should be logged (e.g.,
DoD Basic Security option, this option may appear multiple times in a a counter could be incremented to reflect the packet drop). It
single IP header. should be noted that, unlike the DoD Basic Security option, this
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. 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).
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.13.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
skipping to change at page 41, line 22 skipping to change at page 42, line 49
[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 [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. 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).
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.13.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. it should be dropped, and this event should be logged (e.g., a
counter could be incremented to reflect the packet drop).
3.14. Differentiated Services field 3.14. Differentiated Services field
The Differentiated Services Architecture is intended to enable The Differentiated Services Architecture is intended to enable
scalable service discrimination in the Internet without the need for scalable service discrimination in the Internet without the need for
per-flow state and signaling at every hop [RFC2475]. RFC 2474 per-flow state and signaling at every hop [RFC2475]. RFC 2474
[RFC2474] defines a Differentiated Services Field (DS Field), which [RFC2474] defines a Differentiated Services Field (DS Field), which
is intended to supersede the original Type of Service field. Figure is intended to supersede the original Type of Service field. Figure
5 shows the format of the field. 5 shows the format of the field.
skipping to change at page 42, line 37 skipping to change at page 44, line 11
DSCP of lower relative order. DSCP of lower relative order.
As the DS field is incompatible with the original Type of Service As the DS field is incompatible with the original Type of Service
field, both DS domains and networks using the original Type of field, both DS domains and networks using the original Type of
Service field should protect themselves by remarking the Service field should protect themselves by remarking the
corresponding field where appropriate, probably deploying remarking corresponding field where appropriate, probably deploying remarking
boundary nodes. Nevertheless, care must be taken so that packets boundary nodes. Nevertheless, care must be taken so that packets
received with an unrecognized DSCP do not cause the handling system received with an unrecognized DSCP do not cause the handling system
to malfunction. to malfunction.
3.15. Explicit Congestion Notification (ECN)</t> 3.15. Explicit Congestion Notification (ECN)
RFC 3168 [RFC3168] specifies a mechanism for routers to signal RFC 3168 [RFC3168] specifies a mechanism for routers to signal
congestion to hosts sending IP packets, by marking the offending congestion to hosts sending IP packets, by marking the offending
packets, rather than discarding them. RFC 3168 defines the ECN packets, rather than discarding them. RFC 3168 defines the ECN
field, which utilizes the CU unused field of the DSCP field described 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 in Section 3.14 of this document. Figure 6 shows the syntax of the
ECN field, together with the DSCP field used for Differentiated ECN field, together with the DSCP field used for Differentiated
Services. Services.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
skipping to change at page 53, line 12 skipping to change at page 54, line 30
the fragment buffer, we prefer to keep those packets on which we the fragment buffer, we prefer to keep those packets on which we
could successfully perform a number of validation checks, over those could successfully perform a number of validation checks, over those
packets on which those checks failed, or the checks could not even be packets on which those checks failed, or the checks could not even be
performed. performed.
By checking both the IPsec SPI and the IPsec sequence number, it is By checking both the IPsec SPI and the IPsec sequence number, it is
virtually impossible for an attacker that is off-path to perform a virtually impossible for an attacker that is off-path to perform a
Denial of Service attack to communication flows being protected by Denial of Service attack to communication flows being protected by
IPsec. IPsec.
Unfortunately, some TCP/IP stacks, when performing fragmentation, Unfortunately, some IP implementations (such as that in Linux
send the corresponding fragments in reverse order. In such cases, at [Linux2006]), when performing fragmentation, send the corresponding
the point of flushing the fragment buffer, legitimate fragments will fragments in reverse order. In such cases, at the point of flushing
receive the same treatment as the possible forged fragments. the fragment buffer, legitimate fragments will receive the same
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 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
skipping to change at page 54, line 20 skipping to change at page 55, line 39
Counter-measure for firewall-rules bypassing 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. The necessary which fragment the upper-layer protocol header, and this event should
information to perform this check could be stored by the IP module be logged (e.g., a counter could be incremented to reflect the packet
together with the rest of the upper-layer protocol information. drop). The necessary information to perform this check could be
stored by the IP module together with the rest of the upper-layer
protocol information.
Additionally, given that many middle-boxes such as firewalls create Additionally, given that many middle-boxes such as firewalls create
state according to the contents of the first fragment of a given state according to the contents of the first fragment of a given
packet, it is best that, in the event an end-system receives packet, it is best that, in the event an end-system receives
overlapping fragments, it honors the information contained in the overlapping fragments, it honors the information contained in the
fragment that was received first. fragment that was received first.
RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass RFC 1858 [RFC1858] describes the abuse of IP fragmentation to bypass
firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858. firewall rules. RFC 3128 [RFC3128] corrects some errors in RFC 1858.
skipping to change at page 58, line 9 skipping to change at page 59, line 27
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)
The Class D addresses correspond to the 224/4 address block, and are The Class D addresses correspond to the 224/4 address block, and are
used for Internet multicast. Therefore, if a packet is received with used for Internet multicast. Therefore, if a packet is received with
a Class D address as the Source Address, it should be dropped. a Class D address as the Source Address, it should be dropped, and
Additionally, if an IP packet with a multicast Destination Address is this event should be logged (e.g., a counter could be incremented to
received for a connection-oriented protocol (e.g., TCP), the packet reflect the packet drop). Additionally, if an IP packet with a
should be dropped. multicast Destination Address is received for a connection-oriented
protocol (e.g., TCP), the packet should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet drop).
4.3.4. Class E addresses (240/4 address block) 4.3.4. Class E addresses (240/4 address block)
The Class E addresses correspond to the 240/4 address block, and are The Class E addresses correspond to the 240/4 address block, and are
currently reserved for experimental use. As a result, a number of currently reserved for experimental use. As a result, a number of
implementations discard packets that contain a Class E address as the implementations discard packets that contain a Class E address as the
Source Address or Destination Address. Source Address or Destination Address.
However, there exists ongoing work to reclassify the Class E (240/4) However, there exists ongoing work to reclassify the Class E (240/4)
address block as usable unicast address spaces [Fuller2008a] address block as usable unicast address spaces [Fuller2008a]
skipping to change at page 58, line 37 skipping to change at page 60, line 12
It should be noted that the broadcast address 255.255.255.255 still It should be noted that the broadcast address 255.255.255.255 still
must be treated as indicated in Section 4.3.7 of this document. must be treated as indicated in Section 4.3.7 of this document.
4.3.5. Broadcast and multicast addresses, and connection-oriented 4.3.5. Broadcast and multicast addresses, and connection-oriented
protocols protocols
For connection-oriented protocols, such as TCP, shared state is For connection-oriented protocols, such as TCP, shared state is
maintained between only two endpoints at a time. Therefore, if an IP maintained between only two endpoints at a time. Therefore, if an IP
packet with a multicast (or broadcast) Destination Address is packet with a multicast (or broadcast) Destination Address is
received for a connection-oriented protocol (e.g., TCP), the packet received for a connection-oriented protocol (e.g., TCP), the packet
should be dropped. should be dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).
4.3.6. Broadcast and network addresses 4.3.6. Broadcast and network addresses
Originally, the IETF specifications did not permit IP addresses to Originally, the IETF specifications did not permit IP addresses to
have the value 0 or -1 for any of the Host number, network number, or have the value 0 or -1 for any of the Host number, network number, or
subnet number fields, except for the cases indicated in Section subnet number fields, except for the cases indicated in Section
4.3.7. However, this changed fundamentally with the deployment of 4.3.7. However, this changed fundamentally with the deployment of
Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a Classless Inter-Domain Routing (CIDR) [RFC4632], as with CIDR a
system cannot know a priori what the subnet mask is for a particular system cannot know a priori what the subnet mask is for a particular
IP address. IP address.
skipping to change at page 59, line 29 skipping to change at page 61, line 5
remainder of the prefix. 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. If a packet is received with 0.0.0.0 as the silently dropped, and this event should be logged (e.g., a counter
Destination Address, it should be silently dropped. could be incremented to reflect the packet drop). If a packet is
received with 0.0.0.0 as the Destination Address, it should be
silently dropped, and this event should be logged (e.g., a counter
could be incremented to reflect the packet drop).
{0, Host number} {0, Host number}
This address means "the specified host, in this network". As in the This address means "the specified host, in this network". As in the
previous case, it is meant to be used only during the initialization previous case, it is meant to be used only during the initialization
procedure by which the host learns its own IP address. If a packet procedure by which the host learns its own IP address. If a packet
is received with such an address as the Source Address for any is received with such an address as the Source Address for any
purpose other than bootstrapping, it should be dropped. If a packet purpose other than bootstrapping, it should be dropped, and this
is received with such an address as the Destination Address, it event should be logged (e.g., a counter could be incremented to
should be dropped. reflect the packet drop). If a packet is received with such an
address as the Destination Address, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to
reflect the packet drop).
{-1, -1} {-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. as the Source Address, it should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
Some systems, when receiving an ICMP echo request, for example, will Some systems, when receiving an ICMP echo request, for example, will
use the Destination Address in the ICMP echo request packet as the use the Destination Address in the ICMP echo request packet as the
Source Address of the response they send (in this case, an ICMP echo Source Address of the response they send (in this case, an ICMP echo
reply). Thus, when such systems receive a request sent to a reply). Thus, when such systems receive a request sent to a
broadcast address, the Source Address of the response will contain a broadcast address, the Source Address of the response will contain a
broadcast address. This should be considered a bug, rather than a broadcast address. This should be considered a bug, rather than a
malicious use of the limited broadcast address. malicious use of the limited broadcast address.
{Network number, -1} {Network number, -1}
skipping to change at page 60, line 24 skipping to change at page 62, line 10
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
network interfaces. In such scenarios, routers should forward these network interfaces. In such scenarios, routers should forward these
addresses as if they were traditional unicast addresses. addresses as if they were traditional unicast addresses.
In some scenarios a host may have knowledge about a particular IP In some scenarios a host may have knowledge about a particular IP
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. broadcast address, the packet should be dropped, and this event
should be logged (e.g., a counter could be incremented to reflect the
packet drop).
As noted in Section 4.3.6 of this document, with the deployment of 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 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. (either LSRR or SSRR), should be dropped, and this event should be
logged (e.g., a counter could be incremented to reflect the packet
drop).
For example, packets with a Destination Address in the 127.0.0.0/8 For example, packets with a Destination Address in the 127.0.0.0/8
address block that are received on an interface other than loopback address block that are received on an interface other than loopback
should be silently dropped. Packets received on any interface other should be silently dropped, and this event should be logged (e.g., a
than loopback with a Source Address corresponding to the system counter could be incremented to reflect the packet drop). Packets
receiving the packet should also be dropped. received on any interface other than loopback with a Source Address
corresponding to the system receiving the packet should also be
dropped, and this event should be logged (e.g., a counter could be
incremented to reflect the packet drop).
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
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). It is heavily based on the "Security Assessment of Infrastructure), and is heavily based on the "Security Assessment of
the Internet Protocol" [CPNI2008] released by the UK Centre for the the Internet Protocol" [CPNI2008] published by the UK Centre for the
Protection of National Infrastructure (CPNI), available at: Protection of National Infrastructure (CPNI).
http://www.cpni.gov.uk/Products/technicalnotes/3677.aspx .
The author would like to thank Randall Atkinson, John Day, Juan The author would like to thank Randall Atkinson, John Day, Juan
Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka
Savola, and Christos Zoulas for providing valuable comments on Savola, and Christos Zoulas for providing valuable comments on
earlier versions of [CPNI2008], on which this document is based. earlier versions of [CPNI2008], on which this document is based.
The author would like to thank Randall Atkinson and Roque Gagliano, The author would like to thank Randall Atkinson and Roque Gagliano,
who generously answered a number of questions. who generously answered a number of questions.
Finally, the author would like to thank UK CPNI (formerly NISCC) for Finally, the author would like to thank UK CPNI (formerly NISCC) for
skipping to change at page 64, line 49 skipping to change at page 66, line 44
configuration/guide/scfipso.html, 2003. configuration/guide/scfipso.html, 2003.
[Clark1988] [Clark1988]
Clark, D., "The Design Philosophy of the DARPA Internet Clark, D., "The Design Philosophy of the DARPA Internet
Protocols", Computer Communication Review Vol. 18, No. 4, Protocols", Computer Communication Review Vol. 18, No. 4,
1988. 1988.
[Ed3f2002] [Ed3f2002]
Ed3f, "Firewall spotting and networks analisys with a Ed3f, "Firewall spotting and networks analisys with a
broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c, broken CRC", Phrack Magazine, Volume 0x0b, Issue 0x3c,
Phile #0x0c of Phile #0x0c of 0x10 http://www.phrack.org/
0x10 http://www.phrack.org/phrack/60/p60-0x0c.txt, 2002. issues.html?issue=60&id=12&mode=txt, 2002.
[FIPS1994] [FIPS1994]
FIPS, "Standard Security Label for Information Transfer", FIPS, "Standard Security Label for Information Transfer",
Federal Information Processing Standards Publication. FIP Federal Information Processing Standards Publication. FIP
PUBS 188 http://csrc.nist.gov/publications/fips/fips188/ PUBS 188 http://csrc.nist.gov/publications/fips/fips188/
fips188.pdf, 1994. fips188.pdf, 1994.
[Fuller2008a] [Fuller2008a]
Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The Fuller, V., Lear, E., and D. Meyer, "240.0.0.0/4: The
Future Begins Now", Routing SIG Meeting, 25th APNIC Open Future Begins Now", Routing SIG Meeting, 25th APNIC Open
skipping to change at page 65, line 45 skipping to change at page 67, line 41
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-04 (work in progress), draft-ietf-tcpm-icmp-attacks-05 (work in progress),
October 2008. June 2009.
[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-06 (work in Option (CALIPSO)", draft-stjohns-sipso-11 (work in
progress), December 2008. 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.
[I-D.wilson-class-e] [I-D.wilson-class-e]
Wilson, P., Michaelson, G., and G. Huston, "Redesignation Wilson, P., Michaelson, G., and G. Huston, "Redesignation
of 240/4 from "Future Use" to "Private Use"", of 240/4 from "Future Use" to "Private Use"",
draft-wilson-class-e-02 (work in progress), draft-wilson-class-e-02 (work in progress),
skipping to change at page 71, line 10 skipping to change at page 73, line 5
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-gont-opsec-ip-security-01 B.1. Changes from draft-ietf-opsec-ip-security-00
o Addresses part of the feedback received from Andrew Yourtchenko
(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)
B.2. 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.2. Changes from draft-gont-opsec-ip-security-00 B.3. 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 4.
o Fixed a few typos. o Fixed a few typos.
o (no technical changes) o (no technical changes)
Author's Address Author's Address
 End of changes. 87 change blocks. 
178 lines changed or deleted 301 lines changed or added

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