On Sep 23, 2013, at 1:15 PM, Fernando Gont <[email protected]> wrote:
> On 09/23/2013 12:57 AM, C. M. Heard wrote: >> >> 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. > > 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. 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 > > If you want to experiment with this, you may employ the frag6 tool > (http://www.si6networks.com/tools/ipv6toolkit) with the "--flood-frags" > option. > > >> 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 > > 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 protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
