One document matched: draft-kampanakis-6man-ipv6-eh-parsing-00.txt
IPv6 Maintenance Working Group P. Kampanakis
Internet-Draft Cisco Systems
Intended status: Informational June 2, 2014
Expires: December 4, 2014
Implementation Guidelines for parsing IPv6 Extension Headers
draft-kampanakis-6man-ipv6-eh-parsing-00
Abstract
IPv6 is widely used on the internet today and is expected to be
deployed more as more devices (i.e. home automation) get inter-
connected. The IPv6 header format allows for the use of Extension
Headers (EH). EHs could be chained together with very few existing
guidelines by the IPv6 protocol on how devices should parse them,
which open room for security concerns and inconsistencies. This
document presents guidelines for parsing IPv6 EHs with a goal of
providing a common and consistent parsing methodology for IPv6
implementers among the industry.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Kampanakis Expires December 4, 2014 [Page 1]
Internet-Draft IPv6 EH parsing guidelines June 2014
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Parsing EH chains . . . . . . . . . . . . . . . . . . . . . . . 3
4. Parsing malformed EHs . . . . . . . . . . . . . . . . . . . . . 5
5. Other guidelines . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Kampanakis Expires December 4, 2014 [Page 2]
Internet-Draft IPv6 EH parsing guidelines June 2014
1. Introduction
As defined in [RFC2460], the IPv6 protocol was designed to have a
constant header length and allows for the use of IPv6 Extension
Headers (EH) which could be used to carry routing or other
information for intermediary or end-devices. For example,
Destination Option (DestOpt) EH are used by Mobile IPv6 end-hosts and
Hop-by-Hop (HbH) EHs are used by intermediate routing devices.
Multiple EHs can also be stacked together in an IPv6 header.
Because of the various possible combinations of EHs in an IPv6
packet, it is not clear to implementers how headers should be
evaluated and parsed by intermediary and end-devices. [RFC2460]
describes some IPv6 EH recommendations of the order and allowed
occurrences of headers, but it does not provide other guidance on how
EHs should be parsed. Experience has shown that, based on the
receiving device vendor and operating system (OS), there can be
inconsistencies in he receiver's behaviour when EHs are chained
together in an IPv6 packet. This document presents how EHs in an
IPv6 packet should by parsed in order to provide a consistent
standard behaviour for IPv6 enabled intermediary (i.e. routers) or
end-devices.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Parsing EH chains
[RFC2460] defined various IPv6 EHs and other documents defined new
EHs for various applications. Even though it includes some
guidelines, [RFC2460] does not provide strong recommendations on the
exact restrictions and order of EH headers present in an IPv6 Header.
Thus, it is can be challenging for vendors of intermediate or end-
devices to consistently parse and distinguish between which EH chains
in an IPv6 Header are legitimate or not.
Since [RFC2460] does not limit the maximum EH chain size, [RFC7112]
presents the implications of oversized IPv6 Header chains and how
these should be fragmented and parsed by intermediate devices and
hosts. Also, it defines the maximum allowed size of a EH chain.
Guideline 1: Intermediate devices that enforce policies (ACLs,
stateful inspection and firewalling) by matching on IPv6 EHs SHOULD
Kampanakis Expires December 4, 2014 [Page 3]
Internet-Draft IPv6 EH parsing guidelines June 2014
be able to parse the IPv6 Header at least up to the maximum header
processing length supported by the device hardware acceleration in
order to enforce policies or packet legitimacy. When intermediate
devices are configured to match certain EHs, the EH SHOULD be matched
regardless of its position in the EH chain unless the header is
malformed and dropped according to guidelines in this document. If
multiple EHs of the same type exist in the EH chain, all SHOULD be
parsed by the intermediate device until matched in order to enforce
the matching policy. When an EH chain exceeds the hardware
acceleration processing limit the packets MAY be software processed
in order to enforce policies. To protect against Denial of Service
Denial of Service (DoS), intermediate devices MAY provide rate-
limiting mechanisms that limit resources consumed by software
processed packets. Intermediate devices that are not enforcing
policies based by matching IPv6 EHs, MAY NOT parse EH chains other
than HbH when present ([RFC7045]).
Guideline 2: From Section 5 of [RFC7112], when parsing an EH chain,
o a host MUST drop non-initial fragments that include parts of an
IPv6 EH chain and initial fragments whose last EH Next Header
field is not an Upper Layer (UL) protocol (i.e. TCP) or the No
Next Header. The host SHOULD send an ICMPv6 error message when
dropping the fragment.
o an intermediate device that enforces policies (ACLs, stateful
inspection and firewalling) by matching on IPv6 EHs MAY drop (if
not configured to allow) non-initial fragments that include parts
of an IPv6 EH chain or an initial fragment whose last EH Next
Header field is not an Upper Layer (UL) protocol (i.e. TCP) or
the No Next Header.
Section 4 of [RFC2460] defines that the HbH EH can only occur once in
an IPv6 Header chain and has to be be the first header.
Guideline 3: Thus, when parsing an EH chain,
o an end-host MUST discard packets that have an HbH EH that is not
first in the chain.
o an intermediate device that enforces policies (ACLs, stateful
inspection and firewalling) by matching on IPv6 EHs MUST discard
packets that have an HbH EH that is not first in the chain
(Section 2.2 of [RFC7045]). If the device is not parsing the EH
chain, it MAY NOT discard the packets.
Guideline 4: According to Section 4.1 of [RFC2460], when a end-host
processes a IPv6 packet with multiple DestOpt EHs,
Kampanakis Expires December 4, 2014 [Page 4]
Internet-Draft IPv6 EH parsing guidelines June 2014
o if there is no RH EH in the packet, then only the final
destination host SHOULD process only the last DestOpt EH.
o if there is a RH in the packet
* if the node is the final destination, then it SHOULD process
all the DestOpt EHs in the packet.
* if the node is one of the destinations in the RH, it SHOULD
only process the DestOpt EHs in the chain that are before the
RH EH.
In general, intermediate devices that enforce policies by matching on
IPv6 EHs (ACLs, stateful inspection and firewalling) should follow
Section 2 of [RFC7045] in order to transmit IPv6 packets with EHs.
Note about EH order: [RFC2460] mentions
Each extension header should occur at most once, except for the
Destination Options header which should occur at most twice (once
before a Routing header and once before the upper-layer header).
But, later it says
IPv6 nodes must accept and attempt to process extension headers in
any order and occurring any number of times in the same packet,
except for the Hop-by-Hop Options header which is restricted to
appear immediately after an IPv6 header only. Nonetheless, it is
strongly advised that sources of IPv6 packets adhere to the above
recommended order until and unless subsequent specifications revise
that recommendation.
Thus, there is no other specific EH order end-hosts or intermediate
devices can enforce following current specifications.
4. Parsing malformed EHs
IPv6 EHs that are malformed MUST be efficiently dropped. Malformed
EHs could contain incorrect Hdr Ext Len or Opt Data Len fields.
Guideline 5: When parsing an EH chain, a host or an intermediate
device that enforces policies (ACLs, stateful inspection and
firewalling) by matching on IPv6 EHs MUST discard packets that
contain EHs with inaccurate Hdr Ext Len. To ensure that, while
parsing the chain, each EH Hdr Ext Len SHOULD be used to determine
the next EH in the chain. If the data of the last EH or the UL
Header plus its data does not align with the original IPv6 Header
Kampanakis Expires December 4, 2014 [Page 5]
Internet-Draft IPv6 EH parsing guidelines June 2014
Payload Length the packet MUST be dropped unless another policy step
already discarded it.
Especially for DestOpt and HbH EHs, they can carry a variable number
of type-length-value (TLV) encoded Options. Each option contains an
Opt Data Len field for the data length in the option. Malformed
packets with Options that contain inaccurate length MUST be dropped
by hosts and intermediate devices that are parsing these Options
unless another policy step discarded the packet.
Guideline 6: When parsing EH Options, the Opt Data Len field points
to the end of the Option parsed. If the Opt Data Len of the last
Option in the EH does not align with the Hdr Ext Len of the EH that
contains the Option, the packet MUST be discarded. The guidelines
for actions based on the Option Type value described in Section 4.2
of [RFC2460] MUST still be followed. A host or intermediate device
that is not parsing the Option ([RFC7112]) SHOULD NOT discard the
packet.
The following algorithm shows how an end-host or intermediary device
that enforces policies (ACLs, stateful inspection and firewalling) by
matching on IPv6 EHs could be implementing Guideline 6 and 7:
while (IPv6 EH chain not parsed) {
[TODO: write pseudocode]
}
5. Other guidelines
Guideline 7: Unknown EHs
o As defined in Section 4 of [RFC2460], end-hosts should discard
packets with unknown EH types and send an ICMP Parameter Problem
message to the source of the packet.
o Intermediate devices that enforce policies (ACLs, stateful
inspection and firewalling) by matching on IPv6 EHs MUST only drop
unknown EH as part of configuration policy (Section 2.1 of
[RFC7045]).
Guideline 8: Intermediate or end-hosts MUST process a RH in an IPv6
packet only when the host's address is the same as the packet's IPv6
Destination Address. (Section 4.4 of [RFC2460])
Guideline 9: Unknown RH
Kampanakis Expires December 4, 2014 [Page 6]
Internet-Draft IPv6 EH parsing guidelines June 2014
o End-hosts that receive packets with a RH with an unrecognised
Routing Type value MUST ignore the RH if Segments Left is zero.
If Segments Left is non-zero, the host MUST drop the packet and
send an ICMP Parameter Problem (Section 4.4 of [RFC2460]).
o Intermediate devices that enforce policies by matching on IPv6 EHs
(ACLs, stateful inspection and firewalling) SHOULD forward (unless
configured to drop) standardised and undeprecated RH (Section 2.1
of [RFC7045]).
Guideline 10: Intermediate or end-devices performing re-assembly MUST
silently discard overlapping IPv6 fragments (Section 4 of [RFC5722]).
More info on errors and the corresponding messages to be generated by
a host or intermediate device performing re-assembly can be found in
Section 4.5 of [RFC2460].
Guideline 11: As defined in [RFC6946], "atomic" IPv6 fragments SHOULD
be "re-assembled" from the contents of that sole fragment. End-hosts
and intermediary devices performing re-assembly SHOULD conform to
[RFC6946].
6. Security Considerations
No new security exposures or issues are raised by this document.
This document describes how IPv6 EHs should be parsed by intermediate
and end-devices in a consistent manner. Guidelines presented in this
document also leverage recommendations described in [RFC2460],
[RFC6946], [RFC5722], [RFC7112] and [RFC7045].
Implementers following a common document for parsing and matching
IPv6 EHs can ensure that no network policies are bypassed due to
inconsistent processing of IPv6 EHs.
7. Updates
version -00: Initial submission.
8. Acknowledgements
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kampanakis Expires December 4, 2014 [Page 7]
Internet-Draft IPv6 EH parsing guidelines June 2014
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",
RFC 6946, May 2013.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, January 2014.
Author's Address
Panos Kampanakis
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
US
Email: pkampana@cisco.com
Kampanakis Expires December 4, 2014 [Page 8]| PAFTECH AB 2003-2026 | 2026-04-23 21:33:07 |