Subject: Re: UDP+Fragmentation (was: "Deprecate")

From: "C. M. Heard" <[email-masked]>
Date: Sun, 22 Sep 2013 20:57:27 -0700 (PDT)

On Mon, 26 Aug 2013, C. M. Heard wrote:
> Upon reflection, I have come to the conclusion that the proposal 
> in draft-andrews-6man-fragopt (or a variant thereof) is a much 
> better solution to the problems with IPv6 fragmentation than the 
> UDP segmentation scheme I proposed.
> 
> The huge advantage of putting a skippable IPv6 option with 
> higher-layer header information into IPv6 fragments is that it is 
> much easier to deploy incrementally than the UDP segmentation 
> scheme.  New end systems could begin inserting the option as soon 
> the format is standardized, and they would still be able to 
> communicate with older end systems that comply with existing IPv6 
> specifictions, at least on paths where fragments are not discarded 
> by firewalls.  That's not true of the UDP segmentation scheme (or 
> of more complex alternatives such as SEAL).

Upon further reflection, prompted by Warren Kumari's comments (see 
http://www.ietf.org/mail-archive/web/ipv6/current/msg18858.html and 
http://www.ietf.org/mail-archive/web/ipv6/current/msg18862.html), it 
becomes clear that the very thing that makes this alternative 
(relatively) easy to deploy incrementally can make it unattractive 
to security-conscious operators.

There are two issues that Warren's comments brought to the fore:

1.) One of the reasons why operators block fragments is that if 
    fragments are allowed into one's network, it is relatively easy 
    for an attacker to make a DOS attack on end systems by sending 
    an incomplete series of fragments.  This ties up resources until 
    the end system's reassembly timer expires.

2.) The proposed skippable upper-layer header option is easily 
    forged.  It is therefore still relatively easy to mount the 
    above attack on end systems that do not recognize the option, 
    even if firewalls have been updated to require that option in 
    all fragments.

The problem is that end systems that don't recognize the skippable 
option will ignore it and process fragments in the IP layer as they 
do now.  This is good for incremental deployment, but it also leaves 
such systems just as vulnerable as they were without the option.

In order to avoid that problem, it seems that we need to ensure:

(a) that end systems that don't understand the option drop any 
packets that contain it, and

(b) that end systems that do accept the option use it to filter out 
packets that are unwanted or invalid.

Condition (a) can be achieved by choosing the two high-order bits of 
the option code to specify that the packet must be discarded if the 
option is unrecognized (and whether or not to send an ICMP Parameter 
Problem message).  Condition (b) can be achieved by requiring that 
packets containing this option be kicked up to the transport layer 
for processing prior to reassembly, in lieu of doing reassembly at 
the IPv6 layer prior to transport layer processing.  In particular, 
end-system implementations would need to discard fragments directed 
at a port with no listener.  Other validity checks could be made, 
such as discarding fragments that specify a length in excess of the 
port's receive buffer or that have inconsistent upper-layer headers.  
This does not block all conceivable attacks, but it reduces the 
severity to something equivalent to what an attacker could do by 
forging TCP segments -- and that is a risk that end systems deal 
with today.

