Subject: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments

From: Brian Haberman <[email-masked]>
Date: Mon, 16 Jan 2012 15:23:12 -0500

All,
     This is a consensus call on adopting:

     Title     : Processing of IPv6 "atomic" fragments
     Author(s) : Fernando Gont
     Filename  : draft-gont-6man-ipv6-atomic-fragments-00.txt
     Pages     : 12
     Date      : 2011-12-15

as a 6MAN working group document.  Please state your opinion, positive
or negative, on the mailing list or to the chairs.  This consensus call
will end on January 31, 2012.

Regards,
Brian & Bob

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Jan 2012 08:23:15 -0500

> will end on January 31, 2012.

I support adoption of this document as a WG item.

An implementation has been committed yesterday to OpenBSD's IPv6 stack:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/frag6.c#rev1.42

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Arturo Servin <[email-masked]>
Date: Thu, 26 Jan 2012 10:59:02 -0200

Support to adopt as WG document.

	Couple of questions.

Fernando,

	When you say "Namely, they try to perform IPv6
   reassembly with the "atomic fragment" and any other fragments already
   queued with the same set {IPv6 Source Address, IPv6 Destination
   Address, Fragment Identification}." If there is just one packet what happen? Does the host just hang in there waiting for the next fragment (that possibly will never arrive) until it times out?

	Also, you quoted RFC2640 "In response to an IPv6 packet that is sent to an IPv4 destination
      (i.e., a packet that undergoes translation from IPv6 to IPv4) …" I wonder if there is any negative implication for IPv4/IPv6 translators if atomic fragments are forbidden as proposed.

Regards,
.as

On 16 Jan 2012, at 18:23, Brian Haberman wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Jan 2012 11:00:25 -0300

[Subject changed so that this doesn't "mix" with the poll]

Hi, Arturo,

On 01/26/2012 09:59 AM, Arturo Servin wrote:
> When you say "Namely, they try to perform IPv6 reassembly with the
> "atomic fragment" and any other fragments already queued with the
> same set {IPv6 Source Address, IPv6 Destination Address, Fragment
> Identification}." If there is just one packet what happen? Does the
> host just hang in there waiting for the next fragment (that possibly
> will never arrive) until it times out?

I didn't test *this* one (will do this weekend, and let you know). But
they *do* mix the atomic fragment with fragments present in the fragment
queue. That is, the attacker (knowing that you're relying on atomic
fragments) can send lots of forged fragments to the victim system, such
that when your legitimate fragments arrive at the victim they get mixed
up with the malicious fragments, and hence they get discarded.

> Also, you quoted RFC2640 "In response to an IPv6 packet that is sent
> to an IPv4 destination (i.e., a packet that undergoes translation
> from IPv6 to IPv4) …" I wonder if there is any negative implication
> for IPv4/IPv6 translators if atomic fragments are forbidden as
> proposed.

Dan Wing has noted that forbidding atomic fragments breaks RFC 6144. It
would also break the DNS if atomic fragments are employed for it.

That's why draft-gont-6man-ipv6-atomic-fragments does *not* forbid
atomic fragments, but rather improves the their processing at the
receiving node.

Essentially, what this proposal says "If you receive an atomic fragment,
don't 'merge it' with fragmented traffic, but just remove the
Fragmentation Header and process the packet as if it was not fragmented".

Thanks!

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

---

From: Arturo Servin <[email-masked]>
Date: Fri, 27 Jan 2012 12:39:52 -0200

Thanks. It is clear now.

.as

---

From: Tore Anderson <[email-masked]>
Date: Mon, 30 Jan 2012 12:25:37 +0100

* Brian Haberman

> as a 6MAN working group document.

Support.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com

---

From: Timothy Hartrick <[email-masked]>
Date: Mon, 30 Jan 2012 08:26:53 -0800

Brian,

I support this work.

Tim Hartrick