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

Joe Touch <touch@strayalpha.com> Mon, 30 July 2018 13:44 UTC

Return-Path: <touch@strayalpha.com>
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 C212F1310C6; Mon, 30 Jul 2018 06:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 KoMOlf6AH45M; Mon, 30 Jul 2018 06:44:21 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E34130E2C; Mon, 30 Jul 2018 06:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vrMUs44I22XbyuJYttarWudIBdvb9lvROh52P2QXUwU=; b=tLsh7lxl7J79iXhKnI/dWySuO Ev7eFA78/eQmhLE3L4yz6DAZnKcDqXdv7D3El/VIS3PMuFb1fDbkKKcfHljV+exiejM/cSZbMUeQ3 hTJsJHJ6Ee2GIIlS8bgvu2WJkBwN8cPSEiDdxA+QHkjaAPmLkqU7PJ+sXE1eF4d4vCxpLWJAbWMZS qVKAaPd/BtJwce7t6S4PgpjXHKqYMap21szFbAWW29/mXfMkbFSflN2CTmc7/0iOZYGWafosDWsef FA82nfPK8uM2vAfH76kqMGULtZ48dGzWy2h5XGHLpdBaIcZNm7tMfajfCXNbJ08fFTxswS5BHX8jo qCzAnU/Rg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:55566 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1fk8TD-0026Lw-CS; Mon, 30 Jul 2018 09:44:20 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <5EC9671E-2750-4EC9-B8C5-C86E1C4C513D@employees.org>
Date: Mon, 30 Jul 2018 06:44:17 -0700
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, "internet-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <99184125-6B2A-4F21-9D51-21015E54E9D4@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> <5EC9671E-2750-4EC9-B8C5-C86E1C4C513D@employees.org>
To: Ole Troan <otroan@employees.org>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/RLbSJY34ikROYrO9dXfwyXma3MU>
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 13:44:23 -0000


> On Jul 30, 2018, at 12:33 AM, Ole Troan <otroan@employees.org> wrote:
> 
> 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.

My model describes the rules under which translation devices can operate correctly and predictably in the Internet model.

There are only a few alternatives for devices not explained by either model:
	1- the Internet and my model are incomplete
		in that case, you’re welcome to provide one for the new device
	2- the Internet and/or my model are incorrect
		in that case, you’re welcome to explain why
	3- the device should be considered incorrect and itself corrected

Un-doing fragmentation at IP is an attempt to jump to a solution for #1 without explaining WHY, other than “we need to do this to fix the Internet to support these new devices”.

I don’t think we should break known models to adapt to devices whose behavior might never be correctly accommodated.

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

So? Any device that sources packets with addresses it owns IS an endpoint on the Internet. Nothing changes based on how it translates those devices to the private side.

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

Crypto will just end up putting a halt to all this nonsense - but not quickly enough, IMO.

Then again, I would not be surprised to be back here discussing a doc on “transport crypto considered fragile” in a decade...

Joe