From nobody Mon Jul 18 09:59:33 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDB12DAF5; Mon, 18 Jul 2016 09:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 59NgJrYsbaJh; Mon, 18 Jul 2016 09:59:29 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1AB12DB09; Mon, 18 Jul 2016 09:59:28 -0700 (PDT) Received: from EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 18 Jul 2016 17:59:24 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMHT03-UKBR.domain1.systemhost.net (193.113.108.56) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 18 Jul 2016 17:59:26 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 17:59:26 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 17:59:26 +0100 From: To: , Subject: Request for note takers and jabber scribe for L4S BoF Thread-Topic: Request for note takers and jabber scribe for L4S BoF Thread-Index: AdHhFNkt1/yn7sXhRj6n1ieTS3tC8g== Date: Mon, 18 Jul 2016 16:59:25 +0000 Message-ID: <4c49d7be2c244dffa5a94098793eb333@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.216.161.29] Content-Type: multipart/alternative; boundary="_000_4c49d7be2c244dffa5a94098793eb333rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 16:59:32 -0000 --_000_4c49d7be2c244dffa5a94098793eb333rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have the L4S BoF tomorrow 2pm-4pm. We need a couple of people to take notes and also someone to watch /scribe = in the jabber room. Please let us know if you can volunteer (it would be great to get volunteer= s in advance, so we don't use up meeting time) Thanks Phil & Lars (L4S BoF Chairs) --_000_4c49d7be2c244dffa5a94098793eb333rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have the L4S BoF tomorrow 2pm-4pm.

We need a couple of people to take notes and also so= meone to watch /scribe in the jabber room.

Please let us know if you can volunteer (it would be= great to get volunteers in advance, so we don’t use up meeting time)=

 

Thanks

Phil & Lars (L4S BoF Chairs)

 

--_000_4c49d7be2c244dffa5a94098793eb333rew09926dag03bdomain1sy_-- From nobody Wed Jul 27 05:41:45 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5B12E173 for ; Wed, 27 Jul 2016 05:41:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qhc8n1LBxj_x for ; Wed, 27 Jul 2016 05:41:40 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 AC75812E16F for ; Wed, 27 Jul 2016 05:41:40 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id AB113426A; Wed, 27 Jul 2016 14:41:36 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: TCP proxys in mobile networks Date: Wed, 27 Jul 2016 14:41:36 +0200 Message-Id: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> To: tsv-area@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 12:41:43 -0000 Hi! Spencer asked me to bring up this issue, that originated on the TRAM = mailing list on the topic of STUN discovery of middle boxes. In a few projects, we=E2=80=99ve seen strange things happening when = using mobile networks. Wireshark on a server tells us a message has left and is confirmed delivery by the TCP layer - but nothing appears using = Wireshark on the other end. Seeing a mail message on a SIP implementors mailing list that one vendor = have started using UDP-style retransmits when using TCP as a transport made me starting to worry that this was a more = widespread problem. If I understand it right, mobile carriers are implementing some sort of = middlebox that act as a TCP proxy. I guess the idea is that they want to disable retransmits on the radio, so they confirm = reliable delivery prematurely. If something goes wrong beyond the proxy, it=E2=80=99s too late to do anything about it. I had a few discussions about this with fellows at IETF in Berlin and it = seemed like a known problem. One developer pointed me to a paper discussing this. https://www.cs.montana.edu/mwittie/publications/Goel16Detecting.pdf =46rom the abstract: "In current cellular networks, a myriad of middleboxes disregard the = end-to-end principle to enable network operators to deploy services such = as content caching, compression, and protocol optimization to improve = end-to-end network performance.=E2=80=9D Good reading! (and a bit scary) This mess caused me sadly to suggest that we need to discuss breaking = the assumption that TCP delivery is always reliable and implement retransmits even over TCP in the STUN protocol. STUN was = designed to discover middleboxes with a focus on NAT. This is just another middle box to discover. The bigger picture is even more scary - what happens if our reliable = transport suddenly no longer is reliable? One developer from a well known mobile system vendor said =E2=80=9Cwell, = I guess that using TLS may help=E2=80=9D=E2=80=A6 Have you seen this behaviour in networks close to you? What are your = experiences? /O= From nobody Wed Jul 27 08:18:57 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541AA12DC28 for ; Wed, 27 Jul 2016 08:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 jw4nVcpgwNYV for ; Wed, 27 Jul 2016 08:18:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9E312DBAF for ; Wed, 27 Jul 2016 08:18:55 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6RFICB9015057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2016 08:18:22 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: "Olle E. Johansson" , tsv-area@ietf.org References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> From: Joe Touch Message-ID: <5798D0B2.1040203@isi.edu> Date: Wed, 27 Jul 2016 08:18:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 15:18:56 -0000 Olle, On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > ... > > This mess caused me sadly to suggest that we need to discuss breaking the assumption that TCP delivery is always reliable > and implement retransmits even over TCP in the STUN protocol. STUN was designed to discover middleboxes > with a focus on NAT. This is just another middle box to discover. None of this is news. One of the "features" of middleboxes is "transparent" TCP relaying. That device always destroys TCP reliable delivery semantics. This has been known since the mid 90s'. The challenge with STUN has always been that many middleboxes *do not want to be found*. > The bigger picture is even more scary - what happens if our reliable transport suddenly no longer is reliable? > > One developer from a well known mobile system vendor said “well, I guess that using TLS may help”… Ask them *how* they think TLS helps. TLS relies on TCP semantics. Joe From nobody Wed Jul 27 08:27:47 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4754912DCA4 for ; Wed, 27 Jul 2016 08:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wzMmt_oq-rrl for ; Wed, 27 Jul 2016 08:27:44 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3E412D85B for ; Wed, 27 Jul 2016 08:27:44 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j12so59759781ywb.2 for ; Wed, 27 Jul 2016 08:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x3uneTkE4/C8D9KnSQDpwIT4UHjkqM9nfsTGnUwSZ8I=; b=gc3DyeHn6yVZuGUPhbJb5Tk8PAlIgF11mv7L1dCKha2OJIL1AjfCyzzXZ3hqif4TdW fzXTyny3vY+NwTvXANJyAKDQlkWIF6+O4IVDsyQwejYSuRfUPlbLEAEAlrMrF8jbO5eJ IWaP2sR22+eM7zZA6EkL9KbD7QzL62jPins4TxTvb6gselluUlFcv27kp+MD7AEWu7cx ZyIAqGzocFAWuGmG8h5c5a9LjELnFCOWWbNmahyAdmY6uvA/EyzQrHkxQtFajDVNna2C 2AlKo+olzMs0+oZ3w0ydXXiKz4tv5biRtC6emjeUrsjjkZ01+82AzvDE7VU8RMo3WWhG E/Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x3uneTkE4/C8D9KnSQDpwIT4UHjkqM9nfsTGnUwSZ8I=; b=jETgWZJ7N8B0iG71ehs20GiPFTJrfHcHrTLG6E7zu+ghXB+EHzD0iXfqU/w+YQ3Hc0 BA/XfjIOScqGiQXqdSoCG0yFmY6nydZbqVllLJnOns+dl5BL3/M3rg40L9xKMchIlAM2 rAccUZMRF40aD7oNZej3McUPNu5flYpGWhh7INueBFywNzfWbkpOOhrbrvV5qNxw0DYM kAtrIrgUNlX5OWxEWF9UXdYLdjnYLDYnDrgp6EHNdNtgd0D4gFOzgSZPX8HUtnWE7AhP Sie45Eiw0MniG0gq8vEdyj85RjDPE1b+MxOcTOvR6eAffYqr3cctAwUWsNCMoNJ7Tm1W BI8w== X-Gm-Message-State: AEkoouswR6y99Skktpy6H+5IsSGe3x/HEoxX3DeYetVpkDkDzNLR6qYlJ12BSau0+gjZRvH40azPUbcQEwJ/Xg== X-Received: by 10.37.230.141 with SMTP id d135mr24952277ybh.111.1469633263633; Wed, 27 Jul 2016 08:27:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.20 with HTTP; Wed, 27 Jul 2016 08:27:42 -0700 (PDT) In-Reply-To: <5798D0B2.1040203@isi.edu> References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> From: Spencer Dawkins at IETF Date: Wed, 27 Jul 2016 10:27:42 -0500 Message-ID: Subject: Re: TCP proxys in mobile networks To: Joe Touch Content-Type: multipart/alternative; boundary=94eb2c03e312a10a9805389fa884 Archived-At: Cc: "tsv-area@ietf.org >> tsv-area@ietf.org" , "Olle E. Johansson" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 15:27:46 -0000 --94eb2c03e312a10a9805389fa884 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Joe, On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch wrote: > Olle, > > On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > > ... > > > > This mess caused me sadly to suggest that we need to discuss breaking > the assumption that TCP delivery is always reliable > > and implement retransmits even over TCP in the STUN protocol. STUN was > designed to discover middleboxes > > with a focus on NAT. This is just another middle box to discover. > None of this is news. One of the "features" of middleboxes is > "transparent" TCP relaying. That device always destroys TCP reliable > delivery semantics. > > This has been known since the mid 90s'. Right. IIRC, you and I were part of a number of conversations about this in PILC, while working on https://www.ietf.org/rfc/rfc3135.txt. My reason for asking Olle to bring this forward is that we're having a lot of conversations (starting at the IAB with https://www.iab.org/activities/workshops/marnew/ and headed toward IETF working groups) with wireless carriers about encryption and about UDP-based transports, and I wanted to level-set on what people are (still) seeing these days. Thanks, Spencer > The challenge with STUN has always been that many middleboxes *do not > want to be found*. > > > The bigger picture is even more scary - what happens if our reliable > transport suddenly no longer is reliable? > > > > One developer from a well known mobile system vendor said =E2=80=9Cwell= , I guess > that using TLS may help=E2=80=9D=E2=80=A6 > > Ask them *how* they think TLS helps. TLS relies on TCP semantics. > > Joe > > --94eb2c03e312a10a9805389fa884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Joe,

On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch <<= a href=3D"mailto:touch@isi.edu" target=3D"_blank">touch@isi.edu> wrote:
Olle,

On 7/27/2016 5:41 AM, Olle E. Johansson wrote:
> ...
>
> This mess caused me sadly to suggest that we need to discuss breaking = the assumption that TCP delivery is always reliable
> and implement retransmits even over TCP in the STUN protocol. STUN was= designed to discover middleboxes
> with a focus on NAT. This is just another middle box to discover.
None of this is news. One of the "features" of middleboxes= is
"transparent" TCP relaying. That device always destroys TCP relia= ble
delivery semantics.

This has been known since the mid 90s'.

Right. IIRC, you and I were part of a number of conversations about this i= n PILC, while working on=C2=A0https://www.ietf.org/rfc/rfc3135.txt.=C2=A0

My reason for asking Olle to bring this forward is that we're having = a lot of conversations (starting at the IAB with=C2=A0https://www.iab.org/activities/work= shops/marnew/ and headed toward IETF working groups) with wireless carr= iers about encryption and about UDP-based transports, and I wanted to level= -set on what people are (still) seeing these days.=C2=A0

Thanks,

Spencer
=C2=A0
The challenge with STUN has always been that many middleboxes *= do not
want to be found*.

> The bigger picture is even more scary - what happens if our reliable t= ransport suddenly no longer is reliable?
>
> One developer from a well known mobile system vendor said =E2=80=9Cwel= l, I guess that using TLS may help=E2=80=9D=E2=80=A6

Ask them *how* they think TLS helps. TLS relies on TCP semantics.
Joe


