Subject: draft-andrews-6man-fragopt updated

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Aug 2013 11:14:02 +1000

http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 19 Aug 2013 21:26:10 -0700 (PDT)

> 	http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt

This is an interesting draft and I see that it attempts to offer a 
fairly complete solution, covering not just TCP and UDP but ICMP and 
tunneled IPv4 and IPv6.  The idea is to put L4 information missing 
in 2nd and subsequent framgments into IPv6 options, thereby making 
it readily available to stateless filtering devices, load balancers, 
and the like.

One significant concern that jumps out at me is that the option(s) 
defined in this draft are hop-by-hop options.  Quoting from 
draft-ietf-6man-ext-transmit Section 2.2:

   However, it is to be expected that high performance routers will 
   either ignore it, or assign packets containing it to a slow 
   processing path. Designers planning to use a Hop-by-Hop option 
   need to be aware of this likely behaviour.

To me it seems highly undesirable to risk putting one's traffic on 
the slow path of a core router, especially when the L4 information 
is probably not needed there, but in middleboxes closer to the edge.  
However, I don't see any reason why these options could not go into 
a destination options header.  The standard order in RFC 2460 
(excluding Mobility and Shim6 headers) would work,

           IPv6 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           Fragment header
           Authentication header (note 2)
           Encapsulating Security Payload header (note 2)
           Destination Options header (note 3)
           upper-layer header

though "note 1" would need to be changed as follows:

           note 1: for options to be processed by the first destination
                   that appears in the IPv6 Destination Address field
                   plus subsequent destinations listed in the Routing
                   header or by forwarding nodes needing to inspect 
                   options containing layer 4 header information.

There is precedent for refinement to the placement of Destination 
Options headers; see, e.g., RFC 6275 and the Home Address Option.

In answer to to the open questions, I would suggest using a single 
option code and making the protocol explicit.  The strategy of 
leaving the protcol implicit leads to ambigiuities (e.g., between 
TCP, UDP, and UDP-lite).  I would also suggest judicious use of 
padding to align 4 and 8 bytes quantities on natural boundaries.

Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Aug 2013 16:08:00 -0700 (PDT)

> > 	http://www.ietf.org/id/draft-andrews-6man-fragopt-01.txt
...
> padding to align 4 and 8 bytes quantities on natural boundaries.

It occurs to me that instead of having a different option format for 
every single upper-layer protocol, one could instead just package 
the portion of the header chain (extension headers, if any, and 
upper-layer header) that appears after the fragmentation header in 
the initial fragment.  That would require only a single option code, 
would apply to all present and future upper-layer protocols, and 
would provide the requisite upper-layer information in a form that 
those who want it must already know how to parse.  The option would 
look like this:

                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |0|0|1|  (TBD)  | Opt Data Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+   Portion of header chain following offset=0 fragment header  +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The type would be chosen to indicate that the option is mutable and 
is to be skipped if it is not recognized.  The alignment requirement 
would be 8n+6, since the upper-layer header and any preceding 
extension headers always are aligned on 8-octet boundaries.

Here are some other suggestions:

- Make this a destination option that appears before the 
  fragmentation header, not a hop-by-hop option, as discussed in a 
  previous e-mail in this thread.

- This option MUST NOT appear in an initial fragment (or in an 
  unfragmented fatagram).  That avoids the possibiity that a 
  middlebox will interpret a datagram differently from an end system 
  (or another middlebox).

- New end-system implementations MUST have the capability to insert 
  this option in non-initial fragments.  That capability MUST be 
  configurable, and the default SHOULD be to insert the option.

- If a forwarding node discards a packet containing this option, it 
  MUST be the result of a configurable policy, and not just the 
  result of a failure to recognize the option.  By default, the 
  policy SHOULD be the same that the node would apply to an initial 
  fragment with the same header chain that is in the option, and 
  that in turn SHOULD be the same policy that the node would apply 
  to an unfragmented datagram with the same header chain (less the 
  fragmentation header).

- A forwarding node that rewrites the flow label MAY use the 
  information available in this option for that purpose.

