Subject: RE: draft-macaulay-6man-packet-stain-00

From: Joel jaeggli <[email-masked]>
Date: Sat, 07 Apr 2012 09:17:21 -0700

I hesitate to suggest this because I'll probably turn into a pillar of
salt at some point for harping on it. however...

Getting new extension headers generally parsed is a high bar to get
over. That said within one domain of control you might be able to fit a
subset of the information you're looking to carry into the  20 bits
available in flow label. 6437 probably provides enough cover/instruction
to allow for that.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Apr 2012 08:10:44 +0100

> salt at some point for harping on it. however...

Just don't look back (towards IPv4).

> over. 

I have another concern; this draft appears to state that some
middlebox inserts an extension header into a packet on the fly:
  "IPv6 packet staining support consists of labeling datagrams with
   security reputation information through the addition of an IPv6
   destination option in the packet header by packet manipulation
   devices (PMDs) in the carrier or enterprise network."

I'm not aware of any provision in RFC 2460 allowing this, or of any
other extension header that is inserted by a middlebox. The implications
for MTU size and fragmentation are clear.

> That said within one domain of control you might be able to fit a

Given that the first paragraph of the Introduction to the draft is almost
identical to the same paragraph in 6437, you may be on to something.
However, it's only conformant if (a) the resulting values belong to a
reasonably uniform distribution and are hard to predict and (b) the method
MUST NOT be used for packets whose flow label is already non-zero.

    Brian

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 08 Apr 2012 07:25:22 -0700

> for MTU size and fragmentation are clear.

yes, it occured to me that an alternate approach eg encapsulation would
also necessitate the generation fragmented outer packets (which would be
legal)

> MUST NOT be used for packets whose flow label is already non-zero.

If one reset the flow label at ingress due to security considerations
(namely in this case that the contents of the flow label cannot be
trusted since they contain information) then all flow labels you
encounter when it comes time to stain them, will be zero.

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 08 Apr 2012 12:33:59 -0400

>for MTU size and fragmentation are clear.

This point was brought up in the WG meeting which noted issues with
fragmentation.  I think it was clear based on numbers folks at the mic
that inserting an extension header mid-stream would result in negative
behaviours.

>MUST NOT be used for packets whose flow label is already non-zero.

The point of using the flow label seems valid.  The author will need to
re-evaluate the requirements as I believe it was noted in the WG
presentation that the Flow Label seemed to be too restrictive (size) for
this function (packet staining).  If the staining can be bounded by the
size of the flow label then perhaps the author can re-focus on using it
for this function (packet staining).

Victor K

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