Subject: Papers on IPv6 fragmentation

From: Fernando Gont <[email-masked]>
Date: Sun, 22 Jun 2008 07:47:13 -0300

Hello folks,

Is anybody aware of any papers with real-world data about IPv6 fragmentation?

I'd be interested in something along the lines of:
Shannon, C., Moore, D., and Claffy, K.C. 2001. Characteristics of 
Fragmented IP Traffic on Internet Links.

(but that focuses on IPv6 fragmentation, rather than v4 fragmentation).

Thanks!

Kind regards,

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 22 Jun 2008 21:22:29 +1000

Hi Fernando,

Though this may not be exactly what you are looking for, you may want
to look at some of the issues we identified a long while back with
IPv6 Tiny Fragments.

http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02

Thanks,
Vishwas

On Sun, Jun 22, 2008 at 8:47 PM, Fernando Gont <[email-masked]> wrote:
> Shannon, C., Moore, D., and Claffy, K.C. 2001. Characteristics of Fragmented
> IP Traffic on Internet Links.
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jun 2008 00:18:21 -0300

>http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02

I had a quick look at your document. Here are some quick and dirty comments:

* Your documents talk about specifying a minimum size for non-last 
fragments. Actually, I think one should be concerned only about the 
*first* fragment. That's the one that's used to create state at firewalls, etc.

* I don't think imposing such a requirement will, by itself, help to 
ensure that you have in the first packet all the information you need 
to apply firewalls rules. It would be trivial for an attacker to 
comply with such a requirement, but still do not provide all the 
relevant information that would be needed by the firewall to apply 
its rules. The attacker could just add one or several extension 
headers, with lots of PadN options. Thus, it would comply with your 
requirement, but still avoid sending e.g. the TCP source and destination ports.

Kind regards,

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 23 Jun 2008 14:44:26 +1000

Hi Fernando,

Thanks for reading through the draft.
> fragments. Actually, I think one should be concerned only about the *first*
> fragment. That's the one that's used to create state at firewalls, etc.
This is the more liberal approach you adopt to achieve the same thing.
by having a more conservative approach we reduce the attack vectors
further.

> * I don't think imposing such a requirement will, by itself, help to ensure
> that you have in the first packet all the information you need to apply
> firewalls rules. It would be trivial for an attacker to comply with such a
> requirement, but still do not provide all the relevant information that
> would be needed by the firewall to apply its rules. The attacker could just
> add one or several extension headers, with lots of PadN options. Thus, it
> would comply with your requirement, but still avoid sending e.g. the TCP
> source and destination ports.
Fernando, that is correct. However we intend to put limitations
separately on that. Suresh probably had a draft regarding the same.

Thanks,
Vishwas

On Mon, Jun 23, 2008 at 1:18 PM, Fernando Gont <[email-masked]> wrote:
> fragments. Actually, I think one should be concerned only about the *first*
> fragment. That's the one that's used to create state at firewalls, etc.
>
> * I don't think imposing such a requirement will, by itself, help to ensure
> that you have in the first packet all the information you need to apply
> firewalls rules. It would be trivial for an attacker to comply with such a
> requirement, but still do not provide all the relevant information that
> would be needed by the firewall to apply its rules. The attacker could just
> add one or several extension headers, with lots of PadN options. Thus, it
> would comply with your requirement, but still avoid sending e.g. the TCP
> source and destination ports.
>
> Kind regards,
>
> --
> Fernando Gont

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jun 2008 01:50:31 -0300

>by having a more conservative approach we reduce the attack vectors

Maybe you should clarify this in the draft?

>separately on that.

I think that both requirements should be in the same document, or 
that at least you should explicitly state that the goal cannot be met 
unless there are restriction on the maximum number of bytes allowed 
for Extension Headers.

>Suresh probably had a draft regarding the same.

Any pointers?

Kind regards,

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 23 Jun 2008 16:01:47 +1000

Hi Fernando,

RFC4842 - Section 2.1.9.5 has the details you may be looking for. We
could certainly add additional details like adding the information in
my draft too.

Thanks,
Vishwas

On Mon, Jun 23, 2008 at 2:50 PM, Fernando Gont <[email-masked]> wrote:
>> > *first*
>> > ensure
> I think that both requirements should be in the same document, or that at
> least you should explicitly state that the goal cannot be met unless there
> are restriction on the maximum number of bytes allowed for Extension
> Headers.
>
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jun 2008 03:33:44 -0300

>could certainly add additional details like adding the information in

RFC 4842?? ("Synchronous Optical Network/Synchronous Digital 
Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)"??)

P.S.: BTW, the high-order bit of my feedback on your draft is that it 
is something worth pursuing... just that I think the draft should 
clarify those two issues I pointed out.

Kind regards,

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 23 Jun 2008 16:54:14 +1000

Hi Fernando,

Thanks for your comments on my draft. The RFC number is 4942 I wrongly
tyed it the last time over http://www.ietf.org/rfc/rfc4942.txt.

Thanks,
Vishwas

On Mon, Jun 23, 2008 at 4:33 PM, Fernando Gont <[email-masked]> wrote:
> RFC 4842?? ("Synchronous Optical Network/Synchronous Digital Hierarchy
> (SONET/SDH) Circuit Emulation over Packet (CEP)"??)
>
> P.S.: BTW, the high-order bit of my feedback on your draft is that it is
> something worth pursuing... just that I think the draft should clarify those
> two issues I pointed out.
>
> Kind regards,
>
> --
> Fernando Gont