draft-ietf-opsec-ip-security-03.txt   draft-ietf-opsec-ip-security-04.txt 
Operational Security Capabilities F. Gont Operational Security Capabilities F. Gont
for IP Network Infrastructure UK CPNI for IP Network Infrastructure UK CPNI
(opsec) April 13, 2010 (opsec) October 21, 2010
Internet-Draft Internet-Draft
Intended status: Informational Intended status: Informational
Expires: October 15, 2010 Expires: April 24, 2011
Security Assessment of the Internet Protocol version 4 Security Assessment of the Internet Protocol version 4
draft-ietf-opsec-ip-security-03.txt draft-ietf-opsec-ip-security-04.txt
Abstract Abstract
This document contains a security assessment of the IETF This document contains a security assessment of the IETF
specifications of the Internet Protocol version 4, and of a number of specifications of the Internet Protocol version 4, and of a number of
mechanisms and policies in use by popular IPv4 implementations. It mechanisms and policies in use by popular IPv4 implementations. It
is based on the results of a project carried out by the UK's Centre is based on the results of a project carried out by the UK's Centre
for the Protection of National Infrastructure (CPNI). for the Protection of National Infrastructure (CPNI).
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2010. This Internet-Draft will expire on April 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 43 skipping to change at page 3, line 43
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 . . . . . . . . . . . . . . . 51
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 . . . . . . . . . . . . . . . . . . . . 53
4.1.2. Possible security improvements . . . . . . . . . . . . 53 4.1.2. Possible security improvements . . . . . . . . . . . . 53
4.1.2.1. Memory allocation for fragment reassembly . . . . 53 4.1.2.1. Memory allocation for fragment reassembly . . . . 53
4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 54 4.1.2.2. Flushing the fragment buffer . . . . . . . . . . 54
4.1.2.3. A more selective fragment buffer flushing 4.1.2.3. A more selective fragment buffer flushing
strategy . . . . . . . . . . . . . . . . . . . . 55 strategy . . . . . . . . . . . . . . . . . . . . 55
4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 57 4.1.2.4. Reducing the fragment timeout . . . . . . . . . . 57
4.1.2.5. countermeasure for some IDS evasion techniques . 57 4.1.2.5. Countermeasure for some IDS evasion techniques . 57
4.1.2.6. countermeasure for firewall-rules bypassing . . . 57 4.1.2.6. Countermeasure for firewall-rules bypassing . . . 57
4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 58 4.2. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.1. Precedence-ordered queue service . . . . . . . . . . . 58 4.2.1. Precedence-ordered queue service . . . . . . . . . . . 58
4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 59 4.2.2. Weak Type of Service . . . . . . . . . . . . . . . . . 59
4.2.3. Impact of Address Resolution on Buffer Management . . 59 4.2.3. Impact of Address Resolution on Buffer Management . . 59
4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 60 4.2.4. Dropping packets . . . . . . . . . . . . . . . . . . . 60
4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 60 4.3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 61 4.3.1. Unreachable addresses . . . . . . . . . . . . . . . . 61
4.3.2. Private address space . . . . . . . . . . . . . . . . 61 4.3.2. Private address space . . . . . . . . . . . . . . . . 61
4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 61 4.3.3. Former Class D Addresses (224/4 Address Block) . . . . 61
4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62 4.3.4. Former Class E Addresses (240/4 Address Block) . . . . 62
skipping to change at page 4, line 17 skipping to change at page 4, line 17
Connection-Oriented Protocols . . . . . . . . . . . . 62 Connection-Oriented Protocols . . . . . . . . . . . . 62
4.3.6. Broadcast and network addresses . . . . . . . . . . . 62 4.3.6. Broadcast and network addresses . . . . . . . . . . . 62
4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62 4.3.7. Special Internet addresses . . . . . . . . . . . . . . 62
5. Security Considerations . . . . . . . . . . . . . . . . . . . 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 65
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 65
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1. Normative References . . . . . . . . . . . . . . . . . . . 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 65
7.2. Informative References . . . . . . . . . . . . . . . . . . 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. Advice and guidance to vendors . . . . . . . . . . . 76 Appendix A. Advice and guidance to vendors . . . . . . . . . . . 76
Appendix B. Changes from previous versions of the draft . . . . . 76 Appendix B. Changes from previous versions of the draft . . . . . 76
B.1. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76 B.1. Changes from draft-ietf-opsec-ip-security-03 . . . . . . . 76
B.2. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76 B.2. Changes from draft-ietf-opsec-ip-security-02 . . . . . . . 76
B.3. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77 B.3. Changes from draft-ietf-opsec-ip-security-01 . . . . . . . 76
B.4. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77 B.4. Changes from draft-ietf-opsec-ip-security-00 . . . . . . . 77
B.5. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77 B.5. Changes from draft-gont-opsec-ip-security-01 . . . . . . . 77
B.6. Changes from draft-gont-opsec-ip-security-00 . . . . . . . 77
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 77
1. Preface 1. Preface
1.1. Introduction 1.1. Introduction
The TCP/IP protocols were conceived in an environment that was quite The TCP/IP protocols were conceived in an environment that was quite
different from the hostile environment they currently operate in. different from the hostile environment in which they currently
However, the effectiveness of the protocols led to their early operate. However, the effectiveness of the protocols led to their
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.
While many textbooks and articles have created the myth that the While many textbooks and articles have created the myth that the
Internet protocols were designed for warfare environments, the top Internet protocols were designed for warfare environments, the top
level goal for the DARPA Internet Program was the sharing of large level goal for the DARPA Internet Program was the sharing of large
service machines on the ARPANET [Clark1988]. As a result, many service machines on the ARPANET [Clark1988]. As a result, many
protocol specifications focus only on the operational aspects of the protocol specifications focus only on the operational aspects of the
protocols they specify, and overlook their security implications. protocols they specify, and overlook their security implications.
While the Internet technology evolved since its inception, the While the Internet technology evolved since its inception, the
skipping to change at page 7, line 49 skipping to change at page 7, line 49
to IP" (63 pages). to IP" (63 pages).
o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet o RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet
Address Assignment and Aggregation Plan" (27 pages). Address Assignment and Aggregation Plan" (27 pages).
1.3. Organization of this document 1.3. Organization of this document
This document is basically organized in two parts: "Internet Protocol This document is basically organized in two parts: "Internet Protocol
header fields" and "Internet Protocol mechanisms". The former header fields" and "Internet Protocol mechanisms". The former
contains an analysis of each of the fields of the Internet Protocol contains an analysis of each of the fields of the Internet Protocol
header, identifies their security implications, and discusses the header, identifies their security implications, and discusses
possible countermeasures. The latter contains an analysis of the possible countermeasures for the identified threats. The latter
security implications of the mechanisms implemented by the Internet contains an analysis of the security implications of the mechanisms
Protocol. implemented by the Internet Protocol.
2. The Internet Protocol 2. The Internet Protocol
The Internet Protocol (IP) provides a basic data transfer function The Internet Protocol (IP) provides a basic data transfer function
for passing data blocks called "datagrams" from a source host to a for passing data blocks called "datagrams" from a source host to a
destination host, across the possible intervening networks. destination host, across the possible intervening networks.
Additionally, it provides some functions that are useful for the Additionally, it provides some functions that are useful for the
interconnection of heterogeneous networks, such as fragmentation and interconnection of heterogeneous networks, such as fragmentation and
reassembly. reassembly.
skipping to change at page 10, line 9 skipping to change at page 10, line 9
module, it does so based on a "Protocol Type" field in the data-link module, it does so based on a "Protocol Type" field in the data-link
packet header. packet header.
In theory, different versions of IP could coexist on a network by In theory, different versions of IP could coexist on a network by
using the same "Protocol Type" at the Link-layer, but a different using the same "Protocol Type" at the Link-layer, but a different
value in the Version field of the IP header. Thus, a single IP value in the Version field of the IP header. Thus, a single IP
module could handle all versions of the Internet Protocol, module could handle all versions of the Internet Protocol,
differentiating them by means of this field. differentiating them by means of this field.
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" (EtherType) number in the link-layer different "Protocol Type" (e.g., "EtherType" in the case of Ethernet)
protocol header. For example, IPv4 datagrams are encapsulated in number in the link-layer protocol header. For example, IPv4
Ethernet frames using an EtherType of 0x0800, while IPv6 datagrams datagrams are encapsulated in Ethernet frames using an EtherType of
are encapsulated in Ethernet frames using an EtherType of 0x86DD 0x0800, while IPv6 datagrams are encapsulated in Ethernet frames
[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).
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
skipping to change at page 12, line 41 skipping to change at page 12, line 41
Figure 3: Revised Structure of the Type of Service Field (RFC 2474) Figure 3: Revised Structure of the Type of Service Field (RFC 2474)
The DSCP ("Differentiated Services CodePoint") is used to select the The DSCP ("Differentiated Services CodePoint") is used to select the
treatment the packet is to receive within the Differentiated Services treatment the packet is to receive within the Differentiated Services
Domain. The CU ("Currently Unused") field was, at the time the Domain. The CU ("Currently Unused") field was, at the time the
specification was issued, reserved for future use. The DSCP field is specification was issued, reserved for future use. The DSCP field is
used to select a PHB (Per-Hop Behavior), by matching against the used to select a PHB (Per-Hop Behavior), by matching against the
entire 6-bit field. entire 6-bit field.
Considering that the DSCP field determines how a packet is treated Considering that the DSCP field determines how a packet is treated
within a DS domain, an attacker could send packets with a forged DSCP within a Differentiated Services (DS) domain, an attacker could send
field to perform a theft of service or even a Denial-of-Service packets with a forged DSCP field to perform a theft of service or
attack. In particular, an attacker could forge packets with a even a Denial-of-Service attack. In particular, an attacker could
codepoint of the type '11x000' which, according to Section 4.2.2.2 of forge packets with a codepoint of the type '11x000' which, according
RFC 2474 [RFC2474], would give the packets preferential forwarding to Section 4.2.2.2 of RFC 2474 [RFC2474], would give the packets
treatment when compared with the PHB selected by the codepoint preferential forwarding treatment when compared with the PHB selected
'000000'. If strict priority queuing were utilized, a continuous by the codepoint '000000'. If strict priority queuing were utilized,
stream of such packets could cause a Denial of Service to other flows a continuous stream of such packets could cause a Denial of Service
which have a DSCP of lower relative order. to other flows which have a 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.3.2.2. Explicit Congestion Notification (ECN) 3.3.2.2. Explicit Congestion Notification (ECN)
skipping to change at page 17, line 40 skipping to change at page 17, line 40
While in theory a pseudo-random number generator could lead to While in theory a pseudo-random number generator could lead to
scenarios in which a given Identification number is used more than scenarios in which a given Identification number is used more than
once in the same time-span for datagrams that end up getting once in the same time-span for datagrams that end up getting
fragmented (with the corresponding potential reassembly problems), in fragmented (with the corresponding potential reassembly problems), in
practice this is unlikely to cause trouble. practice this is unlikely to cause trouble.
By default, most implementations of connection-oriented protocols, By default, most implementations of connection-oriented protocols,
such as TCP, implement some mechanism for avoiding fragmentation such as TCP, implement some mechanism for avoiding fragmentation
(such as the Path-MTU Discovery mechanism described in [RFC1191]). (such as the Path-MTU Discovery mechanism described in [RFC1191]).
Thus, fragmentation will only take place sporadically, when a non- Thus, fragmentation will only take place if a non-RFC-compliant
RFC-compliant middle-box is placed somewhere along the path that the middle-box that still fragments packets even when the DF bit is set
packets travel to get to the destination host. Once the sending is placed somewhere along the path that the packets travel to get to
system is signaled by the middle-box that it should reduce the size the destination host. Once the sending system is signaled by the
of the packets it sends, fragmentation would be avoided. Also, for middle-box (by means of an ICMP "fragmentation needed and DF bit set"
reassembly problems to arise, the same Identification value would error message) that it should reduce the size of the packets it
need to be reused very frequently, and either strong packet sends, fragmentation would be avoided. Also, for reassembly problems
reordering or packet loss would need to take place. to arise, the same Identification value would need to be reused very
frequently, and either strong packet reordering or packet loss would
need to take place.
Nevertheless, regardless of what policy is used for selecting the Nevertheless, regardless of what policy is used for selecting the
Identification field, with the current link speeds fragmentation is Identification field, with the current link speeds fragmentation is
already bad enough to rely on it. A mechanism for avoiding already bad enough (i.e., very likely to lead to fragment reassembly
fragmentation (such as [RFC1191] or [RFC4821] should be implemented, errors) to rely on it. A mechanism for avoiding fragmentation (such
instead. as [RFC1191] or [RFC4821] should be implemented, instead.
3.5.2.2. Connectionless Transport Protocols 3.5.2.2. Connectionless Transport Protocols
Connectionless transport protocols often have these characteristics: Connectionless transport protocols often have these characteristics:
o lack of flow-control mechanisms, o lack of flow-control mechanisms,
o lack of packet sequencing mechanisms, and/or, o lack of packet sequencing mechanisms, and/or,
o lack of reliability mechanisms (such as "timeout and retransmit"). o lack of reliability mechanisms (such as "timeout and retransmit").
skipping to change at page 19, line 4 skipping to change at page 19, line 6
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. Probably the only
application that may benefit from disabling the checksum is application that may benefit from disabling the checksum is
streaming media, to avoid dropping a complete sample for a single- streaming media, to avoid dropping a complete sample for a single-
bit error. bit error.
In general, if IP Identification number collisions become an issue In general, if IP Identification number collisions become an issue
for the application using the connection-less protocol, then use of a for the application using the connection-less protocol, the
different transport protocol (which hopefully avoids fragmentation) application designers should consider using a different transport
should be considered. 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
be dropped by the transport protocol, or would incorrectly be handed be dropped by the transport protocol, or would incorrectly be handed
to the corresponding application. This issue is discussed in detail to the corresponding application. This issue is discussed in detail
in section 4.1 ("Fragment Reassembly"). in section 4.1 ("Fragment Reassembly").
3.6. Flags 3.6. Flags
skipping to change at page 23, line 17 skipping to change at page 23, line 17
Most systems allow the administrator to configure the TTL to be used Most systems allow the administrator to configure the TTL to be used
for the packets they originate, with the default value usually being for the packets they originate, with the default value usually being
a power of 2, or 255 (see e.g. [Arkin2000]). The recommended value a power of 2, or 255 (see e.g. [Arkin2000]). The recommended value
for the TTL field, as specified by the IANA is 64 [IANA2006b]. This for the TTL field, as specified by the IANA is 64 [IANA2006b]. This
value reflects the assumed "diameter" of the Internet, plus a margin value reflects the assumed "diameter" of the Internet, plus a margin
to accommodate its growth. to accommodate its growth.
The TTL field has a number of properties that are interesting from a The TTL field has a number of properties that are interesting from a
security point of view. Given that the default value used for the security point of view. Given that the default value used for the
TTL is usually a power of two or 255, chances are that, unless the TTL is usually either a power of two, or 255, chances are that unless
originating system has been explicitly tuned to use a non-default the originating system has been explicitly tuned to use a non-default
value, if a packet arrives with a TTL of 60, the packet was value, if a packet arrives with a TTL of 60, the packet was
originally sent with a TTL of 64. In the same way, if a packet is originally sent with a TTL of 64. In the same way, if a packet is
received with a TTL of 120, chances are that the original packet had received with a TTL of 120, chances are that the original packet had
a TTL of 128. a TTL of 128.
This discussion assumes there was no protocol scrubber, This discussion assumes there was no protocol scrubber,
transparent proxy, or some other middle-box that overwrites the transparent proxy, or some other middle-box that overwrites the
TTL field in a non-standard way, between the originating system TTL field in a non-standard way, between the originating system
and the point of the network in which the packet was received. and the point of the network in which the packet was received.
Asserting the TTL with which a packet was originally sent by the Determining the TTL with which a packet was originally sent by the
source system can help to obtain valuable information. Among other source system can help to obtain valuable information. Among other
things, it may help in: things, it may help in:
o Fingerprinting the originating operating system. o Fingerprinting the originating operating system.
o Fingerprinting the originating physical device. o Fingerprinting the originating physical device.
o Mapping the network topology. o Mapping the network topology.
o Locating the source host in the network topology. o Locating the source host in the network topology.
skipping to change at page 28, line 27 skipping to change at page 28, line 27
internet datagram. The Protocol field may not only contain a value internet datagram. The Protocol field may not only contain a value
corresponding to a protocol implemented by the system processing the corresponding to a protocol implemented by the system processing the
packet, but also a value corresponding to a protocol not implemented, packet, but also a value corresponding to a protocol not implemented,
or even a value not yet assigned by the IANA [IANA2006c]. or even a value not yet assigned by the IANA [IANA2006c].
While in theory there should not be security implications from the While in theory there should not be security implications from the
use of any value in the protocol field, there have been security use of any value in the protocol field, there have been security
issues in the past with systems that had problems when handling issues in the past with systems that had problems when handling
packets with some specific protocol numbers [Cisco2003] [CERT2003]. packets with some specific protocol numbers [Cisco2003] [CERT2003].
A host (i.e., end-system) that receives an IP packet encapsulating a
Protocol it does not support should drop the corresponding packet,
log the event, and possibly send an ICMP Protocol Unreachable (type
3, code 2) error message.
3.10. Header Checksum 3.10. Header Checksum
The Header Checksum field is an error detection mechanism meant to The Header Checksum field is an error detection mechanism meant to
detect errors in the IP header. While in principle there should not detect errors in the IP header. While in principle there should not
be security implications arising from this field, it should be noted be security implications arising from this field, it should be noted
that due to non-RFC-compliant implementations, the Header Checksum that due to non-RFC-compliant implementations, the Header Checksum
might be exploited to detect firewalls and/or evade network intrusion might be exploited to detect firewalls and/or evade network intrusion
detection systems (NIDS). detection systems (NIDS).
[Ed3f2002] describes the exploitation of the TCP checksum for [Ed3f2002] describes the exploitation of the TCP checksum for
skipping to change at page 38, line 49 skipping to change at page 38, line 49
drop). drop).
[Microsoft1999] is a security advisory about a vulnerability [Microsoft1999] is a security advisory about a vulnerability
arising from improper validation of the SSRR.Pointer field. arising from improper validation of the SSRR.Pointer field.
If the option is not empty, and the address in the Destination If the option is not empty, and the address in the Destination
Address field has been reached, the next address in the source route Address field has been reached, the next address in the source route
replaces the address in the Destination Address field, and the IP replaces the address in the Destination Address field, and the IP
address of the interface that will be used to forward this datagram address of the interface that will be used to forward this datagram
is recorded in its place in the source route (SSRR.Data field). is recorded in its place in the source route (SSRR.Data field).
Then, the SSRR.Pointer. is incremented by 4. Then, the SSRR.Pointer is incremented by 4.
Note that the sanity checks for the SSRR.Length and the Note that the sanity checks for the SSRR.Length and the
SSRR.Pointer fields described above ensure that if the option is SSRR.Pointer fields described above ensure that if the option is
not empty, there will be (4*n) octets in the option. That is, not empty, there will be (4*n) octets in the option. That is,
there will be at least one IP address to read, and enough room to there will be at least one IP address to read, and enough room to
record the IP address of the interface that will be used to record the IP address of the interface that will be used to
forward this datagram. forward this datagram.
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
skipping to change at page 40, line 15 skipping to change at page 40, line 15
RR.Pointer should then incremented by 4. RR.Pointer should then incremented by 4.
This option is not copied on fragmentation, and thus appears in the This option is not copied on fragmentation, and thus appears in the
first fragment only. If a fragment other than the one with offset 0 first fragment only. If a fragment other than the one with offset 0
contains the Record Route option, it should be dropped, and this contains the Record Route option, it should be dropped, and this
event should be logged (e.g., a counter could be incremented to event should be logged (e.g., a counter could be incremented to
reflect the packet drop). reflect the packet drop).
The Record Route option can be exploited to learn about the topology The Record Route option can be exploited to learn about the topology
of a network. However, the limited space in the IP header limits the of a network. However, the limited space in the IP header limits the
usefulness of this option for that purpose. usefulness of this option for that purpose if the target network is
several hops away.
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 must be ignored by the processing option is obsolete. Therefore, it must be ignored by the processing
systems. systems.
skipping to change at page 57, line 32 skipping to change at page 57, line 32
to approximately 15 seconds; although further research on this issue to approximately 15 seconds; although further research on this issue
is necessary. is necessary.
It should be noted that in network scenarios of long-delay and high- It should be noted that in network scenarios of long-delay and high-
bandwidth (usually referred to as "Long-Fat Networks"), using a long bandwidth (usually referred to as "Long-Fat Networks"), using a long
fragment timeout would likely increase the probability of collision fragment timeout would likely increase the probability of collision
of IP ID numbers. Therefore, in such scenarios it is highly of IP ID numbers. Therefore, in such scenarios it is highly
desirable to avoid the use of fragmentation with techniques such as desirable to avoid the use of fragmentation with techniques such as
PMTUD [RFC1191] or PLPMTUD [RFC4821]. PMTUD [RFC1191] or PLPMTUD [RFC4821].
4.1.2.5. countermeasure for some IDS evasion techniques 4.1.2.5. Countermeasure for some IDS evasion techniques
[Shankar2003] introduces a technique named "Active Mapping" that [Shankar2003] introduces a technique named "Active Mapping" that
prevents evasion of a NIDS by acquiring sufficient knowledge about prevents evasion of a NIDS by acquiring sufficient knowledge about
the network being monitored, to assess which packets will arrive at the network being monitored, to assess which packets will arrive at
the intended recipient, and how they will be interpreted by it. the intended recipient, and how they will be interpreted by it.
[Novak2005] describes some techniques that are applied by the Snort [Novak2005] describes some techniques that are applied by the Snort
NIDS to avoid evasion. NIDS to avoid evasion.
4.1.2.6. countermeasure for firewall-rules bypassing 4.1.2.6. Countermeasure for firewall-rules bypassing
One of the classical techniques to bypass firewall rules involves One of the classical techniques to bypass firewall rules involves
sending packets in which the header of the encapsulated protocol is sending packets in which the header of the encapsulated protocol is
fragmented. Even when it would be legal (as far as the IETF fragmented. Even when it would be legal (as far as the IETF
specifications are concerned) to receive such a packets, the MTUs of specifications are concerned) to receive such a packets, the MTUs of
the network technologies used in practice are not that small to the network technologies used in practice are not that small to
require the header of the encapsulated protocol to be fragmented. require the header of the encapsulated protocol to be fragmented.
Therefore, the system performing reassembly should drop all packets Therefore, the system performing reassembly should drop all packets
which fragment the upper-layer protocol header, and this event should which fragment the upper-layer protocol header, and this event should
be logged (e.g., a counter could be incremented to reflect the packet be logged (e.g., a counter could be incremented to reflect the packet
skipping to change at page 65, line 20 skipping to change at page 65, line 20
Protocol (IP) and a number of implementation strategies that help to Protocol (IP) and a number of implementation strategies that help to
mitigate a number of vulnerabilities found in the protocol during the mitigate a number of vulnerabilities found in the protocol during the
last 25 years or so. last 25 years or so.
6. Acknowledgements 6. Acknowledgements
The author wishes to thank Alfred Hoenes for providing very thorough The author wishes to thank Alfred Hoenes for providing very thorough
reviews of earlier versions of this document, thus leading to reviews of earlier versions of this document, thus leading to
numerous improvements. numerous improvements.
The author would like to thank Joel Jaeggli, Bruno Rohee, and Andrew The author would like to thank Joel Jaeggli, Warren Kumari, Bruno
Yourtchenko for providing valuable comments on earlier versions of Rohee, and Andrew Yourtchenko for providing valuable comments on
this document. earlier versions of this document.
This document was written by Fernando Gont on behalf of the UK CPNI This document was written by Fernando Gont on behalf of the UK CPNI
(United Kingdom's Centre for the Protection of National (United Kingdom's Centre for the Protection of National
Infrastructure), and is heavily based on the "Security Assessment of Infrastructure), and is heavily based on the "Security Assessment of
the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008. the Internet Protocol" [CPNI2008] published by the UK CPNI in 2008.
The author would like to thank Randall Atkinson, John Day, Juan The author would like to thank Randall Atkinson, John Day, Juan
Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka Fraschini, Roque Gagliano, Guillermo Gont, Martin Marino, Pekka
Savola, and Christos Zoulas for providing valuable comments on Savola, and Christos Zoulas for providing valuable comments on
earlier versions of [CPNI2008], on which this document is based. earlier versions of [CPNI2008], on which this document is based.
skipping to change at page 76, line 27 skipping to change at page 76, line 27
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 Appendix B. Changes from previous versions of the draft
This whole appendix should be removed by the RFC Editor before This whole appendix should be removed by the RFC Editor before
publishing this document as an RFC. publishing this document as an RFC.
B.1. Changes from draft-ietf-opsec-ip-security-02 B.1. Changes from draft-ietf-opsec-ip-security-03
o Addresses feedback received off-list by Warren Kumari.
B.2. Changes from draft-ietf-opsec-ip-security-02
o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Addresses a very thorough review by Alfred Hoenes (sent off-list)
o Miscellaneous edits (centers expressions, fills missing graphics o Miscellaneous edits (centers expressions, fills missing graphics
with ASCII-art, etc.) with ASCII-art, etc.)
B.2. Changes from draft-ietf-opsec-ip-security-01 B.3. Changes from draft-ietf-opsec-ip-security-01
o Addresses rest of the feedback received from Andrew Yourtchenko o Addresses rest of the feedback received from Andrew Yourtchenko
(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)
o Addresses a very thorough review by Alfred Hoenes (sent off-list) o Addresses a very thorough review by Alfred Hoenes (sent off-list)
o Addresses feedback submitted by Joel Jaeggli (off-list) o Addresses feedback submitted by Joel Jaeggli (off-list)
o Addresses feedback submitted (off-list) by Bruno Rohee. o Addresses feedback submitted (off-list) by Bruno Rohee.
o Miscellaneous edits (centers expressions, fills missing graphics o Miscellaneous edits (centers expressions, fills missing graphics
with ASCII-art, etc.) with ASCII-art, etc.)
B.3. Changes from draft-ietf-opsec-ip-security-00 B.4. Changes from draft-ietf-opsec-ip-security-00
o Addresses part of the feedback received from Andrew Yourtchenko o Addresses part of the feedback received from Andrew Yourtchenko
(http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html) (http://www.ietf.org/mail-archive/web/opsec/current/msg00417.html)
B.4. Changes from draft-gont-opsec-ip-security-01 B.5. 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.5. Changes from draft-gont-opsec-ip-security-00 B.6. Changes from draft-gont-opsec-ip-security-00
o Fixed author's affiliation. o Fixed author's affiliation.
o Added Figure 6. o Added Figure 6.
o Fixed a few typos. o Fixed a few typos.
o (no technical changes) o (no technical changes)
Author's Address Author's Address
 End of changes. 26 change blocks. 
61 lines changed or deleted 74 lines changed or added

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