From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp92.iad3a.emailsrvr.com (smtp92.iad3a.emailsrvr.com [173.203.187.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A19033B29E for ; Tue, 13 Aug 2019 22:26:17 -0400 (EDT) Received: from smtp4.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6F14142F8; Tue, 13 Aug 2019 22:26:17 -0400 (EDT) X-SMTPDoctor-Processed: csmtpprox beta Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 55CB8420D; Tue, 13 Aug 2019 22:26:17 -0400 (EDT) X-Sender-Id: dpreed@deepplum.com Received: from app50.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 13 Aug 2019 22:26:17 -0400 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app50.wa-webapps.iad3a (Postfix) with ESMTP id 3DAFC60046; Tue, 13 Aug 2019 22:26:17 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Tue, 13 Aug 2019 22:26:17 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Tue, 13 Aug 2019 22:26:17 -0400 (EDT) From: "David P. Reed" To: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Cc: "Michael Richardson" , "ECN-Sane" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <201908132121.x7DLLxfu018119@gndrsh.dnsmgr.net> References: <201908132121.x7DLLxfu018119@gndrsh.dnsmgr.net> Message-ID: <1565749577.248813006@apps.rackspace.com> X-Mailer: webmail/16.4.7-RC 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: Wed, 14 Aug 2019 02:26:17 -0000 I'm pretty sure it was stated in Cerf and Kahn's paper "A Transmission Cont= rol Protocol" as published in IEEE Proceedings. I know it was in the Transm= ission Control Protocol Working Group email and paper documents, though I d= on't have a personal copy. Is it in an RFC? Probably. It's important to rem= ember that RFC's were literally Requests for Comment in the 1970's. They we= ren't the entire record.=0A=0ABut this kind of gradual rot does creep into = systems design communities. THat's why I'm wondering whether the rationale = and decisions ought to be restated.=0A=0AOn Tuesday, August 13, 2019 5:21pm= , "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> said:=0A=0A>> I'm of a mind = to suggest an RFC specifically reiterating that non-endpoints MUST=0A>> nev= er modify the content part of any IP datagrams, ever, with the exception of= =0A>> the TCP and UDP extended routing header (the ports), and that solely = for the=0A>> purpose of implementing NAT as defined in the NAT standard.=0A= > =0A> Now I think you really mean to say "modify the content part of any I= P datagram=0A> PAYLOAD, ever" I am in agreement, the IP header itself is go= ing to get modified a=0A> lot.=0A> =0A>>=0A>> I think vint Cerf and I would= be happy to be co-authors, maybe along with Dave=0A>> Clark, Noel Chiappa,= and a crew of original Internet Protocol designers.=0A>>=0A>> I had though= t this was a well-understood invariant, core to the design of the=0A>> enti= re Internet.=0A> =0A> People forget history, reasons, etc, I am not even su= re that it is well documented=0A> that IP payload should not be modified, t= hough it may be well known information in=0A> some cicles, I would say that= circle is of diminishing size.=0A> =0A>>=0A>> Part of the reason, but cert= ainly not all of it, was that we all intended that=0A>> the content within = the IP datagram contents would be treated as sacrosanct, as if=0A>> encrypt= ed by a key unknown to the network.=0A> =0A> Isnt it interesting that they = are actually proposing that now to protect the IP=0A> payload from the mali= cious crap that is going on, your proposal would make a rule,=0A> the encry= ption solution would silently enforce that rule without question.=0A> =0A>>= We could not require end-to-end encryption because of ITAR rules at the ti= me. But=0A>> it is absolutely clear that NOTHING in the network transport s= ystem was expected=0A>> to attempt to understand or to modify those bits un= til they reached the=0A>> destination, unchanged.=0A>>=0A>> It wasn't just = a "good idea", it was a design requirement.=0A> =0A> Perhaps a poorly docum= ented one? Can you site any RFC verbage that addresses=0A> this?=0A> =0A> = I would support any effort to codify this in a I-D.=0A> =0A>> On Tuesday, A= ugust 13, 2019 12:39pm, "Michael Richardson" =0A>> said:= =0A>>=0A>> > Thanks.=0A>> > Also a good story as to why middle boxes should= stay away from mangling=0A>> > packets without an audit trail.=0A>> >=0A>>= =0A> =0A> --=0A> Rod Grimes = rgrimes@freebsd.org=0A> =0A