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

joel jaeggli <joelja@bogus.com> Thu, 18 October 2012 07:07 UTC

Return-Path: <joelja@bogus.com>
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 53DAF21F85DA for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 00:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.073
X-Spam-Level:
X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 qHfCnp2AskLT for <v6ops@ietfa.amsl.com>; Thu, 18 Oct 2012 00:07:50 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA42521F85A7 for <v6ops@ietf.org>; Thu, 18 Oct 2012 00:07:50 -0700 (PDT)
Received: from joels-MacBook-Air.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 q9I77h9j059908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 18 Oct 2012 07:07:44 GMT (envelope-from joelja@bogus.com)
Message-ID: <507FAABE.5050601@bogus.com>
Date: Thu, 18 Oct 2012 00:07:42 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121002 Thunderbird/16.0
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.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>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFAE@XCH-NW-01V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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]); Thu, 18 Oct 2012 07:07:48 +0000 (UTC)
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, 18 Oct 2012 07:07:51 -0000

On 10/17/12 3:26 PM, Templin, Fred L wrote:
>
>> -----Original Message-----
>> From: Nick Hilliard [mailto:nick@inex.ie]
>> Sent: Wednesday, October 17, 2012 2:43 PM
>> To: Templin, Fred L
>> Cc: v6ops@ietf.org; draft-taylor-v6ops-fragdrop@tools.ietf.org
>> Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
>>
>> On 17/10/2012 16:39, Templin, Fred L wrote:
>>> You know, all of this discussion is moot. RFC2460, Section 5 says:
>> [...]
>>> the law until someone writes a different one. Middleboxes therefore
>>> have no basis for dropping fragments, unless they can through some
>>> means be determined as malicious (e.g., VFR).
>> We're all agreed that legitimate fragments should get through.  But there
>> is a large body of installed hardware out there in the core of the
>> Internet
>> which has exactly the following options for dealing with ipv6 fragments:
>>
>>> 1. forward them to the RP for software processing, which will cause a
>>> management plane DoS
>>> 2. drop them unilaterally, implicitly overriding all v6 ACLs, breaking
>>> IPv6 fragmentation
>>> 3. forward them unilaterally, implicitly overriding all ACLs, opening up
>>> an infrastructure DoS vector
>> None of these are pleasant options.
>>
>> It's not a moot point: it's just a matter of the equipment not matching up
>> with the requirements of the RFCs and is a serious practical problem for
>> operators which use older equipment.  So how do we deal with it?  Does it
>> deserve a mention in the draft, with recommendations on what to do, or
>> would it be better to ignore the problem as it's a vendor/device specific
>> issue?
> In order to correctly observe the standards, core routers have no
> option other than to simply forward any IPv6 fragments that are
> "just passing through" - regardless of any configurable options
> available on certain vendor products.
The focus on core devices is misguided imho... The services edge of my 
network where both connections terminate and policy is applied may be 
substantially higher capacity than the backbone of many networks it is 
exposed to this issue. Given that I am an end-site all traffic carried 
on a backbone is either coming from or in bound to an end system on our 
network.
> IPv6 fragmentation and reassembly is an end-to-end function, and
> according to the end-to-end principles the function is best
> implemented either within the end system or as close to the end
> system as possible. The core needs to let the edge devices and
> end systems deal with fragments, and even if fragments are passed
> all the way through to the end system without prior examination
> end systems nowadays have host-based firewalls.
>
> I think we may be over-thinking this. Vendor equipment needs
> to observe the standards in order to claim compliance. Broken
> equipment should be identified and reported when it does not.
>
> Fred
> fred.l.templin@boeing.com
>   
>> Nick
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>