draft-ietf-opsec-ip-security-06.txt   draft-ietf-opsec-ip-security-07.txt 
Operational Security Capabilities F. Gont Operational Security Capabilities for F. Gont
for IP Network Infrastructure UK CPNI IP Network Infrastructure (opsec) UK CPNI
(opsec) January 27, 2011 Internet-Draft April 8, 2011
Internet-Draft
Intended status: Informational Intended status: Informational
Expires: July 31, 2011 Expires: October 10, 2011
Security Assessment of the Internet Protocol version 4 Security Assessment of the Internet Protocol version 4
draft-ietf-opsec-ip-security-06.txt draft-ietf-opsec-ip-security-07.txt
Abstract Abstract
This document contains a security assessment of the IETF This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations. It mechanisms and policies in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI). for the Protection of National Infrastructure (CPNI).
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2011. This Internet-Draft will expire on October 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 13
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7 1.2. Scope of this document . . . . . . . . . . . . . . . . . . 7
1.3. Organization of this document . . . . . . . . . . . . . . 8 1.3. Organization of this document . . . . . . . . . . . . . . 8
2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8 2. The Internet Protocol . . . . . . . . . . . . . . . . . . . . 8
3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 8 3. Internet Protocol Header Fields . . . . . . . . . . . . . . . 9
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10 3.2. IHL (Internet Header Length) . . . . . . . . . . . . . . . 10
3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11 3.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11 3.3.1. Original Interpretation . . . . . . . . . . . . . . . 11
3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12 3.3.2. Standard Interpretation . . . . . . . . . . . . . . . 12
3.3.2.1. Differentiated Services field . . . . . . . . . . 12 3.3.2.1. Differentiated Services field . . . . . . . . . . 12
3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13 3.3.2.2. Explicit Congestion Notification (ECN) . . . . . 13
3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Total Length . . . . . . . . . . . . . . . . . . . . . . . 15
3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16 3.5. Identification (ID) . . . . . . . . . . . . . . . . . . . 16
3.5.1. Some Workarounds Implemented by the Industry . . . . . 16 3.5.1. Some Workarounds Implemented by the Industry . . . . . 17
3.5.2. Possible security improvements . . . . . . . . . . . . 17 3.5.2. Possible security improvements . . . . . . . . . . . . 17
3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17 3.5.2.1. Connection-Oriented Transport Protocols . . . . . 17
3.5.2.2. Connectionless Transport Protocols . . . . . . . 18 3.5.2.2. Connectionless Transport Protocols . . . . . . . 18
3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 21 3.7. Fragment Offset . . . . . . . . . . . . . . . . . . . . . 22
3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 22 3.8. Time to Live (TTL) . . . . . . . . . . . . . . . . . . . . 23
3.8.1. Fingerprinting the operating system in use by the 3.8.1. Fingerprinting the operating system in use by the
source host . . . . . . . . . . . . . . . . . . . . . 24 source host . . . . . . . . . . . . . . . . . . . . . 25
3.8.2. Fingerprinting the physical device from which the 3.8.2. Fingerprinting the physical device from which the
packets originate . . . . . . . . . . . . . . . . . . 24 packets originate . . . . . . . . . . . . . . . . . . 25
3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 24 3.8.3. Mapping the Network Topology . . . . . . . . . . . . . 25
3.8.4. Locating the source host in the network topology . . . 25 3.8.4. Locating the source host in the network topology . . . 26
3.8.5. Evading Network Intrusion Detection Systems . . . . . 26 3.8.5. Evading Network Intrusion Detection Systems . . . . . 27
3.8.6. Improving the security of applications that make 3.8.6. Improving the security of applications that make
use of the Internet Protocol (IP) . . . . . . . . . . 27 use of the Internet Protocol (IP) . . . . . . . . . . 28
3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 28 3.8.7. Limiting spread . . . . . . . . . . . . . . . . . . . 29
3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.9. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 28 3.10. Header Checksum . . . . . . . . . . . . . . . . . . . . . 29
3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 28 3.11. Source Address . . . . . . . . . . . . . . . . . . . . . . 29
3.12. Destination Address . . . . . . . . . . . . . . . . . . . 29 3.12. Destination Address . . . . . . . . . . . . . . . . . . . 30
3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.13. Options . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.13.1. General issues with IP options . . . . . . . . . . . . 31 3.13.1. General issues with IP options . . . . . . . . . . . . 32
3.13.1.1. Processing requirements . . . . . . . . . . . . . 31 3.13.1.1. Processing requirements . . . . . . . . . . . . . 32
3.13.1.2. Processing of the options by the upper layer 3.13.1.2. Processing of the options by the upper layer
protocol . . . . . . . . . . . . . . . . . . . . 32 protocol . . . . . . . . . . . . . . . . . . . . 33
3.13.1.3. General sanity checks on IP options . . . . . . . 32 3.13.1.3. General sanity checks on IP options . . . . . . . 33
3.13.2. Issues with specific options . . . . . . . . . . . . . 35
3.13.2. Issues with specific options . . . . . . . . . . . . . 34 3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 35
3.13.2.1. End of Option List (Type=0) . . . . . . . . . . . 34 3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 35
3.13.2.2. No Operation (Type=1) . . . . . . . . . . . . . . 34
3.13.2.3. Loose Source and Record Route (LSRR) 3.13.2.3. Loose Source and Record Route (LSRR)
(Type=131) . . . . . . . . . . . . . . . . . . . 34 (Type=131) . . . . . . . . . . . . . . . . . . . 35
3.13.2.4. Strict Source and Record Route (SSRR) 3.13.2.4. Strict Source and Record Route (SSRR)
(Type=137) . . . . . . . . . . . . . . . . . . . 37 (Type=137) . . . . . . . . . . . . . . . . . . . 38
3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 39 3.13.2.5. Record Route (Type=7) . . . . . . . . . . . . . . 40
3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 40 3.13.2.6. Stream Identifier (Type=136) . . . . . . . . . . 41
3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 40 3.13.2.7. Internet Timestamp (Type=68) . . . . . . . . . . 41
3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 43 3.13.2.8. Router Alert (Type=148) . . . . . . . . . . . . . 44
3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 44 3.13.2.9. Probe MTU (Type=11) (obsolete) . . . . . . . . . 45
3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 44 3.13.2.10. Reply MTU (Type=12) (obsolete) . . . . . . . . . 45
3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 44 3.13.2.11. Traceroute (Type=82) . . . . . . . . . . . . . . 45
3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 44 3.13.2.12. DoD Basic Security Option (Type=130) . . . . . . 45
3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 46 3.13.2.13. DoD Extended Security Option (Type=133) . . . . . 47
3.13.2.14. Commercial IP Security Option (CIPSO) 3.13.2.14. Commercial IP Security Option (CIPSO)
(Type=134) . . . . . . . . . . . . . . . . . . . 46 (Type=134) . . . . . . . . . . . . . . . . . . . 47
3.13.2.15. Sender Directed Multi-Destination Delivery 3.13.2.15. Sender Directed Multi-Destination Delivery
(Type=149) . . . . . . . . . . . . . . . . . . . 47 (Type=149) . . . . . . . . . . . . . . . . . . . 48
4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 47 4. Internet Protocol Mechanisms . . . . . . . . . . . . . . . . . 48
4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 47 4.1. Fragment reassembly . . . . . . . . . . . . . . . . . . . 48
4.1.1. Security Implications of Fragment Reassembly . . . . . 48 4.1.1. Security Implications of Fragment Reassembly . . . . . 49
4.1.1.1. Problems related with memory allocation . . . . . 48 4.1.1.1. Problems related with memory allocation . . . . . 49
4.1.1.2. Problems that arise from the length of the IP 4.1.1.2. Problems that arise from the length of the IP
Identification field . . . . . . . . . . . . . . 50 Identification field . . . . . . . . . . . . . . 51
4.1.1.3. Problems that arise from the complexity of 4.1.1.3. Problems that arise from the complexity of
the reassembly algorithm . . . . . . . . . . . . 51 the reassembly algorithm . . . . . . . . . . . . 52
4.1.1.4. Problems that arise from the ambiguity of the 4.1.1.4. Problems that arise from the ambiguity of the
reassembly process . . . . . . . . . . . . . . . 51 reassembly process . . . . . . . . . . . . . . . 52
4.1.1.5. Problems that arise from the size of the IP 4.1.1.5. Problems that arise from the size of the IP
fragments . . . . . . . . . . . . . . . . . . . . 53 fragments . . . . . . . . . . . . . . . . . . . . 54
4.1.2. Possible security improvements . . . . . . . . . . . . 53 4.1.2. Possible security improvements . . . . . . . . . . . . 54
4.1.2.1. Memory allocation for fragment reassembly . . . . 53 4.1.2.1. Memory allocation for fragment reassembly . . . . 54
4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 54 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 55
4.1.2.3. A more selective fragment buffer flushing 4.1.2.3. A more selective fragment buffer flushing
strategy . . . . . . . . . . . . . . . . . . . . 55 strategy . . . . . . . . . . . . . . . . . . . . 56
4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 57 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 58
4.1.2.5. Countermeasure for some IDS evasion techniques . 57 4.1.2.5. Countermeasure for some IDS evasion techniques . 58
4.1.2.6. Countermeasure for firewall-rules bypassing . . . 57 4.1.2.6. Countermeasure for firewall-rules bypassing . . . 58
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 58 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 59
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 59 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 60
4.2.3. Impact of Address Resolution on Buffer Management . . 59 4.2.3. Impact of Address Resolution on Buffer Management . . 60
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 60 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 61
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 61 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 62
4.3.2. Private address space . . . . . . . . . . . . . . . . 61 4.3.2. Private address space . . . . . . . . . . . . . . . . 62
4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 61 4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 62
4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 63
4.3.5. Broadcast/Multicast addresses, and 4.3.5. Broadcast/Multicast addresses, and
Connection-Oriented Protocols . . . . . . . . . . . . 62 Connection-Oriented Protocols . . . . . . . . . . . . 63
4.3.6. Broadcast and network addresses . . . . . . . . . . . 62 4.3.6. Broadcast and network addresses . . . . . . . . . . . 63
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 63
5. Security Considerations . . . . . . . . . . . . . . . . . . . 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 66
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.1. Normative References . . . . . . . . . . . . . . . . . . . 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 66
7.2. Informative References . . . . . . . . . . . . . . . . . . 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 68
Appendix A. Changes from previous versions of the draft . . . . . 75 Appendix A. Changes from previous versions of the draft . . . . . 76
A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 75 A.1. Changes from draft-ietf-opsec-ip-security-05 . . . . . . . 76
A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 76 A.2. Changes from draft-ietf-opsec-ip-security-04 . . . . . . . 77
A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76 A.3. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 77
A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 A.4. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 77
A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 A.5. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 77
A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 76 A.6. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77
A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 76 A.7. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77
A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 76 A.8. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 78
1. Preface 1. Preface
1.1. Introduction 1.1. Introduction
The TCP/IP protocols were conceived in an environment that was quite The TCP/IP protocols were conceived in an environment that was quite
different from the hostile environment in which they currently different from the hostile environment in which they currently
operate. However, the effectiveness of the protocols led to their operate. However, the effectiveness of the protocols led to their
early adoption in production environments, to the point that, to some early adoption in production environments, to the point that, to some
extent, the current world's economy depends on them. extent, the current world's economy depends on them.
skipping to change at page 6, line 45 skipping to change at page 6, line 45
misbehave. In most cases, the attack packet is simply malformed; in misbehave. In most cases, the attack packet is simply malformed; in
other cases, the attack packet is well-formed, but exercises a little other cases, the attack packet is well-formed, but exercises a little
used path through the IP stack. Well-designed IP implementations used path through the IP stack. Well-designed IP implementations
should protect against these attacks, and therefore this document should protect against these attacks, and therefore this document
describes a number of sanity checks that are expected to prevent most describes a number of sanity checks that are expected to prevent most
of the aforementioned "packet-of-death" attack vectors. We note that of the aforementioned "packet-of-death" attack vectors. We note that
if an IP implementation is is found vulnerable to one of these if an IP implementation is is found vulnerable to one of these
attacks, administrators must resort to mitigating them by packet attacks, administrators must resort to mitigating them by packet
filtering. filtering.
Additionally, this document analyzes the security implications from
changes in the operational environment since the Internet Protocol
was desgined. For example, it analyzes how the Internet Protocol
could be exploited to evade Network Intrusion Detection Systems
(NIDS) or to circumvent firewalls.
This document does not aim to be the final word on the security of This document does not aim to be the final word on the security of
the Internet Protocol (IP). On the contrary, it aims to raise the Internet Protocol (IP). On the contrary, it aims to raise
awareness about many security threats based on the IP protocol that awareness about many security threats based on the IP protocol that
have been faced in the past, those that we are currently facing, and have been faced in the past, those that we are currently facing, and
those we may still have to deal with in the future. It provides those we may still have to deal with in the future. It provides
advice for the secure implementation of the Internet Protocol (IP), advice for the secure implementation of the Internet Protocol (IP),
but also provides insights about the security aspects of the Internet but also provides insights about the security aspects of the Internet
Protocol that may be of help to the Internet operations community. Protocol that may be of help to the Internet operations community.
Feedback from the community is more than encouraged to help this Feedback from the community is more than encouraged to help this
skipping to change at page 10, line 18 skipping to change at page 10, line 26
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" (e.g., "EtherType" in the case of Ethernet) different "Protocol Type" (e.g., "EtherType" in the case of Ethernet)
number in the link-layer protocol header. For example, IPv4 number in the link-layer protocol header. For example, IPv4
datagrams are encapsulated in Ethernet frames using an EtherType of datagrams are encapsulated in Ethernet frames using an EtherType of
0x0800, while IPv6 datagrams are encapsulated in Ethernet frames 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames
using an EtherType of 0x86DD [IANA2006a]. using an EtherType of 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, and this event should be logged (e.g., a counter silently dropped, and this event should be logged (e.g., a counter
could be incremented reflecting the packet drop). could be incremented reflecting the packet drop). If an
implementation does not performs this check, an attacker could use a
different value for the Version field, possibly evading Network
Intrusion Detection Systems (NIDS) that decide which pattern-matching
rules to apply based on the Version field.
If the link-layer protocol employs a specific "Protocol Type" value
for encapsulating IPv4 packets (as is the case of e.g. Ethernet), a
node should check that IPv4 packets are de-multiplexed to the IPv4
module when such value was used for the "Protocol Type" field of the
link-layer protocol. If a packet does not pass this check, it should
be silently dropped.
An attacker could encapsulate IPv4 packets using other link-layer
"Protocol Type" values to try to subvert link-layer Access Control
Lists (ACLs), and/or for tampering with Network Intrusion
Detection Systems (NIDS).
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) field indicates the length of the
header in 32-bit words (4 bytes). As the minimum datagram size is 20 internet header in 32-bit words (4 bytes). The following paragraphs
bytes, the minimum legal value for this field is 5. Therefore, the decribe a number of sanity checks to be performed on the IHL field,
following check should be enforced: such that possible packet-of-death vulnerabilities are avoided.
As the minimum datagram size is 20 bytes, the minimum legal value for
this field is 5. Therefore, the following check should be enforced:
IHL >= 5 IHL >= 5
If the packet does not pass this check, it should be dropped, and If the packet does not pass this check, it should be dropped, and
this event should be logged (e.g., a counter could be incremented this event should be logged (e.g., a counter could be incremented
reflecting the packet drop). reflecting the packet drop).
For obvious reasons, the Internet header cannot be larger than the For obvious reasons, the Internet header cannot be larger than the
whole Internet datagram it is part of. Therefore, the following whole Internet datagram it is part of. Therefore, the following
check should be enforced: check should be enforced:
skipping to change at page 12, line 4 skipping to change at page 12, line 35
+-----+-----------------+ +-----+-----------------+
| 101 | CRITIC/ECP | | 101 | CRITIC/ECP |
+-----+-----------------+ +-----+-----------------+
| 100 | Flash Override | | 100 | Flash Override |
+-----+-----------------+ +-----+-----------------+
| 011 | Flash | | 011 | Flash |
+-----+-----------------+ +-----+-----------------+
| 010 | Immediate | | 010 | Immediate |
+-----+-----------------+ +-----+-----------------+
| 001 | Priority | | 001 | Priority |
+-----+-----------------+
| 000 | Routine | | 000 | Routine |
+-----+-----------------+ +-----+-----------------+
Table 2: Precedence Field Values Table 2: Precedence Field Values
The Type of Service field can be used to affect the way in which the The Type of Service field can be used to affect the way in which the
packet is treated by the systems of a network that process it. packet is treated by the systems of a network that process it.
Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3 Section 4.2.1 ("Precedence-ordered queue service") and Section 4.2.3
("Weak TOS") of this document describe the security implications of ("Weak TOS") of this document describe the security implications of
the Type of Service field in the forwarding of packets. the Type of Service field in the forwarding of packets.
skipping to change at page 19, line 11 skipping to change at page 19, line 37
result in a corrupt datagram. While some existing work result in a corrupt datagram. While some existing work
[Silbersack2005] assumes that this error would be caught by some [Silbersack2005] assumes that this error would be caught by some
upper-layer error detection code, the error detection code in upper-layer error detection code, the error detection code in
question (such as UDP's checksum) might not be able to reliably question (such as UDP's checksum) might not be able to reliably
detect data corruption arising from the replacement of a complete detect data corruption arising from the replacement of a complete
data block (as is the case in corruption arising from collision of IP data block (as is the case in corruption arising from collision of IP
Identification numbers). Identification numbers).
In the case of UDP, unfortunately some systems have been known to In the case of UDP, unfortunately some systems have been known to
not enable the UDP checksum by default. For most applications, not enable the UDP checksum by default. For most applications,
packets containing errors should be dropped. Probably the only packets containing errors should be dropped by the transport layer
application that may benefit from disabling the checksum is and not delivered to the application. A small number of
streaming media, to avoid dropping a complete sample for a single- applications may benefit from disabling the checksum; for example,
bit error. streaming media where it is desired to avoid dropping a complete
sample for a single-bit error, and UDP tunneling applications
where the payload (i.e. the inner packet) is protected by its own
transport checksum or other error detection mechanism.
In general, if IP Identification number collisions become an issue In general, if IP Identification number collisions become an issue
for the application using the connection-less protocol, the for the application using the connection-less protocol, the
application designers should consider using a different transport application designers should consider using a different transport
protocol (which hopefully avoids fragmentation). protocol (which hopefully avoids fragmentation).
It must be noted that an attacker could intentionally exploit It must be noted that an attacker could intentionally exploit
collisions of IP Identification numbers to perform a Denial-of- collisions of IP Identification numbers to perform a Denial-of-
Service attack, by sending forged fragments that would cause the Service attack, by sending forged fragments that would cause the
reassembly process to result in a corrupt datagram that would either reassembly process to result in a corrupt datagram that would either
skipping to change at page 71, line 4 skipping to change at page 72, line 4
Linux Clusters", Linux Linux Clusters", Linux
Journal http://www.linuxjournal.com/article/6943, 2004. Journal http://www.linuxjournal.com/article/6943, 2004.
[Humble1998] [Humble1998]
Humble, "Nestea exploit", Humble, "Nestea exploit",
http://www.insecure.org/sploits/linux.PalmOS.nestea.html, http://www.insecure.org/sploits/linux.PalmOS.nestea.html,
1998. 1998.
[I-D.ietf-intarea-router-alert-considerations] [I-D.ietf-intarea-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage", Faucheur, F., "IP Router Alert Considerations and Usage",
draft-ietf-intarea-router-alert-considerations-02 (work in draft-ietf-intarea-router-alert-considerations-03 (work in
progress), October 2010. progress), March 2011.
[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.
[IANA2006a] [IANA2006a]
Ether Types, Ether Types,
"http://www.iana.org/assignments/ethernet-numbers". "http://www.iana.org/assignments/ethernet-numbers".
 End of changes. 28 change blocks. 
100 lines changed or deleted 127 lines changed or added

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