Subject: [v6ops] Fwd: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt

From: Tom Taylor <[email-masked]>
Date: Mon, 15 Oct 2012 20:44:58 -0400

This draft captures a discussion that occurred at the end of the 
Amsterdam interim meeting. It's raw, but your comments will help to 
bring it to maturity.

-------- Original Message --------
Subject: New Version Notification for draft-taylor-v6ops-fragdrop-00.txt

A new version of I-D, draft-taylor-v6ops-fragdrop-00.txt
has been successfully submitted by Tom Taylor and posted to the
IETF repository.

...

Title:		 Why Operators Filter Fragments and What It Implies
...
Htmlized:        http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00

Abstract:
    This memo is written to make application developers and network
    operators aware of the significant probability that IPv6 packets
    containing fragmentation extension headers will fail to reach their
    destination.  Some assumptions about the ability to use TCP or UDP
    datagrams larger than a single packet may accordingly need
    adjustment.  This memo provides observational evidence for the
    dropping of IPv6 fragments along a significant number of paths,
    explores the operational impact of fragmentation and the reasons why
    dropping occurs, and considers the effect of fragment dropping on
    applications particularly including DNS.

The IETF Secretariat

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 15 Oct 2012 19:50:57 -0700 (PDT)

It's an easy read, but my reaction is: where's the beef?

In particular, there needs to be justification of the bald assertion 
in Section 2.1 that "some cases will remain where legitimate 
fragments are discarded for legitimate reasons."  What legitimate 
reasons?  Those need to be spelled out.

//cmh

On Mon, 15 Oct 2012, Tom Taylor wrote:
> This draft captures a discussion that occurred at the end of the Amsterdam
> interim meeting. It's raw, but your comments will help to bring it to
> maturity.
> 
>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 15 Oct 2012 20:38:36 -0700

> reasons?  Those need to be spelled out.
So I have a stateless hash in front of several stateful devices. If I 
use the 5-tuple to hash, fragments will be dropped on the floor because 
by-in-large the second fragment  will hash to a different device than 
the initial fragment (assuming the initial fragment contains the udp or 
tcp header). If one uses an L3-only hash that stops happening but in the 
5-tuple case the dropping happens whether I deliberately filter or not.

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Oct 2012 17:26:33 +1100

> 5-tuple case the dropping happens whether I deliberately filter or not.

Or one could use 5-tuple for TCP and 3-tuple everything else.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Oct 2012 08:07:08 +0100

> Or one could use 5-tuple for TCP and 3-tuple everything else.

Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Oct 2012 00:23:54 -0700

> Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438.
it's mostly 0.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Oct 2012 10:25:27 +0100

>> Use the flow label. This is one of the reasons we did RFC 6436, 6437

Right. So it's time to start leaning on o/s and router vendors to support
it. I don't think there's another long-term solution to this.

(There's a related issue, covered in draft-carpenter-6man-ext-transmit,
which also needs fixing by vendors.)

   Brian

>>>>>> Amsterdam
>>>>>> Htmlized:       
>>>>>> http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-00
>>>>>>
>>>>>>
>>>>>> Abstract:

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Oct 2012 13:21:37 +0200

Hi,

> Use the flow label. This is one of the reasons we did RFC 6436, 6437 and 6438.

So how exactly is "filter based on an arbitrary value the attacker can
control" better than "just let non-initial fragments through"?

Which is what I'd do - either reassemble at the (stateful) firewall, or
let non-initial fragments pass.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Oct 2012 08:27:01 -0400

On Oct 16, 2012, at 7:21 AM, Gert Doering <[email-masked]> wrote:

> Which is what I'd do - either reassemble at the (stateful) firewall,

Reassembly at "firewalls" is wickedly expensive (in terms of CPU, memory, etc) and often end up as bottlenecks under things like missing fragment / incomplete fragment attacks.  Also, this is assuming that there is a stateful firewall somewhere between the Internet and your network -- for many many people this is not true (or really possible).

> or let non-initial fragments pass.

Or drop them…

W

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Oct 2012 14:49:07 +0200

Hi,

On Tue, Oct 16, 2012 at 08:27:01AM -0400, Warren Kumari wrote:
> Or drop them?

If you want to break other people's communication, that's the way forward.

Gert Doering
        -- NetMaster

---

From: Ivan Pepelnjak <[email-masked]>
Date: Tue, 16 Oct 2012 15:11:09 +0200

It's (probably ... until Fernando figures a way to hack it) safe to pass 
fragments without extension headers other than fragmentation header.

It's also (probably) safe to drop non-initial fragments with extension 
headers (apart from the fragmentation header). If someone generates 
enough extension headers to overflow the minimum MTU, he has a problem 
anyway.

Am I missing something?
Ivan

---

From: Tom Taylor <[email-masked]>
Date: Tue, 16 Oct 2012 10:06:35 -0400

I expect overlapping fragments need to be handled with great care 
wherever the packet is reassembled. In particular it would be wrong to 
overwrite L4 headers.

---

From: Ivan Pepelnjak <[email-masked]>
Date: Tue, 16 Oct 2012 16:12:48 +0200

That SHOULD be covered by RFC 5722. No idea whether the IPv6 stacks do 
that ... but then if the host is perfectly secured, we don't need to 
discuss packet filters, do we ;)

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Oct 2012 08:33:05 -0700

> If you want to break other people's communication, that's the way forward.
I think the point the of the draft is not to point out that this is 
desirable, but rather that some people who  are doing this lack 
palatable alternatives.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Oct 2012 16:39:36 +0100

> enough extension headers to overflow the minimum MTU, he has a problem

Only the fact that to allow innovation, all middleboxes need to be transparent
to newly defined extension headers that they don't know about. I tend to agree
that very long extension headers are probably not a good idea, but we can't
predict all future innovations.

Of course, if we think that innovation on the Internet is a bad thing,
that's another matter.

   Brian

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 16 Oct 2012 08:50:36 -0700 (PDT)

On Tue, 16 Oct 2012, joel jaeggli wrote:
> I think the point the of the draft is not to point out that this is desirable,
> but rather that some people who  are doing this lack palatable alternatives.

I agree that is the point the draft is trying to make.  My complaint 
is that it does not justify the assertion that some people who are 
doing this lack palatable alternatives (e.g., by specifying what 
credible threats are mitigated by dropping non-initial fragments).

//cmh

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Oct 2012 09:23:48 -0700

> credible threats are mitigated by dropping non-initial fragments).
The authors are taking feedback and working on more text. it's clearly 
incompletely described in present form.

Where we go from here operationally is an interesting question,  As 
brian points out there are some changes  that could be made to improve  
the sitaution.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 16 Oct 2012 19:29:05 +0100

> credible threats are mitigated by dropping non-initial fragments).

is it worth mentioning cisco PFC3 based systems by name in this draft and
coming up with recommendations on whether the "platform ipv6 acl fragment
hardware forward" command should be used as a matter of course?  The
internet is still full of older cisco 6500s and 7600s, and will be for
years to come.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Oct 2012 05:18:52 -0300

> control" better than "just let non-initial fragments through"?

I think Brian was referring to hashing, rather than filtering. And when
it comes to hashing, the FL is present in all fragments, while the
upper-layer header isn't.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2012 10:59:00 +0100

> upper-layer header isn't.

That's correct. But if you're building a stateful filter, the argument
applies.

    Brian