What I have described in the paragraph above is different ONLY IN 
DETAIL from the other alternatives we've been discussing in this 
thread, namely modifying UDP so that it supports segmentation of 
long payloads or creating a new UDP-like protocol that supports 
segmentation of long payloads.  The information carried in the IPv6 
and transport layer headers would be equivalent, and the processing 
would be quite similar.  Obviously the header formats would differ; 
in addition, so would the kind of ICMP message, if any, that would 
be returned by systems that don't recognize the new option/protocol 
(Parameter Problem/Unrecognized Option or silent drop for the 
proposed option, Parameter Problem/Unrecognized Next Header for a 
new protocol, or silent drop for a modified UDP as suggested in 
http://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html).

If the above reasoning is correct, then my inclination is to deal 
with the issue explicitly in the transport layers that need to deal 
with it (which would put the problem in the domain of TSVWG).  That 
seems cleaner than intertwining the IP and transport layers (though 
in practice these layers are often tightly coupled anyway).

If there are any operations people listening in, it would be helpful 
to get some feedback on whether this reasoning is correct.

It would also be helpful to get some indication on whether a 
modified UDP or a new UDP-like protocol that supports transport 
layer payload segmentation solves enough problems to be worth the 
effort to specify, implement, and deploy.  At the moment, the only 
compelling use case seems to be DNS (and more particularly DNSSEC).  
There is already a work-around in that case, namely TCP, which was 
made mandatory in 2010 by RFC 5966 to work around firewalls that 
"routinely block fragmented IP packets" and "network devices [that] 
deliberately refuse to handle DNS packets containing EDNS0 options." 
Clearly, making a new or modified UDP-like transport protocol is not 
sufficient; applications that want to use it would need a means to 
signal that they support it and/or a means to query whether their 
peers support it.  In the case of DNS that would presumably mean 
something like a new EDNS0 option.  The question arises whether the 
effort involved in making these changes would be worthwhile, given 
that TCP is already available as a workaround.

Thanks and regards,

Mike Heard

---

From: Mark Andrews <[email-masked]>
Date: Mon, 23 Sep 2013 14:34:12 +1000

In message <[email-masked]>, "C. M. Heard
>     even if firewalls have been updated to require that option in 

Actually before making statements like this we really need a audit
of current stacks and how they behave when subject to a flooding
fragmentation attack.  These attacks are *old* and OS have strategies
to deal with them.  Additionally is the firewalls DoS be dropping
the packets worse than the flooding DoS?

A stateful firewall also doesn't let through all fragments.

> such systems just as vulnerable as they were without the option.

Only if they are vulnerable to begin with and only if the firewall is
letting through all packets with the option.

> packets that contain it, and

Or fix the underlying problem that the filter was put in place to
address in the first place.

> Problem message).

Which makes it no longer incrementally deployable.

> Condition (b) can be achieved by requiring that 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Sep 2013 17:15:05 -0300

>     the end system's reassembly timer expires.

This is, I'd say, inaccurate.

Unless you have a very sloppy IPv6 implementation (that does not enforce
limits on the maximum number of queued fragments), an attacker will only
be able to DoS communication instances (e.g. TCP connections) that
employ fragmentation. Such fragmentation attacks won't have any effect
on non-fragmented traffic.

If you want to experiment with this, you may employ the frag6 tool
(http://www.si6networks.com/tools/ipv6toolkit) with the "--flood-frags"
option.

> There is already a work-around in that case, namely TCP, which was 

If you care about fragmentation-based attacks, you really don't want to
use TCP. There are a bunch of attacks that can be (by far) more
devastating than the fragmentation-based ones (see
<http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf>).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Sep 2013 22:17:02 +0000

Hi,

I have done some looking around on linux and found two more sources
of IPv6 fragmentation. First, unless explicitly told not to, 'ping6'
will use IPv6 fragmentation to ensure that ICMPv6 echo request packets
larger than the path MTU are delivered to the final destination. The
destination then gets to reassemble the ICMPv6 echo request packets
first, and then turns around and uses IPv6 fragmentation to ensure
that its ICMPv6 echo replies get back to the source.

Secondly, a router at the head end of an IPv6 IPsec tunnel can in some
cases fragment the inner IPv6 packet before encapsulation; the final
destination then gets to reassemble. Since this is a tunnel mode
operation, the fragmentation occurs regardless of the inner transport
layer protocol. This bears some further consideration, because IPv6
routers are not supposed to fragment IPv6 packets in transit. The best
I can figure is that an IPsec tunnel router is usually the sole egress
point for an IPv6 host located in the protected network so the router
can act as if it is a "proxy host". It is then the router (and not the
protected host) that inserts the IPv6 fragment header and sets the
Identification value. Again, the final destination gets to perform
reassembly, and this could be for any transport protocol type; not
just for UDP.

I believe what I am seeing from my experiments that yielded the above
observations is accurate, but would welcome any comments or corrections.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Sep 2013 22:35:28 +0000

Hi,

I have prepared an alpha implementation of SEAL that focuses
on RFC4821 for tunnels:

    http://linkupnetworks.com/seal/sealv2-0.0.tgz

The code has been tested on Ubuntu 12.04 linux with the 3.10.12
linux kernel. The release contains a README with instructions
on how to reproduce the experiments.

The implementation has been tested with both IP/IPv6 and GRE/IPv6
tunnels, and includes test scripts that can show the functionality
using the Common Open Research Emulator (CORE):

    http://cs.itd.nrl.navy.mil/work/core/

The implementation inserts a SEAL shim header between the outer
IPv6 header and the inner packet, and uses SEAL fragmentation
and reassembly as follows:

  1) If the inner packet is no larger than 1280 bytes minus the
     length of the encapsulation headers, encapsulate and send
     without fragmentation.

  2) If the inner packet is larger than 1500 bytes but no larger
     than the path MTU, encapsulate and send without fragmentation.

  3) For all other packets, encapsulate and use SEAL fragmentation
     to break the packets into a size that should be small enough
     to traverse the path without further fragmentation even if
     there are other tunnels in the path. At the same time, probe
     the path to see if packets of this size can be delivered without
     fragmentation and, if so, discontinue the fragmentation process
     and send future packets in this size range as whole packets.

