draft-ietf-opsec-ip-options-filtering-05.txt   draft-ietf-opsec-ip-options-filtering-06.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: March 20, 2014 C. Pignataro Expires: May 25, 2014 C. Pignataro
Cisco Cisco
September 16, 2013 November 21, 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-05.txt draft-ietf-opsec-ip-options-filtering-06.txt
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 March 20, 2014. This Internet-Draft will expire on May 25, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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
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 . . 6
4.1. End of Option List (Type = 0) . . . . . . . . . . . . . . 6 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) . . . . 9 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) . . . . . . . . 11
4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 12 4.7. Internet Timestamp (Type = 68) . . . . . . . . . . . . . . 12
4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 13 4.8. Router Alert (Type = 148) . . . . . . . . . . . . . . . . 13
4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 14 4.9. Probe MTU (Type = 11) (obsolete) . . . . . . . . . . . . . 14
4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 15 4.10. Reply MTU (Type = 12) (obsolete) . . . . . . . . . . . . . 15
4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 15 4.11. Traceroute (Type = 82) . . . . . . . . . . . . . . . . . . 15
4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 16 4.12. DoD Basic Security Option (Type = 130) . . . . . . . . . . 16
4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 18 4.13. DoD Extended Security Option (Type = 133) . . . . . . . . 19
4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 20 4.14. Commercial IP Security Option (CIPSO) (Type = 134) . . . . 20
4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 21 4.15. VISA (Type = 142) . . . . . . . . . . . . . . . . . . . . 22
4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 22 4.16. Extended Internet Protocol (Type = 145) . . . . . . . . . 22
4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 22 4.17. Address Extension (Type = 147) . . . . . . . . . . . . . . 23
4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 23 4.18. Sender Directed Multi-Destination Delivery (Type = 149) . 23
4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 23 4.19. Dynamic Packet State (Type = 151) . . . . . . . . . . . . 24
4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 24 4.20. Upstream Multicast Pkt. (Type = 152) . . . . . . . . . . . 25
4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 25 4.21. Quick-Start (Type = 25) . . . . . . . . . . . . . . . . . 25
4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 26 4.22. RFC3692-style Experiment (Types = 30, 94, 158, and 222) . 26
4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 27 4.23. Other IP Options . . . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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].
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 may provide this packets on a "per IP option type", not all devices (routers, security
capability with such granularity. Additionally, even in cases in gateways, and firewalls) may provide this capability with such
which such functionality is provided, the operator might want to granularity. Additionally, even in cases in which such functionality
specify a dropping policy with a coarser granularity (rather than on is provided, the operator might want to specify a dropping policy
a "per IP option type" granularity), as indicated above. with a coarser granularity (rather than on a "per IP option type"
granularity), as indicated above.
Finally, in scenarios in which processing of IP options by Finally, in scenarios in which processing of IP options by
intermediate systems is not required, a widespread approach is to intermediate systems is not required, a widespread approach is to
simply ignore IP options, and process the corresponding packets as if simply ignore IP options, and process the corresponding packets as if
they do not contain any IP options. they do not contain any IP options.
1.1. Terminology and Conventions Used in This Document 1.1. Terminology and Conventions Used in This Document
The terms "fast path", "slow path", and associated relative terms The terms "fast path", "slow path", and associated relative terms
("faster path" and "slower path") are loosely defined as in Section 2 ("faster path" and "slower path") are loosely defined as in Section 2
skipping to change at page 6, line 34 skipping to change at page 6, line 34
when evaluating the operational security risks associated with a when evaluating the operational security risks associated with a
particular IP packet type or IP option type. particular IP packet type or IP option type.
Operators are urged to consider IP option filtering and IP option Operators are urged to consider IP option filtering and IP option
handling capabilities of potential IP routers as they make deployment handling capabilities of potential IP routers as they make deployment
decisions in future. decisions in future.
Additional considerations for protecting the control plane from Additional considerations for protecting the control plane from
packets containing IP Options can be found in [RFC6192]. packets containing IP Options can be found in [RFC6192].
Finally, in addition to advice to operators, this document also
provides advice to router, security gateway, and firewall
implementers in terms of providing the capability to filter packets
with different granularities: both on a "per IP option type"
granularity (to maximize flexibility) as well as more coarse filters
(to minimize configuration complexity).
4. Advice on the Handling of Packets with Specific IP Options 4. Advice on the Handling of Packets with Specific IP Options
The following subsections contain a description of each of the IP The following subsections contain a description of each of the IP
options that have so far been specified, a discussion of possible options that have so far been specified, a discussion of possible
interoperability implications if packets containing such options are interoperability implications if packets containing such options are
dropped, and specific advice on whether to drop packets containing dropped, and specific advice on whether to drop packets containing
these options in a typical enterprise or Service Provider these options in a typical enterprise or Service Provider
environment. environment.
4.1. End of Option List (Type = 0) 4.1. End of Option List (Type = 0)
skipping to change at page 8, line 7 skipping to change at page 8, line 12
Operation option. Therefore, if packets containing this option are Operation option. Therefore, if packets containing this option are
dropped, it is very likely that legitimate traffic is blocked. dropped, it is very likely that legitimate traffic is blocked.
4.2.5. Advice 4.2.5. Advice
Routers, security gateways, and firewalls SHOULD NOT drop packets Routers, security gateways, and firewalls SHOULD NOT drop packets
because they contain this option. because they contain this option.
4.3. Loose Source and Record Route (LSRR) (Type = 131) 4.3. Loose Source and Record Route (LSRR) (Type = 131)
RFC 791 states that this option should appear, at most, once in a RFC 791 states that this option should appear at most once in a given
given packet. Thus, if a packet contains more than one LSRR option, packet. Thus, if a packet contains more than one LSRR option, it
it should be dropped, and this event should be logged (e.g., a should be dropped, and this event should be logged (e.g., a counter
counter could be incremented to reflect the packet drop). could be incremented to reflect the packet drop). Additionally,
Additionally, packets containing a combination of LSRR and SSRR packets containing a combination of LSRR and SSRR options should be
options should be dropped, and this event should be logged (e.g., a dropped, and this event should be logged (e.g., a counter could be
counter could be incremented to reflect the packet drop). incremented to reflect the packet drop).
4.3.1. Uses 4.3.1. Uses
This option lets the originating system specify a number of This option lets the originating system specify a number of
intermediate systems a packet must pass through to get to the intermediate systems a packet must pass through to get to the
destination host. Additionally, the route followed by the packet is destination host. Additionally, the route followed by the packet is
recorded in the option. The receiving host (end-system) must use the recorded in the option. The receiving host (end-system) must use the
reverse of the path contained in the received LSRR option. reverse of the path contained in the received LSRR option.
The LSSR option can be of help in debugging some network problems. The LSSR option can be of help in debugging some network problems.
skipping to change at page 14, line 20 skipping to change at page 14, line 20
SHOULD be dropped. SHOULD be dropped.
A given router, security gateway, or firewall system has no way of A given router, security gateway, or firewall system has no way of
knowing a priori whether this option is valid in its operational knowing a priori whether this option is valid in its operational
environment. Therefore, routers, security gateways, and firewalls environment. Therefore, routers, security gateways, and firewalls
SHOULD, by default, ignore the Router Alert option. Additionally, SHOULD, by default, ignore the Router Alert option. Additionally,
Routers, security gateways, and firewalls SHOULD have a configuration Routers, security gateways, and firewalls SHOULD have a configuration
setting that governs their reaction in the presence of packets setting that governs their reaction in the presence of packets
containing the Router Alert option. This configuration setting containing the Router Alert option. This configuration setting
SHOULD allow to honor and process the option, ignore the option, or SHOULD allow to honor and process the option, ignore the option, or
drop packets containing this option. The default configuration is to drop packets containing this option.
ignore the Router Alert option.
4.9. Probe MTU (Type = 11) (obsolete) 4.9. Probe MTU (Type = 11) (obsolete)
4.9.1. Uses 4.9.1. Uses
This option originally provided a mechanism to discover the Path-MTU. This option originally provided a mechanism to discover the Path-MTU.
It has been declared obsolete. It has been declared obsolete.
4.9.2. Option Specification 4.9.2. Option Specification
skipping to change at page 18, line 27 skipping to change at page 18, line 27
the packet but associate an incorrect sensitivity label with the the packet but associate an incorrect sensitivity label with the
received data from the packet whose BSO was stripped by an received data from the packet whose BSO was stripped by an
intermediate router or firewall. Associating an incorrect intermediate router or firewall. Associating an incorrect
sensitivity label can cause the received information either to be sensitivity label can cause the received information either to be
handled as more sensitive than it really is ("upgrading") or as less handled as more sensitive than it really is ("upgrading") or as less
sensitive than it really is ("downgrading"), either of which is sensitive than it really is ("downgrading"), either of which is
problematic. problematic.
4.12.5. Advice 4.12.5. Advice
Routers, security gateways, and firewalls SHOULD NOT by default A given IP router, security gateway, or firewall has no way to know a
modify or remove this option from IP packets and SHOULD NOT by priori what environment it has been deployed into. Even closed IP
default drop packets because they contain this option. For auditing deployments generally use exactly the same commercial routers,
reasons, Routers, security gateways, and firewalls SHOULD be capable security gateways, and firewalls that are used in the public
of logging the numbers of packets containing the BSO on a per- Internet.
interface basis. Also, Routers, security gateways, and firewalls
SHOULD be capable of dropping packets based on the BSO presence as Since operational problems result in environments where this option
well as the BSO values. is needed if either the option is dropped or IP packets containing
this option are dropped, but no harm results if the option is carried
in environments where it is not needed, the default configuration
SHOULD NOT (a) modify or remove this IP option or (b) drop an IP
packet because the IP packet contains this option.
A given IP router, security gateway, or firewall MAY be configured to
drop this option or to drop IP packets containing this option in an
environment known to not use this option.
For auditing reasons, Routers, security gateways, and firewalls
SHOULD be capable of logging the numbers of packets containing the
BSO on a per-interface basis. Also, Routers, security gateways, and
firewalls SHOULD be capable of dropping packets based on the BSO
presence as well as the BSO values.
4.13. DoD Extended Security Option (Type = 133) 4.13. DoD Extended Security Option (Type = 133)
4.13.1. Uses 4.13.1. Uses
This option permits additional security labeling information, beyond This option permits additional security labeling information, beyond
that present in the Basic Security Option (Section 4.12), to be that present in the Basic Security Option (Section 4.12), to be
supplied in an IP datagram to meet the needs of registered supplied in an IP datagram to meet the needs of registered
authorities. authorities.
skipping to change at page 20, line 7 skipping to change at page 20, line 21
the packet but associate an incorrect sensitivity label with the the packet but associate an incorrect sensitivity label with the
received data from the packet whose ESO was stripped by an received data from the packet whose ESO was stripped by an
intermediate router or firewall. Associating an incorrect intermediate router or firewall. Associating an incorrect
sensitivity label can cause the received information either to be sensitivity label can cause the received information either to be
handled as more sensitive than it really is ("upgrading") or as less handled as more sensitive than it really is ("upgrading") or as less
sensitive than it really is ("downgrading"), either of which is sensitive than it really is ("downgrading"), either of which is
problematic. problematic.
4.13.5. Advice 4.13.5. Advice
Routers, security gateways, and firewalls SHOULD NOT by default A given IP router, security gateway, or firewall has no way to know a
modify or remove this option from IP packets and SHOULD NOT by priori what environment it has been deployed into. Even closed IP
default drop packets because they contain this option. For auditing deployments generally use exactly the same commercial routers,
reasons, Routers, security gateways, and firewalls SHOULD be capable security gateways, and firewalls that are used in the public
of logging the numbers of packets containing the ESO on a per- Internet.
interface basis. Also, Routers, security gateways, and firewalls
SHOULD be capable of dropping packets based on the ESO presence as Since operational problems result in environments where this option
well as the ESO values. is needed if either the option is dropped or IP packets containing
this option are dropped, but no harm results if the option is carried
in environments where it is not needed, the default configuration
SHOULD NOT (a) modify or remove this IP option or (b) drop an IP
packet because the IP packet contains this option.
A given IP router, security gateway, or firewall MAY be configured to
drop this option or to drop IP packets containing this option in an
environment known to not use this option.
For auditing reasons, Routers, security gateways, and firewalls
SHOULD be capable of logging the numbers of packets containing the
ESO on a per-interface basis. Also, Routers, security gateways, and
firewalls SHOULD be capable of dropping packets based on the ESO
presence as well as the ESO values.
4.14. Commercial IP Security Option (CIPSO) (Type = 134) 4.14. Commercial IP Security Option (CIPSO) (Type = 134)
4.14.1. Uses 4.14.1. Uses
This option was proposed by the Trusted Systems Interoperability This option was proposed by the Trusted Systems Interoperability
Group (TSIG), with the intent of meeting trusted networking Group (TSIG), with the intent of meeting trusted networking
requirements for the commercial trusted systems market place. requirements for the commercial trusted systems market place.
It was implemented in IRIX [IRIX2008] and is currently implemented in It was implemented in IRIX [IRIX2008] and is currently implemented in
skipping to change at page 27, line 22 skipping to change at page 27, line 49
RFC 1122: "The IP and transport layer MUST each interpret those IP RFC 1122: "The IP and transport layer MUST each interpret those IP
options that they understand and silently ignore the options that they understand and silently ignore the
others." others."
RFC 1812: "A router MUST ignore IP options which it does not RFC 1812: "A router MUST ignore IP options which it does not
recognize." recognize."
This document adds that unrecognized IP Options MAY also be logged. This document adds that unrecognized IP Options MAY also be logged.
Further, routers, security gateways, and firewalls MUST provide the
ability to log drop events of IP packets containing unrecognized or
obsolete options.
A number of additional options are listed in the "IP OPTIONS NUMBERS" A number of additional options are listed in the "IP OPTIONS NUMBERS"
IANA registry [IANA-IP] as of the time this document was last edited. IANA registry [IANA-IP] as of the time this document was last edited.
Specifically: Specifically:
Copy Class Number Value Name Copy Class Number Value Name
---- ----- ------ ----- ------------------------------------------- ---- ----- ------ ----- -------------------------------------------
0 0 10 10 ZSU - Experimental Measurement 0 0 10 10 ZSU - Experimental Measurement
1 2 13 205 FINN - Experimental Flow Control 1 2 13 205 FINN - Experimental Flow Control
0 0 15 15 ENCODE - ??? 0 0 15 15 ENCODE - ???
1 0 16 144 IMITD - IMI Traffic Descriptor 1 0 16 144 IMITD - IMI Traffic Descriptor
skipping to change at page 28, line 5 skipping to change at page 28, line 36
The lack of open specifications for these options makes it impossible The lack of open specifications for these options makes it impossible
to evaluate the operational and interoperability impact if packets to evaluate the operational and interoperability impact if packets
containing these options are blocked. containing these options are blocked.
4.23.4. Advice 4.23.4. Advice
Routers, security gateways, and firewalls SHOULD have configuration Routers, security gateways, and firewalls SHOULD have configuration
knobs for IP packets containing these options (or other options not knobs for IP packets containing these options (or other options not
recognized) to select between "ignore & forward" and "drop & log"). recognized) to select between "ignore & forward" and "drop & log").
Section 4.23.1 points out that [RFC1122] and [RFC1812] specify that
unrecognized IP options MUST be ignored. However, the previous
paragraph states that routers, security gateways, and firewalls
SHOULD have a configuration option for dropping and logging IP
packets containing unrecognized options. While is is acknowledged
that this advice contradicts the previous RFC requirements, the
advice in this document reflects current operational reality.
Special care needs to be taken in the case of "drop & log". Devices Special care needs to be taken in the case of "drop & log". Devices
SHOULD count the number of packets dropped, but the logging of drop SHOULD count the number of packets dropped, but the logging of drop
events SHOULD be limited to not overburden device resources. events SHOULD be limited to not overburden device resources.
5. IANA Considerations 5. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
6. Security Considerations 6. Security Considerations
skipping to change at page 28, line 28 skipping to change at page 29, line 20
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 Panos Kampanakis, Donald Smith, Ron
Bonica, Arturo Servin, and Merike Kaeo for providing thorough reviews Bonica, Arturo Servin, Merike Kaeo, SM, and Suresh Krishnan for
and valuable comments. Merike Kaeo also contributed text used in providing thorough reviews and valuable comments. Merike Kaeo also
this document. contributed text used 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 29, line 25 skipping to change at page 30, line 15
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR- "Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007. PIM)", RFC 5015, October 2007.
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, November 2012.
8.2. Informative References 8.2. Informative References
[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/
skipping to change at page 32, line 25 skipping to change at page 33, line 20
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", Architecture Label IPv6 Security Option (CALIPSO)",
RFC 5570, July 2009. RFC 5570, July 2009.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011. Router Control Plane", RFC 6192, March 2011.
[RFC6274] Gont, F., "Security Assessment of the Internet Protocol [RFC6274] Gont, F., "Security Assessment of the Internet Protocol
Version 4", RFC 6274, July 2011. Version 4", RFC 6274, July 2011.
[RFC6398] Le Faucheur, F., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, November 2012.
[SELinux2008] [SELinux2008]
National Security Agency, "Security-Enhanced Linux - NSA/ National Security Agency, "Security-Enhanced Linux - NSA/
CSS", January 2009, CSS", January 2009,
<http://www.nsa.gov/research/selinux/index.shtml>. <http://www.nsa.gov/research/selinux/index.shtml>.
[Solaris2008] [Solaris2008]
"Solaris Trusted Extensions - Labeled Security for "Solaris Trusted Extensions - Labeled Security for
Absolute Protection", 2008, <http://www.sun.com/software/ Absolute Protection", 2008, <http://www.sun.com/software/
solaris/ds/trusted_extensions.jsp#3>. solaris/ds/trusted_extensions.jsp#3>.
 End of changes. 22 change blocks. 
56 lines changed or deleted 103 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/