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

Joel jaeggli <joelja@bogus.com> Sun, 08 April 2012 14:25 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1934B21F852A for <ipv6@ietfa.amsl.com>; Sun, 8 Apr 2012 07:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.676
X-Spam-Level:
X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBViUBCB+thi for <ipv6@ietfa.amsl.com>; Sun, 8 Apr 2012 07:25:27 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 296F621F84FE for <ipv6@ietf.org>; Sun, 8 Apr 2012 07:25:25 -0700 (PDT)
Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q38EPNbK063471 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 8 Apr 2012 14:25:23 GMT (envelope-from joelja@bogus.com)
Message-ID: <4F819FD2.4000401@bogus.com>
Date: Sun, 08 Apr 2012 07:25:22 -0700
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: draft-macaulay-6man-packet-stain-00
References: <4F806891.8090403@bogus.com> <4F8139F4.6030508@gmail.com>
In-Reply-To: <4F8139F4.6030508@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 08 Apr 2012 14:25:23 +0000 (UTC)
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2012 14:25:28 -0000

On 4/8/12 00:10 , Brian E Carpenter wrote:
> 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.

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

>> 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.
> 
> 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.

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.

>     Brian
>