draft-ietf-opsec-ip-options-filtering-06.txt   draft-ietf-opsec-ip-options-filtering-07.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) UTN-FRH / SI6 Networks IP Network Infrastructure (opsec) UTN-FRH / SI6 Networks
Internet-Draft R. Atkinson Internet-Draft R. Atkinson
Intended status: BCP Consultant Intended status: BCP Consultant
Expires: May 25, 2014 C. Pignataro Expires: June 12, 2014 C. Pignataro
Cisco Cisco
November 21, 2013 December 9, 2013
Recommendations on filtering of IPv4 packets containing IPv4 options. Recommendations on filtering of IPv4 packets containing IPv4 options.
draft-ietf-opsec-ip-options-filtering-06.txt draft-ietf-opsec-ip-options-filtering-07
Abstract Abstract
This document provides advice on the filtering of IPv4 packets based This document provides advice on the filtering of IPv4 packets based
on the IPv4 options they contain. Additionally, it discusses the on the IPv4 options they contain. Additionally, it discusses the
operational and interoperability implications of dropping packets operational and interoperability implications of dropping packets
based on the IP options they contain. based on the IP options they contain.
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 May 25, 2014. This Internet-Draft will expire on June 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Conventions Used in This Document . . . . 3 1.1. Terminology and Conventions Used in This Document . . . . 3
1.2. Operational Focus . . . . . . . . . . . . . . . . . . . . 4
2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IP Options . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Security Implications of IP options . . . . . . . . . 5 3. General Security Implications of IP options . . . . . . . . . 5
3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5 3.1. Processing Requirements . . . . . . . . . . . . . . . . . 5
4. Advice on the Handling of Packets with Specific IP Options . . 6 4. Advice on the Handling of Packets with Specific IP Options . . 7
4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7 4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 7
4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7 4.2. No Operation (Type = 1) . . . . . . . . . . . . . . . . . 7
4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8 4.3. Loose Source and Record Route (LSRR) (Type = 131) . . . . 8
4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . . 10 4.4. Strict Source and Record Route (SSRR) (Type = 137) . . . . 10
4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11 4.5. Record Route (Type = 7) . . . . . . . . . . . . . . . . . 11
4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 11 4.6. Stream Identifier (Type = 136) (obsolete) . . . . . . . . 12
4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 12 4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 13
4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 13 4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 14
4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 14 4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 15
4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 15 4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 16
4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 15 4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 16
4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 16 4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 17
4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 19 4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 20
4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 20 4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 22
4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 22 4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 23
4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 22 4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 23
4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 23 4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 24
4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 23 4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 25
4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 24 4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 25
4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 25 4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 26
4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 25 4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 27
4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 26 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 28
4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 27 4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
This document discusses the filtering of IPv4 packets based on the This document discusses the filtering of IPv4 packets based on the
IPv4 options they contain. Since various protocols may use IPv4 IPv4 options they contain. Since various protocols may use IPv4
options to some extent, dropping packets based on the options they options to some extent, dropping packets based on the options they
contain may have implications on the proper functioning of the contain may have implications on the proper functioning of the
protocol. Therefore, this document attempts to discuss the protocol. Therefore, this document attempts to discuss the
operational and interoperability implications of such dropping. operational and interoperability implications of such dropping.
Additionally, it outlines what a network operator might do in a Additionally, it outlines what a network operator might do in a
typical enterprise or Service Provider environments. typical enterprise or Service Provider environments. This document
also draws and is partly derifed from [RFC6274], which also received
review from the operational community.
We note that data seems to indicate that there is a current We note that data seems to indicate that there is a current
widespread practice of blocking IPv4 optioned packets. There are widespread practice of blocking IPv4 optioned packets. There are
various plausible approaches to minimize the potential negative various plausible approaches to minimize the potential negative
effects of IPv4 optioned packets while allowing some options effects of IPv4 optioned packets while allowing some options
semantics. One approach is to allow for specific options that are semantics. One approach is to allow for specific options that are
expected or needed, and a default deny. A different approach is to expected or needed, and a default deny. A different approach is to
deny unneeded options and a default allow. Yet a third possible deny unneeded options and a default allow. Yet a third possible
approach is to allow for end-to-end semantics by ignoring options and approach is to allow for end-to-end semantics by ignoring options and
treating packets as un-optioned while in transit. Experiments and treating packets as un-optioned while in transit. Experiments and
currently-available data tends to support the first or third currently-available data tends to support the first or third
approaches as more realistic. Some results of regarding the current approaches as more realistic. Some results of regarding the current
state of affairs with respect to dropping packets containing IP state of affairs with respect to dropping packets containing IP
options can be found in [MEDINA] [FONSECA]. options can be found in [MEDINA] [FONSECA]. Additionally,
[BREMIER-BARR] points out that the deployed Internet already has many
routers that do not process IP options.
We also note that while this document provides advice on dropping We also note that while this document provides advice on dropping
packets on a "per IP option type", not all devices (routers, security packets on a "per IP option type", not all devices (routers, security
gateways, and firewalls) may provide this capability with such gateways, and firewalls) may provide this capability with such
granularity. Additionally, even in cases in which such functionality granularity. Additionally, even in cases in which such functionality
is provided, the operator might want to specify a dropping policy is provided, the operator might want to specify a dropping policy
with a coarser granularity (rather than on a "per IP option type" with a coarser granularity (rather than on a "per IP option type"
granularity), as indicated above. granularity), as indicated above.
Finally, in scenarios in which processing of IP options by Finally, in scenarios in which processing of IP options by
skipping to change at page 4, line 9 skipping to change at page 4, line 14
Because of the security-oriented nature of this document, we are Because of the security-oriented nature of this document, we are
deliberately including some historical citations. This is deliberately including some historical citations. This is
intentional, and has the goal of explicitly retaining and showing intentional, and has the goal of explicitly retaining and showing
history, as well as removing ambiguity and confusion. history, as well as removing ambiguity and confusion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Operational Focus
All of the recommendations in this document have been made in an
effort to optimise for operational community consensus, as best the
editors have been able to determine that. This has included not only
accepting feedback from public lists, but also accepting off-list
feedback from people at various network operators (e.g. ISPs,
content providers, educational institutions, commercial firms).
2. IP Options 2. IP Options
IP options allow for the extension of the Internet Protocol. As IP options allow for the extension of the Internet Protocol. As
specified in [RFC0791], there are two cases for the format of an specified in [RFC0791], there are two cases for the format of an
option: option:
o Case 1: A single byte of option-type. o Case 1: A single byte of option-type.
o Case 2: An option-type byte, an option-length byte, and the actual o Case 2: An option-type byte, an option-length byte, and the actual
option-data bytes. option-data bytes.
skipping to change at page 10, line 5 skipping to change at page 10, line 23
4.3.5. Advice 4.3.5. Advice
Routers, security gateways, and firewalls SHOULD implement an option- Routers, security gateways, and firewalls SHOULD implement an option-
specific configuration knob whether packets with this option are specific configuration knob whether packets with this option are
dropped, packets with this IP option are forwarded as if they did not dropped, packets with this IP option are forwarded as if they did not
contain this IP option, or packets with this option are processed and contain this IP option, or packets with this option are processed and
forwarded as per [RFC0791]. The default setting for this knob SHOULD forwarded as per [RFC0791]. The default setting for this knob SHOULD
be "drop", and the default setting MUST be documented. be "drop", and the default setting MUST be documented.
Please note that treating packets with LSRR as if they did not
contain this option can result in such packets being sent to a
different device that the initially intended destination. With
appropriate ingress filtering this should not open an attack vector
into the infrastructure. Nonetheless, it could result in traffic
that would never reach the initially intended destination. Dropping
these packets prevents unnecessary network traffic, and does not make
end-to-end communication any worse.
4.4. Strict Source and Record Route (SSRR) (Type = 137) 4.4. Strict Source and Record Route (SSRR) (Type = 137)
4.4.1. Uses 4.4.1. Uses
This option allows the originating system to specify a number of This option allows the originating system to specify a number of
intermediate systems a packet must pass through to get to the intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option, and the destination host (end-system) must recorded in the option, and the destination host (end-system) must
use the reverse of the path contained in the received SSRR option. use the reverse of the path contained in the received SSRR option.
skipping to change at page 11, line 5 skipping to change at page 11, line 33
4.4.5. Advice 4.4.5. Advice
Routers, security gateways, and firewalls SHOULD implement an option- Routers, security gateways, and firewalls SHOULD implement an option-
specific configuration knob whether packets with this option are specific configuration knob whether packets with this option are
dropped, packets with this IP option are forwarded as if they did not dropped, packets with this IP option are forwarded as if they did not
contain this IP option, or packets with this option are processed and contain this IP option, or packets with this option are processed and
forwarded as per [RFC0791]. The default setting for this knob SHOULD forwarded as per [RFC0791]. The default setting for this knob SHOULD
be "drop", and the default setting MUST be documented. be "drop", and the default setting MUST be documented.
Please note that treating packets with SSRR as if they did not
contain this option can result in such packets being sent to a
different device that the initially intended destination. With
appropriate ingress filtering this should not open an attack vector
into the infrastructure. Nonetheless, it could result in traffic
that would never reach the initially intended destination. Dropping
these packets prevents unnecessary network traffic, and does not make
end-to-end communication any worse.
4.5. Record Route (Type = 7) 4.5. Record Route (Type = 7)
4.5.1. Uses 4.5.1. Uses
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.
4.5.2. Option Specification 4.5.2. Option Specification
Specified in RFC 791 [RFC0791]. Specified in RFC 791 [RFC0791].
skipping to change at page 11, line 49 skipping to change at page 12, line 38
4.6. Stream Identifier (Type = 136) (obsolete) 4.6. Stream Identifier (Type = 136) (obsolete)
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 3.2.1.8 of RFC 1122 [RFC1122] and However, as stated by Section 3.2.1.8 of RFC 1122 [RFC1122] and
Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete. Section 4.2.2.1 of RFC 1812 [RFC1812], this option is obsolete.
Therefore, it must be ignored by the processing systems. See also Therefore, it must be ignored by the processing systems. See also
Section 5. [IANA-IP] and [RFC6814].
RFC 791 states that this option appears at most once in a given RFC 791 states that this option appears at most once in a given
datagram. Therefore, if a packet contains more than one instance of datagram. Therefore, if a packet contains more than one instance of
this option, it should be dropped, and this event should be logged this option, it should be dropped, and this event should be logged
(e.g., a counter could be incremented to reflect the packet drop). (e.g., a counter could be incremented to reflect the packet drop).
4.6.1. Uses 4.6.1. Uses
This option is obsolete. There is no current use for this option. This option is obsolete. There is no current use for this option.
skipping to change at page 12, line 35 skipping to change at page 13, line 25
4.6.5. Advice 4.6.5. Advice
Routers, security gateways, and firewalls SHOULD drop IP packets Routers, security gateways, and firewalls SHOULD drop IP packets
containing a Stream Identifier option. containing a Stream Identifier option.
4.7. Internet Timestamp (Type = 68) 4.7. Internet Timestamp (Type = 68)
4.7.1. Uses 4.7.1. Uses
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. system (or a specified set of systems) processed this datagram, and
may optionally record the addresses of the systems providing the
timestamps.
4.7.2. Option Specification 4.7.2. Option Specification
Specified by RFC 791 [RFC0791]. Specified by RFC 791 [RFC0791].
4.7.3. Threats 4.7.3. Threats
The timestamp option has a number of security implications [RFC6274]. The timestamp option has a number of security implications [RFC6274].
Among them are: Among them are:
skipping to change at page 13, line 19 skipping to change at page 14, line 10
clock skew. clock skew.
[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.
4.7.4. Operational and Interoperability Impact if Blocked 4.7.4. Operational and Interoperability Impact if Blocked
None. Network troubleshooting techniques that may employ the Internet
Timestamp option (such as ping with the Timestamp option) would break
when using the Timestamp option (ping without IPv4 options is not
impacted). Nevertheless, it should be noted that it is virtually
impossible to use such techniques due to widespread dropping of
packets that contain Internet Timestamp options.
4.7.5. Advice 4.7.5. Advice
Routers, security gateways, and firewalls SHOULD drop IP packets Routers, security gateways, and firewalls SHOULD drop IP packets
containing an Internet Timestamp option. containing an Internet Timestamp option.
4.8. Router Alert (Type = 148) 4.8. Router Alert (Type = 148)
4.8.1. Uses 4.8.1. Uses
skipping to change at page 14, line 37 skipping to change at page 15, line 32
It has been declared obsolete. It has been declared obsolete.
4.9.2. Option Specification 4.9.2. Option Specification
This option was originally defined in RFC 1063 [RFC1063], and was This option was originally defined in RFC 1063 [RFC1063], and was
obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as
RFC 1191 obsoletes RFC 1063 without using IP options. RFC 1191 obsoletes RFC 1063 without using IP options.
4.9.3. Threats 4.9.3. Threats
No specific security issues are known for this IPv4 option. This option is obsolete. This option could have been exploited to
cause a host to set its PMTU estimate to an inordinately low or an
inordinately high value, thereby causing performance problems.
4.9.4. Operational and Interoperability Impact if Blocked 4.9.4. Operational and Interoperability Impact if Blocked
None None
This option is NOT employed with the modern "Path MTU Discovery" This option is NOT employed with the modern "Path MTU Discovery"
(PMTUD) mechanism [RFC1191], which employs special ICMP messages (PMTUD) mechanism [RFC1191], which employs special ICMP messages
(Type 3, Code 4) in combination with the IP DF bit. PLPMTUD (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD
[RFC4821] can perform PMTUD without the need of any special [RFC4821] can perform PMTUD without the need of any special
packets. packets.
skipping to change at page 15, line 25 skipping to change at page 16, line 20
MTU. It is now obsolete. MTU. It is now obsolete.
4.10.2. Option Specification 4.10.2. Option Specification
This option was originally defined in RFC 1063 [RFC1063], and was This option was originally defined in RFC 1063 [RFC1063], and was
obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as obsoleted with RFC 1191 [RFC1191]. This option is now obsolete, as
RFC 1191 obsoletes RFC 1063 without using IP options. RFC 1191 obsoletes RFC 1063 without using IP options.
4.10.3. Threats 4.10.3. Threats
No specific security issues are known for this IPv4 option. This option is obsolete. This option could have been exploited to
cause a host to set its PMTU estimate to an inordinately low or an
inordinately high value, thereby causing performance problems.
4.10.4. Operational and Interoperability Impact if Blocked 4.10.4. Operational and Interoperability Impact if Blocked
None None
This option is NOT employed with the modern "Path MTU Discovery" This option is NOT employed with the modern "Path MTU Discovery"
(PMTUD) mechanism [RFC1191], which employs special ICMP messages (PMTUD) mechanism [RFC1191], which employs special ICMP messages
(Type 3, Code 4) in combination with the IP DF bit. PLPMTUD (Type 3, Code 4) in combination with the IP DF bit. PLPMTUD
[RFC4821] can perform PMTUD without the need of any special [RFC4821] can perform PMTUD without the need of any special
packets. packets.
skipping to change at page 16, line 8 skipping to change at page 17, line 7
host. host.
4.11.2. Option Specification 4.11.2. Option Specification
This option was originally specified by RFC 1393 [RFC1393] as This option was originally specified by RFC 1393 [RFC1393] as
"experimental", and it was never widely deployed on the public "experimental", and it was never widely deployed on the public
Internet. This option has been formally obsoleted by [RFC6814]. Internet. This option has been formally obsoleted by [RFC6814].
4.11.3. Threats 4.11.3. Threats
No specific security issues are known for this IPv4 option. This option is obsolete. Because this option required each router in
the path both to provide special processing and to send an ICMP
message, it could have been exploited to perform a Denial of Service
(DoS) attack by exhausting CPU resources at the processing routers.
4.11.4. Operational and Interoperability Impact if Blocked 4.11.4. Operational and Interoperability Impact if Blocked
None None
4.11.5. Advice 4.11.5. Advice
Routers, security gateways, and firewalls SHOULD drop IP packets that Routers, security gateways, and firewalls SHOULD drop IP packets that
contain a Traceroute option. contain a Traceroute option.
skipping to change at page 16, line 46 skipping to change at page 17, line 48
The DoD Basic Security Option (BSO) was implemented in IRIX The DoD Basic Security Option (BSO) was implemented in IRIX
[IRIX2008] and is currently implemented in a number of operating [IRIX2008] and is currently implemented in a number of operating
systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris systems (e.g., Security-Enhanced Linux [SELinux2008], Solaris
[Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently [Solaris2008], and Cisco IOS [Cisco-IPSO]). It is also currently
deployed in a number of high-security networks. These networks are deployed in a number of high-security networks. These networks are
typically either in physically secure locations, protected by typically either in physically secure locations, protected by
military/governmental communications security equipment, or both. military/governmental communications security equipment, or both.
Such networks are typically built using commercial off-the-shelf Such networks are typically built using commercial off-the-shelf
(COTS) IP routers and Ethernet switches, but are not normally (COTS) IP routers and Ethernet switches, but are not normally
interconnected with the global public Internet. This option probably interconnected with the global public Internet. Multi-Level Secure
has more deployment now than when the IESG removed this option from (MLS) systems are much more widely deployed now than they were at the
the IETF standards-track. [RFC5570] describes a similar option time the then-IESG decided to remove IPSO (IP Security Options) from
recently defined for IPv6 and has much more detailed explanations of the IETF standards-track. Since nearly all MLS systems also support
how sensitivity label options are used in real-world deployments. IPSO BSO and IPSO ESO, this option is believed to have more
deployment now than when the IESG removed this option from the IETF
standards-track. [RFC5570] describes a similar option recently
defined for IPv6 and has much more detailed explanations of how
sensitivity label options are used in real-world deployments.
4.12.2. Option Specification 4.12.2. Option Specification
It is specified by RFC 1108 [RFC1108]], which obsoleted RFC 1038 It is specified by RFC 1108 [RFC1108]], which obsoleted RFC 1038
[RFC1038] (which in turn obsoleted the Security Option defined in RFC [RFC1038] (which in turn obsoleted the Security Option defined in RFC
791 [RFC0791]). 791 [RFC0791]).
RFC 791 [RFC0791] defined the "Security Option" (Type = 130), RFC 791 [RFC0791] defined the "Security Option" (Type = 130),
which used the same option type as the DoD Basic Security option which used the same option type as the DoD Basic Security option
discussed in this section. Later, RFC 1038 [RFC1038] revised the discussed in this section. Later, RFC 1038 [RFC1038] revised the
skipping to change at page 23, line 7 skipping to change at page 24, line 12
during the IPng efforts to address the problem of IPv4 address during the IPng efforts to address the problem of IPv4 address
exhaustion. exhaustion.
4.16.2. Option Specification 4.16.2. Option Specification
Specified in [RFC1385]. This option has been formally obsoleted by Specified in [RFC1385]. This option has been formally obsoleted by
[RFC6814]. [RFC6814].
4.16.3. Threats 4.16.3. Threats
There are no know threats arising from this option, other than the This option is obsolete. This option was used (or was intended to be
general security implications of IP options discussed in Section 3. used) to signal that a packet superficially similar to an IPv4 packet
actually containted a different protocol, opening up the possibility
that an IPv4 node that simply ignored this option would process a
received packet in a manner inconsistent with the intent of the
sender. There are no know threats arising from this option, other
than the general security implications of IP options discussed in
Section 3.
4.16.4. Operational and Interoperability Impact if Blocked 4.16.4. Operational and Interoperability Impact if Blocked
None. None.
4.16.5. Advice 4.16.5. Advice
Routers, security gateways, and firewalls SHOULD drop packets that Routers, security gateways, and firewalls SHOULD drop packets that
contain this option. contain this option.
skipping to change at page 25, line 23 skipping to change at page 26, line 38
This option was originally specified in [I-D.farinacci-bidir-pim]. This option was originally specified in [I-D.farinacci-bidir-pim].
It was never formally standardized in the RFC series, and was never It was never formally standardized in the RFC series, and was never
widely implemented and deployed. Its use was obsoleted by [RFC5015], widely implemented and deployed. Its use was obsoleted by [RFC5015],
which employs a control plane mechanism to solve the problem of doing which employs a control plane mechanism to solve the problem of doing
upstream forwarding of multicast packets on a multi-access LAN. This upstream forwarding of multicast packets on a multi-access LAN. This
option has been formally obsoleted by [RFC6814]. option has been formally obsoleted by [RFC6814].
4.20.3. Threats 4.20.3. Threats
None. This option is obsolete. A router that ignored this option instead
of processing it as specified in [I-D.farinacci-bidir-pim] could have
forwarded multicast packets to an unintended destination.
4.20.4. Operational and Interoperability Impact if Blocked 4.20.4. Operational and Interoperability Impact if Blocked
None. None.
4.20.5. Advice 4.20.5. Advice
Routers, security gateways, and firewalls SHOULD drop packets that Routers, security gateways, and firewalls SHOULD drop packets that
contain this option. contain this option.
skipping to change at page 29, line 19 skipping to change at page 30, line 36
security issues that arise from use of different IP options. Many of security issues that arise from use of different IP options. Many of
the IPv4 options listed in this document are deprecated and cause no the IPv4 options listed in this document are deprecated and cause no
operational impact if dropped. However, dropping packets containing operational impact if dropped. However, dropping packets containing
IPv4 options that are in use can cause real operational problems in IPv4 options that are in use can cause real operational problems in
deployed networks. Therefore, the practice of dropping all IPv4 deployed networks. Therefore, the practice of dropping all IPv4
packets containing one or more IPv4 options without careful packets containing one or more IPv4 options without careful
consideration is not recommended. consideration is not recommended.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Panos Kampanakis, Donald Smith, Ron The authors would like to thank (in alphabetical order) Ron Bonica,
Bonica, Arturo Servin, Merike Kaeo, SM, and Suresh Krishnan for C. M. Heard, Merike Kaeo, Panos Kampanakis, Suresh Krishnan, Arturo
providing thorough reviews and valuable comments. Merike Kaeo also Servin, SM, and Donald Smith for providing thorough reviews and
contributed text used in this document. valuable comments. Merike Kaeo also contributed text used in this
document.
The authors also wish to thank various network operations folks who
supplied feedback on earlier versions of this document, but did not
wish to be named explicitly in this document.
Part of this document is initially based on the document "Security Part of this document is initially based on the document "Security
Assessment of the Internet Protocol" [CPNI2008] that is the result of Assessment of the Internet Protocol" [CPNI2008] that is the result of
a project carried out by Fernando Gont on behalf of UK CPNI (formerly a project carried out by Fernando Gont on behalf of UK CPNI (formerly
NISCC). Fernando Gont would like to thank UK CPNI (formerly NISCC) NISCC). Fernando Gont would like to thank UK CPNI (formerly NISCC)
for their continued support. for their continued support.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 30, line 23 skipping to change at page 31, line 47
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and [RFC6398] Le Faucheur, F., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011. Usage", BCP 168, RFC 6398, October 2011.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, November 2012. Options", RFC 6814, November 2012.
8.2. Informative References 8.2. Informative References
[BREMIER-BARR]
Bremier-Barr, A. and H. Levy, "Spoofing prevention
method", Proceedings of IEEE InfoCom 2005 Volume 1, pp.
536-547, IEEE, March 2005.
[Biondi2007] [Biondi2007]
Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
CanSecWest 2007 Security Conference <http:// CanSecWest 2007 Security Conference <http://
www.secdev.org/conf/IPv6_RH_security-csw07.pdf>, 2007. www.secdev.org/conf/IPv6_RH_security-csw07.pdf>, 2007.
[CIPSOWG1994] [CIPSOWG1994]
CIPSOWG, "Commercial Internet Protocol Security Option CIPSOWG, "Commercial Internet Protocol Security Option
(CIPSO) Working Group", 1994, <http://www.ietf.org/ (CIPSO) Working Group", 1994, <http://www.ietf.org/
proceedings/94jul/charters/cipso-charter.html>. proceedings/94jul/charters/cipso-charter.html>.
 End of changes. 23 change blocks. 
50 lines changed or deleted 118 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/