--94eb2c03e312a10a9805389fa884-- From nobody Wed Jul 27 11:52:37 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125DD12D507 for ; Wed, 27 Jul 2016 11:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] 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 8xQ9mp8P24qp for ; Wed, 27 Jul 2016 11:52:34 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD60112D0AF for ; Wed, 27 Jul 2016 11:52:34 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6RIpwLi015253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 Jul 2016 11:51:58 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: Spencer Dawkins at IETF References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> From: Joe Touch Message-ID: Date: Wed, 27 Jul 2016 11:51:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3E394B10530B79A96DE497C9" X-MailScanner-ID: u6RIpwLi015253 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org >> tsv-area@ietf.org" , "Olle E. Johansson" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 18:52:36 -0000 This is a multi-part message in MIME format. --------------3E394B10530B79A96DE497C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/27/2016 8:27 AM, Spencer Dawkins at IETF wrote: > Hi, Joe, > > On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch > wrote: > > Olle, > > On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > > ... > > > > This mess caused me sadly to suggest that we need to discuss > breaking the assumption that TCP delivery is always reliable > > and implement retransmits even over TCP in the STUN protocol. > STUN was designed to discover middleboxes > > with a focus on NAT. This is just another middle box to discover. > None of this is news. One of the "features" of middleboxes is > "transparent" TCP relaying. That device always destroys TCP reliable > delivery semantics. > > This has been known since the mid 90s'. > > > Right. IIRC, you and I were part of a number of conversations about > this in PILC, while working on https://www.ietf.org/rfc/rfc3135.txt. Yup - I'm just observing that this (mis)behavior has been seen in the wild since the mid 90s. It was the topic of much discussion at the Web Caching Workshops of that era. > > My reason for asking Olle to bring this forward is that we're having a > lot of conversations (starting at the IAB > with https://www.iab.org/activities/workshops/marnew/ and headed > toward IETF working groups) with wireless carriers about encryption > and about UDP-based transports, and I wanted to level-set on what > people are (still) seeing these days. Sure - my point is that the term "transparent proxy" is common, and ALL such animals break TCP semantics *by design*. Yes, it's possible to recover TCP semantics at a higher layer using transaction confirmations, but that just sets up a game of mutual escalation - once you do that, someone will invent a transparent transaction proxy and you'll be back where you started. IMO, transparent proxies should be considered the errors the are, detected, and removed. Joe > Spencer > > > The challenge with STUN has always been that many middleboxes *do not > want to be found*. > > > The bigger picture is even more scary - what happens if our > reliable transport suddenly no longer is reliable? > > > > One developer from a well known mobile system vendor said “well, > I guess that using TLS may help”… > > Ask them *how* they think TLS helps. TLS relies on TCP semantics. > > Joe > > --------------3E394B10530B79A96DE497C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/27/2016 8:27 AM, Spencer Dawkins at IETF wrote:
Hi, Joe,

On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch <touch@isi.edu> wrote:
Olle,

On 7/27/2016 5:41 AM, Olle E. Johansson wrote:
> ...
>
> This mess caused me sadly to suggest that we need to discuss breaking the assumption that TCP delivery is always reliable
> and implement retransmits even over TCP in the STUN protocol. STUN was designed to discover middleboxes
> with a focus on NAT. This is just another middle box to discover.
None of this is news. One of the "features" of middleboxes is
"transparent" TCP relaying. That device always destroys TCP reliable
delivery semantics.

This has been known since the mid 90s'.

Right. IIRC, you and I were part of a number of conversations about this in PILC, while working on https://www.ietf.org/rfc/rfc3135.txt.

Yup - I'm just observing that this (mis)behavior has been seen in the wild since the mid 90s. It was the topic of much discussion at the Web Caching Workshops of that era.

My reason for asking Olle to bring this forward is that we're having a lot of conversations (starting at the IAB with https://www.iab.org/activities/workshops/marnew/ and headed toward IETF working groups) with wireless carriers about encryption and about UDP-based transports, and I wanted to level-set on what people are (still) seeing these days.

Sure - my point is that the term "transparent proxy" is common, and ALL such animals break TCP semantics *by design*.

Yes, it's possible to recover TCP semantics at a higher layer using transaction confirmations, but that just sets up a game of mutual escalation - once you do that, someone will invent a transparent transaction proxy and you'll be back where you started.

IMO, transparent proxies should be considered the errors the are, detected, and removed.

Joe

Spencer
 
The challenge with STUN has always been that many middleboxes *do not
want to be found*.

> The bigger picture is even more scary - what happens if our reliable transport suddenly no longer is reliable?
>
> One developer from a well known mobile system vendor said “well, I guess that using TLS may help”…

Ask them *how* they think TLS helps. TLS relies on TCP semantics.

Joe



