Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Ole Troan <otroan@employees.org> Mon, 30 July 2018 07:35 UTC

Return-Path: <otroan@employees.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F771130EA0; Mon, 30 Jul 2018 00:35:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piFfib1JKpuP; Mon, 30 Jul 2018 00:35:07 -0700 (PDT)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAF4130E64; Mon, 30 Jul 2018 00:35:07 -0700 (PDT)
Received: from h.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id EB8CE2D4F96; Mon, 30 Jul 2018 07:35:05 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1283B2033E302E; Mon, 30 Jul 2018 09:33:47 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <5EC9671E-2750-4EC9-B8C5-C86E1C4C513D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_43059A97-1F9E-4A31-9730-B38660369937"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 30 Jul 2018 09:33:45 +0200
In-Reply-To: <A248CA44-B568-4CB9-B450-067B1845AF9B@strayalpha.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, "internet-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
To: Joe Touch <touch@strayalpha.com>
References: <F227637E-B12D-45AA-AD69-74C947409012@ericsson.com> <0466770D-C8CA-49BB-AC10-5805CFDFB165@strayalpha.com> <6EDF0F79-C8F3-4F05-8442-FF55576ADDD0@employees.org> <alpine.DEB.2.20.1807271530280.14354@uplift.swm.pp.se> <CALx6S35LthDLRry7k-pF8KSoX4BXBA8kyArOpDUAcJMDCoLQpQ@mail.gmail.com> <alpine.DEB.2.20.1807280811540.14354@uplift.swm.pp.se> <8640DCF6-A525-4CF7-A89D-2DEDBF0FADC8@strayalpha.com> <FFF1C23B-7A24-46BC-929E-DD56C77D69A2@employees.org> <A248CA44-B568-4CB9-B450-067B1845AF9B@strayalpha.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/7q-QzO_j7bC8ABniznB4cP1I1_o>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 07:35:10 -0000

Joe,

>> However much money you throw at it, you can't reassemble fragments travelling on different paths, nor can you trivially make network layer reassembly not be an attack vector on those boxes.
> 
> Agreed, but here’s the other point:
> 
> 	Any device that inspects L4 content can do so ONLY as a proxy for the destination endpoint.
> 
> I.e., I know vendors WANT to sell devices they say can be deployed anywhere in the network, and operators believe that, but it’s wrong.
> 
> Basically, if you’re not at a place in the network where you represent that endpoint, you have no business acting as that endpoint - “full stop”.

I understand you want it to fit in your model, but it doesn't.
Take A+P (RFC6346), and it's instantiations through e.g. MAP-E (RFC7597). That's essentially normal longest match forwarding on addresses and ports.

With regards to your point about reassembly at higher layers, crypto is the answer to that.

Ole