Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

Joe Touch <touch@isi.edu> Thu, 01 November 2012 00:54 UTC

Return-Path: <touch@isi.edu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946B021F8858 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 17:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Level:
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UETxdgFQ1zM8 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 17:54:24 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1576021F867C for <v6ops@ietf.org>; Wed, 31 Oct 2012 17:54:24 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA10pJcb007782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Oct 2012 17:51:19 -0700 (PDT)
Message-ID: <5091C787.6060403@isi.edu>
Date: Wed, 31 Oct 2012 17:51:19 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF778@XCH-NW-01V.nw.nos.boeing.com> <507F265E.6030000@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFAE@XCH-NW-01V.nw.nos.boeing.com> <507F32DA.30600@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFC3@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C234@XCH-NW-01V.nw.nos.boeing.com> <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com> <5091907E.3090206@isi.edu> <CAKD1Yr2nzYmH07b=FXC4wQmYjC85vc6Sp2SzCsLVc8p7o_ayrg@mail.gmai! l.com>
In-Reply-To: <CAKD1Yr2nzYmH07b=FXC4wQmYjC85vc6Sp2SzCsLVc8p7o_ayrg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-taylor-v6ops-fragdrop@tools.ietf.org" <draft-taylor-v6ops-fragdrop@tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Nov 2012 00:54:24 -0000

On 10/31/2012 5:35 PM, Lorenzo Colitti wrote:
> On Thu, Nov 1, 2012 at 5:56 AM, Joe Touch <touch@isi.edu
> <mailto:touch@isi.edu>> wrote:
>
>     I'm wondering whether routers that drop fragments do so only when
>     that's the first option, or do they just drop packets with *any*
>     options?
>
>
> Routers just do what operators configure them to do.

Not everything; as you note below, some aspects of the configuration are 
limited by capability.

However, you've answered the key issue - this is not about fragments, 
but rather about two things:

a) DPI
	DPI cannot be done on packets with any options
	so this either means operators need to ignore DPI
	on such packets or drop them

There are certainly places where DPI is expected (e.g., by a 
government), and so only DPI-capable packets are permitted, but this 
doesn't seem tenable anywhere except at the boundaries of customer 
networks (otherwise all encrypted traffic would be dropped all over the 
place, and that doesn't appear to be happening)

b) support for ANY HBH options
	unfortunately, this is very difficult to determine
	unless fragmentation or a known destination option occurs

I.e., there's no structure to the option numbers that makes it easy to 
say "there are no more HBH options", so the best that can be done here 
is, as you note, "drop all packets with any options".

Again, however, that doesn't necessarily mean all remaining packets can 
be DPI processed.

Joe