From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <4bone@gndrsh.dnsmgr.net> Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 31ECF3B29E for ; Tue, 13 Aug 2019 17:22:04 -0400 (EDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x7DLM0Ah018120; Tue, 13 Aug 2019 14:22:00 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net) Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x7DLLxfu018119; Tue, 13 Aug 2019 14:21:59 -0700 (PDT) (envelope-from 4bone) From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Message-Id: <201908132121.x7DLLxfu018119@gndrsh.dnsmgr.net> In-Reply-To: <1565728110.2365220@apps.rackspace.com> To: "David P. Reed" Date: Tue, 13 Aug 2019 14:21:59 -0700 (PDT) CC: Michael Richardson , ECN-Sane X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Re: [Ecn-sane] cautionary tcp tale X-BeenThere: ecn-sane@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of explicit congestion notification's impact on the Internet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 21:22:04 -0000 > I'm of a mind to suggest an RFC specifically reiterating that non-endpoints MUST never modify the content part of any IP datagrams, ever, with the exception of the TCP and UDP extended routing header (the ports), and that solely for the purpose of implementing NAT as defined in the NAT standard. Now I think you really mean to say "modify the content part of any IP datagram PAYLOAD, ever" I am in agreement, the IP header itself is going to get modified a lot. > > I think vint Cerf and I would be happy to be co-authors, maybe along with Dave Clark, Noel Chiappa, and a crew of original Internet Protocol designers. > > I had thought this was a well-understood invariant, core to the design of the entire Internet. People forget history, reasons, etc, I am not even sure that it is well documented that IP payload should not be modified, though it may be well known information in some cicles, I would say that circle is of diminishing size. > > Part of the reason, but certainly not all of it, was that we all intended that the content within the IP datagram contents would be treated as sacrosanct, as if encrypted by a key unknown to the network. Isnt it interesting that they are actually proposing that now to protect the IP payload from the malicious crap that is going on, your proposal would make a rule, the encryption solution would silently enforce that rule without question. > We could not require end-to-end encryption because of ITAR rules at the time. But it is absolutely clear that NOTHING in the network transport system was expected to attempt to understand or to modify those bits until they reached the destination, unchanged. > > It wasn't just a "good idea", it was a design requirement. Perhaps a poorly documented one? Can you site any RFC verbage that addresses this? I would support any effort to codify this in a I-D. > On Tuesday, August 13, 2019 12:39pm, "Michael Richardson" said: > > > Thanks. > > Also a good story as to why middle boxes should stay away from mangling > > packets without an audit trail. > > > -- Rod Grimes rgrimes@freebsd.org