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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 08 April 2012 07:10 UTC

Return-Path: <brian.e.carpenter@gmail.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 5D00221F857F for <ipv6@ietfa.amsl.com>; Sun, 8 Apr 2012 00:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.648
X-Spam-Level:
X-Spam-Status: No, score=-101.648 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 Pof7ZQJpr7k2 for <ipv6@ietfa.amsl.com>; Sun, 8 Apr 2012 00:10:56 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6699821F8522 for <ipv6@ietf.org>; Sun, 8 Apr 2012 00:10:50 -0700 (PDT)
Received: by werb10 with SMTP id b10so2491957wer.31 for <ipv6@ietf.org>; Sun, 08 Apr 2012 00:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8DcuG8gmyASOT1on2cE+YvXpVuPbZ7O30hRc91P6KSc=; b=JlEkmgQ4P3kdblVSXKYinyDxuN2KQh/lBB8g1wHpo5ijCQNCWhkmfNL95IpG4fvk4c n7pZnMAbH+Tgq9mM9bQdyhqDrzhzV8LUWsRAVw5VQ42a230tdLIIoHWGeVIpjbg+xm+I dLpKhDoDaXLwYfD6GWyzV93vc3d7MTLEgU1E/zFgeA5NsqP8WNEBWFDiqDDfX79Qu1VU WKCxjuQXhGcLFZ4nLww1tauyESWCmdkdBCwcLBd6q24T3OQ/lIPZR3xhJ84JFfSnlS5p aT+x+bpVr2mZ256Z6dmOCQ8nkNDuwisEOiYRi3XzvBz8I3WfvC+rLIBcXH4a8T6wb9Hc iZAA==
Received: by 10.180.88.199 with SMTP id bi7mr7487384wib.12.1333869049426; Sun, 08 Apr 2012 00:10:49 -0700 (PDT)
Received: from [192.168.1.69] (host-2-102-219-159.as13285.net. [2.102.219.159]) by mx.google.com with ESMTPS id n8sm32955978wix.10.2012.04.08.00.10.47 (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 00:10:48 -0700 (PDT)
Message-ID: <4F8139F4.6030508@gmail.com>
Date: Sun, 08 Apr 2012 08:10:44 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Joel jaeggli <joelja@bogus.com>
Subject: Re: draft-macaulay-6man-packet-stain-00
References: <4F806891.8090403@bogus.com>
In-Reply-To: <4F806891.8090403@bogus.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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 07:10:57 -0000

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.

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

    Brian