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

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 17 October 2012 22:26 UTC

Return-Path: <Fred.L.Templin@boeing.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 8742621F866C for <v6ops@ietfa.amsl.com>; Wed, 17 Oct 2012 15:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level:
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599]
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 U0HaHDSZo6st for <v6ops@ietfa.amsl.com>; Wed, 17 Oct 2012 15:26:17 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id EB95421F84C4 for <v6ops@ietf.org>; Wed, 17 Oct 2012 15:26:16 -0700 (PDT)
Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9HMQGF2023218 for <v6ops@ietf.org>; Wed, 17 Oct 2012 17:26:16 -0500
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9HMQEqF022730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 17 Oct 2012 17:26:15 -0500
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Wed, 17 Oct 2012 15:26:14 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Nick Hilliard <nick@inex.ie>
Date: Wed, 17 Oct 2012 15:26:12 -0700
Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop
Thread-Index: Ac2ssG35+n6LXwaJTrasH+FfXnik/wABRpqw
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFAE@XCH-NW-01V.nw.nos.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>
In-Reply-To: <507F265E.6030000@inex.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: No
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: Wed, 17 Oct 2012 22:26:17 -0000

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

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