Re: draft-macaulay-6man-packet-stain-00

Tyson Macaulay <> Tue, 10 April 2012 01:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8205811E8073 for <>; Mon, 9 Apr 2012 18:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wCnfM7+ttDLU for <>; Mon, 9 Apr 2012 18:52:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B8F6C21F863F for <>; Mon, 9 Apr 2012 18:52:47 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFBCF281160 for <>; Mon, 9 Apr 2012 21:47:26 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wIacpijitaG0 for <>; Mon, 9 Apr 2012 21:47:22 -0400 (EDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 3C9EA281136 for <>; Mon, 9 Apr 2012 21:47:22 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/
Date: Mon, 09 Apr 2012 21:52:40 -0400
Subject: Re: draft-macaulay-6man-packet-stain-00
From: Tyson Macaulay <>
To: ipv6 <>
Message-ID: <>
Thread-Topic: draft-macaulay-6man-packet-stain-00
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 01:52:48 -0000

Indeed, when I presented in Paris there were excellent comments about
fragmentation.  The draft is being revised to express that the approach
(staining) is intended for use within a "domain of control" as Joel put
it, or from a domain, such as a carrier domain, downstream to a
subscribing enterprise domain.  The intent was not to stain packets, let
them find their way across the internet, and expect nothing to break.  I
acknowledge that the current draft, and my even presentation, lends itself
to that interpretation.

As for the flow label option within a domain of control, that is certainly
another possibility we considered but then rejected because of the move
towards using the flow label for load balancing.

Within an Enterprise domain (all flows based on ULAs?), then perhaps the
flow label could be re-purposed for either threat/reputation intelligence
or as a form of very light-weight layer 3 authentication for end-points
with little memory or processing power.(?) For instance, if the value
(stain) in the flow label (or Destination Option) is not the expected
value - reject the packet.

At this time I am considering extracting and clarifying the problem
statement (timely delivery of threat/reputation intelligence) from the
draft, and re-issuing it as an informational draft. Just see get that part

There appears to be more than one way that IPv6 can address this matter,
assuming we agree on the problem.


>Message: 3
>Date: Sun, 08 Apr 2012 12:33:59 -0400
>From: Victor Kuarsingh <>
>To: Brian E Carpenter <>om>,	Joel jaeggli
>	<>
>Cc: 6man <>
>Subject: Re: draft-macaulay-6man-packet-stain-00
>Message-ID: <>
>Content-Type: text/plain;	charset="US-ASCII"
>On 12-04-08 3:10 AM, "Brian E Carpenter" <>
>>On 2012-04-07 17:17, Joel jaeggli wrote:
>>> I hesitate to suggest this because I'll probably turn into a pillar of
>>> salt at some point for harping on it. however...
>>Just don't look back (towards IPv4).
>>> Getting new extension headers generally parsed is a high bar to get
>>> 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.
>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
>>> 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
>>> to allow for that.
>>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
>>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