- An end system is not required to process this option.  However, if 
  it does, it SHOULD ensure that the copies the upper-layer in the 
  various fragments match what appears in the initial fragment, and 
  that the option does not appear in an initial fragment (or in an
  unfragmented datagram).  [Define codes and pointers for an ICMPv6
  Parameter Problem message that indicates these situations.]

Acknowledgments to draft-ietf-6man-ext-transmit-03 for some stolen 
text.

Item for discussion: does it really matter whether or not this 
option is marked as mutable?  It would not be covered by an 
Authetication Header in any case since "AH is applied only to whole 
IP datagrams (not to IP fragments)" [RFC 2402] and this option is 
inserted only after fragmentation.  A NAT does not respect 
immutability (as defined in RFC 2402), so the possibility of a NAT 
being on the path does not seem like a good reason to mark it 
mutable.  On the other hand, what benefit could there be from 
marking it as immutable?

Mike Heard

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Aug 2013 09:42:23 +1000

In message <[email-masked]>, "C. M. Heard
> those who want it must already know how to parse.  The option would 

It is quite possible to develop asics which understand this option
the same way as there are asics which process tcp and udp headers.

>   middlebox will interpret a datagram differently from an end system 

This is a non starter.  Whatever change we make needs to be visible in
all fragment.  Firewalls need to be able to identify if the packet is
following old fragmentation rules or new fragmentation rules so it can
decide if it is applying old policy or new policy.
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 26 Aug 2013 19:09:23 -0700 (PDT)

On Tue, 27 Aug 2013, Mark Andrews wrote:
> In message <[email-masked]>, 
> "C. M. Heard" writes:

could be developed != exists in current core routers

Existing core routers are likely to punt hop-by-hop options to a 
slow path.  But they aren't the cause of the fragment dropping 
problems.  So we should seek a solution that does not require 
updating them.

I don't see why a destination option (apearing BEFORE the fragment 
header) would not work just as well as a hop-by-hop option while 
being immune from this particular problem.

> decide if it is applying old policy or new policy.

I don't see that.

The initial fragment, without the option, already has the 
upper-layer information that a firewall needs in order to apply a 
filtering policy (assuming of course that it complies with 
draft-ietf-6man-oversized-header-chain).  Non-initial fragments get 
dropped because that information is missing.  The option provides 
the missing information.

Firewalls that discard non-initial fragments will need to be updated 
to use the option.  Firewalls that unconditionally drop anything 
with a fragment header will need also to be updated not to drop 
initial fragments (as long as those fragments contain a complete 
upper-layer header, per draft-ietf-6man-oversized-header-chain).  
Either way, an update to the firewall is required.

The downside of putting the option into initial fragments is what 
can happen if there is a mismatch between the contents of the option 
and the actual upper-layer header if both are present.  If for ease 
of implementation the firewall uses the option but not the 
upper-layer header (so that all fragments are treated the same), 
what it lets through may be interpreted differently by an end system 
than the firewall expected (this is particularly true for old end 
system implemantations that have not been updated to recognize the 
option) -- in other words, there is a possibility of evading the 
firewall's policy.  This possibility is completely elminated by 
eliminating the duplicate information, i.e., by leaving the option 
out of initial fragments (and unfragmented datagrams).

It is true that an initial fragment generated by an old 
implementation and generated one by a new implementation cannot be 
distinguished under my proposal.  The worst that happens is that the 
initial fragment generated by an old implementation gets through, 
but succeeding ones do not.  In that case some resources are 
consumed on the destination host, but the datagram does not get 
through (as intended by the firewall).  Indeed, in looking at

http://www.nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf

which was a primary reference for draft-taylor-v6ops-fragdrop, it 
seems that is generally (or often) what happens today.

//cmh

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Aug 2013 12:24:33 +1000

In message <[email-masked]>, "C. M. Heard
> problems.  So we should seek a solution that does not require 

Some punt them to the slow path but fragmented IP is also a small
percentage of traffic.  Others just don't process hop-by-hop.  Others
just drop.

> > decide if it is applying old policy or new policy.
 
Lots of firewalls discard all fragments as it is pointless sending
the initial fragment if you are discarding non-initial fragments.

As for mis-matches they are expected if you have NATs in the path.

Mark