The procedures are specified in 'draft-templin-intarea-seal', which
can be found here:

    http://tools.ietf.org/html/draft-templin-intarea-seal

Any comments or observations would be welcome.

Thanks - Fred

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 24 Sep 2013 18:51:11 -0700 (PDT)

> on non-fragmented traffic.

In that I hear an echo of some of the pushback in the V6OPS WGLC of 
draft-taylor-v6ops-fragdrop (see, e.g., comments from Havard Eidnes 
at http://www.ietf.org/mail-archive/web/v6ops/current/msg17409.html)

> > There is already a work-around in that case, namely TCP [ ... ]
> 

That is an important observation, for two reasons:

- it suggests that getting fragments to work or making a UDP-like 
  protocol that has equivalent functionality is important for DNSSEC

- it suggests that looking askance at IPv6 fragmentation is not 
  logical if one is not at least as concerned about TCP, which does 
  NOT seem to be widely blocked

Thanks

//cmh

---

From: Warren Kumari <[email-masked]>
Date: Wed, 25 Sep 2013 10:32:42 -0700

> on non-fragmented traffic.

http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01 Section 2.1.4  says, amongst other things:

   Another incentive toward dropping of fragments is the
   disproportionate number of software errors still being encountered in
   fragment processing.  Since this code is exercised less frequently
   than the rest of the stack, bugs remain longer in the code before
   they are detected.  Some of these software errors can introduce
   vulnerabilities subject to exploitation.

There has also been discussion that for things like routers you can just do X to protect the device control plane / only care about traffic directed to the device itself. 

Anyway, I figured folk might find this interesting:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ipv6vfr

(DoS of device through VRF functionality)
This is fragmented traffic transiting the device, a code path that is exercised less frequently than the rest of the stack and DoSs more than TCP connections that employ fragments.

You could spend all day discussing if this is a "very sloppy IPv6 implementation" or not :-P

W

--
I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, with great presence of mind, they brought Thousand Island Dressing and a bottle of chili sauce.
    -- Terry Pratchett

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Sep 2013 19:38:53 -0300

On 09/25/2013 02:32 PM, Warren Kumari wrote:
>> 
>> Unless you have a very sloppy IPv6 implementation (that does not
>> enforce limits on the maximum number of queued fragments), an
>> attacker will only be able to DoS communication instances (e.g. TCP
>> connections) that employ fragmentation. Such fragmentation attacks
>> won't have any effect on non-fragmented traffic.
> 
> 
> disproportionate number of software errors still being encountered
> in fragment processing.  Since this code is exercised less
> frequently than the rest of the stack, bugs remain longer in the code
> before they are detected.  Some of these software errors can
> introduce vulnerabilities subject to exploitation.

I must admit I have not yet read Tom's draft, and I'm not necessarily
arguing that there are no buggy implementations of IPv6 fragment
reassembly. But I stand by my statement that if an implementation cannot
properly handle IPv6 fragment reassembly (which is essentially the same
as IPv4 fragment reassembly, with a long history of bugs and known
fixes), the implementation is immature.

My take is that, unfortunately, many IPv6 implementations are immature
-- and I'm not talking just about fragment reassembly, but about IPv6
implementations in general. If one looks carefully at the kind of bugs
being found in them (whether that's IPv6 fragment reassembly or IPv6 NC
implementation), it's not difficult to assess that at least some of them
are as mature as some IPv4 implementations in the mid/late 90's.

So if we're going to cut down/filter anything with buggy
implementations, we might find our self more than we might want to (so
to speak ;-) ).

That said, I understand an operator filtering fragments to address a
current problem it has. But let's call a lemon a lemon: the problem is
not IPv6 fragmentation per se, but rather the underlying buggy
implementation.