--------------3E394B10530B79A96DE497C9-- From nobody Thu Jul 28 00:20:27 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5272212D15F for ; Thu, 28 Jul 2016 00:20:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 FNdQoYOfiy0b for ; Thu, 28 Jul 2016 00:20:23 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 6E5BF12D08D for ; Thu, 28 Jul 2016 00:20:22 -0700 (PDT) Received: from [10.228.166.197] (unknown [134.25.0.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 24273426A; Thu, 28 Jul 2016 09:20:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: TCP proxys in mobile networks From: "Olle E. Johansson" In-Reply-To: <5798D0B2.1040203@isi.edu> Date: Thu, 28 Jul 2016 09:20:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsv-area@ietf.org, Olle E Johansson X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 07:20:25 -0000 > On 27 Jul 2016, at 17:18, Joe Touch wrote: >=20 > Olle, >=20 > On 7/27/2016 5:41 AM, Olle E. Johansson wrote: >> ... >>=20 >> This mess caused me sadly to suggest that we need to discuss breaking = the assumption that TCP delivery is always reliable >> and implement retransmits even over TCP in the STUN protocol. STUN = was designed to discover middleboxes >> with a focus on NAT. This is just another middle box to discover. > None of this is news. One of the "features" of middleboxes is > "transparent" TCP relaying. That device always destroys TCP reliable > delivery semantics. Even more sad - I just discovered them. >=20 > This has been known since the mid 90s'. >=20 > The challenge with STUN has always been that many middleboxes *do not > want to be found*. Which is one reason to improve STUN - right? >=20 >> The bigger picture is even more scary - what happens if our reliable = transport suddenly no longer is reliable? >>=20 >> One developer from a well known mobile system vendor said =E2=80=9Cwell= , I guess that using TLS may help=E2=80=9D=E2=80=A6 >=20 > Ask them *how* they think TLS helps. TLS relies on TCP semantics. I asked the very same question, got no answer. Will get back to them. /O= From nobody Thu Jul 28 00:33:45 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B259812D0BB for ; Thu, 28 Jul 2016 00:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qZZAFU_y1yod for ; Thu, 28 Jul 2016 00:33:43 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF82128E18 for ; Thu, 28 Jul 2016 00:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1510; q=dns/txt; s=iport; t=1469691223; x=1470900823; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=skGeaB87sJzXM7Nnn5yw7mfMLE58qbOE/uyi47TPD7g=; b=cB2zUS0VRn2t+zGe5p3AuLCo/p+veGIo3xTDOUWobxpwNRbiTWVVWH/W KDrCZ/lfJRkWEvPCv+uWwt8UXdQYAJh5sh/fgsz9kY+CzrlFhg2+bM3js ZkgVcltj/SQ9Y1Zgv4JRNCbWlt5MFYFhtiMEFZP9fO7xDcRokWvhRlcOF k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAgAVtJlX/5ldJa1dg0WBUrhygX2GH?= =?us-ascii?q?QKBNTgUAQEBAQEBAV0nhF0BBTo0CxALGAklDwVJExoBiBa7dQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARyKd4obAQSPC4onjnMKjz+MLoN4HjaCEhyBbBwyiHcBAQE?= X-IronPort-AV: E=Sophos;i="5.28,433,1464652800"; d="scan'208";a="303340788" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jul 2016 07:33:42 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6S7XfN9001735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jul 2016 07:33:42 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u6S7XfJ0014574; Thu, 28 Jul 2016 00:33:41 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u6S7XfXY014573; Thu, 28 Jul 2016 00:33:41 -0700 Date: Thu, 28 Jul 2016 00:33:41 -0700 From: Toerless Eckert To: "Olle E. Johansson" Subject: Re: TCP proxys in mobile networks Message-ID: <20160728073341.GP21039@cisco.com> References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Archived-At: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 07:33:45 -0000 You may want to move this discussion to the spud mailing list. Thats IMHO the "improve STUN" solution. On Thu, Jul 28, 2016 at 09:20:32AM +0200, Olle E. Johansson wrote: > > > On 27 Jul 2016, at 17:18, Joe Touch wrote: > > > > Olle, > > > > On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > >> ... > >> > >> This mess caused me sadly to suggest that we need to discuss breaking the assumption that TCP delivery is always reliable > >> and implement retransmits even over TCP in the STUN protocol. STUN was designed to discover middleboxes > >> with a focus on NAT. This is just another middle box to discover. > > None of this is news. One of the "features" of middleboxes is > > "transparent" TCP relaying. That device always destroys TCP reliable > > delivery semantics. > Even more sad - I just discovered them. > > > > This has been known since the mid 90s'. > > > > The challenge with STUN has always been that many middleboxes *do not > > want to be found*. > Which is one reason to improve STUN - right? > > > > >> The bigger picture is even more scary - what happens if our reliable transport suddenly no longer is reliable? > >> > >> One developer from a well known mobile system vendor said ???well, I guess that using TLS may help?????? > > > > Ask them *how* they think TLS helps. TLS relies on TCP semantics. > I asked the very same question, got no answer. Will get back to them. > > /O -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Jul 28 01:44:32 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B419412D799 for ; Thu, 28 Jul 2016 01:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 KSE57XqwGfpn for ; Thu, 28 Jul 2016 01:44:27 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD6012D0A6 for ; Thu, 28 Jul 2016 01:44:25 -0700 (PDT) Received: from smtpjc.telefonica.com (tgtimjc802.telefonica.com [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3282B2D0550; Thu, 28 Jul 2016 10:44:23 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "ESTGVMSP108", Issuer "ESTGVMSP108" (not verified)) by smtpjc.telefonica.com (Postfix) with ESMTPS id 1A5702D04BE; Thu, 28 Jul 2016 10:44:23 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 28 Jul 2016 10:44:21 +0200 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com (10.167.123.150) by AM4PR0601MB2162.eurprd06.prod.outlook.com (10.167.123.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 28 Jul 2016 08:44:20 +0000 Received: from AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) by AM4PR0601MB2161.eurprd06.prod.outlook.com ([10.167.123.150]) with mapi id 15.01.0549.014; Thu, 28 Jul 2016 08:44:19 +0000 From: "Diego R. Lopez" To: Joe Touch Subject: Re: TCP proxys in mobile networks Thread-Topic: TCP proxys in mobile networks Thread-Index: AQHR6ARKUxzzfdkzSECFINvs3cFp/aAsZCIAgAACqgCAADkSAIAA6JAA Date: Thu, 28 Jul 2016 08:44:19 +0000 Message-ID: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [88.30.242.114] x-ms-office365-filtering-correlation-id: 9aaf3b7a-40b6-4958-c4ff-08d3b6c35dd5 x-microsoft-exchange-diagnostics: 1; AM4PR0601MB2162; 6:UEJdNHfyGtCvj8KjnYSMBaVqHQ7E4RhlRMFXjx+/bRmsAGmNrclA4UDVX5CvEWx3rmmbKzKw4gIhhvk7mzwYst1i9XHMhwx0UyccWrWiPoncPo+cuUi20T8MwR7udL5rCa4xAVDR4axyUVPej3FmpvLwZozJcvT3WSvBxEc4I1miDdM49KwnJR+legyZ6VUbpYdo1QnS7agDENKCI/XEA28dbsl6KWlBnkqaCjPFFueNNXvpkd/aXPz9Qr0RWyKF0pPsUEEqsTDfbgTKkf7DiTOrR7H8DXJdHBhMgPsrjg4=; 5:86J0iywIyLsClEn1O2q6qQ/psFs7AXJrBBi0HXMqCbFdaCkTJVyRTzitwDddDuGYcCDZTlEuzo2MfVc7Tjl2p/2IHddRQZNiCaKP476BpGtKipqSZBdrlsVQkLtALFf6gcfzeCtz7vJvylW5HlasLQ==; 24:P5c/uLrCvuhGRKxqtDFj47hKPfac9etecjZnXkuA9CwsXttpJX15zcFdAYojM2ymtEWVfXgOvxAGOFlgOFx+YhB75qaeIHs43gvHqBXZYxo=; 7:AVgRgo88bHVvgEo8AuQY0LTyPLmvlbifHz4/rLcweJIHy/h1RiHnwOr3YpfH5Q7gqYm8a590sOLKafVLqnf8SHG2PCjIrdJnvxFuBNIz5Id2+ORZinkltPnxVRqsXCp5P6TnjvxITu7yd6HfjpK/gmInBdXHjo7skvRkO69ShZO09azuZXkwdSyh/YribYoj+pOQ6k3bRNz9KzAlKjAYfkWEXwp1ALFpnmfx2Dx/rzKCu3ogyJUSB+d0fkol/mcy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR0601MB2162; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR0601MB2162; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0601MB2162; x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(252514010)(24454002)(77096005)(86362001)(36756003)(7736002)(2950100001)(106356001)(16236675004)(8936002)(551934003)(33656002)(7906003)(106116001)(7846002)(83716003)(87936001)(68736007)(2171001)(54356999)(19617315012)(15975445007)(122556002)(76176999)(50986999)(97736004)(66066001)(2900100001)(110136002)(101416001)(19580405001)(10400500002)(92566002)(5002640100001)(19580395003)(6116002)(3846002)(82746002)(8676002)(81166006)(102836003)(3660700001)(3280700002)(2906002)(4326007)(93886004)(586003)(81156014)(189998001)(105586002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR0601MB2162; H:AM4PR0601MB2161.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AE6FC20375944FF993D45E341BE505F7telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2016 08:44:19.7459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0601MB2162 X-OriginatorOrg: telefonica.com X-TM-AS-GCONF: 00 Archived-At: Cc: "Olle E. Johansson" , "tsv-area@ietf.org >> tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 08:44:31 -0000 --_000_AE6FC20375944FF993D45E341BE505F7telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 27 Jul 2016, at 20:51 , Joe Touch > = wrote: On 7/27/2016 8:27 AM, Spencer Dawkins at IETF wrote: Hi, Joe, On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch > wrote: Olle, On 7/27/2016 5:41 AM, Olle E. Johansson wrote: > ... > > This mess caused me sadly to suggest that we need to discuss breaking the= assumption that TCP delivery is always reliable > and implement retransmits even over TCP in the STUN protocol. STUN was de= signed to discover middleboxes > with a focus on NAT. This is just another middle box to discover. None of this is news. One of the "features" of middleboxes is "transparent" TCP relaying. That device always destroys TCP reliable delivery semantics. This has been known since the mid 90s'. Right. IIRC, you and I were part of a number of conversations about this in= PILC, while working on https://www.ietf.org/rfc/rfc3135.txt. Yup - I'm just observing that this (mis)behavior has been seen in the wild = since the mid 90s. It was the topic of much discussion at the Web Caching W= orkshops of that era. My reason for asking Olle to bring this forward is that we're having a lot = of conversations (starting at the IAB with https://www.iab.org/activities/w= orkshops/marnew/ and headed toward IETF working groups) with wireless carri= ers about encryption and about UDP-based transports, and I wanted to level-= set on what people are (still) seeing these days. Sure - my point is that the term "transparent proxy" is common, and ALL suc= h animals break TCP semantics *by design*. Yes, it's possible to recover TCP semantics at a higher layer using transac= tion confirmations, but that just sets up a game of mutual escalation - onc= e you do that, someone will invent a transparent transaction proxy and you'= ll be back where you started. IMO, transparent proxies should be considered the errors the are, detected,= and removed. Fully agree. And the best solution I can imagine for this removal, avoiding= at the same time mutual escalation, is precisely the idea of a controlled = endpoint-path collaboration framework a-la-PLUS. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_AE6FC20375944FF993D45E341BE505F7telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: quoted-printable
On 27 Jul 2016, at 20:51 , Joe Touch <touch@isi.edu> wrote:

On 7/27/2016 8:27 AM, Spencer Dawkins at IET= F wrote:
Hi, Joe,

On Wed, Jul 27, 2016 at 10:18 AM, Joe Touch <touch@isi.edu> wrote:
Olle,

On 7/27/2016 5:41 AM, Olle E. Johansson wrote:
> ...
>
> This mess caused me sadly to suggest that we need to discuss breaking = the assumption that TCP delivery is always reliable
> and implement retransmits even over TCP in the STUN protocol. STUN was= designed to discover middleboxes
> with a focus on NAT. This is just another middle box to discover.
None of this is news. One of the "features" of middleboxes= is
"transparent" TCP relaying. That device always destroys TCP relia= ble
delivery semantics.

This has been known since the mid 90s'.

Right. IIRC, you and I were part of a number of conversatio= ns about this in PILC, while working on https://www.ietf.org= /rfc/rfc3135.txt.

Yup - I'm just observing that this (mis)behavior has been seen in the wild = since the mid 90s. It was the topic of much discussion at the Web Caching W= orkshops of that era.

My reason for asking Olle to bring this forward is that we'= re having a lot of conversations (starting at the IAB with https://www.iab.org/activities/workshops/marnew/ and headed toward IETF working groups) with wireless carriers about encryp= tion and about UDP-based transports, and I wanted to level-set on what peop= le are (still) seeing these days.

Sure - my point is that the term "transparent proxy" is common, a= nd ALL such animals break TCP semantics *by design*.

Yes, it's possible to recover TCP semantics at a higher layer using transac= tion confirmations, but that just sets up a game of mutual escalation - onc= e you do that, someone will invent a transparent transaction proxy and you'= ll be back where you started.

IMO, transparent proxies should be considered the errors the are, detected,= and removed.

Fully agree. And the best solution I can imagine for this removal, avo= iding at the same time mutual escalation, is precisely the idea of a contro= lled endpoint-path collaboration framework a-la-PLUS.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.= es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_AE6FC20375944FF993D45E341BE505F7telefonicacom_-- From nobody Thu Jul 28 10:15:33 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24C12D8AA for ; Thu, 28 Jul 2016 10:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L8NGTP3cS19H for ; Thu, 28 Jul 2016 10:15:31 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D811712D89C for ; Thu, 28 Jul 2016 10:15:30 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id r9so92745607ywg.0 for ; Thu, 28 Jul 2016 10:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=U0npLsSAvC9jEU1rUZdyZE+C0nIX5XvgSpIUJPcltvs=; b=MHL38826O9HFKIySjc0guCkmiAiXu3Ez7GbBbM7glf0lk5LsFAJxh3PDVcsnCrbrpj Yl7o0pIQSC/SxPgTKunFxlvcxsgP+8XFAdna388ta1MVYW9EGagy5actYuzty8/Z3BbJ QHSTb5kmsZjPxZsoCw+/mP2gb2JjA6Q7SFlKg6kwhKkbB4Aamsf/Exb0GXjwsM3zRdjw xO7Gx0CfQoIwCGDY9lgeDtRwDRIp2zQlQQNgQzIzDAJQH/TZinsNZvDh8sShQsnhkgRR dXcU3nthQs7qe3Cwcp9+l2YKaV5t5lfePCVKP6wTxB66mY2sfqDOCvCDmngc0PprFX2G zA3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=U0npLsSAvC9jEU1rUZdyZE+C0nIX5XvgSpIUJPcltvs=; b=XI4kePRF5N8k9RncEBAbue8jAjl2qkeKwLV/igRjCWsk5ciSa+/2+9NCrXjP0aAGI7 QVF5Y6XBs0Y7AbkL8cH9tZt5guk/c9/S1cKfl3WssMK2WrfWC531aFVx4hkk5VhVFjdo NjrwfhPs/i4HWrxXu0iIpwDh9w2PUkmYCn1t6RVgIhP2dQ+eyjV1UzG+P3KC2cYme6Aa wlJCMbvIMYVza5SP0tIVd5W4enerYmRtSUJYyDnia2MLK+IxKpgmLbNV+v0dUt0I1/FK laZ+ApjBiKwcgDuX20ki7G5bKNL3gmk6xmwcgZe/66bihSQaUIGT8/A76VxFP66rmYha WgVw== X-Gm-Message-State: AEkoouvwOtaEKmEykdw1gPckHWVxa9n2zPdRBpmq4CKxvfNEmC3PKPB4CwQm7Tg9OMvnWA0fHMWBfoiduAD1lg== X-Received: by 10.13.251.66 with SMTP id l63mr31156733ywf.69.1469726130057; Thu, 28 Jul 2016 10:15:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.20 with HTTP; Thu, 28 Jul 2016 10:15:29 -0700 (PDT) From: Spencer Dawkins at IETF Date: Thu, 28 Jul 2016 12:15:29 -0500 Message-ID: Subject: Draft IETF 96 TSVAREA Minutes now available for review To: "tsv-area@ietf.org >> tsv-area@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07e9dee654650538b547e9 Archived-At: X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:15:32 -0000 --94eb2c07e9dee654650538b547e9 Content-Type: text/plain; charset=UTF-8 Draft minutes are available at https://www.ietf.org/proceedings/96/minutes/minutes-96-tsvarea. Please let Mirja and I know about any corrections. Thank you, Mat Ford, for producing these minutes and reviewing them against the MeetEcho recording for the meeting. Spencer --94eb2c07e9dee654650538b547e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft minutes are available at=C2=A0https://www.ietf.org/p= roceedings/96/minutes/minutes-96-tsvarea.

Please let= Mirja and I know about any corrections.

Thank you= , Mat Ford, for producing these minutes and reviewing them against the Meet= Echo recording for the meeting.

Spencer
--94eb2c07e9dee654650538b547e9-- From nobody Thu Jul 28 10:39:41 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CFD12B020 for ; Thu, 28 Jul 2016 10:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 gnGRSg6qYpTb for ; Thu, 28 Jul 2016 10:39:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72F3128B44 for ; Thu, 28 Jul 2016 10:39:38 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6SHcGWI007648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 10:38:17 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> From: Joe Touch Message-ID: <579A4305.7090609@isi.edu> Date: Thu, 28 Jul 2016 10:38:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:39:40 -0000 On 7/28/2016 12:20 AM, Olle E. Johansson wrote: >> > The challenge with STUN has always been that many middleboxes *do not >> > want to be found*. > Which is one reason to improve STUN - right? You can't fix something that doesn't *want* to be found. So-called "transparent" middleboxes (I call them hijacking attackers) do everything possible to hide, which means they refused to participate in any mechanism you create and try very hard not to be discovered at all. All you can do is cause them visibly break so you can detect and eradicate them. Joe From nobody Thu Jul 28 10:44:29 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D05312D0FE for ; Thu, 28 Jul 2016 10:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 wWTcHkh2Oq53 for ; Thu, 28 Jul 2016 10:44:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBE612B04E for ; Thu, 28 Jul 2016 10:44:26 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6SHe7aw008411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 10:40:16 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: Toerless Eckert , "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <20160728073341.GP21039@cisco.com> From: Joe Touch Message-ID: <579A4375.4040808@isi.edu> Date: Thu, 28 Jul 2016 10:40:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160728073341.GP21039@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 17:44:27 -0000 On 7/28/2016 12:33 AM, Toerless Eckert wrote: > You may want to move this discussion to the spud mailing list. Thats IMHO the > "improve STUN" solution. If this were a situation SPUD or STUN could improve, I might agree. I don't think that's the goal of either system, though - there is no system that can interact with something that does everything possible to NOT interact. Joe > On Thu, Jul 28, 2016 at 09:20:32AM +0200, Olle E. Johansson wrote: >>> On 27 Jul 2016, at 17:18, Joe Touch wrote: >>> >>> Olle, >>> >>> On 7/27/2016 5:41 AM, Olle E. Johansson wrote: >>>> ... >>>> >>>> This mess caused me sadly to suggest that we need to discuss breaking the assumption that TCP delivery is always reliable >>>> and implement retransmits even over TCP in the STUN protocol. STUN was designed to discover middleboxes >>>> with a focus on NAT. This is just another middle box to discover. >>> None of this is news. One of the "features" of middleboxes is >>> "transparent" TCP relaying. That device always destroys TCP reliable >>> delivery semantics. >> Even more sad - I just discovered them. >>> This has been known since the mid 90s'. >>> >>> The challenge with STUN has always been that many middleboxes *do not >>> want to be found*. >> Which is one reason to improve STUN - right? >> >>>> The bigger picture is even more scary - what happens if our reliable transport suddenly no longer is reliable? >>>> >>>> One developer from a well known mobile system vendor said ???well, I guess that using TLS may help?????? >>> Ask them *how* they think TLS helps. TLS relies on TCP semantics. >> I asked the very same question, got no answer. Will get back to them. >> >> /O From nobody Thu Jul 28 12:58:26 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABA12E091 for ; Thu, 28 Jul 2016 12:58:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 dWcZQqKd-CdU for ; Thu, 28 Jul 2016 12:58:22 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 6E9E012D8AE for ; Thu, 28 Jul 2016 12:58:21 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 52ACE426A; Thu, 28 Jul 2016 21:58:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: TCP proxys in mobile networks From: "Olle E. Johansson" In-Reply-To: <579A4305.7090609@isi.edu> Date: Thu, 28 Jul 2016 21:57:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsv-area@ietf.org, Olle E Johansson X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 19:58:24 -0000 > On 28 Jul 2016, at 19:38, Joe Touch wrote: > > > > On 7/28/2016 12:20 AM, Olle E. Johansson wrote: >>>> The challenge with STUN has always been that many middleboxes *do not >>>> want to be found*. >> Which is one reason to improve STUN - right? > > You can't fix something that doesn't *want* to be found. So-called > "transparent" middleboxes (I call them hijacking attackers) do > everything possible to hide, which means they refused to participate in > any mechanism you create and try very hard not to be discovered at all. > > All you can do is cause them visibly break so you can detect and > eradicate them. If you check the paper I referred to they have detected the presence of TCP proxys, which may help us with setting protocol options right in order to work. Or just fail. /O From nobody Thu Jul 28 13:04:04 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD79912D1DC for ; Thu, 28 Jul 2016 13:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 gIZW_n4K56YT for ; Thu, 28 Jul 2016 13:04:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F1B12D0A5 for ; Thu, 28 Jul 2016 13:04:01 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6SK3IPA011062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 13:03:19 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> From: Joe Touch Message-ID: <579A6504.1030607@isi.edu> Date: Thu, 28 Jul 2016 13:03:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6SK3IPA011062 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:04:03 -0000 On 7/28/2016 12:57 PM, Olle E. Johansson wrote: >> All you can do is cause them visibly break so you can detect and >> > eradicate them. > If you check the paper I referred to they have detected the presence > of TCP proxys, which may help us with setting protocol options > right in order to work. Or just fail. My point is that this logic is backwards. The order of TCP options is whatever TCP wants them to be at the endpoints. It should NEVER be constrained by these devices, which are already clearly violating spec. I don't want everyone's TCP to "just fail" when it hits these boxes - perhaps it would be useful to create a custom TCP that can be used to find these boxes, but once they're found we need to point them out and demand they be removed (if you're paying for "Internet" behind such a box, you might have the right to make such a demand). I.e., we should NEVER use these boxes to govern how we build TCP for the masses. Joe From nobody Thu Jul 28 13:08:02 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF312D897 for ; Thu, 28 Jul 2016 13:08:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 iFqejRjr_z9q for ; Thu, 28 Jul 2016 13:08:00 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 F1C6112D7FD for ; Thu, 28 Jul 2016 13:07:59 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 57F09426A; Thu, 28 Jul 2016 22:07:56 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: TCP proxys in mobile networks From: "Olle E. Johansson" In-Reply-To: <579A6504.1030607@isi.edu> Date: Thu, 28 Jul 2016 22:07:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1DCDD681-A5AB-4E13-901B-987A63B52D93@edvina.net> References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tsv-area@ietf.org, Olle E Johansson X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:08:01 -0000 > On 28 Jul 2016, at 22:03, Joe Touch wrote: >=20 >=20 >=20 > On 7/28/2016 12:57 PM, Olle E. Johansson wrote: >>> All you can do is cause them visibly break so you can detect and >>>> eradicate them. >> If you check the paper I referred to they have detected the presence=20= >> of TCP proxys, which may help us with setting protocol options >> right in order to work. Or just fail. > My point is that this logic is backwards. >=20 > The order of TCP options is whatever TCP wants them to be at the > endpoints. It should NEVER be constrained by these devices, which are > already clearly violating spec. >=20 > I don't want everyone's TCP to "just fail" when it hits these boxes - > perhaps it would be useful to create a custom TCP that can be used to > find these boxes, but once they're found we need to point them out and > demand they be removed (if you're paying for "Internet" behind such a > box, you might have the right to make such a demand). >=20 > I.e., we should NEVER use these boxes to govern how we build TCP for = the > masses. That=92s right - but we do need to find out what happens. Right now our support is getting a lot of issues that is hard to explain and we=92re = not even customers of these carriers. Telling the customer that the net is broken doesn=92t help us - =93Facebook, Pokemon and the others work=94=20 We either break the assumption that TCP is reliable, find these boxes = and refuse to work=20 with them or will continue to get complains=85 We are pressed into a corner and want to find a way out. At some point we as a community need to find a good =93INternet test = tool=94 for the masses that doesn=92t just focus on download bandwidth - but = also quality of the Internet connectivity. /O= From nobody Thu Jul 28 13:12:17 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0712E097 for ; Thu, 28 Jul 2016 13:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=aero.org header.b=fC1phKz/; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=KvouBinW 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 qsrAw7X8kMI9 for ; Thu, 28 Jul 2016 13:12:14 -0700 (PDT) Received: from email3-east.aero.org (email3-east.aero.org [130.221.184.167]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29DC312E033 for ; Thu, 28 Jul 2016 13:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1469736734; x=1501272734; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=oXLSU7sj4j9RBGS4OCQGqirrA7EXP7YMG4PDcKWLRws=; b=fC1phKz/v1njj9MpGKNhO4SVwws4o4u1Ffrx3Wvo0pfcyo4INQz5jzVn iaxNycZKrxX34KmB/Qvqac/FavgESZIexkidkILK/fzIHuKxSBdg133od q21vffdoH+cILO01AebWgxiMqenRJqSkdjLxudykzhQ08cQw7t+xI2Xc3 w=; x-SBRS: None x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,8240"; a="3430351" X-IronPort-AV: E=Sophos;i="5.28,434,1464667200"; d="scan'208";a="3430351" X-IPAS-Result: A2H+AAAhY5pX/xjGZxdaAw4LAQEBAQGDfU4EKgaNJatPgX0chgECgW8UAQEBAQEBAQNaJ4JROTwBAQEBAQEBAQEBAQEBAQEBAQEBFgINJzgBAQECARIBJwYBATcBBAsCAQg2EDIlAgQBDQUIGod1Aw8In30BgSgBHGEFKAKKbYUqAQEFhHgYhAkBAQEBAQEBAQEBAQEBAQEBAQEBAQEUAwWKd4RAAh8mgmWCL5k3hhiYJJAmHjaCBQwdgRE7bgGIAQF+AQEB Received: from mail-cy1gcc01lp0024.outbound.protection.outlook.com (HELO gcc01-CY1-obe.outbound.protection.outlook.com) ([23.103.198.24]) by email3-east.aero.org with ESMTP/TLS/AES256-SHA; 28 Jul 2016 16:12:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector1-aero-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5kdw5nGNSi0L9ONG+q3ly81fM1hVIu1VRdnlU6dWAgk=; b=KvouBinWBALQLXqCX/IE0FqLE8gcW/aYuxI570RJrjqiTQEsryYzJMSirDc00myfB+8iiRxG29RAN3/kSQZ/k2kV+zOj3BUdgR8krzH/k9uq4vtFvVIedcHGY2XpnwdGhF6v47+dMpeC/bA7ScMD+OjVeYMizR4tbvbDBRxjNtk= Received: from BN6PR09MB2130.namprd09.prod.outlook.com (10.173.160.146) by BN6PR09MB2132.namprd09.prod.outlook.com (10.173.160.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 28 Jul 2016 20:11:51 +0000 Received: from BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) by BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) with mapi id 15.01.0549.016; Thu, 28 Jul 2016 20:11:51 +0000 From: Theodore V Faber To: Joe Touch , "Olle E. Johansson" Subject: Re: TCP proxys in mobile networks Thread-Topic: TCP proxys in mobile networks Thread-Index: AQHR6AQ/D1QqACJDx0asfhcGGcvuig== Date: Thu, 28 Jul 2016 20:11:50 +0000 Message-ID: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-originating-ip: [130.221.224.7] x-ms-office365-filtering-correlation-id: 2ab7b51f-21a7-446a-fb3e-08d3b7236975 x-microsoft-exchange-diagnostics: 1; BN6PR09MB2132; 6:DECXJmi9EOMsksV/L0jm/6l52J3vPiBW79NrgifQFS8kFLzClFhY9N0+70ocecM3LPmKgWsr+LPCZscdNo0cYkcZZUIXoqqI/f8bt9uIw6oU8NHIJ06DcUs7JCQPCNbkAFG2CAAvmpfO7oiPJ3DDEWbXT4jJKpQSfmLjDLANoOGflCUO/LNWg1xvvywB1QaWOhR2Dur4WCXEoc87iisG2COGoVXPhguE/KRLJtZ13Nthoih4qH9ycoEm17ludiLntzcJzFVOrNu56g4mMCjERGNeW0yxGZot7mEcPz9cSu8y+Hbi94mNQHcdxyB8TIhlUwqx9XzjpLfavPVdIcxu9A==; 5:NhutpiAP7KX/R7u5oz+TcaWoen9kCMq0yMtLgx71skUr81flqxmgH4qBSMNKunqU3WAtiYwK3Q/aSkmpIR5TyOGqlPbIGe3jDUwy00JyY/ivL9LeQ5/oBGNOM8CUnB4kI/40zAe9qrrgmWQbmpG9TA==; 24:4L4f29Y+uPJojVSeTnLYkriHVXJzENgxtBtbfKYy8KCts840xi3RQ+5+vEp/+oj3s4XRowiUjMRId5G6ufhH6ZpsgH2GNp0kKZY3UqB+PBw=; 7:9gF3EKRY4ktgHCKJnSmLyUJezPfrJpnnGbM4LBH+gCQ6i28g1ZyCpZS+Sc2qmb3JUJl+hGVHgCV5HBLc5X+weTuZm1PTtEnhzZQI4WGab+Z/k6Nvcjyx4X66lSXr9lUMgkqfcgf3nBxatIz8v5vs5qtbQ8MmFMZye9QAMWJIGTr9ySafLCoEnBP5H8tRP2WiB3HZDq3AW7wj78uAeIhw0ikba76/sh51le4W0UHUk21gVy++hHjAhzKX/8IDQDdM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR09MB2132; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN6PR09MB2132; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB2132; x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(54524002)(24454002)(199003)(92566002)(586003)(3846002)(8936002)(106116001)(99286002)(4326007)(102836003)(2906002)(5002640100001)(6116002)(3280700002)(106356001)(19580395003)(3660700001)(33656002)(9686002)(11100500001)(93886004)(105586002)(7736002)(76576001)(7846002)(2171001)(87936001)(86362001)(97736004)(81166006)(101416001)(74316002)(2900100001)(5001770100001)(7696003)(68736007)(81156014)(575784001)(50986999)(15975445007)(8676002)(76176999)(189998001)(66066001)(54356999)(10400500002)(305945005)(77096005)(122556002)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR09MB2132; H:BN6PR09MB2130.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2016 20:11:50.7047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB2132 Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:12:16 -0000 -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA512=0A= =0A= On 7/28/16 13:04, Joe Touch wrote:=0A= =0A= > I.e., we should NEVER use these boxes to govern how we build TCP=0A= > for the masses.=0A= =0A= To say that another way: vendors who produce such devices are failing=0A= to follow the Postel principle. Whether the IETF says anything=0A= explicitly or not, they're producing artifacts of less value to their=0A= customers. Standards-compliant stacks will emit TCP options in ways=0A= that such vendors evidently don't expect.=0A= =0A= The IETF standard reflects a consensus among designers and=0A= implementers that there's no constraint on TCP option ordering. The=0A= time to argue about it is past; live with it or produce crappy products.=0A= =0A= - -- =0A= Ted Faber =0A= Engineering Specialist=0A= Computer Systems Research Department=0A= 310-336-7373=0A= -----BEGIN PGP SIGNATURE-----=0A= Comment: GPGTools - https://gpgtools.org=0A= =0A= iQIcBAEBCgAGBQJXmmcHAAoJEFNjQnOBW8uOHokP/i5rTEOdxTrn2QgsWYNgv7ae=0A= IfqAEaYVQCmCOS9hZIPXrm31XB8RI3uVAmfTtFc7tZYRO4CG8+XcOuPzUtZRan7Q=0A= 3k7XddaBRF3ScD/gCQCqjt80yxcwQUdTDv5Rnh6WJW1GKPIP2vCT/0rQZxc5nK3l=0A= BfWyhtDeJ4qPgVCqMD+eQdy/W1iKJVKUcw+MXr3J+F5VM08SFEkaw98qDpwkGK9Q=0A= 4+USYlVXpyNHIpU1shtDz3KFEl17hIl6LEkSylsh8JuPgSeoO1pL53nJuCYPgPqQ=0A= IDIrqMp9LCfnQwReSIfh/zqTc+yElMmo7JaV1bX+2jEp402BPIJjNclUf0leUp0Q=0A= cmhS9K6HSNdHtB3xSDpfWnhsaGsPK7k3FYFA6p9CGBSla7duBKkjMG/+N7aR4nIi=0A= PMnMDJpbnCZW3LtTBm/WJwDTA1yCmdvfYmLGTh7Xn9kOUCFYVJ0hczoxQFwDLup/=0A= aZnHdKs9BlGM/L2KYt7pU8//mxH59JGeGDaWS2K84Dm3isPEK3l9vQzzGn1hJkYU=0A= IOivzkYulEEfsjaICQe9bWnzW9f+kkriUdSUzGxgFg2zAPgSWV78yqKEjLZuB+rc=0A= kP+6wcq4bDZ1WKQ7nCVOtUiTzKPZbVKmYOZBRd/ob+4mJzk4wuuXfxCy+k2JOOVT=0A= fXY0a5fMzr1+DR/h31Qw=0A= =3DKZWl=0A= -----END PGP SIGNATURE-----=0A= From nobody Thu Jul 28 13:14:48 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210C912E033 for ; Thu, 28 Jul 2016 13:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 4Y8KF3tHMUzp for ; Thu, 28 Jul 2016 13:14:45 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25FC12D536 for ; Thu, 28 Jul 2016 13:14:45 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6SKEFYV015351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 13:14:16 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <1DCDD681-A5AB-4E13-901B-987A63B52D93@edvina.net> From: Joe Touch Message-ID: <579A6795.2090404@isi.edu> Date: Thu, 28 Jul 2016 13:14:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1DCDD681-A5AB-4E13-901B-987A63B52D93@edvina.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: u6SKEFYV015351 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:14:47 -0000 On 7/28/2016 1:07 PM, Olle E. Johansson wrote: >> I.e., we should NEVER use these boxes to govern how we build TCP for the >> > masses. > Thats right - but we do need to find out what happens. Right now our > support is getting a lot of issues that is hard to explain and were not even > customers of these carriers. Telling the customer that the net is broken > doesnt help us - Facebook, Pokemon and the others work It might be useful to have tools that both detect these boxes and "repair" their effects, e.g., by tunneling over them. However, we need to be careful not to build in these temporary repairs into our widely used protocols. > We either break the assumption that TCP is reliable, find these boxes and refuse to work > with them or will continue to get complains The boxes have broken the assumption, not you. I agree you need to find a way to undo what the box is, but corrupting TCP to be tolerant of byzantine network behavior is a bad idea IMO. > We are pressed into a corner and want to find a way out. > > At some point we as a community need to find a good INternet test tool > for the masses that doesnt just focus on download bandwidth - but also > quality of the Internet connectivity. Agreed. Joe From nobody Thu Jul 28 13:18:20 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB812D0C2 for ; Thu, 28 Jul 2016 13:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 3SdzMZFqNkCm for ; Thu, 28 Jul 2016 13:18:17 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E72E12D836 for ; Thu, 28 Jul 2016 13:18:16 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6SKHhj7006438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 13:17:43 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: Theodore V Faber , "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> From: Joe Touch Message-ID: <579A6864.6030300@isi.edu> Date: Thu, 28 Jul 2016 13:17:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:18:18 -0000 On 7/28/2016 1:11 PM, Theodore V Faber wrote: > On 7/28/16 13:04, Joe Touch wrote: > > > I.e., we should NEVER use these boxes to govern how we build TCP > > for the masses. > > To say that another way: vendors who produce such devices are failing > to follow the Postel principle. The Postel Principle talks about what to do when the docs don't say otherwise. > Whether the IETF says anything > explicitly or not, Actually, they're quite directly contradicting explicit existing standards. > they're producing artifacts of less value to their > customers. Standards-compliant stacks will emit TCP options in ways > that such vendors evidently don't expect. Those vendors shouldn't be looking at TCP options or TCP at all. It's none of their business. Maybe we should just start using IPsec in BTNS mode (to avoid needing keys) as a tunnel to get through all such devices. > > The IETF standard reflects a consensus among designers and > implementers that there's no constraint on TCP option ordering. The > time to argue about it is past; live with it or produce crappy products. This issue cannot be fixed merely by reacting to what vendors deploy. The solution has been clear for a long time - *compliance verification*. I assure you that vendors that get sued for saying "Internet compatible" who are not would behave differently. Joe From nobody Thu Jul 28 13:30:15 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D821B12D513 for ; Thu, 28 Jul 2016 13:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=aero.org header.b=wUrqU09U; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=UcNjwJiv 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 vUSf0g1MclkG for ; Thu, 28 Jul 2016 13:30:08 -0700 (PDT) Received: from email3-east.aero.org (email3-east.aero.org [130.221.184.167]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA2C12DABA for ; Thu, 28 Jul 2016 13:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1469737807; x=1501273807; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=h/mtANpQrT4kDI92qHM5CfKLnH3tI2UH5qdvpMteVeM=; b=wUrqU09UoUslZwbGl0lMV3/Fx4DtK2Lz+kI11w8DcCgnznbc8Ni7o/VE ZcwFw7jMK9H/o1sS6cf/cPT0zl82Kdwr2uQLdVmAjdYfne5lw7P/wwGLl rTFO/imK+RLVcF5K4wbr2w50sSddRsstNBlXtB4C9ZsDKUtQR34Nenq2h w=; x-SBRS: None x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,8240"; a="3430475" X-IronPort-AV: E=Sophos;i="5.28,435,1464667200"; d="scan'208";a="3430475" X-IPAS-Result: A2EaAQBRZJpX/zLGZxdaAw4LAQEBAQGDfS0hBCoGjSWrT4F9HIYBAoFvFAEBAQEBAQEDWieCUTk8AQEBAQEBAQEBAQEBAQEBAQEBARYCDSc3AQEBAQIBEgEnBgEBNwEPAgEIGB4QMiUCBAENBQgTB4d1Aw8In30BgSgBHGEFKAKKbYUqAQEFhHgYhAkBAQEBAQEBAQIBAQEBAQEBAQEWAwWKd4RAAh8mgmWCL5k3hhiCfJUojC6DeB42ggUMARyBETtuAYgBAX4BAQE Received: from mail-dm2gcc01lp0050.outbound.protection.outlook.com (HELO gcc01-dm2-obe.outbound.protection.outlook.com) ([23.103.198.50]) by email3-east.aero.org with ESMTP/TLS/AES256-SHA; 28 Jul 2016 16:30:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector1-aero-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9CE2xq/hUfEteRcxS9Wenjb9aRsaK71fymzcWbTV6KY=; b=UcNjwJiv+YudTHPNZPFhbLLOgErDTrEcmTcTq0E5vx/2NcZ5WJCp44PpUiayRNMd0ODbjQHwzyrjBdw3dVWKoTLP6zI6blDsJUgYvAU5w4HbsPoBo85252vf1FlCCd9QJpBQjktLxctLJlhju669gq8D+6z+7RbmfViiq1pUdVs= Received: from BN6PR09MB2130.namprd09.prod.outlook.com (10.173.160.146) by BN6PR09MB2132.namprd09.prod.outlook.com (10.173.160.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 28 Jul 2016 20:29:43 +0000 Received: from BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) by BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) with mapi id 15.01.0549.016; Thu, 28 Jul 2016 20:29:42 +0000 From: Theodore V Faber To: Joe Touch , "Olle E. Johansson" Subject: Re: TCP proxys in mobile networks Thread-Topic: TCP proxys in mobile networks Thread-Index: AQHR6AQ/D1QqACJDx0asfhcGGcvuig== Date: Thu, 28 Jul 2016 20:29:42 +0000 Message-ID: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-originating-ip: [130.221.224.7] x-ms-office365-filtering-correlation-id: d4bc910b-2936-4725-c41f-08d3b725e845 x-microsoft-exchange-diagnostics: 1; BN6PR09MB2132; 6:BpXLWUpys4ANKamnGLcsPZfl0Ov5lNwwJCzm+qYLY0MllfmuT92lxmrw8fgi9TiZmit92sqYiINRp9LK2lQI9HFL9wGus3H6uZimtc7XF2+Ga8EsSL4JkYi91NTmHQuVvNVydsLB4sPJ+36uH+LqW0gIxJuBPpt9Jf+Fz4WB3W/5xU/rMH0rzq78Px6V5O+HJCUoFX9ZsC4Vx6vQVPPXCB6Aogm9xQCb9jjKCB46ylhZPDidzQtqAP6BH7efuYUC6OiyIBvssgGVWdWG77ADHLHIF7puG42rnrXhBEdm3cxMIHDAgrlBg5rJMaTWRAaEfuO3YGtK/70j+ZL6eCtq5A==; 5:GcQaAW+aprCRgIcRmZugeOZIa2RqfvAgqpqqavofHAYr1NPVD1K7LhY9CbQeYTDqCmhKkyXlCs1PJPhSmfgXriYKQCsI3hqw1GiQVOtfQiUTDJGNUdTJuPFpT+gAMDw75IIug1V280nE9Bl0AwqvFQ==; 24:DgyC7ZANhcrx0G1vVsHgTZFm0obN/zHs24AB1VIUYIs9qfIoxzOPVuAqeK9ZjO9lNW0y8AwX1SseXToj7Hnu56U6C0GV9zkkCqWVWOblHqU=; 7:563SsiX3N5pc2EL4jON+WnNJYAWwFtZOYoGvhJjIOO7wC1hFIPu0UjyAHnfjR4vmphX7f24HptLYjmV3hJnwStx8kty5lLGE3ZFXPtqtoN81rWcgcXFvlnH8MdCXb85eoGv9U2yM1AOX/neQp09CCS7RIDbFjYx6G/25yQQueHcwvngzrLgjcWAYQG70IBv3ZKN9UGqBQV1TKVKbH0v1BHB3E20q/qI6yJr1qE6GQFzM1fIW9mH/PhwZiBkOm+tm x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR09MB2132; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN6PR09MB2132; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB2132; x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(377454003)(54524002)(24454002)(74316002)(2900100001)(101416001)(5001770100001)(7696003)(68736007)(86362001)(2171001)(87936001)(76576001)(7846002)(7736002)(97736004)(81166006)(8676002)(76176999)(189998001)(66066001)(54356999)(15975445007)(50986999)(575784001)(122556002)(19580405001)(10400500002)(305945005)(77096005)(81156014)(102836003)(99286002)(4326007)(2906002)(106116001)(92566002)(8936002)(3846002)(586003)(9686002)(3660700001)(33656002)(93886004)(105586002)(19580395003)(6116002)(3280700002)(5002640100001)(106356001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR09MB2132; H:BN6PR09MB2130.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2016 20:29:42.4658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB2132 Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:30:10 -0000 -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA512=0A= =0A= On 7/28/16 13:18, Joe Touch wrote:=0A= > =0A= > =0A= > On 7/28/2016 1:11 PM, Theodore V Faber wrote:=0A= >> On 7/28/16 13:04, Joe Touch wrote:=0A= >> =0A= >>> I.e., we should NEVER use these boxes to govern how we build=0A= >>> TCP for the masses.=0A= >> =0A= >> To say that another way: vendors who produce such devices are=0A= >> failing to follow the Postel principle.=0A= > =0A= > The Postel Principle talks about what to do when the docs don't=0A= > say otherwise.=0A= =0A= No. The Postel Principle applies to networking in general. "Be=0A= simple in your behavior and tolerant of others" does not include any=0A= proviso about an IETF position.=0A= =0A= > =0A= >> Whether the IETF says anything explicitly or not,=0A= > =0A= > Actually, they're quite directly contradicting explicit existing=0A= > standards.=0A= =0A= Which falls under "says anything," right? Feeling crabby, are we?=0A= =0A= > =0A= >> they're producing artifacts of less value to their customers.=0A= >> Standards-compliant stacks will emit TCP options in ways that=0A= >> such vendors evidently don't expect.=0A= > =0A= > Those vendors shouldn't be looking at TCP options or TCP at all.=0A= > It's none of their business.=0A= > =0A= > Maybe we should just start using IPsec in BTNS mode (to avoid=0A= > needing keys) as a tunnel to get through all such devices.=0A= > =0A= >> =0A= >> The IETF standard reflects a consensus among designers and =0A= >> implementers that there's no constraint on TCP option ordering.=0A= >> The time to argue about it is past; live with it or produce=0A= >> crappy products.=0A= > =0A= > This issue cannot be fixed merely by reacting to what vendors=0A= > deploy.=0A= =0A= "React?" Bah.=0A= =0A= How is my position unclear here? I advocate that the IETF do nothing.=0A= =0A= Perhaps in a just world, their competitors should pipe up and say=0A= "Whoever's crappy product breaks stuff." The IETF has said its piece:=0A= "there is no constraint on the order of TCP options."=0A= =0A= > =0A= > The solution has been clear for a long time - *compliance=0A= > verification*. I assure you that vendors that get sued for saying=0A= > "Internet compatible" who are not would behave differently.=0A= =0A= We prefer different societal pressures, evidently. I like the one=0A= where I can be lazier.=0A= =0A= =0A= - -- =0A= Ted Faber =0A= Engineering Specialist=0A= Computer Systems Research Department=0A= 310-336-7373=0A= -----BEGIN PGP SIGNATURE-----=0A= Comment: GPGTools - https://gpgtools.org=0A= =0A= iQIcBAEBCgAGBQJXmms3AAoJEFNjQnOBW8uOw/0P/RC9ykg6ZK7C/FhAKnEANrLr=0A= wO1io51iZyRTgmchVpqEx0TvgaFW1Hy9GQpDIaZrNPy1IoT/nkP3MCKc/9fEyikV=0A= JKQkAhLuz2Y7EuCEy3VIE3KcQfg8HB1mYs5gkzKutO07/HmIYnr6fHFNBM+cAXKE=0A= II2fB48GJ7eOX3P/SkIcIsAbJcK0+7KyoepSf7MILRorJiRyJ3WBtSJJ4qDcTYQb=0A= WdNjMnDFxc3ETXZjt9aMpzFVe+TKpRf4BB+f0HmezM+6m1tm92pcpiaW5/ZKD8pc=0A= NvJo6pOFszyTHxAeABGc3G6VWcpm4exZKpy+YcirXjpE6pfDD3GutS+X16kRSDhD=0A= i/QhDdspZI6ZRx+JLLsh2cvdVVjn/HLJObzl+U1D3FIdvd8EFXaTqxl7a/zkxpeC=0A= U2Ph39m7bRHDr7aqKr/75kdFBliStkT41Tq9lww3+R39GXGVwkAhRUc0MBiFY5Uk=0A= W1G5JB2/ny/7Sp+3lIhI2brEKyhCfQZl4lkBI+VjPNgei4CFbRh0f+RRoW2yslfa=0A= A80D7ImWiRokQI+5dWkAPx5CmkXeyo+jOVUjt7w8/i3xjbq8JfuMONUfaYTNQ2qw=0A= QHB7MhDuYb5OwWd4XjGuegT0iYdFrz2zft7QM1w2gGRZPsRV67Z9hAtfpKMWM9i2=0A= qPHCCcIg5Z9CQep1FN8F=0A= =3DXtdM=0A= -----END PGP SIGNATURE-----=0A= From nobody Thu Jul 28 13:41:03 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFC212E0D2 for ; Thu, 28 Jul 2016 13:41:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 SWw82kPIwxIM for ; Thu, 28 Jul 2016 13:41:01 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 F36F812D917 for ; Thu, 28 Jul 2016 13:41:00 -0700 (PDT) Received: from [192.168.40.18] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 8B258426A; Thu, 28 Jul 2016 22:40:56 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: TCP proxys in mobile networks From: "Olle E. Johansson" In-Reply-To: <579A6864.6030300@isi.edu> Date: Thu, 28 Jul 2016 22:40:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <626DA5EA-27FD-42D9-9B29-5C9CC0909886@edvina.net> References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tsv-area@ietf.org" , Olle E Johansson X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:41:02 -0000 > On 28 Jul 2016, at 22:17, Joe Touch wrote: >=20 >=20 >=20 > On 7/28/2016 1:11 PM, Theodore V Faber wrote: >> On 7/28/16 13:04, Joe Touch wrote: >>=20 >>> I.e., we should NEVER use these boxes to govern how we build TCP >>> for the masses. >>=20 >> To say that another way: vendors who produce such devices are failing >> to follow the Postel principle.=20 >=20 > The Postel Principle talks about what to do when the docs don't say > otherwise. >=20 >> Whether the IETF says anything >> explicitly or not, >=20 > Actually, they're quite directly contradicting explicit existing = standards. >=20 >> they're producing artifacts of less value to their >> customers. Standards-compliant stacks will emit TCP options in ways >> that such vendors evidently don't expect. >=20 > Those vendors shouldn't be looking at TCP options or TCP at all. It's > none of their business. Well, the question is what they are trying to solve by breaking TCP? I personally suspect that the latency on some radio networks cause a lot of retransmits. By adding a TCP proxy they avoid retransmits=20 wasting bandwidth and at the same time causing issues when it=20 doesn=92t work. Can we help them with a better solution if this is=20 the problem? Does anyone know what the problem they are trying to solve is? (Still trying to find information) >=20 > Maybe we should just start using IPsec in BTNS mode (to avoid needing > keys) as a tunnel to get through all such devices. >=20 >>=20 >> The IETF standard reflects a consensus among designers and >> implementers that there's no constraint on TCP option ordering. The >> time to argue about it is past; live with it or produce crappy = products. >=20 > This issue cannot be fixed merely by reacting to what vendors deploy. >=20 > The solution has been clear for a long time - *compliance = verification*. > I assure you that vendors that get sued for saying "Internet = compatible" > who are not would behave differently. So where do we have a good specification that we agree on defining =93Internet compatible=94 ? /O= From nobody Thu Jul 28 13:46:16 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8512E0EB for ; Thu, 28 Jul 2016 13:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 vXo-T7B0lphO for ; Thu, 28 Jul 2016 13:46:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E52B12E0DA for ; Thu, 28 Jul 2016 13:46:13 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6SKjOiQ016659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 13:45:26 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: Theodore V Faber , "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> From: Joe Touch Message-ID: <579A6EE2.1010000@isi.edu> Date: Thu, 28 Jul 2016 13:45:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:46:14 -0000 On 7/28/2016 1:29 PM, Theodore V Faber wrote: > On 7/28/16 13:18, Joe Touch wrote: > > > > On 7/28/2016 1:11 PM, Theodore V Faber wrote: > >> On 7/28/16 13:04, Joe Touch wrote: > >> > >>> I.e., we should NEVER use these boxes to govern how we build > >>> TCP for the masses. > >> > >> To say that another way: vendors who produce such devices are > >> failing to follow the Postel principle. > > > The Postel Principle talks about what to do when the docs don't > > say otherwise. > > No. The Postel Principle applies to networking in general. "Be > simple in your behavior and tolerant of others" does not include any > proviso about an IETF position. "Be liberal in what you accept, and conservative in what you send." - RFC1122 RFC760 puts it into exactly the context I indiicated: The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. I.e., applies when there is ambiguity. > ... > >> The IETF standard reflects a consensus among designers and > >> implementers that there's no constraint on TCP option ordering. > >> The time to argue about it is past; live with it or produce > >> crappy products. > > > This issue cannot be fixed merely by reacting to what vendors > > deploy. > > "React?" Bah. > > How is my position unclear here? I advocate that the IETF do nothing. > > Perhaps in a just world, their competitors should pipe up and say > "Whoever's crappy product breaks stuff." The IETF has said its piece: > "there is no constraint on the order of TCP options." That's not strictly true. RFC5925 requires that TCP-AO come first, because it would be impossible to undo the effect of processing earlier options when the AO option might indicate the packet is not authentic. However, I'm only saying that the IETF should not be changing TCP specs solely to transit devices that violate this order independence. > > The solution has been clear for a long time - *compliance > > verification*. I assure you that vendors that get sued for saying > > "Internet compatible" who are not would behave differently. > > We prefer different societal pressures, evidently. I like the one > where I can be lazier. It's fine to say "just don't deal with middlebox option order issues", but then we end up with broken behavior. Is that a viable way to leave things? Joe From nobody Thu Jul 28 13:51:34 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0588C12DC21 for ; Thu, 28 Jul 2016 13:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 6Fa61qoll4fz for ; Thu, 28 Jul 2016 13:51:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46EC12D8D8 for ; Thu, 28 Jul 2016 13:51:31 -0700 (PDT) Received: from [128.9.184.214] ([128.9.184.214]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6SKnwU7018184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Jul 2016 13:49:59 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> <626DA5EA-27FD-42D9-9B29-5C9CC0909886@edvina.net> From: Joe Touch Message-ID: <579A6FF3.7060607@isi.edu> Date: Thu, 28 Jul 2016 13:49:55 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <626DA5EA-27FD-42D9-9B29-5C9CC0909886@edvina.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 20:51:33 -0000 On 7/28/2016 1:40 PM, Olle E. Johansson wrote: > ... >> Those vendors shouldn't be looking at TCP options or TCP at all. It's >> none of their business. > Well, the question is what they are trying to solve by breaking TCP? > I personally suspect that the latency on some radio networks cause > a lot of retransmits. By adding a TCP proxy they avoid retransmits > wasting bandwidth and at the same time causing issues when it > doesnt work. Can we help them with a better solution if this is > the problem? They should be doing FEC or ARQ at the link layer or via a tunnel across multiple radio links, but that requires more effort on their part (inserting and coordinating multiple components, rather than just one). > Does anyone know what the problem they are trying to solve is? > (Still trying to find information) The one you cite above is one. Another intermittent connectivity. Another is bandwidth or device capability, but in those cases the proxy can be visible. >> This issue cannot be fixed merely by reacting to what vendors deploy. >> >> The solution has been clear for a long time - *compliance verification*. >> I assure you that vendors that get sued for saying "Internet compatible" >> who are not would behave differently. > So where do we have a good specification that we agree on defining > Internet compatible ? RFC1122/1123 for hosts. RFC1812 for routers. Joe From nobody Fri Jul 29 07:52:45 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8563812DDE9 for ; Fri, 29 Jul 2016 07:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=aero.org header.b=lO58x1o4; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=eGMEYUXi 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 tiuL_Una0uUb for ; Fri, 29 Jul 2016 07:52:41 -0700 (PDT) Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D7012DDB5 for ; Fri, 29 Jul 2016 07:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1469803961; x=1501339961; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=uOnssxqZY+m2ofkW+UrdMTmLHPGDl0jz+E32zz/fp4g=; b=lO58x1o4bdUA6oFdOnV09wI2ivJ1XHfcgJjCSsfV3PCnd0qzVkaVnzgU bBiljTgcs+PirtG08MUB7eifIkFrNZP0J5A7LmlmGIdvmEXxWj0gkYmTf 2qP3khnWX1+9jNG/AkJAeaM7QCx3Tp1eN6bmJcOQHlwg8aCgoDwDWoB9/ o=; x-SBRS: 3.5 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,8241"; a="3987263" X-IronPort-AV: E=Sophos;i="5.28,440,1464678000"; d="scan'208";a="3987263" X-IPAS-Result: A2FKAAAobZtXhzTGZxdaAw4LAQEBAQGDfU4EKgaNJatcgX0chgECgWIUAQEBAQEBAQMPAQEBCA0JCRkvglE5PAEBAQEBAQEBAQEBAQEBAQEBAQEWAg0nNwEBAQECARIBJwYBATcBDwIBCBgeEDIlAgQBDQUIEweHdQMPCKArAYEoARxhBSgCim2FKgEBBYUEGIQJAQEBAQEBAQMBAQEBAQEBGAMFineEQAIfJoJlgi8BmTeGGIJ8lSqMMYN4HoI7DAERC4ERO24BhmsBfgEBAQ Received: from mail-dm2gcc01lp0052.outbound.protection.outlook.com (HELO gcc01-dm2-obe.outbound.protection.outlook.com) ([23.103.198.52]) by email5-west.aero.org with ESMTP/TLS/AES256-SHA; 29 Jul 2016 07:52:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector1-aero-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p8OQxbsmcbTJjDISHBvlSAQ4lZOGCNpuPRUD5TMuEkQ=; b=eGMEYUXiJHZOVZ9E3SGAdmCQeZaH/GpEi6S3mP+GouaQtMRjKZLHJVnWp227kMmo5io5bkQ0KnLyzbK94wo93x3/9AHWOhBIq42TjLggmFQcI6Lv859WDODQyspP3kOMEbXzBnDF8DK43gV6pmp2tG4cSvEi7C4067dFBNIa+SQ= Received: from BN6PR09MB2130.namprd09.prod.outlook.com (10.173.160.146) by BN6PR09MB2131.namprd09.prod.outlook.com (10.173.160.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 29 Jul 2016 14:52:37 +0000 Received: from BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) by BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) with mapi id 15.01.0549.016; Fri, 29 Jul 2016 14:52:37 +0000 From: Theodore V Faber To: Joe Touch , "Olle E. Johansson" Subject: Re: TCP proxys in mobile networks Thread-Topic: TCP proxys in mobile networks Thread-Index: AQHR6AQ/D1QqACJDx0asfhcGGcvuig== Date: Fri, 29 Jul 2016 14:52:36 +0000 Message-ID: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> <579A6EE2.1010000@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-originating-ip: [130.221.224.7] x-ms-office365-filtering-correlation-id: 6a8dc88f-52d7-47a1-b73e-08d3b7bffb30 x-microsoft-exchange-diagnostics: 1; BN6PR09MB2131; 6:VZyt9/ja7isZPfW8iSlZTaDmOBvpuTZU4hGsEa1jKcU0qyJmMmn9rU9EsTcBYW4LTq/eootLGfJu29XjIG0OITGd5CYv6NMTs+etJj8WAwh9Yc96Ll7wmsLTfSW05MKLESnTDDD0kh0R1Zedfrh/GhVhsmuJnyJtS5kRl3vI8i/7qL4EO35Z3cQ8X/NBzmUCGtQgjcsL1kn+Ak/ZhZGmp47XXZJWNradXRKsHQ7urWi7fvQYHHpMmgrEATLR+oAeQzG4GjtU/fmZm+FFt96p0EPFGkWjp58yWkpm2jS3krfiwoXkvNWqyOEnRBRt6giMOOKV0xgay5Xal7Cq+zWLTA==; 5:80KfpktvENKWOExE9JUlEP6UwE0NeEDR8K/rOJpWdoxTbnygyRZuyNhAwD1AjRNbNu/zY7eN1BJS+7zMg7eSIqm87n/0fjmA2Hl0QMcBzMdV6UltgWRWI//2OEgVpMkgiTVnfm9SBqntVAwDm5n3dQ==; 24:ojl6tyWQnqFk1m7S4VnZZQy9xK7Xm5QMtAZXZSGXjEwXx7JVkdX5uevLr7HdSguQxnoQ/VZpB9h61PNgtocA+56+fIPWcpxCu8pFFiUVgzo=; 7:hqyrPBDjyGChPA2ijuLDmSI+iUDqHaTKKkZ+m8DQVRMUe9jm/USgKSb28yXrh+9YglAeiu06eBXNhtRfLvwg26L/wOSpaDNuAUAVIJuzBl/UK8tgo+rvTK7K7vXtbOH4eJjsxugeSUkdK9jqAqF7FIeTxgr6MK8FwZ4kxBAt+eh7ydG+E57rl9xgBbP9T5YR/tDRP6TqjPGCyLSys1fwt9HtWN9Crdd9GNjwrPPCa/x9kjioAjjzQUztfmH5lMCg x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR09MB2131; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN6PR09MB2131; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB2131; x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(54524002)(199003)(377454003)(24454002)(106116001)(3280700002)(7846002)(189998001)(99286002)(19580395003)(74316002)(7736002)(8936002)(9686002)(106356001)(305945005)(92566002)(4326007)(5001770100001)(10400500002)(105586002)(68736007)(97736004)(5002640100001)(81166006)(101416001)(19580405001)(7696003)(3660700001)(11100500001)(8676002)(122556002)(50986999)(33656002)(76176999)(54356999)(77096005)(15975445007)(575784001)(87936001)(86362001)(93886004)(76576001)(66066001)(2906002)(586003)(2171001)(81156014)(102836003)(3846002)(6116002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR09MB2131; H:BN6PR09MB2130.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2016 14:52:36.8741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB2131 Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 14:52:43 -0000 -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA512=0A= =0A= On 7/28/16 13:46, Joe Touch wrote:=0A= > =0A= > =0A= > On 7/28/2016 1:29 PM, Theodore V Faber wrote:=0A= =0A= >> No. The Postel Principle applies to networking in general. "Be =0A= >> simple in your behavior and tolerant of others" does not include=0A= >> any proviso about an IETF position.=0A= > =0A= > "Be liberal in what you accept, and conservative in what you send."=0A= > - RFC1122=0A= > =0A= > RFC760 puts it into exactly the context I indiicated:=0A= > =0A= > The implementation of a protocol must be robust. Each=0A= > implementation must expect to interoperate with others created by=0A= > different individuals. While the goal of this specification is to=0A= > be explicit about the protocol there is the possibility of=0A= > differing interpretations. In general, an implementation should be=0A= > conservative in its sending behavior, and liberal in its receiving=0A= > behavior.=0A= > =0A= > I.e., applies when there is ambiguity.=0A= =0A= That's a remarkable interpretation of the "In general," prefix that I=0A= simply disagree with. (And for the record, I agree that the principle=0A= applies when there's ambiguity; I also think it applies when there is=0A= none - it applies "In general".)=0A= =0A= Beyond the textual analysis, I think restricting that idea in the=0A= (IMHO narrow) context of resolving specification ambiguity sells it=0A= short.=0A= =0A= > =0A= >> ...=0A= >>>> The IETF standard reflects a consensus among designers and =0A= >>>> implementers that there's no constraint on TCP option=0A= >>>> ordering. The time to argue about it is past; live with it or=0A= >>>> produce crappy products.=0A= >> =0A= >>> This issue cannot be fixed merely by reacting to what vendors =0A= >>> deploy.=0A= >> =0A= >> "React?" Bah.=0A= >> =0A= >> How is my position unclear here? I advocate that the IETF do=0A= >> nothing.=0A= >> =0A= >> Perhaps in a just world, their competitors should pipe up and=0A= >> say "Whoever's crappy product breaks stuff." The IETF has said=0A= >> its piece: "there is no constraint on the order of TCP options."=0A= > =0A= > That's not strictly true. RFC5925 requires that TCP-AO come first, =0A= > because it would be impossible to undo the effect of processing=0A= > earlier options when the AO option might indicate the packet is not=0A= > authentic.=0A= > =0A= > However, I'm only saying that the IETF should not be changing TCP=0A= > specs solely to transit devices that violate this order=0A= > independence.=0A= =0A= That sounds like we agree. :-D=0A= =0A= > =0A= >>> The solution has been clear for a long time - *compliance =0A= >>> verification*. I assure you that vendors that get sued for=0A= >>> saying "Internet compatible" who are not would behave=0A= >>> differently.=0A= >> =0A= >> We prefer different societal pressures, evidently. I like the=0A= >> one where I can be lazier.=0A= > =0A= > It's fine to say "just don't deal with middlebox option order=0A= > issues", but then we end up with broken behavior.=0A= > =0A= > Is that a viable way to leave things?=0A= =0A= I am not personally nor is the IETF collectively in a position to=0A= enforce good behavior from network devices. At the scale and=0A= complexity of the Internet, I don't think one could enforce even=0A= compliance with published IETF standards.=0A= =0A= I think trying to turn the IETF from a group of engineers who publish=0A= their consensus on interoperation issues (y'know mostly) to some kind=0A= of implementation evaluation and enforcement body is a waste of time=0A= at best and counterproductive at worst.=0A= =0A= I understand that we disagree on this, and I'm a little sad we won't=0A= get to do so over coffee.=0A= =0A= - -- =0A= Ted Faber =0A= Engineering Specialist=0A= Computer Systems Research Department=0A= 310-336-7373=0A= -----BEGIN PGP SIGNATURE-----=0A= Comment: GPGTools - https://gpgtools.org=0A= =0A= iQIcBAEBCgAGBQJXm221AAoJEFNjQnOBW8uO174P+gIRyGNpSbWo3iHNTCFb0hie=0A= bbtuJ3wBbMulC5T/PTglF3CWHpUKXUVAX4Bj4PllGYHHvEGsSjfsGLi0u1Cvtue7=0A= ubGXiw+Gim+axcorl7D6bogkTQbH4MmgOIoPiymRQQ8lICqnVhBaSfi1aSdr0PBY=0A= e0TVHJZicd83IG2P4S0zM2HapPZV43UPHNMgbcuX6/1EPZ/UGZY81T4Ut7O4aIw7=0A= t6VE52iW416mcNyfQXcOHTN6RuhKjLnu/4au5mpBeZlRqR5EeLSP3JtDGpoFF4Sl=0A= 61No/qcaYLpxH+g+0XMjF9DqAiAfTj0pSWIwYn00Y5GGizgE44M5q4/V8IZ/MwzM=0A= 5yuB+5Rk1DHHTnJ9Q7+kGzPf2M55faiqUcLwyjNR/Chu5oSUcqOQYXyDbbh3fbJx=0A= eDxmO8xpnQBELFqBYN8hEPmDukAyHBIuW9StyJ+jrU5BawXBMzR8x4FN2/gYiRMJ=0A= 8XjpVoMp8WU9nj/cmHZPcJf9aO/knLX9jwytdXUYEevxylch+bpkszQkb7IDGuc3=0A= I5hIN1sHibONr1RwdmMbwYyJwXgORcpzC8zuHk5aGYBbE8Ufgw7mfRcDcqeaO7vr=0A= uPRhHUQ68KHGnTjGAEb/cfQ/JaIyxqPTjrnx3Jnor4ObRxkGTxymiZQM1BRVVEUG=0A= faq018lavMUE1SU8j+JF=0A= =3Du47i=0A= -----END PGP SIGNATURE-----=0A= From nobody Fri Jul 29 10:16:40 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B3B12D7E4 for ; Fri, 29 Jul 2016 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 isap6RYNQztV for ; Fri, 29 Jul 2016 10:16:37 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4876212D792 for ; Fri, 29 Jul 2016 10:16:37 -0700 (PDT) Received: from [128.9.184.41] ([128.9.184.41]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6THFoDJ014208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 Jul 2016 10:15:50 -0700 (PDT) Subject: Re: TCP proxys in mobile networks To: Theodore V Faber , "Olle E. Johansson" References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> <579A6EE2.1010000@isi.edu> From: Joe Touch Message-ID: <579B8F44.7000107@isi.edu> Date: Fri, 29 Jul 2016 10:15:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 17:16:38 -0000 On 7/29/2016 7:52 AM, Theodore V Faber wrote: >> "Be liberal in what you accept, and conservative in what you send." >> > - RFC1122 >> > >> > RFC760 puts it into exactly the context I indiicated: >> > >> > The implementation of a protocol must be robust. Each >> > implementation must expect to interoperate with others created by >> > different individuals. While the goal of this specification is to >> > be explicit about the protocol there is the possibility of >> > differing interpretations. In general, an implementation should be >> > conservative in its sending behavior, and liberal in its receiving >> > behavior. >> > >> > I.e., applies when there is ambiguity. > That's a remarkable interpretation of the "In general," prefix that I > simply disagree with. (And for the record, I agree that the principle > applies when there's ambiguity; I also think it applies when there is > none - it applies "In general".) > > Beyond the textual analysis, I think restricting that idea in the > (IMHO narrow) context of resolving specification ambiguity sells it > short. Can I then ask where you define the limit? What happens when you get an IP packet with protocol type = 18 (not 17), but it otherwise represents a well-formed UDP payload? My interpretation suggests the following: - If there is a valid behavior according to the spec, it MUST be accepted even it it does not represent the typical interpretation of the spec, or if is otherwise "unusual" (I've phrased this before as "a packet doesn't represent an attack merely because it's not what you expect"). - If a spec prohibits something, it MUST NOT be accepted (even if it "could" be) This covers all possible cases (spec is clear, spec is ambiguous). I include "spec says nothing" as "spec is ambiguous" IF there are multiple ways that the missing information could be interpreted *consistent with the explicit limits of the spec*. So I'm struggling to figure out an example where you think "in general" means what you think above (FWIW, I think it is intended to refer to the phrase - i.e., "put in a general way", not "this should be applied to all cases, not just ambiguities"). Can you give an example? Joe From nobody Fri Jul 29 10:35:23 2016 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14DA12D9CA for ; Fri, 29 Jul 2016 10:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=aero.org header.b=oBPEiGUI; dkim=pass (1024-bit key) header.d=aerospacecloud.onmicrosoft.com header.b=nYfn05oR 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 IcRmKuyHKhSa for ; Fri, 29 Jul 2016 10:35:20 -0700 (PDT) Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367CF12D14B for ; Fri, 29 Jul 2016 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1469813720; x=1501349720; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=K3Py2OoA+7D1i6kIv/y7A9q4QtZRc9osDD6PY6Rk6zc=; b=oBPEiGUIMGiHMpqVhTq85mdsosY9SJ7Pcq7rF6SzIbC9UL/bj35VBcKz uQ+FBfonNmuwZmnZAmZ54ES6A0dU7yuprGZI4xkDBPZ8ItBYatmPjaNC2 hoPE6uHukggMqL2PSS/JeLL4RP7txmt1p+fygEjnASFkGYSvgQOqtayLB A=; x-SBRS: 3.5 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,8241"; a="3988507" X-IronPort-AV: E=Sophos;i="5.28,440,1464678000"; d="scan'208";a="3988507" X-IPAS-Result: A2FNAACRkptXhzDGZxdaAw4LAQEBAQGDfU4EKgaNJatggX0chgECgWQUAQEBAQEBAQMPAQEBCgsJCRkvglE5PAEBAQEBAQEBAQEBAQEBAQEBAQEWAg0nOAEBAQMSAScGAQE3AQ8CAQgYHhAyJQIEAQ0FCBqHdQMXoGQBgSgBHGEFKAKKbYUqAQEFhQAYhAkBAQEBAQEBAQEBAQEBAQEBAQEXAwWKd4QdIwIfJoJlgi8BmTeGGIVvhHmNPowxg3gegjsMEguBETtuAYYnRAF+AQEB Received: from mail-dm2gcc01lp0048.outbound.protection.outlook.com (HELO gcc01-dm2-obe.outbound.protection.outlook.com) ([23.103.198.48]) by email5-west.aero.org with ESMTP/TLS/AES256-SHA; 29 Jul 2016 10:35:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aerospacecloud.onmicrosoft.com; s=selector1-aero-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gbOORGJzmLwuqv3k83GfkkKAJSI0mvtP24dzWEHpPrk=; b=nYfn05oR/PfDp+oyWH7BahyEJp3KkdeCw2qPZ2GGRG+gf25lv5gh6lQdbHQ6oK7fom48ss3Ze+ei4d4+AM2Oz+HUz9QG2M+2ph1eTYKnSyloJEJtndji6tJiMyRqlaX8KB03RkcGeiuJkRt0pGVRxNBzPUgcONb0cEnODmXKWkA= Received: from BN6PR09MB2130.namprd09.prod.outlook.com (10.173.160.146) by BN6PR09MB2132.namprd09.prod.outlook.com (10.173.160.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 29 Jul 2016 17:35:14 +0000 Received: from BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) by BN6PR09MB2130.namprd09.prod.outlook.com ([10.173.160.146]) with mapi id 15.01.0549.016; Fri, 29 Jul 2016 17:35:13 +0000 From: Theodore V Faber To: Joe Touch , "Olle E. Johansson" Subject: Re: TCP proxys in mobile networks Thread-Topic: TCP proxys in mobile networks Thread-Index: AQHR6AQ/D1QqACJDx0asfhcGGcvuig== Date: Fri, 29 Jul 2016 17:35:13 +0000 Message-ID: References: <1E75B421-5879-4EA5-817D-6CAAFA249F1A@edvina.net> <5798D0B2.1040203@isi.edu> <579A4305.7090609@isi.edu> <579A6504.1030607@isi.edu> <579A6864.6030300@isi.edu> <579A6EE2.1010000@isi.edu> <579B8F44.7000107@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-originating-ip: [130.221.224.7] x-ms-office365-filtering-correlation-id: 0187f145-4846-4391-a4db-08d3b7d6b2b6 x-microsoft-exchange-diagnostics: 1; BN6PR09MB2132; 6:asEja7pXJfy0sj7fO+mglcNANdKkNee9p1vyhMNt2CmDXk5WycVBxHGe3LxgPEDnyfGln8vtEjMXZG0s2UxIrP68qEEEyNWPtSt7EsKDFOG6/PxhH3r4EqFv1W3YII1YvWiF01qUI0oF52eNQcAeYZIC7nJANzA+OqE5Xn0+oDcXSQ7Boiw+2Pv5mKpVlTR/qzK/uZT+P9mxHQLljE1+cg0EVF8zOrIv/KbnZbS+juvIljk0h7Z65ZzZfNBN7ytnQEzIe09egQqGDMgUnXD4bcXTR433FxxqEHyLPVI+eeH0sXViqnwTl1quSc7ciUZaKThMxNBJ0qrc3z96B5Vgvw==; 5:XgWAFsyT9RJJ77laowqgcWSnkjtfTz/V5lUMnE03L8/aVkWIbV3u3u1QpeWGmafTnQeGj8h3K7E8YFvbSEyx8RBJgX3QBHxoSxME0aARfWADQO7o33A/bgC3k5Q7qVbFFmdcoMBT9C9wFMA7fzTkbw==; 24:hW+sINeM6ntTo98Svz+5Vq20eq0Fevl1+sKHs+mCDWBKHV3DS8aLrLNLq5Q1anbWZihUA5UVdE2fO8o6hY/UirnGYaTCVVuWQHRI5T7jJfM=; 7:g/smaQlbwxcEK5k5BrG8kt0AxzCkCyPI4iFZeLbo0Fq2YBu1R0hgQlbDS5Qc5i0T0YXsXX0sBWWrQT/dhBZyElNwjEyBbyN3PlQ6Wbxc/xuPD4ObceySYL6+88ItIEfgcz/xRbR7CinJ9G9HoR22W4aRF8cU2De/BaxAVcMinb6lFQee/teYtwN+TS/TQnCyhcj9lQm2A2BWLQUSji4vP4e8hbQjdQfhO7/g6hCZEo0MA2gpLB5lKNyM1rmPKtc8 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR09MB2132; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:BN6PR09MB2132; BCL:0; PCL:0; RULEID:; SRVR:BN6PR09MB2132; x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377454003)(54524002)(24454002)(189002)(2900100001)(7736002)(7696003)(68736007)(101416001)(97736004)(2171001)(86362001)(87936001)(74316002)(5001770100001)(76576001)(7846002)(575784001)(50986999)(10400500002)(54356999)(76176999)(189998001)(66066001)(8676002)(81166006)(15975445007)(122556002)(19580405001)(305945005)(77096005)(81156014)(4326007)(99286002)(2906002)(106116001)(586003)(92566002)(3846002)(8936002)(9686002)(3660700001)(33656002)(93886004)(105586002)(106356001)(19580395003)(3280700002)(6116002)(5002640100001)(102836003)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR09MB2132; H:BN6PR09MB2130.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2016 17:35:13.6939 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB2132 Archived-At: Cc: "tsv-area@ietf.org" X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 17:35:22 -0000 -----BEGIN PGP SIGNED MESSAGE-----=0A= Hash: SHA512=0A= =0A= On 7/29/16 10:16, Joe Touch wrote:=0A= > =0A= > =0A= > On 7/29/2016 7:52 AM, Theodore V Faber wrote:=0A= >>> "Be liberal in what you accept, and conservative in what you=0A= >>> send."=0A= >>>> - RFC1122=0A= >>>> =0A= >>>> RFC760 puts it into exactly the context I indiicated:=0A= >>>> =0A= >>>> The implementation of a protocol must be robust. Each =0A= >>>> implementation must expect to interoperate with others=0A= >>>> created by different individuals. While the goal of this=0A= >>>> specification is to be explicit about the protocol there is=0A= >>>> the possibility of differing interpretations. In general, an=0A= >>>> implementation should be conservative in its sending=0A= >>>> behavior, and liberal in its receiving behavior.=0A= >>>> =0A= >>>> I.e., applies when there is ambiguity.=0A= >> That's a remarkable interpretation of the "In general," prefix=0A= >> that I simply disagree with. (And for the record, I agree that=0A= >> the principle applies when there's ambiguity; I also think it=0A= >> applies when there is none - it applies "In general".)=0A= >> =0A= >> Beyond the textual analysis, I think restricting that idea in=0A= >> the (IMHO narrow) context of resolving specification ambiguity=0A= >> sells it short.=0A= > =0A= > Can I then ask where you define the limit?=0A= =0A= My limit is 3. In general.=0A= =0A= The Postel Principle is an aphorism. A principle. Advice. I would=0A= not even try to quantify this good advice (my limit is completely=0A= facetious).=0A= =0A= I'm not going to advocate ignoring IETF standards based on the words=0A= of Jon Postel. If you look at my first message in this thread, you'll=0A= notice that I castigated these implementers *based* *on* *that*=0A= *principle*:=0A= =0A= To say that another way: vendors who produce such devices [that make=0A= assumptions about TCP option ordering] are failing to follow the=0A= Postel principle.=0A= =0A= In general, being conservative in what one sends implies following a=0A= standard when one exists. Why are we trying to quantify our agreement?=0A= =0A= - -- =0A= Ted Faber =0A= Engineering Specialist=0A= Computer Systems Research Department=0A= 310-336-7373=0A= -----BEGIN PGP SIGNATURE-----=0A= Comment: GPGTools - https://gpgtools.org=0A= =0A= iQIcBAEBCgAGBQJXm5PSAAoJEFNjQnOBW8uOfbYP/2Pw5TWGtUZzUMQl/2C8g1hg=0A= ED0HIQ1CCYdZm+8aOgTjvZTpYWTU/uwAf2ypBZeaAphCN5j1+EtVfpGgH4HSG7CR=0A= MapyjbNd+Ru6a8YGpwhdnupWO1rKLtb2BRJjkjlIclAPdeu7Wrt+XOu0UlQYFB3n=0A= aiiXs9DQX5s6PlL0w59ie/91LLotZ2YqsYA/TfGvDrh2z/74bSMnIFdPH34Qev/5=0A= +QcP0J+PADD052GtTLWD1aCsT+Kv3LrxEwYhDbcFVVVqTrSGlyVcJM4ju81S4rhR=0A= HuYWuap+ToSkKyjdnm3vCpohHPjpm9skvme+9hHvA5WLtVKN5aU8pD3SvTqW4vpN=0A= lZDKNEuIYEbR2kMPr4NyrvO5stCQ4Y/OzlOF/yLu87nyom/eXUqnTWMorMFaa9AM=0A= WFVMEkTwSwSeAwfgwx26R02tbgOmmavh56LRgftXd/YpmqPGbiecSmd1lSC2dZKy=0A= qxfDkC69sELtOw1vx5E/Txbj6siYNyW/vBGDYV/cR9bBM0uplYKxkTc1AL3zUcrj=0A= b6mxP8hEL+nzrfuSnUgN6VjGXiwOsgADbQGHQdYEEsBYw70Jz307APqszTnbQPnJ=0A= 1vc/idUieBuzI0qdv5DMu8ahJBRevlMuw15EQqsgdWPhzQ5iJ0Ymo6N5At5c9eES=0A= ok/a2kgFFquAXruI65eX=0A= =3DeP/E=0A= -----END PGP SIGNATURE-----=0A=