Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Lorenzo Colitti <[e-mail]>]

On Wed, Oct 31, 2012 at 5:14 AM, Mark Smith <[e-mail]>wrote:

> Is it that packets with the fragmentation extension header as the first
> extension header are dropped, and all first extension header types are let
> through (meaning a fragmentation extension header would pass as long as it
> isn't the first), or is it that only TCP and UDP first extension headers
> are let through (and perhaps IPsec ESP) and all others are dropped? My
> pure guess would be the latter is more likely, meaning that this also
> breaks DCCP and SCTP.

 I've been hoping that one of the benefits of IPv6 will be the ability to
> use more modern transport layer protocols like DCCP and SCTP without having
> to encapsulate them inside UDP.
>

I think DCCP and SCTP are easier than fragments.

I think there are two main issues here (in user/enterprise/edge networks;
not in backbone networks):

1. Allow through only what you use.
2. Allow through only what your hardware is capable of inspecting/filtering
at line rate.

#1 equally affects fragment headers and DCCP/SCTP/other protocols. However,
#2 specially affects fragment headers and other extension headers in
general.

As an example: a lot of hardware currently deployed, including, I believe,
the totality of one major backbone router vendor's product line, is unable
to inspect extension headers beyond the first - at all. On such hardware,
saying "allow SCTP from any port to port 53" is no different than saying
"allow UDP from this any port to port 53". The hardware has to do the same
number of lookups, and even the offsets are the same. It's a simple code
fix, if even that. However, saying "allow all UDP packets from any port to
port 53, including fragments" requires that the hardware be able to perform
a more complex lookup on the same packet - look for a fragment header, and
if it's there, skip over it to find the upper-layer protocol header. Things
get more expensive if you consider that it's not just fragment headers -
it's routing headers, and shim6 headers, and any $header that anyone can
dream up and get through the IETF.

Doing this at line rate is hard. AIUI many current forwarding architectures
work by hashing the first X (e.g., 128) bytes of the packet and turning it
into a lookup key that can be processed at high speed (e.g., in TCAM). On
such architectures, there is basically no way to process arbitrary
extension header chains at line rate without substantially increasing the
amount of work that the hardware has to do - and as we know, routers aren't
exactly cheap today.

If you allow the upper-layer header not to be in the first packet at all
(i.e., have the first fragment consist entirely of extension headers). In
this case, there is simply no way to filter correctly unless you do
full-blown stateful filtering AND ensure that all the packets are processed
by the same device.


> >2. If you're an application developer and your apps need to run on the
> Internet, then fragments will likely not work in many cases. If you want
> your application to work in these cases, you should either use
> application-layer fragmentation, use path MTU discovery, or limit yourself
> to small packets instead of sending fragments.
>
>
> ICMP based PMTUD is probably not reliable enough either :-(
>

But it needs to be, or as others say, 1280 is the new 1500 and we'll never
get ourselves out of this hole. Fortunately I think it's easier than
processing arbitrary extension header chains.


> >3. If you control the network (e.g., if you're the network operator), and
> want to use fragments for tunnels or other purposes, go ahead, but note
> that in other people's networks, they might be filtered.
> >
>
> That's ok for e.g. OSPF, however the use case I was thinking of for IPsec
> was across the Internet. It's about 10 years since I did a lot of work with
> IPsec tunnels so I'm wondering how they cope with varying MTUs, broken ICMP
> PMTUD etc. these days. I'm aware that IPsec has become commonly
> encapsulated inside UDP to avoid NATs, but RFC3948 doesn't seem to cover
> fragmentation issues below UDP.
>

As you say, I think we've given up on running IPsec across the Internet. We
use IPsec over UDP instead.