There are a number of reason why the current situation may be what it is:

1) Different folks working on the IPv6 code than the folks who worked on
the IPv4 code at the time.
2) We not simply having understood the lessons from the IPv4 world.
3) Lack of guidance about how to avoid known implementation flaws.
4) A mix of th above.

FWIW, my take is that the one *we* can tackle is "3", and that has been
the spirit of some of the documents I've authored.

> There has also been discussion that for things like routers you can
> just do X to protect the device control plane / only care about
> traffic directed to the device itself.

Agreed. But, isn't that orthogonal to the discussion regarding filtering
fragments altogether? -- i.e., the ongoing discussions seem to argue
that folks are filtering fragments, no matter which device they are
directed to.

> http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130925-ipv6vfr

I did find the pointer interesting (thanks!). If folks know more about
this vulnerability, please feel free to share. (e.g., is i an IPv6
version of the Ping o' Death?).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Warren Kumari <[email-masked]>
Date: Thu, 26 Sep 2013 10:02:49 -0700

> fixes), the implementation is immature.

Yup, sure. No argument.

> implementations in general.
> If one looks carefully at the kind of bugs

> fragments altogether? --

Nope, I don't think so… There were discussions earlier saying that you don't need to filter in the network, you can just filter at the hosts, and on the device control plane (packets destined to the deviceS)  and ignore transit traffic. This is an example of an issue where it is transit traffic that causes the issue.

> i.e., the ongoing discussions seem to argue

Yes, exactly. 

I have no way of knowing what all devices / hosts / systems will have buggy implementations, but I know that some will… Often times these bugs are triggered under unusual conditions / less often exercised code paths (if they were not, they would have already been found :-P). I won't know about the vulnerabilities when they are first discovered, and I really don'e want to be in the situation where all of my network is falling over. Even if the bugs are patched as soon as they are discovered (and are not being actively exploited), it takes significant time to regression test / smoke test new code, and significant time to upgrade an entire network. It therefore makes sense to try and limit the exposure / attack surface…

W

-- 
Eagles soar but a weasel will never get sucked into a jet engine

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Sep 2013 14:33:31 -0300

On 09/26/2013 02:02 PM, Warren Kumari wrote:
>>> There has also been discussion that for things like routers you
>>> can just do X to protect the device control plane / only care
>>> about traffic directed to the device itself.
>> 
>> Agreed. But, isn't that orthogonal to the discussion regarding
>> filtering fragments altogether? --
> 
> Nope, I don't think so… There were discussions earlier saying that
> you don't need to filter in the network, you can just filter at the
> hosts, and on the device control plane (packets destined to the
> deviceS)  and ignore transit traffic. This is an example of an issue
> where it is transit traffic that causes the issue.

Oh, I know see your point. And... yes it's a... difficult situation.

I should say, though, that implementations have been found to have
trouble to parse extension headers, and probably also malformed packets
-- that's what I was meaning: implementations are immature in general.

>> i.e., the ongoing discussions seem to argue that folks are
>> filtering fragments, no matter which device they are directed to.
> 
> Yes, exactly.
> 
> I have no way of knowing what all devices / hosts / systems will have
> buggy implementations, but I know that some will… Often times these
> bugs are triggered under unusual conditions / less often exercised
> code paths (if they were not, they would have already been found
> :-P).

My personal take (based on personal experience), is that there is a lot
to be found. :-)  -- and when it comes to vendor's response, some
desktop OS' vendors thing that e.g. a DoS vector based on NCE exhaustion
is not something they should be addressing. -- i.e., the future doesn't
look that bright, unfortunately.

> I won't know about the vulnerabilities when they are first
> discovered, and I really don'e want to be in the situation where all
> of my network is falling over. Even if the bugs are patched as soon
> as they are discovered (and are not being actively exploited), it
> takes significant time to regression test / smoke test new code, and
> significant time to upgrade an entire network. It therefore makes
> sense to try and limit the exposure / attack surface…

I understand. At the end of the day, the folk running the network needs
some pragmatism, more than a "what the world should be, but isn't" rant. :-)

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 28 Sep 2013 17:38:52 -0300

>   NOT seem to be widely blocked

FWIW, I came across this (worth-reading) article:
<http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/>
-- please take a look at th section on TCP usage.

Cheers,