From nobody Wed May 1 11:55:11 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18012008D; Wed, 1 May 2019 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 FGWfdLu12vy6; Wed, 1 May 2019 11:55:00 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 17F88120021; Wed, 1 May 2019 11:54:59 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id x15so8560622pln.9; Wed, 01 May 2019 11:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=RlXnca01+Nw8qZwp1Gio8Luahnr9NcYZvBNsG8MVF58=; b=U8eG+p2IpZL6PEPS36L+y6ihTYVKsqFo3Q9MkkB4D/A/fBgRK3t8hKbMx0/f77y4Pf DWHCrb3lwrHPX+F9Jp7kdijvMiXQS5PMG5JL3Gb0vxn+VnLPytMO7xmWlNo+0yRa8qbr RBipSvTN/YZoUPswkAgodby9v93Quzg7iA9nh1kW3Xy2L9Mz6gensBGF+M8+V0qOMELH yYcF47WFnTm3or86NIuSVcul75NJMGDlT/AvnuC6ZvYvWjqRfnkWHflW+m+gPg8CYkMI qAiWYJxOJHHK0MDp9Ex/Zh4FvKSC/6IvWTQJBkFkBKyUwNy76QLg656EIYamylDRY9VS RuLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=RlXnca01+Nw8qZwp1Gio8Luahnr9NcYZvBNsG8MVF58=; b=TxWJ549FeSOk9J2xkuHEDuyTp5wdrqUXB2MKpbdqBcF2kvjJlLWCL4wFcFxIQr9qey 2zBR5wIANsx6XGlpokGOjsTq92eqVl+9vtqQ61K4z4RxI71/dVfuRm69iW8PtDbocBDK zUHcD+hfTYHVlndmuzrUo6yMh0KeeaWTqhF9hw/7FYO8qA3nfkKJAMz1ScjSZ8bD5GzT HB2PT+44loVUwKxQewaJIe4iAZEHSjFs20gVw7CfBFqs55twwje5okdcZON8fniN74/7 Tja/Z7l4Oe6EhtRaRGoa1cecwv+nbjMxm8rXWz3zuyAHJURlR99MikE8JX7UgKJMeYxZ jiXw== X-Gm-Message-State: APjAAAWdNEFoiLHL9wuLU5RZN7TftcXztyjm75xUPLT4HZa8CPPzlSc1 lMxjFL8ISqVIHQu1bsB8NqtsNnbQSO0= X-Google-Smtp-Source: APXvYqz0iFbRuvuOTcMId0lljXtnygaG4NMMSmqm45DR2WoofSaXrTS5A0B9Ra5ZIuJ8GNM81RU+jg== X-Received: by 2002:a17:902:7b8f:: with SMTP id w15mr28456113pll.314.1556736899155; Wed, 01 May 2019 11:54:59 -0700 (PDT) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id z127sm21107472pfb.53.2019.05.01.11.54.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 May 2019 11:54:57 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com> Date: Wed, 1 May 2019 11:54:56 -0700 Cc: tcpm@ietf.org To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [tcpm] Re-issue of adoption poll for draft-kwatsen-netconf-tcp-client-server-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 18:55:02 -0000 As noted in the mail yesterday to the NETCONF WG, I am issuing a new = poll on draft-kwatsen-netconf-tcp-client-server draft that was discussed = in 104. There were comments that were received on the -00 draft that was = presented in 104, that have been addressed in the -02 version of the = draft. Since the original poll was on the -00 version of the draft, we = (the chairs), felt the need to re-issue the poll. Also, that poll = included the HTTP client/server draft, which is still under discussion, = and as such has been removed from this poll. The TCP client/server draft did get support in 103, so rather than = asking for a repeat of that show of support, I am asking if there is any = objection to the adoption of this draft. If you do have an objection, = please state your reasons for why you feel this work should not be done. The poll will run for two weeks, till May 15, and if no objections are = received by then, the draft will be adopted as a WG item. Cheers. Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed May 1 22:48:02 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C90A1200A0 for ; Wed, 1 May 2019 22:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 CPD3L7xqidiS for ; Wed, 1 May 2019 22:47:58 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800120.outbound.protection.outlook.com [40.107.80.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D96120044 for ; Wed, 1 May 2019 22:47:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=X8WwV2/tb2mK7t8AHI3FHECE+2fl7ya8yoXXyAUncZm+qdnovGwOUFncizYettu0sc7YNvaJdX1VqU1mP3hs2yh6DoCk7SDdxWfuWZAzJnXx3aSI6GOb0mLObLOTIxw06yj6h26rhn44AaZq3DIYOZ4v5vVEcigRoWbT11zbqvk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSZmKFE+qFdXXHuOCwbsxTuFMfNbZggHioP1C94FzVc=; b=ioG/2F482tIhMHo74nqLXhfeMeaEVJXGchAVHsBhGrl+7v4ibg5RXc7H9yXi7NCbCnG56XNV7JD5gtaJ/tOIzuVqn5WRHcfXWWaDnNbgnjvPz8vfhMlchSgc3ZTd0YE95ec1uJ/a0BD7DxvTyBfWCitFOfhcIfnBZr5AeGnUY2A= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iSZmKFE+qFdXXHuOCwbsxTuFMfNbZggHioP1C94FzVc=; b=NlQEzieIyE/oAvjfxE3VltC+cZxXSzThUOVzzUuo0bJDctkjlIoAd/WC937wO7H4OS4YSYGcImFyiWoAqrF4/fqqiQtVdTptNWTwM9rnNwNnPOSVA71+cCRZd5ugiiI8qJCaS8rMcybCtugQLCoNR3pTY6d6OhebV1bLCWm+NsM= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1074.namprd21.prod.outlook.com (52.132.24.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.9; Thu, 2 May 2019 05:47:56 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1856.004; Thu, 2 May 2019 05:47:56 +0000 From: Yi Huang To: "tcpm@ietf.org" CC: Praveen Balasubramanian , Matt Olson Thread-Topic: Questions about TLP Thread-Index: AdUAqnPmaX0KgH/WQE+MIFBj5gEdQg== Date: Thu, 2 May 2019 05:47:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-02T05:47:54.8308835Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9c927d00-22ac-4c49-9ca3-daaaf7816e45; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:1:30c4:3613:61af:58ac] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff430e2d-4c13-41e6-b572-08d6cec1b9dd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1074; x-ms-traffictypediagnostic: BL0PR2101MB1074: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(346002)(376002)(366004)(199004)(189003)(256004)(73956011)(86612001)(86362001)(5640700003)(107886003)(66946007)(66556008)(66446008)(46003)(476003)(66476007)(64756008)(76116006)(52536014)(316002)(6916009)(55016002)(8990500004)(1730700003)(81166006)(81156014)(8676002)(6116002)(2501003)(790700001)(2351001)(14444005)(10090500001)(8936002)(71190400001)(71200400001)(6436002)(3480700005)(5660300002)(102836004)(4744005)(6506007)(25786009)(54906003)(53936002)(22452003)(2906002)(186003)(478600001)(74316002)(9686003)(10290500003)(6306002)(54896002)(486006)(7116003)(7696005)(99286004)(7736002)(68736007)(33656002)(4326008)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1074; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8mFI4VRfLkukNAUm5rO0ol6E8NoG46oEoNSYkFm0yVsiN3yFT+gAPY0AwYe7TcTdRC8Y4WCXlI0SpC4UaB2+tP06ol34kVeBIpjTNWRbZYOp0A5sLD/6Ou+gSxoFCXqLh3XnN4lujHKor8aUOjKou7yyDAgy2E1RqAo9VPq7WWzaZGGxck2VP5BKf6VB2gFIF2Pqwmu/QAIBI+3tfyY7TJ698l++JCX+QF8BG+mMtCtZNpt40o8zaYCrtWM6h5iZ2ycy4nNCm/eMS+tyCr1kkvFHJt3QMZ90+XkusBxv06WeRCg1sX2YJ+Xf6xmdZ1ohXxTRkJvBxwaAUGnenUrpNO8Sf3Qx2/bZPzhfj7pt87JzUVV0GNkgcSl9iv/9tNR+FxvCzJgiatbATQahtchZBliD4Nvlq6m0EylkrqDRbx0= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043C5ABE55E48572EB20C62C3340BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff430e2d-4c13-41e6-b572-08d6cec1b9dd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 05:47:56.0689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1074 Archived-At: Subject: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 05:48:02 -0000 --_000_BL0PR2101MB1043C5ABE55E48572EB20C62C3340BL0PR2101MB1043_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi RACK/TLP authors, I have the following questions (page numbers refer to draft-ietf-tcpm-rack-= 05): 1.In page 16, it says "Finally, if the time at which an RTO would fire (her= e denoted "TCP_RTO_expire") is sooner than the computed time for the PTO, t= hen a probe is scheduled to be sent at that earlier time." What does this T= CP_RTO_expire actually mean? Does it mean there is another RTO timer (possi= bly started some time in the past) running along with PTO or just RTT + 4*R= TTVar + Now()? Also, why would another probe be sent at RTO expiration time= instead of treating it like RTO and collapsing the cwnd? 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it is sta= ted that TLPRxtOut is used to guarantee that there is only one outstanding = TLP retransmission. However, it is not clear to me when TLPRxtOut should be= really used. Should it be used in 6.5.1 Step. 1 (checking whether we shoul= d and can schedule a TLP) or in TLP_send_probe()? Thanks, Yi --_000_BL0PR2101MB1043C5ABE55E48572EB20C62C3340BL0PR2101MB1043_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi RACK/TLP authors,

 

I have the following questions (page numbers refer = to draft-ietf-tcpm-rack-05):

 

1.In page 16, it says “Finally, if the time a= t which an RTO would fire (here denoted "TCP_RTO_expire") is soon= er than the computed time for the PTO, then a probe is scheduled to be sent= at that earlier time.” What does this TCP_RTO_expire actually mean? Does it mean there is another RTO timer (possibly started s= ome time in the past) running along with PTO or just RTT + 4*RTTVar = 3; Now()? Also, why would another probe be sent at RTO expiration time inst= ead of treating it like RTO and collapsing the cwnd?

 <= /p>

2.In page 18 secti= on 6.6, a new variable TLPRxtOut is defined and it is stated that TLPRxtOut= is used to guarantee that there is only one outstanding TLP retransmission= . However, it is not clear to me when TLPRxtOut should be really used. Should it be used in 6.5.1 Step. 1 (check= ing whether we should and can schedule a TLP) or in TLP_send_probe()?<= /o:p>

 <= /p>

Thanks,=

 <= /p>

Yi

 

--_000_BL0PR2101MB1043C5ABE55E48572EB20C62C3340BL0PR2101MB1043_-- From nobody Wed May 1 23:33:50 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331E12004C for ; Wed, 1 May 2019 23:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Mua7wwieWFr8 for ; Wed, 1 May 2019 23:33:45 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 CA925120006 for ; Wed, 1 May 2019 23:33:44 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id a12so1579191wrq.10 for ; Wed, 01 May 2019 23:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xeOrSmjczwx4TICWotjjMmnoUPS6+vpMl1oBIBaxl7k=; b=ZXjA0UKZrw8kDMwboqbBSc3gWNvMSuJsjLILXkYBBrbCu/dV3pnCM0fKvHKSTBXkdj I4OLLUfWgSbMPukE+BbItarlD4/WQLSK98w9U9CcoIJDBVZ+CL+9VSwXANJ0khZUl38X qf0EnP1YdTItVTJanElPFUTecGYNIBnFfIMWRwMNNhNu4Od7+ANFiLofyQJ3L+ak8f7I sRmNsRxR2lvJExXZUqEuupfnIrvSkZAGMy66W64xERVPyNUvBGdAoPOylxOz4Czhq/mw Ex+ohJ6CWMGl8kcxjKyGp9Kmrz23B9GfPu8UXWbqXXpPaXLMMrv7mk6TrD03GYNQqLIY cAgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xeOrSmjczwx4TICWotjjMmnoUPS6+vpMl1oBIBaxl7k=; b=QjLapQ+rpbbGtShLDMa7AdYJDXZ23mxKX/dg33y1Ii74lLUVsluyhYmzitQi5kWgAO b45GkCCYP/OM+bUWA0WlTnSTe8413q8whD+oBXHxjsHKYQTDzr0urwkYArj8hgCBUGIg XYT9dWdA3jpLzehJvrKNG0G1UO3bj2j1ObujLcXJ07+DjNIzwx39wzAEHzF7d24r/WYE Z5rTOzbSST0sAeJazQAwNXfgOjDUJvqQSDassJsZHoz4xDLPNeJ5SJ/ThL55V4rHYvWC DHU094htLF91fmEygZn/WnZ2QlMcJs5xJM3JZX3ai1uv7e0pgClxzFoLdPM3m7Ojhx2x bsjg== X-Gm-Message-State: APjAAAWhcm6tp29skicDY2ZA6FWR9uFqntU6dawgOkBagtbJZmw+NCTH qb4IHcWjkWX0A4jvgVsv1y3AXtNR4MKF15j6Zr2u4w== X-Google-Smtp-Source: APXvYqwXR+2CFfxBOWbIYD6S4pEIdTpdjsgrEBZT3T7kGAsLi98aDCQvUneLof1omUnKKCZP8vajbmmoRNUARSTwobQ= X-Received: by 2002:a05:6000:104c:: with SMTP id c12mr1331667wrx.35.1556778822610; Wed, 01 May 2019 23:33:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 1 May 2019 23:33:04 -0700 Message-ID: To: Yi Huang Cc: "tcpm@ietf.org" , Matt Olson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 06:33:47 -0000 On Wed, May 1, 2019 at 10:48 PM Yi Huang wrote: > > Hi RACK/TLP authors, > > > > I have the following questions (page numbers refer to draft-ietf-tcpm-rac= k-05): > > > > 1.In page 16, it says =E2=80=9CFinally, if the time at which an RTO would= fire (here denoted "TCP_RTO_expire") is sooner than the computed time for = the PTO, then a probe is scheduled to be sent at that earlier time.=E2=80= =9D What does this TCP_RTO_expire actually mean? Does it mean there is anot= her RTO timer (possibly started some time in the past) running along with P= TO or just RTT + 4*RTTVar + Now()? Also, why would another probe be sent at= RTO expiration time instead of treating it like RTO and collapsing the cwn= d? TCP_RTO_expire() should return a timeout value for regular RTO, i.e. SRTT + 4*RTTVAR + Now() We use TCP_RTO_expire() because many implementations including Linux do not use the exact RFC formula The reason it's not treated as a regular RTO is to avoid resetting congestion window to 1. The rationale is if the probe was sent within min(PTO, RTO) and was delivered successfully, there's no need to reset congestion window and re-start slow-start, similar to the rationale of Reno's fast recovery reducing window to ssthresh instead of 1. We have found this strategy benefits wireless connections, as the chance of spurious RTO is high due to the delay variation. > > > > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it is s= tated that TLPRxtOut is used to guarantee that there is only one outstandin= g TLP retransmission.. However, it is not clear to me when TLPRxtOut should= be really used. Should it be used in 6.5.1 Step. 1 (checking whether we sh= ould and can schedule a TLP) or in TLP_send_probe()? This is in 6.6.2. Recording loss probe states Senders MUST only send a TLP loss probe retransmission if TLPRxtOut is false. This ensures that at any given time a connection has at most one outstanding TLP retransmission. This allows the sender to but I agree it'd be more clear to include this in TLP_send_probe() pseudo code. I'd incorporate in the next rev. > > > > Thanks, > > > > Yi > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu May 2 02:16:16 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC4E120318; Thu, 2 May 2019 02:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 BEWIruCkZZa8; Thu, 2 May 2019 02:16:07 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB180120312; Thu, 2 May 2019 02:16:05 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 02 May 2019 12:15:59 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=8ZW61b5NB8GJ5plQz cNqN0yNAwKY712uuAd/rsqP+k0=; b=QMO7gjwae07Sfo+wMu/i/noz87lGO28b0 850mrcu1kCioMtITsDxRLHrYoIubsul5K6STu11RuKGAIoYQO4jddCd+YH0Oa4ig ulP88WoaDRDJVImvq28vc0LlmOrI6ioLE1wMkt5TZ9XJvy4TJH2nRa8lRCRe7D7u ru+u4Ta+DI= Received: from hp8x-60 (85-76-8-120-nat.elisa-mobile.fi [85.76.8.120]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 02 May 2019 12:15:59 +0300 id 00000000005A014E.000000005CCAB54F.00003E45 Date: Thu, 2 May 2019 12:15:59 +0300 (EEST) From: Markku Kojo To: lwip@ietf.org, tcpm@ietf.org In-Reply-To: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com> Message-ID: References: <4de71836-c2d1-2a64-6836-8d69a38d4a3d@ericsson.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: [tcpm] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 09:16:10 -0000 Hi all, I have reviewed the -07 version of this draft for the WGLC. The draft is very useful for many developpers using or considering of using TCP in CNN scenarious. It has improved a lot from the previous versions but there are still a number of issues worth addressing. See comments below. Best regards, /Markku Sec 4.1. Title: Path properties - Would it be better to use "Addressing path properties" or something similar as TCP cannot (much) affect the properties? Sec. 4.1.1. If I understand it correctly, the discussion in this section is intended to be all about avoiding Path MTU discovery when running TCP oevr IPv6? Therefore, "Avoiding Path MTU Discovery in IPv6" would probably be a better title? In addition, to my understanding TCP implementations typically address the presence of TCP options such that they eat the necessary space for TCP options from the payload, not by increasing the IP datagram size if TCP options are present. For example, if SMSS is set to, let's say 1460 octets, and a TCP sender adds a TCP timestamp option (12 bytes) it will send only 1448 bytes of payload in a TCP segment? What the draft now says in this respect is on the safe side, but it might be overcautious. I don't remember any RFC saying how SMSS and adding options to a TCP segment are related. Maybe someone of the TCP implementors may shed more light to this how? The second but last para discussing IPv4 in this context is very confusing. In particular, the 2nd sentence "In IPv4, the MTU is 576 bytes." is simply incorrect. In IPv4 the requirement is that any host must be able to accept datagrams of up to 576 octets, but there is no upper limit of 576 for IPv4 MTU! Sec. 4.1.2. "In such traffic patterns, it is more difficult to detect packet loss without retransmission timeouts ..." -> "In such traffic patterns, it is more difficult and often impossible to detect packet loss without retransmission timeouts unless ECN is enabled ..." "When the congestion window of a TCP sender has a size of one segment, the TCP sender resets the retransmit timer, and the sender will only be able to send a new packet when the retransmit timer expires [RFC3168]. Effectively, the TCP sender reduces at that moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 segment per RTO, which can result in a very low throughput. In addition to better throughput, ECN can also help reducing latency and ECN can also help reducing latency and jitter." This text is somewhat inaccurate in terms of how ECN works if only a single segment is in flight (cwnd = 1 MSS) and confusing when it says "which can result in a very low throughput". The latter is kind a true, but also necessary to avoid congestion and, after all, it may result in higher throughput compared to the case where ECN is not used and retransmissions are needed. I'd rephrase the above to something along the lines: "When the congestion window of a TCP sender has a size of one segment and a TCP ACK with an ECN signal (ECE flag) arrives at the TCP sender, the TCP sender resets the retransmit timer, and the sender will only be able to send a new packet when the retransmit timer expires. Effectively, the TCP sender reduces at that moment its sending rate from 1 segment per Round Trip Time (RTT) to 1 segment per RTO and reduces the sending rate further on each ECN signal received in subsequent TCP ACKs. Otherwise, if an ECN signal is not present in a subsequent TCP ACK the TCP sender resumes the normal ack-clocked transmission of segments [RFC 3168]. It might be also good to rearrange the text in the second and third paragraphs to disscuss the effect of retrasmission and timeouts more coherently. I may suggest text for this. Sec 4.2. "This section discusses TCP stacks that focus on transferring a single MSS." Maybe better: "This section discusses TCP stacks that allow transferring only a single MSS at a time." Sec 4.2.1. Last sentence: "For this use of CoAP, a maximum TCP window of one MSS will be sufficient." This is not necessarily true. If both TCP stacks involved allow a TCP window larger than 1 MSS and a CoAP request or response larger than one MSS is in use, it can be delivered more efficiently than in case where max TCP window is one MSS. Furthermore, this may also not be the case if a CoAP over TCP application uses short-lived TCP connections. Why? Because then the mandatory CSM message that each CoAP endpoint sends after the 3WHS may introduce an additional RTT as it cannot necessarily be sent during the same RTT with the first CoAP request/response. Of course, if the CSM message and the first CoAP request/response message fit into a single MSS and the TCP Nagle algorithm is disabled, such a single MSS window does not result in an additional RTT. Sec. 4.2.2. "A TCP implementation for a constrained device that uses a single-MSS TCP receive or transmit window size may not benefit from supporting the following TCP options: Window scale [RFC7323], TCP Timestamps [RFC7323], Selective Acknowledgments (SACK) and SACK-Permitted [RFC2018]." It may be useful to mention that a TCP sender can benefit from Timestamps in detecting spurious RTOs that are quite likely to occur in CNN scenarios. Sec. 4.2.3. 2nd para: "A device that advertises a single-MSS receive window should avoid use of Delayed ACKs in order to avoid contributing unnecessary delay (of up to 500 ms) to the RTT [RFC5681], which limits the throughput and can increase the data delivery time." This should not appear as a generic recommendation as it is not correct for some typical usage scenarios such as request-response traffic where the node with a single-MSS receive window is the server sending the responses. With delayed ACKs it can biggyback the TCP ACK with the response if the response is sent before the delayed ACK timer expires, thus avoiding unnecessary pure TCP ACKs. So, here, like in Sec 4.3.2., it is important to indicate that it depends on the communication pattern whether delayed ACKs are useful or harmful. 3rd para: "A device that can send at most one MSS of data is significantly affected if the receiver uses Delayed ACKs, e.g., if a TCP server or receiver is outside the CNN." Again, this does not hold in all cases. E.g., if the server is outside of the CNN and request-response communication is used. The "split hack" is not advisable workaround. First for the reason stated in the end of the para, but more importantly because it simply does not necessarily even work; a TCP receiver is requited to acknowledge every second full-sized segment, but not two consecutive small segments. 4th para: "Similar issues happen when a sender uses the Nagle algorithm. Disabling the algorithm will not have impact if the sender can only handle stop-and-wait operation." Actually it does have an impact in some specific usage scenarios, e.g., with CoAP over TCP disabling the Nagle algorithm allows sending the mandatory CSM message and the first CoAP msg (request) and possibly also CSM and the first response without unnecessarily waiting for a TCP ACK of the CSM msg. This is of particular impact if short-lived TCP connections are in use with CoAP over TCP. Sec. 4.2.4. RTO is not estimated but calculated using estimated RTT and deviation from it. That is, modify: RTO estimation -> RTO calculation 2nd para: "[RFC6298] describes the standard TCP RTO algorithm." You may delete this sentence and cite RFC 6298 in the first sentence of the Sec 4.2.4 where the algorithm is first mentioned. 3rd para: "As an example, an adaptive RTO algorithm for CoAP over UDP has been defined [I-D.ietf-core-cocoa] that has been found to perform well in CNN scenarios [Commag]." Maybe not a good idea to cite the current version of CoCoA RTO algorithm (v3) that have been found also to have detrimental behavior? Sec. 4.3.1. "Assuming that Delayed ACKs are used by the receiver, the mentioned algorithms work efficiently for window sizes of at least 5 MSS: If in a given TCP transmission of segments 1, 2, 3, 4, 5, and 6 the segment 2 gets lost, the sender should get an ACK for segment 1 when 3 arrives and duplicate acknowledgements when 4, 5, and 6 arrive. It will retransmit segment 2 when the third duplicate ACK arrives. In order to have segment 2, 3, 4, 5, and 6 sent, the window has to be at least 5 MSS. With an MSS of 1220 byte, a buffer of the size of 5 MSS would require 6100 bytes." The requirement for the window size to be of at least 5 segments does not hold if Limited Transmit is in use. Also, the requirement of at least 5 segments is valid only if the ACK for the segment 1 was held by the DelAck timer, i.e., the requirement holds approx. with 50% probability. That is, if the segment 1 got acknowledged (because there was also a segment before segment 1 and that was held by DelAck timer), only a window size of 4 MSS is needed. "For bulk data transfers further TCP improvements may also be useful, such as limited transmit [RFC3042]. Limited Transmit is not useful only for bulk data transfers but for any transfer that has more than one segment in flight. Small transfers tend to benefit more, because they are more likely to not receive enough dupacks. Sec. 4.3.1.1. "... a sender (having previously sent the SACK-Permitted option) can avoid performing unnecessary retransmissions, saving energy and bandwidth, as well as reducing latency." It might be worth mentioning also that SACK often allows for faster loss recovery when there is more than one lost segment in a window of data (i.e., recovery with less RTTs). Sec. 4.3.2. Disabling delayed ACKs on a client for infrequent request-response traffic with small messages might be advisable, too. It would allow an immediate ACK for the data segment carrying the response. This comment holds for Sec. 4.2.3 as well. Sec. 5.3. "A mean TCP NAT binding timeout of 386 minutes has been reported, while in some cases, inactivity timeouts are in the order of a few minutes [HomeGateway]. Reporting just the mean TCP NAT binding timeout from [HomeGateway] does not give a correct view of the results in this study, because the meaasured timeouts were highly variable and some devices had a very long timeout (or no timeout at all), yielding a very high mean timeout value. Therefore, we reported median and it would be more descriptive to report it here as well. The median of the measured TCP NAT binding timeouts in this study was around 60 mins, the shortest being around 2 mins. That is, clearly more than 50% of the devices had timeout shorter than RFC 5382 recommended minimum of 124 mins. In the light of these results, it may be hard to find a proper timeout value for the application-layer heartbeat messages, and it might be worth mentioning, I think. Nits: Sec 1: 1st para: Add references and cite 6LoWPAN, RPL, and CoAP. 3rd para: "At the application layer, CoAP was developed over UDP [RFC7252]." - this seems to cite UDP incorrectly while the intent is to cite CoAP. If you cite CoAP in the first para, you do not need to cite here at all. "This the main reason..." -> "This is the main reason..." 5th para: "Given the limited resources on constrained devices, careful "tuning" of the TCP implementation can make an implementation more lightweight." Instead of saying "tuning" of the TCP implementation, I'd say that careful selection of optional TCP features can make an implementation more lightweight (and improve operation in CNNs). 6th para: "This document provides guidance on how to implement and use TCP in CNNs. -> "This document provides guidance on how to implement and configure TCP as well as how TCP is advisable to be used by applications in CNNs. Sec 3.1., last para: high bit error rate -> high bit-error rate Sec 5., first sentence: "how a TCP stack can be used" -> "how TCP can be used" From nobody Thu May 2 10:25:49 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE2120499 for ; Thu, 2 May 2019 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 HwEiMbyJz_4K for ; Thu, 2 May 2019 10:25:46 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 04125120485 for ; Thu, 2 May 2019 10:25:45 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id p21so3953894wmc.0 for ; Thu, 02 May 2019 10:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uYZFZhj9XXITRJrXQuV3Zi3AJ6Vs2jgIvOMTDVJVE4g=; b=YCzfb2Xpx+ZYaYeMiiiPETU9OyIKjCFrF5icuuMd2CgXuZrMW+jzz6ZjMf282wDQmU CS/GiJRgL4sszeqRlPLUodGKoBt6zVfKW+4WpsOwlpcJ5tWxCFFxNO/VVPio2hZpKoqt OXO6vNGfxv0Z6Ow8aThE/cWL7M6P2xmHNJGmEpBJF3ITalNZl4VhLVfE0CKdzJAyg4XS orrCN1d7aP+3aWNsHXjV0LNXqVqMz8kYf0sx3OTZqwFk0qO8Q1nFBfm1e+E0WMiWHVA0 jkkzlFog4whqnsFewpmqqSwMfUcIBDuHvye7r+T4qj7t0ayJ12HaIpB2Jd3Xz9Id/Q8T oY4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uYZFZhj9XXITRJrXQuV3Zi3AJ6Vs2jgIvOMTDVJVE4g=; b=K3YHo/jyLOG2L346/tOmcnEh8ayjX4xmXhvzAki78B+gfLGG4jDlkePtWmfd71jTSa rPClVUvaubD2FzapW5oxeAWOBWKcLw5aov9NavX0itMgxz25XWfr/XDWwqsZhVErlJGZ SYFWyjzn7FfjsOdMqZILUjwjJmfIB1AWFpjLriZF91quNI7f+E9DXRIDPJu9kESyvB4A fRLouRjAwrwbVeJP9WSFUDJd2kCfbcWjs4QodUkK9SLFFfbiimf/PcucyZcwSciuYRgc 1Kv644A2tuQ1r00KhTdLaQpKn5/GHroTwVfAhFeNXor6aeULCZaNt86zMq/q9QaC8OCv JHCw== X-Gm-Message-State: APjAAAUIDJ9Kgn2rM/GdWZKS8PyxXw614jPR57sMM6lauU2RUmCjG6Q7 hTNqRGNL8UjbyX6quiqkX2Eeh/z0DMmlHjSqgt7IEX1lrcQ= X-Google-Smtp-Source: APXvYqxgVI2PsAY/stjirS5a71rsyLRVZci4EL9yVF9sTV21XO7Pj95x1cqQdtcBUwtQeHdyVTgk2OZzgTaponkIJ7w= X-Received: by 2002:a7b:cb04:: with SMTP id u4mr3217140wmj.0.1556817943850; Thu, 02 May 2019 10:25:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Thu, 2 May 2019 10:25:07 -0700 Message-ID: To: Matt Olson Cc: Yi Huang , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 17:25:48 -0000 On Thu, May 2, 2019 at 10:09 AM Matt Olson wrote: > > Also, section 6.5.1 Step 1 is presented as a complete set of conditions f= or scheduling a PTO, but it is missing a bullet point for TLPRxtOut. Thanks for checking: but checking TLPRxtOut is not necessary and is not preferred when scheduling a probe -- the goal is to prevent more than one probe inflight, so checking right before TLPRxtOut sending the nex= t one allows the best coverage of application-limited writes (burst-idle-burst-..= .). > > -----Original Message----- > From: Yuchung Cheng > Sent: Wednesday, May 1, 2019 11:33 PM > To: Yi Huang > Cc: tcpm@ietf.org; Matt Olson > Subject: Re: [tcpm] Questions about TLP > > On Wed, May 1, 2019 at 10:48 PM Yi Huang wrote: > > > > Hi RACK/TLP authors, > > > > > > > > I have the following questions (page numbers refer to draft-ietf-tcpm-r= ack-05): > > > > > > > > 1.In page 16, it says =E2=80=9CFinally, if the time at which an RTO wou= ld fire (here denoted "TCP_RTO_expire") is sooner than the computed time fo= r the PTO, then a probe is scheduled to be sent at that earlier time.=E2=80= =9D What does this TCP_RTO_expire actually mean? Does it mean there is anot= her RTO timer (possibly started some time in the past) running along with P= TO or just RTT + 4*RTTVar + Now()? Also, why would another probe be sent at= RTO expiration time instead of treating it like RTO and collapsing the cwn= d? > > TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > SRTT + 4*RTTVAR + Now() > We use TCP_RTO_expire() because many implementations including Linux do n= ot use the exact RFC formula > > The reason it's not treated as a regular RTO is to avoid resetting conges= tion window to 1. The rationale is if the probe was sent within min(PTO, RT= O) and was delivered successfully, there's no need to reset congestion wind= ow and re-start slow-start, similar to the rationale of Reno's fast recover= y reducing window to ssthresh instead of 1. We have found this strategy ben= efits wireless connections, as the chance of spurious RTO is high due to th= e delay variation. > > > > > > > > > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it is= stated that TLPRxtOut is used to guarantee that there is only one outstand= ing TLP retransmission.. However, it is not clear to me when TLPRxtOut shou= ld be really used. Should it be used in 6.5.1 Step. 1 (checking whether we = should and can schedule a TLP) or in TLP_send_probe()? > > This is in > > 6.6.2. Recording loss probe states > > Senders MUST only send a TLP loss probe retransmission if TLPRxtOut > is false. This ensures that at any given time a connection has at > most one outstanding TLP retransmission. This allows the sender to > > but I agree it'd be more clear to include this in TLP_send_probe() pseudo= code. I'd incorporate in the next rev. > > > > > > > > Thanks, > > > > > > > > Yi > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D01%7C01%7Cmaolson%40mic= r > > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2d7 > > cd011db47%7C1&sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2iy3OBAno%3= D > > &reserved=3D0 From nobody Thu May 2 11:47:29 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90596120485 for ; Thu, 2 May 2019 11:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 whPdd6_OrTI2 for ; Thu, 2 May 2019 11:47:23 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790124.outbound.protection.outlook.com [40.107.79.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1D0120604 for ; Thu, 2 May 2019 11:47:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=TBeBWDSWVCsYBYkhddDsgnR/iArUcousGQT5K8mA2Sf+ha2vtIPfhH2ttMGLqyE4rZu9kreDFbigZ9mXUe3VsAN0CmtBK6D3XIi980eVAAFM/dm1klbh+sOmSXTI6uo9bgCg1wETsxDNkuGrI2EVSKZbds5XaG0SHHvuuw8PFGo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=suqFg/FR/ThkxHfSvPfCnjor7QQ6wdD1Tde4+6rRM9E=; b=vRENnWv2/yPrFWuzlsndYdjM2Zu5y5+qJiWyd5QmFR3Tb1xZbBkjJ78ARvyH05IPEQEZvICMFU+lfY9kXSN40RWbApduyxQ10nCXFfXCBHD83SCxvWZ407UillIXOoHRNnlC8KRtN9/dfWdk6p2+SMqto+Yi6HusrMOu4ZKHpZY= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=suqFg/FR/ThkxHfSvPfCnjor7QQ6wdD1Tde4+6rRM9E=; b=O/5xnJZ63RPLzgFehfaIiZKq7GnbdOP0lOE7a5yjWFbI27xcVpgrPlhZKtx+AG3mIifeH2MiC7AhRc5E1qR5gmUklSpVugvGFypA6nFwnYm/QaanQC6JCTOQQLq7iPgdQCWi0zP90U44T9StOTi15ak/kIE/Cv3VAbxKBc2i1mE= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1124.namprd21.prod.outlook.com (52.132.20.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.2; Thu, 2 May 2019 18:47:04 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::ccc6:ba71:d72f:a8c9%8]) with mapi id 15.20.1856.004; Thu, 2 May 2019 18:47:04 +0000 From: Yi Huang To: Yuchung Cheng , Matt Olson CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Questions about TLP Thread-Index: AdUAqnPmaX0KgH/WQE+MIFBj5gEdQgABnF8AABYYoqAAAK0mgAACL/RQ Date: Thu, 2 May 2019 18:47:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-02T18:47:03.0820021Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=70b6eb19-bd8c-4f57-b6e6-9705ec7f7fc2; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:1:30c4:3613:61af:58ac] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a9e9326-a911-49ff-7fdb-08d6cf2e9228 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1124; x-ms-traffictypediagnostic: BL0PR2101MB1124: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(396003)(39860400002)(346002)(13464003)(189003)(199004)(55016002)(71190400001)(71200400001)(5660300002)(1511001)(52536014)(2906002)(8936002)(8676002)(81156014)(81166006)(66446008)(76116006)(73956011)(66476007)(66946007)(66556008)(64756008)(14444005)(256004)(8990500004)(6116002)(68736007)(6306002)(74316002)(9686003)(10090500001)(6246003)(4326008)(53936002)(102836004)(53546011)(6506007)(186003)(476003)(11346002)(446003)(46003)(966005)(76176011)(99286004)(7696005)(10290500003)(478600001)(22452003)(316002)(25786009)(7736002)(14454004)(110136005)(486006)(305945005)(86612001)(6436002)(229853002)(86362001)(6636002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1124; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QnXhCO8sn68tuskhhMtn50n4aTb4lHTFAe26MXhpOLIM+FeiPo3RYol6ln00spZuU7TQ7xytDu8wyhh4+LbdBPSoiCwNWEx+71ndRFEdl/pGVrjVoIJZYvjKh/872JGM+xa7fckS+0MhGzWH8BiCV5jJuUOeZctEKNByzN4uj2oJuBspAETFvD/hRtf/Aa07g4FxODeuAbiqTWRvAjiYvQOdgRRGJ8F38Me+KLJKocRdOGGTDrhjL/rS/ATbh/O/8G9pDjKlUziEybO8hcgEKs1ErbxC/0B9V7XnKOU5bWvaNahDxoj7oBAQM5s//8mVtHDl9Qb70G3MHIyCWwVxD5N2xfBZMhziXoSWPzX5oz+Kv0NrqtqwyYI/GaQ8WrEr7qYcA4RI9GYKNyI/k1UsUuWpWcyA2LKifgWBOTtQlkk= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a9e9326-a911-49ff-7fdb-08d6cf2e9228 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 18:47:04.4698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1124 Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 18:47:28 -0000 SWYgVExQUnh0T3V0IGlzIGNoZWNrZWQgaW4gVExQX3NlbmRfcHJvYmUoKSwgYSBuZXcgUFRPIGNh biBjYW5jZWwgYW4gYWxyZWFkeSBydW5uaW5nIFJUTyB0aW1lciBhcm1lZCBieSBzZW5kaW5nIFRM UCBwcmV2aW91c2x5LiBJZiBUTFBfc2VuZF9wcm9iZSgpIGRlY2lkZXMgbm90IHRvIHNlbmQgdGhl IHByb2JlIGZvciB0aGUgbmV3IFBUTywgd2hhdCBzaG91bGQgdGhlIHNlbmRlciBkbyBuZXh0PyBS ZWFybSBSVE8gb3IgdHJlYXQgaXQgYXMgUlRPIHRpbWVvdXQ/IFRoZSBkcmFmdCBzdGF0ZXMgd2Ug bXVzdCBhcm0gYW4gUlRPIGFmdGVyIHRyYW5zbWl0dGluZyBUTFAgYnV0IGluIHRoaXMgY2FzZSwg bm8gcHJvYmUgd2lsbCBiZSBzZW50Lg0KDQpBbHNvLCBpbiBwYWdlIDE3LCB0aGUgZHJhZnQgc2F5 cyAiVGhpcyBpcyBpbXBvcnRhbnQgdG8gYXZvaWQgVExQIGxvb3BzIGlmIGFuIGFwcGxpY2F0aW9u IHdyaXRlcyBwZXJpb2RpY2FsbHkgYXQgYW4gaW50ZXJ2YWwgbGVzcyB0aGFuIFBUTy4iIGJ1dCBp ZiB0aGUgYXBwIHdyaXRlcyBwZXJpb2RpY2FsbHkgYXQgYW4gaW50ZXJ2YWwgbGVzcyB0aGFuIFBU TywgUFRPIHdpbGwganVzdCBiZSBwdXNoZWQgb3V0IGFuZCBub3QgZmlyZSB1bnRpbCB0aGUgc2Vu ZGVyIGNhbm5vdCBzZW5kIGFueXRoaW5nIGR1ZSB0byB3aW5kb3cgbGltaXQuIFRoZW4gaW4gdGhp cyBjYXNlLCBUTFAgbG9vcHMgZG8gbm90IHNlZW0gdG8gZXhpc3QgaWYgVExQIGxvb3BzIG1lYW5z IGJhY2stdG8tYmFjayBUTFAgcHJvYmVzLiBBbSBJIG1pc3NpbmcgYW55dGhpbmcgaGVyZT8NCg0K VGhhbmtzLA0KDQpZaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWXVjaHVu ZyBDaGVuZyA8eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4gDQpTZW50OiBUaHVy c2RheSwgTWF5IDIsIDIwMTkgMTA6MjUgQU0NClRvOiBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jv c29mdC5jb20+DQpDYzogWWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPjsgdGNwbUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQgVExQDQoNCk9uIFRodSwg TWF5IDIsIDIwMTkgYXQgMTA6MDkgQU0gTWF0dCBPbHNvbiA8bWFvbHNvbkBtaWNyb3NvZnQuY29t PiB3cm90ZToNCj4NCj4gQWxzbywgc2VjdGlvbiA2LjUuMSBTdGVwIDEgaXMgcHJlc2VudGVkIGFz IGEgY29tcGxldGUgc2V0IG9mIGNvbmRpdGlvbnMgZm9yIHNjaGVkdWxpbmcgYSBQVE8sIGJ1dCBp dCBpcyBtaXNzaW5nIGEgYnVsbGV0IHBvaW50IGZvciBUTFBSeHRPdXQuDQpUaGFua3MgZm9yIGNo ZWNraW5nOiBidXQgY2hlY2tpbmcgVExQUnh0T3V0IGlzIG5vdCBuZWNlc3NhcnkgYW5kIGlzIG5v dCBwcmVmZXJyZWQgd2hlbiBzY2hlZHVsaW5nIGEgcHJvYmUgLS0gdGhlIGdvYWwgaXMgdG8gcHJl dmVudCBtb3JlIHRoYW4gb25lIHByb2JlIGluZmxpZ2h0LCBzbyBjaGVja2luZyByaWdodCBiZWZv cmUgVExQUnh0T3V0IHNlbmRpbmcgdGhlIG5leHQgb25lIGFsbG93cyB0aGUgYmVzdCBjb3ZlcmFn ZSBvZiBhcHBsaWNhdGlvbi1saW1pdGVkIHdyaXRlcyAoYnVyc3QtaWRsZS1idXJzdC0uLi4uKS4N Cg0KDQoNCg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZdWNodW5n IENoZW5nIDx5Y2hlbmdAZ29vZ2xlLmNvbT4NCj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMSwgMjAx OSAxMTozMyBQTQ0KPiBUbzogWWkgSHVhbmcgPGh1YW55aT00MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc+DQo+IENjOiB0Y3BtQGlldGYub3JnOyBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jv c29mdC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gUXVlc3Rpb25zIGFib3V0IFRMUA0KPg0K PiBPbiBXZWQsIE1heSAxLCAyMDE5IGF0IDEwOjQ4IFBNIFlpIEh1YW5nIDxodWFueWk9NDBtaWNy b3NvZnQuY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPg0KPiA+IEhpIFJBQ0svVExQIGF1 dGhvcnMsDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25z IChwYWdlIG51bWJlcnMgcmVmZXIgdG8gZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDUpOg0KPiA+DQo+ ID4NCj4gPg0KPiA+IDEuSW4gcGFnZSAxNiwgaXQgc2F5cyDigJxGaW5hbGx5LCBpZiB0aGUgdGlt ZSBhdCB3aGljaCBhbiBSVE8gd291bGQgZmlyZSAoaGVyZSBkZW5vdGVkICJUQ1BfUlRPX2V4cGly ZSIpIGlzIHNvb25lciB0aGFuIHRoZSBjb21wdXRlZCB0aW1lIGZvciB0aGUgUFRPLCB0aGVuIGEg cHJvYmUgaXMgc2NoZWR1bGVkIHRvIGJlIHNlbnQgYXQgdGhhdCBlYXJsaWVyIHRpbWUu4oCdIFdo YXQgZG9lcyB0aGlzIFRDUF9SVE9fZXhwaXJlIGFjdHVhbGx5IG1lYW4/IERvZXMgaXQgbWVhbiB0 aGVyZSBpcyBhbm90aGVyIFJUTyB0aW1lciAocG9zc2libHkgc3RhcnRlZCBzb21lIHRpbWUgaW4g dGhlIHBhc3QpIHJ1bm5pbmcgYWxvbmcgd2l0aCBQVE8gb3IganVzdCBSVFQgKyA0KlJUVFZhciAr IE5vdygpPyBBbHNvLCB3aHkgd291bGQgYW5vdGhlciBwcm9iZSBiZSBzZW50IGF0IFJUTyBleHBp cmF0aW9uIHRpbWUgaW5zdGVhZCBvZiB0cmVhdGluZyBpdCBsaWtlIFJUTyBhbmQgY29sbGFwc2lu ZyB0aGUgY3duZD8NCj4NCj4gVENQX1JUT19leHBpcmUoKSBzaG91bGQgcmV0dXJuIGEgdGltZW91 dCB2YWx1ZSBmb3IgcmVndWxhciBSVE8sIGkuZS4NCj4gU1JUVCArIDQqUlRUVkFSICsgTm93KCkN Cj4gV2UgdXNlIFRDUF9SVE9fZXhwaXJlKCkgYmVjYXVzZSBtYW55IGltcGxlbWVudGF0aW9ucyBp bmNsdWRpbmcgTGludXggDQo+IGRvIG5vdCB1c2UgdGhlIGV4YWN0IFJGQyBmb3JtdWxhDQo+DQo+ IFRoZSByZWFzb24gaXQncyBub3QgdHJlYXRlZCBhcyBhIHJlZ3VsYXIgUlRPIGlzIHRvIGF2b2lk IHJlc2V0dGluZyBjb25nZXN0aW9uIHdpbmRvdyB0byAxLiBUaGUgcmF0aW9uYWxlIGlzIGlmIHRo ZSBwcm9iZSB3YXMgc2VudCB3aXRoaW4gbWluKFBUTywgUlRPKSBhbmQgd2FzIGRlbGl2ZXJlZCBz dWNjZXNzZnVsbHksIHRoZXJlJ3Mgbm8gbmVlZCB0byByZXNldCBjb25nZXN0aW9uIHdpbmRvdyBh bmQgcmUtc3RhcnQgc2xvdy1zdGFydCwgc2ltaWxhciB0byB0aGUgcmF0aW9uYWxlIG9mIFJlbm8n cyBmYXN0IHJlY292ZXJ5IHJlZHVjaW5nIHdpbmRvdyB0byBzc3RocmVzaCBpbnN0ZWFkIG9mIDEu IFdlIGhhdmUgZm91bmQgdGhpcyBzdHJhdGVneSBiZW5lZml0cyB3aXJlbGVzcyBjb25uZWN0aW9u cywgYXMgdGhlIGNoYW5jZSBvZiBzcHVyaW91cyBSVE8gaXMgaGlnaCBkdWUgdG8gdGhlIGRlbGF5 IHZhcmlhdGlvbi4NCj4NCj4gPg0KPiA+DQo+ID4NCj4gPiAyLkluIHBhZ2UgMTggc2VjdGlvbiA2 LjYsIGEgbmV3IHZhcmlhYmxlIFRMUFJ4dE91dCBpcyBkZWZpbmVkIGFuZCBpdCBpcyBzdGF0ZWQg dGhhdCBUTFBSeHRPdXQgaXMgdXNlZCB0byBndWFyYW50ZWUgdGhhdCB0aGVyZSBpcyBvbmx5IG9u ZSBvdXRzdGFuZGluZyBUTFAgcmV0cmFuc21pc3Npb24uLiBIb3dldmVyLCBpdCBpcyBub3QgY2xl YXIgdG8gbWUgd2hlbiBUTFBSeHRPdXQgc2hvdWxkIGJlIHJlYWxseSB1c2VkLiBTaG91bGQgaXQg YmUgdXNlZCBpbiA2LjUuMSBTdGVwLiAxIChjaGVja2luZyB3aGV0aGVyIHdlIHNob3VsZCBhbmQg Y2FuIHNjaGVkdWxlIGEgVExQKSBvciBpbiBUTFBfc2VuZF9wcm9iZSgpPw0KPg0KPiBUaGlzIGlz IGluDQo+DQo+IDYuNi4yLiAgUmVjb3JkaW5nIGxvc3MgcHJvYmUgc3RhdGVzDQo+DQo+ICAgIFNl bmRlcnMgTVVTVCBvbmx5IHNlbmQgYSBUTFAgbG9zcyBwcm9iZSByZXRyYW5zbWlzc2lvbiBpZiBU TFBSeHRPdXQNCj4gICAgaXMgZmFsc2UuICBUaGlzIGVuc3VyZXMgdGhhdCBhdCBhbnkgZ2l2ZW4g dGltZSBhIGNvbm5lY3Rpb24gaGFzIGF0DQo+ICAgIG1vc3Qgb25lIG91dHN0YW5kaW5nIFRMUCBy ZXRyYW5zbWlzc2lvbi4gIFRoaXMgYWxsb3dzIHRoZSBzZW5kZXIgdG8NCj4NCj4gYnV0IEkgYWdy ZWUgaXQnZCBiZSBtb3JlIGNsZWFyIHRvIGluY2x1ZGUgdGhpcyBpbiBUTFBfc2VuZF9wcm9iZSgp IHBzZXVkbyBjb2RlLiBJJ2QgaW5jb3Jwb3JhdGUgaW4gdGhlIG5leHQgcmV2Lg0KPiA+DQo+ID4N Cj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+DQo+ID4NCj4gPiBZaQ0KPiA+DQo+ID4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g dGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Li4N Cj4gPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDElN0Mw MSU3Q21hb2xzb24lNDBtaQ0KPiA+IGNyDQo+ID4gb3NvZnQuY29tJTdDNjZkYjQ0NjcyZTNkNDEw MWQ3MjkwOGQ2Y2VjODIwMDElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjINCj4gPiBkNyANCj4gPiBj ZDAxMWRiNDclN0MxJmFtcDtzZGF0YT1uOHJwNUVtb3dtNDU5aVNLb2xoSVAxaEZYQnM4cFpqc0dH Mml5M09CQW5vJQ0KPiA+IDNEDQo+ID4gJmFtcDtyZXNlcnZlZD0wDQo= From nobody Fri May 3 09:25:42 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCF3120483 for ; Thu, 2 May 2019 10:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 jooRZqoAGL00 for ; Thu, 2 May 2019 10:09:29 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740130.outbound.protection.outlook.com [40.107.74.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A59812011A for ; Thu, 2 May 2019 10:09:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=CjfagCXy4m0evmLOO4ysmXaCyF5k3MhKgy2D/QhgOrV3aUANvQTasRhPxOnXoUT/nUZntdx4Kr8q5UXw5Wh7Im2zJtpmhjr9awt2MH169k1t2ndjNt+J/bh7HpLutUmVQ8bsxPdtVuVFInVv6KfTQWei3Hck60xOuS8LFBLj5ag= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fVp4GDfPZFwQsREWXHAWct8M0bC9t0wHaeEYLHA5Gsg=; b=UDvptyo2tA21w+x+M+3R2HHipo48XeGMlSB3fSJNIe9l8rI0LL8o0tgAijyBVNnPbHNP3xMo9i+TXe6sfAb5INRlw9/DtnBZ5RLlEWHrxB5U5k63/jq1M3LpLpOJj0f9V/LNYXEUhKO1YwH5C0eGg9saFV5V6pCnHg1ea+XkuX0= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none action=none header.from=microsoft.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fVp4GDfPZFwQsREWXHAWct8M0bC9t0wHaeEYLHA5Gsg=; b=Js7EW21pj7XCeA0H7Xv2IrRk3ZM1oML0g0HQw2N3Q7Pp7mgfbFRh1cchi5mQ/VoclfirZCDOrcA4mGAhWKQS6mHPmm33+Z4if/vm9N4HIrihemDZ4+IGs9+yIbtabnbCM3T4pwztlzzbZKbNRfeOJuBYuV9tM/gIVqH3RUPLrTw= Received: from BYAPR21MB1256.namprd21.prod.outlook.com (20.179.57.160) by BYAPR21MB1238.namprd21.prod.outlook.com (20.179.57.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.2; Thu, 2 May 2019 17:09:26 +0000 Received: from BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d]) by BYAPR21MB1256.namprd21.prod.outlook.com ([fe80::a4a4:9084:90b3:f89d%10]) with mapi id 15.20.1878.004; Thu, 2 May 2019 17:09:26 +0000 From: Matt Olson To: Yuchung Cheng , Yi Huang CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Questions about TLP Thread-Index: AdUAqnPmaX0KgH/WQE+MIFBj5gEdQgABnF8AABYYoqA= Date: Thu, 2 May 2019 17:09:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=maolson@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-02T17:09:25.6118818Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=172a29e5-7622-4a7f-985e-d067a4be7cd0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=maolson@microsoft.com; x-originating-ip: [2001:4898:80e8:3:421e:6a9d:cc27:641c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf7b20ce-0b90-4698-5b99-08d6cf20eeaa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR21MB1238; x-ms-traffictypediagnostic: BYAPR21MB1238: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0025434D2D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(376002)(136003)(396003)(13464003)(199004)(189003)(446003)(74316002)(99286004)(229853002)(66556008)(6506007)(86612001)(6116002)(86362001)(76176011)(53546011)(8990500004)(102836004)(10290500003)(478600001)(10090500001)(7696005)(966005)(52536014)(5660300002)(110136005)(316002)(33656002)(8676002)(71200400001)(14454004)(186003)(22452003)(7736002)(256004)(76116006)(53936002)(2906002)(68736007)(66476007)(73956011)(81156014)(6306002)(55016002)(81166006)(14444005)(305945005)(46003)(486006)(6436002)(25786009)(11346002)(476003)(4326008)(66446008)(8936002)(6246003)(64756008)(66946007)(71190400001)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR21MB1238; H:BYAPR21MB1256.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6XGkfawfW8AJGyGTMgL49a0K3vQ/VvRxwiU+s+27lsxtHciGL/dOhNfPnWQOOS5/qvhpIzp+MNk4BBg6CX0G8e1DGWCpJJ8b9UEREEFh/9EgEENlSoyy4jhQkgrFiuMp2MLjNfvZVdMLbr1fhHdesUjxyUXzqq1T3GCxWIp6xQJ42JUDFMJGIw59x1Tld4dAsvGnHbmjeek7fIWhDbKfGeKI1hzn9+Qk9LBKkLfT/NJI+mH5GGHVcncy90o2msXtFrT84I5OuFuQ+zWPoCHPcaI/vA64HV9L91ZrZXCo8jc5MhFp3EI85JuM/XqSQL/Xwqdo396ef++WKkRADNfxN6sq6abP0iFg6u1cmG8XUgHFlLODrVLaALNdWgclykYYXvPEOF2WJPjNB7cKFrl2hglJW3Y/zCq6fIYw14/WLV4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: cf7b20ce-0b90-4698-5b99-08d6cf20eeaa X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 17:09:26.8329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR21MB1238 Archived-At: X-Mailman-Approved-At: Fri, 03 May 2019 09:25:41 -0700 Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 17:09:32 -0000 QWxzbywgc2VjdGlvbiA2LjUuMSBTdGVwIDEgaXMgcHJlc2VudGVkIGFzIGEgY29tcGxldGUgc2V0 IG9mIGNvbmRpdGlvbnMgZm9yIHNjaGVkdWxpbmcgYSBQVE8sIGJ1dCBpdCBpcyBtaXNzaW5nIGEg YnVsbGV0IHBvaW50IGZvciBUTFBSeHRPdXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29vZ2xlLmNvbT4gDQpTZW50OiBXZWRuZXNk YXksIE1heSAxLCAyMDE5IDExOjMzIFBNDQpUbzogWWkgSHVhbmcgPGh1YW55aT00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogdGNwbUBpZXRmLm9yZzsgTWF0dCBPbHNvbiA8bWFv bHNvbkBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQg VExQDQoNCk9uIFdlZCwgTWF5IDEsIDIwMTkgYXQgMTA6NDggUE0gWWkgSHVhbmcgPGh1YW55aT00 MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPg0KPiBIaSBSQUNLL1RMUCBh dXRob3JzLA0KPg0KPg0KPg0KPiBJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgKHBhZ2Ug bnVtYmVycyByZWZlciB0byBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNSk6DQo+DQo+DQo+DQo+IDEu SW4gcGFnZSAxNiwgaXQgc2F5cyDigJxGaW5hbGx5LCBpZiB0aGUgdGltZSBhdCB3aGljaCBhbiBS VE8gd291bGQgZmlyZSAoaGVyZSBkZW5vdGVkICJUQ1BfUlRPX2V4cGlyZSIpIGlzIHNvb25lciB0 aGFuIHRoZSBjb21wdXRlZCB0aW1lIGZvciB0aGUgUFRPLCB0aGVuIGEgcHJvYmUgaXMgc2NoZWR1 bGVkIHRvIGJlIHNlbnQgYXQgdGhhdCBlYXJsaWVyIHRpbWUu4oCdIFdoYXQgZG9lcyB0aGlzIFRD UF9SVE9fZXhwaXJlIGFjdHVhbGx5IG1lYW4/IERvZXMgaXQgbWVhbiB0aGVyZSBpcyBhbm90aGVy IFJUTyB0aW1lciAocG9zc2libHkgc3RhcnRlZCBzb21lIHRpbWUgaW4gdGhlIHBhc3QpIHJ1bm5p bmcgYWxvbmcgd2l0aCBQVE8gb3IganVzdCBSVFQgKyA0KlJUVFZhciArIE5vdygpPyBBbHNvLCB3 aHkgd291bGQgYW5vdGhlciBwcm9iZSBiZSBzZW50IGF0IFJUTyBleHBpcmF0aW9uIHRpbWUgaW5z dGVhZCBvZiB0cmVhdGluZyBpdCBsaWtlIFJUTyBhbmQgY29sbGFwc2luZyB0aGUgY3duZD8NCg0K VENQX1JUT19leHBpcmUoKSBzaG91bGQgcmV0dXJuIGEgdGltZW91dCB2YWx1ZSBmb3IgcmVndWxh ciBSVE8sIGkuZS4NClNSVFQgKyA0KlJUVFZBUiArIE5vdygpDQpXZSB1c2UgVENQX1JUT19leHBp cmUoKSBiZWNhdXNlIG1hbnkgaW1wbGVtZW50YXRpb25zIGluY2x1ZGluZyBMaW51eCBkbyBub3Qg dXNlIHRoZSBleGFjdCBSRkMgZm9ybXVsYQ0KDQpUaGUgcmVhc29uIGl0J3Mgbm90IHRyZWF0ZWQg YXMgYSByZWd1bGFyIFJUTyBpcyB0byBhdm9pZCByZXNldHRpbmcgY29uZ2VzdGlvbiB3aW5kb3cg dG8gMS4gVGhlIHJhdGlvbmFsZSBpcyBpZiB0aGUgcHJvYmUgd2FzIHNlbnQgd2l0aGluIG1pbihQ VE8sIFJUTykgYW5kIHdhcyBkZWxpdmVyZWQgc3VjY2Vzc2Z1bGx5LCB0aGVyZSdzIG5vIG5lZWQg dG8gcmVzZXQgY29uZ2VzdGlvbiB3aW5kb3cgYW5kIHJlLXN0YXJ0IHNsb3ctc3RhcnQsIHNpbWls YXIgdG8gdGhlIHJhdGlvbmFsZSBvZiBSZW5vJ3MgZmFzdCByZWNvdmVyeSByZWR1Y2luZyB3aW5k b3cgdG8gc3N0aHJlc2ggaW5zdGVhZCBvZiAxLiBXZSBoYXZlIGZvdW5kIHRoaXMgc3RyYXRlZ3kg YmVuZWZpdHMgd2lyZWxlc3MgY29ubmVjdGlvbnMsIGFzIHRoZSBjaGFuY2Ugb2Ygc3B1cmlvdXMg UlRPIGlzIGhpZ2ggZHVlIHRvIHRoZSBkZWxheSB2YXJpYXRpb24uDQoNCj4NCj4NCj4NCj4gMi5J biBwYWdlIDE4IHNlY3Rpb24gNi42LCBhIG5ldyB2YXJpYWJsZSBUTFBSeHRPdXQgaXMgZGVmaW5l ZCBhbmQgaXQgaXMgc3RhdGVkIHRoYXQgVExQUnh0T3V0IGlzIHVzZWQgdG8gZ3VhcmFudGVlIHRo YXQgdGhlcmUgaXMgb25seSBvbmUgb3V0c3RhbmRpbmcgVExQIHJldHJhbnNtaXNzaW9uLi4gSG93 ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoZW4gVExQUnh0T3V0IHNob3VsZCBiZSByZWFs bHkgdXNlZC4gU2hvdWxkIGl0IGJlIHVzZWQgaW4gNi41LjEgU3RlcC4gMSAoY2hlY2tpbmcgd2hl dGhlciB3ZSBzaG91bGQgYW5kIGNhbiBzY2hlZHVsZSBhIFRMUCkgb3IgaW4gVExQX3NlbmRfcHJv YmUoKT8NCg0KVGhpcyBpcyBpbg0KDQo2LjYuMi4gIFJlY29yZGluZyBsb3NzIHByb2JlIHN0YXRl cw0KDQogICBTZW5kZXJzIE1VU1Qgb25seSBzZW5kIGEgVExQIGxvc3MgcHJvYmUgcmV0cmFuc21p c3Npb24gaWYgVExQUnh0T3V0DQogICBpcyBmYWxzZS4gIFRoaXMgZW5zdXJlcyB0aGF0IGF0IGFu eSBnaXZlbiB0aW1lIGEgY29ubmVjdGlvbiBoYXMgYXQNCiAgIG1vc3Qgb25lIG91dHN0YW5kaW5n IFRMUCByZXRyYW5zbWlzc2lvbi4gIFRoaXMgYWxsb3dzIHRoZSBzZW5kZXIgdG8NCg0KYnV0IEkg YWdyZWUgaXQnZCBiZSBtb3JlIGNsZWFyIHRvIGluY2x1ZGUgdGhpcyBpbiBUTFBfc2VuZF9wcm9i ZSgpIHBzZXVkbyBjb2RlLiBJJ2QgaW5jb3Jwb3JhdGUgaW4gdGhlIG5leHQgcmV2Lg0KPg0KPg0K Pg0KPiBUaGFua3MsDQo+DQo+DQo+DQo+IFlpDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRj cG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDElN0MwMSU3Q21hb2xzb24lNDBtaWNyDQo+IG9zb2Z0LmNv bSU3QzY2ZGI0NDY3MmUzZDQxMDFkNzI5MDhkNmNlYzgyMDAxJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDcNCj4gY2QwMTFkYjQ3JTdDMSZhbXA7c2RhdGE9bjhycDVFbW93bTQ1OWlTS29saElQMWhG WEJzOHBaanNHRzJpeTNPQkFubyUzRA0KPiAmYW1wO3Jlc2VydmVkPTANCg== From nobody Mon May 6 01:20:03 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DEA120049 for ; Mon, 6 May 2019 01:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 VKM5A-U6gOke for ; Mon, 6 May 2019 01:19:58 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC3D120033 for ; Mon, 6 May 2019 01:19:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E9CBD25A15; Mon, 6 May 2019 10:19:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1557130795; bh=L4xUBCIX9YGAGuPlgynKFqBefAzZt06g4Gvl8j/F9lQ=; h=From:To:Subject:Date:References:In-Reply-To:From; b=RlARGpoiAQXkn0lYTeDu9idIg3SE7l/BAgKrlUve+8PN4hbRRizIwN+Hl/07Tetvv 6A7IBW5U9NUFWMmvn28f50Dlztoumv51kfP7o0vigZNidKB0yAM1VOH8sW7Iqty9zN wXNQhkYhZaV1C3bKaCsfqUdDHE0/UDLnOoBBbszk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCgShhd91GnT; Mon, 6 May 2019 10:19:54 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 6 May 2019 10:19:54 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.34]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Mon, 6 May 2019 10:19:54 +0200 From: "Scharf, Michael" To: Yuchung Cheng , "tcpm@ietf.org Extensions" Thread-Topic: New Version Notification for draft-ietf-tcpm-rack-05.txt Thread-Index: AQHU/JqdhmF+Y1FrckqG+5/cgJ9tiqZdy/kA Date: Mon, 6 May 2019 08:19:53 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D2E45F5@rznt8114.rznt.rzdir.fht-esslingen.de> References: <155632918775.6767.10665022766872955742.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D2E45F5rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rack-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 08:20:01 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D2E45F5rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWXVjaHVuZywNCg0KQSBwdXJlbHkgZWRpdG9yaWFsIGNvbW1lbnQgb24gdGhlIG5ldyB0ZXh0 IGluIC0wNToNCg0KVGhlIGRlZmluaXRpb24gb2YgdGVybXMgaGFzIGJlZW4gdXBkYXRlZCBieSBS RkMgODE3NCBhbmQgdGhlIG5ldyBzdWdnZXN0ZWQgd29yZGluZyBpczoNCg0KICAgICAgVGhlIGtl eSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTA0K ICAgICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBS RUNPTU1FTkRFRCIsDQogICAgICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMNCiAgICAgIGRlc2NyaWJlZCBpbiBCQ1AgMTQgW1JG QzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5DQogICAgICBhcHBlYXIg aW4gYWxsIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLg0KDQpVbmxlc3MgdGhlcmUgYXJlIGdvb2Qg cmVhc29ucyB0byBkZXZpYXRlLCBJTUhPIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gdXNlIHRoZSBk ZWZhdWx0IHRleHQuDQoNCkFsc28sIG5vdGUgdGhhdCB0aGVyZSBpcyBzb21lIHVzZSBvZiBjYXBp dGFsIGxldHRlciB0ZXJtcyBiZWZvcmUgU2VjdGlvbiA1LiBUaGUgZGVmaW5pdGlvbiBzaG91bGQg cHJvYmFibHkgYmUgaW50cm9kdWNlZCBiZWZvcmUgdGhlIGZpcnN0IHVzZSAoaW4gdGhlIGJvZHkp Lg0KDQpGaW5hbGx5LCBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNSByZWZlcmVuY2VzIFJGQzIxMTkg dGhyZWUgdGltZXMsIHdoaWNoIG1heSBiZSBhIHRvb2xpbmcgYnVnLg0KDQpUaG9zZSBlZGl0b3Jp YWwgbml0cyBjYW4gYmUgZml4ZWQgbGF0ZXIgaW4gdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MsIGJ1 dCBhcyB0aGVzZSBhcmUgbG93IGhhbmdpbmcgZnJ1aXRzLCBJTUhPIGl0IHdvdWxkIG1ha2Ugc2Vu c2UgdG8gY29ycmVjdCB0aGVtIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNClRoYW5rcw0KDQpNaWNo YWVsDQoNCg0KRnJvbTogWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb20+DQpTZW50OiBT YXR1cmRheSwgQXByaWwgMjcsIDIwMTkgMzo0MyBBTQ0KVG86IHRjcG0tY2hhaXJzQGlldGYub3Jn OyB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBGd2Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDUudHh0 DQoNCkhpIHdlIGFyZSBwb3N0aW5nIG5ldyBkcmFmdCBwZXIgY2hhaXJzJyByZXF1ZXN0IGZvciBk aXNjdXNzaW9uIG9uIHN0YXR1cy4NCg0KMDQtMDUgZGlmZnMgYXJlIG1pbm9yIGVkaXRzIGZvciBj bGFyaWZpY2F0aW9uIHJhaXNlZCBieSBtYW55IHJldmlld2VycyAodGhhbmtzISkuIE5vIGNoYW5n ZXMgdG8gYWxnb3JpdGhtIC8gcHJvdG9jb2wuDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdl IC0tLS0tLS0tLQ0KRnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPj4NCkRhdGU6IEZyaSwgQXByIDI2LCAyMDE5IGF0IDY6MzkgUE0N ClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi10Y3BtLXJh Y2stMDUudHh0DQpUbzogTmVhbCBDYXJkd2VsbCA8bmNhcmR3ZWxsQGdvb2dsZS5jb208bWFpbHRv Om5jYXJkd2VsbEBnb29nbGUuY29tPj4sIFl1Y2h1bmcgQ2hlbmcgPHljaGVuZ0Bnb29nbGUuY29t PG1haWx0bzp5Y2hlbmdAZ29vZ2xlLmNvbT4+LCBQcml5YXJhbmphbiBKaGEgPHByaXlhcmpoYUBn b29nbGUuY29tPG1haWx0bzpwcml5YXJqaGFAZ29vZ2xlLmNvbT4+LCBOYW5kaXRhIER1a2tpcGF0 aSA8bmFuZGl0YWRAZ29vZ2xlLmNvbTxtYWlsdG86bmFuZGl0YWRAZ29vZ2xlLmNvbT4+DQoNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDUudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1Y2h1bmcgQ2hlbmcgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWlldGYtdGNw bS1yYWNrDQpSZXZpc2lvbjogICAgICAgMDUNClRpdGxlOiAgICAgICAgICBSQUNLOiBhIHRpbWUt YmFzZWQgZmFzdCBsb3NzIGRldGVjdGlvbiBhbGdvcml0aG0gZm9yIFRDUA0KRG9jdW1lbnQgZGF0 ZTogIDIwMTktMDQtMjYNCkdyb3VwOiAgICAgICAgICB0Y3BtDQpQYWdlczogICAgICAgICAgMjkN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi10Y3BtLXJhY2stMDUudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJhY2svDQpIdG1saXplZDogICAgICAg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGNwbS1yYWNrLTA1DQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXRjcG0tcmFjaw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmFjay0wNQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgcHJlc2VudHMgYSBuZXcgVENQIGxvc3MgZGV0ZWN0aW9uIGFsZ29yaXRobSBjYWxsZWQg UkFDSw0KICAgKCJSZWNlbnQgQUNLbm93bGVkZ21lbnQiKS4gIFJBQ0sgdXNlcyB0aGUgbm90aW9u IG9mIHRpbWUsIGluc3RlYWQgb2YNCiAgIHBhY2tldCBvciBzZXF1ZW5jZSBjb3VudHMsIHRvIGRl dGVjdCBsb3NzZXMsIGZvciBtb2Rlcm4gVENQDQogICBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4g c3VwcG9ydCBwZXItcGFja2V0IHRpbWVzdGFtcHMgYW5kIHRoZQ0KICAgc2VsZWN0aXZlIGFja25v d2xlZGdtZW50IChTQUNLKSBvcHRpb24uICBJdCBpcyBpbnRlbmRlZCB0byByZXBsYWNlDQogICB0 aGUgY29udmVudGlvbmFsIERVUEFDSyB0aHJlc2hvbGQgYXBwcm9hY2ggYW5kIGl0cyB2YXJpYW50 cywgYXMgd2VsbA0KICAgYXMgb3RoZXIgbm9uc3RhbmRhcmQgYXBwcm9hY2hlcy4NCg0KDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D2E45F5rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0K c3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkUtTWFpbEZvcm1hdHZvcmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFl1Y2h1bmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QSBwdXJlbHkgZWRpdG9yaWFsIGNvbW1lbnQgb24g dGhlIG5ldyB0ZXh0IGluIC0wNTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGRlZmluaXRpb24gb2YgdGVybXMgaGFz IGJlZW4gdXBkYXRlZCBieSBSRkMgODE3NCBhbmQgdGhlIG5ldyBzdWdnZXN0ZWQgd29yZGluZyBp czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBrZXkgd29yZHMg JnF1b3Q7TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1 b3Q7LCAmcXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBOT1QmcXVvdDssICZxdW90O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5P VCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssICZxdW90O05PVCBSRUNPTU1FTkRFRCZx dW90Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtNQVkmcXVvdDssIGFu ZCAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaWJlZCBpbiBCQ1Ag MTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwZWFyIGluIGFsbCBjYXBpdGFscywgYXMgc2hvd24g aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VW5sZXNzIHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgdG8gZGV2aWF0ZSwg SU1ITyBpdCB3b3VsZCBtYWtlIHNlbnNlIHRvIHVzZSB0aGUgZGVmYXVsdCB0ZXh0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5BbHNvLCBub3RlIHRoYXQgdGhlcmUgaXMgc29tZSB1c2Ugb2YgY2FwaXRhbCBsZXR0ZXIgdGVy bXMgYmVmb3JlIFNlY3Rpb24gNS4gVGhlIGRlZmluaXRpb24gc2hvdWxkIHByb2JhYmx5IGJlIGlu dHJvZHVjZWQNCiBiZWZvcmUgdGhlIGZpcnN0IHVzZSAoaW4gdGhlIGJvZHkpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5G aW5hbGx5LCBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNSByZWZlcmVuY2VzIFJGQzIxMTkgdGhyZWUg dGltZXMsIHdoaWNoIG1heSBiZSBhIHRvb2xpbmcgYnVnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaG9zZSBlZGl0b3Jp YWwgbml0cyBjYW4gYmUgZml4ZWQgbGF0ZXIgaW4gdGhlIHB1YmxpY2F0aW9uIHByb2Nlc3MsIGJ1 dCBhcyB0aGVzZSBhcmUgbG93IGhhbmdpbmcgZnJ1aXRzLCBJTUhPIGl0IHdvdWxkDQogbWFrZSBz ZW5zZSB0byBjb3JyZWN0IHRoZW0gaW4gdGhlIG5leHQgdmVyc2lvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBZdWNodW5nIENoZW5nICZsdDt5Y2hlbmdAZ29vZ2xlLmNvbSZn dDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXByaWwgMjcsIDIwMTkgMzo0MyBBTTxi cj4NCjxiPlRvOjwvYj4gdGNwbS1jaGFpcnNAaWV0Zi5vcmc7IHRjcG1AaWV0Zi5vcmcgRXh0ZW5z aW9ucyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRndkOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA1LnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSB3ZSBh cmUgcG9zdGluZyBuZXcgZHJhZnQgcGVyIGNoYWlycycgcmVxdWVzdCBmb3IgZGlzY3Vzc2lvbiBv biBzdGF0dXMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjA0LTA1IGRpZmZzIGFyZSBtaW5vciBlZGl0cyBm b3IgY2xhcmlmaWNhdGlvbiByYWlzZWQgYnkgbWFueSByZXZpZXdlcnMgKHRoYW5rcyEpLiBObyBj aGFuZ2VzIHRvIGFsZ29yaXRobSAvIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0t LS0tLS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8 YnI+DQpEYXRlOiBGcmksIEFwciAyNiwgMjAxOSBhdCA2OjM5IFBNPGJyPg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNS50eHQ8YnI+ DQpUbzogTmVhbCBDYXJkd2VsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5jYXJkd2VsbEBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bmNhcmR3ZWxsQGdvb2dsZS5jb208L2E+Jmd0OywgWXVjaHVu ZyBDaGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+eWNoZW5nQGdvb2dsZS5jb208L2E+Jmd0OywgUHJpeWFyYW5qYW4gSmhhICZsdDs8YSBo cmVmPSJtYWlsdG86cHJpeWFyamhhQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5wcml5YXJq aGFAZ29vZ2xlLmNvbTwvYT4mZ3Q7LA0KIE5hbmRpdGEgRHVra2lwYXRpICZsdDs8YSBocmVmPSJt YWlsdG86bmFuZGl0YWRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5hbmRpdGFkQGdvb2ds ZS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNS50eHQ8YnI+DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1Y2h1bmcgQ2hlbmcgYW5kIHBvc3RlZCB0byB0aGU8 YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWlldGYtdGNwbS1yYWNrPGJyPg0KUmV2aXNpb246 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDU8YnI+DQpUaXRsZTombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFJBQ0s6IGEgdGltZS1iYXNlZCBmYXN0IGxvc3MgZGV0ZWN0aW9u IGFsZ29yaXRobSBmb3IgVENQPGJyPg0KRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxOS0wNC0yNjxi cj4NCkdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGNwbTxicj4NClBh Z2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjk8YnI+DQpVUkw6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtdGNwbS1yYWNrLTA1LnR4dCIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtdGNwbS1yYWNrLTA1LnR4dDwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdGNwbS1yYWNrLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGNwbS1yYWNrLzwvYT48YnI+DQpIdG1saXplZDom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDU8L2E+PGJyPg0KSHRtbGl6 ZWQ6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmFjayIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJh Y2s8L2E+PGJyPg0KRGlmZjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRj cG0tcmFjay0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmFjay0wNTwvYT48YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+ DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIG5ldyBUQ1AgbG9zcyBkZXRl Y3Rpb24gYWxnb3JpdGhtIGNhbGxlZCBSQUNLPGJyPg0KJm5ic3A7ICZuYnNwOygmcXVvdDtSZWNl bnQgQUNLbm93bGVkZ21lbnQmcXVvdDspLiZuYnNwOyBSQUNLIHVzZXMgdGhlIG5vdGlvbiBvZiB0 aW1lLCBpbnN0ZWFkIG9mPGJyPg0KJm5ic3A7ICZuYnNwO3BhY2tldCBvciBzZXF1ZW5jZSBjb3Vu dHMsIHRvIGRldGVjdCBsb3NzZXMsIGZvciBtb2Rlcm4gVENQPGJyPg0KJm5ic3A7ICZuYnNwO2lt cGxlbWVudGF0aW9ucyB0aGF0IGNhbiBzdXBwb3J0IHBlci1wYWNrZXQgdGltZXN0YW1wcyBhbmQg dGhlPGJyPg0KJm5ic3A7ICZuYnNwO3NlbGVjdGl2ZSBhY2tub3dsZWRnbWVudCAoU0FDSykgb3B0 aW9uLiZuYnNwOyBJdCBpcyBpbnRlbmRlZCB0byByZXBsYWNlPGJyPg0KJm5ic3A7ICZuYnNwO3Ro ZSBjb252ZW50aW9uYWwgRFVQQUNLIHRocmVzaG9sZCBhcHByb2FjaCBhbmQgaXRzIHZhcmlhbnRz LCBhcyB3ZWxsPGJyPg0KJm5ic3A7ICZuYnNwO2FzIG90aGVyIG5vbnN0YW5kYXJkIGFwcHJvYWNo ZXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4N CnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEg aHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRm Lm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D2E45F5rznt8114rzntrzd_-- From nobody Mon May 6 09:39:35 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEE712025F for ; Mon, 6 May 2019 09:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5bY9LrXupBHS for ; Mon, 6 May 2019 09:39:13 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 832891201E6 for ; Mon, 6 May 2019 09:38:27 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id y2so16293739wmi.5 for ; Mon, 06 May 2019 09:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WtTZAe0hg6Ovcj+zAUj2+MUiCbixCoE0G9Mboc03EhU=; b=P5+Y2aaxg1qrr/YW7sw1YoBJk4YXOaXnAmAmz3gf1a1h8Q6YAthyiyJ4e+oAbt/b3m Gnu26CQ/ddlLG0LQALJeygyYNhhnc64XyPCU4PkSI6n764HxOjOLfLGT6hrcw+KrjQcH CX9bmwU+UtWXOvadj0XDVswQMzwvfK6daR502fgD76r4PcMpEsde1ZBvhmwUiJlNHdfo 0jokxRpqpKnopLtTswbJwFWJkhdvfh3Rmq87B7BAd6QiZEuhzzWtBXLq+CG58K5e/+E5 pNU5e61Svg9wJg6wVhHdLHZuyMb6eRL25PFFS+8GuWLi0tsUB79vWeu1Y7rPhkKmwgKa HYFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WtTZAe0hg6Ovcj+zAUj2+MUiCbixCoE0G9Mboc03EhU=; b=AYxI7/r/2Wf+P7Xl/WA+/ro6kHoZcKrdOA7wZI9uW7km0nuwwKIsAYdvfxUIABOyRM qD4sdL2UwueGU1rsXgkfSaxxDvilOb65U2LSjeEA6A0Ea1SIyufvi2MaRrRoyCqSw8lS U0gaeTpIpt6mWKXTCXhsPz/Oz8loFZfoCjfdeVXpfxMzRTqnV09HbELE3/WVay1danWG T2UxKdmmEOzm4abQZtiVXn63EG2dDGvATQqUFOb0KSsbiwXGsgm26rhuBr4ZBuXhKpq/ 3Teajsa9epELaTUdIvqugGyfUfPi89Y/ReeTegHU4QJxT/ugHzA5OUv+jsAFJrZzYtlI cbRw== X-Gm-Message-State: APjAAAXs465P851YhYrL6W3mUC0aSVfo6cKjGqn+QKy2kTAhJeF9EF2Q zb9N8BnRDQaPiC6K6MobHuP17o5wShivN9+82rC6qQ== X-Google-Smtp-Source: APXvYqyCquvqNfydgxmft0E6Ay8eakCdN8pAIfkDcGRLFL2tye9wPNhGRRhbqS6iJDiw89kqIuTn0I1KqbbGP4RY36w= X-Received: by 2002:a05:600c:2101:: with SMTP id u1mr7365280wml.36.1557160705132; Mon, 06 May 2019 09:38:25 -0700 (PDT) MIME-Version: 1.0 References: <155632918775.6767.10665022766872955742.idtracker@ietfa.amsl.com> <6EC6417807D9754DA64F3087E2E2E03E2D2E45F5@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D2E45F5@rznt8114.rznt.rzdir.fht-esslingen.de> From: Yuchung Cheng Date: Mon, 6 May 2019 09:37:47 -0700 Message-ID: To: "Scharf, Michael" Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000b0b63705883aba8a" Archived-At: Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-rack-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 16:39:28 -0000 --000000000000b0b63705883aba8a Content-Type: text/plain; charset="UTF-8" Thanks Mchael. Noted and will correct in the next revision. On Mon, May 6, 2019 at 1:19 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Hi Yuchung, > > > > A purely editorial comment on the new text in -05: > > > > The definition of terms has been updated by RFC 8174 and the new suggested > wording is: > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > > "MAY", and "OPTIONAL" in this document are to be interpreted as > > described in BCP 14 [RFC2119] [RFC8174] when, and only when, they > > appear in all capitals, as shown here. > > > > Unless there are good reasons to deviate, IMHO it would make sense to use > the default text. > > > > Also, note that there is some use of capital letter terms before Section > 5. The definition should probably be introduced before the first use (in > the body). > > > > Finally, draft-ietf-tcpm-rack-05 references RFC2119 three times, which may > be a tooling bug. > > > > Those editorial nits can be fixed later in the publication process, but as > these are low hanging fruits, IMHO it would make sense to correct them in > the next version. > > > > Thanks > > > > Michael > > > > > > *From:* Yuchung Cheng > *Sent:* Saturday, April 27, 2019 3:43 AM > *To:* tcpm-chairs@ietf.org; tcpm@ietf.org Extensions > *Subject:* Fwd: New Version Notification for draft-ietf-tcpm-rack-05.txt > > > > Hi we are posting new draft per chairs' request for discussion on status. > > > > 04-05 diffs are minor edits for clarification raised by many reviewers > (thanks!). No changes to algorithm / protocol. > > ---------- Forwarded message --------- > From: > Date: Fri, Apr 26, 2019 at 6:39 PM > Subject: New Version Notification for draft-ietf-tcpm-rack-05.txt > To: Neal Cardwell , Yuchung Cheng , > Priyaranjan Jha , Nandita Dukkipati < > nanditad@google.com> > > > > > A new version of I-D, draft-ietf-tcpm-rack-05.txt > has been successfully submitted by Yuchung Cheng and posted to the > IETF repository. > > Name: draft-ietf-tcpm-rack > Revision: 05 > Title: RACK: a time-based fast loss detection algorithm for TCP > Document date: 2019-04-26 > Group: tcpm > Pages: 29 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-rack-05 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-05 > > Abstract: > This document presents a new TCP loss detection algorithm called RACK > ("Recent ACKnowledgment"). RACK uses the notion of time, instead of > packet or sequence counts, to detect losses, for modern TCP > implementations that can support per-packet timestamps and the > selective acknowledgment (SACK) option. It is intended to replace > the conventional DUPACK threshold approach and its variants, as well > as other nonstandard approaches. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > --000000000000b0b63705883aba8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mchael. Noted and will correct in the next revision= .

On Mon, May 6, 2019 at 1:19 AM Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Hi Yuchung,

=C2=A0

A purely editorial comment on= the new text in -05:

=C2=A0

The definition of terms has b= een updated by RFC 8174 and the new suggested wording is:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 The key words "MUST", "MUST NOT", "REQUIRED&qu= ot;, "SHALL", "SHALL

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDE= D", "NOT RECOMMENDED",

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 "MAY", and "OPTIONAL" in this document are to be in= terpreted as

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 appear in all capitals, as shown here.

=C2=A0

Unless there are good reasons= to deviate, IMHO it would make sense to use the default text.

=C2=A0

Also, note that there is some= use of capital letter terms before Section 5. The definition should probab= ly be introduced before the first use (in the body).

=C2=A0

Finally, draft-ietf-tcpm-rack= -05 references RFC2119 three times, which may be a tooling bug.

=C2=A0

Those editorial nits can be f= ixed later in the publication process, but as these are low hanging fruits,= IMHO it would make sense to correct them in the next version.

=C2=A0

Thanks

=C2=A0

Michael<= /p>

=C2=A0

=C2=A0

From: Yuchung Cheng <ycheng@google.com>
Sent: Saturday, April 27, 2019 3:43 AM
To: tcpm-c= hairs@ietf.org; tcpm= @ietf.org Extensions <tcpm@ietf.org>
Subject: Fwd: New Version Notification for draft-ietf-tcpm-rack-05.t= xt

=C2=A0

Hi we are posting new draft per chairs' request = for discussion on status.

=C2=A0

04-05 diffs are minor e= dits for clarification raised by many reviewers (thanks!). No changes to al= gorithm / protocol.

---------- Forwarded message ---------
From: <int= ernet-drafts@ietf.org>
Date: Fri, Apr 26, 2019 at 6:39 PM
Subject: New Version Notification for draft-ietf-tcpm-rack-05.txt
To: Neal Cardwell <ncardwell@google.com>, Yuchung Cheng <ycheng@google.com>, Priyaranjan Jha= <priyarjha@go= ogle.com>, Nandita Dukkipati <nanditad@google.com>




A new version of I-D, draft-ietf-tcpm-rack-05.txt
has been successfully submitted by Yuchung Cheng and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-tcpm-rack
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK: a time-based fast loss detec= tion algorithm for TCP
Document date:=C2=A0 2019-04-26
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tcpm
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 29
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-05.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf= .org/doc/draft-ietf-tcpm-rack/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draf= t-ietf-tcpm-rack-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.= org/doc/html/draft-ietf-tcpm-rack
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rack-05

Abstract:
=C2=A0 =C2=A0This document presents a new TCP loss detection algorithm call= ed RACK
=C2=A0 =C2=A0("Recent ACKnowledgment").=C2=A0 RACK uses the notio= n of time, instead of
=C2=A0 =C2=A0packet or sequence counts, to detect losses, for modern TCP =C2=A0 =C2=A0implementations that can support per-packet timestamps and the=
=C2=A0 =C2=A0selective acknowledgment (SACK) option.=C2=A0 It is intended t= o replace
=C2=A0 =C2=A0the conventional DUPACK threshold approach and its variants, a= s well
=C2=A0 =C2=A0as other nonstandard approaches.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000b0b63705883aba8a-- From nobody Mon May 6 14:29:04 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7693E120162 for ; Mon, 6 May 2019 14:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 egyqfinO398J for ; Mon, 6 May 2019 14:28:59 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 323E2120020 for ; Mon, 6 May 2019 14:28:59 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id h4so19205708wre.7 for ; Mon, 06 May 2019 14:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+3cLoVN5KenOPJSp41U3Rq9OFj2jU3cruV9YdZPZcoc=; b=D7/ArXUaYSWmSIw9vxTNPkyap/8aefhfyWvgSIC3TpEUu7ZV4JIAHPEd3TWs63Nn51 tsPAaAiLFg/Nl12xeatOqJGPIsI8k8nNxRuNswYYBMYsZcdBzvRXMmCR5y3rfhOmhkzz duuSndxWCvsdmPRbq9gBjBmmQh74jcGs70gyX9oMTj1os66OB3v44Vw+cqWqafT0JJBW l6YIextF9uWawbr8uQv9Bve+MLS27CfDTdBFDL/ZEQk8vNR5OOBhyNVtB3m2DjeKIUki 0nF7gXNkYQt1riDYH0XbMOWVpgHhpPWesTlwwY66WB1YGbiGkHteHmc71o+TgIiW2Wna GPSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+3cLoVN5KenOPJSp41U3Rq9OFj2jU3cruV9YdZPZcoc=; b=W78B+XWj38uCPV+SsQxnwnyQMjCmc9XlJbQiUn1WcKtOOL3A9IVQy94I8e3JbJSJ3B rB/ztamvmz4KohAuvr2ov1OurPbd/RXGYU7Lck0b60F3hDWjgJo10fMdoYG+LmD8/R0o Vqr/b4J6tg8Fl7/fcf8I0dOBZgHjorqDFOvcTIEG4TQ91v8XwGAc6v/vf50pSTlTHAiH hnwp2Bu5CIqhy9OU+HXUBJRS1vhZRUeQzJTxof2VlOU1yfcP0bIoB0rIvkTgiVTAXYPp znNa/MSE9stbRJSRewa0qc5lxPveyKk1J2a8OkTBKVOjsc9S09gPUTXeJEUQwiP2Vdvm +RBA== X-Gm-Message-State: APjAAAWqo0j9Oiyph5GFB9BBQqr1sr8Sj83lJHvmSqH+YI1ctjq03JKx tOEvPnkodz2BbeW4YXJYRf8dkk/l2ceq0Pi3fFgzAQ== X-Google-Smtp-Source: APXvYqy3LVLRWr6uK1rh9UG3iQujz3B7rK0O6DO32ATDLmIgCMz7OBY8kfOtgChG+K7zycLFeIgqMpq+blhuaLfsO1U= X-Received: by 2002:adf:f349:: with SMTP id e9mr1381359wrp.71.1557178136942; Mon, 06 May 2019 14:28:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 6 May 2019 14:28:17 -0700 Message-ID: To: Yi Huang Cc: Yuchung Cheng , Matt Olson , "tcpm@ietf.org" , Neal Cardwell Content-Type: multipart/alternative; boundary="000000000000b4d2aa05883ec9cf" Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 21:29:02 -0000 --000000000000b4d2aa05883ec9cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the late reply. Forget to hit send after drafting the reply... Thanks for spotting that. TCP_send_probe() should always re-arm the RTO regardless of a TLP is sent or not, if there's unacknowledged data. Proposed rev in "Note that the sender MUST arm an RTO timer and not the PTO timer *at the end of TLP_send_probe() as long as FlightSize is not zero, regardless of sending a probe or not*. This ensures that the sender does not send repeated, back-to-back TLP probes. *Also checking TLPRxtOut prior to sending the loss probe* is important to avoid TLP loops if an application writes periodically at an interval less than PTO." *From: *Yi Huang *Date: *Thu, May 2, 2019 at 11:47 AM *To: *Yuchung Cheng, Matt Olson *Cc: *tcpm@ietf.org If TLPRxtOut is checked in TLP_send_probe(), a new PTO can cancel an > already running RTO timer armed by sending TLP previously. If > TLP_send_probe() decides not to send the probe for the new PTO, what shou= ld > the sender do next? Rearm RTO or treat it as RTO timeout? The draft state= s > we must arm an RTO after transmitting TLP but in this case, no probe will > be sent. > > Also, in page 17, the draft says "This is important to avoid TLP loops if > an application writes periodically at an interval less than PTO." but if > the app writes periodically at an interval less than PTO, PTO will just b= e > pushed out and not fire until the sender cannot send anything due to wind= ow > limit. Then in this case, TLP loops do not seem to exist if TLP loops mea= ns > back-to-back TLP probes. Am I missing anything here? > > Thanks, > > Yi > > -----Original Message----- > From: Yuchung Cheng > Sent: Thursday, May 2, 2019 10:25 AM > To: Matt Olson > Cc: Yi Huang ; tcpm@ietf.org > Subject: Re: [tcpm] Questions about TLP > > On Thu, May 2, 2019 at 10:09 AM Matt Olson wrote: > > > > Also, section 6.5.1 Step 1 is presented as a complete set of conditions > for scheduling a PTO, but it is missing a bullet point for TLPRxtOut. > Thanks for checking: but checking TLPRxtOut is not necessary and is not > preferred when scheduling a probe -- the goal is to prevent more than one > probe inflight, so checking right before TLPRxtOut sending the next one > allows the best coverage of application-limited writes > (burst-idle-burst-....). > > > > > > > > -----Original Message----- > > From: Yuchung Cheng > > Sent: Wednesday, May 1, 2019 11:33 PM > > To: Yi Huang > > Cc: tcpm@ietf.org; Matt Olson > > Subject: Re: [tcpm] Questions about TLP > > > > On Wed, May 1, 2019 at 10:48 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > > > > > > Hi RACK/TLP authors, > > > > > > > > > > > > I have the following questions (page numbers refer to > draft-ietf-tcpm-rack-05): > > > > > > > > > > > > 1.In page 16, it says =E2=80=9CFinally, if the time at which an RTO w= ould fire > (here denoted "TCP_RTO_expire") is sooner than the computed time for the > PTO, then a probe is scheduled to be sent at that earlier time.=E2=80=9D = What does > this TCP_RTO_expire actually mean? Does it mean there is another RTO time= r > (possibly started some time in the past) running along with PTO or just R= TT > + 4*RTTVar + Now()? Also, why would another probe be sent at RTO expirati= on > time instead of treating it like RTO and collapsing the cwnd? > > > > TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > > SRTT + 4*RTTVAR + Now() > > We use TCP_RTO_expire() because many implementations including Linux > > do not use the exact RFC formula > > > > The reason it's not treated as a regular RTO is to avoid resetting > congestion window to 1. The rationale is if the probe was sent within > min(PTO, RTO) and was delivered successfully, there's no need to reset > congestion window and re-start slow-start, similar to the rationale of > Reno's fast recovery reducing window to ssthresh instead of 1. We have > found this strategy benefits wireless connections, as the chance of > spurious RTO is high due to the delay variation. > > > > > > > > > > > > > > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it > is stated that TLPRxtOut is used to guarantee that there is only one > outstanding TLP retransmission.. However, it is not clear to me when > TLPRxtOut should be really used. Should it be used in 6.5.1 Step. 1 > (checking whether we should and can schedule a TLP) or in TLP_send_probe(= )? > > > > This is in > > > > 6.6.2. Recording loss probe states > > > > Senders MUST only send a TLP loss probe retransmission if TLPRxtOut > > is false. This ensures that at any given time a connection has at > > most one outstanding TLP retransmission. This allows the sender to > > > > but I agree it'd be more clear to include this in TLP_send_probe() > pseudo code. I'd incorporate in the next rev. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Yi > > > > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > .. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D01%7C01%7Cmaolson%40m= i > > > cr > > > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2 > > > d7 > > > cd011db47%7C1&sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2iy3OBAno= % > > > 3D > > > &reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000b4d2aa05883ec9cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the late reply. Forget to hit send after draftin= g the reply...

Thanks for spotting that. TCP_send_probe() should alw= ays re-arm the
RTO regardless of a TLP is sent or not, if there's un= acknowledged
data. Proposed rev in

"Note that the sender MUS= T arm an RTO timer and not the PTO timer=C2=A0at the end of TLP_send_pro= be() as long as FlightSize is not zero, regardless of sending a probe or no= t. This ensures that the sender does not send repeated, back-to-back TL= P probes.=C2=A0Also checking TLPRxtOut prior to sending the loss probe is important to avoid TLP loops if an application writes periodically at= an interval less than PTO."

From: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
Dat= e: Thu, May 2, 2019 at 11:47 AM
To: Yuchung Ch= eng, Matt Olson
Cc: tcpm@ietf.org

If TLPRxtOut is checked in TLP_send_probe(), a new PT= O can cancel an already running RTO timer armed by sending TLP previously. = If TLP_send_probe() decides not to send the probe for the new PTO, what sho= uld the sender do next? Rearm RTO or treat it as RTO timeout? The draft sta= tes we must arm an RTO after transmitting TLP but in this case, no probe wi= ll be sent.

Also, in page 17, the draft says "This is important to avoid TLP loops= if an application writes periodically at an interval less than PTO." = but if the app writes periodically at an interval less than PTO, PTO will j= ust be pushed out and not fire until the sender cannot send anything due to= window limit. Then in this case, TLP loops do not seem to exist if TLP loo= ps means back-to-back TLP probes. Am I missing anything here?

Thanks,

Yi

-----Original Message-----
From: Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org>
Sent: Thursday, May 2, 2019 10:25 AM
To: Matt Olson <maolson@microsoft.com>
Cc: Yi Huang <= huanyi@microsoft.com>; tcpm@ietf.org
Subject: Re: [tcpm] Questions about TLP

On Thu, May 2, 2019 at 10:09 AM Matt Olson <maolson@microsoft.com> wrote:
>
> Also, section 6.5.1 Step 1 is presented as a complete set of condition= s for scheduling a PTO, but it is missing a bullet point for TLPRxtOut.
Thanks for checking: but checking TLPRxtOut is not necessary and is not pre= ferred when scheduling a probe -- the goal is to prevent more than one prob= e inflight, so checking right before TLPRxtOut sending the next one allows = the best coverage of application-limited writes (burst-idle-burst-....).



>
> -----Original Message-----
> From: Yuchung Cheng <ycheng@google.com>
> Sent: Wednesday, May 1, 2019 11:33 PM
> To: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
> Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>
> Subject: Re: [tcpm] Questions about TLP
>
> On Wed, May 1, 2019 at 10:48 PM Yi Huang <huanyi=3D40microsoft.com@dmarc.i= etf.org> wrote:
> >
> > Hi RACK/TLP authors,
> >
> >
> >
> > I have the following questions (page numbers refer to draft-ietf-= tcpm-rack-05):
> >
> >
> >
> > 1.In page 16, it says =E2=80=9CFinally, if the time at which an R= TO would fire (here denoted "TCP_RTO_expire") is sooner than the = computed time for the PTO, then a probe is scheduled to be sent at that ear= lier time.=E2=80=9D What does this TCP_RTO_expire actually mean? Does it me= an there is another RTO timer (possibly started some time in the past) runn= ing along with PTO or just RTT + 4*RTTVar + Now()? Also, why would another = probe be sent at RTO expiration time instead of treating it like RTO and co= llapsing the cwnd?
>
> TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > SRTT + 4*RTTVAR + Now()
> We use TCP_RTO_expire() because many implementations including Linux <= br> > do not use the exact RFC formula
>
> The reason it's not treated as a regular RTO is to avoid resetting= congestion window to 1. The rationale is if the probe was sent within min(= PTO, RTO) and was delivered successfully, there's no need to reset cong= estion window and re-start slow-start, similar to the rationale of Reno'= ;s fast recovery reducing window to ssthresh instead of 1. We have found th= is strategy benefits wireless connections, as the chance of spurious RTO is= high due to the delay variation.
>
> >
> >
> >
> > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and= it is stated that TLPRxtOut is used to guarantee that there is only one ou= tstanding TLP retransmission.. However, it is not clear to me when TLPRxtOu= t should be really used. Should it be used in 6.5.1 Step. 1 (checking wheth= er we should and can schedule a TLP) or in TLP_send_probe()?
>
> This is in
>
> 6.6.2.=C2=A0 Recording loss probe states
>
>=C2=A0 =C2=A0 Senders MUST only send a TLP loss probe retransmission if= TLPRxtOut
>=C2=A0 =C2=A0 is false.=C2=A0 This ensures that at any given time a con= nection has at
>=C2=A0 =C2=A0 most one outstanding TLP retransmission.=C2=A0 This allow= s the sender to
>
> but I agree it'd be more clear to include this in TLP_send_probe()= pseudo code. I'd incorporate in the next rev.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Yi
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://nam06.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww..
> > = ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D01%7C01%7Cmaolson%4= 0mi
> > cr
> > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2 > > d7
> > cd011db47%7C1&amp;sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2= iy3OBAno%
> > 3D
> > &amp;reserved=3D0
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000b4d2aa05883ec9cf-- From nobody Mon May 6 15:20:50 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E2A1200A4 for ; Mon, 6 May 2019 15:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 IzD8PaeJwuV2 for ; Mon, 6 May 2019 15:20:45 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730105.outbound.protection.outlook.com [40.107.73.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52498120098 for ; Mon, 6 May 2019 15:20:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=OGkTBb0K/3J/QXgJKZIBXkG/xX2sTE+B0SBO2c946sawQYCpEBqZFieXl/nUpCQGFsz5ZcQKx581gZ6r9qXFpNVaV2Ac6OEH5nupSkN/1WDS4A50dyl9PQTj0L7/2WupqbpW2vbIRO5zmKCInf53NlOfNuygMLIPMOKj9cc6FFA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GoZPZU82DNHS7ojUOT9sTjFSM3qVJkvWRqUWajSFD54=; b=Gd7NmEsgUCoCGoo4lIeWvsq3/JmCKBpGfG8dP3R0kpEkgNHr77mGVLWN3ZKAoWUxyA75JfezMjWBaurQYtPf9D/CnVzHuRmOj9GLOZz+XmFIzD78lzYJypTfiL6tC+Vmuo7kGgJ43NupFpOAnbbrZtX0davoMNc46ZZp4TsDS8o= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GoZPZU82DNHS7ojUOT9sTjFSM3qVJkvWRqUWajSFD54=; b=GeBAFVZwspy0x5AOfT06rfd/BzDebC/fN60hrKOQa+OIQ1IFqnHO10sa0qTCYZWhscC1as4GpTmHN5MjqXWedxQoyQzb2cETruAHpgmQUlC4Nf7uEVf+lxSVrx97Gk1wuOKO8nimL+l2o+5cuKUVRnJbRkIcvMV9VaWbL8cCVII= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB0881.namprd21.prod.outlook.com (52.132.23.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.4; Mon, 6 May 2019 22:20:41 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::2056:cdb6:e2aa:e45a]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::2056:cdb6:e2aa:e45a%9]) with mapi id 15.20.1900.002; Mon, 6 May 2019 22:20:41 +0000 From: Yi Huang To: Yuchung Cheng CC: Yuchung Cheng , Matt Olson , "tcpm@ietf.org" , Neal Cardwell Thread-Topic: [tcpm] Questions about TLP Thread-Index: AdUAqnPmaX0KgH/WQE+MIFBj5gEdQgABnF8AABYYoqAAAK0mgAACL/RQAM94ioAAAcfIIA== Date: Mon, 6 May 2019 22:20:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-06T22:20:39.4904300Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b31c7480-4fa1-413c-80ea-3f7503265918; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:2:c52:a508:8c4c:b31e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4efacf08-8588-449a-be00-08d6d2711342 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB0881; x-ms-traffictypediagnostic: BL0PR2101MB0881: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(136003)(366004)(13464003)(199004)(189003)(51914003)(476003)(66556008)(11346002)(66446008)(66946007)(73956011)(446003)(66476007)(64756008)(486006)(606006)(76116006)(46003)(33656002)(236005)(186003)(5660300002)(52536014)(25786009)(6116002)(10090500001)(2906002)(10290500003)(790700001)(86612001)(86362001)(54906003)(256004)(14444005)(6436002)(966005)(8676002)(55016002)(81166006)(81156014)(7736002)(71200400001)(71190400001)(478600001)(6306002)(54896002)(4326008)(9686003)(68736007)(6246003)(22452003)(76176011)(229853002)(99286004)(102836004)(6506007)(53546011)(53936002)(316002)(8990500004)(8936002)(7696005)(74316002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB0881; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: x/SwDOKmhMLosb2RLRT46E0zc4KSv8UhviLjl9gq/nrkUvA34nCQnBhNX7x07DzEH8UoET/Y3sSfHeZtaFTQwafftHnXJ1unFYwmzmbrL4DlHud5Ve3lXKQEOqNL8SedBcG3nNYA7nx6c+QKJENiUxcVBAGzQE60y7fcldQkxK7+VxLaWJEiN4ELdQ9M0fubxxEKyhCdP4Bba5tw2G2g8yZZhFP4RRKqTvzxVYMWRsAS54NiXEfcAsTO2tJlIJ7VrMiUsOMq6M8VbeQjlMvy7twi2zf/+Ff46ajAkKlQ/8jv7IeZtO2ONs+QH7okdZaqxp21yEh4UZXZEVPRBX/xBOqeZwfP7fZ3LmqtoYGdslH8QjFRHfGbf+FB/WQvRls051zc8wvsuR8jhcNLFy8w0yEBys3NeZdvsHJZiFHrO04= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1043893F691DED20889B3C45C3300BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4efacf08-8588-449a-be00-08d6d2711342 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2019 22:20:41.3253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0881 Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 22:20:49 -0000 --_000_BL0PR2101MB1043893F691DED20889B3C45C3300BL0PR2101MB1043_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gVGhlIHByb3Bvc2VkIHJldiBvZiB0aGUgc3Rh dGVtZW50IGlzIG11Y2ggZWFzaWVyIHRvIHVuZGVyc3RhbmQuDQoNCllpDQoNCkZyb206IFl1Y2h1 bmcgQ2hlbmcgPHljaGVuZz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTZW50OiBNb25k YXksIE1heSA2LCAyMDE5IDI6MjggUE0NClRvOiBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29mdC5j b20+DQpDYzogWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb20+OyBNYXR0IE9sc29uIDxt YW9sc29uQG1pY3Jvc29mdC5jb20+OyB0Y3BtQGlldGYub3JnOyBOZWFsIENhcmR3ZWxsIDxuY2Fy ZHdlbGxAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbdGNwbV0gUXVlc3Rpb25zIGFib3V0IFRM UA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIEZvcmdldCB0byBoaXQgc2VuZCBhZnRlciBk cmFmdGluZyB0aGUgcmVwbHkuLi4NCg0KVGhhbmtzIGZvciBzcG90dGluZyB0aGF0LiBUQ1Bfc2Vu ZF9wcm9iZSgpIHNob3VsZCBhbHdheXMgcmUtYXJtIHRoZQ0KUlRPIHJlZ2FyZGxlc3Mgb2YgYSBU TFAgaXMgc2VudCBvciBub3QsIGlmIHRoZXJlJ3MgdW5hY2tub3dsZWRnZWQNCmRhdGEuIFByb3Bv c2VkIHJldiBpbg0KDQoiTm90ZSB0aGF0IHRoZSBzZW5kZXIgTVVTVCBhcm0gYW4gUlRPIHRpbWVy IGFuZCBub3QgdGhlIFBUTyB0aW1lciBhdCB0aGUgZW5kIG9mIFRMUF9zZW5kX3Byb2JlKCkgYXMg bG9uZyBhcyBGbGlnaHRTaXplIGlzIG5vdCB6ZXJvLCByZWdhcmRsZXNzIG9mIHNlbmRpbmcgYSBw cm9iZSBvciBub3QuIFRoaXMgZW5zdXJlcyB0aGF0IHRoZSBzZW5kZXIgZG9lcyBub3Qgc2VuZCBy ZXBlYXRlZCwgYmFjay10by1iYWNrIFRMUCBwcm9iZXMuIEFsc28gY2hlY2tpbmcgVExQUnh0T3V0 IHByaW9yIHRvIHNlbmRpbmcgdGhlIGxvc3MgcHJvYmUgaXMgaW1wb3J0YW50IHRvIGF2b2lkIFRM UCBsb29wcyBpZiBhbiBhcHBsaWNhdGlvbiB3cml0ZXMgcGVyaW9kaWNhbGx5IGF0IGFuIGludGVy dmFsIGxlc3MgdGhhbiBQVE8uIg0KDQpGcm9tOiBZaSBIdWFuZyA8aHVhbnlpPTQwbWljcm9zb2Z0 LmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3Jn Pj4NCkRhdGU6IFRodSwgTWF5IDIsIDIwMTkgYXQgMTE6NDcgQU0NClRvOiBZdWNodW5nIENoZW5n LCBNYXR0IE9sc29uDQpDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCklm IFRMUFJ4dE91dCBpcyBjaGVja2VkIGluIFRMUF9zZW5kX3Byb2JlKCksIGEgbmV3IFBUTyBjYW4g Y2FuY2VsIGFuIGFscmVhZHkgcnVubmluZyBSVE8gdGltZXIgYXJtZWQgYnkgc2VuZGluZyBUTFAg cHJldmlvdXNseS4gSWYgVExQX3NlbmRfcHJvYmUoKSBkZWNpZGVzIG5vdCB0byBzZW5kIHRoZSBw cm9iZSBmb3IgdGhlIG5ldyBQVE8sIHdoYXQgc2hvdWxkIHRoZSBzZW5kZXIgZG8gbmV4dD8gUmVh cm0gUlRPIG9yIHRyZWF0IGl0IGFzIFJUTyB0aW1lb3V0PyBUaGUgZHJhZnQgc3RhdGVzIHdlIG11 c3QgYXJtIGFuIFJUTyBhZnRlciB0cmFuc21pdHRpbmcgVExQIGJ1dCBpbiB0aGlzIGNhc2UsIG5v IHByb2JlIHdpbGwgYmUgc2VudC4NCg0KQWxzbywgaW4gcGFnZSAxNywgdGhlIGRyYWZ0IHNheXMg IlRoaXMgaXMgaW1wb3J0YW50IHRvIGF2b2lkIFRMUCBsb29wcyBpZiBhbiBhcHBsaWNhdGlvbiB3 cml0ZXMgcGVyaW9kaWNhbGx5IGF0IGFuIGludGVydmFsIGxlc3MgdGhhbiBQVE8uIiBidXQgaWYg dGhlIGFwcCB3cml0ZXMgcGVyaW9kaWNhbGx5IGF0IGFuIGludGVydmFsIGxlc3MgdGhhbiBQVE8s IFBUTyB3aWxsIGp1c3QgYmUgcHVzaGVkIG91dCBhbmQgbm90IGZpcmUgdW50aWwgdGhlIHNlbmRl ciBjYW5ub3Qgc2VuZCBhbnl0aGluZyBkdWUgdG8gd2luZG93IGxpbWl0LiBUaGVuIGluIHRoaXMg Y2FzZSwgVExQIGxvb3BzIGRvIG5vdCBzZWVtIHRvIGV4aXN0IGlmIFRMUCBsb29wcyBtZWFucyBi YWNrLXRvLWJhY2sgVExQIHByb2Jlcy4gQW0gSSBtaXNzaW5nIGFueXRoaW5nIGhlcmU/DQoNClRo YW5rcywNCg0KWWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFl1Y2h1bmcg Q2hlbmcgPHljaGVuZz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwZ29vZ2xl LmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpTZW50OiBUaHVyc2RheSwgTWF5IDIsIDIwMTkgMTA6MjUg QU0NClRvOiBNYXR0IE9sc29uIDxtYW9sc29uQG1pY3Jvc29mdC5jb208bWFpbHRvOm1hb2xzb25A bWljcm9zb2Z0LmNvbT4+DQpDYzogWWkgSHVhbmcgPGh1YW55aUBtaWNyb3NvZnQuY29tPG1haWx0 bzpodWFueWlAbWljcm9zb2Z0LmNvbT4+OyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQgVExQDQoNCk9uIFRodSwg TWF5IDIsIDIwMTkgYXQgMTA6MDkgQU0gTWF0dCBPbHNvbiA8bWFvbHNvbkBtaWNyb3NvZnQuY29t PG1haWx0bzptYW9sc29uQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4NCj4gQWxzbywgc2VjdGlv biA2LjUuMSBTdGVwIDEgaXMgcHJlc2VudGVkIGFzIGEgY29tcGxldGUgc2V0IG9mIGNvbmRpdGlv bnMgZm9yIHNjaGVkdWxpbmcgYSBQVE8sIGJ1dCBpdCBpcyBtaXNzaW5nIGEgYnVsbGV0IHBvaW50 IGZvciBUTFBSeHRPdXQuDQpUaGFua3MgZm9yIGNoZWNraW5nOiBidXQgY2hlY2tpbmcgVExQUnh0 T3V0IGlzIG5vdCBuZWNlc3NhcnkgYW5kIGlzIG5vdCBwcmVmZXJyZWQgd2hlbiBzY2hlZHVsaW5n IGEgcHJvYmUgLS0gdGhlIGdvYWwgaXMgdG8gcHJldmVudCBtb3JlIHRoYW4gb25lIHByb2JlIGlu ZmxpZ2h0LCBzbyBjaGVja2luZyByaWdodCBiZWZvcmUgVExQUnh0T3V0IHNlbmRpbmcgdGhlIG5l eHQgb25lIGFsbG93cyB0aGUgYmVzdCBjb3ZlcmFnZSBvZiBhcHBsaWNhdGlvbi1saW1pdGVkIHdy aXRlcyAoYnVyc3QtaWRsZS1idXJzdC0uLi4uKS4NCg0KDQoNCg0KPg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29vZ2xlLmNvbTxt YWlsdG86eWNoZW5nQGdvb2dsZS5jb20+Pg0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxLCAyMDE5 IDExOjMzIFBNDQo+IFRvOiBZaSBIdWFuZyA8aHVhbnlpPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYuLm9yZz4+DQo+IENjOiB0 Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPjsgTWF0dCBPbHNvbiA8bWFvbHNvbkBt aWNyb3NvZnQuY29tPG1haWx0bzptYW9sc29uQG1pY3Jvc29mdC5jb20+Pg0KPiBTdWJqZWN0OiBS ZTogW3RjcG1dIFF1ZXN0aW9ucyBhYm91dCBUTFANCj4NCj4gT24gV2VkLCBNYXkgMSwgMjAxOSBh dCAxMDo0OCBQTSBZaSBIdWFuZyA8aHVhbnlpPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y ZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+ID4NCj4g PiBIaSBSQUNLL1RMUCBhdXRob3JzLA0KPiA+DQo+ID4NCj4gPg0KPiA+IEkgaGF2ZSB0aGUgZm9s bG93aW5nIHF1ZXN0aW9ucyAocGFnZSBudW1iZXJzIHJlZmVyIHRvIGRyYWZ0LWlldGYtdGNwbS1y YWNrLTA1KToNCj4gPg0KPiA+DQo+ID4NCj4gPiAxLkluIHBhZ2UgMTYsIGl0IHNheXMg4oCcRmlu YWxseSwgaWYgdGhlIHRpbWUgYXQgd2hpY2ggYW4gUlRPIHdvdWxkIGZpcmUgKGhlcmUgZGVub3Rl ZCAiVENQX1JUT19leHBpcmUiKSBpcyBzb29uZXIgdGhhbiB0aGUgY29tcHV0ZWQgdGltZSBmb3Ig dGhlIFBUTywgdGhlbiBhIHByb2JlIGlzIHNjaGVkdWxlZCB0byBiZSBzZW50IGF0IHRoYXQgZWFy bGllciB0aW1lLuKAnSBXaGF0IGRvZXMgdGhpcyBUQ1BfUlRPX2V4cGlyZSBhY3R1YWxseSBtZWFu PyBEb2VzIGl0IG1lYW4gdGhlcmUgaXMgYW5vdGhlciBSVE8gdGltZXIgKHBvc3NpYmx5IHN0YXJ0 ZWQgc29tZSB0aW1lIGluIHRoZSBwYXN0KSBydW5uaW5nIGFsb25nIHdpdGggUFRPIG9yIGp1c3Qg UlRUICsgNCpSVFRWYXIgKyBOb3coKT8gQWxzbywgd2h5IHdvdWxkIGFub3RoZXIgcHJvYmUgYmUg c2VudCBhdCBSVE8gZXhwaXJhdGlvbiB0aW1lIGluc3RlYWQgb2YgdHJlYXRpbmcgaXQgbGlrZSBS VE8gYW5kIGNvbGxhcHNpbmcgdGhlIGN3bmQ/DQo+DQo+IFRDUF9SVE9fZXhwaXJlKCkgc2hvdWxk IHJldHVybiBhIHRpbWVvdXQgdmFsdWUgZm9yIHJlZ3VsYXIgUlRPLCBpLmUuDQo+IFNSVFQgKyA0 KlJUVFZBUiArIE5vdygpDQo+IFdlIHVzZSBUQ1BfUlRPX2V4cGlyZSgpIGJlY2F1c2UgbWFueSBp bXBsZW1lbnRhdGlvbnMgaW5jbHVkaW5nIExpbnV4DQo+IGRvIG5vdCB1c2UgdGhlIGV4YWN0IFJG QyBmb3JtdWxhDQo+DQo+IFRoZSByZWFzb24gaXQncyBub3QgdHJlYXRlZCBhcyBhIHJlZ3VsYXIg UlRPIGlzIHRvIGF2b2lkIHJlc2V0dGluZyBjb25nZXN0aW9uIHdpbmRvdyB0byAxLiBUaGUgcmF0 aW9uYWxlIGlzIGlmIHRoZSBwcm9iZSB3YXMgc2VudCB3aXRoaW4gbWluKFBUTywgUlRPKSBhbmQg d2FzIGRlbGl2ZXJlZCBzdWNjZXNzZnVsbHksIHRoZXJlJ3Mgbm8gbmVlZCB0byByZXNldCBjb25n ZXN0aW9uIHdpbmRvdyBhbmQgcmUtc3RhcnQgc2xvdy1zdGFydCwgc2ltaWxhciB0byB0aGUgcmF0 aW9uYWxlIG9mIFJlbm8ncyBmYXN0IHJlY292ZXJ5IHJlZHVjaW5nIHdpbmRvdyB0byBzc3RocmVz aCBpbnN0ZWFkIG9mIDEuIFdlIGhhdmUgZm91bmQgdGhpcyBzdHJhdGVneSBiZW5lZml0cyB3aXJl bGVzcyBjb25uZWN0aW9ucywgYXMgdGhlIGNoYW5jZSBvZiBzcHVyaW91cyBSVE8gaXMgaGlnaCBk dWUgdG8gdGhlIGRlbGF5IHZhcmlhdGlvbi4NCj4NCj4gPg0KPiA+DQo+ID4NCj4gPiAyLkluIHBh Z2UgMTggc2VjdGlvbiA2LjYsIGEgbmV3IHZhcmlhYmxlIFRMUFJ4dE91dCBpcyBkZWZpbmVkIGFu ZCBpdCBpcyBzdGF0ZWQgdGhhdCBUTFBSeHRPdXQgaXMgdXNlZCB0byBndWFyYW50ZWUgdGhhdCB0 aGVyZSBpcyBvbmx5IG9uZSBvdXRzdGFuZGluZyBUTFAgcmV0cmFuc21pc3Npb24uLiBIb3dldmVy LCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hlbiBUTFBSeHRPdXQgc2hvdWxkIGJlIHJlYWxseSB1 c2VkLiBTaG91bGQgaXQgYmUgdXNlZCBpbiA2LjUuMSBTdGVwLiAxIChjaGVja2luZyB3aGV0aGVy IHdlIHNob3VsZCBhbmQgY2FuIHNjaGVkdWxlIGEgVExQKSBvciBpbiBUTFBfc2VuZF9wcm9iZSgp Pw0KPg0KPiBUaGlzIGlzIGluDQo+DQo+IDYuNi4yLiAgUmVjb3JkaW5nIGxvc3MgcHJvYmUgc3Rh dGVzDQo+DQo+ICAgIFNlbmRlcnMgTVVTVCBvbmx5IHNlbmQgYSBUTFAgbG9zcyBwcm9iZSByZXRy YW5zbWlzc2lvbiBpZiBUTFBSeHRPdXQNCj4gICAgaXMgZmFsc2UuICBUaGlzIGVuc3VyZXMgdGhh dCBhdCBhbnkgZ2l2ZW4gdGltZSBhIGNvbm5lY3Rpb24gaGFzIGF0DQo+ICAgIG1vc3Qgb25lIG91 dHN0YW5kaW5nIFRMUCByZXRyYW5zbWlzc2lvbi4gIFRoaXMgYWxsb3dzIHRoZSBzZW5kZXIgdG8N Cj4NCj4gYnV0IEkgYWdyZWUgaXQnZCBiZSBtb3JlIGNsZWFyIHRvIGluY2x1ZGUgdGhpcyBpbiBU TFBfc2VuZF9wcm9iZSgpIHBzZXVkbyBjb2RlLiBJJ2QgaW5jb3Jwb3JhdGUgaW4gdGhlIG5leHQg cmV2Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+DQo+ID4NCj4gPiBZaQ0K PiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnPG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy4uDQo+ID4gaWV0Zi5vcmc8aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZpZXRmLm9yZyZkYXRhPTAxJTdDMDElN0NodWFueWklNDBtaWNyb3NvZnQuY29tJTdDYTA3NjNl ODVmNTRmNDQzYjRjNTUwOGQ2ZDI2OWRlMWUlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzEmc2RhdGE9UnpjS1g3bzVDNE1EZmFvdVRkMURQdlB0SFZvQXJTM05VVVAyMzZlSWQy WSUzRCZyZXNlcnZlZD0wPiUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDEl N0MwMSU3Q21hb2xzb24lNDBtaQ0KPiA+IGNyDQo+ID4gb3NvZnQuY29tPGh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGb3NvZnQu Y29tJmRhdGE9MDElN0MwMSU3Q2h1YW55aSU0MG1pY3Jvc29mdC5jb20lN0NhMDc2M2U4NWY1NGY0 NDNiNGM1NTA4ZDZkMjY5ZGUxZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdD MSZzZGF0YT1od2lZJTJCJTJCeW10Q3JpMlF4bHB6ZnpLVVExQmoyY2sySnFrWVRiZnBhUHB2RSUz RCZyZXNlcnZlZD0wPiU3QzY2ZGI0NDY3MmUzZDQxMDFkNzI5MDhkNmNlYzgyMDAxJTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyDQo+ID4gZDcNCj4gPiBjZDAxMWRiNDclN0MxJmFtcDtzZGF0YT1uOHJw NUVtb3dtNDU5aVNLb2xoSVAxaEZYQnM4cFpqc0dHMml5M09CQW5vJQ0KPiA+IDNEDQo+ID4gJmFt cDtyZXNlcnZlZD0wDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08aHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZkYXRhPTAxJTdDMDElN0No dWFueWklNDBtaWNyb3NvZnQuY29tJTdDYTA3NjNlODVmNTRmNDQzYjRjNTUwOGQ2ZDI2OWRlMWUl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEmc2RhdGE9Q3d2a1hxM3F3Ymgy THF3Q3BrQUZJSjIxSGtsM21wcm9JMndBJTJCUEh2WHVzJTNEJnJlc2VydmVkPTA+DQo= --_000_BL0PR2101MB1043893F691DED20889B3C45C3300BL0PR2101MB1043_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9u LiBUaGUgcHJvcG9zZWQgcmV2IG9mIHRoZSBzdGF0ZW1lbnQgaXMgbXVjaCBlYXNpZXIgdG8gdW5k ZXJzdGFuZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFl1Y2h1bmcgQ2hlbmcgJmx0O3ljaGVuZz00MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXkgNiwgMjAxOSAy OjI4IFBNPGJyPg0KPGI+VG86PC9iPiBZaSBIdWFuZyAmbHQ7aHVhbnlpQG1pY3Jvc29mdC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBZdWNodW5nIENoZW5nICZsdDt5Y2hlbmdAZ29vZ2xlLmNvbSZn dDs7IE1hdHQgT2xzb24gJmx0O21hb2xzb25AbWljcm9zb2Z0LmNvbSZndDs7IHRjcG1AaWV0Zi5v cmc7IE5lYWwgQ2FyZHdlbGwgJmx0O25jYXJkd2VsbEBnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW3RjcG1dIFF1ZXN0aW9ucyBhYm91dCBUTFA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4gRm9yZ2V0IHRvIGhpdCBz ZW5kIGFmdGVyIGRyYWZ0aW5nIHRoZSByZXBseS4uLjxicj4NCjxicj4NClRoYW5rcyBmb3Igc3Bv dHRpbmcgdGhhdC4gVENQX3NlbmRfcHJvYmUoKSBzaG91bGQgYWx3YXlzIHJlLWFybSB0aGU8YnI+ DQpSVE8gcmVnYXJkbGVzcyBvZiBhIFRMUCBpcyBzZW50IG9yIG5vdCwgaWYgdGhlcmUncyB1bmFj a25vd2xlZGdlZDxicj4NCmRhdGEuIFByb3Bvc2VkIHJldiBpbjxicj4NCjxicj4NCiZxdW90O05v dGUgdGhhdCB0aGUgc2VuZGVyIE1VU1QgYXJtIGFuIFJUTyB0aW1lciBhbmQgbm90IHRoZSBQVE8g dGltZXImbmJzcDs8dT5hdCB0aGUgZW5kIG9mIFRMUF9zZW5kX3Byb2JlKCkgYXMgbG9uZyBhcyBG bGlnaHRTaXplIGlzIG5vdCB6ZXJvLCByZWdhcmRsZXNzIG9mIHNlbmRpbmcgYSBwcm9iZSBvciBu b3Q8L3U+LiBUaGlzIGVuc3VyZXMgdGhhdCB0aGUgc2VuZGVyIGRvZXMgbm90IHNlbmQgcmVwZWF0 ZWQsIGJhY2stdG8tYmFjayBUTFAgcHJvYmVzLiZuYnNwOzx1PkFsc28NCiBjaGVja2luZyBUTFBS eHRPdXQgcHJpb3IgdG8gc2VuZGluZyB0aGUgbG9zcyBwcm9iZTwvdT4gaXMgaW1wb3J0YW50IHRv IGF2b2lkIFRMUCBsb29wcyBpZiBhbiBhcHBsaWNhdGlvbiB3cml0ZXMgcGVyaW9kaWNhbGx5IGF0 IGFuIGludGVydmFsIGxlc3MgdGhhbiBQVE8uJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbToNCjwvc3Bhbj48L3N0cm9uZz5ZaSBIdWFuZyAmbHQ7aHVhbnlpPTxhIGhyZWY9Im1h aWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1p Y3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RGF0ZTogPC9z cGFuPjwvc3Ryb25nPlRodSwgTWF5IDIsIDIwMTkgYXQgMTE6NDcgQU08YnI+DQo8c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRv OiA8L3NwYW4+PC9zdHJvbmc+WXVjaHVuZyBDaGVuZywgTWF0dCBPbHNvbjxicj4NCjxzdHJvbmc+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Q2M6IDwvc3Bhbj48L3N0cm9uZz48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBUTFBSeHRPdXQgaXMgY2hlY2tlZCBpbiBU TFBfc2VuZF9wcm9iZSgpLCBhIG5ldyBQVE8gY2FuIGNhbmNlbCBhbiBhbHJlYWR5IHJ1bm5pbmcg UlRPIHRpbWVyIGFybWVkIGJ5IHNlbmRpbmcgVExQIHByZXZpb3VzbHkuIElmIFRMUF9zZW5kX3By b2JlKCkgZGVjaWRlcyBub3QgdG8gc2VuZCB0aGUgcHJvYmUgZm9yIHRoZSBuZXcgUFRPLCB3aGF0 IHNob3VsZCB0aGUgc2VuZGVyIGRvIG5leHQ/IFJlYXJtIFJUTw0KIG9yIHRyZWF0IGl0IGFzIFJU TyB0aW1lb3V0PyBUaGUgZHJhZnQgc3RhdGVzIHdlIG11c3QgYXJtIGFuIFJUTyBhZnRlciB0cmFu c21pdHRpbmcgVExQIGJ1dCBpbiB0aGlzIGNhc2UsIG5vIHByb2JlIHdpbGwgYmUgc2VudC48YnI+ DQo8YnI+DQpBbHNvLCBpbiBwYWdlIDE3LCB0aGUgZHJhZnQgc2F5cyAmcXVvdDtUaGlzIGlzIGlt cG9ydGFudCB0byBhdm9pZCBUTFAgbG9vcHMgaWYgYW4gYXBwbGljYXRpb24gd3JpdGVzIHBlcmlv ZGljYWxseSBhdCBhbiBpbnRlcnZhbCBsZXNzIHRoYW4gUFRPLiZxdW90OyBidXQgaWYgdGhlIGFw cCB3cml0ZXMgcGVyaW9kaWNhbGx5IGF0IGFuIGludGVydmFsIGxlc3MgdGhhbiBQVE8sIFBUTyB3 aWxsIGp1c3QgYmUgcHVzaGVkIG91dCBhbmQgbm90IGZpcmUgdW50aWwgdGhlIHNlbmRlcg0KIGNh bm5vdCBzZW5kIGFueXRoaW5nIGR1ZSB0byB3aW5kb3cgbGltaXQuIFRoZW4gaW4gdGhpcyBjYXNl LCBUTFAgbG9vcHMgZG8gbm90IHNlZW0gdG8gZXhpc3QgaWYgVExQIGxvb3BzIG1lYW5zIGJhY2st dG8tYmFjayBUTFAgcHJvYmVzLiBBbSBJIG1pc3NpbmcgYW55dGhpbmcgaGVyZT88YnI+DQo8YnI+ DQpUaGFua3MsPGJyPg0KPGJyPg0KWWk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCkZyb206IFl1Y2h1bmcgQ2hlbmcgJmx0O3ljaGVuZz08YSBocmVmPSJtYWlsdG86 NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnPC9hPiZndDsNCjxicj4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMiwgMjAx OSAxMDoyNSBBTTxicj4NClRvOiBNYXR0IE9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFvbHNv bkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFvbHNvbkBtaWNyb3NvZnQuY29tPC9h PiZndDs8YnI+DQpDYzogWWkgSHVhbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpodWFueWlAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh1YW55aUBtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8 YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5v cmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQgVExQPGJyPg0K PGJyPg0KT24gVGh1LCBNYXkgMiwgMjAxOSBhdCAxMDowOSBBTSBNYXR0IE9sc29uICZsdDs8YSBo cmVmPSJtYWlsdG86bWFvbHNvbkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFvbHNv bkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgQWxzbywg c2VjdGlvbiA2LjUuMSBTdGVwIDEgaXMgcHJlc2VudGVkIGFzIGEgY29tcGxldGUgc2V0IG9mIGNv bmRpdGlvbnMgZm9yIHNjaGVkdWxpbmcgYSBQVE8sIGJ1dCBpdCBpcyBtaXNzaW5nIGEgYnVsbGV0 IHBvaW50IGZvciBUTFBSeHRPdXQuPGJyPg0KVGhhbmtzIGZvciBjaGVja2luZzogYnV0IGNoZWNr aW5nIFRMUFJ4dE91dCBpcyBub3QgbmVjZXNzYXJ5IGFuZCBpcyBub3QgcHJlZmVycmVkIHdoZW4g c2NoZWR1bGluZyBhIHByb2JlIC0tIHRoZSBnb2FsIGlzIHRvIHByZXZlbnQgbW9yZSB0aGFuIG9u ZSBwcm9iZSBpbmZsaWdodCwgc28gY2hlY2tpbmcgcmlnaHQgYmVmb3JlIFRMUFJ4dE91dCBzZW5k aW5nIHRoZSBuZXh0IG9uZSBhbGxvd3MgdGhlIGJlc3QgY292ZXJhZ2Ugb2YgYXBwbGljYXRpb24t bGltaXRlZA0KIHdyaXRlcyAoYnVyc3QtaWRsZS1idXJzdC0uLi4uKS48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgRnJvbTogWXVjaHVuZyBDaGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnljaGVuZ0Bn b29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+eWNoZW5nQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4N CiZndDsgU2VudDogV2VkbmVzZGF5LCBNYXkgMSwgMjAxOSAxMTozMyBQTTxicj4NCiZndDsgVG86 IFlpIEh1YW5nICZsdDtodWFueWk9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT47IE1hdHQgT2xzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptYW9sc29uQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW9sc29uQG1p Y3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlv bnMgYWJvdXQgVExQPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBNYXkgMSwgMjAxOSBhdCAx MDo0OCBQTSBZaSBIdWFuZyAmbHQ7aHVhbnlpPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSGkg UkFDSy9UTFAgYXV0aG9ycyw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBoYXZlIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zIChwYWdl IG51bWJlcnMgcmVmZXIgdG8gZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDUpOjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAxLkluIHBhZ2Ug MTYsIGl0IHNheXMg4oCcRmluYWxseSwgaWYgdGhlIHRpbWUgYXQgd2hpY2ggYW4gUlRPIHdvdWxk IGZpcmUgKGhlcmUgZGVub3RlZCAmcXVvdDtUQ1BfUlRPX2V4cGlyZSZxdW90OykgaXMgc29vbmVy IHRoYW4gdGhlIGNvbXB1dGVkIHRpbWUgZm9yIHRoZSBQVE8sIHRoZW4gYSBwcm9iZSBpcyBzY2hl ZHVsZWQgdG8gYmUgc2VudCBhdCB0aGF0IGVhcmxpZXIgdGltZS7igJ0gV2hhdCBkb2VzIHRoaXMg VENQX1JUT19leHBpcmUgYWN0dWFsbHkgbWVhbj8NCiBEb2VzIGl0IG1lYW4gdGhlcmUgaXMgYW5v dGhlciBSVE8gdGltZXIgKHBvc3NpYmx5IHN0YXJ0ZWQgc29tZSB0aW1lIGluIHRoZSBwYXN0KSBy dW5uaW5nIGFsb25nIHdpdGggUFRPIG9yIGp1c3QgUlRUICYjNDM7IDQqUlRUVmFyICYjNDM7IE5v dygpPyBBbHNvLCB3aHkgd291bGQgYW5vdGhlciBwcm9iZSBiZSBzZW50IGF0IFJUTyBleHBpcmF0 aW9uIHRpbWUgaW5zdGVhZCBvZiB0cmVhdGluZyBpdCBsaWtlIFJUTyBhbmQgY29sbGFwc2luZyB0 aGUgY3duZD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBUQ1BfUlRPX2V4cGlyZSgpIHNob3VsZCByZXR1 cm4gYSB0aW1lb3V0IHZhbHVlIGZvciByZWd1bGFyIFJUTywgaS5lLjxicj4NCiZndDsgU1JUVCAm IzQzOyA0KlJUVFZBUiAmIzQzOyBOb3coKTxicj4NCiZndDsgV2UgdXNlIFRDUF9SVE9fZXhwaXJl KCkgYmVjYXVzZSBtYW55IGltcGxlbWVudGF0aW9ucyBpbmNsdWRpbmcgTGludXggPGJyPg0KJmd0 OyBkbyBub3QgdXNlIHRoZSBleGFjdCBSRkMgZm9ybXVsYTxicj4NCiZndDs8YnI+DQomZ3Q7IFRo ZSByZWFzb24gaXQncyBub3QgdHJlYXRlZCBhcyBhIHJlZ3VsYXIgUlRPIGlzIHRvIGF2b2lkIHJl c2V0dGluZyBjb25nZXN0aW9uIHdpbmRvdyB0byAxLiBUaGUgcmF0aW9uYWxlIGlzIGlmIHRoZSBw cm9iZSB3YXMgc2VudCB3aXRoaW4gbWluKFBUTywgUlRPKSBhbmQgd2FzIGRlbGl2ZXJlZCBzdWNj ZXNzZnVsbHksIHRoZXJlJ3Mgbm8gbmVlZCB0byByZXNldCBjb25nZXN0aW9uIHdpbmRvdyBhbmQg cmUtc3RhcnQgc2xvdy1zdGFydCwgc2ltaWxhcg0KIHRvIHRoZSByYXRpb25hbGUgb2YgUmVubydz IGZhc3QgcmVjb3ZlcnkgcmVkdWNpbmcgd2luZG93IHRvIHNzdGhyZXNoIGluc3RlYWQgb2YgMS4g V2UgaGF2ZSBmb3VuZCB0aGlzIHN0cmF0ZWd5IGJlbmVmaXRzIHdpcmVsZXNzIGNvbm5lY3Rpb25z LCBhcyB0aGUgY2hhbmNlIG9mIHNwdXJpb3VzIFJUTyBpcyBoaWdoIGR1ZSB0byB0aGUgZGVsYXkg dmFyaWF0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgMi5JbiBwYWdlIDE4IHNlY3Rpb24gNi42LCBhIG5ldyB2 YXJpYWJsZSBUTFBSeHRPdXQgaXMgZGVmaW5lZCBhbmQgaXQgaXMgc3RhdGVkIHRoYXQgVExQUnh0 T3V0IGlzIHVzZWQgdG8gZ3VhcmFudGVlIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgb3V0c3RhbmRp bmcgVExQIHJldHJhbnNtaXNzaW9uLi4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdo ZW4gVExQUnh0T3V0IHNob3VsZCBiZSByZWFsbHkgdXNlZC4gU2hvdWxkIGl0IGJlDQogdXNlZCBp biA2LjUuMSBTdGVwLiAxIChjaGVja2luZyB3aGV0aGVyIHdlIHNob3VsZCBhbmQgY2FuIHNjaGVk dWxlIGEgVExQKSBvciBpbiBUTFBfc2VuZF9wcm9iZSgpPzxicj4NCiZndDs8YnI+DQomZ3Q7IFRo aXMgaXMgaW48YnI+DQomZ3Q7PGJyPg0KJmd0OyA2LjYuMi4mbmJzcDsgUmVjb3JkaW5nIGxvc3Mg cHJvYmUgc3RhdGVzPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7IFNlbmRlcnMgTVVT VCBvbmx5IHNlbmQgYSBUTFAgbG9zcyBwcm9iZSByZXRyYW5zbWlzc2lvbiBpZiBUTFBSeHRPdXQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpcyBmYWxzZS4mbmJzcDsgVGhpcyBlbnN1cmVzIHRoYXQg YXQgYW55IGdpdmVuIHRpbWUgYSBjb25uZWN0aW9uIGhhcyBhdDxicj4NCiZndDsmbmJzcDsgJm5i c3A7IG1vc3Qgb25lIG91dHN0YW5kaW5nIFRMUCByZXRyYW5zbWlzc2lvbi4mbmJzcDsgVGhpcyBh bGxvd3MgdGhlIHNlbmRlciB0bzxicj4NCiZndDs8YnI+DQomZ3Q7IGJ1dCBJIGFncmVlIGl0J2Qg YmUgbW9yZSBjbGVhciB0byBpbmNsdWRlIHRoaXMgaW4gVExQX3NlbmRfcHJvYmUoKSBwc2V1ZG8g Y29kZS4gSSdkIGluY29ycG9yYXRlIGluIHRoZSBuZXh0IHJldi48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhhbmtzLDxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBZaTxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgJmd0OyB0Y3BtIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86 dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG d3d3PC9hPi4uPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0Zi5vcmcmYW1wO2Rh dGE9MDElN0MwMSU3Q2h1YW55aSU0MG1pY3Jvc29mdC5jb20lN0NhMDc2M2U4NWY1NGY0NDNiNGM1 NTA4ZDZkMjY5ZGUxZSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSZhbXA7 c2RhdGE9UnpjS1g3bzVDNE1EZmFvdVRkMURQdlB0SFZvQXJTM05VVVAyMzZlSWQyWSUzRCZhbXA7 cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaWV0Zi5vcmc8L2E+JTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGdGNwbSZhbXA7YW1wO2RhdGE9MDElN0MwMSU3Q21hb2xzb24lNDBtaTxicj4NCiZn dDsgJmd0OyBjcjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRm9zb2Z0LmNvbSZhbXA7 ZGF0YT0wMSU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2EwNzYzZTg1ZjU0ZjQ0M2I0 YzU1MDhkNmQyNjlkZTFlJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJmFt cDtzZGF0YT1od2lZJTJCJTJCeW10Q3JpMlF4bHB6ZnpLVVExQmoyY2sySnFrWVRiZnBhUHB2RSUz RCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3NvZnQuY29tPC9hPiU3QzY2ZGI0 NDY3MmUzZDQxMDFkNzI5MDhkNmNlYzgyMDAxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyPGJyPg0K Jmd0OyAmZ3Q7IGQ3IDxicj4NCiZndDsgJmd0OyBjZDAxMWRiNDclN0MxJmFtcDthbXA7c2RhdGE9 bjhycDVFbW93bTQ1OWlTS29saElQMWhGWEJzOHBaanNHRzJpeTNPQkFubyU8YnI+DQomZ3Q7ICZn dDsgM0Q8YnI+DQomZ3Q7ICZndDsgJmFtcDthbXA7cmVzZXJ2ZWQ9MDxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRj cG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0wMSU3QzAxJTdDaHVhbnlpJTQwbWljcm9z b2Z0LmNvbSU3Q2EwNzYzZTg1ZjU0ZjQ0M2I0YzU1MDhkNmQyNjlkZTFlJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJmFtcDtzZGF0YT1Dd3ZrWHEzcXdiaDJMcXdDcGtBRklK MjFIa2wzbXByb0kyd0ElMkJQSHZYdXMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL0PR2101MB1043893F691DED20889B3C45C3300BL0PR2101MB1043_-- From nobody Tue May 7 09:52:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE901201C3 for ; Tue, 7 May 2019 09:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VkfXgbmFoHHp for ; Tue, 7 May 2019 09:52:22 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 D6DE812018A for ; Tue, 7 May 2019 09:52:21 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id y5so21037009wma.2 for ; Tue, 07 May 2019 09:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qMXYOnvuxZB2+iLCEh3jQ5HV35rhPMIhZoYw7erauOc=; b=fmiVfaYvh8VH34oZ7bJWVVywEScYzkISZgH90hxr9vjd7E1p4j1CvuTL3yjfzd6pNF pBW57zoWDi639D/VEB4/heDlHxgTJb74U1NehlMZ1TtfNIaRStv4tpYJWPrVHTx2x9KH NUVKwpUvYrjOYr7ojsPuaAke6nUmBHHAqxiQJLMFrfORZTH5NlJ/fpJrlUUGN173HEW+ fLyn9ufr8MNlOjJfIHtkYNYGX/kQR7QN4wWUyP1WCqxEyL//qg3/21CEJYYmWE4PB34L CKm7szzqUcTqxLvCun5VzyGeZq/CIrzf2UUG+mZpYfVekIOSZAodK2Ugrb1uS8tjLsQ3 srmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qMXYOnvuxZB2+iLCEh3jQ5HV35rhPMIhZoYw7erauOc=; b=HX4LZgACPOAtqknEf05sdFCaTfvQBmwmxWUB9QRoMinwofc+Rn5RNz9xrU0qs6wY7H P3BlFvuN++6CxKjjntRCcGIyhVAwAnrdocwuFgFnGXNO7fPQmD9Ktan2bZM6/VxGWHf5 oy06Mqfxl5YhFKXUfyPY/CxaIU0/iD1WwQ7vIAxgphipDFK6vtOarovP4VD6NNx6fqgo ptPtYllFqFl5mLKGEDYir4HoVo6iSZnvtLdmh09vfOxDeDRGna5C125xZrMAgIYENi5n MCHjfpKO+yUlTqneWEVW9BH9oU1N1ziEoDqUoT2OTxe3Q9JPlTVOBDRsyYyE7oeDwyWk M5zA== X-Gm-Message-State: APjAAAWFPlhbjl6FWm+QG+XtQw6L45LCy8wxMx4woIujYNe2oO8qVklE z8rUoj900dggQ8L+xSk5KxaNSzFBq+WiAFPNhrN74Q== X-Google-Smtp-Source: APXvYqzfbDSS/w8SImsC8RNUzTValf9ZHfUByEb3VBGADSzpXK0Av0c8SijP74Zqmw2mdxxbQtDkOusgnVIfrb+z/Q8= X-Received: by 2002:a05:600c:2101:: with SMTP id u1mr11790706wml.36.1557247939749; Tue, 07 May 2019 09:52:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Tue, 7 May 2019 09:52:07 -0700 Message-ID: To: Yi Huang Cc: Yuchung Cheng , Matt Olson , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004728ee05884f0a6f" Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 16:52:27 -0000 --0000000000004728ee05884f0a6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review as well! *From: *Yi Huang *Date: *Thu, May 2, 2019, 11:47 AM *To: *Yuchung Cheng, Matt Olson *Cc: *tcpm@ietf.org If TLPRxtOut is checked in TLP_send_probe(), a new PTO can cancel an > already running RTO timer armed by sending TLP previously. If > TLP_send_probe() decides not to send the probe for the new PTO, what shou= ld > the sender do next? Rearm RTO or treat it as RTO timeout? The draft state= s > we must arm an RTO after transmitting TLP but in this case, no probe will > be sent. > > Also, in page 17, the draft says "This is important to avoid TLP loops if > an application writes periodically at an interval less than PTO." but if > the app writes periodically at an interval less than PTO, PTO will just b= e > pushed out and not fire until the sender cannot send anything due to wind= ow > limit. Then in this case, TLP loops do not seem to exist if TLP loops mea= ns > back-to-back TLP probes. Am I missing anything here? > > Thanks, > > Yi > > -----Original Message----- > From: Yuchung Cheng > Sent: Thursday, May 2, 2019 10:25 AM > To: Matt Olson > Cc: Yi Huang ; tcpm@ietf.org > Subject: Re: [tcpm] Questions about TLP > > On Thu, May 2, 2019 at 10:09 AM Matt Olson wrote: > > > > Also, section 6.5.1 Step 1 is presented as a complete set of conditions > for scheduling a PTO, but it is missing a bullet point for TLPRxtOut. > Thanks for checking: but checking TLPRxtOut is not necessary and is not > preferred when scheduling a probe -- the goal is to prevent more than one > probe inflight, so checking right before TLPRxtOut sending the next one > allows the best coverage of application-limited writes > (burst-idle-burst-....). > > > > > > > > -----Original Message----- > > From: Yuchung Cheng > > Sent: Wednesday, May 1, 2019 11:33 PM > > To: Yi Huang > > Cc: tcpm@ietf.org; Matt Olson > > Subject: Re: [tcpm] Questions about TLP > > > > On Wed, May 1, 2019 at 10:48 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > > > > > > Hi RACK/TLP authors, > > > > > > > > > > > > I have the following questions (page numbers refer to > draft-ietf-tcpm-rack-05): > > > > > > > > > > > > 1.In page 16, it says =E2=80=9CFinally, if the time at which an RTO w= ould fire > (here denoted "TCP_RTO_expire") is sooner than the computed time for the > PTO, then a probe is scheduled to be sent at that earlier time.=E2=80=9D = What does > this TCP_RTO_expire actually mean? Does it mean there is another RTO time= r > (possibly started some time in the past) running along with PTO or just R= TT > + 4*RTTVar + Now()? Also, why would another probe be sent at RTO expirati= on > time instead of treating it like RTO and collapsing the cwnd? > > > > TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > > SRTT + 4*RTTVAR + Now() > > We use TCP_RTO_expire() because many implementations including Linux > > do not use the exact RFC formula > > > > The reason it's not treated as a regular RTO is to avoid resetting > congestion window to 1. The rationale is if the probe was sent within > min(PTO, RTO) and was delivered successfully, there's no need to reset > congestion window and re-start slow-start, similar to the rationale of > Reno's fast recovery reducing window to ssthresh instead of 1. We have > found this strategy benefits wireless connections, as the chance of > spurious RTO is high due to the delay variation. > > > > > > > > > > > > > > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it > is stated that TLPRxtOut is used to guarantee that there is only one > outstanding TLP retransmission.. However, it is not clear to me when > TLPRxtOut should be really used. Should it be used in 6.5.1 Step. 1 > (checking whether we should and can schedule a TLP) or in TLP_send_probe(= )? > > > > This is in > > > > 6.6.2. Recording loss probe states > > > > Senders MUST only send a TLP loss probe retransmission if TLPRxtOut > > is false. This ensures that at any given time a connection has at > > most one outstanding TLP retransmission. This allows the sender to > > > > but I agree it'd be more clear to include this in TLP_send_probe() > pseudo code. I'd incorporate in the next rev. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Yi > > > > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > .. > > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D01%7C01%7Cmaolson%40m= i > > > cr > > > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2 > > > d7 > > > cd011db47%7C1&sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2iy3OBAno= % > > > 3D > > > &reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000004728ee05884f0a6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review as well!

From: Yi H= uang <huanyi=3D40microsoft.com@dmarc.ietf.org>
Date: <= /strong>Thu, May 2, 2019, 11:47 AM
To: Yuchung Cheng, M= att Olson
Cc: tcpm@iet= f.org

If TLPRxtOut is check= ed in TLP_send_probe(), a new PTO can cancel an already running RTO timer a= rmed by sending TLP previously. If TLP_send_probe() decides not to send the= probe for the new PTO, what should the sender do next? Rearm RTO or treat = it as RTO timeout? The draft states we must arm an RTO after transmitting T= LP but in this case, no probe will be sent.

Also, in page 17, the draft says "This is important to avoid TLP loops= if an application writes periodically at an interval less than PTO." = but if the app writes periodically at an interval less than PTO, PTO will j= ust be pushed out and not fire until the sender cannot send anything due to= window limit. Then in this case, TLP loops do not seem to exist if TLP loo= ps means back-to-back TLP probes. Am I missing anything here?

Thanks,

Yi

-----Original Message-----
From: Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org&g= t;
Sent: Thursday, May 2, 2019 10:25 AM
To: Matt Olson <maolson@microsoft.com>
Cc: Yi Huang <huanyi@microsoft.com>; tcpm@ietf.org
Subject: Re: [tcpm] Questions about TLP

On Thu, May 2, 2019 at 10:09 AM Matt Olson <maolson@microsoft.com= > wrote:
>
> Also, section 6.5.1 Step 1 is presented as a complete set of condition= s for scheduling a PTO, but it is missing a bullet point for TLPRxtOut.
Thanks for checking: but checking TLPRxtOut is not necessary and is not pre= ferred when scheduling a probe -- the goal is to prevent more than one prob= e inflight, so checking right before TLPRxtOut sending the next one allows = the best coverage of application-limited writes (burst-idle-burst-....).



>
> -----Original Message-----
> From: Yuchung Cheng <ycheng@google.com>
> Sent: Wednesday, May 1, 2019 11:33 PM
> To: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
> Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>
> Subject: Re: [tcpm] Questions about TLP
>
> On Wed, May 1, 2019 at 10:48 PM Yi Huang <huanyi=3D40mi= crosoft.com@dmarc.ietf.org> wrote:
> >
> > Hi RACK/TLP authors,
> >
> >
> >
> > I have the following questions (page numbers refer to draft-ietf-= tcpm-rack-05):
> >
> >
> >
> > 1.In page 16, it says =E2=80=9CFinally, if the time at which an R= TO would fire (here denoted "TCP_RTO_expire") is sooner than the = computed time for the PTO, then a probe is scheduled to be sent at that ear= lier time.=E2=80=9D What does this TCP_RTO_expire actually mean? Does it me= an there is another RTO timer (possibly started some time in the past) runn= ing along with PTO or just RTT + 4*RTTVar + Now()? Also, why would another = probe be sent at RTO expiration time instead of treating it like RTO and co= llapsing the cwnd?
>
> TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > SRTT + 4*RTTVAR + Now()
> We use TCP_RTO_expire() because many implementations including Linux <= br> > do not use the exact RFC formula
>
> The reason it's not treated as a regular RTO is to avoid resetting= congestion window to 1. The rationale is if the probe was sent within min(= PTO, RTO) and was delivered successfully, there's no need to reset cong= estion window and re-start slow-start, similar to the rationale of Reno'= ;s fast recovery reducing window to ssthresh instead of 1. We have found th= is strategy benefits wireless connections, as the chance of spurious RTO is= high due to the delay variation.
>
> >
> >
> >
> > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and= it is stated that TLPRxtOut is used to guarantee that there is only one ou= tstanding TLP retransmission.. However, it is not clear to me when TLPRxtOu= t should be really used. Should it be used in 6.5.1 Step. 1 (checking wheth= er we should and can schedule a TLP) or in TLP_send_probe()?
>
> This is in
>
> 6.6.2.=C2=A0 Recording loss probe states
>
>=C2=A0 =C2=A0 Senders MUST only send a TLP loss probe retransmission if= TLPRxtOut
>=C2=A0 =C2=A0 is false.=C2=A0 This ensures that at any given time a con= nection has at
>=C2=A0 =C2=A0 most one outstanding TLP retransmission.=C2=A0 This allow= s the sender to
>
> but I agree it'd be more clear to include this in TLP_send_probe()= pseudo code. I'd incorporate in the next rev.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Yi
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://= nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww..
> > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D01%7C01= %7Cmaolson%40mi
> > cr
> > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f1= 41af91ab2
> > d7
> > cd011db47%7C1&amp;sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2= iy3OBAno%
> > 3D
> > &amp;reserved=3D0
_______________________________________________
tcpm mailing list
tcpm@= ietf.org
https://www.ietf.org/mailman/listinfo/tcpm<= br>
--0000000000004728ee05884f0a6f-- From nobody Wed May 8 06:30:49 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52E120273; Wed, 8 May 2019 06:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 L5_byfRkLiqT; Wed, 8 May 2019 06:30:38 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80087.outbound.protection.outlook.com [40.107.8.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C77412024E; Wed, 8 May 2019 06:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=laneAeCZKDz90HhHSQivw6frMoAnJW0Z/MTISZ5xdGo=; b=aIiNqt2HWL5Gw5u1MM+hFvmPgWsYImVJBUFSvhiH5WYiI+fvHsSUANrE6mS1ApaeucFjuhijDkuUXOOgh5iwwVlAjKPILqNwyXmXb6vrJTudf0vriLWN8x+BSjparq6WAn/8cByt/UyZegLXWEI4wDFaMJD7uFpAH2o9jKNCOmQ= Received: from HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4188.eurprd07.prod.outlook.com (20.176.166.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.18; Wed, 8 May 2019 13:30:35 +0000 Received: from HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35%5]) with mapi id 15.20.1878.019; Wed, 8 May 2019 13:30:35 +0000 From: Ingemar Johansson S To: "tcpm@ietf.org" , "lwip@ietf.org" CC: Ingemar Johansson S Thread-Topic: WGLC review of draft-ietf-lwig-tcp-constrained-node-networks Thread-Index: AdUFoNWJ0yX8rjm/R0SxdahRUHAdrA== Date: Wed, 8 May 2019 13:30:35 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 787656f5-d619-411c-1f48-08d6d3b95a4a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4188; x-ms-traffictypediagnostic: HE1PR07MB4188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(376002)(366004)(136003)(189003)(199004)(55016002)(14454004)(52536014)(110136005)(86362001)(33656002)(71200400001)(71190400001)(2906002)(26005)(450100002)(53936002)(99936001)(25786009)(8936002)(256004)(6306002)(54896002)(8676002)(9686003)(316002)(73956011)(76116006)(4326008)(66946007)(64756008)(66556008)(66476007)(66616009)(66446008)(81156014)(81166006)(478600001)(74316002)(2501003)(6436002)(107886003)(66066001)(68736007)(66574012)(99286004)(186003)(7736002)(476003)(7696005)(486006)(6116002)(3846002)(102836004)(5660300002)(6506007)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4188; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5PwIiSWwB2H18CLlD9yDCE0fXS3ywM5KXNtvawcP0LUR+CxkTpWb2B0Ii0dkZ5u0ZFLQaCbEWip+nlaqPKE5HljyuLo/7ajaVBEm2rDJnyw74LCCjqVXQGjLxZIJXg1b2wXgd3U0Gk8Qo1pj+Ka6oL9wuNcI3mt95AwD94xDD2GUgUiJqd5CeggmPxPuQ5QMBZtrtW48GR/PguCxkS1cVbbVqDPCO9Xlnmtfmesfv+AN7YqckKbgyHDdhMOooTck33MXJboeU5lfD3c7CQhgacdMzHTP7QY+MQmpTASySdckP6WNjgHnUmzY91JQoS9kQkJ0A4JAYLSm/NAEjAdsyBJqC5AEDWT1+zE5mvc0Jm8sNU+sVbGCqRkf07vNHwUfJLLhPjIvT0sUQXftQgnfUMelY+hKqKJlvinyrg2MfY4= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_07FD_01D505B2.FA541670" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 787656f5-d619-411c-1f48-08d6d3b95a4a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 13:30:35.4502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4188 Archived-At: Subject: [tcpm] WGLC review of draft-ietf-lwig-tcp-constrained-node-networks X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 13:30:48 -0000 ------=_NextPart_000_07FD_01D505B2.FA541670 Content-Type: multipart/alternative; boundary="----=_NextPart_001_07FE_01D505B2.FA541670" ------=_NextPart_001_07FE_01D505B2.FA541670 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I hope that I am not too late with the review.=20 Perhaps this has been brought up earlier, and it that is the case then = sorry for kicking in open doors. =20 I have read but to not seen any mention of the initial congestion window size. Today the initial window in most TCP stacks is set to 10*MSS and = this may well be used by Nb-IoT implementers that are unaware of default settings. While this is likely not an issue if he applications transmit small = objects that fit in a few segments, it can become an issue with larger object transfers and if a burst of 14600 bytes overflows a tiny network buffer. Should this be addressed, possibly with a recommendation to adjust the initial window based on network constraints ?=20 =20 /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc.=20 Master Researcher =20 Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com =20 Nothing to stop this being the best day ever U2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 ------=_NextPart_001_07FE_01D505B2.FA541670 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I hope that I am not too late with the review. =

Perhaps = this has been brought up earlier, and it that is the case then sorry for = kicking in open doors.

 

I have read but to not seen any mention of the initial = congestion window size. Today the initial window in most TCP stacks is = set to 10*MSS and this may well be used by Nb-IoT implementers that are = unaware of default settings.

While this is likely not an issue = if he applications transmit small objects that fit in a few segments, it = can become an issue with larger object transfers and if a burst of 14600 = bytes overflows a tiny network buffer.

Should this be addressed, possibly = with a recommendation to adjust the initial window based on network = constraints ?

 

/Ingemar

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Ingemar Johansson=A0 M.Sc. =

Master = Researcher

 

Ericsson = Research

Network Protocols & E2E = Performance

Labratoriegr=E4nd = 11

971 28, Lule=E5, = Sweden

Phone +46-1071 = 43042

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

<= p class=3DMsoNormal style=3D'text-autospace:none'> 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Nothing to stop this

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = being the best day ever

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 U2

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

------=_NextPart_001_07FE_01D505B2.FA541670-- ------=_NextPart_000_07FD_01D505B2.FA541670 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVfDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGDTCCA/WgAwIBAgIQ Us79UtuT8yEU6XIq+TroQjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTI3 MTAxMzQ4WhcNMjAxMTI3MTAxMzQ3WjB0MREwDwYDVQQKDAhFcmljc3NvbjEcMBoGA1UEAwwTSW5n ZW1hciBKb2hhbnNzb24gUzEvMC0GCSqGSIb3DQEJARYgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20xEDAOBgNVBAUTB0VQTElKT0gwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCvxK7X3xRTAzY+JaEVXSFcykcRDnb9xJCcMYXRb7WCh0HpVZ7PThGgp0ZUNQQJ9ypm7YcIcwRD kYdD4fgxGLU1bIUC4GcH7rKiuf93b+Ec3jsrkSEkCsXkO7ROjlS9+7y7H/qC8bB8D4CTQNs15o3J 0njOaYngdmLGb8bwYV47hv3sAiyqoY0aZeGZyk2a/D9Kc28b+towJxQrGnekMxynyQQesKF7mFaA gtlEa5bNbLEfIki5tZWceSZEd5xXxuib7vv0Rb/Gd+Q+jyvobAEyd5RDB6i9HAA/FFPZIJTgM+k9 7yIFPPhpLjjcjeowqH9PlEaody2drdP67tBDnNQTAgMBAAGjggHGMIIBwjBIBgNVHR8EQTA/MD2g O6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMu Y3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxp YS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNlcjArBgNVHREEJDAigSBpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRw czovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEF BQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFH5/jYsQz4BrrLa7pwQSkqtzL4EOMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEA uwe9UtkD6Q6/dW/uQOCxTOaGCX76lOy+a0Fqlyh+ZmlS8qWj8YTCtD866gJOXMzYUMVFrWoeggvP 9j/MBmkDDuuJMgCkN3TEuAu4AF9ekcbm/yjWOUFx3kje0SYL+GNwN50He1tuOlmHrsHo7S89kOL6 Pq8+QMRSESzEqva7nC6sJdYxXGyWAagM1ZWFnJTtFCzsW6Tm6P6rpit4yCPYvPSgNPhPRj7UbHon vU4uwGBiO15aKLwg0jfoJn6wF/CZqtGeza+ucmcuEKA+y/IRnQ2pA5+p3QnX41eypQ7OJfCG5U6k fXjxyu7PGMompQQutZk75tw76wvE8kWj5VpDNf0dRVhq/PQugzqiRjrF5tFSQbOnq1GGQ4X3PhJ8 TBaoC4otM95ZguVQrM8wdYMSxeinbJY4T91eVXYltNgtUd84zbmL/1JgVa7PN3wASXPhguc0WZu3 OWNn31yKlqL/QmgDEoOs8UsNqYU7ngsg620TE9tta4S96LXRhXhBiQCDKR16ZhEITbaJPT7KgoMO 30YCHQa0K7ah5UxC9S6+E6cPK+uKyHvzXzjNdILMh6DXQFMblld6ax+to7tQQEkv1Xr4tjCN2H/z elNX2LGB1lO2qra3MfgaENY5SMk6sIi4Y4QDrVEBnrZeKstS9Qd3TCvc+fHu6bt3wU9Tk3K0dOAw ggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoM C1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEy MTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOC Ag8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM3 0k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5 S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT 05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PV tO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBs bpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUO xSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT 9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx 5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9z aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1Ud EwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYs aHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBA oD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3Rj YXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0G A1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuq F+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhlto FS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBAR xr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55d rdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPg vLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+ i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GI Tb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5m dZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeC aPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xOTA1MDgxMzMwMzNaMCMGCSqGSIb3DQEJBDEWBBSzaStGLzSXCbYxY4kp HBRWWAj07TBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQUs79 UtuT8yEU6XIq+TroQjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhBSzv1S25Pz IRTpcir5OuhCMA0GCSqGSIb3DQEBAQUABIIBAAGDMqYSIJx3pds9/rZInjqt2oUh6kWk4Q3IM1tL Lw6KHccI+EYt+v6DW0FERRsLy702D0qWVhu0KzybOhDZq0g/HwdS1Q7Nf6xIxmlHasmKeqQJ548O vmntO365pUy7WXrFs4Xa0RCaKgl2+L5zD4DUl5wsQ8uft+an5x2YnlOgIpHC6JfDH+t3QJr7xpFp tsQ8GaSDDbITZmJV2mVpmRHF7dp/U8ZMzISf3oC4qX5/eQrHhjwbK0QG8Lvp/Fd/VJg6DQyrNNkL uc+PzDufBtuKb3Lrg9T0uCFYAP3oOpTu94WVCAuSue7e//tD/ItdBmwWtnh7lqU5Tf0YyrJtU30A AAAAAAA= ------=_NextPart_000_07FD_01D505B2.FA541670-- From nobody Wed May 8 17:19:44 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B121201DB for ; Wed, 8 May 2019 17:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.602 X-Spam-Level: * X-Spam-Status: No, score=1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 8D9MVqUb2XvQ for ; Wed, 8 May 2019 17:19:40 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820095.outbound.protection.outlook.com [40.107.82.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53C11201CC for ; Wed, 8 May 2019 17:19:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=XcHn4KqsWRTIKm/IUNNbaVCgT2dTuI2DWD5np9Wx3tUZ+v1XwBaSvDjg3TnAUG+q8sQfYgtOojfec+BVfviE0Geo4rDMnQ0QNrvcc7qyaolSiZiiRPrgtvMBaZrSk1CPVFFlYtQGLRvZrYzMC/rE5a/+Zs+AG/GEQnyPfUjTFzQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qW/QpLZ1/ezRgjJWnwxWwDNDHt4rYQHgsefWGQWeYwQ=; b=P1dLSAstxZJqHqeoy5lArGpRriCOncZ/1MZEIywk4AEoPKespbGvnYSIUm/XrIbxHRK8fy2dzP9nlStAssxsVz6+9OMUTw+LHFQiMk25+4Y2b0Jq+PGMn8HxlV/Z5ZWQDS3hxP2jpGxwiNpW8tmNjptGk7Z9QMvAF3gM8oKREfw= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qW/QpLZ1/ezRgjJWnwxWwDNDHt4rYQHgsefWGQWeYwQ=; b=HwcPLyh80q80i9nDxhE1IYJe24SruzjLsWRuQ9JvAfEsweaXLsecnivNAHAb3YFC/BXaIW605hiwjsfY3odsnjCHEOpP62eipRRunRLTPB0b9fph7/BcH8vJnD7GQhpvty2mg9paLZXFnLBrWVO/405SOao9W4WoVeTI2pv8DmE= Received: from BL0PR2101MB1043.namprd21.prod.outlook.com (52.132.24.13) by BL0PR2101MB1059.namprd21.prod.outlook.com (52.132.24.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.3; Thu, 9 May 2019 00:19:37 +0000 Received: from BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::2056:cdb6:e2aa:e45a]) by BL0PR2101MB1043.namprd21.prod.outlook.com ([fe80::2056:cdb6:e2aa:e45a%9]) with mapi id 15.20.1900.002; Thu, 9 May 2019 00:19:37 +0000 From: Yi Huang To: Yuchung Cheng CC: Yuchung Cheng , Matt Olson , "tcpm@ietf.org" Thread-Topic: [tcpm] Questions about TLP Thread-Index: AdUAqnPmaX0KgH/WQE+MIFBj5gEdQgABnF8AABYYoqAAAK0mgAACL/RQAPgeBYAAQdDQAA== Date: Thu, 9 May 2019 00:19:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-09T00:19:35.8716685Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=5092bb3e-39ee-4ee2-acde-fb70eba0073c; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-originating-ip: [2001:4898:80e8:2:c52:a508:8c4c:b31e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 013575a7-2491-4e9f-a942-08d6d4140577 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BL0PR2101MB1059; x-ms-traffictypediagnostic: BL0PR2101MB1059: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(136003)(346002)(376002)(13464003)(199004)(189003)(51914003)(790700001)(6116002)(4326008)(46003)(186003)(2906002)(52536014)(73956011)(486006)(66446008)(64756008)(66556008)(66476007)(66946007)(11346002)(446003)(476003)(25786009)(6436002)(8990500004)(54906003)(5660300002)(68736007)(74316002)(14444005)(99286004)(256004)(76176011)(9686003)(53546011)(236005)(7696005)(55016002)(102836004)(6306002)(54896002)(10090500001)(6506007)(8676002)(81166006)(81156014)(53936002)(9326002)(8936002)(10290500003)(76116006)(7736002)(6246003)(71190400001)(71200400001)(86612001)(86362001)(22452003)(316002)(33656002)(229853002)(966005)(14454004)(478600001)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1059; H:BL0PR2101MB1043.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vAFhh3wEbMZ/5PrhAUBiRvEGNM/bvUwQ2RZEhv0I4VXYg4BcfHKZJZ6rRcXHc83Sq2F6NTGyeNYwkHZYfqEmNlxVRhcQ3OcmXKm/7vDqbX7qqJ9tXwaSCeg8SuAZUMDOU3w+FD9wUL8z5XargYtbf0zmN8zccNhgJeeMuNBB03QR0bejGllWpof2dPraBXPrE/YrYgBOnai0zBuSVFRywZsnD1zF0iOYM6emSItJqvgPqSetYZ75JKovBJh9zBGyFTy0gQLaWB8YHVQuyywgAKBPIR78mksDgQdCWiw6drM57jr4r0HS3FGLKn8KN9P9m2jbn31Z+lE92TQSVwiZrfY/VAPz01Z1knCItILCw8nWRO+GZbfTMT9icaSmNR5+x9z/rhRwoJfiKri+6cDOVkxvl/Y5EVamT7v1npSxR2M= Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB104398C390A677A41F52E075C3330BL0PR2101MB1043_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 013575a7-2491-4e9f-a942-08d6d4140577 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 00:19:37.3647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1059 Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 00:19:42 -0000 --_000_BL0PR2101MB104398C390A677A41F52E075C3330BL0PR2101MB1043_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWXVjaHVuZywNCg0KSSBoYXZlIG9uZSBtb3JlIHF1ZXN0aW9uIHJlZ2FyZGluZyB0byBUTFAg YW5kIHRoZSBwcm9wb3NlZCByZXYuIFNvIGR1cmluZyBhIHBvc3QtVExQIFJUTywgaWYgdGhlIGFw cGxpY2F0aW9uIHdyaXRlcyBzb21ldGhpbmcgYmVmb3JlIHRoaXMgUlRPIGZpcmVzLCB0aGUgc2Vu ZGVyIHdpbGwgc3RpbGwgdHJ5IHRvIHNjaGVkdWxlIFBUTywgd2hpY2ggc2hvdWxkIGNhbmNlbCB0 aGUgYWxyZWFkeSBydW5uaW5nIFJUTy4gV2hlbiB0aGlzIG5ldyBQVE8gZmlyZXMsIHNpbmNlIFRM UFJ4dE91dCBpcyB0cnVlIGR1ZSB0aGUgcHJldmlvdXMgVExQIHNlbnQsIHRoZSBzZW5kZXIgd2ls bCBub3Qgc2VuZCBhbm90aGVyIFRMUCBidXQgcmVhcm0gUlRPIHRpbWVyLiBJcyB0aGlzIHRydWU/ IElmIHNvIGFuZCBhbiBhcHAgYWx3YXlzIHdyaXRlcyBkYXRhIGluIHN1Y2ggYSBwYXR0ZXJuIGFu ZCBubyBBQ0tzIGFyZSBjb21pbmcgYmFjayBkdWUgdG8gbmV0d29yayBmYWlsdXJlLCBSVE8gd2ls bCBiZSBwb3N0cG9uZWQgaW5maW5pdGVseSB1bnRpbCB0aGUgd2luZG93IGxpbWl0IGlzIHJlYWNo ZWQ/IE15IG1haW4gY29uY2VybiBpcyB0aGF0IHdlIGNvdWxkIGhhdmUgZGV0ZWN0ZWQgdGhlIG5l dHdvcmsgZmFpbHVyZSB2ZXJ5IGVhcmx5LiBJdCBzZWVtcyBsaWtlIHRoZSBjdXJyZW50IGFsZ29y aXRobSBtaWdodCBjYXVzZSBkZWxheXMgaW4gdGVhcmluZyBkb3duIHRoZSBjb25uZWN0aW9uIGRl cGVuZGluZyBvbiBhcHAgc2VuZCBiZWhhdmlvci4NCg0KQSBzZXF1ZW5jZSB0byBoZWxwIGlsbHVz dHJhdGUgdGhlIHByb2JsZW0gSSBtZW50aW9uZWQgYW5kIGFzc3VtZSBubyBBQ0tzIHdpbGwgYmUg cmVjZWl2ZWQgZHVlIHRvIG5ldHdvcmsgZmFpbHVyZSBkdXJpbmcgc28uDQpBcHAgd3JpdGVzLT5h cm0gUFRPLT5QVE8gZmlyZXMtPlRMUC0+YXJtIFJUTy0+YXBwIHdyaXRlcy0+YXJtIFBUTy0+UFRP IGZpcmVzLT5hcm0gUlRPLT5hcHAgd3JpdGVzLT5hcm0gUFRPLT5QVE8gZmlyZXMtPmFybSBSVE/i gKYNCg0KQWxzbywgdGhlIHByb3Bvc2VkIHJldiBzYXlzIOKAnEFsc28gY2hlY2tpbmcgVExQUnh0 T3V0IHByaW9yIHRvIHNlbmRpbmcgdGhlIGxvc3MgcHJvYmUgaXMgaW1wb3J0YW50IHRvIGF2b2lk IFRMUCBsb29wcyBpZiBhbiBhcHBsaWNhdGlvbiB3cml0ZXMgcGVyaW9kaWNhbGx5IGF0IGFuIGlu dGVydmFsIGxlc3MgdGhhbiBQVE8u4oCdLiBJZiBhbiBhcHAgd3JpdGVzIHBlcmlvZGljYWxseSBh dCBhbiBpbnRlcnZhbCBsZXNzIHRoYW4gUFRPLCB0aGUgc2VuZGVyIHdpbGwganVzdCBwZXJpb2Rp Y2FsbHkgcG9zdHBvbmUgUFRPIHVudGlsIHdpbmRvdyBsaW1pdCBpcyByZWFjaGVkIHNpbmNlIGVh Y2ggdGltZSB0aGUgYXBwIHdyaXRlcyBkYXRhLCBhIG5ldyBQVE8gd2lsbCBiZSBzY2hlZHVsZWQg YW5kIGNhbmNlbCB0aGUgZXhpc3Rpbmcgb25lLiBJIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCBo b3cgdGhpcyBhcHAgYmVoYXZpb3IgaXMgcmVsYXRlZCB0byByZXBlYXRlZCBiYWNrLXRvLWJhY2sg VExQcyBwcm9ibGVtIGNhdXNlZCBieSBhcm1pbmcgUFRPIGFmdGVyIHNlbmRpbmcgVExQLiBCdHcs IOKAnFRMUCBsb29wc+KAnSBsb29rcyBsaWtlIGEgYnJhbmQgbmV3IHRlcm0gdXNlZCBvbmx5IGlu IHRoaXMgcGFyYWdyYXBoLg0KDQpUaGFua3MsDQoNCllpDQoNCg0KRnJvbTogWXVjaHVuZyBDaGVu ZyA8eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1h eSA3LCAyMDE5IDk6NTIgQU0NClRvOiBZaSBIdWFuZyA8aHVhbnlpQG1pY3Jvc29mdC5jb20+DQpD YzogWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb20+OyBNYXR0IE9sc29uIDxtYW9sc29u QG1pY3Jvc29mdC5jb20+OyB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RjcG1dIFF1ZXN0 aW9ucyBhYm91dCBUTFANCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFzIHdlbGwhDQoNCkZyb206 IFlpIEh1YW5nIDxodWFueWk9NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MG1pY3Jvc29mdC5jb21AZG1hcmMuLmlldGYub3JnPj4NCkRhdGU6IFRodSwgTWF5IDIsIDIwMTks IDExOjQ3IEFNDQpUbzogWXVjaHVuZyBDaGVuZywgTWF0dCBPbHNvbg0KQ2M6IHRjcG1AaWV0Zi5v cmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpJZiBUTFBSeHRPdXQgaXMgY2hlY2tlZCBpbiBUTFBf c2VuZF9wcm9iZSgpLCBhIG5ldyBQVE8gY2FuIGNhbmNlbCBhbiBhbHJlYWR5IHJ1bm5pbmcgUlRP IHRpbWVyIGFybWVkIGJ5IHNlbmRpbmcgVExQIHByZXZpb3VzbHkuIElmIFRMUF9zZW5kX3Byb2Jl KCkgZGVjaWRlcyBub3QgdG8gc2VuZCB0aGUgcHJvYmUgZm9yIHRoZSBuZXcgUFRPLCB3aGF0IHNo b3VsZCB0aGUgc2VuZGVyIGRvIG5leHQ/IFJlYXJtIFJUTyBvciB0cmVhdCBpdCBhcyBSVE8gdGlt ZW91dD8gVGhlIGRyYWZ0IHN0YXRlcyB3ZSBtdXN0IGFybSBhbiBSVE8gYWZ0ZXIgdHJhbnNtaXR0 aW5nIFRMUCBidXQgaW4gdGhpcyBjYXNlLCBubyBwcm9iZSB3aWxsIGJlIHNlbnQuDQoNCkFsc28s IGluIHBhZ2UgMTcsIHRoZSBkcmFmdCBzYXlzICJUaGlzIGlzIGltcG9ydGFudCB0byBhdm9pZCBU TFAgbG9vcHMgaWYgYW4gYXBwbGljYXRpb24gd3JpdGVzIHBlcmlvZGljYWxseSBhdCBhbiBpbnRl cnZhbCBsZXNzIHRoYW4gUFRPLiIgYnV0IGlmIHRoZSBhcHAgd3JpdGVzIHBlcmlvZGljYWxseSBh dCBhbiBpbnRlcnZhbCBsZXNzIHRoYW4gUFRPLCBQVE8gd2lsbCBqdXN0IGJlIHB1c2hlZCBvdXQg YW5kIG5vdCBmaXJlIHVudGlsIHRoZSBzZW5kZXIgY2Fubm90IHNlbmQgYW55dGhpbmcgZHVlIHRv IHdpbmRvdyBsaW1pdC4gVGhlbiBpbiB0aGlzIGNhc2UsIFRMUCBsb29wcyBkbyBub3Qgc2VlbSB0 byBleGlzdCBpZiBUTFAgbG9vcHMgbWVhbnMgYmFjay10by1iYWNrIFRMUCBwcm9iZXMuIEFtIEkg bWlzc2luZyBhbnl0aGluZyBoZXJlPw0KDQpUaGFua3MsDQoNCllpDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBZdWNodW5nIENoZW5nIDx5Y2hlbmc9NDBnb29nbGUuY29tQGRt YXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDog VGh1cnNkYXksIE1heSAyLCAyMDE5IDEwOjI1IEFNDQpUbzogTWF0dCBPbHNvbiA8bWFvbHNvbkBt aWNyb3NvZnQuY29tPG1haWx0bzptYW9sc29uQG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFlpIEh1YW5n IDxodWFueWlAbWljcm9zb2Z0LmNvbTxtYWlsdG86aHVhbnlpQG1pY3Jvc29mdC5jb20+PjsgdGNw bUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdGNwbV0gUXVl c3Rpb25zIGFib3V0IFRMUA0KDQpPbiBUaHUsIE1heSAyLCAyMDE5IGF0IDEwOjA5IEFNIE1hdHQg T2xzb24gPG1hb2xzb25AbWljcm9zb2Z0LmNvbTxtYWlsdG86bWFvbHNvbkBtaWNyb3NvZnQuY29t Pj4gd3JvdGU6DQo+DQo+IEFsc28sIHNlY3Rpb24gNi41LjEgU3RlcCAxIGlzIHByZXNlbnRlZCBh cyBhIGNvbXBsZXRlIHNldCBvZiBjb25kaXRpb25zIGZvciBzY2hlZHVsaW5nIGEgUFRPLCBidXQg aXQgaXMgbWlzc2luZyBhIGJ1bGxldCBwb2ludCBmb3IgVExQUnh0T3V0Lg0KVGhhbmtzIGZvciBj aGVja2luZzogYnV0IGNoZWNraW5nIFRMUFJ4dE91dCBpcyBub3QgbmVjZXNzYXJ5IGFuZCBpcyBu b3QgcHJlZmVycmVkIHdoZW4gc2NoZWR1bGluZyBhIHByb2JlIC0tIHRoZSBnb2FsIGlzIHRvIHBy ZXZlbnQgbW9yZSB0aGFuIG9uZSBwcm9iZSBpbmZsaWdodCwgc28gY2hlY2tpbmcgcmlnaHQgYmVm b3JlIFRMUFJ4dE91dCBzZW5kaW5nIHRoZSBuZXh0IG9uZSBhbGxvd3MgdGhlIGJlc3QgY292ZXJh Z2Ugb2YgYXBwbGljYXRpb24tbGltaXRlZCB3cml0ZXMgKGJ1cnN0LWlkbGUtYnVyc3QtLi4uLiku DQoNCg0KDQoNCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWXVjaHVu ZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb208bWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tPj4NCj4g U2VudDogV2VkbmVzZGF5LCBNYXkgMSwgMjAxOSAxMTozMyBQTQ0KPiBUbzogWWkgSHVhbmcgPGh1 YW55aT00MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLi5vcmc+Pg0KPiBDYzogdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRm Lm9yZz47IE1hdHQgT2xzb24gPG1hb2xzb25AbWljcm9zb2Z0LmNvbTxtYWlsdG86bWFvbHNvbkBt aWNyb3NvZnQuY29tPj4NCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQgVExQ DQo+DQo+IE9uIFdlZCwgTWF5IDEsIDIwMTkgYXQgMTA6NDggUE0gWWkgSHVhbmcgPGh1YW55aT00 MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZz4+IHdyb3RlOg0KPiA+DQo+ID4gSGkgUkFDSy9UTFAgYXV0aG9ycywNCj4gPg0K PiA+DQo+ID4NCj4gPiBJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgKHBhZ2UgbnVtYmVy cyByZWZlciB0byBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNSk6DQo+ID4NCj4gPg0KPiA+DQo+ID4g MS5JbiBwYWdlIDE2LCBpdCBzYXlzIOKAnEZpbmFsbHksIGlmIHRoZSB0aW1lIGF0IHdoaWNoIGFu IFJUTyB3b3VsZCBmaXJlIChoZXJlIGRlbm90ZWQgIlRDUF9SVE9fZXhwaXJlIikgaXMgc29vbmVy IHRoYW4gdGhlIGNvbXB1dGVkIHRpbWUgZm9yIHRoZSBQVE8sIHRoZW4gYSBwcm9iZSBpcyBzY2hl ZHVsZWQgdG8gYmUgc2VudCBhdCB0aGF0IGVhcmxpZXIgdGltZS7igJ0gV2hhdCBkb2VzIHRoaXMg VENQX1JUT19leHBpcmUgYWN0dWFsbHkgbWVhbj8gRG9lcyBpdCBtZWFuIHRoZXJlIGlzIGFub3Ro ZXIgUlRPIHRpbWVyIChwb3NzaWJseSBzdGFydGVkIHNvbWUgdGltZSBpbiB0aGUgcGFzdCkgcnVu bmluZyBhbG9uZyB3aXRoIFBUTyBvciBqdXN0IFJUVCArIDQqUlRUVmFyICsgTm93KCk/IEFsc28s IHdoeSB3b3VsZCBhbm90aGVyIHByb2JlIGJlIHNlbnQgYXQgUlRPIGV4cGlyYXRpb24gdGltZSBp bnN0ZWFkIG9mIHRyZWF0aW5nIGl0IGxpa2UgUlRPIGFuZCBjb2xsYXBzaW5nIHRoZSBjd25kPw0K Pg0KPiBUQ1BfUlRPX2V4cGlyZSgpIHNob3VsZCByZXR1cm4gYSB0aW1lb3V0IHZhbHVlIGZvciBy ZWd1bGFyIFJUTywgaS5lLg0KPiBTUlRUICsgNCpSVFRWQVIgKyBOb3coKQ0KPiBXZSB1c2UgVENQ X1JUT19leHBpcmUoKSBiZWNhdXNlIG1hbnkgaW1wbGVtZW50YXRpb25zIGluY2x1ZGluZyBMaW51 eA0KPiBkbyBub3QgdXNlIHRoZSBleGFjdCBSRkMgZm9ybXVsYQ0KPg0KPiBUaGUgcmVhc29uIGl0 J3Mgbm90IHRyZWF0ZWQgYXMgYSByZWd1bGFyIFJUTyBpcyB0byBhdm9pZCByZXNldHRpbmcgY29u Z2VzdGlvbiB3aW5kb3cgdG8gMS4gVGhlIHJhdGlvbmFsZSBpcyBpZiB0aGUgcHJvYmUgd2FzIHNl bnQgd2l0aGluIG1pbihQVE8sIFJUTykgYW5kIHdhcyBkZWxpdmVyZWQgc3VjY2Vzc2Z1bGx5LCB0 aGVyZSdzIG5vIG5lZWQgdG8gcmVzZXQgY29uZ2VzdGlvbiB3aW5kb3cgYW5kIHJlLXN0YXJ0IHNs b3ctc3RhcnQsIHNpbWlsYXIgdG8gdGhlIHJhdGlvbmFsZSBvZiBSZW5vJ3MgZmFzdCByZWNvdmVy eSByZWR1Y2luZyB3aW5kb3cgdG8gc3N0aHJlc2ggaW5zdGVhZCBvZiAxLiBXZSBoYXZlIGZvdW5k IHRoaXMgc3RyYXRlZ3kgYmVuZWZpdHMgd2lyZWxlc3MgY29ubmVjdGlvbnMsIGFzIHRoZSBjaGFu Y2Ugb2Ygc3B1cmlvdXMgUlRPIGlzIGhpZ2ggZHVlIHRvIHRoZSBkZWxheSB2YXJpYXRpb24uDQo+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gMi5JbiBwYWdlIDE4IHNlY3Rpb24gNi42LCBhIG5ldyB2YXJp YWJsZSBUTFBSeHRPdXQgaXMgZGVmaW5lZCBhbmQgaXQgaXMgc3RhdGVkIHRoYXQgVExQUnh0T3V0 IGlzIHVzZWQgdG8gZ3VhcmFudGVlIHRoYXQgdGhlcmUgaXMgb25seSBvbmUgb3V0c3RhbmRpbmcg VExQIHJldHJhbnNtaXNzaW9uLi4gSG93ZXZlciwgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoZW4g VExQUnh0T3V0IHNob3VsZCBiZSByZWFsbHkgdXNlZC4gU2hvdWxkIGl0IGJlIHVzZWQgaW4gNi41 LjEgU3RlcC4gMSAoY2hlY2tpbmcgd2hldGhlciB3ZSBzaG91bGQgYW5kIGNhbiBzY2hlZHVsZSBh IFRMUCkgb3IgaW4gVExQX3NlbmRfcHJvYmUoKT8NCj4NCj4gVGhpcyBpcyBpbg0KPg0KPiA2LjYu Mi4gIFJlY29yZGluZyBsb3NzIHByb2JlIHN0YXRlcw0KPg0KPiAgICBTZW5kZXJzIE1VU1Qgb25s eSBzZW5kIGEgVExQIGxvc3MgcHJvYmUgcmV0cmFuc21pc3Npb24gaWYgVExQUnh0T3V0DQo+ICAg IGlzIGZhbHNlLiAgVGhpcyBlbnN1cmVzIHRoYXQgYXQgYW55IGdpdmVuIHRpbWUgYSBjb25uZWN0 aW9uIGhhcyBhdA0KPiAgICBtb3N0IG9uZSBvdXRzdGFuZGluZyBUTFAgcmV0cmFuc21pc3Npb24u ICBUaGlzIGFsbG93cyB0aGUgc2VuZGVyIHRvDQo+DQo+IGJ1dCBJIGFncmVlIGl0J2QgYmUgbW9y ZSBjbGVhciB0byBpbmNsdWRlIHRoaXMgaW4gVExQX3NlbmRfcHJvYmUoKSBwc2V1ZG8gY29kZS4g SSdkIGluY29ycG9yYXRlIGluIHRoZSBuZXh0IHJldi4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFu a3MsDQo+ID4NCj4gPg0KPiA+DQo+ID4gWWkNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHRjcG0gbWFpbGluZyBs aXN0DQo+ID4gdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCj4gPiBodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuLg0KPiA+IGlldGYub3JnPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0Zi5vcmcmZGF0YT0wMSU3QzAxJTdDaHVh bnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2JiZjFhZDRhNTI0YzQ4MjEwMzFiMDhkNmQzMGM2NDZmJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJnNkYXRhPXk4JTJGJTJCQ094TiUy RmpBSmlTUHVaeUlFZ0ZrRlo5bDdTJTJGb2puaG1md0RSaGs2VSUzRCZyZXNlcnZlZD0wPiUyRm1h aWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDElN0MwMSU3Q21hb2xzb24lNDBtaQ0K PiA+IGNyDQo+ID4gb3NvZnQuY29tPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGb3NvZnQuY29tJmRhdGE9MDElN0MwMSU3Q2h1 YW55aSU0MG1pY3Jvc29mdC5jb20lN0NiYmYxYWQ0YTUyNGM0ODIxMDMxYjA4ZDZkMzBjNjQ2ZiU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSZzZGF0YT1OdFklMkJaeTM3OVY0 VjdDMWRsVFJ5anNtQnR2R3pEU05lRm1jYlpwUklUMHMlM0QmcmVzZXJ2ZWQ9MD4lN0M2NmRiNDQ2 NzJlM2Q0MTAxZDcyOTA4ZDZjZWM4MjAwMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMg0KPiA+IGQ3 DQo+ID4gY2QwMTFkYjQ3JTdDMSZhbXA7c2RhdGE9bjhycDVFbW93bTQ1OWlTS29saElQMWhGWEJz OHBaanNHRzJpeTNPQkFubyUNCj4gPiAzRA0KPiA+ICZhbXA7cmVzZXJ2ZWQ9MA0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0 DQp0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4l MkZsaXN0aW5mbyUyRnRjcG0mZGF0YT0wMSU3QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3 Q2JiZjFhZDRhNTI0YzQ4MjEwMzFiMDhkNmQzMGM2NDZmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJnNkYXRhPTk1VndEMVd5MTNZTyUyRmtzTnpTNEE5T2p5ZlBFeXVRS2RH Y0tuOWdvaTVzWSUzRCZyZXNlcnZlZD0wPg0K --_000_BL0PR2101MB104398C390A677A41F52E075C3330BL0PR2101MB1043_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBZdWNodW5nLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhdmUgb25lIG1vcmUgcXVlc3Rpb24gcmVnYXJkaW5nIHRvIFRMUCBhbmQgdGhl IHByb3Bvc2VkIHJldi4gU28gZHVyaW5nIGEgcG9zdC1UTFAgUlRPLCBpZiB0aGUgYXBwbGljYXRp b24gd3JpdGVzIHNvbWV0aGluZyBiZWZvcmUgdGhpcyBSVE8gZmlyZXMsIHRoZSBzZW5kZXIgd2ls bCBzdGlsbCB0cnkgdG8gc2NoZWR1bGUgUFRPLCB3aGljaCBzaG91bGQgY2FuY2VsIHRoZSBhbHJl YWR5IHJ1bm5pbmcgUlRPLg0KIFdoZW4gdGhpcyBuZXcgUFRPIGZpcmVzLCBzaW5jZSBUTFBSeHRP dXQgaXMgdHJ1ZSBkdWUgdGhlIHByZXZpb3VzIFRMUCBzZW50LCB0aGUgc2VuZGVyIHdpbGwgbm90 IHNlbmQgYW5vdGhlciBUTFAgYnV0IHJlYXJtIFJUTyB0aW1lci4gSXMgdGhpcyB0cnVlPyBJZiBz byBhbmQgYW4gYXBwIGFsd2F5cyB3cml0ZXMgZGF0YSBpbiBzdWNoIGEgcGF0dGVybiBhbmQgbm8g QUNLcyBhcmUgY29taW5nIGJhY2sgZHVlIHRvIG5ldHdvcmsgZmFpbHVyZSwgUlRPDQogd2lsbCBi ZSBwb3N0cG9uZWQgaW5maW5pdGVseSB1bnRpbCB0aGUgd2luZG93IGxpbWl0IGlzIHJlYWNoZWQ/ IE15IG1haW4gY29uY2VybiBpcyB0aGF0IHdlIGNvdWxkIGhhdmUgZGV0ZWN0ZWQgdGhlIG5ldHdv cmsgZmFpbHVyZSB2ZXJ5IGVhcmx5LiBJdCBzZWVtcyBsaWtlIHRoZSBjdXJyZW50IGFsZ29yaXRo bSBtaWdodCBjYXVzZSBkZWxheXMgaW4gdGVhcmluZyBkb3duIHRoZSBjb25uZWN0aW9uIGRlcGVu ZGluZyBvbiBhcHAgc2VuZCBiZWhhdmlvci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzZXF1 ZW5jZSB0byBoZWxwIGlsbHVzdHJhdGUgdGhlIHByb2JsZW0gSSBtZW50aW9uZWQgYW5kIGFzc3Vt ZSBubyBBQ0tzIHdpbGwgYmUgcmVjZWl2ZWQgZHVlIHRvIG5ldHdvcmsgZmFpbHVyZSBkdXJpbmcg c28uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHAgd3JpdGVzLSZndDth cm0gUFRPLSZndDtQVE8gZmlyZXMtJmd0O1RMUC0mZ3Q7PHU+YXJtIFJUTzwvdT4tJmd0O2FwcCB3 cml0ZXMtJmd0O2FybSBQVE8tJmd0O1BUTyBmaXJlcy0mZ3Q7PHU+YXJtIFJUTzwvdT4tJmd0O2Fw cCB3cml0ZXMtJmd0O2FybSBQVE8tJmd0O1BUTyBmaXJlcy0mZ3Q7PHU+YXJtIFJUTzwvdT7igKY8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdGhlIHByb3Bvc2VkIHJldiBzYXlzIOKAnDx1 PkFsc28gY2hlY2tpbmcgVExQUnh0T3V0IHByaW9yIHRvIHNlbmRpbmcgdGhlIGxvc3MgcHJvYmU8 L3U+IGlzIGltcG9ydGFudCB0byBhdm9pZCBUTFAgbG9vcHMgaWYgYW4gYXBwbGljYXRpb24gd3Jp dGVzIHBlcmlvZGljYWxseSBhdCBhbiBpbnRlcnZhbCBsZXNzIHRoYW4gUFRPLuKAnS4gSWYgYW4g YXBwIHdyaXRlcyBwZXJpb2RpY2FsbHkgYXQgYW4gaW50ZXJ2YWwNCiBsZXNzIHRoYW4gUFRPLCB0 aGUgc2VuZGVyIHdpbGwganVzdCBwZXJpb2RpY2FsbHkgcG9zdHBvbmUgUFRPIHVudGlsIHdpbmRv dyBsaW1pdCBpcyByZWFjaGVkIHNpbmNlIGVhY2ggdGltZSB0aGUgYXBwIHdyaXRlcyBkYXRhLCBh IG5ldyBQVE8gd2lsbCBiZSBzY2hlZHVsZWQgYW5kIGNhbmNlbCB0aGUgZXhpc3Rpbmcgb25lLiBJ IGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCBob3cgdGhpcyBhcHAgYmVoYXZpb3IgaXMgcmVsYXRl ZCB0byByZXBlYXRlZA0KIGJhY2stdG8tYmFjayBUTFBzIHByb2JsZW0gY2F1c2VkIGJ5IGFybWlu ZyBQVE8gYWZ0ZXIgc2VuZGluZyBUTFAuIEJ0dywg4oCcVExQIGxvb3Bz4oCdIGxvb2tzIGxpa2Ug YSBicmFuZCBuZXcgdGVybSB1c2VkIG9ubHkgaW4gdGhpcyBwYXJhZ3JhcGguPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5Gcm9tOjwvYj4gWXVjaHVuZyBDaGVuZyAmbHQ7eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgNywgMjAxOSA5 OjUyIEFNPGJyPg0KPGI+VG86PC9iPiBZaSBIdWFuZyAmbHQ7aHVhbnlpQG1pY3Jvc29mdC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBZdWNodW5nIENoZW5nICZsdDt5Y2hlbmdAZ29vZ2xlLmNvbSZn dDs7IE1hdHQgT2xzb24gJmx0O21hb2xzb25AbWljcm9zb2Z0LmNvbSZndDs7IHRjcG1AaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBRdWVzdGlvbnMgYWJvdXQgVExQPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXZpZXcgYXMgd2Vs bCE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOg0KPC9zcGFuPjwvc3Ryb25nPllpIEh1 YW5nICZsdDtodWFueWk9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy4uaWV0 Zi5vcmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5EYXRlOiA8L3NwYW4+PC9zdHJvbmc+VGh1LCBNYXkgMiwgMjAxOSwgMTE6NDcgQU08YnI+DQo8 c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRvOiA8L3NwYW4+PC9zdHJvbmc+WXVjaHVuZyBDaGVuZywgTWF0dCBPbHNvbjxicj4N CjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Q2M6IDwvc3Bhbj48L3N0cm9uZz48YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9y ZyI+dGNwbUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIFRMUFJ4dE91dCBpcyBjaGVja2VkIGluIFRMUF9zZW5k X3Byb2JlKCksIGEgbmV3IFBUTyBjYW4gY2FuY2VsIGFuIGFscmVhZHkgcnVubmluZyBSVE8gdGlt ZXIgYXJtZWQgYnkgc2VuZGluZyBUTFAgcHJldmlvdXNseS4gSWYgVExQX3NlbmRfcHJvYmUoKSBk ZWNpZGVzIG5vdCB0byBzZW5kIHRoZSBwcm9iZSBmb3IgdGhlIG5ldyBQVE8sIHdoYXQgc2hvdWxk IHRoZSBzZW5kZXIgZG8gbmV4dD8gUmVhcm0gUlRPDQogb3IgdHJlYXQgaXQgYXMgUlRPIHRpbWVv dXQ/IFRoZSBkcmFmdCBzdGF0ZXMgd2UgbXVzdCBhcm0gYW4gUlRPIGFmdGVyIHRyYW5zbWl0dGlu ZyBUTFAgYnV0IGluIHRoaXMgY2FzZSwgbm8gcHJvYmUgd2lsbCBiZSBzZW50Ljxicj4NCjxicj4N CkFsc28sIGluIHBhZ2UgMTcsIHRoZSBkcmFmdCBzYXlzICZxdW90O1RoaXMgaXMgaW1wb3J0YW50 IHRvIGF2b2lkIFRMUCBsb29wcyBpZiBhbiBhcHBsaWNhdGlvbiB3cml0ZXMgcGVyaW9kaWNhbGx5 IGF0IGFuIGludGVydmFsIGxlc3MgdGhhbiBQVE8uJnF1b3Q7IGJ1dCBpZiB0aGUgYXBwIHdyaXRl cyBwZXJpb2RpY2FsbHkgYXQgYW4gaW50ZXJ2YWwgbGVzcyB0aGFuIFBUTywgUFRPIHdpbGwganVz dCBiZSBwdXNoZWQgb3V0IGFuZCBub3QgZmlyZSB1bnRpbCB0aGUgc2VuZGVyDQogY2Fubm90IHNl bmQgYW55dGhpbmcgZHVlIHRvIHdpbmRvdyBsaW1pdC4gVGhlbiBpbiB0aGlzIGNhc2UsIFRMUCBs b29wcyBkbyBub3Qgc2VlbSB0byBleGlzdCBpZiBUTFAgbG9vcHMgbWVhbnMgYmFjay10by1iYWNr IFRMUCBwcm9iZXMuIEFtIEkgbWlzc2luZyBhbnl0aGluZyBoZXJlPzxicj4NCjxicj4NClRoYW5r cyw8YnI+DQo8YnI+DQpZaTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KRnJvbTogWXVjaHVuZyBDaGVuZyAmbHQ7eWNoZW5nPTxhIGhyZWY9Im1haWx0bzo0MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS5jb21AZG1hcmMu aWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KU2VudDogVGh1cnNkYXksIE1heSAyLCAyMDE5IDEwOjI1 IEFNPGJyPg0KVG86IE1hdHQgT2xzb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYW9sc29uQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW9sc29uQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxi cj4NCkNjOiBZaSBIdWFuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1YW55aUBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+aHVhbnlpQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBSZTogW3RjcG1dIFF1ZXN0aW9ucyBhYm91dCBUTFA8YnI+DQo8YnI+DQpP biBUaHUsIE1heSAyLCAyMDE5IGF0IDEwOjA5IEFNIE1hdHQgT2xzb24gJmx0OzxhIGhyZWY9Im1h aWx0bzptYW9sc29uQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYW9sc29uQG1pY3Jv c29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbHNvLCBzZWN0aW9u IDYuNS4xIFN0ZXAgMSBpcyBwcmVzZW50ZWQgYXMgYSBjb21wbGV0ZSBzZXQgb2YgY29uZGl0aW9u cyBmb3Igc2NoZWR1bGluZyBhIFBUTywgYnV0IGl0IGlzIG1pc3NpbmcgYSBidWxsZXQgcG9pbnQg Zm9yIFRMUFJ4dE91dC48YnI+DQpUaGFua3MgZm9yIGNoZWNraW5nOiBidXQgY2hlY2tpbmcgVExQ Unh0T3V0IGlzIG5vdCBuZWNlc3NhcnkgYW5kIGlzIG5vdCBwcmVmZXJyZWQgd2hlbiBzY2hlZHVs aW5nIGEgcHJvYmUgLS0gdGhlIGdvYWwgaXMgdG8gcHJldmVudCBtb3JlIHRoYW4gb25lIHByb2Jl IGluZmxpZ2h0LCBzbyBjaGVja2luZyByaWdodCBiZWZvcmUgVExQUnh0T3V0IHNlbmRpbmcgdGhl IG5leHQgb25lIGFsbG93cyB0aGUgYmVzdCBjb3ZlcmFnZSBvZiBhcHBsaWNhdGlvbi1saW1pdGVk DQogd3JpdGVzIChidXJzdC1pZGxlLWJ1cnN0LS4uLi4pLjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0 OyBGcm9tOiBZdWNodW5nIENoZW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWNoZW5nQGdvb2dsZS5j b20iIHRhcmdldD0iX2JsYW5rIj55Y2hlbmdAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBT ZW50OiBXZWRuZXNkYXksIE1heSAxLCAyMDE5IDExOjMzIFBNPGJyPg0KJmd0OyBUbzogWWkgSHVh bmcgJmx0O2h1YW55aT08YSBocmVmPSJtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYu Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjsgTWF0dCBPbHNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1hb2xzb25AbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hb2xzb25AbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3RjcG1dIFF1ZXN0aW9ucyBhYm91 dCBUTFA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBXZWQsIE1heSAxLCAyMDE5IGF0IDEwOjQ4IFBN IFlpIEh1YW5nICZsdDtodWFueWk9PGEgaHJlZj0ibWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFy Yy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y ZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIaSBSQUNLL1RM UCBhdXRob3JzLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBJIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVzdGlvbnMgKHBhZ2UgbnVtYmVy cyByZWZlciB0byBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNSk6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IDEuSW4gcGFnZSAxNiwgaXQg c2F5cyDigJxGaW5hbGx5LCBpZiB0aGUgdGltZSBhdCB3aGljaCBhbiBSVE8gd291bGQgZmlyZSAo aGVyZSBkZW5vdGVkICZxdW90O1RDUF9SVE9fZXhwaXJlJnF1b3Q7KSBpcyBzb29uZXIgdGhhbiB0 aGUgY29tcHV0ZWQgdGltZSBmb3IgdGhlIFBUTywgdGhlbiBhIHByb2JlIGlzIHNjaGVkdWxlZCB0 byBiZSBzZW50IGF0IHRoYXQgZWFybGllciB0aW1lLuKAnSBXaGF0IGRvZXMgdGhpcyBUQ1BfUlRP X2V4cGlyZSBhY3R1YWxseSBtZWFuPw0KIERvZXMgaXQgbWVhbiB0aGVyZSBpcyBhbm90aGVyIFJU TyB0aW1lciAocG9zc2libHkgc3RhcnRlZCBzb21lIHRpbWUgaW4gdGhlIHBhc3QpIHJ1bm5pbmcg YWxvbmcgd2l0aCBQVE8gb3IganVzdCBSVFQgJiM0MzsgNCpSVFRWYXIgJiM0MzsgTm93KCk/IEFs c28sIHdoeSB3b3VsZCBhbm90aGVyIHByb2JlIGJlIHNlbnQgYXQgUlRPIGV4cGlyYXRpb24gdGlt ZSBpbnN0ZWFkIG9mIHRyZWF0aW5nIGl0IGxpa2UgUlRPIGFuZCBjb2xsYXBzaW5nIHRoZSBjd25k Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFRDUF9SVE9fZXhwaXJlKCkgc2hvdWxkIHJldHVybiBhIHRp bWVvdXQgdmFsdWUgZm9yIHJlZ3VsYXIgUlRPLCBpLmUuPGJyPg0KJmd0OyBTUlRUICYjNDM7IDQq UlRUVkFSICYjNDM7IE5vdygpPGJyPg0KJmd0OyBXZSB1c2UgVENQX1JUT19leHBpcmUoKSBiZWNh dXNlIG1hbnkgaW1wbGVtZW50YXRpb25zIGluY2x1ZGluZyBMaW51eCA8YnI+DQomZ3Q7IGRvIG5v dCB1c2UgdGhlIGV4YWN0IFJGQyBmb3JtdWxhPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHJlYXNv biBpdCdzIG5vdCB0cmVhdGVkIGFzIGEgcmVndWxhciBSVE8gaXMgdG8gYXZvaWQgcmVzZXR0aW5n IGNvbmdlc3Rpb24gd2luZG93IHRvIDEuIFRoZSByYXRpb25hbGUgaXMgaWYgdGhlIHByb2JlIHdh cyBzZW50IHdpdGhpbiBtaW4oUFRPLCBSVE8pIGFuZCB3YXMgZGVsaXZlcmVkIHN1Y2Nlc3NmdWxs eSwgdGhlcmUncyBubyBuZWVkIHRvIHJlc2V0IGNvbmdlc3Rpb24gd2luZG93IGFuZCByZS1zdGFy dCBzbG93LXN0YXJ0LCBzaW1pbGFyDQogdG8gdGhlIHJhdGlvbmFsZSBvZiBSZW5vJ3MgZmFzdCBy ZWNvdmVyeSByZWR1Y2luZyB3aW5kb3cgdG8gc3N0aHJlc2ggaW5zdGVhZCBvZiAxLiBXZSBoYXZl IGZvdW5kIHRoaXMgc3RyYXRlZ3kgYmVuZWZpdHMgd2lyZWxlc3MgY29ubmVjdGlvbnMsIGFzIHRo ZSBjaGFuY2Ugb2Ygc3B1cmlvdXMgUlRPIGlzIGhpZ2ggZHVlIHRvIHRoZSBkZWxheSB2YXJpYXRp b24uPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAyLkluIHBhZ2UgMTggc2VjdGlvbiA2LjYsIGEgbmV3IHZhcmlhYmxl IFRMUFJ4dE91dCBpcyBkZWZpbmVkIGFuZCBpdCBpcyBzdGF0ZWQgdGhhdCBUTFBSeHRPdXQgaXMg dXNlZCB0byBndWFyYW50ZWUgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBvdXRzdGFuZGluZyBUTFAg cmV0cmFuc21pc3Npb24uLiBIb3dldmVyLCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgd2hlbiBUTFBS eHRPdXQgc2hvdWxkIGJlIHJlYWxseSB1c2VkLiBTaG91bGQgaXQgYmUNCiB1c2VkIGluIDYuNS4x IFN0ZXAuIDEgKGNoZWNraW5nIHdoZXRoZXIgd2Ugc2hvdWxkIGFuZCBjYW4gc2NoZWR1bGUgYSBU TFApIG9yIGluIFRMUF9zZW5kX3Byb2JlKCk/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBpcyBp bjxicj4NCiZndDs8YnI+DQomZ3Q7IDYuNi4yLiZuYnNwOyBSZWNvcmRpbmcgbG9zcyBwcm9iZSBz dGF0ZXM8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgU2VuZGVycyBNVVNUIG9ubHkg c2VuZCBhIFRMUCBsb3NzIHByb2JlIHJldHJhbnNtaXNzaW9uIGlmIFRMUFJ4dE91dDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IGlzIGZhbHNlLiZuYnNwOyBUaGlzIGVuc3VyZXMgdGhhdCBhdCBhbnkg Z2l2ZW4gdGltZSBhIGNvbm5lY3Rpb24gaGFzIGF0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgbW9z dCBvbmUgb3V0c3RhbmRpbmcgVExQIHJldHJhbnNtaXNzaW9uLiZuYnNwOyBUaGlzIGFsbG93cyB0 aGUgc2VuZGVyIHRvPGJyPg0KJmd0Ozxicj4NCiZndDsgYnV0IEkgYWdyZWUgaXQnZCBiZSBtb3Jl IGNsZWFyIHRvIGluY2x1ZGUgdGhpcyBpbiBUTFBfc2VuZF9wcm9iZSgpIHBzZXVkbyBjb2RlLiBJ J2QgaW5jb3Jwb3JhdGUgaW4gdGhlIG5leHQgcmV2Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlpPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 IHRjcG0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL25hbTA2LnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3c8L2E+ Li48YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZpZXRmLm9yZyZhbXA7ZGF0YT0wMSU3 QzAxJTdDaHVhbnlpJTQwbWljcm9zb2Z0LmNvbSU3Q2JiZjFhZDRhNTI0YzQ4MjEwMzFiMDhkNmQz MGM2NDZmJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJmFtcDtzZGF0YT15 OCUyRiUyQkNPeE4lMkZqQUppU1B1WnlJRWdGa0ZaOWw3UyUyRm9qbmhtZndEUmhrNlUlM0QmYW1w O3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmlldGYub3JnPC9hPiUyRm1haWxtYW4lMkZs aXN0aW5mbyUyRnRjcG0mYW1wO2FtcDtkYXRhPTAxJTdDMDElN0NtYW9sc29uJTQwbWk8YnI+DQom Z3Q7ICZndDsgY3I8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZvc29mdC5jb20mYW1w O2RhdGE9MDElN0MwMSU3Q2h1YW55aSU0MG1pY3Jvc29mdC5jb20lN0NiYmYxYWQ0YTUyNGM0ODIx MDMxYjA4ZDZkMzBjNjQ2ZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSZh bXA7c2RhdGE9TnRZJTJCWnkzNzlWNFY3QzFkbFRSeWpzbUJ0dkd6RFNOZUZtY2JacFJJVDBzJTNE JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpvc29mdC5jb208L2E+JTdDNjZkYjQ0 NjcyZTNkNDEwMWQ3MjkwOGQ2Y2VjODIwMDElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjI8YnI+DQom Z3Q7ICZndDsgZDcgPGJyPg0KJmd0OyAmZ3Q7IGNkMDExZGI0NyU3QzEmYW1wO2FtcDtzZGF0YT1u OHJwNUVtb3dtNDU5aVNLb2xoSVAxaEZYQnM4cFpqc0dHMml5M09CQW5vJTxicj4NCiZndDsgJmd0 OyAzRDxicj4NCiZndDsgJmd0OyAmYW1wO2FtcDtyZXNlcnZlZD0wPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNw bUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAxJTdDMDElN0NodWFueWklNDBtaWNyb3Nv ZnQuY29tJTdDYmJmMWFkNGE1MjRjNDgyMTAzMWIwOGQ2ZDMwYzY0NmYlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEmYW1wO3NkYXRhPTk1VndEMVd5MTNZTyUyRmtzTnpTNEE5 T2p5ZlBFeXVRS2RHY0tuOWdvaTVzWSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNwbTwvYT48bzpwPjwvbzpw PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR2101MB104398C390A677A41F52E075C3330BL0PR2101MB1043_-- From nobody Wed May 8 18:29:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08724120203 for ; Wed, 8 May 2019 18:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.899 X-Spam-Level: X-Spam-Status: No, score=-13.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URI_HEX=1.122, URI_NOVOWEL=0.5, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PfhWG_4F6Bxy for ; Wed, 8 May 2019 18:29:23 -0700 (PDT) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 320E51200C7 for ; Wed, 8 May 2019 18:29:23 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id f7so520530wrq.1 for ; Wed, 08 May 2019 18:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z4wp3kC/GR+kDlj76J5cdL2+aOICXinHn6DwsUxIapU=; b=S38YDEQF7+d1ywJZj5A3qDR9gwDpi6TEzNFPiU7KapQEuJjOpFXxaZVt0zb9DP/GMc evy+Xbrd2Zy/PUiMjdtHG7a2qYfUb0cU/Y1gijxwtM7nUduRjmT/ikLVk4RxmLBbb9b6 /01LYJYlgm0NYbHIrahKfgTrnvlJh2J7q2z0ibMQHP823lmYT2U1anaq6gxIdgViYla0 sOGlSDQ3UJye2NYv7v03t1Jg7eUlmta5CQH1PIDd/K6Fuh1dORTBsrqK2edGjthwXOx9 e6pTbEFyCV39nd9Bb/N9fDCcwW1OeK8OegzAcTHJRtNG+Zw17O892ldZn2D7R+0gOiTW fr5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z4wp3kC/GR+kDlj76J5cdL2+aOICXinHn6DwsUxIapU=; b=qKkMtYYCIqHV9ixrKUBZPdZ7qbKn4izZV/owGxZMCoZnY0yoqNFERNtWKCPgg/+7If Io3aAI98HtHkiysbuLHYGRPZtqocYnA65JWo+aM1+Xfy7mzYnkxpfIVoVAL8LSm0oSge Rn12TqaGd3AUJcRLw8AE1b7PPsHdeaHKMF6z9YZhjc5PpwtvOZrBwa+wMa/JFtUHjhT6 nYQ1YojwEnnYIkwPEFe7YTUMM2Qv6VNptqxrG1kBWmsy/1fbfAFEOrJK4bAuvOqO1zbo TAJTihBq4P7484ZA/sd2DOyrlgeZ4aW3KyhTGhrOHv4HtF0XGorfxFdzAUOuBcRd1Vw/ uolA== X-Gm-Message-State: APjAAAU8igbax5LU4RtQbPvKMvtqhuNizzmGHUSYiLDHcD2UCBCGhegI J4Vg00NfpkltagXQ6mwm9IyUp6TotjoOuYPKe1ZlEg== X-Google-Smtp-Source: APXvYqwo3aCELFMDAPUzqImpROAgOsWCp7P7A1uIfAZOc9h+B51d41MHpGPX5Ecy97DvQNc3PVoZe7Ctl2u6HclqTlg= X-Received: by 2002:adf:f304:: with SMTP id i4mr622112wro.97.1557365361081; Wed, 08 May 2019 18:29:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 8 May 2019 18:28:43 -0700 Message-ID: To: Yi Huang Cc: Yuchung Cheng , Matt Olson , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002270bf05886a61ef" Archived-At: Subject: Re: [tcpm] Questions about TLP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 01:29:26 -0000 --0000000000002270bf05886a61ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *From: *Yi Huang *Date: *Wed, May 8, 2019 at 5:19 PM *To: *Yuchung Cheng *Cc: *Yuchung Cheng, Matt Olson, tcpm@ietf.org Hi Yuchung, > > > > I have one more question regarding to TLP and the proposed rev. So during > a post-TLP RTO, if the application writes something before this RTO fires= , > the sender will still try to schedule PTO, which should cancel the alread= y > running RTO. When this new PTO fires, since TLPRxtOut is true due the > previous TLP sent, the sender will not send another TLP but rearm RTO > timer. Is this true? > yes > If so and an app always writes data in such a pattern and no ACKs are > coming back due to network failure, RTO will be postponed infinitely unti= l > the window limit is reached? My main concern is that we could have detect= ed > the network failure very early. It seems like the current algorithm might > cause delays in tearing down the connection depending on app send behavio= r. > > > > A sequence to help illustrate the problem I mentioned and assume no ACKs > will be received due to network failure during so. > > App writes->arm PTO->PTO fires->TLP->*arm RTO*->app writes->arm PTO->PTO > fires->*arm RTO*->app writes->arm PTO->PTO fires->*arm RTO*=E2=80=A6 > Good question. In the second "arm PTO" of your example, the last two lines in TLP_timeout() pseudo code may set PTO timer to expire at the original RTO (TCP_RTO_expire()). The timer expiration won't be extended forever but rather set to expire at max(PTO, original_RTO) of the first app writes. > > Also, the proposed rev says =E2=80=9C*Also checking TLPRxtOut prior to se= nding > the loss probe* is important to avoid TLP loops if an application writes > periodically at an interval less than PTO.=E2=80=9D. If an app writes per= iodically > at an interval less than PTO, the sender will just periodically postpone > PTO until window limit is reached since each time the app writes data, a > new PTO will be scheduled and cancel the existing one. I don=E2=80=99t qu= ite > understand how this app behavior is related to repeated back-to-back TLPs > problem caused by arming PTO after sending TLP. Btw, =E2=80=9CTLP loops= =E2=80=9D looks like > a brand new term used only in this paragraph. > > > > Thanks, > > > > Yi > > > > > > *From:* Yuchung Cheng > *Sent:* Tuesday, May 7, 2019 9:52 AM > *To:* Yi Huang > *Cc:* Yuchung Cheng ; Matt Olson ; > tcpm@ietf.org > *Subject:* Re: [tcpm] Questions about TLP > > > > Thanks for the review as well! > > > > *From: *Yi Huang <40microsoft.com@dmarc..ietf.org>> > *Date: *Thu, May 2, 2019, 11:47 AM > *To: *Yuchung Cheng, Matt Olson > *Cc: *tcpm@ietf.org > > If TLPRxtOut is checked in TLP_send_probe(), a new PTO can cancel an > already running RTO timer armed by sending TLP previously. If > TLP_send_probe() decides not to send the probe for the new PTO, what shou= ld > the sender do next? Rearm RTO or treat it as RTO timeout? The draft state= s > we must arm an RTO after transmitting TLP but in this case, no probe will > be sent. > > Also, in page 17, the draft says "This is important to avoid TLP loops if > an application writes periodically at an interval less than PTO." but if > the app writes periodically at an interval less than PTO, PTO will just b= e > pushed out and not fire until the sender cannot send anything due to wind= ow > limit. Then in this case, TLP loops do not seem to exist if TLP loops mea= ns > back-to-back TLP probes. Am I missing anything here? > > Thanks, > > Yi > > -----Original Message----- > From: Yuchung Cheng > Sent: Thursday, May 2, 2019 10:25 AM > To: Matt Olson > Cc: Yi Huang ; tcpm@ietf.org > Subject: Re: [tcpm] Questions about TLP > > On Thu, May 2, 2019 at 10:09 AM Matt Olson wrote: > > > > Also, section 6.5.1 Step 1 is presented as a complete set of conditions > for scheduling a PTO, but it is missing a bullet point for TLPRxtOut. > Thanks for checking: but checking TLPRxtOut is not necessary and is not > preferred when scheduling a probe -- the goal is to prevent more than one > probe inflight, so checking right before TLPRxtOut sending the next one > allows the best coverage of application-limited writes > (burst-idle-burst-....). > > > > > > > > -----Original Message----- > > From: Yuchung Cheng > > Sent: Wednesday, May 1, 2019 11:33 PM > > To: Yi Huang <40microsoft.com@dmarc.ietf..org>> > > Cc: tcpm@ietf.org; Matt Olson > > Subject: Re: [tcpm] Questions about TLP > > > > On Wed, May 1, 2019 at 10:48 PM Yi Huang 40microsoft.com@dmarc.ietf.org> wrote: > > > > > > Hi RACK/TLP authors, > > > > > > > > > > > > I have the following questions (page numbers refer to > draft-ietf-tcpm-rack-05): > > > > > > > > > > > > 1.In page 16, it says =E2=80=9CFinally, if the time at which an RTO w= ould fire > (here denoted "TCP_RTO_expire") is sooner than the computed time for the > PTO, then a probe is scheduled to be sent at that earlier time.=E2=80=9D = What does > this TCP_RTO_expire actually mean? Does it mean there is another RTO time= r > (possibly started some time in the past) running along with PTO or just R= TT > + 4*RTTVar + Now()? Also, why would another probe be sent at RTO expirati= on > time instead of treating it like RTO and collapsing the cwnd? > > > > TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > > SRTT + 4*RTTVAR + Now() > > We use TCP_RTO_expire() because many implementations including Linux > > do not use the exact RFC formula > > > > The reason it's not treated as a regular RTO is to avoid resetting > congestion window to 1. The rationale is if the probe was sent within > min(PTO, RTO) and was delivered successfully, there's no need to reset > congestion window and re-start slow-start, similar to the rationale of > Reno's fast recovery reducing window to ssthresh instead of 1. We have > found this strategy benefits wireless connections, as the chance of > spurious RTO is high due to the delay variation. > > > > > > > > > > > > > > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it > is stated that TLPRxtOut is used to guarantee that there is only one > outstanding TLP retransmission.. However, it is not clear to me when > TLPRxtOut should be really used. Should it be used in 6.5.1 Step. 1 > (checking whether we should and can schedule a TLP) or in TLP_send_probe(= )? > > > > This is in > > > > 6.6.2. Recording loss probe states > > > > Senders MUST only send a TLP loss probe retransmission if TLPRxtOut > > is false. This ensures that at any given time a connection has at > > most one outstanding TLP retransmission. This allows the sender to > > > > but I agree it'd be more clear to include this in TLP_send_probe() > pseudo code. I'd incorporate in the next rev. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Yi > > > > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww > .. > > > ietf.org > > %2Fmailman%2Flistinfo%2Ftcpm&data=3D01%7C01%7Cmaolson%40mi > > > cr > > > osoft.com > > %7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2 > > > d7 > > > cd011db47%7C1&sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2iy3OBAno= % > > > 3D > > > &reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --0000000000002270bf05886a61ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
From: Yi Huang <= huanyi@microsoft.com>
Date: Wed, May 8, 2= 019 at 5:19 PM
To: Yuchung Cheng
Cc: Yuchung Cheng, Matt Olson, tcpm@ietf.org

Hi Yuchung,

=C2=A0

I have one more question regarding to TLP and the pr= oposed rev. So during a post-TLP RTO, if the application writes something b= efore this RTO fires, the sender will still try to schedule PTO, which shou= ld cancel the already running RTO. When this new PTO fires, since TLPRxtOut is true due the previous TLP sent= , the sender will not send another TLP but rearm RTO timer. Is this true?= =C2=A0

yes
=C2=A0

If so and an app always writes data in such a pattern and no ACKs = are coming back due to network failure, RTO will be postponed infinitely until the window limit is reached? My main co= ncern is that we could have detected the network failure very early. It see= ms like the current algorithm might cause delays in tearing down the connec= tion depending on app send behavior.

=C2=A0

A sequence to help illustrate the problem I mentione= d and assume no ACKs will be received due to network failure during so.<= /u>

App writes->arm PTO->PTO fires->TLP->= arm RTO->app writes->arm PTO->PTO fires->arm RTO->= ;app writes->arm PTO->PTO fires->arm RTO=E2=80=A6

=
Good question. In the second "arm P= TO" of your example, the last two lines in TLP_timeout() pseudo code m= ay set PTO timer to expire at the original RTO (TCP_RTO_expire()). The timer expiration wo= n't be extended forever but rather set to expire at max(PTO, original_R= TO) of the first app writes.

=C2=A0

Also, the proposed rev says =E2=80=9CAlso checkin= g TLPRxtOut prior to sending the loss probe is important to avoid TLP l= oops if an application writes periodically at an interval less than PTO.=E2= =80=9D. If an app writes periodically at an interval less than PTO, the sender will just periodically postpone PTO until window= limit is reached since each time the app writes data, a new PTO will be sc= heduled and cancel the existing one. I don=E2=80=99t quite understand how t= his app behavior is related to repeated back-to-back TLPs problem caused by arming PTO after sending TLP. Btw, =E2= =80=9CTLP loops=E2=80=9D looks like a brand new term used only in this para= graph.

=C2=A0

Thanks,

=C2=A0

Yi

=C2=A0

=C2=A0

From: Yuchung Cheng <ycheng=3D40google.com@dmarc.iet= f.org>
Sent: Tuesday, May 7, 2019 9:52 AM
To: Yi Huang <huanyi@microsoft.com>
Cc: Yuchung Cheng <ycheng@google.com>; Matt Olson <maolson@microsoft.com>; tcpm@ietf.org
Subject: Re: [tcpm] Questions about TLP

=C2=A0

Thanks for the review as well!

=C2=A0

From: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
Date: Thu, May 2, 2019, 11:47 AM
To: = Yuchung Cheng, Matt Olson
Cc: = tcpm@ietf.org=

If TLPRxtOut is checked in TLP_send_probe(), a new P= TO can cancel an already running RTO timer armed by sending TLP previously.= If TLP_send_probe() decides not to send the probe for the new PTO, what sh= ould the sender do next? Rearm RTO or treat it as RTO timeout? The draft states we must arm an RTO after tran= smitting TLP but in this case, no probe will be sent.

Also, in page 17, the draft says "This is important to avoid TLP loops= if an application writes periodically at an interval less than PTO." = but if the app writes periodically at an interval less than PTO, PTO will j= ust be pushed out and not fire until the sender cannot send anything due to window limit. Then in this case, TLP loops do = not seem to exist if TLP loops means back-to-back TLP probes. Am I missing = anything here?

Thanks,

Yi

-----Original Message-----
From: Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org>
Sent: Thursday, May 2, 2019 10:25 AM
To: Matt Olson <maolson@microsoft.com>
Cc: Yi Huang <= huanyi@microsoft.com>; tcpm@ietf.org
Subject: Re: [tcpm] Questions about TLP

On Thu, May 2, 2019 at 10:09 AM Matt Olson <maolson@microsoft.com> wrote:
>
> Also, section 6.5.1 Step 1 is presented as a complete set of condition= s for scheduling a PTO, but it is missing a bullet point for TLPRxtOut.
Thanks for checking: but checking TLPRxtOut is not necessary and is not pre= ferred when scheduling a probe -- the goal is to prevent more than one prob= e inflight, so checking right before TLPRxtOut sending the next one allows = the best coverage of application-limited writes (burst-idle-burst-....).




>
> -----Original Message-----
> From: Yuchung Cheng <ycheng@google.com>
> Sent: Wednesday, May 1, 2019 11:33 PM
> To: Yi Huang <huanyi=3D40microsoft.com@dmarc.ietf.org>
> Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>
> Subject: Re: [tcpm] Questions about TLP
>
> On Wed, May 1, 2019 at 10:48 PM Yi Huang <huanyi=3D40microsoft.com@dmarc.i= etf.org> wrote:
> >
> > Hi RACK/TLP authors,
> >
> >
> >
> > I have the following questions (page numbers refer to draft-ietf-= tcpm-rack-05):
> >
> >
> >
> > 1.In page 16, it says =E2=80=9CFinally, if the time at which an R= TO would fire (here denoted "TCP_RTO_expire") is sooner than the = computed time for the PTO, then a probe is scheduled to be sent at that ear= lier time.=E2=80=9D What does this TCP_RTO_expire actually mean? Does it mean there is another RTO timer (possibly started some time in the= past) running along with PTO or just RTT + 4*RTTVar + Now()? Also, why wou= ld another probe be sent at RTO expiration time instead of treating it like= RTO and collapsing the cwnd?
>
> TCP_RTO_expire() should return a timeout value for regular RTO, i.e. > SRTT + 4*RTTVAR + Now()
> We use TCP_RTO_expire() because many implementations including Linux <= br> > do not use the exact RFC formula
>
> The reason it's not treated as a regular RTO is to avoid resetting= congestion window to 1. The rationale is if the probe was sent within min(= PTO, RTO) and was delivered successfully, there's no need to reset cong= estion window and re-start slow-start, similar to the rationale of Reno's fast recovery reducing window to ssthresh i= nstead of 1. We have found this strategy benefits wireless connections, as = the chance of spurious RTO is high due to the delay variation.
>
> >
> >
> >
> > 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and= it is stated that TLPRxtOut is used to guarantee that there is only one ou= tstanding TLP retransmission.. However, it is not clear to me when TLPRxtOu= t should be really used. Should it be used in 6.5.1 Step. 1 (checking whether we should and can schedule a TLP) = or in TLP_send_probe()?
>
> This is in
>
> 6.6.2.=C2=A0 Recording loss probe states
>
>=C2=A0 =C2=A0 Senders MUST only send a TLP loss probe retransmission if= TLPRxtOut
>=C2=A0 =C2=A0 is false.=C2=A0 This ensures that at any given time a con= nection has at
>=C2=A0 =C2=A0 most one outstanding TLP retransmission.=C2=A0 This allow= s the sender to
>
> but I agree it'd be more clear to include this in TLP_send_probe()= pseudo code. I'd incorporate in the next rev.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Yi
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= ..
> > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D01%7C01%7Cmaolson%4= 0mi
> > cr
> > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2 > > d7
> > cd011db47%7C1&amp;sdata=3Dn8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2= iy3OBAno%
> > 3D
> > &amp;reserved=3D0
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tc= pm

--0000000000002270bf05886a61ef-- From nobody Fri May 10 05:14:54 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3420E12001B for ; Fri, 10 May 2019 05:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 QAgt3QiA1fzY for ; Fri, 10 May 2019 05:14:51 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 0A90C120052 for ; Fri, 10 May 2019 05:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 0A2C52D3 for ; Fri, 10 May 2019 14:14:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aGSA8JNKB31v for ; Fri, 10 May 2019 14:14:48 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 2B7442D2 for ; Fri, 10 May 2019 14:14:47 +0200 (CEST) To: tcpm@ietf.org Reply-To: sy@informatik.uni-hamburg.de From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: Date: Fri, 10 May 2019 14:14:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 12:14:53 -0000 Hi everyone, TCP Fast Open has significant privacy problems which are not considered in RFC 7413. For example, this protocol allows a passive network observer to correlate connections established by the same client, which protocols such as TLS 1.3 and QUIC actively protect against. Furthermore, Fast Open cookies present a kernel-based tracking mechanism which is quite persistent. Amongst others, they can be used to conduct cross-browser tracking on the same operating system. For further details please refer to this article: https://arxiv.org/pdf/1905.03518.pdf I suggest, that the working group takes steps to highlight these privacy problems of RFC 7413. Regards, Erik From nobody Thu May 16 12:03:11 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50541201DD; Thu, 16 May 2019 12:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Tor2eNACkvnS; Thu, 16 May 2019 12:03:02 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 8909712021B; Thu, 16 May 2019 12:02:50 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id z16so1996173pgv.11; Thu, 16 May 2019 12:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dDehXbwovcYfEiNlzWq6xnL0iekFRh0ZK/XSocW+rak=; b=SMGiitX+nn2wOsBe+JdXMqVFW2YcdrdY2I220VYx5/tWIYSvYBT7PIRogs9aJilqzM yBi2tuRzV8BKD1K7k+xoKzvN9WGAXRc5fdVuX94I7i4DplR+Y9xm9Dz1AqW33nHpedKw FClxyTny+UKpUbZhFCNegEyuckCLqzd4ZfRNLpnFYVgAOojcFZuOCmTVXOlxERBxmY2K oOqP/y8siEidBlHJCKmtbGaNUqTvV2jdKncqX8gH8dfUaOfpUgOpFFQEQ7WNT7Qh4Am1 iuA2BKF1Yt/AEIU8takW0suSvHGyRxNwacFvsTWiRjyue16/pExoyqwxfl/ZQsg5laS9 tL9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dDehXbwovcYfEiNlzWq6xnL0iekFRh0ZK/XSocW+rak=; b=i1jQAoYnK9owqT0f+AhFwX4Tohoa3yCimmLXDSYlYy9fUVsJC3VIf6IFm++Pip8V3h 8/tAiCltX15oudw3bTcKmtop1QD2+SnQBKb4QscFZVR2/LQNmY38c2sRBRn6g2bucsl/ i3BtHbqzAT64XLoq6zkMatMi3KZEr265SMrQCs4yYob8GDQHBJGkiNv3vynRZs9TCiXY SE84uZETzvDyufAyP+u2k2/OlneEfffQyAI4y5Di/NtasuFS96jCv/uRr7cM8wfSjL// 9Oxcwv6MGRH1cKi3fD85jw6UQKadcXUuCiEIEnZQeypqCPn/98V3KDdSCOqebqog4zR4 0H5Q== X-Gm-Message-State: APjAAAXwKzrbFijlZF2lCMIbor5NZFJcfJZ4QMpHCVe6r9/EwWumHcJR 0S0aGi5wq5apRY+PfIwFtsFxdxta X-Google-Smtp-Source: APXvYqxjMffG89PcwEGzTizOEtuj770gnn8RcOhJNcc4h1KFBICK3dnV9Vu/pWz5EA5ZjbGaV4CVsA== X-Received: by 2002:aa7:820c:: with SMTP id k12mr55854901pfi.177.1558033369671; Thu, 16 May 2019 12:02:49 -0700 (PDT) Received: from [10.33.123.214] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id o20sm7109759pgj.70.2019.05.16.12.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2019 12:02:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mahesh Jethanandani In-Reply-To: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com> Date: Thu, 16 May 2019 12:02:47 -0700 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EE979DF-F274-44E1-B33F-FE70A50590F8@gmail.com> References: <0A966DA9-7CF7-4288-B636-70EABC184742@gmail.com> To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tcpm] Re-issue of adoption poll for draft-kwatsen-netconf-tcp-client-server-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 19:03:04 -0000 This closes this adoption poll. No comments or objections were received = during the poll. Therefore, this draft is now adopted as a WG item. = Author(s), please post this draft as = draft-ietf-netconf-tcp-client-server-00 without any modifications. Thanks. > On May 1, 2019, at 11:54 AM, Mahesh Jethanandani = wrote: >=20 > As noted in the mail yesterday to the NETCONF WG, I am issuing a new = poll on draft-kwatsen-netconf-tcp-client-server draft that was discussed = in 104. >=20 > There were comments that were received on the -00 draft that was = presented in 104, that have been addressed in the -02 version of the = draft. Since the original poll was on the -00 version of the draft, we = (the chairs), felt the need to re-issue the poll. Also, that poll = included the HTTP client/server draft, which is still under discussion, = and as such has been removed from this poll. >=20 > The TCP client/server draft did get support in 103, so rather than = asking for a repeat of that show of support, I am asking if there is any = objection to the adoption of this draft. If you do have an objection, = please state your reasons for why you feel this work should not be done. >=20 > The poll will run for two weeks, till May 15, and if no objections are = received by then, the draft will be adopted as a WG item. Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon May 20 09:23:39 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3624112017A for ; Mon, 20 May 2019 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dY_RDvjlZNku for ; Mon, 20 May 2019 09:23:36 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 831491201AA for ; Mon, 20 May 2019 09:23:36 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id a132so9127805qkb.13 for ; Mon, 20 May 2019 09:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PmAVUyjnXq+2CgfPIb4eyB7LmvxkhgoLLEJH8FPuoQA=; b=Rj2jbCh1pfNMehQTkbtAGYvJx9b05KKKTsrg/7flbxBKYgeF5LrMIKhPn/P/8ZEJpF ZIZT2qe+UjOoPpm/kx5HupmwRtxU9PJ0/PBZEn6jZoAZwHGSkWiHfi2pOn/TC6aur8vB Iy47bAnaMGmtkdMW9HmcN7RJiJSeVbWrqM6dBq7zjVIXz+nv4ROiEJDwdwJNautbUE8X s+xAubZUUf2Zo0sRsv114lZuZ4WwA8TQnVKFShApVG8Jc4coDMtpYxZDXiPt5CBRlaCB W91SNoXK+3ht4A8raQVhZH+TQTA8zkLyG2lF3Y2pfXdJvDrCnEgdjU3ZYNsvot7WRyHO lBhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PmAVUyjnXq+2CgfPIb4eyB7LmvxkhgoLLEJH8FPuoQA=; b=BShIGshDL3QzVn1BWTU8hAbJ1NkKg7zzsP3wqmwWBqGgYQ3aSrRwjbxM3cVS6E8AB6 sDakqUEMk63Oy58TQ9g0OLNbF/4q8YnikLZzwRhHb6O3OUux/COE56QQTWZyl5V/jv95 0tmvP0Y5d2qg4zcsy/IOcc6HuX6wivkPatNojbzjNuz5GX0+dvuYHXwfSAo+U4Z0/fSp lQ/a0TQck+af9zPuHRZQ+8Wa/xvtI2knj3TvKrmPqrddmEKMm1jgZlbfRIuKwPyjyJrL mXXqfaC1b9yy8Y9a84s1qmIM221mUhIfxhVN/yJt85RJEIzmLWs1yPHlAc5n02ZbQWIf Ikpw== X-Gm-Message-State: APjAAAXmdInRbcHMGy8lZ04L9T+QvmjLk67pRcWWwRFh5oedr7Rnnc5r VJLxyt29wMm3V+m0Eyl40NsAB1RjlQAop0BBRn6sdhCd X-Google-Smtp-Source: APXvYqxdYn+dpYbFfaF052OvakMibo20JdxUmLtFhfyIYN7WjiCYMhJOUaDDjWnTGYNVo4qP6ZywGUzbjrkxI31dckk= X-Received: by 2002:a37:8d84:: with SMTP id p126mr20899942qkd.72.1558369415593; Mon, 20 May 2019 09:23:35 -0700 (PDT) MIME-Version: 1.0 From: Marc Date: Mon, 20 May 2019 18:23:22 +0200 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tcpm] tcp window size X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 16:23:38 -0000 Hello experts, I've been trying to find definitive information about tcp window size negotiation, and if it exists at all. Take a browser that downloads a file (receiver) and a webserver (sender). If - both sender and receiver support window scaling - the receiver advertises a TCP winsize of 256KB - the sender advertises a window size of 32KB - the sender has enough space in its TCP send buffer (/proc/sys/net/ipv4/tcp_wmem on linux) How much 'outstanding unacked data' is the sender allowed to have, 32KB or 256KB ? I can't see any logic for it being limited to the window size of the sender (32KB), I think it depends on both the receiver winsize and the sender TCP Send Buffer Size, but I need to be sure. Reading https://tools.ietf.org/html/rfc793 also suggests there is no such thing like window size 'negotiation' and each end of a TCP connection just advertises its own to indicate how much data it can receive, independently. Is that correct ? Thanks! From nobody Mon May 20 09:54:23 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E311200F9 for ; Mon, 20 May 2019 09:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 szX4Hss6MTWI for ; Mon, 20 May 2019 09:54:19 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 CFE0C12004C for ; Mon, 20 May 2019 09:54:18 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id c66so377201wme.0 for ; Mon, 20 May 2019 09:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6UEf18HwQegFwupKU61h3ukLAAG2YWF4f/FgR5UTOI=; b=MrQEXwvbs/VvW1GgZNnPhOhBGOkdxBpHW5l+tTfMQu/0OGXG8jnhSBdccqzcEMpML4 GrtxduzYTtXg4U0HHj278FuCVZ29/IFdtnb2Vyw7pT7oTsyJ0bjlJQe8RTbqzq9hJ2mY uu0XrMMMH5lELcDJ8Uno6OE6Dv6DrGihSUt3p31G1+mVtz70ypOitOymQjA3hXZFyJ2U aVZrYKkwV7WQsIDEELFk4uyuniLZvs9O1F9p/a4Hj5ctazEOX5uCQbAdimcXSVcNz+1A SUT7ovCUdPxILt2dEW5rbaJeCf07n9d36CvLZO/a6LSCMC0ZbI9yxyNYlZ+aG6f5ulgq yKow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E6UEf18HwQegFwupKU61h3ukLAAG2YWF4f/FgR5UTOI=; b=gcOKswlWKsxcEqp7u0CIqjRjF/DTV/a4imxGYAZOTAljxrZCRh+v83c3Z+bhtl6iiC fAZGbUXdue4mdAW2xL9FD34Fcaz3Gf3G86e/qGozL9b3smwechI0l9+N2wTqe++O9YOB GBZJDwpwzeAhOvrIrTQ396QD5ByVh9H1Pp0/PL6c/aMbZOLsooNrnfbLu9mEkrUw2Fbl oacq6jt8bWuOAeqxY1VRujNOp3zsuL/WDmuy2YEh4GZqYmuIGKk20kfOjSB0phWQFAJ4 9Mij2YGZNI+h1tJUcZ/nwCj5R6OXvNvFjnlS0nxDNs64JUP21lUX90rgntHppJ/fLn3f kN0A== X-Gm-Message-State: APjAAAVzaTsZ5tvBx4RHrSybknN/vgRqV2qs08iMtfJbgnIEKbPw1T5I jOmLTJuXnRi3Dtc+TToBonY/jf6EnlGXnSOfVX0mWA== X-Google-Smtp-Source: APXvYqzcgIMR3At9frS8Us7ltvq35ldf9ehb+LH8MzvdwxQ4v22PTGCmpHn6Kqi7i7fiAWYneLvB8VFaNYjAOTi4phQ= X-Received: by 2002:a1c:f311:: with SMTP id q17mr78396wmq.144.1558371256693; Mon, 20 May 2019 09:54:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 20 May 2019 09:53:40 -0700 Message-ID: To: Marc Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] tcp window size X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 16:54:21 -0000 On Mon, May 20, 2019 at 9:23 AM Marc wrote: > > Hello experts, > > I've been trying to find definitive information about tcp window size > negotiation, and if it exists at all. > > Take a browser that downloads a file (receiver) and a webserver (sender). If > - both sender and receiver support window scaling > - the receiver advertises a TCP winsize of 256KB > - the sender advertises a window size of 32KB > - the sender has enough space in its TCP send buffer > (/proc/sys/net/ipv4/tcp_wmem on linux) > > How much 'outstanding unacked data' is the sender allowed to have, > 32KB or 256KB ? > > I can't see any logic for it being limited to the window size of the > sender (32KB), I think it depends on both the receiver winsize and the > sender TCP Send Buffer Size, but I need to be sure. > > Reading https://tools.ietf.org/html/rfc793 also suggests there is no > such thing like window size 'negotiation' and each end of a TCP > connection just advertises its own to indicate how much data it can > receive, independently. > > Is that correct ? That's correct. It's FYI not negotiated. > > Thanks! > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 20 10:07:28 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D25E1200A3 for ; Mon, 20 May 2019 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 7xjOB9tWuV6D for ; Mon, 20 May 2019 10:07:23 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 4D547120073 for ; Mon, 20 May 2019 10:07:23 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id d18so15472666wrs.5 for ; Mon, 20 May 2019 10:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to :content-transfer-encoding; bh=+/NLy5yIqMEK7ffbDgCZG2Cbkfl+WhAsFzpjhlXxAyw=; b=aN6OJ3Sttea78kZsxekC3BVktkq8kQHpEN4QJTiQR0Gqa5StKhRktsbpkaOqhdJYtq Hsp2fGkIPP3/kaNOA71N2YJGbc6GnzejYyrJKjFkbHwCIZ5gX/WL/ofMk0PNEP3Rkvjr DLs9JKvOnTJJexkAniFxOYLJOnPRYfwNOLNysNgMTUByjTYx56/CvnStAeq5wrLaPa6N /17ButGqM8WxlzUc/hHBFq8WDQw/ouQQPjOzra7qgzRU8kQBOaLEgB8TX+PHntAKz5e7 WjdP3hsJT5JNg25yf8pNi+/XWTM6kp+3BtlmTQk2w+OFMzPTFKxLCqIL+n+Lp506zsXE 8KeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to :content-transfer-encoding; bh=+/NLy5yIqMEK7ffbDgCZG2Cbkfl+WhAsFzpjhlXxAyw=; b=NvE+OaVYfb02uuEZro4xirbhOOZ7/x5AfcbTR/bEHWiomk+qlosag5Ls7nmd9QUW30 JvIBpT6NcvnoxWvjeB8hUdvx9a1KLpeiuHM0GcbdUHic35hBF51oidoYGGHDbz3FHsdK eg89skOKFkkR4pp/lYPS/cXB3MpSKdW8iMT2b1dgi8Io5pLTAdvIuf8FBPUtWzgrkocY w++TYu4trH9H8ntAxffe2mzAXTxQwbRT9p4S5nM0A0RdKo4OXpPG+0e6m+vXDrodZPOg S+R7WCCX21ntWjIWv+LQx98cOKc0olH1ldcpExWxgA8fPgFRie527f/NQoh+uhQbLxzI GzVg== X-Gm-Message-State: APjAAAXnNcuxw4fP0ZDYg4Oky2KrFEww0KQ+sIyWvkGL4+J5qcoImol5 j+XIRYwE3i9Y68EZXpiySqMRwB4y1BD9YgZBNg3W41yczFFD18HNFU5Ne/92yMsQiul7QxsS8tU BIQ== X-Google-Smtp-Source: APXvYqxnjFnR1H0vvsHMjKCZnMROLydYL8nOhEXwXCqh3J5diawf/OixU2cu3pP634RsEy21Xo/dJg== X-Received: by 2002:adf:f041:: with SMTP id t1mr40673569wro.74.1558372041391; Mon, 20 May 2019 10:07:21 -0700 (PDT) Received: from ?IPv6:2001:6a8:308f:2:e028:e7a6:1a3c:937a? ([2001:6a8:308f:2:e028:e7a6:1a3c:937a]) by smtp.gmail.com with ESMTPSA id q13sm18307399wrn.27.2019.05.20.10.07.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 10:07:20 -0700 (PDT) From: Olivier Bonaventure Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: Date: Mon, 20 May 2019 19:07:19 +0200 To: tcpm@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 17:07:27 -0000 Hello, During the Prague meeting, I presented the updated version of draft-ietf-tc= pm-converter. This new draft places data inside the SYN, but does not use t= he TFO option defined in RFC7413. After the meeting, we had some discussion= s by email with Praveen Balasubramanian and Christoph Paasch. Praveen sugge= sted to use an empty TFO option, but we do not believe that this would be a= good solution. I would like to summarise the main points of the discussion= and solicit the opinion of the working group. According to RFC793, a SYN can contain a non-zero payload. The Experimental= RFC7413 proposes the utilisation of a cookie to protect the server from s= ome forms of attacks. RFC7413 was designed for generic application-level th= at do not include the possibility of placing the cookie in the first packet= of the payload. For this reason, RFC7413 uses a TCP option to encode the c= ookie. This design choice limits the length of the cookies and thus their s= ecurity. The 0-RTT convert protocol is a specialised application level protocol that= takes a different approach by putting the cookie inside the SYN payload as= part of the application data. This reduces the consumption of TCP options = and enables the utilisation of longer and more secure cookies. We believe t= hat this is the right approach in the long term.=20 We believe that a specialised TCP application should be allowed to use its = own cookie inside the payload instead of relying on the TCP header to use f= ast open. The 0-RTT convert protocol is one example, but there could be oth= ers. Looking at other application layer protocols, I noticed that TLS1.3 (r= fc8446) also includes a cookie which is mainly designed enable servers to g= et a confirmation of the reachability of the client IP addresses for DTLS, = but the same approach could be used when TLS sends its initial data in the = SYN as well.=20 Another point that should be clarified in RFC7413 are how middleboxes shoul= d handle SYN packets containing a non-zero payload. According to RFC793, su= ch packets are valid TCP packets. The TFO option, defined in RFC7314 is not= and should not be considered as an indication that is required to =E2=80= =9Cauthorise=E2=80=9D the utilisation of payload inside a SYN packet. Durin= g the Prague meeting, Christoph Paasch mentioned at the mike that they have= one application that uses data inside the SYN and their measurements indic= ate that sending this SYN without the TFO option enables it to pass through= more middleboxes than when the same SYN contains the TFO option. Another point is the socket API. Currently, Linux and MacOS decouple the tr= ansmission of data inside the SYN from the utilisation of the TFO option. T= his makes it possible for a client to send data inside the SYN without enab= ling TFO. On Windows, the API seems to force the utilisation of TFO when th= ere is data in the SYN. As indicated earlier, RFC793 does not mandate the p= resence of the TFO to place data inside the SYN.=20 The approach we are proposing has the benefits of RFC7413 but without its d= rawbacks. Moreover, given that RFC7413 is Experimental, we don't think that= there is a harm if we proceed with the approach 0-rtt convert protocol whi= le the IETF can further tweak and adjust the applicability scope of RFC7413= . For example, an update can be proposed to RFC7413 to clarify that special= ized application-level protocols could place cookie information in their pa= yload and thus not use the TFO option.=20 As indicated during the Prague meeting, we would like to finalize the 0-rtt= convert protocol soon. Unless there are objections, we would like to ask t= o kindly issue a WGLC for the draft. Comments are more than welcome.=20 Olivier and Med --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 From nobody Mon May 20 10:24:43 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0D1201C3 for ; Mon, 20 May 2019 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.41 X-Spam-Level: X-Spam-Status: No, score=-7.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, URIBL_SBL=10, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 cHzyh57Nh6a1 for ; Mon, 20 May 2019 10:24:39 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 5D58A120091 for ; Mon, 20 May 2019 10:24:39 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 198so163031wme.3 for ; Mon, 20 May 2019 10:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/HonKtfs/FRHJo41zIQVkiTqQ/3QZmLS2eydSvP8R4g=; b=JWN2yUchzFcOfW3dZcO6i1IZzGN7QRqLVi1UFmUgvr6Pch9nU4RN66H8OKMoVpQdFj RtAsSWOYskyrWGGOg1RhWLe1bDrH6vCpXn0tUvESv6JY7T7WQkyO0KAwZz1AWGU7jc+0 kAnWPAsS3xBQMgIKVX5KrkDscmMBFAN6TNBV+0p5jnhSsHCA8iynQ5rqHmAUmi758Nk8 eHjglBe7/G/NDoPBS3r2KjWngw3+jDNUZuDigFRIXmrWUw45+cmnh9VbbrSctqzQktdi 7xIvJ8Zej+sEISieBItVzXeQKV5UWATDGfy9eTTBxFht2k8lQ1Ai30baJVeps+L1ZYjS Hsvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/HonKtfs/FRHJo41zIQVkiTqQ/3QZmLS2eydSvP8R4g=; b=JbpG0mYrvOsyjMTIsUeD7raYrtQOolVhSdWwjeMmqnsExxQxHvC16qeOgmkAeBCTMl aLDmnhrh4aexBMNKWsFNjkdS5ShTml6DNVFu//mpZTZYagRWQInGI9jArSN89vvYwm5o Z5vW2daMd5wK8QxTtOHC/hToD0wu1zGMEi1LzLl8MDmYImyUXnECrNGUG38eHFVGjTq0 n9lOfHqvlvlPKRZG5KD0W98BINFUv6U8/k9s0dI9iXkEBj6cTlbZ8FdT//qLLHggEMcB WCYDC2WSEsiGTpxeGawaiFDL0KtEjZMfKLbGCcRsiI5WihObd/+Yo0mIp+y8JELMw+jz EAvA== X-Gm-Message-State: APjAAAXOVUiM1DAcEK+xKyKn+xeg0PbHsEW8gt1WYaRPSVd9zwp1Xp/o Iua75dpPvmKg72kLBHjvwYCiM3rD+qjxI4kqy6Pflw== X-Google-Smtp-Source: APXvYqxtv1n+Exrb3B80AXwqVJkyHC0KNxxCjSa4t8jvMkQwbsa2GVsdULaFGtDnWBXkDg3Bckpx44dNoeWAJmXhckg= X-Received: by 2002:a1c:6206:: with SMTP id w6mr201315wmb.56.1558373077240; Mon, 20 May 2019 10:24:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Mon, 20 May 2019 10:24:00 -0700 Message-ID: To: Olivier Bonaventure Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 17:24:42 -0000 On Mon, May 20, 2019 at 10:07 AM Olivier Bonaventure wrote: > > Hello, > > During the Prague meeting, I presented the updated version of draft-ietf-= tcpm-converter. This new draft places data inside the SYN, but does not use= the TFO option defined in RFC7413. After the meeting, we had some discussi= ons by email with Praveen Balasubramanian and Christoph Paasch. Praveen sug= gested to use an empty TFO option, but we do not believe that this would be= a good solution. I would like to summarise the main points of the discussi= on and solicit the opinion of the working group. > > According to RFC793, a SYN can contain a non-zero payload. The Experiment= al RFC7413 proposes the utilisation of a cookie to protect the server from= some forms of attacks. RFC7413 was designed for generic application-level = that do not include the possibility of placing the cookie in the first pack= et of the payload. For this reason, RFC7413 uses a TCP option to encode the= cookie. This design choice limits the length of the cookies and thus their= security. > > The 0-RTT convert protocol is a specialised application level protocol th= at takes a different approach by putting the cookie inside the SYN payload = as part of the application data. This reduces the consumption of TCP option= s and enables the utilisation of longer and more secure cookies. We believe= that this is the right approach in the long term. > > We believe that a specialised TCP application should be allowed to use it= s own cookie inside the payload instead of relying on the TCP header to use= fast open. The 0-RTT convert protocol is one example, but there could be o= thers. Looking at other application layer protocols, I noticed that TLS1.3 = (rfc8446) also includes a cookie which is mainly designed enable servers to= get a confirmation of the reachability of the client IP addresses for DTLS= , but the same approach could be used when TLS sends its initial data in th= e SYN as well. > > Another point that should be clarified in RFC7413 are how middleboxes sho= uld handle SYN packets containing a non-zero payload. According to RFC793, = such packets are valid TCP packets. The TFO option, defined in RFC7314 is n= ot and should not be considered as an indication that is required to =E2=80= =9Cauthorise=E2=80=9D the utilisation of payload inside a SYN packet. Durin= g the Prague meeting, Christoph Paasch mentioned at the mike that they have= one application that uses data inside the SYN and their measurements indic= ate that sending this SYN without the TFO option enables it to pass through= more middleboxes than when the same SYN contains the TFO option. > > Another point is the socket API. Currently, Linux and MacOS decouple the = transmission of data inside the SYN from the utilisation of the TFO option.= This makes it possible for a client to send data inside the SYN without en= abling TFO. On Windows, the API seems to force the utilisation of TFO when = there is data in the SYN. As indicated earlier, RFC793 does not mandate the= presence of the TFO to place data inside the SYN. > > The approach we are proposing has the benefits of RFC7413 but without its= drawbacks. Moreover, given that RFC7413 is Experimental, we don't think th= at there is a harm if we proceed with the approach 0-rtt convert protocol w= hile the IETF can further tweak and adjust the applicability scope of RFC74= 13. For example, an update can be proposed to RFC7413 to clarify that speci= alized application-level protocols could place cookie information in their = payload and thus not use the TFO option. Just to confirm: you mean an API that let application sets the TFO cookie (on either server and client)? otherwise obviously application can place any data in their TCP payload for= its purposes. > > As indicated during the Prague meeting, we would like to finalize the 0-r= tt convert protocol soon. Unless there are objections, we would like to ask= to kindly issue a WGLC for the draft. > > Comments are more than welcome. > > > Olivier and Med > > > > > -- > > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon May 20 12:37:35 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0B8120115 for ; Mon, 20 May 2019 12:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xh2Eg3eR4elZ for ; Mon, 20 May 2019 12:37:32 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 15E2112010E for ; Mon, 20 May 2019 12:37:32 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id j187so516552wmj.1 for ; Mon, 20 May 2019 12:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g9fdLUuCd2t2LsPmxGO0heUOtU39LUwvps5u43jKdAU=; b=ru+wDgylL/5sRTBNkgohjGruAOSO2Kh7tTg/rI6OM4iX/UfPHUSMOZKhJuIpT39Qtg WEqWtuSSLQc9DPM7VPYXeaDAlV7hQZZw6KbL38hxZHKbQ2y0mSML6efxav3n+kESd4uS bxB0deyBtMM03K/P9shJxk3ftugH+Jl3G4q7plUInFCaLzvlPTQ1qNVJP8lyiDdHxkfP 2XnW/Frm7kUouTyJHyzRrIi1Q546ZC3Ec8OWFBgcZNT4f7POh4+iD5NE9D/dvdm2B220 I71O3QUuXXUBqjb5Z1r2Ca9A0ZndY+ATcSUwftleYFykM4yOu02O8FrtQc5TKCtfCRUg ainA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g9fdLUuCd2t2LsPmxGO0heUOtU39LUwvps5u43jKdAU=; b=Z+lBbtcW2NTYQ13E1J5BtHZPtUf58i18M4dEQExUjLpO4N1q2MaV14T/fPrrUTajKV +jb4KJrfOQrNIsi8bCTQZlRUM375CURBUuDf8mn5JruamnauPUJR1Lu33jviISHuw4ay WCh55+SW9BepYaMYr7wfh5TXrWVvQeriD8Me502Stt4h9R9FwPj+ty217fyFfYailK2x OTo2CWUgQPYjSkkmM1nZ80CocHT3VORoDv87o+yKMSul1PkrvhlEF6WeekPpa55ICYAz uqIn27dCPQM+GMnOcijWJ97wrSv16GbhlhO8UFEWHexvayMCqV1zeRtz5mm+3Gyulu02 qJEg== X-Gm-Message-State: APjAAAW8PE56Y+cdoBquR4g3msePTVXRfX4GNHuPr5Cmb+ncZXJd91T4 xBtpNJXP2XkvuZxLADTlK/75AFPBxeni49TeEHc= X-Google-Smtp-Source: APXvYqxXxXgN49re8mdl7tGEoIYQB7cODJRYD2oeT/NUYWK1UnLU+H1EaknULZtaV2JYnjJ6BkPeKbxI0ODyWG1pJ0U= X-Received: by 2002:a1c:658b:: with SMTP id z133mr554308wmb.82.1558381050679; Mon, 20 May 2019 12:37:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Mon, 20 May 2019 12:37:19 -0700 Message-ID: To: Marc Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000f35657058956dc04" Archived-At: Subject: Re: [tcpm] tcp window size X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 19:37:34 -0000 --000000000000f35657058956dc04 Content-Type: text/plain; charset="UTF-8" Hi Marc, On Mon, May 20, 2019 at 9:23 AM Marc wrote: > Hello experts, > > I've been trying to find definitive information about tcp window size > negotiation, and if it exists at all. > > Take a browser that downloads a file (receiver) and a webserver (sender). > If > - both sender and receiver support window scaling > - the receiver advertises a TCP winsize of 256KB > - the sender advertises a window size of 32KB > - the sender has enough space in its TCP send buffer > (/proc/sys/net/ipv4/tcp_wmem on linux) > > How much 'outstanding unacked data' is the sender allowed to have, > 32KB or 256KB ? > advertised window is receiving buffer size on each side. > I can't see any logic for it being limited to the window size of the > sender (32KB), I think it depends on both the receiver winsize and the > sender TCP Send Buffer Size, but I need to be sure. > > Reading https://tools.ietf.org/html/rfc793 also suggests there is no > such thing like window size 'negotiation' and each end of a TCP > connection just advertises its own to indicate how much data it can > receive, independently. > > Is that correct ? > yep, correct. -- Yoshi --000000000000f35657058956dc04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Marc,

On Mon, May 20, 20= 19 at 9:23 AM Marc <gaardiolor@gmail.com> wrote:
Hello experts,

I've been trying to find definitive information about tcp window size negotiation, and if it exists at all.

Take a browser that downloads a file (receiver) and a webserver (sender). I= f
- both sender and receiver support window scaling
- the receiver advertises a TCP winsize of 256KB
- the sender advertises a window size of 32KB
- the sender has enough space in its TCP send buffer
(/proc/sys/net/ipv4/tcp_wmem on linux)

How much 'outstanding unacked data' is the sender allowed to have,<= br> 32KB or 256KB ?

advertised window is re= ceiving buffer size on each side.=C2=A0
=C2=A0
I can't see any logic for it being limited to the window size of the sender (32KB), I think it depends on both the receiver winsize and the
sender TCP Send Buffer Size, but I need to be sure.

Reading https://tools.ietf.org/html/rfc793 also suggests there= is no
such thing like window size 'negotiation' and each end of a TCP
connection just advertises its own to indicate how much data it can
receive, independently.

Is that correct ?

yep, correct.
--
Yoshi=C2=A0
--000000000000f35657058956dc04-- From nobody Mon May 20 14:19:34 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEF41200B4 for ; Mon, 20 May 2019 14:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 hArwm01U7LU4 for ; Mon, 20 May 2019 14:19:30 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 3C6E112004E for ; Mon, 20 May 2019 14:19:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 3ABA8114 for ; Mon, 20 May 2019 23:19:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7te6IqSPl7xO for ; Mon, 20 May 2019 23:19:27 +0200 (CEST) Received: from users-MBP.fritz.box (i577AF203.versanet.de [87.122.242.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 753FD113 for ; Mon, 20 May 2019 23:19:27 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: tcpm@ietf.org References: From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: Date: Mon, 20 May 2019 23:19:26 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 21:19:33 -0000 I think it is important to warn users about the privacy risks of RFC 7413. For example, Mozilla reacted to the privacy problems of TCP Fast Open by deprecating this protocol on all it's Firefox branches. In total, TCP Fast Open has significant issues with respect to user privacy, performance and deployment on the real-world Internet. From my point of view, it is about time to deprecate RFC 7413. Regards, Erik On 5/10/19 14:14, Erik Sy wrote: > Hi everyone, > > TCP Fast Open has significant privacy problems which are not considered > in RFC 7413. > For example, this protocol allows a passive network observer to > correlate connections established by the same client, which protocols > such as TLS 1.3 and QUIC actively protect against. Furthermore, Fast > Open cookies present a kernel-based tracking mechanism which is quite > persistent. Amongst others, they can be used to conduct cross-browser > tracking on the same operating system. > For further details please refer to this article: > https://arxiv.org/pdf/1905.03518.pdf > > I suggest, that the working group takes steps to highlight these privacy > problems of RFC 7413. > > Regards, > Erik > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 00:13:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D841C12017E for ; Tue, 21 May 2019 00:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 0_4JNMq03nAF for ; Tue, 21 May 2019 00:13:17 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A963120167 for ; Tue, 21 May 2019 00:13:16 -0700 (PDT) Received: from [IPv6:2a02:c6a0:4015:12:245d:a85d:1:989e] (unknown [IPv6:2a02:c6a0:4015:12:245d:a85d:1:989e]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 3224F721E281C; Tue, 21 May 2019 09:13:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: Date: Tue, 21 May 2019 09:13:11 +0200 Cc: tcpm@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> References: To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 07:13:21 -0000 > On 20. May 2019, at 23:19, Erik Sy wrote: > > I think it is important to warn users about the privacy risks of RFC > 7413. For example, Mozilla reacted to the privacy problems of TCP Fast > Open by deprecating this protocol on all it's Firefox branches. In > total, TCP Fast Open has significant issues with respect to user > privacy, performance and deployment on the real-world Internet. From my > point of view, it is about time to deprecate RFC 7413. Hi Eric, my understanding is that a cookie is specific to a client address, a server address and a server port. So it would make sense for a client to remove entries from the cookie cache on an address change. Assuming that, how does your described host based attacks relate to the server just using the client IP address for tracking? If you are trying to hide you IP-address (like using a TOR browser) you don't want to use TFO, but you are not optimising for small RTTs in that case, so it makes no sense in that case. Best regards Michael > > Regards, > Erik > > On 5/10/19 14:14, Erik Sy wrote: > >> Hi everyone, >> >> TCP Fast Open has significant privacy problems which are not considered >> in RFC 7413. >> For example, this protocol allows a passive network observer to >> correlate connections established by the same client, which protocols >> such as TLS 1.3 and QUIC actively protect against. Furthermore, Fast >> Open cookies present a kernel-based tracking mechanism which is quite >> persistent. Amongst others, they can be used to conduct cross-browser >> tracking on the same operating system. >> For further details please refer to this article: >> https://arxiv.org/pdf/1905.03518.pdf >> >> I suggest, that the working group takes steps to highlight these privacy >> problems of RFC 7413. >> >> Regards, >> Erik >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 00:52:17 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6D012007C for ; Tue, 21 May 2019 00:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lU6PBJRB8AOn for ; Tue, 21 May 2019 00:52:14 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 E533312006E for ; Tue, 21 May 2019 00:52:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 8ABFD188; Tue, 21 May 2019 09:52:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 52KbZVavO0NE; Tue, 21 May 2019 09:52:11 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id BF49F187; Tue, 21 May 2019 09:52:10 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm@ietf.org References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 09:52:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 07:52:17 -0000 Hi Michael, thanks for this question! Yes, TFO cookies are bound to the clients (local) IP address. However, a client with a static local IP address in a home network will use the same TFO cookie independently of it's publicly visible IP address. As a result, TFO cookies present an independent tracking mechanism, which does not necessarily rely on the client's publicly visible IP address. Returning to your example, onion routing does not necessarily protect you against tracking via TFO cookies. Best regards, Erik On 5/21/19 09:13, Michael Tuexen wrote: >> On 20. May 2019, at 23:19, Erik Sy wrote: >> >> I think it is important to warn users about the privacy risks of RFC >> 7413. For example, Mozilla reacted to the privacy problems of TCP Fast >> Open by deprecating this protocol on all it's Firefox branches. In >> total, TCP Fast Open has significant issues with respect to user >> privacy, performance and deployment on the real-world Internet. From my >> point of view, it is about time to deprecate RFC 7413. > Hi Eric, > > my understanding is that a cookie is specific to a client address, a server > address and a server port. So it would make sense for a client to remove > entries from the cookie cache on an address change. Assuming that, how > does your described host based attacks relate to the server just using > the client IP address for tracking? If you are trying to hide you IP-address > (like using a TOR browser) you don't want to use TFO, but you are not > optimising for small RTTs in that case, so it makes no sense in that case. > > Best regards > Michael >> Regards, >> Erik >> >> On 5/10/19 14:14, Erik Sy wrote: >> >>> Hi everyone, >>> >>> TCP Fast Open has significant privacy problems which are not considered >>> in RFC 7413. >>> For example, this protocol allows a passive network observer to >>> correlate connections established by the same client, which protocols >>> such as TLS 1.3 and QUIC actively protect against. Furthermore, Fast >>> Open cookies present a kernel-based tracking mechanism which is quite >>> persistent. Amongst others, they can be used to conduct cross-browser >>> tracking on the same operating system. >>> For further details please refer to this article: >>> https://arxiv.org/pdf/1905.03518.pdf >>> >>> I suggest, that the working group takes steps to highlight these privacy >>> problems of RFC 7413. >>> >>> Regards, >>> Erik >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 02:40:16 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7013C120048 for ; Tue, 21 May 2019 02:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 riHAvURdDsPs for ; Tue, 21 May 2019 02:40:03 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 D92EA120142 for ; Tue, 21 May 2019 02:40:02 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hT1FW-000Cm7-Na; Tue, 21 May 2019 11:39:58 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1hT1FV-000DKS-PX; Tue, 21 May 2019 11:39:58 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 11:39:55 +0200 Cc: Michael Tuexen , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5A1B826E94BB3C4242CAB74D7415A8435CEDAD09 Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 09:40:15 -0000 Hi all, I'm about to make a fool of myself because I'm quite certain that I'm = missing something. But, I guess this is worth the risk - somehow I'm not risking much, as = most people on this list already know me well enough to not be surprised = by another foolish idea coming from me :) So... Actually, couldn't we just remove the cookie from TFO? As far as I understand, the main point of the cookie is to protect the = server against clients that might spoof their IP addresses and just send = tons of requests to the server - which could potentially be much heavier = to handle than just the SYN state without TFO. To some degree, this is an OS problem, not a network problem: methods = could be in place to limit the time an application spends answering = requests that are carried on SYNs. My question is: wouldn't that be = enough? A few years ago, I'm sure that such a proposal would have been shot by = people saying that data carried by TCP is general and TCP must serve all = applications, and that we can't have that kind of special treatment for = data arriving via SYNs. However, TFO has already departed from this generality, in several ways: = applications using it must be able to handle incoming duplicate = requests; they need to use special API calls to access the data; = importantly (for the point I'm making), rate limits should already be in = place when using TFO (RFC 7413, section 5.1). So what I'm proposing is: couldn't we re-write TFO to just remove the = Cookie from it, and say: "it's allowed for applications to accept data = that comes with a SYN right away, but this must be done in a special way = (as already described in RFC 7413), and in particular, the time an = application spends processing TFO requests must be limited to avoid = being DDoSed?" If a server is overloaded and can't process any more TFO data, the = result could be that it just doesn't answer at all, and the client would = then retransmit the SYN, just as if the SYN had been dropped. Cheers, Michael > On 21 May 2019, at 09:52, Erik Sy = wrote: >=20 > Hi Michael, >=20 > thanks for this question! >=20 > Yes, TFO cookies are bound to the clients (local) IP address. However, = a > client with a static local IP address in a home network will use the > same TFO cookie independently of it's publicly visible IP address. As = a > result, TFO cookies present an independent tracking mechanism, which > does not necessarily rely on the client's publicly visible IP address. >=20 > Returning to your example, onion routing does not necessarily protect > you against tracking via TFO cookies. >=20 > Best regards, > Erik >=20 > On 5/21/19 09:13, Michael Tuexen wrote: >>> On 20. May 2019, at 23:19, Erik Sy = wrote: >>>=20 >>> I think it is important to warn users about the privacy risks of RFC >>> 7413. For example, Mozilla reacted to the privacy problems of TCP = Fast >>> Open by deprecating this protocol on all it's Firefox branches. In >>> total, TCP Fast Open has significant issues with respect to user >>> privacy, performance and deployment on the real-world Internet. =46rom= my >>> point of view, it is about time to deprecate RFC 7413. >> Hi Eric, >>=20 >> my understanding is that a cookie is specific to a client address, a = server >> address and a server port. So it would make sense for a client to = remove >> entries from the cookie cache on an address change. Assuming that, = how >> does your described host based attacks relate to the server just = using >> the client IP address for tracking? If you are trying to hide you = IP-address >> (like using a TOR browser) you don't want to use TFO, but you are not >> optimising for small RTTs in that case, so it makes no sense in that = case. >>=20 >> Best regards >> Michael >>> Regards, >>> Erik >>>=20 >>> On 5/10/19 14:14, Erik Sy wrote: >>>=20 >>>> Hi everyone, >>>>=20 >>>> TCP Fast Open has significant privacy problems which are not = considered >>>> in RFC 7413. >>>> For example, this protocol allows a passive network observer to >>>> correlate connections established by the same client, which = protocols >>>> such as TLS 1.3 and QUIC actively protect against. Furthermore, = Fast >>>> Open cookies present a kernel-based tracking mechanism which is = quite >>>> persistent. Amongst others, they can be used to conduct = cross-browser >>>> tracking on the same operating system. >>>> For further details please refer to this article: >>>> https://arxiv.org/pdf/1905.03518.pdf >>>>=20 >>>> I suggest, that the working group takes steps to highlight these = privacy >>>> problems of RFC 7413. >>>>=20 >>>> Regards, >>>> Erik >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 03:18:58 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0176C120108 for ; Tue, 21 May 2019 03:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01] 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 Lkfz6GStrHFZ for ; Tue, 21 May 2019 03:18:54 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C3B120048 for ; Tue, 21 May 2019 03:18:53 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:207d:baab:61e5:af0] (p200300CD6F384A00207DBAAB61E50AF0.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:207d:baab:61e5:af0]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 751E3721E281C; Tue, 21 May 2019 12:18:49 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 12:18:48 +0200 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 10:18:57 -0000 > On 21. May 2019, at 09:52, Erik Sy = wrote: >=20 > Hi Michael, >=20 > thanks for this question! >=20 > Yes, TFO cookies are bound to the clients (local) IP address. However, = a > client with a static local IP address in a home network will use the > same TFO cookie independently of it's publicly visible IP address. As = a > result, TFO cookies present an independent tracking mechanism, which > does not necessarily rely on the client's publicly visible IP address. How often do the public addresses change? One could extend the TFO API = in a way that the application can request a new cookie by only sending=20 a cookie request. >=20 > Returning to your example, onion routing does not necessarily protect > you against tracking via TFO cookies. Yepp, that is what I wanted to say. But using TFO in that case doesn't make much sense. Best regards Michael >=20 > Best regards, > Erik >=20 > On 5/21/19 09:13, Michael Tuexen wrote: >>> On 20. May 2019, at 23:19, Erik Sy = wrote: >>>=20 >>> I think it is important to warn users about the privacy risks of RFC >>> 7413. For example, Mozilla reacted to the privacy problems of TCP = Fast >>> Open by deprecating this protocol on all it's Firefox branches. In >>> total, TCP Fast Open has significant issues with respect to user >>> privacy, performance and deployment on the real-world Internet. =46rom= my >>> point of view, it is about time to deprecate RFC 7413. >> Hi Eric, >>=20 >> my understanding is that a cookie is specific to a client address, a = server >> address and a server port. So it would make sense for a client to = remove >> entries from the cookie cache on an address change. Assuming that, = how >> does your described host based attacks relate to the server just = using >> the client IP address for tracking? If you are trying to hide you = IP-address >> (like using a TOR browser) you don't want to use TFO, but you are not >> optimising for small RTTs in that case, so it makes no sense in that = case. >>=20 >> Best regards >> Michael >>> Regards, >>> Erik >>>=20 >>> On 5/10/19 14:14, Erik Sy wrote: >>>=20 >>>> Hi everyone, >>>>=20 >>>> TCP Fast Open has significant privacy problems which are not = considered >>>> in RFC 7413. >>>> For example, this protocol allows a passive network observer to >>>> correlate connections established by the same client, which = protocols >>>> such as TLS 1.3 and QUIC actively protect against. Furthermore, = Fast >>>> Open cookies present a kernel-based tracking mechanism which is = quite >>>> persistent. Amongst others, they can be used to conduct = cross-browser >>>> tracking on the same operating system. >>>> For further details please refer to this article: >>>> https://arxiv.org/pdf/1905.03518.pdf >>>>=20 >>>> I suggest, that the working group takes steps to highlight these = privacy >>>> problems of RFC 7413. >>>>=20 >>>> Regards, >>>> Erik >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 04:52:27 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BBF12015E for ; Tue, 21 May 2019 04:52: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 l1LRAgE7V2P0 for ; Tue, 21 May 2019 04:52:23 -0700 (PDT) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 4D4BC12012D for ; Tue, 21 May 2019 04:52:23 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id e15so18280089wrs.4 for ; Tue, 21 May 2019 04:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to:content-transfer-encoding; bh=kwZi8LaOL0O1cRz2UJFTEqMenmJjh5+OJqvAaDJ+dRM=; b=j2xNu84uZz91d1RD8NIjsoNMRNJy6T/yyF+Bx+vDb6dSxob9trRvPbyFd9pMGxM41G sNBhZOR1j2+F2692ZAevz23TDXLMT0S4mVOCmiJanLJrl40ScdCHx7vkxSsQk9h+hPub 0floviFCZCD8+s65zCJwBfXSEDhfAE8P8iBHlnxPP37wBUCV/S4BTSM06uS/GyhXRYjv MTqNBB368ARRGAO2wdWK34hmv1xwapLJeaOfdu5Dm2j6g/rWFzb9NwxGhvGJXQhO8fcb +nbr8mDkDpwjr+6W308fP+XdPxuWuV2cCyGgnLqA9Rkylx/HcGBKTr1sx0eSA0G+Xq77 L9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:content-transfer-encoding; bh=kwZi8LaOL0O1cRz2UJFTEqMenmJjh5+OJqvAaDJ+dRM=; b=GMez7ZiHXLhprc5V078DgOptHlUC9cHLTN3UnkICgA04Rg61GUZxLJyQbua2HWcpln x0/Q707rGtlEF806Xm7XaDuBqUvfVNj2KVBkUDYgJ1lpzE/Zn8KrVx45UPGLfPN71Met L+W1/lTI14i6aaCBjqWIx68IMrUMc0MtRroJxDZAw+TfNHbeCfrDeaVp4rcdeUWkg62X ccW1i/OJOKvOZ/NPFqCfJuZs0fNaNKP2loWw8Xb92M5Lv+guweStxpzTTS2sEHPD3m/w 9oBa9Pp9MtwnAGsGPcmAo3CzJ+cCXu95qPj2dwjGwu2csIZOsbOIQJONCE9o/iy5x9jy nE/g== X-Gm-Message-State: APjAAAUZz+eUKXCoZxSeoNWQ3KPbqODfOU4mQ92mQOsRMxykV3JC8bkE YvXIuJ5F+1NeJ6qEFhL8cpAuKPILaEs6vGAUV5S9DVNt1Xhy3Qj1/qrJVGUdoMCPE89cVO21 X-Google-Smtp-Source: APXvYqz7iWSPParkgprskvCpEEIxbXFcHCVStzKWgfZcqEjNZSwAA1u7bA/AI08qRUlReIYaCokFdg== X-Received: by 2002:adf:ce90:: with SMTP id r16mr51548822wrn.156.1558439541754; Tue, 21 May 2019 04:52:21 -0700 (PDT) Received: from ?IPv6:2001:6a8:308f:2:9cf9:5d5b:52e7:b807? ([2001:6a8:308f:2:9cf9:5d5b:52e7:b807]) by smtp.gmail.com with ESMTPSA id a15sm5173210wrw.49.2019.05.21.04.52.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 May 2019 04:52:21 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Olivier Bonaventure In-Reply-To: Date: Tue, 21 May 2019 13:52:18 +0200 Cc: "tcpm@ietf.org Extensions" Message-Id: References: To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.104.8) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 11:52:26 -0000 Yuchung, >>=20 >> We believe that a specialised TCP application should be allowed to use i= ts own cookie inside the payload instead of relying on the TCP header to us= e fast open. The 0-RTT convert protocol is one example, but there could be = others. Looking at other application layer protocols, I noticed that TLS1.3= (rfc8446) also includes a cookie which is mainly designed enable servers t= o get a confirmation of the reachability of the client IP addresses for DTL= S, but the same approach could be used when TLS sends its initial data in t= he SYN as well. >>=20 >> Another point that should be clarified in RFC7413 are how middleboxes sh= ould handle SYN packets containing a non-zero payload. According to RFC793,= such packets are valid TCP packets. The TFO option, defined in RFC7314 is = not and should not be considered as an indication that is required to =E2= =80=9Cauthorise=E2=80=9D the utilisation of payload inside a SYN packet. Du= ring the Prague meeting, Christoph Paasch mentioned at the mike that they h= ave one application that uses data inside the SYN and their measurements in= dicate that sending this SYN without the TFO option enables it to pass thro= ugh more middleboxes than when the same SYN contains the TFO option. >>=20 >> Another point is the socket API. Currently, Linux and MacOS decouple the= transmission of data inside the SYN from the utilisation of the TFO option= . This makes it possible for a client to send data inside the SYN without e= nabling TFO. On Windows, the API seems to force the utilisation of TFO when= there is data in the SYN. As indicated earlier, RFC793 does not mandate th= e presence of the TFO to place data inside the SYN. >>=20 >> The approach we are proposing has the benefits of RFC7413 but without it= s drawbacks. Moreover, given that RFC7413 is Experimental, we don't think t= hat there is a harm if we proceed with the approach 0-rtt convert protocol = while the IETF can further tweak and adjust the applicability scope of RFC7= 413. For example, an update can be proposed to RFC7413 to clarify that spec= ialized application-level protocols could place cookie information in their= payload and thus not use the TFO option. > Just to confirm: you mean an API that > let application sets the TFO cookie (on either server and client)? No, we suggest to let specific applications use data in the SYN without usi= ng the TFO cookie. Those applications can manage their cookie inside the SY= N payload if needed. Instead of having TFO cookies that are managed by the = TCP stack and have limited size, those specialised protocols would use appl= ication-level cookies which can be longer and are managed by these applicat= ion protocols. > otherwise obviously application can place any data in their TCP payload f= or its > purposes. This is what we proposed in Prague, i.e. using data in the TCP SYN without = the TFO option. Olivier --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 From nobody Tue May 21 05:25:33 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C8120041 for ; Tue, 21 May 2019 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cTXDcNOS5-tB for ; Tue, 21 May 2019 05:25:29 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 7D87B12003E for ; Tue, 21 May 2019 05:25:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 22924B16; Tue, 21 May 2019 14:25:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O+jl9iDiHmAX; Tue, 21 May 2019 14:25:26 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id D803FB15; Tue, 21 May 2019 14:25:25 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm@ietf.org References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 14:25:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 12:25:32 -0000 On 5/21/19 12:18, Michael Tuexen wrote: >> On 21. May 2019, at 09:52, Erik Sy wrote: >> >> Hi Michael, >> >> thanks for this question! >> >> Yes, TFO cookies are bound to the clients (local) IP address. However, a >> client with a static local IP address in a home network will use the >> same TFO cookie independently of it's publicly visible IP address. As a >> result, TFO cookies present an independent tracking mechanism, which >> does not necessarily rely on the client's publicly visible IP address. > How often do the public addresses change? I do not have a general answer to your question. In the case of my home network, my ISP assigns me at least every 24 hours a new IPv4 address. Additionally, I can initiate a change of my network's public IP address at anytime. TFO cookies allow basically unlimited tracking periods because they do not have an expiration mechanism. Thus, even infrequently changed IP addresses can be correlated. > One could extend the TFO API in > a way that the application can request a new cookie by only sending > a cookie request. I do not think this is an appropriate countermeasure. >From my perspective, caching TFO cookies in the kernel is a more fundamental privacy problem. This design requires applications to share a pool of TFO cookies, which allows tracking across several applications. For example, this prevents user's to separate their online activities across different browsers. >> Returning to your example, onion routing does not necessarily protect >> you against tracking via TFO cookies. > Yepp, that is what I wanted to say. > But using TFO in that case doesn't > make much sense. Yes, TFO does not make sense if user privacy is at stake. Thus, we should warn users about these risks of RFC 7413. Best regards, Erik From nobody Tue May 21 06:31:34 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447E0120086 for ; Tue, 21 May 2019 06:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5GkRPnWnMQZO for ; Tue, 21 May 2019 06:31:31 -0700 (PDT) Received: from magic.dirtside.com (magic.dirtside.com [199.33.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 39D9312015E for ; Tue, 21 May 2019 06:31:16 -0700 (PDT) Received: from minoc.dirtside.com ([199.33.225.53]) by magic.dirtside.com (8.14.3/) with ESMTP id x4LDV0cX001102 for ; Tue, 21 May 2019 06:31:00 -0700 X-Really-To: Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by minoc.dirtside.com (Postfix) with ESMTPSA id 421FFEBEB0 for ; Tue, 21 May 2019 06:31:00 -0700 (PDT) Received: by mail-pg1-f170.google.com with SMTP id d30so8610274pgm.7 for ; Tue, 21 May 2019 06:31:00 -0700 (PDT) X-Gm-Message-State: APjAAAUe+Aj2cOss0D4W94BWvRQN7hNBOyf+Y+OqdyjmfG6Ip2RKoUAO r5Ov1vuOiBTh17+KVGBWvdPpm2uSboWUMqs0BUE= X-Google-Smtp-Source: APXvYqwGX2mifia1hxuzqesY5buJfHXeKHEkScAqVcVO7Xxk1Uccd9xMRziQnopOZjmJoCLxTdae03HaPZfYfE7Yxtw= X-Received: by 2002:a65:6145:: with SMTP id o5mr82136083pgv.262.1558445460025; Tue, 21 May 2019 06:31:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: William Herrin Date: Tue, 21 May 2019 06:30:43 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Marc Cc: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000000bf773058965dc43" X-Spam-Checker: magic.dirtside.com Archived-At: Subject: Re: [tcpm] tcp window size X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 13:31:33 -0000 --0000000000000bf773058965dc43 Content-Type: text/plain; charset="UTF-8" On Mon, May 20, 2019 at 9:23 AM Marc wrote: > Take a browser that downloads a file (receiver) and a webserver (sender). If > - both sender and receiver support window scaling > - the receiver advertises a TCP winsize of 256KB > - the sender advertises a window size of 32KB > - the sender has enough space in its TCP send buffer > (/proc/sys/net/ipv4/tcp_wmem on linux) > > How much 'outstanding unacked data' is the sender allowed to have, > 32KB or 256KB ? 256kb. But note the assertion that tcp_wmem is 256kb or larger. If the transmit buffer is 32kb you'll get 32kb even though the receiver is willing to accept 256kb. > Reading https://tools.ietf.org/html/rfc793 also suggests there is no > such thing like window size 'negotiation' and each end of a TCP > connection just advertises its own to indicate how much data it can > receive, independently. > > Is that correct ? Correct but incomplete. The receiver doesn't describe the window size just once. In every acknowledged packet, the receiver tells the sender how many more bytes he may send before he must stop and wait. The receiver can tell the sender to stop sending entirely by acknowledging each new receipt with a window size of zero. He can later send a duplicate ack with a non-zero window size when he wants the sender to resume sending. He WILL do so when the application stops pulling bytes out of the receive buffer causing the buffer to fill. Your TCP stack also has a congestion control algorithm. This will slow-start the window size when you first establish the TCP connection and will, for a time, reduce the window size in response to retransmissions and lost packets. This has some wacky interactions with NIC offloading where a stack that processes a TCP packet coalesced by the NIC will ramp up the window much faster than one which receives the original smaller TCP packets. Creates a bit of a mess for middleboxes which have to try to keep packets for a destination close enough together for the endpoint NIC to choose to coalesce them. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/ --0000000000000bf773058965dc43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2019 at 9:23 AM Marc <gaardiolor@gmail.com> wrote= :
> Take a browser that downloads a file (receiver) and a webserver (= sender). If
> - both sender and receiver support window scaling
&g= t; - the receiver advertises a TCP winsize of 256KB
> - the sender ad= vertises a window size of 32KB
> - the sender has enough space in its= TCP send buffer
> (/proc/sys/net/ipv4/tcp_wmem on linux)
>
= > How much 'outstanding unacked data' is the sender allowed to h= ave,
> 32KB or 256KB ?

256kb. But note the asserti= on that tcp_wmem is 256kb or larger. If the transmit buffer is 32kb you'= ;ll get 32kb even though the receiver is willing to accept 256kb.

> Reading https://tools.ietf.org/html/rfc793 also suggests the= re is no
> such thing like window size 'negotiation' and each= end of a TCP
> connection just advertises its own to indicate how mu= ch data it can
> receive, independently.
>
> Is that corr= ect ?

Correct but incomplete.=C2=A0

The receiver doesn't describe the window size just once. In ev= ery acknowledged packet, the receiver tells the sender how many more bytes = he may send before he must stop and wait. The receiver can tell the sender = to stop sending entirely by acknowledging each new receipt with a window si= ze of zero. He can later send a duplicate ack with a non-zero window size w= hen he wants the sender to resume sending. He WILL do so when the applicati= on stops pulling bytes out of the receive buffer causing the buffer to fill= .

Your TCP stack also has a congestion control alg= orithm. This will slow-start the window size when you first establish the T= CP connection and will, for a time, reduce the window size in response to r= etransmissions and lost packets. This has some wacky interactions with NIC = offloading where a stack that processes a TCP packet coalesced by the NIC w= ill ramp up the window much faster than one which receives the original sma= ller TCP packets. Creates a bit of a mess for middleboxes which have to try= to keep packets for a destination close enough together for the endpoint N= IC to choose to coalesce them.

Regards,
= Bill Herrin

--=C2=A0
--0000000000000bf773058965dc43-- From nobody Tue May 21 07:48:09 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A2512003E for ; Tue, 21 May 2019 07:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kgIU5X70JnDf for ; Tue, 21 May 2019 07:48:03 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 6EE7812001E for ; Tue, 21 May 2019 07:48:03 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x4LEm05i014580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 May 2019 16:48:01 +0200 Received: from [IPv6:2001:67c:64:49:6135:873c:6a:daf9] ([IPv6:2001:67c:64:49:6135:873c:6a:daf9]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x4LElweN013587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 May 2019 16:47:59 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Brian Trammell (IETF) In-Reply-To: <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> Date: Tue, 21 May 2019 14:47:58 +0000 Cc: Erik Sy , Michael Tuexen , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.8) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 14:48:07 -0000 hi Michael, Further foolishness inside ;) > On 21 May 2019, at 09:39, Michael Welzl wrote: >=20 > Hi all, >=20 > I'm about to make a fool of myself because I'm quite certain that I'm = missing something. > But, I guess this is worth the risk - somehow I'm not risking much, as = most people on this list already know me well enough to not be surprised = by another foolish idea coming from me :) >=20 >=20 > So... >=20 >=20 > Actually, couldn't we just remove the cookie from TFO? >=20 >=20 > As far as I understand, the main point of the cookie is to protect the = server against clients that might spoof their IP addresses and just send = tons of requests to the server - which could potentially be much heavier = to handle than just the SYN state without TFO. > To some degree, this is an OS problem, not a network problem: methods = could be in place to limit the time an application spends answering = requests that are carried on SYNs. My question is: wouldn't that be = enough? All simple cookie based-approaches have a pretty simple tradeoff: use a = cookie which references some previous visible exchange between client = and server, trading off load reduction on the server (and flexibility in = deployment of DoS protection in front of the server) for traceability = (which, in this case, is a requirement, not something to be avoided). = The design of TFO (and SYN cookies before it).=20 More advanced 0RTT tokens have a different tradeoff; since the token is = established between client and server without being observable on the = path, here we gain traceability protection and retain server load = reduction, but give up the ability to have front-ends that can reject = attack traffic without some form of coordination with the server. > A few years ago, I'm sure that such a proposal would have been shot by = people saying that data carried by TCP is general and TCP must serve all = applications, and that we can't have that kind of special treatment for = data arriving via SYNs. > However, TFO has already departed from this generality, in several = ways: applications using it must be able to handle incoming duplicate = requests; they need to use special API calls to access the data; = importantly (for the point I'm making), rate limits should already be in = place when using TFO (RFC 7413, section 5.1). >=20 > So what I'm proposing is: couldn't we re-write TFO to just remove the = Cookie from it, and say: "it's allowed for applications to accept data = that comes with a SYN right away, but this must be done in a special way = (as already described in RFC 7413), and in particular, the time an = application spends processing TFO requests must be limited to avoid = being DDoSed?" You're correct to point out that 0RTT resumption is and will always = remain special, not only due to the special requirements it places on = applications but also for cryptographic reasons (0RTT cannot be made = forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different = cryptographic properties than the rest of the session).=20 ISTM there are the following possibilities: (1) Do nothing. (1a) Do nothing, but issue guidance in an informational RFC notinf that = TFO cookies are traceable, and should be avoided in the open Internet = when=20 (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); = explain the privacy reason behind the deprecation in the deprecated = document. (3) Update TFO to make TFO cookies optional, and explain the tradeoffs. I would expect pushback on 2 or 3 from people running TFO on the = Internet, because it requires coordinated implementation effort and = changes the operational environment (which always carries risk). There is the caveat that I'm not sure how many are running TFO on the = Internet. (I do know Google was the biggest one, at least a couple of = years ago, from research I did before joining). Cheers, Brian > If a server is overloaded and can't process any more TFO data, the = result could be that it just doesn't answer at all, and the client would = then retransmit the SYN, just as if the SYN had been dropped. >=20 >=20 > Cheers, > Michael >=20 >=20 >=20 >> On 21 May 2019, at 09:52, Erik Sy = wrote: >>=20 >> Hi Michael, >>=20 >> thanks for this question! >>=20 >> Yes, TFO cookies are bound to the clients (local) IP address. = However, a >> client with a static local IP address in a home network will use the >> same TFO cookie independently of it's publicly visible IP address. As = a >> result, TFO cookies present an independent tracking mechanism, which >> does not necessarily rely on the client's publicly visible IP = address. >>=20 >> Returning to your example, onion routing does not necessarily protect >> you against tracking via TFO cookies. >>=20 >> Best regards, >> Erik >>=20 >> On 5/21/19 09:13, Michael Tuexen wrote: >>>> On 20. May 2019, at 23:19, Erik Sy = wrote: >>>>=20 >>>> I think it is important to warn users about the privacy risks of = RFC >>>> 7413. For example, Mozilla reacted to the privacy problems of TCP = Fast >>>> Open by deprecating this protocol on all it's Firefox branches. In >>>> total, TCP Fast Open has significant issues with respect to user >>>> privacy, performance and deployment on the real-world Internet. = =46rom my >>>> point of view, it is about time to deprecate RFC 7413. >>> Hi Eric, >>>=20 >>> my understanding is that a cookie is specific to a client address, a = server >>> address and a server port. So it would make sense for a client to = remove >>> entries from the cookie cache on an address change. Assuming that, = how >>> does your described host based attacks relate to the server just = using >>> the client IP address for tracking? If you are trying to hide you = IP-address >>> (like using a TOR browser) you don't want to use TFO, but you are = not >>> optimising for small RTTs in that case, so it makes no sense in that = case. >>>=20 >>> Best regards >>> Michael >>>> Regards, >>>> Erik >>>>=20 >>>> On 5/10/19 14:14, Erik Sy wrote: >>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> TCP Fast Open has significant privacy problems which are not = considered >>>>> in RFC 7413. >>>>> For example, this protocol allows a passive network observer to >>>>> correlate connections established by the same client, which = protocols >>>>> such as TLS 1.3 and QUIC actively protect against. Furthermore, = Fast >>>>> Open cookies present a kernel-based tracking mechanism which is = quite >>>>> persistent. Amongst others, they can be used to conduct = cross-browser >>>>> tracking on the same operating system. >>>>> For further details please refer to this article: >>>>> https://arxiv.org/pdf/1905.03518.pdf >>>>>=20 >>>>> I suggest, that the working group takes steps to highlight these = privacy >>>>> problems of RFC 7413. >>>>>=20 >>>>> Regards, >>>>> Erik >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 09:28:20 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE212007A for ; Tue, 21 May 2019 09:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 H2MylJ3CioAZ for ; Tue, 21 May 2019 09:28:04 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D3812001E for ; Tue, 21 May 2019 09:28:03 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:3539:3577:8688:4695] (p200300CD6F384A003539357786884695.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:3539:3577:8688:4695]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id E0461721E2823; Tue, 21 May 2019 18:27:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> Date: Tue, 21 May 2019 18:27:59 +0200 Cc: sy@informatik.uni-hamburg.de, tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <38FAF4D4-088C-4772-B61B-3C32C7FFB0A9@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 16:28:17 -0000 > On 21. May 2019, at 11:39, Michael Welzl wrote: >=20 > Hi all, >=20 > I'm about to make a fool of myself because I'm quite certain that I'm = missing something. > But, I guess this is worth the risk - somehow I'm not risking much, as = most people on this list already know me well enough to not be surprised = by another foolish idea coming from me :) >=20 >=20 > So... >=20 >=20 > Actually, couldn't we just remove the cookie from TFO? Aren't you referring to https://tools.ietf.org/html/rfc7413#section-7.3 Best regards Michael >=20 >=20 > As far as I understand, the main point of the cookie is to protect the = server against clients that might spoof their IP addresses and just send = tons of requests to the server - which could potentially be much heavier = to handle than just the SYN state without TFO. > To some degree, this is an OS problem, not a network problem: methods = could be in place to limit the time an application spends answering = requests that are carried on SYNs. My question is: wouldn't that be = enough? >=20 > A few years ago, I'm sure that such a proposal would have been shot by = people saying that data carried by TCP is general and TCP must serve all = applications, and that we can't have that kind of special treatment for = data arriving via SYNs. > However, TFO has already departed from this generality, in several = ways: applications using it must be able to handle incoming duplicate = requests; they need to use special API calls to access the data; = importantly (for the point I'm making), rate limits should already be in = place when using TFO (RFC 7413, section 5.1). >=20 > So what I'm proposing is: couldn't we re-write TFO to just remove the = Cookie from it, and say: "it's allowed for applications to accept data = that comes with a SYN right away, but this must be done in a special way = (as already described in RFC 7413), and in particular, the time an = application spends processing TFO requests must be limited to avoid = being DDoSed?" >=20 > If a server is overloaded and can't process any more TFO data, the = result could be that it just doesn't answer at all, and the client would = then retransmit the SYN, just as if the SYN had been dropped. >=20 >=20 > Cheers, > Michael >=20 >=20 >=20 >> On 21 May 2019, at 09:52, Erik Sy = wrote: >>=20 >> Hi Michael, >>=20 >> thanks for this question! >>=20 >> Yes, TFO cookies are bound to the clients (local) IP address. = However, a >> client with a static local IP address in a home network will use the >> same TFO cookie independently of it's publicly visible IP address. As = a >> result, TFO cookies present an independent tracking mechanism, which >> does not necessarily rely on the client's publicly visible IP = address. >>=20 >> Returning to your example, onion routing does not necessarily protect >> you against tracking via TFO cookies. >>=20 >> Best regards, >> Erik >>=20 >> On 5/21/19 09:13, Michael Tuexen wrote: >>>> On 20. May 2019, at 23:19, Erik Sy = wrote: >>>>=20 >>>> I think it is important to warn users about the privacy risks of = RFC >>>> 7413. For example, Mozilla reacted to the privacy problems of TCP = Fast >>>> Open by deprecating this protocol on all it's Firefox branches. In >>>> total, TCP Fast Open has significant issues with respect to user >>>> privacy, performance and deployment on the real-world Internet. = =46rom my >>>> point of view, it is about time to deprecate RFC 7413. >>> Hi Eric, >>>=20 >>> my understanding is that a cookie is specific to a client address, a = server >>> address and a server port. So it would make sense for a client to = remove >>> entries from the cookie cache on an address change. Assuming that, = how >>> does your described host based attacks relate to the server just = using >>> the client IP address for tracking? If you are trying to hide you = IP-address >>> (like using a TOR browser) you don't want to use TFO, but you are = not >>> optimising for small RTTs in that case, so it makes no sense in that = case. >>>=20 >>> Best regards >>> Michael >>>> Regards, >>>> Erik >>>>=20 >>>> On 5/10/19 14:14, Erik Sy wrote: >>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> TCP Fast Open has significant privacy problems which are not = considered >>>>> in RFC 7413. >>>>> For example, this protocol allows a passive network observer to >>>>> correlate connections established by the same client, which = protocols >>>>> such as TLS 1.3 and QUIC actively protect against. Furthermore, = Fast >>>>> Open cookies present a kernel-based tracking mechanism which is = quite >>>>> persistent. Amongst others, they can be used to conduct = cross-browser >>>>> tracking on the same operating system. >>>>> For further details please refer to this article: >>>>> https://arxiv.org/pdf/1905.03518.pdf >>>>>=20 >>>>> I suggest, that the working group takes steps to highlight these = privacy >>>>> problems of RFC 7413. >>>>>=20 >>>>> Regards, >>>>> Erik >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Tue May 21 09:34:45 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5F012017D for ; Tue, 21 May 2019 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 OuZ6xi192rVd for ; Tue, 21 May 2019 09:34:42 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8A2120177 for ; Tue, 21 May 2019 09:34:42 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:3539:3577:8688:4695] (p200300CD6F384A003539357786884695.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:3539:3577:8688:4695]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 019CF721E2823; Tue, 21 May 2019 18:34:38 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 18:34:38 +0200 Cc: tcpm@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 16:34:44 -0000 > On 21. May 2019, at 14:25, Erik Sy wrote: > > > On 5/21/19 12:18, Michael Tuexen wrote: >>> On 21. May 2019, at 09:52, Erik Sy wrote: >>> >>> Hi Michael, >>> >>> thanks for this question! >>> >>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>> client with a static local IP address in a home network will use the >>> same TFO cookie independently of it's publicly visible IP address. As a >>> result, TFO cookies present an independent tracking mechanism, which >>> does not necessarily rely on the client's publicly visible IP address. >> How often do the public addresses change? > > I do not have a general answer to your question. In the case of my home > network, my ISP assigns me at least every 24 hours a new IPv4 address. I also had this on my DSL line (I guess we both live in Germany), but since my telephone line was moved to "all IP", the assignment stays up for months. > Additionally, I can initiate a change of my network's public IP address > at anytime. Sure. > > TFO cookies allow basically unlimited tracking periods because they do > not have an expiration mechanism. Thus, even infrequently changed IP > addresses can be correlated. An implementation can do implement such a thing and even allow an API for it. For testing I'm flushing the cookie cache quite often... > >> One could extend the TFO API in >> a way that the application can request a new cookie by only sending >> a cookie request. > > I do not think this is an appropriate countermeasure. > > From my perspective, caching TFO cookies in the kernel is a more > fundamental privacy problem. This design requires applications to share > a pool of TFO cookies, which allows tracking across several > applications. For example, this prevents user's to separate their online > activities across different browsers. They would share the IP address. If they decide to trigger a new address binding on the access router, why couldn't they trigger flushing the cache? Best regards Michael > >>> Returning to your example, onion routing does not necessarily protect >>> you against tracking via TFO cookies. >> Yepp, that is what I wanted to say. >> But using TFO in that case doesn't >> make much sense. > > Yes, TFO does not make sense if user privacy is at stake. Thus, we > should warn users about these risks of RFC 7413. > > Best regards, > Erik > > From nobody Tue May 21 11:14:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395631201DD for ; Tue, 21 May 2019 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 cCE4MLLZcdhE for ; Tue, 21 May 2019 11:14:10 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770131.outbound.protection.outlook.com [40.107.77.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1EE2120223 for ; Tue, 21 May 2019 11:14:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=woZx7UuaC0sUc6OHwzZ0FL2ysPHQFiujV5QKEyyn5Kix0QrNpX2kyZm/q0sQtpydyKYB3JPXfq1e0ZvHHGOFLzqmR1xX5/Itxye4jjPh0zFtt315zcprm4aGjtu9zub6m2if24ng8UFFLAJD5yRiSjAePArTcHb0SVfPdsarzxA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6eA1rDAXjw89vZmVakHn7PNevAGOhdOexBqdBv7KI4=; b=dMA4kmUhZfzWUFdi+o3TDKkPxS2JBUjG/ge2EIq2KWqYsg3hQMzUQPw9gH1Jp3Qq1n8ln7VOebsJ7lBtaDpJoaNKc1XXGxUo6N4vVmsyEr/WtYgzhTmQ7YwY00Om/geeVBl3K7kMSMRMu1e8zyX08QkUv3KBtQAl+Bx22HpcMCE= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6eA1rDAXjw89vZmVakHn7PNevAGOhdOexBqdBv7KI4=; b=gb+u40MZgDumC+DRtjmj4fmkojxI5fOyAq8cNkTvHOCki0NS/H2pf19Qt07bEc+JulncjkkSqWpKuvReZycqLYe/0IqcFes6fDJjC7uKFbJAAr/t72r+Ms95kTAssdos8Rdedg4M1uSojVkYdE4JSaqNlNW4VbewpvFRaLf9n+E= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (2603:10b6:302:a::13) by MW2PR2101MB1019.namprd21.prod.outlook.com (2603:10b6:302:5::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.6; Tue, 21 May 2019 18:14:07 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2%4]) with mapi id 15.20.1943.006; Tue, 21 May 2019 18:14:07 +0000 From: Praveen Balasubramanian To: Brian Trammell , Michael Welzl CC: Michael Tuexen , tcpm IETF list Thread-Topic: [tcpm] Privacy problems of TCP Fast Open Thread-Index: AQHVByn/aakJ4ZD9PEmuWaFrgWjVpKZ0lRMAgACl5ICAAArjgIAAHh2AgABWEQCAADks4A== Date: Tue, 21 May 2019 18:14:07 +0000 Message-ID: References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> In-Reply-To: <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-21T18:14:06.0570732Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=25a8cf3a-91d5-457c-bb90-89e82f4c9b47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:2:9b7:a73:7c65:990e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef63c7e3-95b9-4803-3353-08d6de181d5c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1019; x-ms-traffictypediagnostic: MW2PR2101MB1019: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(346002)(396003)(366004)(199004)(189003)(53754006)(13464003)(486006)(74316002)(476003)(478600001)(446003)(5660300002)(76116006)(55016002)(11346002)(68736007)(52396003)(15974865002)(66946007)(73956011)(25786009)(102836004)(8936002)(66476007)(66556008)(64756008)(6436002)(6506007)(10290500003)(76176011)(316002)(66446008)(7696005)(53546011)(8990500004)(186003)(966005)(33656002)(7736002)(46003)(305945005)(9686003)(99286004)(6306002)(22452003)(110136005)(561944003)(54906003)(66574012)(71200400001)(53936002)(10090500001)(71190400001)(52536014)(6246003)(4326008)(86362001)(2906002)(14454004)(81156014)(256004)(14444005)(8676002)(6116002)(86612001)(229853002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1019; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: oQJ8Da0QA3eU+me8OnreUMIZ/dJe4p/bZsP0CwZtj1ne0rk2WeSwt/CFQ15EVvIsEZl67nIm+3cOAs6KJM0U9lVPW56fCYPLp00RKNL/FPzriakC6Tk6ljiSWaOfMrdQbQEV4rJpa+5dgzCH7ZgxahELWqehFTO4bfdTESkRAmenMIDgp/Ma9LAY+flHzNaYFNMxurXPjrmm5J3CdZXUL+0pEbQLbFdErgPcfU4nc0gqh6BULef52XTDEge4FJXlCncXLLOk0nO5C0GTilf3MmrDwrXHioVnQI3LcfMGLot3FCxQoI1IXbKDeaeDkRWpw3z7ILa0tWqfb3wal13b7uUqPego2cN+8HMXTfo6COXJ8VjiqxQprxSP4oeNQKtpljPqIHe5G8yx9BRKRoyNO+J3Z1mjxh1BgjEt+jLhpjw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef63c7e3-95b9-4803-3353-08d6de181d5c X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 18:14:07.1657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1019 Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 18:14:20 -0000 We are removing support for TFO only in the InPrivate (incognito) mode of t= he Edge browser.=20 IPv6 privacy addresses mitigate this somewhat. Also, TFO servers will expir= e the cookies periodically as well.=20 I wouldn't be opposed to some expiration scheme on client as well. And I am= fine with adding some guidance around this. If TFO is to become a standard= s track RFC, then I agree that these concerns should be addressed.=20 Let's not overreact and deprecate the only path we have for low latency set= up on TCP. Also, TFO could also be used on non-public Internet. Brian a lot of major servers now support TFO. Client support is the problem= . -----Original Message----- From: tcpm On Behalf Of Brian Trammell Sent: Tuesday, May 21, 2019 7:48 AM To: Michael Welzl Cc: Michael Tuexen ; tcpm IETF list Subject: Re: [tcpm] Privacy problems of TCP Fast Open hi Michael, Further foolishness inside ;) > On 21 May 2019, at 09:39, Michael Welzl wrote: >=20 > Hi all, >=20 > I'm about to make a fool of myself because I'm quite certain that I'm mis= sing something. > But, I guess this is worth the risk - somehow I'm not risking much, as mo= st people on this list already know me well enough to not be surprised by a= nother foolish idea coming from me :) >=20 >=20 > So... >=20 >=20 > Actually, couldn't we just remove the cookie from TFO? >=20 >=20 > As far as I understand, the main point of the cookie is to protect the se= rver against clients that might spoof their IP addresses and just send tons= of requests to the server - which could potentially be much heavier to han= dle than just the SYN state without TFO. > To some degree, this is an OS problem, not a network problem: methods cou= ld be in place to limit the time an application spends answering requests t= hat are carried on SYNs. My question is: wouldn't that be enough? All simple cookie based-approaches have a pretty simple tradeoff: use a coo= kie which references some previous visible exchange between client and serv= er, trading off load reduction on the server (and flexibility in deployment= of DoS protection in front of the server) for traceability (which, in this= case, is a requirement, not something to be avoided). The design of TFO (a= nd SYN cookies before it).=20 More advanced 0RTT tokens have a different tradeoff; since the token is est= ablished between client and server without being observable on the path, he= re we gain traceability protection and retain server load reduction, but gi= ve up the ability to have front-ends that can reject attack traffic without= some form of coordination with the server. > A few years ago, I'm sure that such a proposal would have been shot by pe= ople saying that data carried by TCP is general and TCP must serve all appl= ications, and that we can't have that kind of special treatment for data ar= riving via SYNs. > However, TFO has already departed from this generality, in several ways: = applications using it must be able to handle incoming duplicate requests; t= hey need to use special API calls to access the data; importantly (for the = point I'm making), rate limits should already be in place when using TFO (R= FC 7413, section 5.1). >=20 > So what I'm proposing is: couldn't we re-write TFO to just remove the Coo= kie from it, and say: "it's allowed for applications to accept data that co= mes with a SYN right away, but this must be done in a special way (as alrea= dy described in RFC 7413), and in particular, the time an application spend= s processing TFO requests must be limited to avoid being DDoSed?" You're correct to point out that 0RTT resumption is and will always remain = special, not only due to the special requirements it places on applications= but also for cryptographic reasons (0RTT cannot be made forward-secret, so= data sent in 0RTT for TLS1.3 or QUIC has different cryptographic propertie= s than the rest of the session).=20 ISTM there are the following possibilities: (1) Do nothing. (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO= cookies are traceable, and should be avoided in the open Internet when=20 (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain = the privacy reason behind the deprecation in the deprecated document. (3) Update TFO to make TFO cookies optional, and explain the tradeoffs. I would expect pushback on 2 or 3 from people running TFO on the Internet, = because it requires coordinated implementation effort and changes the opera= tional environment (which always carries risk). There is the caveat that I'm not sure how many are running TFO on the Inter= net. (I do know Google was the biggest one, at least a couple of years ago,= from research I did before joining). Cheers, Brian > If a server is overloaded and can't process any more TFO data, the result= could be that it just doesn't answer at all, and the client would then ret= ransmit the SYN, just as if the SYN had been dropped. >=20 >=20 > Cheers, > Michael >=20 >=20 >=20 >> On 21 May 2019, at 09:52, Erik Sy wrote: >>=20 >> Hi Michael, >>=20 >> thanks for this question! >>=20 >> Yes, TFO cookies are bound to the clients (local) IP address.=20 >> However, a client with a static local IP address in a home network=20 >> will use the same TFO cookie independently of it's publicly visible=20 >> IP address. As a result, TFO cookies present an independent tracking=20 >> mechanism, which does not necessarily rely on the client's publicly visi= ble IP address. >>=20 >> Returning to your example, onion routing does not necessarily protect=20 >> you against tracking via TFO cookies. >>=20 >> Best regards, >> Erik >>=20 >> On 5/21/19 09:13, Michael Tuexen wrote: >>>> On 20. May 2019, at 23:19, Erik Sy wrot= e: >>>>=20 >>>> I think it is important to warn users about the privacy risks of=20 >>>> RFC 7413. For example, Mozilla reacted to the privacy problems of=20 >>>> TCP Fast Open by deprecating this protocol on all it's Firefox=20 >>>> branches. In total, TCP Fast Open has significant issues with=20 >>>> respect to user privacy, performance and deployment on the=20 >>>> real-world Internet. From my point of view, it is about time to deprec= ate RFC 7413. >>> Hi Eric, >>>=20 >>> my understanding is that a cookie is specific to a client address, a=20 >>> server address and a server port. So it would make sense for a=20 >>> client to remove entries from the cookie cache on an address change.=20 >>> Assuming that, how does your described host based attacks relate to=20 >>> the server just using the client IP address for tracking? If you are=20 >>> trying to hide you IP-address (like using a TOR browser) you don't=20 >>> want to use TFO, but you are not optimising for small RTTs in that case= , so it makes no sense in that case. >>>=20 >>> Best regards >>> Michael >>>> Regards, >>>> Erik >>>>=20 >>>> On 5/10/19 14:14, Erik Sy wrote: >>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> TCP Fast Open has significant privacy problems which are not=20 >>>>> considered in RFC 7413. >>>>> For example, this protocol allows a passive network observer to=20 >>>>> correlate connections established by the same client, which=20 >>>>> protocols such as TLS 1.3 and QUIC actively protect against.=20 >>>>> Furthermore, Fast Open cookies present a kernel-based tracking=20 >>>>> mechanism which is quite persistent. Amongst others, they can be=20 >>>>> used to conduct cross-browser tracking on the same operating system. >>>>> For further details please refer to this article: >>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F >>>>> arxiv.org%2Fpdf%2F1905.03518.pdf&data=3D02%7C01%7Cpravb%40micros >>>>> oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2 >>>>> d7cd011db47%7C1%7C1%7C636940469018140114&sdata=3DdkgWLSFZYKENl7l >>>>> scesJExW6SbZCGfOUXEN8oPHWh2k%3D&reserved=3D0 >>>>>=20 >>>>> I suggest, that the working group takes steps to highlight these=20 >>>>> privacy problems of RFC 7413. >>>>>=20 >>>>> Regards, >>>>> Erik >>>>>=20 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F >>>>> www.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb% >>>>> 40microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f14 >>>>> 1af91ab2d7cd011db47%7C1%7C1%7C636940469018140114&sdata=3D05KZ4W% >>>>> 2BrEPGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=3D0 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw >>>> ww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40 >>>> microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af >>>> 91ab2d7cd011db47%7C1%7C1%7C636940469018140114&sdata=3D05KZ4W%2BrE >>>> PGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=3D0 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww >> .ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr >> osoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d >> 7cd011db47%7C1%7C1%7C636940469018140114&sdata=3D05KZ4W%2BrEPGOmzC0z >> Uf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=3D0 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros > oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C1%7C636940469018140114&sdata=3D05KZ4W%2BrEPGOmzC0zUf4K > GYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.co= m%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C1%7C636940469018140114&sdata=3D05KZ4W%2BrEPGOmzC0zUf4KGYQWicR%2BS7%2= F3VKYXvlizj4%3D&reserved=3D0 From nobody Tue May 21 12:22:36 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3DF120025 for ; Tue, 21 May 2019 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qTTgNwqTLLj5 for ; Tue, 21 May 2019 12:22:33 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 7566A120096 for ; Tue, 21 May 2019 12:22:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E4B42FD5; Tue, 21 May 2019 21:22:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L8q+Nk7dYxob; Tue, 21 May 2019 21:22:24 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5CC20.versanet.de [89.245.204.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id AC4C5FD4; Tue, 21 May 2019 21:22:23 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm@ietf.org References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: Date: Tue, 21 May 2019 21:22:20 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 19:22:36 -0000 On 5/21/19 18:34, Michael Tuexen wrote: >> On 21. May 2019, at 14:25, Erik Sy wrote: >> >> >> On 5/21/19 12:18, Michael Tuexen wrote: >>>> On 21. May 2019, at 09:52, Erik Sy wrote: >>>> >>>> Hi Michael, >>>> >>>> thanks for this question! >>>> >>>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>>> client with a static local IP address in a home network will use the >>>> same TFO cookie independently of it's publicly visible IP address. As a >>>> result, TFO cookies present an independent tracking mechanism, which >>>> does not necessarily rely on the client's publicly visible IP address. >>> How often do the public addresses change? >> I do not have a general answer to your question. In the case of my home >> network, my ISP assigns me at least every 24 hours a new IPv4 address. > I also had this on my DSL line (I guess we both live in Germany), > but since my telephone line was moved to "all IP", the assignment stays > up for months. >> Additionally, I can initiate a change of my network's public IP address >> at anytime. > Sure. >> TFO cookies allow basically unlimited tracking periods because they do >> not have an expiration mechanism. Thus, even infrequently changed IP >> addresses can be correlated. > An implementation can do implement such a thing and even allow an API for it. Yes, I agree with you that implementations can go beyond RFC 7413 and implement an expiration mechanism limiting feasible tracking periods. > For testing I'm flushing the cookie cache quite often... >>> One could extend the TFO API in >>> a way that the application can request a new cookie by only sending >>> a cookie request. >> I do not think this is an appropriate countermeasure. >> >> From my perspective, caching TFO cookies in the kernel is a more >> fundamental privacy problem. This design requires applications to share >> a pool of TFO cookies, which allows tracking across several >> applications. For example, this prevents user's to separate their online >> activities across different browsers. > They would share the IP address. If they decide to trigger a new address > binding on the access router, why couldn't they trigger flushing the > cache? Flushing the cache presents a performance versus privacy trade off because flushing increases the chance of a cache miss preventing a 0-RTT handshake. Thus, an application that often flushes the cache degrades the performance of all other applications sharing the same pool of TFO cookies. As a result, the application with the highest privacy requirements limits the TFO performance of all other applications. Furthermore flushing has difficulties to separate applications running at the same time. For example, running a browser window in the normal browsing mode and another window in the private browsing mode (incognito). In this scenario, only excessive flushing can prevent an online tracker to link the user's online activities across both browser windows. >From my perspective, an approach that delegates the caching to the application itself, is the better solution to address this privacy versus performance trade off. Moreover, I believe users tend to make the application/browser vendor responsible to protect their privacy. Thus, these vendors require appropriate measures to control their users' privacy. Best regards, Erik > Best regards > Michael >>>> Returning to your example, onion routing does not necessarily protect >>>> you against tracking via TFO cookies. >>> Yepp, that is what I wanted to say. >>> But using TFO in that case doesn't >>> make much sense. >> Yes, TFO does not make sense if user privacy is at stake. Thus, we >> should warn users about these risks of RFC 7413. >> >> Best regards, >> Erik >> >> From nobody Tue May 21 12:57:07 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCE31200D6 for ; Tue, 21 May 2019 12:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01] 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 Vkbwfmv-q3jD for ; Tue, 21 May 2019 12:57:02 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782A3120044 for ; Tue, 21 May 2019 12:57:02 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:d9db:e8ce:b83f:a6ec] (p200300CD6F384A00D9DBE8CEB83FA6EC.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:d9db:e8ce:b83f:a6ec]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id B8130721E2823; Tue, 21 May 2019 21:56:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: Date: Tue, 21 May 2019 21:56:59 +0200 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 19:57:06 -0000 > On 21. May 2019, at 21:22, Erik Sy = wrote: >=20 >=20 > On 5/21/19 18:34, Michael Tuexen wrote: >>> On 21. May 2019, at 14:25, Erik Sy = wrote: >>>=20 >>>=20 >>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>> On 21. May 2019, at 09:52, Erik Sy = wrote: >>>>>=20 >>>>> Hi Michael, >>>>>=20 >>>>> thanks for this question! >>>>>=20 >>>>> Yes, TFO cookies are bound to the clients (local) IP address. = However, a >>>>> client with a static local IP address in a home network will use = the >>>>> same TFO cookie independently of it's publicly visible IP address. = As a >>>>> result, TFO cookies present an independent tracking mechanism, = which >>>>> does not necessarily rely on the client's publicly visible IP = address. >>>> How often do the public addresses change? >>> I do not have a general answer to your question. In the case of my = home >>> network, my ISP assigns me at least every 24 hours a new IPv4 = address. >> I also had this on my DSL line (I guess we both live in Germany), >> but since my telephone line was moved to "all IP", the assignment = stays >> up for months. >>> Additionally, I can initiate a change of my network's public IP = address >>> at anytime. >> Sure. >>> TFO cookies allow basically unlimited tracking periods because they = do >>> not have an expiration mechanism. Thus, even infrequently changed IP >>> addresses can be correlated. >> An implementation can do implement such a thing and even allow an API = for it. >=20 > Yes, I agree with you that implementations can go beyond RFC 7413 and > implement an expiration mechanism limiting feasible tracking periods. >=20 >> For testing I'm flushing the cookie cache quite often... >>>> One could extend the TFO API in >>>> a way that the application can request a new cookie by only sending=20= >>>> a cookie request. >>> I do not think this is an appropriate countermeasure. >>>=20 >>> =46rom my perspective, caching TFO cookies in the kernel is a more >>> fundamental privacy problem. This design requires applications to = share >>> a pool of TFO cookies, which allows tracking across several >>> applications. For example, this prevents user's to separate their = online >>> activities across different browsers. >> They would share the IP address. If they decide to trigger a new = address >> binding on the access router, why couldn't they trigger flushing the >> cache? >=20 > Flushing the cache presents a performance versus privacy trade off > because flushing increases the chance of a cache miss preventing a = 0-RTT > handshake. Sure it does. It was just meant as an equivalent to resetting the public IP address of your access router. This also affects all outgoing connections. > Thus, an application that often flushes the cache degrades the > performance of all other applications sharing the same pool of TFO = cookies. > As a result, the application with the highest privacy requirements > limits the TFO performance of all other applications. >=20 > Furthermore flushing has difficulties to separate applications running > at the same time. For example, running a browser window in the normal > browsing mode and another window in the private browsing mode > (incognito). In this scenario, only excessive flushing can prevent an > online tracker to link the user's online activities across both = browser > windows. Can't they both be linked by the IP address being used? >=20 > =46rom my perspective, an approach that delegates the caching to the > application itself, is the better solution to address this privacy > versus performance trade off. Moreover, I believe users tend to make = the How does this prevent "tracking by IP-address" compared to "tracking by TFO cookie"? Best regards Michael > application/browser vendor responsible to protect their privacy. Thus, > these vendors require appropriate measures to control their users' = privacy. >=20 > Best regards, > Erik >=20 >> Best regards >> Michael >>>>> Returning to your example, onion routing does not necessarily = protect >>>>> you against tracking via TFO cookies. >>>> Yepp, that is what I wanted to say.=20 >>>> But using TFO in that case doesn't >>>> make much sense. >>> Yes, TFO does not make sense if user privacy is at stake. Thus, we >>> should warn users about these risks of RFC 7413. >>>=20 >>> Best regards, >>> Erik >>>=20 >>>=20 From nobody Tue May 21 13:12:49 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCA41200EC for ; Tue, 21 May 2019 13:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 U8NulnKsDiQz for ; Tue, 21 May 2019 13:12:45 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 5C85E120088 for ; Tue, 21 May 2019 13:12:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 7993988E; Tue, 21 May 2019 22:12:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PT5iuDK6Lu-Z; Tue, 21 May 2019 22:12:42 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5CC20.versanet.de [89.245.204.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id F24A288D; Tue, 21 May 2019 22:12:41 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: "Brian Trammell (IETF)" Cc: tcpm IETF list References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <5fd05c70-ce53-0966-7097-090830526d4c@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 22:12:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 20:12:48 -0000 Hi Brian, On 5/21/19 16:47, Brian Trammell (IETF) wrote: > hi Michael, > > Further foolishness inside ;) > >> On 21 May 2019, at 09:39, Michael Welzl wrote: >> >> Hi all, >> >> I'm about to make a fool of myself because I'm quite certain that I'm missing something. >> But, I guess this is worth the risk - somehow I'm not risking much, as most people on this list already know me well enough to not be surprised by another foolish idea coming from me :) >> >> >> So... >> >> >> Actually, couldn't we just remove the cookie from TFO? >> >> >> As far as I understand, the main point of the cookie is to protect the server against clients that might spoof their IP addresses and just send tons of requests to the server - which could potentially be much heavier to handle than just the SYN state without TFO. >> To some degree, this is an OS problem, not a network problem: methods could be in place to limit the time an application spends answering requests that are carried on SYNs. My question is: wouldn't that be enough? > All simple cookie based-approaches have a pretty simple tradeoff: use a cookie which references some previous visible exchange between client and server, trading off load reduction on the server (and flexibility in deployment of DoS protection in front of the server) for traceability (which, in this case, is a requirement, not something to be avoided). The design of TFO (and SYN cookies before it). > > More advanced 0RTT tokens have a different tradeoff; since the token is established between client and server without being observable on the path, here we gain traceability protection and retain server load reduction, but give up the ability to have front-ends that can reject attack traffic without some form of coordination with the server. > >> A few years ago, I'm sure that such a proposal would have been shot by people saying that data carried by TCP is general and TCP must serve all applications, and that we can't have that kind of special treatment for data arriving via SYNs. >> However, TFO has already departed from this generality, in several ways: applications using it must be able to handle incoming duplicate requests; they need to use special API calls to access the data; importantly (for the point I'm making), rate limits should already be in place when using TFO (RFC 7413, section 5.1). >> >> So what I'm proposing is: couldn't we re-write TFO to just remove the Cookie from it, and say: "it's allowed for applications to accept data that comes with a SYN right away, but this must be done in a special way (as already described in RFC 7413), and in particular, the time an application spends processing TFO requests must be limited to avoid being DDoSed?" > You're correct to point out that 0RTT resumption is and will always remain special, not only due to the special requirements it places on applications but also for cryptographic reasons (0RTT cannot be made forward-secret, Technically 0-RTT does allow forward security and hopefully some of this research will find its way into TLS (https://eprint.iacr.org/2019/228.pdf) > so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). > > ISTM there are the following possibilities: > > (1) Do nothing. > > (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO cookies are traceable, and should be avoided in the open Internet when > > (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain the privacy reason behind the deprecation in the deprecated document. > > (3) Update TFO to make TFO cookies optional, and explain the tradeoffs. > > I would expect pushback on 2 or 3 from people running TFO on the Internet, because it requires coordinated implementation effort and changes the operational environment (which always carries risk). > > There is the caveat that I'm not sure how many are running TFO on the Internet. (I do know Google was the biggest one, at least a couple of years ago, from research I did before joining). As described in the linked paper (https://arxiv.org/pdf/1905.03518.pdf), my measurements indicate that 3.2% of the Alexa Top Million Sites support TFO. Thus, only a few people on the Internet run TFO. However, most clients including Firefox and Chrome do not support TFO by default. As a result, the TFO traffic share on the Internet is approximately far below 3.2%. Best regards Erik > Cheers, > > Brian > >> If a server is overloaded and can't process any more TFO data, the result could be that it just doesn't answer at all, and the client would then retransmit the SYN, just as if the SYN had been dropped. >> >> >> Cheers, >> Michael >> >> >> >>> On 21 May 2019, at 09:52, Erik Sy wrote: >>> >>> Hi Michael, >>> >>> thanks for this question! >>> >>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>> client with a static local IP address in a home network will use the >>> same TFO cookie independently of it's publicly visible IP address. As a >>> result, TFO cookies present an independent tracking mechanism, which >>> does not necessarily rely on the client's publicly visible IP address. >>> >>> Returning to your example, onion routing does not necessarily protect >>> you against tracking via TFO cookies. >>> >>> Best regards, >>> Erik >>> >>> On 5/21/19 09:13, Michael Tuexen wrote: >>>>> On 20. May 2019, at 23:19, Erik Sy wrote: >>>>> >>>>> I think it is important to warn users about the privacy risks of RFC >>>>> 7413. For example, Mozilla reacted to the privacy problems of TCP Fast >>>>> Open by deprecating this protocol on all it's Firefox branches. In >>>>> total, TCP Fast Open has significant issues with respect to user >>>>> privacy, performance and deployment on the real-world Internet. From my >>>>> point of view, it is about time to deprecate RFC 7413. >>>> Hi Eric, >>>> >>>> my understanding is that a cookie is specific to a client address, a server >>>> address and a server port. So it would make sense for a client to remove >>>> entries from the cookie cache on an address change. Assuming that, how >>>> does your described host based attacks relate to the server just using >>>> the client IP address for tracking? If you are trying to hide you IP-address >>>> (like using a TOR browser) you don't want to use TFO, but you are not >>>> optimising for small RTTs in that case, so it makes no sense in that case. >>>> >>>> Best regards >>>> Michael >>>>> Regards, >>>>> Erik >>>>> >>>>> On 5/10/19 14:14, Erik Sy wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> TCP Fast Open has significant privacy problems which are not considered >>>>>> in RFC 7413. >>>>>> For example, this protocol allows a passive network observer to >>>>>> correlate connections established by the same client, which protocols >>>>>> such as TLS 1.3 and QUIC actively protect against. Furthermore, Fast >>>>>> Open cookies present a kernel-based tracking mechanism which is quite >>>>>> persistent. Amongst others, they can be used to conduct cross-browser >>>>>> tracking on the same operating system. >>>>>> For further details please refer to this article: >>>>>> https://arxiv.org/pdf/1905.03518.pdf >>>>>> >>>>>> I suggest, that the working group takes steps to highlight these privacy >>>>>> problems of RFC 7413. >>>>>> >>>>>> Regards, >>>>>> Erik >>>>>> >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue May 21 13:51:10 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4AC1200FD for ; Tue, 21 May 2019 13:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EqbYzFnGgkVN for ; Tue, 21 May 2019 13:51:06 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 B8B6D1200FB for ; Tue, 21 May 2019 13:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E91AEBD8; Tue, 21 May 2019 22:51:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YHYHEZtZRKu7; Tue, 21 May 2019 22:51:03 +0200 (CEST) Received: from users-MBP.fritz.box (i59F5CC20.versanet.de [89.245.204.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id A4B9DBD7; Tue, 21 May 2019 22:51:01 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm@ietf.org References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> Date: Tue, 21 May 2019 22:51:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 20:51:09 -0000 On 5/21/19 21:56, Michael Tuexen wrote: >> On 21. May 2019, at 21:22, Erik Sy wrote: >> >> >> On 5/21/19 18:34, Michael Tuexen wrote: >>>> On 21. May 2019, at 14:25, Erik Sy wrote: >>>> >>>> >>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>> On 21. May 2019, at 09:52, Erik Sy wrote: >>>>>> >>>>>> Hi Michael, >>>>>> >>>>>> thanks for this question! >>>>>> >>>>>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>>>>> client with a static local IP address in a home network will use the >>>>>> same TFO cookie independently of it's publicly visible IP address. As a >>>>>> result, TFO cookies present an independent tracking mechanism, which >>>>>> does not necessarily rely on the client's publicly visible IP address. >>>>> How often do the public addresses change? >>>> I do not have a general answer to your question. In the case of my home >>>> network, my ISP assigns me at least every 24 hours a new IPv4 address. >>> I also had this on my DSL line (I guess we both live in Germany), >>> but since my telephone line was moved to "all IP", the assignment stays >>> up for months. >>>> Additionally, I can initiate a change of my network's public IP address >>>> at anytime. >>> Sure. >>>> TFO cookies allow basically unlimited tracking periods because they do >>>> not have an expiration mechanism. Thus, even infrequently changed IP >>>> addresses can be correlated. >>> An implementation can do implement such a thing and even allow an API for it. >> Yes, I agree with you that implementations can go beyond RFC 7413 and >> implement an expiration mechanism limiting feasible tracking periods. >> >>> For testing I'm flushing the cookie cache quite often... >>>>> One could extend the TFO API in >>>>> a way that the application can request a new cookie by only sending >>>>> a cookie request. >>>> I do not think this is an appropriate countermeasure. >>>> >>>> From my perspective, caching TFO cookies in the kernel is a more >>>> fundamental privacy problem. This design requires applications to share >>>> a pool of TFO cookies, which allows tracking across several >>>> applications. For example, this prevents user's to separate their online >>>> activities across different browsers. >>> They would share the IP address. If they decide to trigger a new address >>> binding on the access router, why couldn't they trigger flushing the >>> cache? >> Flushing the cache presents a performance versus privacy trade off >> because flushing increases the chance of a cache miss preventing a 0-RTT >> handshake. > Sure it does. It was just meant as an equivalent to resetting the > public IP address of your access router. This also affects all outgoing > connections. >> Thus, an application that often flushes the cache degrades the >> performance of all other applications sharing the same pool of TFO cookies. >> As a result, the application with the highest privacy requirements >> limits the TFO performance of all other applications. >> >> Furthermore flushing has difficulties to separate applications running >> at the same time. For example, running a browser window in the normal >> browsing mode and another window in the private browsing mode >> (incognito). In this scenario, only excessive flushing can prevent an >> online tracker to link the user's online activities across both browser >> windows. > Can't they both be linked by the IP address being used? Tracking via IP addresses has the limitation that it cannot differentiate clients behind a NAT. However, TFO cookies can be used to overcome this limitation if each TFO connection from the same IP address gets assigned a unique token. Thus, reusing such a unique token during a connection request allows a more accurate tracking than can be done via the publicly visible IP addresses. >> From my perspective, an approach that delegates the caching to the >> application itself, is the better solution to address this privacy >> versus performance trade off. Moreover, I believe users tend to make the > How does this prevent "tracking by IP-address" compared to "tracking > by TFO cookie"? As described, tracking by IP addresses has limitations especially if several users share the same IP address or change their publicly visible IP address frequently. As discussed, tracking via TFO cookies can be more persistent and more precise than tracking by IP addresses. Applications controlling their retrieved TFO cookies can provide upper boundaries for feasible tracking periods via this mechanism without affecting the TFO performance of other applications. Furthermore, caching TFO cookies separately within each application prevents tracking user activities across these different applications on the same device. Best regards, Erik > > Best regards > Michael >> application/browser vendor responsible to protect their privacy. Thus, >> these vendors require appropriate measures to control their users' privacy. >> >> Best regards, >> Erik >> >>> Best regards >>> Michael >>>>>> Returning to your example, onion routing does not necessarily protect >>>>>> you against tracking via TFO cookies. >>>>> Yepp, that is what I wanted to say. >>>>> But using TFO in that case doesn't >>>>> make much sense. >>>> Yes, TFO does not make sense if user privacy is at stake. Thus, we >>>> should warn users about these risks of RFC 7413. >>>> >>>> Best regards, >>>> Erik >>>> >>>> From nobody Tue May 21 15:13:20 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C703712029D for ; Tue, 21 May 2019 15:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 GZXHyq2NYAKl for ; Tue, 21 May 2019 15:13:11 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 E8FFA120232 for ; Tue, 21 May 2019 15:13:10 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hTD0L-0000Oq-Te; Wed, 22 May 2019 00:13:05 +0200 Received: from 223.247.16.62.customer.cdi.no ([62.16.247.223] helo=[10.0.0.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1hTD0J-000AJC-Th; Wed, 22 May 2019 00:13:05 +0200 From: Michael Welzl Message-Id: <9F56B293-307F-4CE8-BD10-117F792CF272@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 22 May 2019 00:13:01 +0200 In-Reply-To: <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> Cc: Erik Sy , Michael Tuexen , tcpm IETF list To: Brian Trammell References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> X-Mailer: Apple Mail (2.3445.104.8) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 62.16.247.223 is neither permitted nor denied by domain of ifi.uio.no) client-ip=62.16.247.223; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.8]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 983132B18C42CAF9F8950C8CF58B3E267B9669DB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 22:13:19 -0000 --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, See below: > On May 21, 2019, at 4:47 PM, Brian Trammell wrote: >=20 > hi Michael, >=20 > Further foolishness inside ;) >=20 >> On 21 May 2019, at 09:39, Michael Welzl wrote: >>=20 >> Hi all, >>=20 >> I'm about to make a fool of myself because I'm quite certain that I'm = missing something. >> But, I guess this is worth the risk - somehow I'm not risking much, = as most people on this list already know me well enough to not be = surprised by another foolish idea coming from me :) >>=20 >>=20 >> So... >>=20 >>=20 >> Actually, couldn't we just remove the cookie from TFO? >>=20 >>=20 >> As far as I understand, the main point of the cookie is to protect = the server against clients that might spoof their IP addresses and just = send tons of requests to the server - which could potentially be much = heavier to handle than just the SYN state without TFO. >> To some degree, this is an OS problem, not a network problem: methods = could be in place to limit the time an application spends answering = requests that are carried on SYNs. My question is: wouldn't that be = enough? >=20 > All simple cookie based-approaches have a pretty simple tradeoff: use = a cookie which references some previous visible exchange between client = and server, trading off load reduction on the server (and flexibility in = deployment of DoS protection in front of the server) for traceability = (which, in this case, is a requirement, not something to be avoided). = The design of TFO (and SYN cookies before it).=20 >=20 > More advanced 0RTT tokens have a different tradeoff; since the token = is established between client and server without being observable on the = path, here we gain traceability protection and retain server load = reduction, but give up the ability to have front-ends that can reject = attack traffic without some form of coordination with the server. >=20 >> A few years ago, I'm sure that such a proposal would have been shot = by people saying that data carried by TCP is general and TCP must serve = all applications, and that we can't have that kind of special treatment = for data arriving via SYNs. >> However, TFO has already departed from this generality, in several = ways: applications using it must be able to handle incoming duplicate = requests; they need to use special API calls to access the data; = importantly (for the point I'm making), rate limits should already be in = place when using TFO (RFC 7413, section 5.1). >>=20 >> So what I'm proposing is: couldn't we re-write TFO to just remove the = Cookie from it, and say: "it's allowed for applications to accept data = that comes with a SYN right away, but this must be done in a special way = (as already described in RFC 7413), and in particular, the time an = application spends processing TFO requests must be limited to avoid = being DDoSed?" >=20 > You're correct to point out that 0RTT resumption is and will always = remain special, not only due to the special requirements it places on = applications but also for cryptographic reasons (0RTT cannot be made = forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different = cryptographic properties than the rest of the session).=20 >=20 > ISTM there are the following possibilities: >=20 > (1) Do nothing. >=20 > (1a) Do nothing, but issue guidance in an informational RFC notinf = that TFO cookies are traceable, and should be avoided in the open = Internet when=20 >=20 > (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); = explain the privacy reason behind the deprecation in the deprecated = document. >=20 > (3) Update TFO to make TFO cookies optional, and explain the = tradeoffs. >=20 > I would expect pushback on 2 or 3 from people running TFO on the = Internet, because it requires coordinated implementation effort and = changes the operational environment (which always carries risk). Why would 3 require coordinated implementation effort? Just to make sure we=E2=80=99re on the same page, I=E2=80=99m proposing = to allow handing over data from the SYN directly (with all the needed = caveats and warnings), even when there=E2=80=99s no TFO option in place. If a server doesn=E2=80=99t support this yet, it takes an RTT longer. If = a client doesn=E2=80=99t support this yet (and hence only puts in data = on a SYN *with* the TFO option), nothing bad happens, except that there = are the privacy concerns that kicked off this thread. When a client = doesn=E2=80=99t support this and does *not* put data on a SYN, nothing = special happens. This seems like a good gradual upgrade path for me. Regarding front-ends, I guess they could make rejection decisions when = they see too many SYNs carrying data with or without a TFO option. Perhaps this also answers Michael Tuexen=E2=80=99s comment about = https://tools.ietf.org/html/rfc7413#section-7.3 = - which has = similarities, but: - the first paragraph sounds a bit too limiting: I mean this as a = general use thing, just like TFO, only with the caveat of having to = limit the load somehow=E2=80=A6 e.g. limit how many of these = messages-on-SYNs an app processes per second. - the second paragraph is in conflict with what I=E2=80=99m proposing: = it talks about generating "a trivial or even a zero-length cookie=E2=80=9D= and switching to regular TFO as a fall-back. I=E2=80=99m proposing = operation without a TFO option; just relax the =E2=80=9Chow to process = data from SYN=E2=80=9D rule and state all the necessary warnings. > There is the caveat that I'm not sure how many are running TFO on the = Internet. (I do know Google was the biggest one, at least a couple of = years ago, from research I did before joining). Yep, that too=E2=80=A6 just relaxing the =E2=80=9Chow to process = data-on-SYN" rule seems easier to deploy. Cheers, Michael --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

See = below:

On May 21, 2019, at 4:47 PM, Brian Trammell = <ietf@trammell.ch> wrote:

hi Michael,

Further foolishness inside = ;)

On 21 = May 2019, at 09:39, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi all,

I'm about to make a fool of myself because I'm quite certain = that I'm missing something.
But, I guess this is worth the = risk - somehow I'm not risking much, as most people on this list already = know me well enough to not be surprised by another foolish idea coming = from me   :)


So...


Actually, = couldn't we just remove the cookie from TFO?


As far as I understand, the main point of the = cookie is to protect the server against clients that might spoof their = IP addresses and just send tons of requests to the server - which could = potentially be much heavier to handle than just the SYN state without = TFO.
To some degree, this is an OS problem, not a network = problem: methods could be in place to limit the time an application = spends answering requests that are carried on SYNs. My question is: = wouldn't that be enough?

All simple cookie = based-approaches have a pretty simple tradeoff: use a cookie which = references some previous visible exchange between client and server, = trading off load reduction on the server (and flexibility in deployment = of DoS protection in front of the server) for traceability (which, in = this case, is a requirement, not something to be avoided). The design of = TFO (and SYN cookies before it). 

More advanced 0RTT tokens have a = different tradeoff; since the token is established between client and = server without being observable on the path, here we gain traceability = protection and retain server load reduction, but give up the ability to = have front-ends that can reject attack traffic without some form of = coordination with the server.

A few years ago, I'm sure that such a = proposal would have been shot by people saying that data carried by TCP = is general and TCP must serve all applications, and that we can't have = that kind of special treatment for data arriving via SYNs.
However, TFO has already departed from this generality, in = several ways: applications using it must be able to handle incoming = duplicate requests; they need to use special API calls to access the = data; importantly (for the point I'm making), rate limits should already = be in place when using TFO (RFC 7413, section 5.1).

So what I'm proposing is: couldn't we re-write TFO to just = remove the Cookie from it, and say: "it's allowed for applications to = accept data that comes with a SYN right away, but this must be done in a = special way (as already described in RFC 7413), and in particular, the = time an application spends processing TFO requests must be limited to = avoid being DDoSed?"

You're correct to point out that 0RTT resumption is and will = always remain special, not only due to the special requirements it = places on applications but also for cryptographic reasons (0RTT cannot = be made forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has = different cryptographic properties than the rest of the session). 

ISTM there are the following = possibilities:

(1) Do nothing.

(1a) Do nothing, but issue guidance in an informational RFC = notinf that TFO cookies are traceable, and should be avoided in the open = Internet when 
(2) Deprecate TFO (and hope = people who want 0RTT migrate to QUIC); explain the privacy reason behind = the deprecation in the deprecated document.

(3) Update TFO to make TFO = cookies optional, and explain the tradeoffs.

I would expect pushback on 2 or = 3 from people running TFO on the Internet, because it requires = coordinated implementation effort and changes the operational = environment (which always carries risk).

Why would 3 require coordinated implementation = effort?
Just to make sure we=E2=80=99re on the same page, = I=E2=80=99m proposing to allow handing over data from the SYN directly = (with all the needed caveats and warnings), even when there=E2=80=99s no = TFO option in place.
If a server doesn=E2=80=99t support this = yet, it takes an RTT longer. If a client doesn=E2=80=99t support this = yet (and hence only puts in data on a SYN *with* the TFO option), = nothing bad happens, except that there are the privacy concerns that = kicked off this thread. When a client doesn=E2=80=99t support this and = does *not* put data on a SYN, nothing special happens. This seems like a = good gradual upgrade path for me.
Regarding front-ends, I = guess they could make rejection decisions when they see too many SYNs = carrying data with or without a TFO option.

Perhaps this also answers Michael Tuexen=E2=80=99s = comment about  https://tools.ietf.org/html/rfc7413#section-7.3  - = which has similarities, but:
- the first paragraph sounds a = bit too limiting: I mean this as a general use thing, just like TFO, = only with the caveat of having to limit the load somehow=E2=80=A6 e.g. = limit how many of these messages-on-SYNs an app processes per = second.
- the second paragraph is in conflict with what I=E2=80=99= m proposing: it talks about generating "a trivial or even a zero-length = cookie=E2=80=9D and switching to regular TFO as a fall-back. I=E2=80=99m = proposing operation without a TFO option; just relax the =E2=80=9Chow to = process data from SYN=E2=80=9D rule and state all the necessary = warnings.


There is the caveat that I'm not sure how many are running = TFO on the Internet. (I do know Google was the biggest one, at least a = couple of years ago, from research I did before = joining).

Yep, that = too=E2=80=A6 just relaxing the =E2=80=9Chow to process data-on-SYN" rule = seems easier to deploy.

Cheers,
Michael

= --Apple-Mail=_BCC41475-1AC5-40CA-AE63-3BF55177DD4A-- From nobody Wed May 22 00:10:32 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B861200E6 for ; Wed, 22 May 2019 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 bI9xh7dvk-Dg for ; Wed, 22 May 2019 00:10:27 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 CD50512008B for ; Wed, 22 May 2019 00:10:26 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id j187so962881wmj.1 for ; Wed, 22 May 2019 00:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N8K6Gxx+cNbdGAnF5T9JAdd1hDbVPqCelEHw4EKxIno=; b=zYxKhj0OUWNpiszMcq50CvdBoaSW4pPu9N89uXuPEtTSLAhto+8edCkIbGJPqaY/2E HNVEqMJWlfDp3ydJI6lSQ5IkhQT+AHVPlce5GA1qRXVgvWDMYBG6qlvzZ4KivJwVEb9q +DtzN/B4U9nfetOzhEw8QxHp1zmycYKbXcU/cy9mzYejJqSBuQJHLe8E/svv0dKoleDs 59UIEZncwTK/P8pd8XE70YfFtidWkQ3EOrJfdAOW0iTPweUxo2ihTRQ712PqIMgO6I74 WlvbjAFZk/Og0v0sVrv20/X7hF4i3+dWLYlmpojTbxHP68nDu6sVUsnjZaqLZxH+SzIh F9rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N8K6Gxx+cNbdGAnF5T9JAdd1hDbVPqCelEHw4EKxIno=; b=ezbPr3fYSZCHdEdBN+I3Ku61Gsn4ylqZoRXZjSQ9VHxptMm80cfIhi5bXx0YsG/Y9J 2FmsUDcjcAj0nVHZvxP/6EWf1Y7YX0rT0fzKqk5/wA19kg07gZDJZLkra7AzflIg6BFr LesX/up3RAgPk4PuLXvoKHGjZNcZgQI+aAzYD3J2bJk2v056wSOtH8/vgH7MxGYZpG3q /fTnqL91KMzGBoeqRtYaP0xGWathJCUEplIe2YsJ0dQo5pw+CQMoyFdz9wRStMv9ouFU ZxfDxydj+vA9WSFeL2EgzktAaj9SwuDV/alXF8aOyP3OMExiMRZ2JzhlsuFfAltwHMwx p+sw== X-Gm-Message-State: APjAAAVNbeZnAi/5Zy/k63cDv6wC6U4BH56KQGTmLfleDtrIsej7Dzs0 oDll1HRqUtw6Y2vBD+mbwPmmzPxh4H/LLspTFjgXyUIqnnnKBctwnpKdipA9Vmoyc0kiM+5R X-Google-Smtp-Source: APXvYqwpeCDWGJXy6Tvosr9EJPdU8M7O98YnpnEb7z8K5S5ZOSfgemcPTH+TW1t4XnzX9k5y7nljiA== X-Received: by 2002:a05:600c:10ca:: with SMTP id l10mr6526051wmd.23.1558509024799; Wed, 22 May 2019 00:10:24 -0700 (PDT) Received: from ?IPv6:2001:6a8:308f:2:473:d768:6978:2d29? ([2001:6a8:308f:2:473:d768:6978:2d29]) by smtp.gmail.com with ESMTPSA id t194sm8639851wmt.3.2019.05.22.00.10.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 00:10:23 -0700 (PDT) From: Olivier Bonaventure Message-Id: <34AADC0D-B82C-4BD6-8A83-93749F350AAF@tessares.net> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 May 2019 09:10:22 +0200 In-Reply-To: <9F56B293-307F-4CE8-BD10-117F792CF272@ifi.uio.no> Cc: Brian Trammell , Michael Tuexen , tcpm IETF list To: Michael Welzl References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> <9F56B293-307F-4CE8-BD10-117F792CF272@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) Content-Type: multipart/alternative; boundary="Apple-Mail=_5F4E3698-3D92-43BD-B5CB-C78A3C0D069F" Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 07:10:31 -0000 --Apple-Mail=_5F4E3698-3D92-43BD-B5CB-C78A3C0D069F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Michael, Brian, >>>=20 >>>=20 >>=20 >> You're correct to point out that 0RTT resumption is and will always rema= in special, not only due to the special requirements it places on applicati= ons but also for cryptographic reasons (0RTT cannot be made forward-secret,= so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic proper= ties than the rest of the session).=20 >>=20 >> ISTM there are the following possibilities: >>=20 >> (1) Do nothing. >>=20 >> (1a) Do nothing, but issue guidance in an informational RFC notinf that = TFO cookies are traceable, and should be avoided in the open Internet when= =20 >>=20 >> (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); expla= in the privacy reason behind the deprecation in the deprecated document. >>=20 >> (3) Update TFO to make TFO cookies optional, and explain the tradeoffs. >>=20 >> I would expect pushback on 2 or 3 from people running TFO on the Interne= t, because it requires coordinated implementation effort and changes the op= erational environment (which always carries risk). >=20 > Why would 3 require coordinated implementation effort? > Just to make sure we=E2=80=99re on the same page, I=E2=80=99m proposing t= o allow handing over data from the SYN directly (with all the needed caveat= s and warnings), even when there=E2=80=99s no TFO option in place. During the Prague meeting, Christoph Paasch explained that this approach is= already used by a specific application. The 0-rtt convert protocol also pr= oposes to use this approach. > If a server doesn=E2=80=99t support this yet, it takes an RTT longer. If = a client doesn=E2=80=99t support this yet (and hence only puts in data on a= SYN *with* the TFO option), nothing bad happens, except that there are the= privacy concerns that kicked off this thread. When a client doesn=E2=80=99= t support this and does *not* put data on a SYN, nothing special happens. T= his seems like a good gradual upgrade path for me. > Regarding front-ends, I guess they could make rejection decisions when th= ey see too many SYNs carrying data with or without a TFO option. I agree, there are various techniques to deal with DoS attacks on a stack a= nd inside specialised protocols. >=20 > Perhaps this also answers Michael Tuexen=E2=80=99s comment about https:/= /tools.ietf.org/html/rfc7413#section-7.3 - which has similarities, but: > - the first paragraph sounds a bit too limiting: I mean this as a general= use thing, just like TFO, only with the caveat of having to limit the load= somehow=E2=80=A6 e.g. limit how many of these messages-on-SYNs an app proc= esses per second. > - the second paragraph is in conflict with what I=E2=80=99m proposing: it= talks about generating "a trivial or even a zero-length cookie=E2=80=9D an= d switching to regular TFO as a fall-back. I=E2=80=99m proposing operation = without a TFO option; just relax the =E2=80=9Chow to process data from SYN= =E2=80=9D rule and state all the necessary warnings. >=20 >=20 >> There is the caveat that I'm not sure how many are running TFO on the In= ternet. (I do know Google was the biggest one, at least a couple of years a= go, from research I did before joining). >=20 > Yep, that too=E2=80=A6 just relaxing the =E2=80=9Chow to process data-on-= SYN" rule seems easier to deploy. >=20 RFC793 authorises data in the SYN and Christoph=E2=80=99s explanation shows= that today SYN with data but without TFO option pass through more paths th= an SYN with data but with a TFO option Olivier --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 --Apple-Mail=_5F4E3698-3D92-43BD-B5CB-C78A3C0D069F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Michael, Brian,




You're cor= rect to point out that 0RTT resumption is and will always remain special, n= ot only due to the special requirements it places on applications but also = for cryptographic reasons (0RTT cannot be made forward-secret, so data sent= in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the= rest of the session). 

ISTM there are the following possibilities:

(1) Do nothing.

(1a) Do nothing, but issue guidance in an = informational RFC notinf that TFO cookies are traceable, and should be avoi= ded in the open Internet when 

(2) Deprecate TFO (and hope people who want 0RTT migr= ate to QUIC); explain the privacy reason behind the deprecation in the depr= ecated document.

(3) Update TFO to make TFO cookies optiona= l, and explain the tradeoffs.
=
I would expect pushback on 2 = or 3 from people running TFO on the Internet, because it requires coordinat= ed implementation effort and changes the operational environment (which alw= ays carries risk).

Why would 3 re= quire coordinated implementation effort?
Just to make = sure we=E2=80=99re on the same page, I=E2=80=99m proposing to allow handing= over data from the SYN directly (with all the needed caveats and warnings)= , even when there=E2=80=99s no TFO option in place.
=

During the Prague meeting, Chri= stoph Paasch explained that this approach is already used by a specific app= lication. The 0-rtt convert protocol also proposes to use this approach.
If a server does= n=E2=80=99t support this yet, it takes an RTT longer. If a client doesn=E2= =80=99t support this yet (and hence only puts in data on a SYN *with* the T= FO option), nothing bad happens, except that there are the privacy concerns= that kicked off this thread. When a client doesn=E2=80=99t support this an= d does *not* put data on a SYN, nothing special happens. This seems like a = good gradual upgrade path for me.
Regarding front-ends= , I guess they could make rejection decisions when they see too many SYNs c= arrying data with or without a TFO option.

I agree, there are various techniques to deal= with DoS attacks on a stack and inside specialised protocols.

Perhaps this also answers Michael Tuexen=E2=80=99s comment about &nbs= p;ht= tps://tools.ietf.org/html/rfc7413#section-7.3  - which has similar= ities, but:
- the first paragraph sounds a bit too lim= iting: I mean this as a general use thing, just like TFO, only with the cav= eat of having to limit the load somehow=E2=80=A6 e.g. limit how many of the= se messages-on-SYNs an app processes per second.
- the= second paragraph is in conflict with what I=E2=80=99m proposing: it talks = about generating "a trivial or even a zero-length cookie=E2=80=9D and switc= hing to regular TFO as a fall-back. I=E2=80=99m proposing operation without= a TFO option; just relax the =E2=80=9Chow to process data from SYN=E2=80= =9D rule and state all the necessary warnings.


There is the caveat that I'm not sure how many are running TF= O on the Internet. (I do know Google was the biggest one, at least a couple= of years ago, from research I did before joining).

Yep, that too=E2=80=A6 just relaxing= the =E2=80=9Chow to process data-on-SYN" rule seems easier to deploy.


RFC793 authorises data in the SYN and Christoph=E2=80=99s exp= lanation shows that today SYN with data but without TFO option pass through= more paths than SYN with data but with a TFO option


Olivier






--Apple-Mail=_5F4E3698-3D92-43BD-B5CB-C78A3C0D069F-- From nobody Wed May 22 00:47:41 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB28B1200FE for ; Wed, 22 May 2019 00:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 FTY6_4BR0ym9 for ; Wed, 22 May 2019 00:47:27 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 8C42C1200E6 for ; Wed, 22 May 2019 00:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id B3A11F6C; Wed, 22 May 2019 09:47:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id woOOd0ly1Y3I; Wed, 22 May 2019 09:47:25 +0200 (CEST) Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 590C0F6B; Wed, 22 May 2019 09:47:24 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Praveen Balasubramanian Cc: tcpm IETF list References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: Date: Wed, 22 May 2019 09:47:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 07:47:32 -0000 Hi Praveen, On 5/21/19 20:14, Praveen Balasubramanian wrote: > We are removing support for TFO only in the InPrivate (incognito) mode of the Edge browser. I'm happy to hear this :-) > IPv6 privacy addresses mitigate this somewhat. Let's say IPv6 addresses allow unique user identification for usually up to 24 hours. Thus, the additional privacy harm of TFO cookies is rather small. Do you support TFO cookies on IPv4 addresses? If yes, how do you plan to protect your users against unlimited tracking periods? > Also, TFO servers will expire the cookies periodically as well. This does not protect against this tracking mechanism. Server and network-based tracker can correlate the presented (invalid) TFO cookie with a subsequently issued TFO cookies. > I wouldn't be opposed to some expiration scheme on client as well. The deployment of such kernel patches takes several years. How do you plan to protect the user's privacy during this transition period? > And I am fine with adding some guidance around this. If TFO is to become a standards track RFC, then I agree that these concerns should be addressed. > > Let's not overreact and deprecate the only path we have for low latency setup on TCP. Achieving low latency TCP connection establishments is a noble goal. The Internet changed a lot during the last years with transport encryption becoming the new default. We can use this as a chance to improve TFO with respect to its privacy, performance and deployment. A state-of-the-art TFO version will not be downwards compatible with today's TFO. I suggest to stop the experiment of RFC 7413 and apply the lessons learned to make the Internet work better :-)   > Also, TFO could also be used on non-public Internet. I guess, you can run anything on non-public Intenet ;-) Best regards Erik > > Brian a lot of major servers now support TFO. Client support is the problem. > -----Original Message----- > From: tcpm On Behalf Of Brian Trammell > Sent: Tuesday, May 21, 2019 7:48 AM > To: Michael Welzl > Cc: Michael Tuexen ; tcpm IETF list > Subject: Re: [tcpm] Privacy problems of TCP Fast Open > > hi Michael, > > Further foolishness inside ;) > >> On 21 May 2019, at 09:39, Michael Welzl wrote: >> >> Hi all, >> >> I'm about to make a fool of myself because I'm quite certain that I'm missing something. >> But, I guess this is worth the risk - somehow I'm not risking much, as most people on this list already know me well enough to not be surprised by another foolish idea coming from me :) >> >> >> So... >> >> >> Actually, couldn't we just remove the cookie from TFO? >> >> >> As far as I understand, the main point of the cookie is to protect the server against clients that might spoof their IP addresses and just send tons of requests to the server - which could potentially be much heavier to handle than just the SYN state without TFO. >> To some degree, this is an OS problem, not a network problem: methods could be in place to limit the time an application spends answering requests that are carried on SYNs. My question is: wouldn't that be enough? > All simple cookie based-approaches have a pretty simple tradeoff: use a cookie which references some previous visible exchange between client and server, trading off load reduction on the server (and flexibility in deployment of DoS protection in front of the server) for traceability (which, in this case, is a requirement, not something to be avoided). The design of TFO (and SYN cookies before it). > > More advanced 0RTT tokens have a different tradeoff; since the token is established between client and server without being observable on the path, here we gain traceability protection and retain server load reduction, but give up the ability to have front-ends that can reject attack traffic without some form of coordination with the server. > >> A few years ago, I'm sure that such a proposal would have been shot by people saying that data carried by TCP is general and TCP must serve all applications, and that we can't have that kind of special treatment for data arriving via SYNs. >> However, TFO has already departed from this generality, in several ways: applications using it must be able to handle incoming duplicate requests; they need to use special API calls to access the data; importantly (for the point I'm making), rate limits should already be in place when using TFO (RFC 7413, section 5.1). >> >> So what I'm proposing is: couldn't we re-write TFO to just remove the Cookie from it, and say: "it's allowed for applications to accept data that comes with a SYN right away, but this must be done in a special way (as already described in RFC 7413), and in particular, the time an application spends processing TFO requests must be limited to avoid being DDoSed?" > You're correct to point out that 0RTT resumption is and will always remain special, not only due to the special requirements it places on applications but also for cryptographic reasons (0RTT cannot be made forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). > > ISTM there are the following possibilities: > > (1) Do nothing. > > (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO cookies are traceable, and should be avoided in the open Internet when > > (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain the privacy reason behind the deprecation in the deprecated document. > > (3) Update TFO to make TFO cookies optional, and explain the tradeoffs. > > I would expect pushback on 2 or 3 from people running TFO on the Internet, because it requires coordinated implementation effort and changes the operational environment (which always carries risk). > > There is the caveat that I'm not sure how many are running TFO on the Internet. (I do know Google was the biggest one, at least a couple of years ago, from research I did before joining). > > Cheers, > > Brian > >> If a server is overloaded and can't process any more TFO data, the result could be that it just doesn't answer at all, and the client would then retransmit the SYN, just as if the SYN had been dropped. >> >> >> Cheers, >> Michael >> >> >> >>> On 21 May 2019, at 09:52, Erik Sy wrote: >>> >>> Hi Michael, >>> >>> thanks for this question! >>> >>> Yes, TFO cookies are bound to the clients (local) IP address. >>> However, a client with a static local IP address in a home network >>> will use the same TFO cookie independently of it's publicly visible >>> IP address. As a result, TFO cookies present an independent tracking >>> mechanism, which does not necessarily rely on the client's publicly visible IP address. >>> >>> Returning to your example, onion routing does not necessarily protect >>> you against tracking via TFO cookies. >>> >>> Best regards, >>> Erik >>> >>> On 5/21/19 09:13, Michael Tuexen wrote: >>>>> On 20. May 2019, at 23:19, Erik Sy wrote: >>>>> >>>>> I think it is important to warn users about the privacy risks of >>>>> RFC 7413. For example, Mozilla reacted to the privacy problems of >>>>> TCP Fast Open by deprecating this protocol on all it's Firefox >>>>> branches. In total, TCP Fast Open has significant issues with >>>>> respect to user privacy, performance and deployment on the >>>>> real-world Internet. From my point of view, it is about time to deprecate RFC 7413. >>>> Hi Eric, >>>> >>>> my understanding is that a cookie is specific to a client address, a >>>> server address and a server port. So it would make sense for a >>>> client to remove entries from the cookie cache on an address change. >>>> Assuming that, how does your described host based attacks relate to >>>> the server just using the client IP address for tracking? If you are >>>> trying to hide you IP-address (like using a TOR browser) you don't >>>> want to use TFO, but you are not optimising for small RTTs in that case, so it makes no sense in that case. >>>> >>>> Best regards >>>> Michael >>>>> Regards, >>>>> Erik >>>>> >>>>> On 5/10/19 14:14, Erik Sy wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> TCP Fast Open has significant privacy problems which are not >>>>>> considered in RFC 7413. >>>>>> For example, this protocol allows a passive network observer to >>>>>> correlate connections established by the same client, which >>>>>> protocols such as TLS 1.3 and QUIC actively protect against. >>>>>> Furthermore, Fast Open cookies present a kernel-based tracking >>>>>> mechanism which is quite persistent. Amongst others, they can be >>>>>> used to conduct cross-browser tracking on the same operating system. >>>>>> For further details please refer to this article: >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>> arxiv.org%2Fpdf%2F1905.03518.pdf&data=02%7C01%7Cpravb%40micros >>>>>> oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2 >>>>>> d7cd011db47%7C1%7C1%7C636940469018140114&sdata=dkgWLSFZYKENl7l >>>>>> scesJExW6SbZCGfOUXEN8oPHWh2k%3D&reserved=0 >>>>>> >>>>>> I suggest, that the working group takes steps to highlight these >>>>>> privacy problems of RFC 7413. >>>>>> >>>>>> Regards, >>>>>> Erik >>>>>> >>>>>> _______________________________________________ >>>>>> tcpm mailing list >>>>>> tcpm@ietf.org >>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F >>>>>> www.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb% >>>>>> 40microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f14 >>>>>> 1af91ab2d7cd011db47%7C1%7C1%7C636940469018140114&sdata=05KZ4W% >>>>>> 2BrEPGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=0 >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw >>>>> ww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40 >>>>> microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af >>>>> 91ab2d7cd011db47%7C1%7C1%7C636940469018140114&sdata=05KZ4W%2BrE >>>>> PGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=0 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >>> .ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40micr >>> osoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d >>> 7cd011db47%7C1%7C1%7C636940469018140114&sdata=05KZ4W%2BrEPGOmzC0z >>> Uf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=0 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40micros >> oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd >> 011db47%7C1%7C1%7C636940469018140114&sdata=05KZ4W%2BrEPGOmzC0zUf4K >> GYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636940469018140114&sdata=05KZ4W%2BrEPGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&reserved=0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed May 22 09:07:27 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583D71200B8 for ; Wed, 22 May 2019 09:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 25dyd3rjc2u2 for ; Wed, 22 May 2019 09:07:22 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0720.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::720]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D95312013D for ; Wed, 22 May 2019 09:07:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=myoPEbNAxCBZwsweIW3bhbZ1dLaH+xtGr+YteOEsib8FoQbxUq5O1FaX1qlEUg45erJfv1AcRFa2QTyr4l/hH4nPz98mrZ1b49jROtXp9Vt4eBlRi2KfJTGXYtm3nuhoCIuIGJ4YdX0LTflFziQ8DuIHH5VuK6L65Mge8+qtDRw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+UMtRY5rj1NVMeNhKX5WPW1iCSXJafN0fg8tb7zXJRA=; b=mTDPZ8tmcFHZsOav99OldCsDowDCWcCZ8BKEEsJDlJRP0qZjijK2J0eN5GHQLo5j8Uson7BWVe2lEEs0iGbwRRZXd2kTfM1lDlIsQDLsYDPlnKHOsrJBwEZeC4i2d4D0kqFSSnlhu2Nt480vYDu60OZgVBVkT1cZlLWt2GOX6fc= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+UMtRY5rj1NVMeNhKX5WPW1iCSXJafN0fg8tb7zXJRA=; b=Xwkh+e6NPb9LsxDRS3sVAyfnSb9yzvkeUFLPKnEk/wJn3iXKCFthTNldAJqYjBre4woZ1panKgxtMwPFttRS1f5P3gPXO/NI4E+rNxdCqF8eNxXstdwlojB/NNSwnMJK1LXx+LE+hWhCM+/kYv+yvOuFNoZdXaxHUgYhUM4TS4c= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (2603:10b6:302:a::13) by MW2PR2101MB0938.namprd21.prod.outlook.com (2603:10b6:302:4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.6; Wed, 22 May 2019 16:07:17 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2%4]) with mapi id 15.20.1943.006; Wed, 22 May 2019 16:07:17 +0000 From: Praveen Balasubramanian To: "sy@informatik.uni-hamburg.de" , Praveen Balasubramanian CC: tcpm IETF list Thread-Topic: [tcpm] Privacy problems of TCP Fast Open Thread-Index: AQHVByn/aakJ4ZD9PEmuWaFrgWjVpKZ0lRMAgACl5ICAAArjgIAAHh2AgABWEQCAADks4IAA46aAgACK91A= Date: Wed, 22 May 2019 16:07:17 +0000 Message-ID: References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-22T16:07:15.2795746Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=68e3f33c-bdd6-4abb-aae0-9c4cb44cd215; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:3:e567:b3c1:7ad8:9e57] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b41f1afc-dbeb-49c0-22c1-08d6decf8fd0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB0938; x-ms-traffictypediagnostic: MW2PR2101MB0938: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(396003)(376002)(346002)(53754006)(13464003)(199004)(189003)(10090500001)(68736007)(2906002)(14444005)(99286004)(52396003)(8990500004)(7696005)(256004)(22452003)(316002)(73956011)(11346002)(229853002)(446003)(486006)(66556008)(64756008)(66446008)(86362001)(6436002)(476003)(186003)(71200400001)(76116006)(66476007)(66946007)(46003)(55016002)(6306002)(86612001)(2501003)(9686003)(71190400001)(66574012)(81166006)(561944003)(10290500003)(478600001)(8936002)(966005)(5660300002)(74316002)(52536014)(53936002)(6246003)(30864003)(25786009)(6116002)(110136005)(76176011)(6506007)(53546011)(102836004)(33656002)(14454004)(7736002)(305945005)(8676002)(81156014)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0938; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AqFyulFpaor0Zjzc1Ia1Yjxm/QFfvkOn8aPS3wNutPvBVE0ky7M3rze7AsMDTcN4uTZm6VvEE1fi5Hsdlv0jnf6CKyxfKxKhzjucefjTKtkLlBEAjSLHNMFSDVbjkXnGNN6omHzs5Fc6SIpUZSKfvQzxljviJNSCKx5JVQY5A5LQK3pozlTEKFDYkAQ5c7ROUf+p4DQF6JgMznVOnSMNFFGSGndY7p+hcxub2Qh3CyciG8Atw1YprCNnlS5OYNobWClwZEPKa1HeB/+PpX6K5fn+dNuUtf4pDlpYk+SbYeQZ50DUxjokjhr4AFabsZsGJvc6/tCNKPvsRjEEmW5kfCDnIWsVP7IHprGHyXcdnJaiNI42D+NWS7tRwJ2R78TnFG/GdJ0okDC1UfuIuUIUV2LPNz479oHlHHOVSerzG7k= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b41f1afc-dbeb-49c0-22c1-08d6decf8fd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2019 16:07:17.0773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0938 Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 16:07:26 -0000 Pj4gSWYgeWVzLCBob3cgZG8geW91IHBsYW4gdG8gcHJvdGVjdCB5b3VyIHVzZXJzIGFnYWluc3Qg dW5saW1pdGVkIHRyYWNraW5nIHBlcmlvZHM/DQpDdXJyZW50bHkgYnkgc2ltcGx5IG5vdCBlbmFi bGluZyBpdCBpbiBJblByaXZhdGUgYnJvd3NpbmcgbW9kZS4gSW4gZnV0dXJlIHdlIG1heSBleHBp cmUgY29va2llcyBwZXJpb2RpY2FsbHkuIEZXSVcgaW4gbXkgb2JzZXJ2YXRpb24gY29va2llcyBh cmUgZXhwaXJlZCBieSBzZXJ2ZXJzIGV2ZXJ5IGZldyBob3Vycy4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIEVyaWsgU3kNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDIyLCAyMDE5IDEyOjQ3IEFNDQpUbzog UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRm Lm9yZz4NCkNjOiB0Y3BtIElFVEYgbGlzdCA8dGNwbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb dGNwbV0gUHJpdmFjeSBwcm9ibGVtcyBvZiBUQ1AgRmFzdCBPcGVuDQoNCkhpIFByYXZlZW4sDQoN Ck9uIDUvMjEvMTkgMjA6MTQsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIHdyb3RlOg0KPiBXZSBh cmUgcmVtb3Zpbmcgc3VwcG9ydCBmb3IgVEZPIG9ubHkgaW4gdGhlIEluUHJpdmF0ZSAoaW5jb2du aXRvKSBtb2RlIG9mIHRoZSBFZGdlIGJyb3dzZXIuDQpJJ20gaGFwcHkgdG8gaGVhciB0aGlzIDot KQ0KPiBJUHY2IHByaXZhY3kgYWRkcmVzc2VzIG1pdGlnYXRlIHRoaXMgc29tZXdoYXQuDQoNCkxl dCdzIHNheSBJUHY2IGFkZHJlc3NlcyBhbGxvdyB1bmlxdWUgdXNlciBpZGVudGlmaWNhdGlvbiBm b3IgdXN1YWxseSB1cCB0byAyNCBob3Vycy4gVGh1cywgdGhlIGFkZGl0aW9uYWwgcHJpdmFjeSBo YXJtIG9mIFRGTyBjb29raWVzIGlzIHJhdGhlciBzbWFsbC4NCg0KRG8geW91IHN1cHBvcnQgVEZP IGNvb2tpZXMgb24gSVB2NCBhZGRyZXNzZXM/IElmIHllcywgaG93IGRvIHlvdSBwbGFuIHRvIHBy b3RlY3QgeW91ciB1c2VycyBhZ2FpbnN0IHVubGltaXRlZCB0cmFja2luZyBwZXJpb2RzPw0KDQo+ ICBBbHNvLCBURk8gc2VydmVycyB3aWxsIGV4cGlyZSB0aGUgY29va2llcyBwZXJpb2RpY2FsbHkg YXMgd2VsbC4NClRoaXMgZG9lcyBub3QgcHJvdGVjdCBhZ2FpbnN0IHRoaXMgdHJhY2tpbmcgbWVj aGFuaXNtLiBTZXJ2ZXIgYW5kIG5ldHdvcmstYmFzZWQgdHJhY2tlciBjYW4gY29ycmVsYXRlIHRo ZSBwcmVzZW50ZWQgKGludmFsaWQpIFRGTyBjb29raWUgd2l0aCBhIHN1YnNlcXVlbnRseSBpc3N1 ZWQgVEZPIGNvb2tpZXMuDQo+IEkgd291bGRuJ3QgYmUgb3Bwb3NlZCB0byBzb21lIGV4cGlyYXRp b24gc2NoZW1lIG9uIGNsaWVudCBhcyB3ZWxsLg0KVGhlIGRlcGxveW1lbnQgb2Ygc3VjaCBrZXJu ZWwgcGF0Y2hlcyB0YWtlcyBzZXZlcmFsIHllYXJzLiBIb3cgZG8geW91IHBsYW4gdG8gcHJvdGVj dCB0aGUgdXNlcidzIHByaXZhY3kgZHVyaW5nIHRoaXMgdHJhbnNpdGlvbiBwZXJpb2Q/DQo+ICBB bmQgSSBhbSBmaW5lIHdpdGggYWRkaW5nIHNvbWUgZ3VpZGFuY2UgYXJvdW5kIHRoaXMuIElmIFRG TyBpcyB0byBiZWNvbWUgYSBzdGFuZGFyZHMgdHJhY2sgUkZDLCB0aGVuIEkgYWdyZWUgdGhhdCB0 aGVzZSBjb25jZXJucyBzaG91bGQgYmUgYWRkcmVzc2VkLiANCj4NCj4gTGV0J3Mgbm90IG92ZXJy ZWFjdCBhbmQgZGVwcmVjYXRlIHRoZSBvbmx5IHBhdGggd2UgaGF2ZSBmb3IgbG93IGxhdGVuY3kg c2V0dXAgb24gVENQLiANCkFjaGlldmluZyBsb3cgbGF0ZW5jeSBUQ1AgY29ubmVjdGlvbiBlc3Rh Ymxpc2htZW50cyBpcyBhIG5vYmxlIGdvYWwuIFRoZSBJbnRlcm5ldCBjaGFuZ2VkIGEgbG90IGR1 cmluZyB0aGUgbGFzdCB5ZWFycyB3aXRoIHRyYW5zcG9ydCBlbmNyeXB0aW9uIGJlY29taW5nIHRo ZSBuZXcgZGVmYXVsdC4gV2UgY2FuIHVzZSB0aGlzIGFzIGEgY2hhbmNlIHRvIGltcHJvdmUgVEZP IHdpdGggcmVzcGVjdCB0byBpdHMgcHJpdmFjeSwgcGVyZm9ybWFuY2UgYW5kIGRlcGxveW1lbnQu IEEgc3RhdGUtb2YtdGhlLWFydCBURk8gdmVyc2lvbiB3aWxsIG5vdCBiZSBkb3dud2FyZHMgY29t cGF0aWJsZSB3aXRoIHRvZGF5J3MgVEZPLiBJIHN1Z2dlc3QgdG8gc3RvcCB0aGUgZXhwZXJpbWVu dCBvZiBSRkMgNzQxMyBhbmQgYXBwbHkgdGhlIGxlc3NvbnMgbGVhcm5lZCB0byBtYWtlIHRoZSBJ bnRlcm5ldCB3b3JrIGJldHRlciA6LSkgwqANCj4gQWxzbywgVEZPIGNvdWxkIGFsc28gYmUgdXNl ZCBvbiBub24tcHVibGljIEludGVybmV0Lg0KDQpJIGd1ZXNzLCB5b3UgY2FuIHJ1biBhbnl0aGlu ZyBvbiBub24tcHVibGljIEludGVuZXQgOy0pDQoNCkJlc3QgcmVnYXJkcw0KRXJpaw0KDQo+DQo+ IEJyaWFuIGEgbG90IG9mIG1ham9yIHNlcnZlcnMgbm93IHN1cHBvcnQgVEZPLiBDbGllbnQgc3Vw cG9ydCBpcyB0aGUgcHJvYmxlbS4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gVHJhbW1l bGwNCj4gU2VudDogVHVlc2RheSwgTWF5IDIxLCAyMDE5IDc6NDggQU0NCj4gVG86IE1pY2hhZWwg V2VsemwgPG1pY2hhd2VAaWZpLnVpby5ubz4NCj4gQ2M6IE1pY2hhZWwgVHVleGVuIDxtaWNoYWVs LnR1ZXhlbkBsdXJjaGkuZnJhbmtlbi5kZT47IHRjcG0gSUVURiBsaXN0IA0KPiA8dGNwbUBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFt0Y3BtXSBQcml2YWN5IHByb2JsZW1zIG9mIFRDUCBGYXN0 IE9wZW4NCj4NCj4gaGkgTWljaGFlbCwNCj4NCj4gRnVydGhlciBmb29saXNobmVzcyBpbnNpZGUg OykNCj4NCj4+IE9uIDIxIE1heSAyMDE5LCBhdCAwOTozOSwgTWljaGFlbCBXZWx6bCA8bWljaGF3 ZUBpZmkudWlvLm5vPiB3cm90ZToNCj4+DQo+PiBIaSBhbGwsDQo+Pg0KPj4gSSdtIGFib3V0IHRv IG1ha2UgYSBmb29sIG9mIG15c2VsZiBiZWNhdXNlIEknbSBxdWl0ZSBjZXJ0YWluIHRoYXQgSSdt IG1pc3Npbmcgc29tZXRoaW5nLg0KPj4gQnV0LCBJIGd1ZXNzIHRoaXMgaXMgd29ydGggdGhlIHJp c2sgLSBzb21laG93IEknbSBub3Qgcmlza2luZyBtdWNoLCBhcyBtb3N0IHBlb3BsZSBvbiB0aGlz IGxpc3QgYWxyZWFkeSBrbm93IG1lIHdlbGwgZW5vdWdoIHRvIG5vdCBiZSBzdXJwcmlzZWQgYnkg YW5vdGhlciBmb29saXNoIGlkZWEgY29taW5nIGZyb20gbWUgICA6KQ0KPj4NCj4+DQo+PiBTby4u Lg0KPj4NCj4+DQo+PiBBY3R1YWxseSwgY291bGRuJ3Qgd2UganVzdCByZW1vdmUgdGhlIGNvb2tp ZSBmcm9tIFRGTz8NCj4+DQo+Pg0KPj4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIG1haW4g cG9pbnQgb2YgdGhlIGNvb2tpZSBpcyB0byBwcm90ZWN0IHRoZSBzZXJ2ZXIgYWdhaW5zdCBjbGll bnRzIHRoYXQgbWlnaHQgc3Bvb2YgdGhlaXIgSVAgYWRkcmVzc2VzIGFuZCBqdXN0IHNlbmQgdG9u cyBvZiByZXF1ZXN0cyB0byB0aGUgc2VydmVyIC0gd2hpY2ggY291bGQgcG90ZW50aWFsbHkgYmUg bXVjaCBoZWF2aWVyIHRvIGhhbmRsZSB0aGFuIGp1c3QgdGhlIFNZTiBzdGF0ZSB3aXRob3V0IFRG Ty4NCj4+IFRvIHNvbWUgZGVncmVlLCB0aGlzIGlzIGFuIE9TIHByb2JsZW0sIG5vdCBhIG5ldHdv cmsgcHJvYmxlbTogbWV0aG9kcyBjb3VsZCBiZSBpbiBwbGFjZSB0byBsaW1pdCB0aGUgdGltZSBh biBhcHBsaWNhdGlvbiBzcGVuZHMgYW5zd2VyaW5nIHJlcXVlc3RzIHRoYXQgYXJlIGNhcnJpZWQg b24gU1lOcy4gTXkgcXVlc3Rpb24gaXM6IHdvdWxkbid0IHRoYXQgYmUgZW5vdWdoPw0KPiBBbGwg c2ltcGxlIGNvb2tpZSBiYXNlZC1hcHByb2FjaGVzIGhhdmUgYSBwcmV0dHkgc2ltcGxlIHRyYWRl b2ZmOiB1c2UgYSBjb29raWUgd2hpY2ggcmVmZXJlbmNlcyBzb21lIHByZXZpb3VzIHZpc2libGUg ZXhjaGFuZ2UgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciwgdHJhZGluZyBvZmYgbG9hZCByZWR1 Y3Rpb24gb24gdGhlIHNlcnZlciAoYW5kIGZsZXhpYmlsaXR5IGluIGRlcGxveW1lbnQgb2YgRG9T IHByb3RlY3Rpb24gaW4gZnJvbnQgb2YgdGhlIHNlcnZlcikgZm9yIHRyYWNlYWJpbGl0eSAod2hp Y2gsIGluIHRoaXMgY2FzZSwgaXMgYSByZXF1aXJlbWVudCwgbm90IHNvbWV0aGluZyB0byBiZSBh dm9pZGVkKS4gVGhlIGRlc2lnbiBvZiBURk8gKGFuZCBTWU4gY29va2llcyBiZWZvcmUgaXQpLiAN Cj4NCj4gTW9yZSBhZHZhbmNlZCAwUlRUIHRva2VucyBoYXZlIGEgZGlmZmVyZW50IHRyYWRlb2Zm OyBzaW5jZSB0aGUgdG9rZW4gaXMgZXN0YWJsaXNoZWQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZl ciB3aXRob3V0IGJlaW5nIG9ic2VydmFibGUgb24gdGhlIHBhdGgsIGhlcmUgd2UgZ2FpbiB0cmFj ZWFiaWxpdHkgcHJvdGVjdGlvbiBhbmQgcmV0YWluIHNlcnZlciBsb2FkIHJlZHVjdGlvbiwgYnV0 IGdpdmUgdXAgdGhlIGFiaWxpdHkgdG8gaGF2ZSBmcm9udC1lbmRzIHRoYXQgY2FuIHJlamVjdCBh dHRhY2sgdHJhZmZpYyB3aXRob3V0IHNvbWUgZm9ybSBvZiBjb29yZGluYXRpb24gd2l0aCB0aGUg c2VydmVyLg0KPg0KPj4gQSBmZXcgeWVhcnMgYWdvLCBJJ20gc3VyZSB0aGF0IHN1Y2ggYSBwcm9w b3NhbCB3b3VsZCBoYXZlIGJlZW4gc2hvdCBieSBwZW9wbGUgc2F5aW5nIHRoYXQgZGF0YSBjYXJy aWVkIGJ5IFRDUCBpcyBnZW5lcmFsIGFuZCBUQ1AgbXVzdCBzZXJ2ZSBhbGwgYXBwbGljYXRpb25z LCBhbmQgdGhhdCB3ZSBjYW4ndCBoYXZlIHRoYXQga2luZCBvZiBzcGVjaWFsIHRyZWF0bWVudCBm b3IgZGF0YSBhcnJpdmluZyB2aWEgU1lOcy4NCj4+IEhvd2V2ZXIsIFRGTyBoYXMgYWxyZWFkeSBk ZXBhcnRlZCBmcm9tIHRoaXMgZ2VuZXJhbGl0eSwgaW4gc2V2ZXJhbCB3YXlzOiBhcHBsaWNhdGlv bnMgdXNpbmcgaXQgbXVzdCBiZSBhYmxlIHRvIGhhbmRsZSBpbmNvbWluZyBkdXBsaWNhdGUgcmVx dWVzdHM7IHRoZXkgbmVlZCB0byB1c2Ugc3BlY2lhbCBBUEkgY2FsbHMgdG8gYWNjZXNzIHRoZSBk YXRhOyBpbXBvcnRhbnRseSAoZm9yIHRoZSBwb2ludCBJJ20gbWFraW5nKSwgcmF0ZSBsaW1pdHMg c2hvdWxkIGFscmVhZHkgYmUgaW4gcGxhY2Ugd2hlbiB1c2luZyBURk8gKFJGQyA3NDEzLCBzZWN0 aW9uIDUuMSkuDQo+Pg0KPj4gU28gd2hhdCBJJ20gcHJvcG9zaW5nIGlzOiBjb3VsZG4ndCB3ZSBy ZS13cml0ZSBURk8gdG8ganVzdCByZW1vdmUgdGhlIENvb2tpZSBmcm9tIGl0LCBhbmQgc2F5OiAi aXQncyBhbGxvd2VkIGZvciBhcHBsaWNhdGlvbnMgdG8gYWNjZXB0IGRhdGEgdGhhdCBjb21lcyB3 aXRoIGEgU1lOIHJpZ2h0IGF3YXksIGJ1dCB0aGlzIG11c3QgYmUgZG9uZSBpbiBhIHNwZWNpYWwg d2F5IChhcyBhbHJlYWR5IGRlc2NyaWJlZCBpbiBSRkMgNzQxMyksIGFuZCBpbiBwYXJ0aWN1bGFy LCB0aGUgdGltZSBhbiBhcHBsaWNhdGlvbiBzcGVuZHMgcHJvY2Vzc2luZyBURk8gcmVxdWVzdHMg bXVzdCBiZSBsaW1pdGVkIHRvIGF2b2lkIGJlaW5nIEREb1NlZD8iDQo+IFlvdSdyZSBjb3JyZWN0 IHRvIHBvaW50IG91dCB0aGF0IDBSVFQgcmVzdW1wdGlvbiBpcyBhbmQgd2lsbCBhbHdheXMgcmVt YWluIHNwZWNpYWwsIG5vdCBvbmx5IGR1ZSB0byB0aGUgc3BlY2lhbCByZXF1aXJlbWVudHMgaXQg cGxhY2VzIG9uIGFwcGxpY2F0aW9ucyBidXQgYWxzbyBmb3IgY3J5cHRvZ3JhcGhpYyByZWFzb25z ICgwUlRUIGNhbm5vdCBiZSBtYWRlIGZvcndhcmQtc2VjcmV0LCBzbyBkYXRhIHNlbnQgaW4gMFJU VCBmb3IgVExTMS4zIG9yIFFVSUMgaGFzIGRpZmZlcmVudCBjcnlwdG9ncmFwaGljIHByb3BlcnRp ZXMgdGhhbiB0aGUgcmVzdCBvZiB0aGUgc2Vzc2lvbikuIA0KPg0KPiBJU1RNIHRoZXJlIGFyZSB0 aGUgZm9sbG93aW5nIHBvc3NpYmlsaXRpZXM6DQo+DQo+ICgxKSBEbyBub3RoaW5nLg0KPg0KPiAo MWEpIERvIG5vdGhpbmcsIGJ1dCBpc3N1ZSBndWlkYW5jZSBpbiBhbiBpbmZvcm1hdGlvbmFsIFJG QyBub3RpbmYgDQo+IHRoYXQgVEZPIGNvb2tpZXMgYXJlIHRyYWNlYWJsZSwgYW5kIHNob3VsZCBi ZSBhdm9pZGVkIGluIHRoZSBvcGVuIA0KPiBJbnRlcm5ldCB3aGVuDQo+DQo+ICgyKSBEZXByZWNh dGUgVEZPIChhbmQgaG9wZSBwZW9wbGUgd2hvIHdhbnQgMFJUVCBtaWdyYXRlIHRvIFFVSUMpOyBl eHBsYWluIHRoZSBwcml2YWN5IHJlYXNvbiBiZWhpbmQgdGhlIGRlcHJlY2F0aW9uIGluIHRoZSBk ZXByZWNhdGVkIGRvY3VtZW50Lg0KPg0KPiAoMykgVXBkYXRlIFRGTyB0byBtYWtlIFRGTyBjb29r aWVzIG9wdGlvbmFsLCBhbmQgZXhwbGFpbiB0aGUgdHJhZGVvZmZzLg0KPg0KPiBJIHdvdWxkIGV4 cGVjdCBwdXNoYmFjayBvbiAyIG9yIDMgZnJvbSBwZW9wbGUgcnVubmluZyBURk8gb24gdGhlIElu dGVybmV0LCBiZWNhdXNlIGl0IHJlcXVpcmVzIGNvb3JkaW5hdGVkIGltcGxlbWVudGF0aW9uIGVm Zm9ydCBhbmQgY2hhbmdlcyB0aGUgb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQgKHdoaWNoIGFsd2F5 cyBjYXJyaWVzIHJpc2spLg0KPg0KPiBUaGVyZSBpcyB0aGUgY2F2ZWF0IHRoYXQgSSdtIG5vdCBz dXJlIGhvdyBtYW55IGFyZSBydW5uaW5nIFRGTyBvbiB0aGUgSW50ZXJuZXQuIChJIGRvIGtub3cg R29vZ2xlIHdhcyB0aGUgYmlnZ2VzdCBvbmUsIGF0IGxlYXN0IGEgY291cGxlIG9mIHllYXJzIGFn bywgZnJvbSByZXNlYXJjaCBJIGRpZCBiZWZvcmUgam9pbmluZykuDQo+DQo+IENoZWVycywNCj4N Cj4gQnJpYW4NCj4NCj4+IElmIGEgc2VydmVyIGlzIG92ZXJsb2FkZWQgYW5kIGNhbid0IHByb2Nl c3MgYW55IG1vcmUgVEZPIGRhdGEsIHRoZSByZXN1bHQgY291bGQgYmUgdGhhdCBpdCBqdXN0IGRv ZXNuJ3QgYW5zd2VyIGF0IGFsbCwgYW5kIHRoZSBjbGllbnQgd291bGQgdGhlbiByZXRyYW5zbWl0 IHRoZSBTWU4sIGp1c3QgYXMgaWYgdGhlIFNZTiBoYWQgYmVlbiBkcm9wcGVkLg0KPj4NCj4+DQo+ PiBDaGVlcnMsDQo+PiBNaWNoYWVsDQo+Pg0KPj4NCj4+DQo+Pj4gT24gMjEgTWF5IDIwMTksIGF0 IDA5OjUyLCBFcmlrIFN5IDxzeUBpbmZvcm1hdGlrLnVuaS1oYW1idXJnLmRlPiB3cm90ZToNCj4+ Pg0KPj4+IEhpIE1pY2hhZWwsDQo+Pj4NCj4+PiB0aGFua3MgZm9yIHRoaXMgcXVlc3Rpb24hDQo+ Pj4NCj4+PiBZZXMsIFRGTyBjb29raWVzIGFyZSBib3VuZCB0byB0aGUgY2xpZW50cyAobG9jYWwp IElQIGFkZHJlc3MuIA0KPj4+IEhvd2V2ZXIsIGEgY2xpZW50IHdpdGggYSBzdGF0aWMgbG9jYWwg SVAgYWRkcmVzcyBpbiBhIGhvbWUgbmV0d29yayANCj4+PiB3aWxsIHVzZSB0aGUgc2FtZSBURk8g Y29va2llIGluZGVwZW5kZW50bHkgb2YgaXQncyBwdWJsaWNseSB2aXNpYmxlIA0KPj4+IElQIGFk ZHJlc3MuIEFzIGEgcmVzdWx0LCBURk8gY29va2llcyBwcmVzZW50IGFuIGluZGVwZW5kZW50IHRy YWNraW5nIA0KPj4+IG1lY2hhbmlzbSwgd2hpY2ggZG9lcyBub3QgbmVjZXNzYXJpbHkgcmVseSBv biB0aGUgY2xpZW50J3MgcHVibGljbHkgdmlzaWJsZSBJUCBhZGRyZXNzLg0KPj4+DQo+Pj4gUmV0 dXJuaW5nIHRvIHlvdXIgZXhhbXBsZSwgb25pb24gcm91dGluZyBkb2VzIG5vdCBuZWNlc3Nhcmls eSANCj4+PiBwcm90ZWN0IHlvdSBhZ2FpbnN0IHRyYWNraW5nIHZpYSBURk8gY29va2llcy4NCj4+ Pg0KPj4+IEJlc3QgcmVnYXJkcywNCj4+PiBFcmlrDQo+Pj4NCj4+PiBPbiA1LzIxLzE5IDA5OjEz LCBNaWNoYWVsIFR1ZXhlbiB3cm90ZToNCj4+Pj4+IE9uIDIwLiBNYXkgMjAxOSwgYXQgMjM6MTks IEVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+IHdyb3RlOg0KPj4+Pj4NCj4+ Pj4+IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIHdhcm4gdXNlcnMgYWJvdXQgdGhlIHByaXZh Y3kgcmlza3Mgb2YgDQo+Pj4+PiBSRkMgNzQxMy4gRm9yIGV4YW1wbGUsIE1vemlsbGEgcmVhY3Rl ZCB0byB0aGUgcHJpdmFjeSBwcm9ibGVtcyBvZiANCj4+Pj4+IFRDUCBGYXN0IE9wZW4gYnkgZGVw cmVjYXRpbmcgdGhpcyBwcm90b2NvbCBvbiBhbGwgaXQncyBGaXJlZm94IA0KPj4+Pj4gYnJhbmNo ZXMuIEluIHRvdGFsLCBUQ1AgRmFzdCBPcGVuIGhhcyBzaWduaWZpY2FudCBpc3N1ZXMgd2l0aCAN Cj4+Pj4+IHJlc3BlY3QgdG8gdXNlciBwcml2YWN5LCBwZXJmb3JtYW5jZSBhbmQgZGVwbG95bWVu dCBvbiB0aGUgDQo+Pj4+PiByZWFsLXdvcmxkIEludGVybmV0LiBGcm9tIG15IHBvaW50IG9mIHZp ZXcsIGl0IGlzIGFib3V0IHRpbWUgdG8gZGVwcmVjYXRlIFJGQyA3NDEzLg0KPj4+PiBIaSBFcmlj LA0KPj4+Pg0KPj4+PiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYSBjb29raWUgaXMgc3BlY2lm aWMgdG8gYSBjbGllbnQgYWRkcmVzcywgDQo+Pj4+IGEgc2VydmVyIGFkZHJlc3MgYW5kIGEgc2Vy dmVyIHBvcnQuIFNvIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgZm9yIGEgDQo+Pj4+IGNsaWVudCB0byBy ZW1vdmUgZW50cmllcyBmcm9tIHRoZSBjb29raWUgY2FjaGUgb24gYW4gYWRkcmVzcyBjaGFuZ2Uu DQo+Pj4+IEFzc3VtaW5nIHRoYXQsIGhvdyBkb2VzIHlvdXIgZGVzY3JpYmVkIGhvc3QgYmFzZWQg YXR0YWNrcyByZWxhdGUgdG8gDQo+Pj4+IHRoZSBzZXJ2ZXIganVzdCB1c2luZyB0aGUgY2xpZW50 IElQIGFkZHJlc3MgZm9yIHRyYWNraW5nPyBJZiB5b3UgDQo+Pj4+IGFyZSB0cnlpbmcgdG8gaGlk ZSB5b3UgSVAtYWRkcmVzcyAobGlrZSB1c2luZyBhIFRPUiBicm93c2VyKSB5b3UgDQo+Pj4+IGRv bid0IHdhbnQgdG8gdXNlIFRGTywgYnV0IHlvdSBhcmUgbm90IG9wdGltaXNpbmcgZm9yIHNtYWxs IFJUVHMgaW4gdGhhdCBjYXNlLCBzbyBpdCBtYWtlcyBubyBzZW5zZSBpbiB0aGF0IGNhc2UuDQo+ Pj4+DQo+Pj4+IEJlc3QgcmVnYXJkcw0KPj4+PiBNaWNoYWVsDQo+Pj4+PiBSZWdhcmRzLA0KPj4+ Pj4gRXJpaw0KPj4+Pj4NCj4+Pj4+IE9uIDUvMTAvMTkgMTQ6MTQsIEVyaWsgU3kgd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4+IEhpIGV2ZXJ5b25lLA0KPj4+Pj4+DQo+Pj4+Pj4gVENQIEZhc3QgT3BlbiBo YXMgc2lnbmlmaWNhbnQgcHJpdmFjeSBwcm9ibGVtcyB3aGljaCBhcmUgbm90IA0KPj4+Pj4+IGNv bnNpZGVyZWQgaW4gUkZDIDc0MTMuDQo+Pj4+Pj4gRm9yIGV4YW1wbGUsIHRoaXMgcHJvdG9jb2wg YWxsb3dzIGEgcGFzc2l2ZSBuZXR3b3JrIG9ic2VydmVyIHRvIA0KPj4+Pj4+IGNvcnJlbGF0ZSBj b25uZWN0aW9ucyBlc3RhYmxpc2hlZCBieSB0aGUgc2FtZSBjbGllbnQsIHdoaWNoIA0KPj4+Pj4+ IHByb3RvY29scyBzdWNoIGFzIFRMUyAxLjMgYW5kIFFVSUMgYWN0aXZlbHkgcHJvdGVjdCBhZ2Fp bnN0Lg0KPj4+Pj4+IEZ1cnRoZXJtb3JlLCBGYXN0IE9wZW4gY29va2llcyBwcmVzZW50IGEga2Vy bmVsLWJhc2VkIHRyYWNraW5nIA0KPj4+Pj4+IG1lY2hhbmlzbSB3aGljaCBpcyBxdWl0ZSBwZXJz aXN0ZW50LiBBbW9uZ3N0IG90aGVycywgdGhleSBjYW4gYmUgDQo+Pj4+Pj4gdXNlZCB0byBjb25k dWN0IGNyb3NzLWJyb3dzZXIgdHJhY2tpbmcgb24gdGhlIHNhbWUgb3BlcmF0aW5nIHN5c3RlbS4N Cj4+Pj4+PiBGb3IgZnVydGhlciBkZXRhaWxzIHBsZWFzZSByZWZlciB0byB0aGlzIGFydGljbGU6 DQo+Pj4+Pj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTINCj4+Pj4+PiBGIA0KPj4+Pj4+IGFyeGl2Lm9yZyUyRnBkZiUyRjE5 MDUuMDM1MTgucGRmJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3JvDQo+Pj4+Pj4gcw0K Pj4+Pj4+IG9mdC5jb20lN0NjOGYwZTYyNDg2ODU0MWRhODdjODA4ZDZkZGZiNWQ3MSU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiDQo+Pj4+Pj4gMiANCj4+Pj4+PiBkN2NkMDExZGI0NyU3QzElN0MxJTdD NjM2OTQwNDY5MDE4MTQwMTE0JmFtcDtzZGF0YT1ka2dXTFNGWllLRU5sNw0KPj4+Pj4+IGwNCj4+ Pj4+PiBzY2VzSkV4VzZTYlpDR2ZPVVhFTjhvUEhXaDJrJTNEJmFtcDtyZXNlcnZlZD0wDQo+Pj4+ Pj4NCj4+Pj4+PiBJIHN1Z2dlc3QsIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgdGFrZXMgc3RlcHMg dG8gaGlnaGxpZ2h0IHRoZXNlIA0KPj4+Pj4+IHByaXZhY3kgcHJvYmxlbXMgb2YgUkZDIDc0MTMu DQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+IEVyaWsNCj4+Pj4+Pg0KPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gdGNw bSBtYWlsaW5nIGxpc3QNCj4+Pj4+PiB0Y3BtQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTINCj4+ Pj4+PiBGIA0KPj4+Pj4+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD13d3cuaWV0Zi5vcmcmDQo+Pj4+Pj4gYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZi JTQwbWljcm9zb2Z0LmNvbSU3Q2JhZDQxODA0OTA3MDQwY2M0OGM4MDgNCj4+Pj4+PiBkNmRlODlj NzAxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0MTA4 MA0KPj4+Pj4+IDY4NTY1NzM1OSZhbXA7c2RhdGE9RWNCcFAlMkZPY1haZGp0WWNhV3VQYlYlMkZV V1FyZ0hZVlQ4T2F5TERmUElODQo+Pj4+Pj4gaGMlM0QmYW1wO3Jlc2VydmVkPTAlMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdDMDENCj4+Pj4+PiAlN0NwcmF2YiUNCj4+ Pj4+PiA0MG1pY3Jvc29mdC5jb20lN0NjOGYwZTYyNDg2ODU0MWRhODdjODA4ZDZkZGZiNWQ3MSU3 QzcyZjk4OGJmODZmMQ0KPj4+Pj4+IDQgDQo+Pj4+Pj4gMWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MxJTdDNjM2OTQwNDY5MDE4MTQwMTE0JmFtcDtzZGF0YT0wNUtaNFcNCj4+Pj4+PiAlDQo+Pj4+ Pj4gMkJyRVBHT216QzB6VWY0S0dZUVdpY1IlMkJTNyUyRjNWS1lYdmxpemo0JTNEJmFtcDtyZXNl cnZlZD0wDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4+Pj4+IHRjcG1AaWV0Zi5vcmcNCj4+Pj4+ IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRg0KPj4+Pj4gdw0KPj4+Pj4gd3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0DQo+Pj4+PiAwIA0KPj4+Pj4gbWlj cm9zb2Z0LmNvbSU3Q2M4ZjBlNjI0ODY4NTQxZGE4N2M4MDhkNmRkZmI1ZDcxJTdDNzJmOTg4YmY4 NmYxNDFhDQo+Pj4+PiBmIA0KPj4+Pj4gOTFhYjJkN2NkMDExZGI0NyU3QzElN0MxJTdDNjM2OTQw NDY5MDE4MTQwMTE0JmFtcDtzZGF0YT0wNUtaNFclMkJyDQo+Pj4+PiBFDQo+Pj4+PiBQR09tekMw elVmNEtHWVFXaWNSJTJCUzclMkYzVktZWHZsaXpqNCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gdGNwbSBt YWlsaW5nIGxpc3QNCj4+PiB0Y3BtQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3cNCj4+PiB3IA0K Pj4+IC5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljDQo+Pj4gciANCj4+PiBvc29mdC5jb20lN0NjOGYwZTYyNDg2ODU0MWRh ODdjODA4ZDZkZGZiNWQ3MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMg0KPj4+IGQgDQo+Pj4gN2Nk MDExZGI0NyU3QzElN0MxJTdDNjM2OTQwNDY5MDE4MTQwMTE0JmFtcDtzZGF0YT0wNUtaNFclMkJy RVBHT216QzANCj4+PiB6DQo+Pj4gVWY0S0dZUVdpY1IlMkJTNyUyRjNWS1lYdmxpemo0JTNEJmFt cDtyZXNlcnZlZD0wDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4+IHRjcG1AaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy4NCj4+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNybw0KPj4gcyANCj4+IG9mdC5jb20lN0NjOGYwZTYyNDg2 ODU0MWRhODdjODA4ZDZkZGZiNWQ3MSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Yw0KPj4gZCAN Cj4+IDAxMWRiNDclN0MxJTdDMSU3QzYzNjk0MDQ2OTAxODE0MDExNCZhbXA7c2RhdGE9MDVLWjRX JTJCckVQR09tekMwelVmNA0KPj4gSw0KPj4gR1lRV2ljUiUyQlM3JTJGM1ZLWVh2bGl6ajQlM0Qm YW1wO3Jlc2VydmVkPTANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuDQo+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0w MiU3QzAxJTdDcHJhdmIlNDBtaWNyb3MNCj4gb2Z0LmNvbSU3Q2JhZDQxODA0OTA3MDQwY2M0OGM4 MDhkNmRlODljNzAxJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZA0KPiAwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY5NDEwODA2ODU2NTczNTkmYW1wO3NkYXRhPTdBY1BVek5Qc1A3QlRwSDk3NGtGSFds DQo+IFpXU0IlMkJCS3lZcVRPRVFETUQySUklM0QmYW1wO3Jlc2VydmVkPTANCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5n IGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+IGlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3MN Cj4gb2Z0LmNvbSU3Q2JhZDQxODA0OTA3MDQwY2M0OGM4MDhkNmRlODljNzAxJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZA0KPiAwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NDEwODA2ODU2NTczNTkm YW1wO3NkYXRhPTdBY1BVek5Qc1A3QlRwSDk3NGtGSFdsDQo+IFpXU0IlMkJCS3lZcVRPRVFETUQy SUklM0QmYW1wO3Jlc2VydmVkPTANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnDQpodHRwczov L25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NiYWQ0MTgwNDkwNzA0MGNjNDhjODA4ZDZkZTg5 YzcwMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NDEw ODA2ODU2NTczNTkmYW1wO3NkYXRhPTdBY1BVek5Qc1A3QlRwSDk3NGtGSFdsWldTQiUyQkJLeVlx VE9FUURNRDJJSSUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From nobody Wed May 22 10:21:48 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA61201FA for ; Wed, 22 May 2019 10:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=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 AkdVUhwvo-uX for ; Wed, 22 May 2019 10:21:44 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90461201E7 for ; Wed, 22 May 2019 10:21:43 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:952a:38cc:78e:716c] (p200300CD6F384A00952A38CC078E716C.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:952a:38cc:78e:716c]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id C1083721E280D; Wed, 22 May 2019 19:21:39 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> Date: Wed, 22 May 2019 19:21:39 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 17:21:47 -0000 > On 21. May 2019, at 22:51, Erik Sy = wrote: >=20 >=20 > On 5/21/19 21:56, Michael Tuexen wrote: >>> On 21. May 2019, at 21:22, Erik Sy = wrote: >>>=20 >>>=20 >>> On 5/21/19 18:34, Michael Tuexen wrote: >>>>> On 21. May 2019, at 14:25, Erik Sy = wrote: >>>>>=20 >>>>>=20 >>>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>>> On 21. May 2019, at 09:52, Erik Sy = wrote: >>>>>>>=20 >>>>>>> Hi Michael, >>>>>>>=20 >>>>>>> thanks for this question! >>>>>>>=20 >>>>>>> Yes, TFO cookies are bound to the clients (local) IP address. = However, a >>>>>>> client with a static local IP address in a home network will use = the >>>>>>> same TFO cookie independently of it's publicly visible IP = address. As a >>>>>>> result, TFO cookies present an independent tracking mechanism, = which >>>>>>> does not necessarily rely on the client's publicly visible IP = address. >>>>>> How often do the public addresses change? >>>>> I do not have a general answer to your question. In the case of my = home >>>>> network, my ISP assigns me at least every 24 hours a new IPv4 = address. >>>> I also had this on my DSL line (I guess we both live in Germany), >>>> but since my telephone line was moved to "all IP", the assignment = stays >>>> up for months. >>>>> Additionally, I can initiate a change of my network's public IP = address >>>>> at anytime. >>>> Sure. >>>>> TFO cookies allow basically unlimited tracking periods because = they do >>>>> not have an expiration mechanism. Thus, even infrequently changed = IP >>>>> addresses can be correlated. >>>> An implementation can do implement such a thing and even allow an = API for it. >>> Yes, I agree with you that implementations can go beyond RFC 7413 = and >>> implement an expiration mechanism limiting feasible tracking = periods. >>>=20 >>>> For testing I'm flushing the cookie cache quite often... >>>>>> One could extend the TFO API in >>>>>> a way that the application can request a new cookie by only = sending=20 >>>>>> a cookie request. >>>>> I do not think this is an appropriate countermeasure. >>>>>=20 >>>>> =46rom my perspective, caching TFO cookies in the kernel is a more >>>>> fundamental privacy problem. This design requires applications to = share >>>>> a pool of TFO cookies, which allows tracking across several >>>>> applications. For example, this prevents user's to separate their = online >>>>> activities across different browsers. >>>> They would share the IP address. If they decide to trigger a new = address >>>> binding on the access router, why couldn't they trigger flushing = the >>>> cache? >>> Flushing the cache presents a performance versus privacy trade off >>> because flushing increases the chance of a cache miss preventing a = 0-RTT >>> handshake. >> Sure it does. It was just meant as an equivalent to resetting the >> public IP address of your access router. This also affects all = outgoing >> connections. >>> Thus, an application that often flushes the cache degrades the >>> performance of all other applications sharing the same pool of TFO = cookies. >>> As a result, the application with the highest privacy requirements >>> limits the TFO performance of all other applications. >>>=20 >>> Furthermore flushing has difficulties to separate applications = running >>> at the same time. For example, running a browser window in the = normal >>> browsing mode and another window in the private browsing mode >>> (incognito). In this scenario, only excessive flushing can prevent = an >>> online tracker to link the user's online activities across both = browser >>> windows. >> Can't they both be linked by the IP address being used? > Tracking via IP addresses has the limitation that it cannot > differentiate clients behind a NAT. However, TFO cookies can be used = to > overcome this limitation if each TFO connection from the same IP = address > gets assigned a unique token. Thus, reusing such a unique token during = a How does that work. Wouldn't the server compute the cookie based on the IP address it sees from the client, which is the public address of the = NAT, and is the same for all clients? So I would assume that all clients = behind a NAT store and use the same TFO cookie. > connection request allows a more accurate tracking than can be done = via > the publicly visible IP addresses. >>> =46rom my perspective, an approach that delegates the caching to the >>> application itself, is the better solution to address this privacy >>> versus performance trade off. Moreover, I believe users tend to make = the >> How does this prevent "tracking by IP-address" compared to "tracking >> by TFO cookie"? > As described, tracking by IP addresses has limitations especially if > several users share the same IP address or change their publicly = visible > IP address frequently. As discussed, tracking via TFO cookies can be > more persistent and more precise than tracking by IP addresses. I don't see the more precise... See above. The more persistent I do see and might be mitigated by timing out the TFO cookies. > Applications controlling their retrieved TFO cookies can provide upper > boundaries for feasible tracking periods via this mechanism without > affecting the TFO performance of other applications. Furthermore, > caching TFO cookies separately within each application prevents = tracking > user activities across these different applications on the same = device. But wouldn't the different applications on the same host use the same IP address? Can't they the tracked by that in (almost the same way)? Best regards Michael >=20 > Best regards, > Erik >=20 >>=20 >> Best regards >> Michael >>> application/browser vendor responsible to protect their privacy. = Thus, >>> these vendors require appropriate measures to control their users' = privacy. >>>=20 >>> Best regards, >>> Erik >>>=20 >>>> Best regards >>>> Michael >>>>>>> Returning to your example, onion routing does not necessarily = protect >>>>>>> you against tracking via TFO cookies. >>>>>> Yepp, that is what I wanted to say.=20 >>>>>> But using TFO in that case doesn't >>>>>> make much sense. >>>>> Yes, TFO does not make sense if user privacy is at stake. Thus, we >>>>> should warn users about these risks of RFC 7413. >>>>>=20 >>>>> Best regards, >>>>> Erik >>>>>=20 >>>>>=20 From nobody Wed May 22 12:41:55 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF612016D for ; Wed, 22 May 2019 12:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 XcKbtUqrRimq for ; Wed, 22 May 2019 12:41:50 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 958EF120181 for ; Wed, 22 May 2019 12:41:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 1E78FC96; Wed, 22 May 2019 21:41:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ouilRxhJxpDI; Wed, 22 May 2019 21:41:47 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB4AB.versanet.de [87.123.180.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id 1FF9EC95; Wed, 22 May 2019 21:41:44 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm IETF list References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> Date: Wed, 22 May 2019 21:41:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 19:41:54 -0000 On 5/22/19 19:21, Michael Tuexen wrote: >> On 21. May 2019, at 22:51, Erik Sy wrote: >> >> >> On 5/21/19 21:56, Michael Tuexen wrote: >>>> On 21. May 2019, at 21:22, Erik Sy wrote: >>>> >>>> >>>> On 5/21/19 18:34, Michael Tuexen wrote: >>>>>> On 21. May 2019, at 14:25, Erik Sy wrote: >>>>>> >>>>>> >>>>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>>>> On 21. May 2019, at 09:52, Erik Sy wrote: >>>>>>>> >>>>>>>> Hi Michael, >>>>>>>> >>>>>>>> thanks for this question! >>>>>>>> >>>>>>>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>>>>>>> client with a static local IP address in a home network will use the >>>>>>>> same TFO cookie independently of it's publicly visible IP address. As a >>>>>>>> result, TFO cookies present an independent tracking mechanism, which >>>>>>>> does not necessarily rely on the client's publicly visible IP address. >>>>>>> How often do the public addresses change? >>>>>> I do not have a general answer to your question. In the case of my home >>>>>> network, my ISP assigns me at least every 24 hours a new IPv4 address. >>>>> I also had this on my DSL line (I guess we both live in Germany), >>>>> but since my telephone line was moved to "all IP", the assignment stays >>>>> up for months. >>>>>> Additionally, I can initiate a change of my network's public IP address >>>>>> at anytime. >>>>> Sure. >>>>>> TFO cookies allow basically unlimited tracking periods because they do >>>>>> not have an expiration mechanism. Thus, even infrequently changed IP >>>>>> addresses can be correlated. >>>>> An implementation can do implement such a thing and even allow an API for it. >>>> Yes, I agree with you that implementations can go beyond RFC 7413 and >>>> implement an expiration mechanism limiting feasible tracking periods. >>>> >>>>> For testing I'm flushing the cookie cache quite often... >>>>>>> One could extend the TFO API in >>>>>>> a way that the application can request a new cookie by only sending >>>>>>> a cookie request. >>>>>> I do not think this is an appropriate countermeasure. >>>>>> >>>>>> From my perspective, caching TFO cookies in the kernel is a more >>>>>> fundamental privacy problem. This design requires applications to share >>>>>> a pool of TFO cookies, which allows tracking across several >>>>>> applications. For example, this prevents user's to separate their online >>>>>> activities across different browsers. >>>>> They would share the IP address. If they decide to trigger a new address >>>>> binding on the access router, why couldn't they trigger flushing the >>>>> cache? >>>> Flushing the cache presents a performance versus privacy trade off >>>> because flushing increases the chance of a cache miss preventing a 0-RTT >>>> handshake. >>> Sure it does. It was just meant as an equivalent to resetting the >>> public IP address of your access router. This also affects all outgoing >>> connections. >>>> Thus, an application that often flushes the cache degrades the >>>> performance of all other applications sharing the same pool of TFO cookies. >>>> As a result, the application with the highest privacy requirements >>>> limits the TFO performance of all other applications. >>>> >>>> Furthermore flushing has difficulties to separate applications running >>>> at the same time. For example, running a browser window in the normal >>>> browsing mode and another window in the private browsing mode >>>> (incognito). In this scenario, only excessive flushing can prevent an >>>> online tracker to link the user's online activities across both browser >>>> windows. >>> Can't they both be linked by the IP address being used? >> Tracking via IP addresses has the limitation that it cannot >> differentiate clients behind a NAT. However, TFO cookies can be used to >> overcome this limitation if each TFO connection from the same IP address >> gets assigned a unique token. Thus, reusing such a unique token during a > How does that work. Wouldn't the server compute the cookie based on the > IP address it sees from the client, which is the public address of the NAT, > and is the same for all clients? So I would assume that all clients behind > a NAT store and use the same TFO cookie. TFO cookies are created and consumed by the server and are opaque to the client. Yes, there exist implementations that only use the client's IP address to generate the TFO cookie. However, it is up to the server to add additional information into the cookies as described in: https://tools.ietf.org/html/rfc7413#section-4.1.2 Number 4. A server that wants to differentiate clients behind a NAT would make the cookies unique per connection. >> connection request allows a more accurate tracking than can be done via >> the publicly visible IP addresses. >>>> From my perspective, an approach that delegates the caching to the >>>> application itself, is the better solution to address this privacy >>>> versus performance trade off. Moreover, I believe users tend to make the >>> How does this prevent "tracking by IP-address" compared to "tracking >>> by TFO cookie"? >> As described, tracking by IP addresses has limitations especially if >> several users share the same IP address or change their publicly visible >> IP address frequently. As discussed, tracking via TFO cookies can be >> more persistent and more precise than tracking by IP addresses. > I don't see the more precise... See above. The more persistent I do see > and might be mitigated by timing out the TFO cookies. >> Applications controlling their retrieved TFO cookies can provide upper >> boundaries for feasible tracking periods via this mechanism without >> affecting the TFO performance of other applications. Furthermore, >> caching TFO cookies separately within each application prevents tracking >> user activities across these different applications on the same device. > But wouldn't the different applications on the same host use the same > IP address? Can't they the tracked by that in (almost the same way)? Most applications on the same host will certainly use the same IP address. However, this does not have to be the case. For example, every popular browser allows you to configure an application specific proxy that can change the publicly visible IP address of it's traffic (similar to the TorBrowser). Best regards Erik > > Best regards > Michael >> Best regards, >> Erik >> >>> Best regards >>> Michael >>>> application/browser vendor responsible to protect their privacy. Thus, >>>> these vendors require appropriate measures to control their users' privacy. >>>> >>>> Best regards, >>>> Erik >>>> >>>>> Best regards >>>>> Michael >>>>>>>> Returning to your example, onion routing does not necessarily protect >>>>>>>> you against tracking via TFO cookies. >>>>>>> Yepp, that is what I wanted to say. >>>>>>> But using TFO in that case doesn't >>>>>>> make much sense. >>>>>> Yes, TFO does not make sense if user privacy is at stake. Thus, we >>>>>> should warn users about these risks of RFC 7413. >>>>>> >>>>>> Best regards, >>>>>> Erik >>>>>> >>>>>> From nobody Wed May 22 13:26:09 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8EA120150 for ; Wed, 22 May 2019 13:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 B8_RA8zPiurU for ; Wed, 22 May 2019 13:26:04 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69D4120136 for ; Wed, 22 May 2019 13:26:03 -0700 (PDT) Received: from [IPv6:2003:cd:6f38:4a00:98c9:1b18:e31c:a9cb] (p200300CD6F384A0098C91B18E31CA9CB.dip0.t-ipconnect.de [IPv6:2003:cd:6f38:4a00:98c9:1b18:e31c:a9cb]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 0B4DD721E280D; Wed, 22 May 2019 22:26:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> Date: Wed, 22 May 2019 22:25:59 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <7A3BBF13-C650-4AE2-B69A-18A1F5151DC7@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 20:26:08 -0000 > On 22. May 2019, at 21:41, Erik Sy = wrote: >=20 >=20 > On 5/22/19 19:21, Michael Tuexen wrote: >>> On 21. May 2019, at 22:51, Erik Sy = wrote: >>>=20 >>>=20 >>> On 5/21/19 21:56, Michael Tuexen wrote: >>>>> On 21. May 2019, at 21:22, Erik Sy = wrote: >>>>>=20 >>>>>=20 >>>>> On 5/21/19 18:34, Michael Tuexen wrote: >>>>>>> On 21. May 2019, at 14:25, Erik Sy = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>>>>> On 21. May 2019, at 09:52, Erik Sy = wrote: >>>>>>>>>=20 >>>>>>>>> Hi Michael, >>>>>>>>>=20 >>>>>>>>> thanks for this question! >>>>>>>>>=20 >>>>>>>>> Yes, TFO cookies are bound to the clients (local) IP address. = However, a >>>>>>>>> client with a static local IP address in a home network will = use the >>>>>>>>> same TFO cookie independently of it's publicly visible IP = address. As a >>>>>>>>> result, TFO cookies present an independent tracking mechanism, = which >>>>>>>>> does not necessarily rely on the client's publicly visible IP = address. >>>>>>>> How often do the public addresses change? >>>>>>> I do not have a general answer to your question. In the case of = my home >>>>>>> network, my ISP assigns me at least every 24 hours a new IPv4 = address. >>>>>> I also had this on my DSL line (I guess we both live in Germany), >>>>>> but since my telephone line was moved to "all IP", the assignment = stays >>>>>> up for months. >>>>>>> Additionally, I can initiate a change of my network's public IP = address >>>>>>> at anytime. >>>>>> Sure. >>>>>>> TFO cookies allow basically unlimited tracking periods because = they do >>>>>>> not have an expiration mechanism. Thus, even infrequently = changed IP >>>>>>> addresses can be correlated. >>>>>> An implementation can do implement such a thing and even allow an = API for it. >>>>> Yes, I agree with you that implementations can go beyond RFC 7413 = and >>>>> implement an expiration mechanism limiting feasible tracking = periods. >>>>>=20 >>>>>> For testing I'm flushing the cookie cache quite often... >>>>>>>> One could extend the TFO API in >>>>>>>> a way that the application can request a new cookie by only = sending=20 >>>>>>>> a cookie request. >>>>>>> I do not think this is an appropriate countermeasure. >>>>>>>=20 >>>>>>> =46rom my perspective, caching TFO cookies in the kernel is a = more >>>>>>> fundamental privacy problem. This design requires applications = to share >>>>>>> a pool of TFO cookies, which allows tracking across several >>>>>>> applications. For example, this prevents user's to separate = their online >>>>>>> activities across different browsers. >>>>>> They would share the IP address. If they decide to trigger a new = address >>>>>> binding on the access router, why couldn't they trigger flushing = the >>>>>> cache? >>>>> Flushing the cache presents a performance versus privacy trade off >>>>> because flushing increases the chance of a cache miss preventing a = 0-RTT >>>>> handshake. >>>> Sure it does. It was just meant as an equivalent to resetting the >>>> public IP address of your access router. This also affects all = outgoing >>>> connections. >>>>> Thus, an application that often flushes the cache degrades the >>>>> performance of all other applications sharing the same pool of TFO = cookies. >>>>> As a result, the application with the highest privacy requirements >>>>> limits the TFO performance of all other applications. >>>>>=20 >>>>> Furthermore flushing has difficulties to separate applications = running >>>>> at the same time. For example, running a browser window in the = normal >>>>> browsing mode and another window in the private browsing mode >>>>> (incognito). In this scenario, only excessive flushing can prevent = an >>>>> online tracker to link the user's online activities across both = browser >>>>> windows. >>>> Can't they both be linked by the IP address being used? >>> Tracking via IP addresses has the limitation that it cannot >>> differentiate clients behind a NAT. However, TFO cookies can be used = to >>> overcome this limitation if each TFO connection from the same IP = address >>> gets assigned a unique token. Thus, reusing such a unique token = during a >> How does that work. Wouldn't the server compute the cookie based on = the >> IP address it sees from the client, which is the public address of = the NAT, >> and is the same for all clients? So I would assume that all clients = behind >> a NAT store and use the same TFO cookie. >=20 > TFO cookies are created and consumed by the server and are opaque to = the > client. Yes, there exist implementations that only use the client's IP > address to generate the TFO cookie. However, it is up to the server to > add additional information into the cookies as described in: > https://tools.ietf.org/html/rfc7413#section-4.1.2 Number 4. A server > that wants to differentiate clients behind a NAT would make the = cookies > unique per connection. Are you aware of such an implementation? Doesn't that mean that a server has the capability to differentiate clients behind a NAT to provide = different TFO cookies? If he has the capability, why does he need TFO cookies? >=20 >>> connection request allows a more accurate tracking than can be done = via >>> the publicly visible IP addresses. >>>>> =46rom my perspective, an approach that delegates the caching to = the >>>>> application itself, is the better solution to address this privacy >>>>> versus performance trade off. Moreover, I believe users tend to = make the >>>> How does this prevent "tracking by IP-address" compared to = "tracking >>>> by TFO cookie"? >>> As described, tracking by IP addresses has limitations especially if >>> several users share the same IP address or change their publicly = visible >>> IP address frequently. As discussed, tracking via TFO cookies can be >>> more persistent and more precise than tracking by IP addresses. >> I don't see the more precise... See above. The more persistent I do = see >> and might be mitigated by timing out the TFO cookies. >>> Applications controlling their retrieved TFO cookies can provide = upper >>> boundaries for feasible tracking periods via this mechanism without >>> affecting the TFO performance of other applications. Furthermore, >>> caching TFO cookies separately within each application prevents = tracking >>> user activities across these different applications on the same = device. >> But wouldn't the different applications on the same host use the same >> IP address? Can't they the tracked by that in (almost the same way)? >=20 > Most applications on the same host will certainly use the same IP > address. However, this does not have to be the case. For example, = every > popular browser allows you to configure an application specific proxy > that can change the publicly visible IP address of it's traffic = (similar > to the TorBrowser). OK. So the server sees multiple proxies talking to him. Since the = proxies terminate the TCP connections, the server would not see the TFO cookies, which were provided by the proxies to the clients. Best regards Michael >=20 > Best regards > Erik >=20 >>=20 >> Best regards >> Michael >>> Best regards, >>> Erik >>>=20 >>>> Best regards >>>> Michael >>>>> application/browser vendor responsible to protect their privacy. = Thus, >>>>> these vendors require appropriate measures to control their users' = privacy. >>>>>=20 >>>>> Best regards, >>>>> Erik >>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>>>> Returning to your example, onion routing does not necessarily = protect >>>>>>>>> you against tracking via TFO cookies. >>>>>>>> Yepp, that is what I wanted to say.=20 >>>>>>>> But using TFO in that case doesn't >>>>>>>> make much sense. >>>>>>> Yes, TFO does not make sense if user privacy is at stake. Thus, = we >>>>>>> should warn users about these risks of RFC 7413. >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Erik >>>>>>>=20 >>>>>>>=20 From nobody Wed May 22 14:42:21 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9849E1200A1 for ; Wed, 22 May 2019 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 0hwRZpi0UiKb for ; Wed, 22 May 2019 14:42:17 -0700 (PDT) Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (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 873E212004A for ; Wed, 22 May 2019 14:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 89C3C84D; Wed, 22 May 2019 23:42:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LdjAHH5sfUvL; Wed, 22 May 2019 23:42:14 +0200 (CEST) Received: from users-MBP.fritz.box (i577BB4AB.versanet.de [87.123.180.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id C815484C; Wed, 22 May 2019 23:42:13 +0200 (CEST) Reply-To: sy@informatik.uni-hamburg.de To: Michael Tuexen Cc: tcpm IETF list References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> <7A3BBF13-C650-4AE2-B69A-18A1F5151DC7@lurchi.franken.de> From: Erik Sy Openpgp: preference=signencrypt Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw== Message-ID: <0a474aad-623f-8974-c52e-e832dc1f780d@informatik.uni-hamburg.de> Date: Wed, 22 May 2019 23:42:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <7A3BBF13-C650-4AE2-B69A-18A1F5151DC7@lurchi.franken.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 21:42:20 -0000 On 5/22/19 22:25, Michael Tuexen wrote: >> On 22. May 2019, at 21:41, Erik Sy wrote: >> >> >> On 5/22/19 19:21, Michael Tuexen wrote: >>>> On 21. May 2019, at 22:51, Erik Sy wrote: >>>> >>>> >>>> On 5/21/19 21:56, Michael Tuexen wrote: >>>>>> On 21. May 2019, at 21:22, Erik Sy wrote: >>>>>> >>>>>> >>>>>> On 5/21/19 18:34, Michael Tuexen wrote: >>>>>>>> On 21. May 2019, at 14:25, Erik Sy wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>>>>>> On 21. May 2019, at 09:52, Erik Sy wrote: >>>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> thanks for this question! >>>>>>>>>> >>>>>>>>>> Yes, TFO cookies are bound to the clients (local) IP address. However, a >>>>>>>>>> client with a static local IP address in a home network will use the >>>>>>>>>> same TFO cookie independently of it's publicly visible IP address. As a >>>>>>>>>> result, TFO cookies present an independent tracking mechanism, which >>>>>>>>>> does not necessarily rely on the client's publicly visible IP address. >>>>>>>>> How often do the public addresses change? >>>>>>>> I do not have a general answer to your question. In the case of my home >>>>>>>> network, my ISP assigns me at least every 24 hours a new IPv4 address. >>>>>>> I also had this on my DSL line (I guess we both live in Germany), >>>>>>> but since my telephone line was moved to "all IP", the assignment stays >>>>>>> up for months. >>>>>>>> Additionally, I can initiate a change of my network's public IP address >>>>>>>> at anytime. >>>>>>> Sure. >>>>>>>> TFO cookies allow basically unlimited tracking periods because they do >>>>>>>> not have an expiration mechanism. Thus, even infrequently changed IP >>>>>>>> addresses can be correlated. >>>>>>> An implementation can do implement such a thing and even allow an API for it. >>>>>> Yes, I agree with you that implementations can go beyond RFC 7413 and >>>>>> implement an expiration mechanism limiting feasible tracking periods. >>>>>> >>>>>>> For testing I'm flushing the cookie cache quite often... >>>>>>>>> One could extend the TFO API in >>>>>>>>> a way that the application can request a new cookie by only sending >>>>>>>>> a cookie request. >>>>>>>> I do not think this is an appropriate countermeasure. >>>>>>>> >>>>>>>> From my perspective, caching TFO cookies in the kernel is a more >>>>>>>> fundamental privacy problem. This design requires applications to share >>>>>>>> a pool of TFO cookies, which allows tracking across several >>>>>>>> applications. For example, this prevents user's to separate their online >>>>>>>> activities across different browsers. >>>>>>> They would share the IP address. If they decide to trigger a new address >>>>>>> binding on the access router, why couldn't they trigger flushing the >>>>>>> cache? >>>>>> Flushing the cache presents a performance versus privacy trade off >>>>>> because flushing increases the chance of a cache miss preventing a 0-RTT >>>>>> handshake. >>>>> Sure it does. It was just meant as an equivalent to resetting the >>>>> public IP address of your access router. This also affects all outgoing >>>>> connections. >>>>>> Thus, an application that often flushes the cache degrades the >>>>>> performance of all other applications sharing the same pool of TFO cookies. >>>>>> As a result, the application with the highest privacy requirements >>>>>> limits the TFO performance of all other applications. >>>>>> >>>>>> Furthermore flushing has difficulties to separate applications running >>>>>> at the same time. For example, running a browser window in the normal >>>>>> browsing mode and another window in the private browsing mode >>>>>> (incognito). In this scenario, only excessive flushing can prevent an >>>>>> online tracker to link the user's online activities across both browser >>>>>> windows. >>>>> Can't they both be linked by the IP address being used? >>>> Tracking via IP addresses has the limitation that it cannot >>>> differentiate clients behind a NAT. However, TFO cookies can be used to >>>> overcome this limitation if each TFO connection from the same IP address >>>> gets assigned a unique token. Thus, reusing such a unique token during a >>> How does that work. Wouldn't the server compute the cookie based on the >>> IP address it sees from the client, which is the public address of the NAT, >>> and is the same for all clients? So I would assume that all clients behind >>> a NAT store and use the same TFO cookie. >> TFO cookies are created and consumed by the server and are opaque to the >> client. Yes, there exist implementations that only use the client's IP >> address to generate the TFO cookie. However, it is up to the server to >> add additional information into the cookies as described in: >> https://tools.ietf.org/html/rfc7413#section-4.1.2 Number 4. A server >> that wants to differentiate clients behind a NAT would make the cookies >> unique per connection. > Are you aware of such an implementation? I did not investigate the default mechanisms different operating systems use to generate TFO cookies. However, patching a kernel to generate unique TFO cookies for connections from the same IP address is certainly feasible for online trackers. For example, one can use an truncated hash of the client's IP address appended by a counter to construct such a unique cookies. > Doesn't that mean that a server > has the capability to differentiate clients behind a NAT to provide different > TFO cookies? If he has the capability, why does he need TFO cookies? No. Let's assume we have two clients behind a NAT with the same public IP address. The first client receives a unique TFO cookie during its first connection. When this client reconnects to the server, it will present the cookie received during it's first connection. This allows the server to conclude that both connection originate from the same host because this cookie was only issued a single time. The second client will receive a different TFO cookie during it's first connection. Thus, both clients can be clearly differentiated by the server. >>>> connection request allows a more accurate tracking than can be done via >>>> the publicly visible IP addresses. >>>>>> From my perspective, an approach that delegates the caching to the >>>>>> application itself, is the better solution to address this privacy >>>>>> versus performance trade off. Moreover, I believe users tend to make the >>>>> How does this prevent "tracking by IP-address" compared to "tracking >>>>> by TFO cookie"? >>>> As described, tracking by IP addresses has limitations especially if >>>> several users share the same IP address or change their publicly visible >>>> IP address frequently. As discussed, tracking via TFO cookies can be >>>> more persistent and more precise than tracking by IP addresses. >>> I don't see the more precise... See above. The more persistent I do see >>> and might be mitigated by timing out the TFO cookies. >>>> Applications controlling their retrieved TFO cookies can provide upper >>>> boundaries for feasible tracking periods via this mechanism without >>>> affecting the TFO performance of other applications. Furthermore, >>>> caching TFO cookies separately within each application prevents tracking >>>> user activities across these different applications on the same device. >>> But wouldn't the different applications on the same host use the same >>> IP address? Can't they the tracked by that in (almost the same way)? >> Most applications on the same host will certainly use the same IP >> address. However, this does not have to be the case. For example, every >> popular browser allows you to configure an application specific proxy >> that can change the publicly visible IP address of it's traffic (similar >> to the TorBrowser). > OK. So the server sees multiple proxies talking to him. Since the proxies > terminate the TCP connections, the server would not see the TFO cookies, > which were provided by the proxies to the clients. There exist different types of proxies. I thought of gateways/ tunnelling proxies that only change the publicly visible IP address similar to onion routing. Thus, the client's TFO cookie will be forwarded to the server. Best regards, Erik > > Best regards > Michael >> Best regards >> Erik >> >>> Best regards >>> Michael >>>> Best regards, >>>> Erik >>>> >>>>> Best regards >>>>> Michael >>>>>> application/browser vendor responsible to protect their privacy. Thus, >>>>>> these vendors require appropriate measures to control their users' privacy. >>>>>> >>>>>> Best regards, >>>>>> Erik >>>>>> >>>>>>> Best regards >>>>>>> Michael >>>>>>>>>> Returning to your example, onion routing does not necessarily protect >>>>>>>>>> you against tracking via TFO cookies. >>>>>>>>> Yepp, that is what I wanted to say. >>>>>>>>> But using TFO in that case doesn't >>>>>>>>> make much sense. >>>>>>>> Yes, TFO does not make sense if user privacy is at stake. Thus, we >>>>>>>> should warn users about these risks of RFC 7413. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Erik >>>>>>>> >>>>>>>> From nobody Thu May 23 09:38:59 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2972120113 for ; Thu, 23 May 2019 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.411 X-Spam-Level: X-Spam-Status: No, score=-7.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_SBL=10, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 49teGWhVRmxv for ; Thu, 23 May 2019 09:38:54 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 786B912006D for ; Thu, 23 May 2019 09:38:54 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id m3so7018675wrv.2 for ; Thu, 23 May 2019 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qw3MVrMtOqSLsvhAr+qH3WQ8tYegNR3pVSeSJ5NJnbQ=; b=ka0zHOpg07vjHmyfejsHtSS7WVVrGwuqJUs3JRRT3qf+x9F1tXSJoYgzNaGEbhdzxJ o2X6ETBlkdFkPz10P6XnBdDonN6nLPr4FfFHiIUmOhYMoQHK1WNQ1WlHthIn7FOt36fE owFuPi7uGDAXPlz/kFPwWUc9gNE8ZTtJUqB4+t6fg5MN2Fq/5zp6+2rzvxLOaPS4z3RA lEObfm4U3ZeXsOtdPdO5XHUr6bJrsRvjGHXK2K75jwZkXNr/euMpgvw9cZF+oa5y4KMb 6OKqRA+fimipuAEBz7PVtDZ8uRO9aXGJfOdafwBs/vkmVFgiROybn/dfHp7CMi3G/XlA 4CJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Qw3MVrMtOqSLsvhAr+qH3WQ8tYegNR3pVSeSJ5NJnbQ=; b=C5nDJglk5ToHomHpcQelhGQfbYTHo9ofaB5zTrSlYkHYn3rvlXyo6pwCuXh56lHhRb QaZ1RZJtfPEYCBCDR7TiffbK9a3A7uv9ru1OOW3x03lFTtSK6SlnHcYQ2ZYKUOS/TIP+ wnAfTcodAOxMdLX3g4Z3PhKI3OdrQr5R7Zk58NEbSZBy4pSEFEdPitx0OAt7DVv3InrV ddak7P9UAMT1ZGWF1X98xxobvu7dKA5QQTQP0hqgl92PZoxFunpU1OHgFuihAefOSFe/ ns7bJ3gJJx7LorRfv0Zy3EKiapeaDjIMuvG4Xs1I/74bj71zW/AgbbwTqAHHkO+h7BF0 iqpg== X-Gm-Message-State: APjAAAX883rGCdP/HXApXy8eSpms13t4f3foiNu0OSwiqE9N1rKAlICL Qg5vbISV+DxKzbeXGzOpTXxxkqJx9OrWzxpZOW65gV0B X-Google-Smtp-Source: APXvYqxMDVRD3DFQL4AKm/F9vxd8R26jcz/kECq1vINGuJQnHWitj1PME+3wqAeolsO+97BiiOe/iJTptGIIV90NbRY= X-Received: by 2002:adf:81a2:: with SMTP id 31mr58681128wra.165.1558629532169; Thu, 23 May 2019 09:38:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Thu, 23 May 2019 09:38:14 -0700 Message-ID: To: Olivier Bonaventure Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 16:38:57 -0000 On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure wrote: > > Yuchung, > > >> > >> We believe that a specialised TCP application should be allowed to use= its own cookie inside the payload instead of relying on the TCP header to = use fast open. The 0-RTT convert protocol is one example, but there could b= e others. Looking at other application layer protocols, I noticed that TLS1= .3 (rfc8446) also includes a cookie which is mainly designed enable servers= to get a confirmation of the reachability of the client IP addresses for D= TLS, but the same approach could be used when TLS sends its initial data in= the SYN as well. > >> > >> Another point that should be clarified in RFC7413 are how middleboxes = should handle SYN packets containing a non-zero payload. According to RFC79= 3, such packets are valid TCP packets. The TFO option, defined in RFC7314 i= s not and should not be considered as an indication that is required to =E2= =80=9Cauthorise=E2=80=9D the utilisation of payload inside a SYN packet. Du= ring the Prague meeting, Christoph Paasch mentioned at the mike that they h= ave one application that uses data inside the SYN and their measurements in= dicate that sending this SYN without the TFO option enables it to pass thro= ugh more middleboxes than when the same SYN contains the TFO option. > >> > >> Another point is the socket API. Currently, Linux and MacOS decouple t= he transmission of data inside the SYN from the utilisation of the TFO opti= on. This makes it possible for a client to send data inside the SYN without= enabling TFO. On Windows, the API seems to force the utilisation of TFO wh= en there is data in the SYN. As indicated earlier, RFC793 does not mandate = the presence of the TFO to place data inside the SYN. > >> > >> The approach we are proposing has the benefits of RFC7413 but without = its drawbacks. Moreover, given that RFC7413 is Experimental, we don't think= that there is a harm if we proceed with the approach 0-rtt convert protoco= l while the IETF can further tweak and adjust the applicability scope of RF= C7413. For example, an update can be proposed to RFC7413 to clarify that sp= ecialized application-level protocols could place cookie information in the= ir payload and thus not use the TFO option. > > Just to confirm: you mean an API that > > let application sets the TFO cookie (on either server and client)? > > > No, we suggest to let specific applications use data in the SYN without u= sing the TFO cookie. Those applications can manage their cookie inside the = SYN payload if needed. Instead of having TFO cookies that are managed by th= e TCP stack and have limited size, those specialised protocols would use ap= plication-level cookies which can be longer and are managed by these applic= ation protocols. I see. though I suppose this requires changing RFC793 of not uploading the data to application until 3WHS completes. > > > otherwise obviously application can place any data in their TCP payload= for its > > purposes. > > This is what we proposed in Prague, i.e. using data in the TCP SYN withou= t the TFO option. > > > Olivier > -- > > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > From nobody Thu May 23 13:06:20 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68F120123 for ; Thu, 23 May 2019 13:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 MmEOp2_-1MHs for ; Thu, 23 May 2019 13:06:15 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1907D1200C5 for ; Thu, 23 May 2019 13:06:15 -0700 (PDT) Received: from [192.168.1.2] (p57BB45F7.dip0.t-ipconnect.de [87.187.69.247]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id A12337213B003; Thu, 23 May 2019 22:06:10 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Tuexen In-Reply-To: <0a474aad-623f-8974-c52e-e832dc1f780d@informatik.uni-hamburg.de> Date: Thu, 23 May 2019 22:06:09 +0200 Cc: tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <2DDFC67A-C0E4-468D-85BF-645BCAAC1C52@lurchi.franken.de> References: <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> <7A3BBF13-C650-4AE2-B69A-18A1F5151DC7@lurchi.franken.de> <0a474aad-623f-8974-c52e-e832dc1f780d@informatik.uni-hamburg.de> To: sy@informatik.uni-hamburg.de X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [tcpm] Privacy problems of TCP Fast Open X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 20:06:19 -0000 > On 22. May 2019, at 23:42, Erik Sy = wrote: >=20 >=20 > On 5/22/19 22:25, Michael Tuexen wrote: >>> On 22. May 2019, at 21:41, Erik Sy = wrote: >>>=20 >>>=20 >>> On 5/22/19 19:21, Michael Tuexen wrote: >>>>> On 21. May 2019, at 22:51, Erik Sy = wrote: >>>>>=20 >>>>>=20 >>>>> On 5/21/19 21:56, Michael Tuexen wrote: >>>>>>> On 21. May 2019, at 21:22, Erik Sy = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 5/21/19 18:34, Michael Tuexen wrote: >>>>>>>>> On 21. May 2019, at 14:25, Erik Sy = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 5/21/19 12:18, Michael Tuexen wrote: >>>>>>>>>>> On 21. May 2019, at 09:52, Erik Sy = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Michael, >>>>>>>>>>>=20 >>>>>>>>>>> thanks for this question! >>>>>>>>>>>=20 >>>>>>>>>>> Yes, TFO cookies are bound to the clients (local) IP = address. However, a >>>>>>>>>>> client with a static local IP address in a home network will = use the >>>>>>>>>>> same TFO cookie independently of it's publicly visible IP = address. As a >>>>>>>>>>> result, TFO cookies present an independent tracking = mechanism, which >>>>>>>>>>> does not necessarily rely on the client's publicly visible = IP address. >>>>>>>>>> How often do the public addresses change? >>>>>>>>> I do not have a general answer to your question. In the case = of my home >>>>>>>>> network, my ISP assigns me at least every 24 hours a new IPv4 = address. >>>>>>>> I also had this on my DSL line (I guess we both live in = Germany), >>>>>>>> but since my telephone line was moved to "all IP", the = assignment stays >>>>>>>> up for months. >>>>>>>>> Additionally, I can initiate a change of my network's public = IP address >>>>>>>>> at anytime. >>>>>>>> Sure. >>>>>>>>> TFO cookies allow basically unlimited tracking periods because = they do >>>>>>>>> not have an expiration mechanism. Thus, even infrequently = changed IP >>>>>>>>> addresses can be correlated. >>>>>>>> An implementation can do implement such a thing and even allow = an API for it. >>>>>>> Yes, I agree with you that implementations can go beyond RFC = 7413 and >>>>>>> implement an expiration mechanism limiting feasible tracking = periods. >>>>>>>=20 >>>>>>>> For testing I'm flushing the cookie cache quite often... >>>>>>>>>> One could extend the TFO API in >>>>>>>>>> a way that the application can request a new cookie by only = sending=20 >>>>>>>>>> a cookie request. >>>>>>>>> I do not think this is an appropriate countermeasure. >>>>>>>>>=20 >>>>>>>>> =46rom my perspective, caching TFO cookies in the kernel is a = more >>>>>>>>> fundamental privacy problem. This design requires applications = to share >>>>>>>>> a pool of TFO cookies, which allows tracking across several >>>>>>>>> applications. For example, this prevents user's to separate = their online >>>>>>>>> activities across different browsers. >>>>>>>> They would share the IP address. If they decide to trigger a = new address >>>>>>>> binding on the access router, why couldn't they trigger = flushing the >>>>>>>> cache? >>>>>>> Flushing the cache presents a performance versus privacy trade = off >>>>>>> because flushing increases the chance of a cache miss preventing = a 0-RTT >>>>>>> handshake. >>>>>> Sure it does. It was just meant as an equivalent to resetting the >>>>>> public IP address of your access router. This also affects all = outgoing >>>>>> connections. >>>>>>> Thus, an application that often flushes the cache degrades the >>>>>>> performance of all other applications sharing the same pool of = TFO cookies. >>>>>>> As a result, the application with the highest privacy = requirements >>>>>>> limits the TFO performance of all other applications. >>>>>>>=20 >>>>>>> Furthermore flushing has difficulties to separate applications = running >>>>>>> at the same time. For example, running a browser window in the = normal >>>>>>> browsing mode and another window in the private browsing mode >>>>>>> (incognito). In this scenario, only excessive flushing can = prevent an >>>>>>> online tracker to link the user's online activities across both = browser >>>>>>> windows. >>>>>> Can't they both be linked by the IP address being used? >>>>> Tracking via IP addresses has the limitation that it cannot >>>>> differentiate clients behind a NAT. However, TFO cookies can be = used to >>>>> overcome this limitation if each TFO connection from the same IP = address >>>>> gets assigned a unique token. Thus, reusing such a unique token = during a >>>> How does that work. Wouldn't the server compute the cookie based on = the >>>> IP address it sees from the client, which is the public address of = the NAT, >>>> and is the same for all clients? So I would assume that all clients = behind >>>> a NAT store and use the same TFO cookie. >>> TFO cookies are created and consumed by the server and are opaque to = the >>> client. Yes, there exist implementations that only use the client's = IP >>> address to generate the TFO cookie. However, it is up to the server = to >>> add additional information into the cookies as described in: >>> https://tools.ietf.org/html/rfc7413#section-4.1.2 Number 4. A server >>> that wants to differentiate clients behind a NAT would make the = cookies >>> unique per connection. >> Are you aware of such an implementation?=20 > I did not investigate the default mechanisms different operating = systems > use to generate TFO cookies. However, patching a kernel to generate > unique TFO cookies for connections from the same IP address is = certainly > feasible for online trackers. For example, one can use an truncated = hash > of the client's IP address appended by a counter to construct such a > unique cookies. Sure. But this can always be done by the issuer of the cookie. Or am I = missing something? >> Doesn't that mean that a server >> has the capability to differentiate clients behind a NAT to provide = different >> TFO cookies? If he has the capability, why does he need TFO cookies? >=20 > No. Let's assume we have two clients behind a NAT with the same public > IP address. The first client receives a unique TFO cookie during its > first connection. When this client reconnects to the server, it will > present the cookie received during it's first connection. This allows > the server to conclude that both connection originate from the same = host > because this cookie was only issued a single time. The second client > will receive a different TFO cookie during it's first connection. = Thus, > both clients can be clearly differentiated by the server. As said above: If the issuer of the cookie wants to do that, it is = possible. This is a consequence of of using a cookie mechanism. As far as I know, neither Linux nor FreeBSD build the cookie in a way to send you different ones for different clients behind a NAT. Best regards Michael >=20 >=20 >>>>> connection request allows a more accurate tracking than can be = done via >>>>> the publicly visible IP addresses. >>>>>>> =46rom my perspective, an approach that delegates the caching to = the >>>>>>> application itself, is the better solution to address this = privacy >>>>>>> versus performance trade off. Moreover, I believe users tend to = make the >>>>>> How does this prevent "tracking by IP-address" compared to = "tracking >>>>>> by TFO cookie"? >>>>> As described, tracking by IP addresses has limitations especially = if >>>>> several users share the same IP address or change their publicly = visible >>>>> IP address frequently. As discussed, tracking via TFO cookies can = be >>>>> more persistent and more precise than tracking by IP addresses. >>>> I don't see the more precise... See above. The more persistent I do = see >>>> and might be mitigated by timing out the TFO cookies. >>>>> Applications controlling their retrieved TFO cookies can provide = upper >>>>> boundaries for feasible tracking periods via this mechanism = without >>>>> affecting the TFO performance of other applications. Furthermore, >>>>> caching TFO cookies separately within each application prevents = tracking >>>>> user activities across these different applications on the same = device. >>>> But wouldn't the different applications on the same host use the = same >>>> IP address? Can't they the tracked by that in (almost the same = way)? >>> Most applications on the same host will certainly use the same IP >>> address. However, this does not have to be the case. For example, = every >>> popular browser allows you to configure an application specific = proxy >>> that can change the publicly visible IP address of it's traffic = (similar >>> to the TorBrowser). >> OK. So the server sees multiple proxies talking to him. Since the = proxies >> terminate the TCP connections, the server would not see the TFO = cookies, >> which were provided by the proxies to the clients. > There exist different types of proxies. I thought of gateways/ > tunnelling proxies that only change the publicly visible IP address > similar to onion routing. Thus, the client's TFO cookie will be > forwarded to the server. >=20 > Best regards, > Erik >=20 >>=20 >> Best regards >> Michael >>> Best regards >>> Erik >>>=20 >>>> Best regards >>>> Michael >>>>> Best regards, >>>>> Erik >>>>>=20 >>>>>> Best regards >>>>>> Michael >>>>>>> application/browser vendor responsible to protect their privacy. = Thus, >>>>>>> these vendors require appropriate measures to control their = users' privacy. >>>>>>>=20 >>>>>>> Best regards, >>>>>>> Erik >>>>>>>=20 >>>>>>>> Best regards >>>>>>>> Michael >>>>>>>>>>> Returning to your example, onion routing does not = necessarily protect >>>>>>>>>>> you against tracking via TFO cookies. >>>>>>>>>> Yepp, that is what I wanted to say.=20 >>>>>>>>>> But using TFO in that case doesn't >>>>>>>>>> make much sense. >>>>>>>>> Yes, TFO does not make sense if user privacy is at stake. = Thus, we >>>>>>>>> should warn users about these risks of RFC 7413. >>>>>>>>>=20 >>>>>>>>> Best regards, >>>>>>>>> Erik >>>>>>>>>=20 >>>>>>>>>=20 From nobody Fri May 24 08:01:37 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9321202EC for ; Fri, 24 May 2019 08:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.41 X-Spam-Level: X-Spam-Status: No, score=-7.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, URIBL_SBL=10, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Sn1t-X00Hoex for ; Fri, 24 May 2019 08:01:33 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 66E23120019 for ; Fri, 24 May 2019 08:01:33 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id x64so9717767wmb.5 for ; Fri, 24 May 2019 08:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i4LtHzpVGhieVdGANC7NMRcMyb8WWtQvvU3E84PhsJk=; b=n8Prkcf4zEg9JcIW+xduqNjg59ngJ2vYUCpqu4XEzygjJzAHoDxP5AxpSQZs2Z6aXQ lHrlw36GS34AX26ag5VtGEH8bmPyXdASnLCOfO/4Sn9w265DiSxEW9bwi+SwrI4JFnNV VTRkbHBJ20LkTXLR3YHnP5ThIsK3dgnZG1YZ8/R5oF+4+O5oLZdwvTxASqtZN8K/QgOA Nhq0ZQ4dr+jBGIYPhyNol9VqvBfxLsYawU9YwyNpJb3Bj4DJM20PMPn2cVSQfKu98nqP EotkhznzbLSpxdC6MOdccjDWMCXzkm0LgA2Au43v3Dlbl3VRxfsgvJbV3mK7yKrEfuQO xhGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i4LtHzpVGhieVdGANC7NMRcMyb8WWtQvvU3E84PhsJk=; b=b3r5VW1V2yMN0WOXWuFr8mmpevgsfBBoHK8s+zBHV5Bqw+9nb8RL6QAKOvM6WqBQWu AXXd2Gz8YQpL39cfOZz30xvYVNkC0nr2L7mbyRlqc8l0hVE5vjb9fWTod6SvAJpfwHzH k/SkjVg+3kYoFDFEwG+lK2v1jogRQVLpOHDDrPGUBezUJKdNoMgzKAC/7TQFXFmBRf5K xpDm6vpr92FCYnOKXa2DEvP7NLCfL6vU8/CbKvIkkDV7UCehmNM6y9w7zwMKTmwspYiu k6N5b/qLZUHx5Txd3z7Z2GxKnSqmy0Cl8QNYTAP4mdISu6wTbNBUgv1LujOfyl3J6GAq YAVA== X-Gm-Message-State: APjAAAWrTuo4WrtlUS1+kogDcXvEhAqGyFD8+aoUnVmZujmFPc4grDnQ 8PFPTiiS4EPzUvkcqb1zH+yuy8NEOpXQ06kIvZ9xJoVm X-Google-Smtp-Source: APXvYqwru+ptxw6StjccGBscirumNKWJqnDc8jDh1QIerU/emQ4FQqMYsL4chbE9SccDySSxrr3EwFCEATt355TAmZg= X-Received: by 2002:a1c:38c5:: with SMTP id f188mr180633wma.9.1558710091205; Fri, 24 May 2019 08:01:31 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yuchung Cheng Date: Fri, 24 May 2019 08:00:53 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: Olivier Bonaventure , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 15:01:36 -0000 On Thu, May 23, 2019 at 11:34 PM wrote: > > Hi Yuchung, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung Cheng > > Envoy=C3=A9 : jeudi 23 mai 2019 18:38 > > =C3=80 : Olivier Bonaventure > > Cc : tcpm@ietf.org Extensions > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure > > wrote: > > > > > > Yuchung, > > > > > > >> > > > >> We believe that a specialised TCP application should be allowed to > > use its own cookie inside the payload instead of relying on the TCP hea= der > > to use fast open. The 0-RTT convert protocol is one example, but there > > could be others. Looking at other application layer protocols, I notice= d > > that TLS1.3 (rfc8446) also includes a cookie which is mainly designed > > enable servers to get a confirmation of the reachability of the client = IP > > addresses for DTLS, but the same approach could be used when TLS sends = its > > initial data in the SYN as well. > > > >> > > > >> Another point that should be clarified in RFC7413 are how middlebo= xes > > should handle SYN packets containing a non-zero payload. According to > > RFC793, such packets are valid TCP packets. The TFO option, defined in > > RFC7314 is not and should not be considered as an indication that is > > required to =E2=80=9Cauthorise=E2=80=9D the utilisation of payload insi= de a SYN packet. > > During the Prague meeting, Christoph Paasch mentioned at the mike that > > they have one application that uses data inside the SYN and their > > measurements indicate that sending this SYN without the TFO option enab= les > > it to pass through more middleboxes than when the same SYN contains the > > TFO option. > > > >> > > > >> Another point is the socket API. Currently, Linux and MacOS decoup= le > > the transmission of data inside the SYN from the utilisation of the TFO > > option. This makes it possible for a client to send data inside the SYN > > without enabling TFO. On Windows, the API seems to force the utilisatio= n > > of TFO when there is data in the SYN. As indicated earlier, RFC793 does > > not mandate the presence of the TFO to place data inside the SYN. > > > >> > > > >> The approach we are proposing has the benefits of RFC7413 but with= out > > its drawbacks. Moreover, given that RFC7413 is Experimental, we don't > > think that there is a harm if we proceed with the approach 0-rtt conver= t > > protocol while the IETF can further tweak and adjust the applicability > > scope of RFC7413. For example, an update can be proposed to RFC7413 to > > clarify that specialized application-level protocols could place cookie > > information in their payload and thus not use the TFO option. > > > > Just to confirm: you mean an API that > > > > let application sets the TFO cookie (on either server and client)? > > > > > > > > > No, we suggest to let specific applications use data in the SYN witho= ut > > using the TFO cookie. Those applications can manage their cookie inside > > the SYN payload if needed. Instead of having TFO cookies that are manag= ed > > by the TCP stack and have limited size, those specialised protocols wou= ld > > use application-level cookies which can be longer and are managed by th= ese > > application protocols. > > I see. though I suppose this requires changing RFC793 of not uploading > > the data to application until 3WHS completes. > > > > [Med] That constraint can be relaxed following a rationale similar to the= one in RFC7413. > > Is there any particular reason why a change to RFC793 would be required h= ere but not for RFC7413? It's an interesting question - RFC793 long allows data-in-SYN but requires data to be posted after handshake. RFC7413 relaxes that but also requires a cookie. So if we think this is an "extension" to TFO, then perhaps extends RFC7413 not changing RFC793? personally I do think that makes sense. IMO TFO implementation provides a generic way to do data-in-SYN. Application can use whatever they prefer to protect or optimize data-in-SYN. TFO cookie is just a default simple mechanism for application who finds that acceptable. > > > > > > > > otherwise obviously application can place any data in their TCP > > payload for its > > > > purposes. > > > > > > This is what we proposed in Prague, i.e. using data in the TCP SYN > > without the TFO option. > > > > > > > > > Olivier > > > -- > > > > > > > > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun May 26 08:50:42 2019 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E68120006; Sun, 26 May 2019 08:50:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: michael.scharf@hs-esslingen.de, tcpm@ietf.org, ietf@kuehlewind.net, tcpm-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155888583986.18372.5419860498204692737.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2019 08:50:39 -0700 Archived-At: Subject: [tcpm] tcpm - New Meeting Session Request for IETF 105 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 May 2019 15:50:40 -0000 A new meeting session request has just been submitted by Michael Scharf, a Chair of the tcpm working group. --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: iccrg tcpinc mptcp taps tsvarea tsvwg quic Second Priority: httpbis lwig rmcat teas detnet Third Priority: rtcweb maprg panrg People who must be present: Yoshifumi Nishida Michael Tuexen Michael Scharf Mirja Kuehlewind Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon May 27 02:36:27 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA44912006D for ; Mon, 27 May 2019 02:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 iDYFQsXH-WPT for ; Mon, 27 May 2019 02:36:23 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CD0120033 for ; Mon, 27 May 2019 02:36:23 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45CBgT5V9mzFqJY; Mon, 27 May 2019 11:36:21 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 45CBgT4SsfzCql5; Mon, 27 May 2019 11:36:21 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 27 May 2019 11:36:21 +0200 From: To: Yuchung Cheng CC: Olivier Bonaventure , "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVEkGTbjKW3YkghkOKhWLDIJr28qZ+uG5w Date: Mon, 27 May 2019 09:36:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA8F74D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 09:36:26 -0000 SGkgWXVjaHVuZywgDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogWXVjaHVuZyBDaGVuZyBbbWFpbHRv OnljaGVuZ0Bnb29nbGUuY29tXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDI0IG1haSAyMDE5IDE3 OjAxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogT2xpdmllciBC b25hdmVudHVyZTsgdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zDQo+IE9iamV0wqA6IFJlOiBbdGNw bV0gUHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gDQo+IE9uIFRodSwg TWF5IDIzLCAyMDE5IGF0IDExOjM0IFBNIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3 cm90ZToNCj4gPg0KPiA+IEhpIFl1Y2h1bmcsDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4N Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4gPiBEZSA6IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgWXVjaHVuZyBDaGVuZw0KPiA+ID4gRW52b3nDqSA6IGpldWRpIDIzIG1h aSAyMDE5IDE4OjM4DQo+ID4gPiDDgCA6IE9saXZpZXIgQm9uYXZlbnR1cmUNCj4gPiA+IENjIDog dGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zDQo+ID4gPiBPYmpldCA6IFJlOiBbdGNwbV0gUHJvZ3Jl c3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gPiA+DQo+ID4gPiBPbiBUdWUsIE1h eSAyMSwgMjAxOSBhdCA0OjUyIEFNIE9saXZpZXIgQm9uYXZlbnR1cmUNCj4gPiA+IDxvbGl2aWVy LmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldD4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IFl1Y2h1 bmcsDQo+ID4gPiA+DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFdlIGJlbGlldmUgdGhhdCBhIHNw ZWNpYWxpc2VkIFRDUCBhcHBsaWNhdGlvbiBzaG91bGQgYmUgYWxsb3dlZA0KPiB0bw0KPiA+ID4g dXNlIGl0cyBvd24gY29va2llIGluc2lkZSB0aGUgcGF5bG9hZCBpbnN0ZWFkIG9mIHJlbHlpbmcg b24gdGhlIFRDUA0KPiBoZWFkZXINCj4gPiA+IHRvIHVzZSBmYXN0IG9wZW4uIFRoZSAwLVJUVCBj b252ZXJ0IHByb3RvY29sIGlzIG9uZSBleGFtcGxlLCBidXQgdGhlcmUNCj4gPiA+IGNvdWxkIGJl IG90aGVycy4gTG9va2luZyBhdCBvdGhlciBhcHBsaWNhdGlvbiBsYXllciBwcm90b2NvbHMsIEkN Cj4gbm90aWNlZA0KPiA+ID4gdGhhdCBUTFMxLjMgKHJmYzg0NDYpIGFsc28gaW5jbHVkZXMgYSBj b29raWUgd2hpY2ggaXMgbWFpbmx5IGRlc2lnbmVkDQo+ID4gPiBlbmFibGUgc2VydmVycyB0byBn ZXQgYSBjb25maXJtYXRpb24gb2YgdGhlIHJlYWNoYWJpbGl0eSBvZiB0aGUgY2xpZW50DQo+IElQ DQo+ID4gPiBhZGRyZXNzZXMgZm9yIERUTFMsIGJ1dCB0aGUgc2FtZSBhcHByb2FjaCBjb3VsZCBi ZSB1c2VkIHdoZW4gVExTIHNlbmRzDQo+IGl0cw0KPiA+ID4gaW5pdGlhbCBkYXRhIGluIHRoZSBT WU4gYXMgd2VsbC4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQW5vdGhlciBwb2ludCB0aGF0IHNo b3VsZCBiZSBjbGFyaWZpZWQgaW4gUkZDNzQxMyBhcmUgaG93DQo+IG1pZGRsZWJveGVzDQo+ID4g PiBzaG91bGQgaGFuZGxlIFNZTiBwYWNrZXRzIGNvbnRhaW5pbmcgYSBub24temVybyBwYXlsb2Fk LiBBY2NvcmRpbmcgdG8NCj4gPiA+IFJGQzc5Mywgc3VjaCBwYWNrZXRzIGFyZSB2YWxpZCBUQ1Ag cGFja2V0cy4gVGhlIFRGTyBvcHRpb24sIGRlZmluZWQgaW4NCj4gPiA+IFJGQzczMTQgaXMgbm90 IGFuZCBzaG91bGQgbm90IGJlIGNvbnNpZGVyZWQgYXMgYW4gaW5kaWNhdGlvbiB0aGF0IGlzDQo+ ID4gPiByZXF1aXJlZCB0byDigJxhdXRob3Jpc2XigJ0gdGhlIHV0aWxpc2F0aW9uIG9mIHBheWxv YWQgaW5zaWRlIGEgU1lODQo+IHBhY2tldC4NCj4gPiA+IER1cmluZyB0aGUgUHJhZ3VlIG1lZXRp bmcsIENocmlzdG9waCBQYWFzY2ggbWVudGlvbmVkIGF0IHRoZSBtaWtlIHRoYXQNCj4gPiA+IHRo ZXkgaGF2ZSBvbmUgYXBwbGljYXRpb24gdGhhdCB1c2VzIGRhdGEgaW5zaWRlIHRoZSBTWU4gYW5k IHRoZWlyDQo+ID4gPiBtZWFzdXJlbWVudHMgaW5kaWNhdGUgdGhhdCBzZW5kaW5nIHRoaXMgU1lO IHdpdGhvdXQgdGhlIFRGTyBvcHRpb24NCj4gZW5hYmxlcw0KPiA+ID4gaXQgdG8gcGFzcyB0aHJv dWdoIG1vcmUgbWlkZGxlYm94ZXMgdGhhbiB3aGVuIHRoZSBzYW1lIFNZTiBjb250YWlucw0KPiB0 aGUNCj4gPiA+IFRGTyBvcHRpb24uDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEFub3RoZXIgcG9p bnQgaXMgdGhlIHNvY2tldCBBUEkuIEN1cnJlbnRseSwgTGludXggYW5kIE1hY09TDQo+IGRlY291 cGxlDQo+ID4gPiB0aGUgdHJhbnNtaXNzaW9uIG9mIGRhdGEgaW5zaWRlIHRoZSBTWU4gZnJvbSB0 aGUgdXRpbGlzYXRpb24gb2YgdGhlDQo+IFRGTw0KPiA+ID4gb3B0aW9uLiBUaGlzIG1ha2VzIGl0 IHBvc3NpYmxlIGZvciBhIGNsaWVudCB0byBzZW5kIGRhdGEgaW5zaWRlIHRoZQ0KPiBTWU4NCj4g PiA+IHdpdGhvdXQgZW5hYmxpbmcgVEZPLiBPbiBXaW5kb3dzLCB0aGUgQVBJIHNlZW1zIHRvIGZv cmNlIHRoZQ0KPiB1dGlsaXNhdGlvbg0KPiA+ID4gb2YgVEZPIHdoZW4gdGhlcmUgaXMgZGF0YSBp biB0aGUgU1lOLiBBcyBpbmRpY2F0ZWQgZWFybGllciwgUkZDNzkzDQo+IGRvZXMNCj4gPiA+IG5v dCBtYW5kYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGUgVEZPIHRvIHBsYWNlIGRhdGEgaW5zaWRlIHRo ZSBTWU4uDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFRoZSBhcHByb2FjaCB3ZSBhcmUgcHJvcG9z aW5nIGhhcyB0aGUgYmVuZWZpdHMgb2YgUkZDNzQxMyBidXQNCj4gd2l0aG91dA0KPiA+ID4gaXRz IGRyYXdiYWNrcy4gTW9yZW92ZXIsIGdpdmVuIHRoYXQgUkZDNzQxMyBpcyBFeHBlcmltZW50YWws IHdlIGRvbid0DQo+ID4gPiB0aGluayB0aGF0IHRoZXJlIGlzIGEgaGFybSBpZiB3ZSBwcm9jZWVk IHdpdGggdGhlIGFwcHJvYWNoIDAtcnR0DQo+IGNvbnZlcnQNCj4gPiA+IHByb3RvY29sIHdoaWxl IHRoZSBJRVRGIGNhbiBmdXJ0aGVyIHR3ZWFrIGFuZCBhZGp1c3QgdGhlIGFwcGxpY2FiaWxpdHkN Cj4gPiA+IHNjb3BlIG9mIFJGQzc0MTMuIEZvciBleGFtcGxlLCBhbiB1cGRhdGUgY2FuIGJlIHBy b3Bvc2VkIHRvIFJGQzc0MTMgdG8NCj4gPiA+IGNsYXJpZnkgdGhhdCBzcGVjaWFsaXplZCBhcHBs aWNhdGlvbi1sZXZlbCBwcm90b2NvbHMgY291bGQgcGxhY2UNCj4gY29va2llDQo+ID4gPiBpbmZv cm1hdGlvbiBpbiB0aGVpciBwYXlsb2FkIGFuZCB0aHVzIG5vdCB1c2UgdGhlIFRGTyBvcHRpb24u DQo+ID4gPiA+ID4gSnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiBhbiBBUEkgdGhhdA0KPiA+ID4g PiA+IGxldCBhcHBsaWNhdGlvbiBzZXRzIHRoZSBURk8gY29va2llIChvbiBlaXRoZXIgc2VydmVy IGFuZCBjbGllbnQpPw0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBObywgd2Ugc3VnZ2VzdCB0 byBsZXQgc3BlY2lmaWMgYXBwbGljYXRpb25zIHVzZSBkYXRhIGluIHRoZSBTWU4NCj4gd2l0aG91 dA0KPiA+ID4gdXNpbmcgdGhlIFRGTyBjb29raWUuIFRob3NlIGFwcGxpY2F0aW9ucyBjYW4gbWFu YWdlIHRoZWlyIGNvb2tpZQ0KPiBpbnNpZGUNCj4gPiA+IHRoZSBTWU4gcGF5bG9hZCBpZiBuZWVk ZWQuIEluc3RlYWQgb2YgaGF2aW5nIFRGTyBjb29raWVzIHRoYXQgYXJlDQo+IG1hbmFnZWQNCj4g PiA+IGJ5IHRoZSBUQ1Agc3RhY2sgYW5kIGhhdmUgbGltaXRlZCBzaXplLCB0aG9zZSBzcGVjaWFs aXNlZCBwcm90b2NvbHMNCj4gd291bGQNCj4gPiA+IHVzZSBhcHBsaWNhdGlvbi1sZXZlbCBjb29r aWVzIHdoaWNoIGNhbiBiZSBsb25nZXIgYW5kIGFyZSBtYW5hZ2VkIGJ5DQo+IHRoZXNlDQo+ID4g PiBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQo+ID4gPiBJIHNlZS4gdGhvdWdoIEkgc3VwcG9zZSB0 aGlzIHJlcXVpcmVzIGNoYW5naW5nIFJGQzc5MyBvZiBub3QgdXBsb2FkaW5nDQo+ID4gPiB0aGUg ZGF0YSB0byBhcHBsaWNhdGlvbiB1bnRpbCAzV0hTIGNvbXBsZXRlcy4NCj4gPiA+DQo+ID4NCj4g PiBbTWVkXSBUaGF0IGNvbnN0cmFpbnQgY2FuIGJlIHJlbGF4ZWQgZm9sbG93aW5nIGEgcmF0aW9u YWxlIHNpbWlsYXIgdG8NCj4gdGhlIG9uZSBpbiBSRkM3NDEzLg0KPiA+DQo+ID4gSXMgdGhlcmUg YW55IHBhcnRpY3VsYXIgcmVhc29uIHdoeSBhIGNoYW5nZSB0byBSRkM3OTMgd291bGQgYmUgcmVx dWlyZWQNCj4gaGVyZSBidXQgbm90IGZvciBSRkM3NDEzPw0KPiBJdCdzIGFuIGludGVyZXN0aW5n IHF1ZXN0aW9uIC0NCj4gDQo+IFJGQzc5MyBsb25nIGFsbG93cyBkYXRhLWluLVNZTiBidXQgcmVx dWlyZXMgZGF0YSB0byBiZSBwb3N0ZWQgYWZ0ZXINCj4gaGFuZHNoYWtlLiBSRkM3NDEzIHJlbGF4 ZXMgdGhhdCBidXQgYWxzbyByZXF1aXJlcyBhIGNvb2tpZS4NCg0KW01lZF0gWWVhaC4gU2FtZSB3 aXRoIGFueSBvdGhlciBhcHByb2FjaCB1c2luZyBhIGNvb2tpZS4gSSBkb27igJl0IHNlZSBhIHZh bGlkIHJlYXNvbiB3aHkgYW4gYXBwcm9hY2ggd291bGQgYmUgbWFya2VkIGFzIHVwZGF0aW5nIDc5 MyBidXQgdGhlIGFsdGVybmF0aXZlIHdvdWxkbid0Lg0KDQo+IA0KPiBTbyBpZiB3ZSB0aGluayB0 aGlzIGlzIGFuICJleHRlbnNpb24iIHRvIFRGTw0KDQpbTWVkXSBJdCBpcyBub3QgYW4gZXh0ZW5z aW9uIHBlciBzZS4gSXQgaXMgYW5vdGhlciB3YXkgdG8gYWNoaWV2ZSB0aGUgc2FtZSBnb2FscyBh cyBURk8gYnV0IHdpdGhvdXQgdGhlIFRGTyBpc3N1ZXMgKGUuZy4sIHRjcCBvcHRpb24gc3BhY2Us IG1pZGRsZWJveGVzIHN0cmlwcGluZyB0Zm8pLg0KDQosIHRoZW4gcGVyaGFwcyBleHRlbmRzDQo+ IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8gcGVyc29uYWxseSBJIGRvIHRoaW5rIHRoYXQg bWFrZXMgc2Vuc2UuDQo+IElNTyBURk8gaW1wbGVtZW50YXRpb24gcHJvdmlkZXMgYSBnZW5lcmlj IHdheSB0byBkbyBkYXRhLWluLVNZTi4NCj4gQXBwbGljYXRpb24gY2FuIHVzZSB3aGF0ZXZlciB0 aGV5IHByZWZlciB0byBwcm90ZWN0IG9yIG9wdGltaXplDQo+IGRhdGEtaW4tU1lOLiBURk8gY29v a2llIGlzIGp1c3QgYSBkZWZhdWx0IHNpbXBsZSBtZWNoYW5pc20gZm9yDQo+IGFwcGxpY2F0aW9u IHdobyBmaW5kcyB0aGF0IGFjY2VwdGFibGUuDQo+IA0KPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4g b3RoZXJ3aXNlIG9idmlvdXNseSBhcHBsaWNhdGlvbiBjYW4gcGxhY2UgYW55IGRhdGEgaW4gdGhl aXIgVENQDQo+ID4gPiBwYXlsb2FkIGZvciBpdHMNCj4gPiA+ID4gPiBwdXJwb3Nlcy4NCj4gPiA+ ID4NCj4gPiA+ID4gVGhpcyBpcyB3aGF0IHdlIHByb3Bvc2VkIGluIFByYWd1ZSwgaS5lLiB1c2lu ZyBkYXRhIGluIHRoZSBUQ1AgU1lODQo+ID4gPiB3aXRob3V0IHRoZSBURk8gb3B0aW9uLg0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBPbGl2aWVyDQo+ID4gPiA+IC0tDQo+ID4gPiA+DQo+ID4g PiA+DQo+ID4gPiA+IERpc2NsYWltZXI6IGh0dHBzOi8vd3d3LnRlc3NhcmVzLm5ldC9tYWlsLWRp c2NsYWltZXIvDQo+ID4gPiA+IDxodHRwczovL3d3dy50ZXNzYXJlcy5uZXQvbWFpbC1kaXNjbGFp bWVyLz4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4g PiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGNwbQ0K From nobody Mon May 27 04:37:58 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06008120133 for ; Mon, 27 May 2019 04:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xD7TAlJBcImS for ; Mon, 27 May 2019 04:37:54 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9F31200B8 for ; Mon, 27 May 2019 04:37:53 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45CFMh0VwKz301V; Mon, 27 May 2019 13:37:52 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 45CFMg6jpnzCqk7; Mon, 27 May 2019 13:37:51 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 27 May 2019 13:37:51 +0200 From: To: Praveen Balasubramanian , Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVEkGTbjKW3YkghkOKhWLDIJr28qZ6WiIAgASAsYA= Date: Mon, 27 May 2019 11:37:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 11:37:56 -0000 SGkgUHJhdmVlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4gW21haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDI0 IG1haSAyMDE5IDE4OjQ1DQo+IMOAwqA6IFl1Y2h1bmcgQ2hlbmc7IEJPVUNBREFJUiBNb2hhbWVk IFRHSS9PTE4NCj4gQ2PCoDogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zDQo+IE9iamV0wqA6IFJF OiBbdGNwbV0gUHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gDQo+IEFn cmVlZCBhbmQgSSBoYWQgcmFpc2VkIHRoZSBzYW1lIHF1ZXN0aW9uIGJlZm9yZTogIiBJc24ndCBw YXNzaW5nIGRhdGEgaW4NCj4gdGhlIFNZTiB1cCB0byB0aGUgYXBwbGljYXRpb24gYmVmb3JlIDNX SFMgaW52YWxpZCBwZXIgUkZDIDc5Mz8NCg0KW01lZF0gVGhpcyBpcyBzaW1pbGFyIHRvIHdoYXQg VEZPIGRvZXMuIEJvdGggKGkuZS4sIFRGTyBhbmQgdGhlIGFwcGxpY2F0aW9uLWJhc2VkIGNvb2tp ZSkgYXJlIHJlbGF4aW5nIHRoYXQgY29uc3RyYWludCBmcm9tIDc5My4gDQoNCiBIb3cgaXMgdGhl DQo+IGNvbnZlcnRlciAoVCkgZXh0cmFjdGluZyB0aGUgc2VydmVyIElQIGFkZHJlc3MgYW5kIHBv cnQgZnJvbSB0aGUgU1lODQo+IHBheWxvYWQ/IElzIGl0IHJ1bm5pbmcgc29tZSBjdXN0b20gVENQ IGltcGxlbWVudGF0aW9uIHRoYXQgdmlvbGF0ZXMgNzkzPyINCj4gNzQxMyBhbGxvd3MgbmlsLWNv b2tpZSBhbmQgYXBwIGNhbiBlbmNvZGUgY29va2llIGFuZCBkYXRhIGluIFNZTiBpZiBpdA0KPiB3 YW50cy4gSWYgVEZPIG9wdGlvbiBpcyBub3QgdXNlZCBhdCBhbGwgdGhlbiBpdCB3b3VsZCBiZSBh IGNoYW5nZSB0byA3OTMNCj4gYW5kIG5vdCA3NDEzLg0KDQpbTWVkXSBUaGlzIGlzIHdoYXQgdGhl IGluaXRpYWwgbWVzc2FnZSBmcm9tIE9saXZpZXIgdHJpZWQgdG8gYWRkcmVzcy4gVGhlIGlzc3Vl IGlzIHdoYXQgaXMgdGhlIHBvaW50IGluIGVuY2xvc2luZyB0aGUgVEZPIG9wdGlvbiBpZiB0aGUg Y29va2llIGlzIHN1cHBsaWVkIGJ5IHRoZSBhcHBsaWNhdGlvbj8gVGhlIHNhbWUgcHJvdGVjdGlv biBsZXZlbCBjYW4gYmUgcHJvdmlkZWQgd2l0aCB0aGUgYXBwbGljYXRpb24tc3VwcGxpZWQgY29v a2llIHdpdGhvdXQgcmVxdWlyaW5nIHRvIGluc2VydCB0aGUgVEZPIG9wdGlvbi4gIA0KDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBZdWNodW5nIENoZW5nDQo+IFNlbnQ6IEZyaWRheSwgTWF5 IDI0LCAyMDE5IDg6MDEgQU0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4g Q2M6IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyA8dGNwbUBpZXRmLm9yZz4NCj4gU3ViamVjdDog UmU6IFt0Y3BtXSBQcm9ncmVzc2luZyBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycw0KPiANCj4g T24gVGh1LCBNYXkgMjMsIDIwMTkgYXQgMTE6MzQgUE0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgWXVjaHVuZywNCj4gPg0KPiA+IFBsZWFzZSBzZWUg aW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4gPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gPiA+IERlIDogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0Bp ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBZdWNodW5nIENoZW5nDQo+ID4gPiBFbnZvecOpIDogamV1 ZGkgMjMgbWFpIDIwMTkgMTg6Mzggw4AgOiBPbGl2aWVyIEJvbmF2ZW50dXJlIENjIDoNCj4gPiA+ IHRjcG1AaWV0Zi5vcmcgRXh0ZW5zaW9ucyBPYmpldCA6IFJlOiBbdGNwbV0gUHJvZ3Jlc3NpbmcN Cj4gPiA+IGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+ID4gPg0KPiA+ID4gT24gVHVlLCBN YXkgMjEsIDIwMTkgYXQgNDo1MiBBTSBPbGl2aWVyIEJvbmF2ZW50dXJlDQo+ID4gPiA8b2xpdmll ci5ib25hdmVudHVyZUB0ZXNzYXJlcy5uZXQ+IHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiBZdWNo dW5nLA0KPiA+ID4gPg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBXZSBiZWxpZXZlIHRoYXQgYSBz cGVjaWFsaXNlZCBUQ1AgYXBwbGljYXRpb24gc2hvdWxkIGJlIGFsbG93ZWQNCj4gPiA+ID4gPj4g dG8NCj4gPiA+IHVzZSBpdHMgb3duIGNvb2tpZSBpbnNpZGUgdGhlIHBheWxvYWQgaW5zdGVhZCBv ZiByZWx5aW5nIG9uIHRoZSBUQ1ANCj4gPiA+IGhlYWRlciB0byB1c2UgZmFzdCBvcGVuLiBUaGUg MC1SVFQgY29udmVydCBwcm90b2NvbCBpcyBvbmUgZXhhbXBsZSwNCj4gPiA+IGJ1dCB0aGVyZSBj b3VsZCBiZSBvdGhlcnMuIExvb2tpbmcgYXQgb3RoZXIgYXBwbGljYXRpb24gbGF5ZXINCj4gPiA+ IHByb3RvY29scywgSSBub3RpY2VkIHRoYXQgVExTMS4zIChyZmM4NDQ2KSBhbHNvIGluY2x1ZGVz IGEgY29va2llDQo+ID4gPiB3aGljaCBpcyBtYWlubHkgZGVzaWduZWQgZW5hYmxlIHNlcnZlcnMg dG8gZ2V0IGEgY29uZmlybWF0aW9uIG9mIHRoZQ0KPiA+ID4gcmVhY2hhYmlsaXR5IG9mIHRoZSBj bGllbnQgSVAgYWRkcmVzc2VzIGZvciBEVExTLCBidXQgdGhlIHNhbWUNCj4gPiA+IGFwcHJvYWNo IGNvdWxkIGJlIHVzZWQgd2hlbiBUTFMgc2VuZHMgaXRzIGluaXRpYWwgZGF0YSBpbiB0aGUgU1lO IGFzDQo+IHdlbGwuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEFub3RoZXIgcG9pbnQgdGhhdCBz aG91bGQgYmUgY2xhcmlmaWVkIGluIFJGQzc0MTMgYXJlIGhvdw0KPiA+ID4gPiA+PiBtaWRkbGVi b3hlcw0KPiA+ID4gc2hvdWxkIGhhbmRsZSBTWU4gcGFja2V0cyBjb250YWluaW5nIGEgbm9uLXpl cm8gcGF5bG9hZC4gQWNjb3JkaW5nDQo+ID4gPiB0byBSRkM3OTMsIHN1Y2ggcGFja2V0cyBhcmUg dmFsaWQgVENQIHBhY2tldHMuIFRoZSBURk8gb3B0aW9uLA0KPiA+ID4gZGVmaW5lZCBpbg0KPiA+ ID4gUkZDNzMxNCBpcyBub3QgYW5kIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBhcyBhbiBpbmRp Y2F0aW9uIHRoYXQgaXMNCj4gPiA+IHJlcXVpcmVkIHRvIOKAnGF1dGhvcmlzZeKAnSB0aGUgdXRp bGlzYXRpb24gb2YgcGF5bG9hZCBpbnNpZGUgYSBTWU4NCj4gcGFja2V0Lg0KPiA+ID4gRHVyaW5n IHRoZSBQcmFndWUgbWVldGluZywgQ2hyaXN0b3BoIFBhYXNjaCBtZW50aW9uZWQgYXQgdGhlIG1p a2UNCj4gPiA+IHRoYXQgdGhleSBoYXZlIG9uZSBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgZGF0YSBp bnNpZGUgdGhlIFNZTiBhbmQNCj4gPiA+IHRoZWlyIG1lYXN1cmVtZW50cyBpbmRpY2F0ZSB0aGF0 IHNlbmRpbmcgdGhpcyBTWU4gd2l0aG91dCB0aGUgVEZPDQo+ID4gPiBvcHRpb24gZW5hYmxlcyBp dCB0byBwYXNzIHRocm91Z2ggbW9yZSBtaWRkbGVib3hlcyB0aGFuIHdoZW4gdGhlDQo+ID4gPiBz YW1lIFNZTiBjb250YWlucyB0aGUgVEZPIG9wdGlvbi4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4g QW5vdGhlciBwb2ludCBpcyB0aGUgc29ja2V0IEFQSS4gQ3VycmVudGx5LCBMaW51eCBhbmQgTWFj T1MNCj4gPiA+ID4gPj4gZGVjb3VwbGUNCj4gPiA+IHRoZSB0cmFuc21pc3Npb24gb2YgZGF0YSBp bnNpZGUgdGhlIFNZTiBmcm9tIHRoZSB1dGlsaXNhdGlvbiBvZiB0aGUNCj4gPiA+IFRGTyBvcHRp b24uIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgZm9yIGEgY2xpZW50IHRvIHNlbmQgZGF0YSBpbnNp ZGUNCj4gPiA+IHRoZSBTWU4gd2l0aG91dCBlbmFibGluZyBURk8uIE9uIFdpbmRvd3MsIHRoZSBB UEkgc2VlbXMgdG8gZm9yY2UgdGhlDQo+ID4gPiB1dGlsaXNhdGlvbiBvZiBURk8gd2hlbiB0aGVy ZSBpcyBkYXRhIGluIHRoZSBTWU4uIEFzIGluZGljYXRlZA0KPiA+ID4gZWFybGllciwgUkZDNzkz IGRvZXMgbm90IG1hbmRhdGUgdGhlIHByZXNlbmNlIG9mIHRoZSBURk8gdG8gcGxhY2UgZGF0YQ0K PiBpbnNpZGUgdGhlIFNZTi4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gVGhlIGFwcHJvYWNoIHdl IGFyZSBwcm9wb3NpbmcgaGFzIHRoZSBiZW5lZml0cyBvZiBSRkM3NDEzIGJ1dA0KPiA+ID4gPiA+ PiB3aXRob3V0DQo+ID4gPiBpdHMgZHJhd2JhY2tzLiBNb3Jlb3ZlciwgZ2l2ZW4gdGhhdCBSRkM3 NDEzIGlzIEV4cGVyaW1lbnRhbCwgd2UNCj4gPiA+IGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMg YSBoYXJtIGlmIHdlIHByb2NlZWQgd2l0aCB0aGUgYXBwcm9hY2gNCj4gPiA+IDAtcnR0IGNvbnZl cnQgcHJvdG9jb2wgd2hpbGUgdGhlIElFVEYgY2FuIGZ1cnRoZXIgdHdlYWsgYW5kIGFkanVzdA0K PiA+ID4gdGhlIGFwcGxpY2FiaWxpdHkgc2NvcGUgb2YgUkZDNzQxMy4gRm9yIGV4YW1wbGUsIGFu IHVwZGF0ZSBjYW4gYmUNCj4gPiA+IHByb3Bvc2VkIHRvIFJGQzc0MTMgdG8gY2xhcmlmeSB0aGF0 IHNwZWNpYWxpemVkIGFwcGxpY2F0aW9uLWxldmVsDQo+ID4gPiBwcm90b2NvbHMgY291bGQgcGxh Y2UgY29va2llIGluZm9ybWF0aW9uIGluIHRoZWlyIHBheWxvYWQgYW5kIHRodXMgbm90DQo+IHVz ZSB0aGUgVEZPIG9wdGlvbi4NCj4gPiA+ID4gPiBKdXN0IHRvIGNvbmZpcm06IHlvdSBtZWFuIGFu IEFQSSB0aGF0IGxldCBhcHBsaWNhdGlvbiBzZXRzIHRoZQ0KPiA+ID4gPiA+IFRGTyBjb29raWUg KG9uIGVpdGhlciBzZXJ2ZXIgYW5kIGNsaWVudCk/DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ IE5vLCB3ZSBzdWdnZXN0IHRvIGxldCBzcGVjaWZpYyBhcHBsaWNhdGlvbnMgdXNlIGRhdGEgaW4g dGhlIFNZTg0KPiA+ID4gPiB3aXRob3V0DQo+ID4gPiB1c2luZyB0aGUgVEZPIGNvb2tpZS4gVGhv c2UgYXBwbGljYXRpb25zIGNhbiBtYW5hZ2UgdGhlaXIgY29va2llDQo+ID4gPiBpbnNpZGUgdGhl IFNZTiBwYXlsb2FkIGlmIG5lZWRlZC4gSW5zdGVhZCBvZiBoYXZpbmcgVEZPIGNvb2tpZXMgdGhh dA0KPiA+ID4gYXJlIG1hbmFnZWQgYnkgdGhlIFRDUCBzdGFjayBhbmQgaGF2ZSBsaW1pdGVkIHNp emUsIHRob3NlDQo+ID4gPiBzcGVjaWFsaXNlZCBwcm90b2NvbHMgd291bGQgdXNlIGFwcGxpY2F0 aW9uLWxldmVsIGNvb2tpZXMgd2hpY2ggY2FuDQo+ID4gPiBiZSBsb25nZXIgYW5kIGFyZSBtYW5h Z2VkIGJ5IHRoZXNlIGFwcGxpY2F0aW9uIHByb3RvY29scy4NCj4gPiA+IEkgc2VlLiB0aG91Z2gg SSBzdXBwb3NlIHRoaXMgcmVxdWlyZXMgY2hhbmdpbmcgUkZDNzkzIG9mIG5vdA0KPiA+ID4gdXBs b2FkaW5nIHRoZSBkYXRhIHRvIGFwcGxpY2F0aW9uIHVudGlsIDNXSFMgY29tcGxldGVzLg0KPiA+ ID4NCj4gPg0KPiA+IFtNZWRdIFRoYXQgY29uc3RyYWludCBjYW4gYmUgcmVsYXhlZCBmb2xsb3dp bmcgYSByYXRpb25hbGUgc2ltaWxhciB0bw0KPiB0aGUgb25lIGluIFJGQzc0MTMuDQo+ID4NCj4g PiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IGEgY2hhbmdlIHRvIFJGQzc5MyB3 b3VsZCBiZSByZXF1aXJlZA0KPiBoZXJlIGJ1dCBub3QgZm9yIFJGQzc0MTM/DQo+IEl0J3MgYW4g aW50ZXJlc3RpbmcgcXVlc3Rpb24gLQ0KPiANCj4gUkZDNzkzIGxvbmcgYWxsb3dzIGRhdGEtaW4t U1lOIGJ1dCByZXF1aXJlcyBkYXRhIHRvIGJlIHBvc3RlZCBhZnRlcg0KPiBoYW5kc2hha2UuIFJG Qzc0MTMgcmVsYXhlcyB0aGF0IGJ1dCBhbHNvIHJlcXVpcmVzIGEgY29va2llLg0KPiANCj4gU28g aWYgd2UgdGhpbmsgdGhpcyBpcyBhbiAiZXh0ZW5zaW9uIiB0byBURk8sIHRoZW4gcGVyaGFwcyBl eHRlbmRzDQo+IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8gcGVyc29uYWxseSBJIGRvIHRo aW5rIHRoYXQgbWFrZXMgc2Vuc2UuDQo+IElNTyBURk8gaW1wbGVtZW50YXRpb24gcHJvdmlkZXMg YSBnZW5lcmljIHdheSB0byBkbyBkYXRhLWluLVNZTi4NCj4gQXBwbGljYXRpb24gY2FuIHVzZSB3 aGF0ZXZlciB0aGV5IHByZWZlciB0byBwcm90ZWN0IG9yIG9wdGltaXplIGRhdGEtaW4tDQo+IFNZ Ti4gVEZPIGNvb2tpZSBpcyBqdXN0IGEgZGVmYXVsdCBzaW1wbGUgbWVjaGFuaXNtIGZvciBhcHBs aWNhdGlvbiB3aG8NCj4gZmluZHMgdGhhdCBhY2NlcHRhYmxlLg0KPiANCj4gPg0KPiA+ID4gPg0K PiA+ID4gPiA+IG90aGVyd2lzZSBvYnZpb3VzbHkgYXBwbGljYXRpb24gY2FuIHBsYWNlIGFueSBk YXRhIGluIHRoZWlyIFRDUA0KPiA+ID4gcGF5bG9hZCBmb3IgaXRzDQo+ID4gPiA+ID4gcHVycG9z ZXMuDQo+ID4gPiA+DQo+ID4gPiA+IFRoaXMgaXMgd2hhdCB3ZSBwcm9wb3NlZCBpbiBQcmFndWUs IGkuZS4gdXNpbmcgZGF0YSBpbiB0aGUgVENQIFNZTg0KPiA+ID4gd2l0aG91dCB0aGUgVEZPIG9w dGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT2xpdmllcg0KPiA+ID4gPiAtLQ0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBEaXNjbGFpbWVyOg0KPiA+ID4gPiBodHRwczovL25hbTA2 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkYNCj4g PiA+ID4gd3d3LnRlc3NhcmVzLm5ldCUyRm1haWwtZGlzY2xhaW1lciUyRiZhbXA7ZGF0YT0wMiU3 QzAxJTdDcHJhdmIlNDBtDQo+ID4gPiA+IGljcm9zb2Z0LmNvbSU3QzUyZjc2ZDZiNDg1MjRlYTMz ZGZjMDhkNmUwNThiZGE4JTdDNzJmOTg4YmY4NmYxNDFhZg0KPiA+ID4gPiA5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY5NDMwNjkwODE2MzY3ODAmYW1wO3NkYXRhPWh4a2ZqOGJ5SU0NCj4g PiA+ID4gVHhoMlV3UUJqeiUyQm9QOG9CdzMlMkZSaVlNR0czRU1Fb3JRNCUzRCZhbXA7cmVzZXJ2 ZWQ9MA0KPiA+ID4gPiA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTINCj4gPiA+ID4gRnd3dy50ZXNzYXJlcy5uZXQlMkZtYWls LWRpc2NsYWltZXIlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwDQo+ID4gPiA+IG1pY3Jv c29mdC5jb20lN0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJmODZm MTQxYQ0KPiA+ID4gPiBmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTQzMDY5MDgxNjM2 NzgwJmFtcDtzZGF0YT1oeGtmajhieUkNCj4gPiA+ID4gTVR4aDJVd1FCanolMkJvUDhvQnczJTJG UmlZTUdHM0VNRW9yUTQlM0QmYW1wO3Jlc2VydmVkPTA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4g Pg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiA+IHRjcG0gbWFpbGluZyBsaXN0DQo+ID4gPiB0Y3BtQGlldGYub3JnDQo+ID4gPiBodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3dw0KPiA+ID4gdy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1w O2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWkNCj4gPiA+IGNyb3NvZnQuY29tJTdDNTJmNzZkNmI0 ODUyNGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhDQo+ID4gPiBiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NDMwNjkwODE2MzY3ODAmYW1wO3NkYXRhPTFscnJNSDky akhMaDVkcQ0KPiA+ID4gVTRxMzN5SyUyRktnMEx2WEpLR1IzZ2xjbmJBZXI4JTNEJmFtcDtyZXNl cnZlZD0wDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmDQo+IC5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lDQo+IDdDNTJmNzZkNmI0ODUyNGVhMzNkZmMwOGQ2 ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElDQo+IDdDMCU3 QzYzNjk0MzA2OTA4MTYzNjc4MCZhbXA7c2RhdGE9MWxyck1IOTJqSExoNWRxVTRxMzN5SyUyRktn MEx2WEpLR1IzZ2xjDQo+IG5iQWVyOCUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From nobody Tue May 28 08:22:31 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CFA1200D6 for ; Tue, 28 May 2019 08:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 95YGYvlAQ2YQ for ; Tue, 28 May 2019 08:22:25 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770112.outbound.protection.outlook.com [40.107.77.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4DA12026A for ; Tue, 28 May 2019 08:22:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=htsWFzUZbCxq6D9LifTCUivrNFuCVjytN/qVDlTkp4yLxNdFrKnYfVFQATLBzISr7IQ+u8A64qqi7LuJq5FxHX7USFu0jjMQ566YtrCLFwVBjTrJ3NnTrzTk+qcS1TEbEBmoYUSiIkr1+cR++heceeMeV0ANwiZ0/jh5XgJrA18= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xqytaQkgKkt4p/PPTLb+JtRsZtsRMlAx0JGfveFgXA=; b=HO+xWH9WvHpik/qVu6zaAVMh700l8cvJqRAS8tXHkPc4DSk65PLNpPBNm4idnMPzY586t+o5JlMTd0VeEdLcaYq9LCa3wmXveQPJCoVWu+KwsckNa48C5r42MYQ8T5S7Cjt+r/akSaW7PrfrFXhG3sU1jYHiofpxSvwMxvbNIFU= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4xqytaQkgKkt4p/PPTLb+JtRsZtsRMlAx0JGfveFgXA=; b=gI+tecUlOXSCtRhe7Db03IuOf+q/8Ic99Hz7183iC3Kj/j5fwmJEEp2sOYY8jHBQAjc4YofxpuTaw80PIhkg+BzKi/6TYXGTHp0JxWQKbmY33+UNE7Lrhx+MSEa6/b60nI+NzC3Zp8zew8sg4+ncKBU4qMlj38vRJfkIAQmIPeE= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (2603:10b6:302:a::13) by MW2PR2101MB1114.namprd21.prod.outlook.com (2603:10b6:302:a::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.3; Tue, 28 May 2019 15:22:23 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2%4]) with mapi id 15.20.1965.003; Tue, 28 May 2019 15:22:23 +0000 From: Praveen Balasubramanian To: "mohamed.boucadair@orange.com" , Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVDy6HMMq1d9rUjkC05hHsqCIciaZ0Q0IAgAE1qACAA3SNAIABd2QegAAbJQCABGLcAIABzvvg Date: Tue, 28 May 2019 15:22:22 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-28T15:22:21.0352247Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=e325bc2f-623d-4ab0-b0dc-be9b5008f0a5; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:b:9156:2223:14b:e0d9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14149254-ccbd-47d9-39f1-08d6e3804877 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1114; x-ms-traffictypediagnostic: MW2PR2101MB1114: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(136003)(396003)(346002)(39860400002)(13464003)(199004)(189003)(52536014)(5660300002)(6116002)(2906002)(316002)(2501003)(305945005)(33656002)(186003)(71190400001)(71200400001)(46003)(7736002)(73956011)(66946007)(22452003)(76116006)(66446008)(66476007)(66556008)(64756008)(11346002)(476003)(486006)(446003)(14444005)(256004)(6306002)(10290500003)(9686003)(102836004)(966005)(7696005)(52396003)(25786009)(6506007)(53546011)(478600001)(10090500001)(229853002)(6436002)(74316002)(110136005)(81166006)(81156014)(8676002)(8936002)(68736007)(8990500004)(53936002)(14454004)(4326008)(55016002)(76176011)(86612001)(86362001)(6246003)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1114; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: S49HAiwKZefLpEhLwjk7itf+s34CDvGdUPmuGNMEagOUqN7GtrTXrh24Rc0Jq91MQPwa1HCO6kVIHXkTNxfkTGia1kATr6YNLowQS6V87yfCOWajESngM2NDFvkY7IwjPFcESo1iJkKU+lqYwwArTPLXejTyAnYqxBv+dvX5SYA5cUcZsMjLjGv2pCZWcdU2TOE5S/iZbKV5NOiQoLeKk94+hiWO8fjpLkK3faLW9FYL7+C9y1p3cabmRbyVlUq2FXGtJOc8i7wDJ4ooz4JtR5Pf633KPNX9KJSsP7w8jcyy1QHm5Vb34Ids/4XesCz1h/xAUGVForhf++rz0CbJENeHhiFNS7bI63K3zI1sRbknzd27GY+y58Wv0QaY6hxPFVNM/xmmSzQsIS/JkmJjJYfvto88pSdKjcR1wRYd314= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14149254-ccbd-47d9-39f1-08d6e3804877 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 15:22:22.9086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1114 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 15:22:30 -0000 VEZPIGlzIGEgbmV3IFJGQyBhbmQgc2VydmVyIGlzIG9wdGluZyBpbiB0byByZWNlaXZlIGVhcmx5 IGRhdGEgd2hpY2ggaW1wbGllcyBiZWluZyBhd2FyZSBvZiB0aGUgcmVwbGF5IGlzc3Vlcy4gSWYg dGhlIFRGTyBzdGF0ZSBtYWNoaW5lIHN1Y2NlZWRzICh2YWxpZCBjb29raWUgd2l0aCBkYXRhIGlu IFNZTikgb25seSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBjYW4gcmV0cmlldmUgZGF0YSBldmVuIGJl Zm9yZSBoYW5kc2hha2UgY29tcGxldGVzLg0KDQpXaXRob3V0IFRGTywgdGhlIHN0YW5kYXJkIHNv Y2tldHMgQVBJIGRvZXMgbm90IGFsbG93IGFuIGFwcGxpY2F0aW9uIHRvIHJlY2VpdmUgZGF0YSBi ZWZvcmUgM1dIUyBjb21wbGV0ZXMsIGV2ZW4gaWYgZGF0YSBpcyByZWNlaXZlZCBpbiB0aGUgU1lO LiBXaGF0IHlvdSBzZWVtIHRvIGJlIGFza2luZyBmb3IgaXMgYSBtb2RpZmljYXRpb24gb2YgNzkz IGFuZC9vciBBUEkgYmVoYXZpb3Igd2hpY2ggd2lsbCBuZWVkIGEgbmV3IG9wdC1pbiBzb2NrZXQg b3B0aW9uIGZvciBwcmVzZXJ2aW5nIGNvbXBhdCBmb3IgZXhpc3RpbmcgYXBwbGljYXRpb25zLiAN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IA0KU2VudDogTW9uZGF5LCBN YXkgMjcsIDIwMTkgNDozOCBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt aWNyb3NvZnQuY29tPjsgWXVjaHVuZyBDaGVuZyA8eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5p ZXRmLm9yZz4NCkNjOiB0Y3BtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3RjcG1dIFByb2dyZXNz aW5nIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQoNCkhpIFByYXZlZW4sDQoNClBsZWFzZSBz ZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIFttYWlsdG86cHJhdmJAbWljcm9z b2Z0LmNvbV0gRW52b3nDqcKgOiANCj4gdmVuZHJlZGkgMjQgbWFpIDIwMTkgMTg6NDUgw4DCoDog WXVjaHVuZyBDaGVuZzsgQk9VQ0FEQUlSIE1vaGFtZWQgDQo+IFRHSS9PTE4gQ2PCoDogdGNwbUBp ZXRmLm9yZyBFeHRlbnNpb25zIE9iamV0wqA6IFJFOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgDQo+IGRy YWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+IA0KPiBBZ3JlZWQgYW5kIEkgaGFkIHJhaXNlZCB0 aGUgc2FtZSBxdWVzdGlvbiBiZWZvcmU6ICIgSXNuJ3QgcGFzc2luZyBkYXRhIA0KPiBpbiB0aGUg U1lOIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBiZWZvcmUgM1dIUyBpbnZhbGlkIHBlciBSRkMgNzkz Pw0KDQpbTWVkXSBUaGlzIGlzIHNpbWlsYXIgdG8gd2hhdCBURk8gZG9lcy4gQm90aCAoaS5lLiwg VEZPIGFuZCB0aGUgYXBwbGljYXRpb24tYmFzZWQgY29va2llKSBhcmUgcmVsYXhpbmcgdGhhdCBj b25zdHJhaW50IGZyb20gNzkzLiANCg0KIEhvdyBpcyB0aGUNCj4gY29udmVydGVyIChUKSBleHRy YWN0aW5nIHRoZSBzZXJ2ZXIgSVAgYWRkcmVzcyBhbmQgcG9ydCBmcm9tIHRoZSBTWU4gDQo+IHBh eWxvYWQ/IElzIGl0IHJ1bm5pbmcgc29tZSBjdXN0b20gVENQIGltcGxlbWVudGF0aW9uIHRoYXQg dmlvbGF0ZXMgNzkzPyINCj4gNzQxMyBhbGxvd3MgbmlsLWNvb2tpZSBhbmQgYXBwIGNhbiBlbmNv ZGUgY29va2llIGFuZCBkYXRhIGluIFNZTiBpZiBpdCANCj4gd2FudHMuIElmIFRGTyBvcHRpb24g aXMgbm90IHVzZWQgYXQgYWxsIHRoZW4gaXQgd291bGQgYmUgYSBjaGFuZ2UgdG8gDQo+IDc5MyBh bmQgbm90IDc0MTMuDQoNCltNZWRdIFRoaXMgaXMgd2hhdCB0aGUgaW5pdGlhbCBtZXNzYWdlIGZy b20gT2xpdmllciB0cmllZCB0byBhZGRyZXNzLiBUaGUgaXNzdWUgaXMgd2hhdCBpcyB0aGUgcG9p bnQgaW4gZW5jbG9zaW5nIHRoZSBURk8gb3B0aW9uIGlmIHRoZSBjb29raWUgaXMgc3VwcGxpZWQg YnkgdGhlIGFwcGxpY2F0aW9uPyBUaGUgc2FtZSBwcm90ZWN0aW9uIGxldmVsIGNhbiBiZSBwcm92 aWRlZCB3aXRoIHRoZSBhcHBsaWNhdGlvbi1zdXBwbGllZCBjb29raWUgd2l0aG91dCByZXF1aXJp bmcgdG8gaW5zZXJ0IHRoZSBURk8gb3B0aW9uLiAgDQoNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIFl1Y2h1bmcgQ2hlbmcNCj4gU2VudDogRnJpZGF5LCBNYXkgMjQsIDIwMTkgODowMSBBTQ0K PiBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBDYzogdGNwbUBpZXRmLm9yZyBF eHRlbnNpb25zIDx0Y3BtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFByb2dyZXNz aW5nIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+IA0KPiBPbiBUaHUsIE1heSAyMywgMjAx OSBhdCAxMTozNCBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiBIaSBZdWNodW5nLA0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4NCj4gPiBD aGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiA+ID4gRGUgOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0 IGRlIFl1Y2h1bmcgDQo+ID4gPiBDaGVuZyBFbnZvecOpIDogamV1ZGkgMjMgbWFpIDIwMTkgMTg6 Mzggw4AgOiBPbGl2aWVyIEJvbmF2ZW50dXJlIENjIDoNCj4gPiA+IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9ucyBPYmpldCA6IFJlOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgDQo+ID4gPiBkcmFmdC1pZXRm LXRjcG0tY29udmVydGVycw0KPiA+ID4NCj4gPiA+IE9uIFR1ZSwgTWF5IDIxLCAyMDE5IGF0IDQ6 NTIgQU0gT2xpdmllciBCb25hdmVudHVyZSANCj4gPiA+IDxvbGl2aWVyLmJvbmF2ZW50dXJlQHRl c3NhcmVzLm5ldD4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IFl1Y2h1bmcsDQo+ID4gPiA+DQo+ ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFdlIGJlbGlldmUgdGhhdCBhIHNwZWNpYWxpc2VkIFRDUCBh cHBsaWNhdGlvbiBzaG91bGQgYmUgDQo+ID4gPiA+ID4+IGFsbG93ZWQgdG8NCj4gPiA+IHVzZSBp dHMgb3duIGNvb2tpZSBpbnNpZGUgdGhlIHBheWxvYWQgaW5zdGVhZCBvZiByZWx5aW5nIG9uIHRo ZSANCj4gPiA+IFRDUCBoZWFkZXIgdG8gdXNlIGZhc3Qgb3Blbi4gVGhlIDAtUlRUIGNvbnZlcnQg cHJvdG9jb2wgaXMgb25lIA0KPiA+ID4gZXhhbXBsZSwgYnV0IHRoZXJlIGNvdWxkIGJlIG90aGVy cy4gTG9va2luZyBhdCBvdGhlciBhcHBsaWNhdGlvbiANCj4gPiA+IGxheWVyIHByb3RvY29scywg SSBub3RpY2VkIHRoYXQgVExTMS4zIChyZmM4NDQ2KSBhbHNvIGluY2x1ZGVzIGEgDQo+ID4gPiBj b29raWUgd2hpY2ggaXMgbWFpbmx5IGRlc2lnbmVkIGVuYWJsZSBzZXJ2ZXJzIHRvIGdldCBhIA0K PiA+ID4gY29uZmlybWF0aW9uIG9mIHRoZSByZWFjaGFiaWxpdHkgb2YgdGhlIGNsaWVudCBJUCBh ZGRyZXNzZXMgZm9yIA0KPiA+ID4gRFRMUywgYnV0IHRoZSBzYW1lIGFwcHJvYWNoIGNvdWxkIGJl IHVzZWQgd2hlbiBUTFMgc2VuZHMgaXRzIA0KPiA+ID4gaW5pdGlhbCBkYXRhIGluIHRoZSBTWU4g YXMNCj4gd2VsbC4NCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gQW5vdGhlciBwb2ludCB0aGF0IHNo b3VsZCBiZSBjbGFyaWZpZWQgaW4gUkZDNzQxMyBhcmUgaG93IA0KPiA+ID4gPiA+PiBtaWRkbGVi b3hlcw0KPiA+ID4gc2hvdWxkIGhhbmRsZSBTWU4gcGFja2V0cyBjb250YWluaW5nIGEgbm9uLXpl cm8gcGF5bG9hZC4gQWNjb3JkaW5nIA0KPiA+ID4gdG8gUkZDNzkzLCBzdWNoIHBhY2tldHMgYXJl IHZhbGlkIFRDUCBwYWNrZXRzLiBUaGUgVEZPIG9wdGlvbiwgDQo+ID4gPiBkZWZpbmVkIGluDQo+ ID4gPiBSRkM3MzE0IGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIGFuIGlu ZGljYXRpb24gdGhhdCANCj4gPiA+IGlzIHJlcXVpcmVkIHRvIOKAnGF1dGhvcmlzZeKAnSB0aGUg dXRpbGlzYXRpb24gb2YgcGF5bG9hZCBpbnNpZGUgYSBTWU4NCj4gcGFja2V0Lg0KPiA+ID4gRHVy aW5nIHRoZSBQcmFndWUgbWVldGluZywgQ2hyaXN0b3BoIFBhYXNjaCBtZW50aW9uZWQgYXQgdGhl IG1pa2UgDQo+ID4gPiB0aGF0IHRoZXkgaGF2ZSBvbmUgYXBwbGljYXRpb24gdGhhdCB1c2VzIGRh dGEgaW5zaWRlIHRoZSBTWU4gYW5kIA0KPiA+ID4gdGhlaXIgbWVhc3VyZW1lbnRzIGluZGljYXRl IHRoYXQgc2VuZGluZyB0aGlzIFNZTiB3aXRob3V0IHRoZSBURk8gDQo+ID4gPiBvcHRpb24gZW5h YmxlcyBpdCB0byBwYXNzIHRocm91Z2ggbW9yZSBtaWRkbGVib3hlcyB0aGFuIHdoZW4gdGhlIA0K PiA+ID4gc2FtZSBTWU4gY29udGFpbnMgdGhlIFRGTyBvcHRpb24uDQo+ID4gPiA+ID4+DQo+ID4g PiA+ID4+IEFub3RoZXIgcG9pbnQgaXMgdGhlIHNvY2tldCBBUEkuIEN1cnJlbnRseSwgTGludXgg YW5kIE1hY09TIA0KPiA+ID4gPiA+PiBkZWNvdXBsZQ0KPiA+ID4gdGhlIHRyYW5zbWlzc2lvbiBv ZiBkYXRhIGluc2lkZSB0aGUgU1lOIGZyb20gdGhlIHV0aWxpc2F0aW9uIG9mIA0KPiA+ID4gdGhl IFRGTyBvcHRpb24uIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgZm9yIGEgY2xpZW50IHRvIHNlbmQg ZGF0YSANCj4gPiA+IGluc2lkZSB0aGUgU1lOIHdpdGhvdXQgZW5hYmxpbmcgVEZPLiBPbiBXaW5k b3dzLCB0aGUgQVBJIHNlZW1zIHRvIA0KPiA+ID4gZm9yY2UgdGhlIHV0aWxpc2F0aW9uIG9mIFRG TyB3aGVuIHRoZXJlIGlzIGRhdGEgaW4gdGhlIFNZTi4gQXMgDQo+ID4gPiBpbmRpY2F0ZWQgZWFy bGllciwgUkZDNzkzIGRvZXMgbm90IG1hbmRhdGUgdGhlIHByZXNlbmNlIG9mIHRoZSBURk8gDQo+ ID4gPiB0byBwbGFjZSBkYXRhDQo+IGluc2lkZSB0aGUgU1lOLg0KPiA+ID4gPiA+Pg0KPiA+ID4g PiA+PiBUaGUgYXBwcm9hY2ggd2UgYXJlIHByb3Bvc2luZyBoYXMgdGhlIGJlbmVmaXRzIG9mIFJG Qzc0MTMgYnV0IA0KPiA+ID4gPiA+PiB3aXRob3V0DQo+ID4gPiBpdHMgZHJhd2JhY2tzLiBNb3Jl b3ZlciwgZ2l2ZW4gdGhhdCBSRkM3NDEzIGlzIEV4cGVyaW1lbnRhbCwgd2UgDQo+ID4gPiBkb24n dCB0aGluayB0aGF0IHRoZXJlIGlzIGEgaGFybSBpZiB3ZSBwcm9jZWVkIHdpdGggdGhlIGFwcHJv YWNoIA0KPiA+ID4gMC1ydHQgY29udmVydCBwcm90b2NvbCB3aGlsZSB0aGUgSUVURiBjYW4gZnVy dGhlciB0d2VhayBhbmQgYWRqdXN0IA0KPiA+ID4gdGhlIGFwcGxpY2FiaWxpdHkgc2NvcGUgb2Yg UkZDNzQxMy4gRm9yIGV4YW1wbGUsIGFuIHVwZGF0ZSBjYW4gYmUgDQo+ID4gPiBwcm9wb3NlZCB0 byBSRkM3NDEzIHRvIGNsYXJpZnkgdGhhdCBzcGVjaWFsaXplZCBhcHBsaWNhdGlvbi1sZXZlbCAN Cj4gPiA+IHByb3RvY29scyBjb3VsZCBwbGFjZSBjb29raWUgaW5mb3JtYXRpb24gaW4gdGhlaXIg cGF5bG9hZCBhbmQgdGh1cyANCj4gPiA+IG5vdA0KPiB1c2UgdGhlIFRGTyBvcHRpb24uDQo+ID4g PiA+ID4gSnVzdCB0byBjb25maXJtOiB5b3UgbWVhbiBhbiBBUEkgdGhhdCBsZXQgYXBwbGljYXRp b24gc2V0cyB0aGUgDQo+ID4gPiA+ID4gVEZPIGNvb2tpZSAob24gZWl0aGVyIHNlcnZlciBhbmQg Y2xpZW50KT8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gTm8sIHdlIHN1Z2dlc3QgdG8gbGV0 IHNwZWNpZmljIGFwcGxpY2F0aW9ucyB1c2UgZGF0YSBpbiB0aGUgU1lOIA0KPiA+ID4gPiB3aXRo b3V0DQo+ID4gPiB1c2luZyB0aGUgVEZPIGNvb2tpZS4gVGhvc2UgYXBwbGljYXRpb25zIGNhbiBt YW5hZ2UgdGhlaXIgY29va2llIA0KPiA+ID4gaW5zaWRlIHRoZSBTWU4gcGF5bG9hZCBpZiBuZWVk ZWQuIEluc3RlYWQgb2YgaGF2aW5nIFRGTyBjb29raWVzIA0KPiA+ID4gdGhhdCBhcmUgbWFuYWdl ZCBieSB0aGUgVENQIHN0YWNrIGFuZCBoYXZlIGxpbWl0ZWQgc2l6ZSwgdGhvc2UgDQo+ID4gPiBz cGVjaWFsaXNlZCBwcm90b2NvbHMgd291bGQgdXNlIGFwcGxpY2F0aW9uLWxldmVsIGNvb2tpZXMg d2hpY2ggDQo+ID4gPiBjYW4gYmUgbG9uZ2VyIGFuZCBhcmUgbWFuYWdlZCBieSB0aGVzZSBhcHBs aWNhdGlvbiBwcm90b2NvbHMuDQo+ID4gPiBJIHNlZS4gdGhvdWdoIEkgc3VwcG9zZSB0aGlzIHJl cXVpcmVzIGNoYW5naW5nIFJGQzc5MyBvZiBub3QgDQo+ID4gPiB1cGxvYWRpbmcgdGhlIGRhdGEg dG8gYXBwbGljYXRpb24gdW50aWwgM1dIUyBjb21wbGV0ZXMuDQo+ID4gPg0KPiA+DQo+ID4gW01l ZF0gVGhhdCBjb25zdHJhaW50IGNhbiBiZSByZWxheGVkIGZvbGxvd2luZyBhIHJhdGlvbmFsZSBz aW1pbGFyIA0KPiA+IHRvDQo+IHRoZSBvbmUgaW4gUkZDNzQxMy4NCj4gPg0KPiA+IElzIHRoZXJl IGFueSBwYXJ0aWN1bGFyIHJlYXNvbiB3aHkgYSBjaGFuZ2UgdG8gUkZDNzkzIHdvdWxkIGJlIA0K PiA+IHJlcXVpcmVkDQo+IGhlcmUgYnV0IG5vdCBmb3IgUkZDNzQxMz8NCj4gSXQncyBhbiBpbnRl cmVzdGluZyBxdWVzdGlvbiAtDQo+IA0KPiBSRkM3OTMgbG9uZyBhbGxvd3MgZGF0YS1pbi1TWU4g YnV0IHJlcXVpcmVzIGRhdGEgdG8gYmUgcG9zdGVkIGFmdGVyIA0KPiBoYW5kc2hha2UuIFJGQzc0 MTMgcmVsYXhlcyB0aGF0IGJ1dCBhbHNvIHJlcXVpcmVzIGEgY29va2llLg0KPiANCj4gU28gaWYg d2UgdGhpbmsgdGhpcyBpcyBhbiAiZXh0ZW5zaW9uIiB0byBURk8sIHRoZW4gcGVyaGFwcyBleHRl bmRzDQo+IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8gcGVyc29uYWxseSBJIGRvIHRoaW5r IHRoYXQgbWFrZXMgc2Vuc2UuDQo+IElNTyBURk8gaW1wbGVtZW50YXRpb24gcHJvdmlkZXMgYSBn ZW5lcmljIHdheSB0byBkbyBkYXRhLWluLVNZTi4NCj4gQXBwbGljYXRpb24gY2FuIHVzZSB3aGF0 ZXZlciB0aGV5IHByZWZlciB0byBwcm90ZWN0IG9yIG9wdGltaXplIA0KPiBkYXRhLWluLSBTWU4u IFRGTyBjb29raWUgaXMganVzdCBhIGRlZmF1bHQgc2ltcGxlIG1lY2hhbmlzbSBmb3IgDQo+IGFw cGxpY2F0aW9uIHdobyBmaW5kcyB0aGF0IGFjY2VwdGFibGUuDQo+IA0KPiA+DQo+ID4gPiA+DQo+ ID4gPiA+ID4gb3RoZXJ3aXNlIG9idmlvdXNseSBhcHBsaWNhdGlvbiBjYW4gcGxhY2UgYW55IGRh dGEgaW4gdGhlaXIgDQo+ID4gPiA+ID4gVENQDQo+ID4gPiBwYXlsb2FkIGZvciBpdHMNCj4gPiA+ ID4gPiBwdXJwb3Nlcy4NCj4gPiA+ID4NCj4gPiA+ID4gVGhpcyBpcyB3aGF0IHdlIHByb3Bvc2Vk IGluIFByYWd1ZSwgaS5lLiB1c2luZyBkYXRhIGluIHRoZSBUQ1AgDQo+ID4gPiA+IFNZTg0KPiA+ ID4gd2l0aG91dCB0aGUgVEZPIG9wdGlvbi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT2xp dmllcg0KPiA+ID4gPiAtLQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBEaXNjbGFpbWVyOg0K PiA+ID4gPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlDQo+ID4gPiA+IDJGIA0KPiA+ID4gPiBodHRwczovL25hbTA2LnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9d3d3LnRlc3NhcmVzDQo+ID4gPiA+IC5u ZXQmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2Q2NjQxMTU3NmRj YzRlOWMNCj4gPiA+ID4gMmM5MzA4ZDZlMjk3YzE4YyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2Mw0KPiA+ID4gPiA2OTQ1NTM4NzQ2OTcyNzU0JmFtcDtzZGF0 YT1aSGZ0NHlkNzlSMEltOEkyN0tNOWRFVENZZ0VocGMzemw5akp3DQo+ID4gPiA+IHZ4WVpXYyUz RCZhbXA7cmVzZXJ2ZWQ9MCUyRm1haWwtZGlzY2xhaW1lciUyRiZhbXA7ZGF0YT0wMiU3QzAxJTcN Cj4gPiA+ID4gQ3ByYXZiJTQwbSANCj4gPiA+ID4gaWNyb3NvZnQuY29tJTdDNTJmNzZkNmI0ODUy NGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MQ0KPiA+ID4gPiBhZiANCj4gPiA+ ID4gOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTQzMDY5MDgxNjM2NzgwJmFtcDtzZGF0 YT1oeGtmajhieQ0KPiA+ID4gPiBJTQ0KPiA+ID4gPiBUeGgyVXdRQmp6JTJCb1A4b0J3MyUyRlJp WU1HRzNFTUVvclE0JTNEJmFtcDtyZXNlcnZlZD0wDQo+ID4gPiA+IDxodHRwczovL25hbTA2LnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYNCj4gPiA+ID4g JTINCj4gPiA+ID4gRnd3dy50ZXNzYXJlcy5uZXQlMkZtYWlsLWRpc2NsYWltZXIlMkYmYW1wO2Rh dGE9MDIlN0MwMSU3Q3ByYXZiJQ0KPiA+ID4gPiA0MCANCj4gPiA+ID4gbWljcm9zb2Z0LmNvbSU3 QzUyZjc2ZDZiNDg1MjRlYTMzZGZjMDhkNmUwNThiZGE4JTdDNzJmOTg4YmY4NmYxNA0KPiA+ID4g PiAxYSANCj4gPiA+ID4gZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0MzA2OTA4MTYz Njc4MCZhbXA7c2RhdGE9aHhrZmo4Yg0KPiA+ID4gPiB5SSBNVHhoMlV3UUJqeiUyQm9QOG9CdzMl MkZSaVlNR0czRU1Fb3JRNCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiA+IGh0 dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRg0KPiA+ID4gd3cgDQo+ID4gPiB3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDANCj4gPiA+IG1pIA0KPiA+ID4gY3Jv c29mdC5jb20lN0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJmODZm MTQxYWY5DQo+ID4gPiAxYSANCj4gPiA+IGIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0MzA2 OTA4MTYzNjc4MCZhbXA7c2RhdGE9MWxyck1IOTJqSExoNQ0KPiA+ID4gZHENCj4gPiA+IFU0cTMz eUslMkZLZzBMdlhKS0dSM2dsY25iQWVyOCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5n IGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+IGlldGYgDQo+IC5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1p Y3Jvc29mdC4NCj4gY29tJSANCj4gN0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JQ0KPiA3QzElIA0KPiA3QzAlN0M2MzY5 NDMwNjkwODE2MzY3ODAmYW1wO3NkYXRhPTFscnJNSDkyakhMaDVkcVU0cTMzeUslMkZLZzBMdlhK S0dSDQo+IDNnbGMNCj4gbmJBZXI4JTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Tue May 28 12:36:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D112120132 for ; Tue, 28 May 2019 12:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TLwU7GWI00bi for ; Tue, 28 May 2019 12:36:17 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 F05D31200B5 for ; Tue, 28 May 2019 12:36:16 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id f8so21562757wrt.1 for ; Tue, 28 May 2019 12:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8fT3HHcoKfrRwAMgBxdDHYO1jpCwk+KQdXbGdnmG32A=; b=V1U7CSH83sIJauiL5XRQ7q8Z+CvpOLXJfGKSUeFd+1V1mNJkss/W/P0wFXpxUR3nOt s/c28yNbO80uAEV20UvKfrZJhhRZLQIyzAzcheLGFKOsCn8EUz5lZkLGSJIy4I7RrMe0 zmtRncYfW2GPff/KIAEKc1sm7CLrtCtZBaXqkoaMKas2HD3ekQTQKftnvdYhAXPg9cgh JySMiWwf6aqEgkzkvuvgw0G9H8KHuJHjrCL73g8zEi+Lv/jXvBYgo/tQ33gMmzVx3Wi6 s4fSbynpZuyEJKSAozgu7kJdbIvvQOt6nhwFnryfMcnBwCcRJk+m7C2nEuxOMrp9lBqr Yfuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8fT3HHcoKfrRwAMgBxdDHYO1jpCwk+KQdXbGdnmG32A=; b=TC49u4Opssg3RjzQE9RzWxRdsJzrz9ETG9Nn3NsESuaOZcXR/3u+abK4FzNKbWu4xO IqFYO+r6uNKMp9mnUnIFrqQvs5EuUI6mOkYrfVXRv9tddVBbnwdhH+yfE8KOPgc0upjm ihIM9muLK0gY7a1OLx/rPFVVctP5ppY/qByyY1/S0pWG/hm1csNUjJDB73nlYlcQUYy9 C26Yj4M7aHvY1BizRbAQL0DbcQrHVgybi0uOE7qQtbtgKVOG52CiFpNgyXg+iYtIDnTG VRw0xEnnItFEo1UCMV9fo7jXsy1HSXY1xdfowtmp+Ug1ZLOXqwMjTLQz15rihRmch7jv fkqQ== X-Gm-Message-State: APjAAAWCv2QZYzx1cTE/LAacHHOcqHn/Zux+tNdhYhQtZC/qmm1I3ABE tW5Sn+pHwCswAaGRckpmnRCWM8WPHOFEhf09aV1VFA== X-Google-Smtp-Source: APXvYqxprhtuAdFhVJ22FoI1KEJ2VaDER+0/hutxezDyvQezfBT9jP3v12cAcyiCFEAVgt2hABWs8Mglmt2pRofc3gk= X-Received: by 2002:adf:dc0c:: with SMTP id t12mr66908107wri.101.1559072174755; Tue, 28 May 2019 12:36:14 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: From: Yuchung Cheng Date: Tue, 28 May 2019 12:35:37 -0700 Message-ID: To: Praveen Balasubramanian Cc: "mohamed.boucadair@orange.com" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 19:36:20 -0000 On Tue, May 28, 2019 at 8:22 AM Praveen Balasubramanian wrote: > > TFO is a new RFC and server is opting in to receive early data which impl= ies being aware of the replay issues. If the TFO state machine succeeds (va= lid cookie with data in SYN) only then the application can retrieve data ev= en before handshake completes. > > Without TFO, the standard sockets API does not allow an application to re= ceive data before 3WHS completes, even if data is received in the SYN. What= you seem to be asking for is a modification of 793 and/or API behavior whi= ch will need a new opt-in socket option for preserving compat for existing = applications. yes that's my sense as well (i.e. this draft requires a change in RFC793). > > > -----Original Message----- > From: mohamed.boucadair@orange.com > Sent: Monday, May 27, 2019 4:38 AM > To: Praveen Balasubramanian ; Yuchung Cheng > Cc: tcpm@ietf.org > Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters > > Hi Praveen, > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Praveen Balasubramanian [mailto:pravb@microsoft.com] Envoy=C3=A9 : > > vendredi 24 mai 2019 18:45 =C3=80 : Yuchung Cheng; BOUCADAIR Mohamed > > TGI/OLN Cc : tcpm@ietf.org Extensions Objet : RE: [tcpm] Progressing > > draft-ietf-tcpm-converters > > > > Agreed and I had raised the same question before: " Isn't passing data > > in the SYN up to the application before 3WHS invalid per RFC 793? > > [Med] This is similar to what TFO does. Both (i.e., TFO and the applicati= on-based cookie) are relaxing that constraint from 793. > > How is the > > converter (T) extracting the server IP address and port from the SYN > > payload? Is it running some custom TCP implementation that violates 793= ?" > > 7413 allows nil-cookie and app can encode cookie and data in SYN if it > > wants. If TFO option is not used at all then it would be a change to > > 793 and not 7413. > > [Med] This is what the initial message from Olivier tried to address. The= issue is what is the point in enclosing the TFO option if the cookie is su= pplied by the application? The same protection level can be provided with t= he application-supplied cookie without requiring to insert the TFO option. > > > > > -----Original Message----- > > From: tcpm On Behalf Of Yuchung Cheng > > Sent: Friday, May 24, 2019 8:01 AM > > To: mohamed.boucadair@orange.com > > Cc: tcpm@ietf.org Extensions > > Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > On Thu, May 23, 2019 at 11:34 PM wrote: > > > > > > Hi Yuchung, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung > > > > Cheng Envoy=C3=A9 : jeudi 23 mai 2019 18:38 =C3=80 : Olivier Bonave= nture Cc : > > > > tcpm@ietf.org Extensions Objet : Re: [tcpm] Progressing > > > > draft-ietf-tcpm-converters > > > > > > > > On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure > > > > wrote: > > > > > > > > > > Yuchung, > > > > > > > > > > >> > > > > > >> We believe that a specialised TCP application should be > > > > > >> allowed to > > > > use its own cookie inside the payload instead of relying on the > > > > TCP header to use fast open. The 0-RTT convert protocol is one > > > > example, but there could be others. Looking at other application > > > > layer protocols, I noticed that TLS1.3 (rfc8446) also includes a > > > > cookie which is mainly designed enable servers to get a > > > > confirmation of the reachability of the client IP addresses for > > > > DTLS, but the same approach could be used when TLS sends its > > > > initial data in the SYN as > > well. > > > > > >> > > > > > >> Another point that should be clarified in RFC7413 are how > > > > > >> middleboxes > > > > should handle SYN packets containing a non-zero payload. According > > > > to RFC793, such packets are valid TCP packets. The TFO option, > > > > defined in > > > > RFC7314 is not and should not be considered as an indication that > > > > is required to =E2=80=9Cauthorise=E2=80=9D the utilisation of paylo= ad inside a SYN > > packet. > > > > During the Prague meeting, Christoph Paasch mentioned at the mike > > > > that they have one application that uses data inside the SYN and > > > > their measurements indicate that sending this SYN without the TFO > > > > option enables it to pass through more middleboxes than when the > > > > same SYN contains the TFO option. > > > > > >> > > > > > >> Another point is the socket API. Currently, Linux and MacOS > > > > > >> decouple > > > > the transmission of data inside the SYN from the utilisation of > > > > the TFO option. This makes it possible for a client to send data > > > > inside the SYN without enabling TFO. On Windows, the API seems to > > > > force the utilisation of TFO when there is data in the SYN. As > > > > indicated earlier, RFC793 does not mandate the presence of the TFO > > > > to place data > > inside the SYN. > > > > > >> > > > > > >> The approach we are proposing has the benefits of RFC7413 but > > > > > >> without > > > > its drawbacks. Moreover, given that RFC7413 is Experimental, we > > > > don't think that there is a harm if we proceed with the approach > > > > 0-rtt convert protocol while the IETF can further tweak and adjust > > > > the applicability scope of RFC7413. For example, an update can be > > > > proposed to RFC7413 to clarify that specialized application-level > > > > protocols could place cookie information in their payload and thus > > > > not > > use the TFO option. > > > > > > Just to confirm: you mean an API that let application sets the > > > > > > TFO cookie (on either server and client)? > > > > > > > > > > > > > > > No, we suggest to let specific applications use data in the SYN > > > > > without > > > > using the TFO cookie. Those applications can manage their cookie > > > > inside the SYN payload if needed. Instead of having TFO cookies > > > > that are managed by the TCP stack and have limited size, those > > > > specialised protocols would use application-level cookies which > > > > can be longer and are managed by these application protocols. > > > > I see. though I suppose this requires changing RFC793 of not > > > > uploading the data to application until 3WHS completes. > > > > > > > > > > [Med] That constraint can be relaxed following a rationale similar > > > to > > the one in RFC7413. > > > > > > Is there any particular reason why a change to RFC793 would be > > > required > > here but not for RFC7413? > > It's an interesting question - > > > > RFC793 long allows data-in-SYN but requires data to be posted after > > handshake. RFC7413 relaxes that but also requires a cookie. > > > > So if we think this is an "extension" to TFO, then perhaps extends > > RFC7413 not changing RFC793? personally I do think that makes sense. > > IMO TFO implementation provides a generic way to do data-in-SYN. > > Application can use whatever they prefer to protect or optimize > > data-in- SYN. TFO cookie is just a default simple mechanism for > > application who finds that acceptable. > > > > > > > > > > > > > > > > otherwise obviously application can place any data in their > > > > > > TCP > > > > payload for its > > > > > > purposes. > > > > > > > > > > This is what we proposed in Prague, i.e. using data in the TCP > > > > > SYN > > > > without the TFO option. > > > > > > > > > > > > > > > Olivier > > > > > -- > > > > > > > > > > > > > > > Disclaimer: > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= % > > > > > 2F > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dwww.tessare= s > > > > > .net&data=3D02%7C01%7Cpravb%40microsoft.com%7Cd66411576dcc4e9= c > > > > > 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > > > > > 6945538746972754&sdata=3DZHft4yd79R0Im8I27KM9dETCYgEhpc3zl9jJ= w > > > > > vxYZWc%3D&reserved=3D0%2Fmail-disclaimer%2F&data=3D02%7C0= 1%7 > > > > > Cpravb%40m > > > > > icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141 > > > > > af > > > > > 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhxkfj8b= y > > > > > IM > > > > > Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0 > > > > > > > > > %2 > > > > > Fwww.tessares.net%2Fmail-disclaimer%2F&data=3D02%7C01%7Cpravb= % > > > > > 40 > > > > > microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f14 > > > > > 1a > > > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhxkfj8= b > > > > > yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= F > > > > ww > > > > w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%4= 0 > > > > mi > > > > crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af9 > > > > 1a > > > > b2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3D1lrrMH92jHLh= 5 > > > > dq > > > > U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf > > .org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft= . > > com% > > 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db47% > > 7C1% > > 7C0%7C636943069081636780&sdata=3D1lrrMH92jHLh5dqU4q33yK%2FKg0LvXJKG= R > > 3glc > > nbAer8%3D&reserved=3D0 From nobody Tue May 28 13:04:07 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665EF1200D6 for ; Tue, 28 May 2019 13:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THaQw6ehvTtj for ; Tue, 28 May 2019 13:04:04 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094CD1200CC for ; Tue, 28 May 2019 13:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jNcOecDvXfvi+M5Ts1QvI/Sish+lEjBqn8AajCf07qA=; b=QKycFlJfsYtjFud40LukxrrjP XXkaZr2dsFbeeRDx/FvV10T3X2DzrjdLkhWwtaVoECKidq6KQlltwvt7QjutE/djOdTcz+CMwUH67 ciDfSN2Hvt4lHI6DaDTUjiwJouOwxBPnyo7TmUW9tdQHdLZTiKYE3OkHe+IFTeavjPWT5Savn31Us JkJqJwHVf273N84EO4btHFOkVv7lvV62GUni9NTKJgZmcLrENIXGWYc69x0TMMGYmIqAwIugjUaO3 ZPu+xeC87sMeZfX0nIjevuCVrHY9KiNQEPt8EwSSM4/Di0bSkhLpiBLpAXGeX9eAoNkxTBvZxavlB 09zZ8tEOw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:50014 helo=[192.168.1.179]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1hViKF-0030S4-40; Tue, 28 May 2019 16:04:03 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Tue, 28 May 2019 13:03:58 -0700 Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <330FD553-AB92-48EC-84AF-21A525CD1949@strayalpha.com> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Yuchung Cheng X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 20:04:06 -0000 On May 28, 2019, at 12:35 PM, Yuchung Cheng wrote: >> What you seem to be asking for is a modification of 793 and/or API behavi= or which will need a new opt-in socket option for preserving compat for exis= ting applications. >=20 > yes that's my sense as well (i.e. this draft requires a change in RFC793 That=E2=80=99s not trivial and shouldn=E2=80=99t be assumed a viable way for= ward.=20 Joe= From nobody Tue May 28 23:00:51 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D87120045 for ; Tue, 28 May 2019 23:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 SJMJ9_x0S_uY for ; Tue, 28 May 2019 23:00:46 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DB112008B for ; Tue, 28 May 2019 23:00:45 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 45DKnl5rXxz20Lr; Wed, 29 May 2019 08:00:43 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45DKnl571TzDq80; Wed, 29 May 2019 08:00:43 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM34.corporate.adroot.infra.ftgroup ([fe80::7873:1668:636f:52c%21]) with mapi id 14.03.0439.000; Wed, 29 May 2019 08:00:43 +0200 From: To: Praveen Balasubramanian , Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVDy6HMMq1d9rUjkC05hHsqCIciaZ0Q0IAgAE1qACAA3SNAIABd2QegAAbJQCABGLcAIABzvvggADzc/A= Date: Wed, 29 May 2019 06:00:42 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA90851@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 06:00:49 -0000 SGkgUHJhdmVlbiwNCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biBbbWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb21dDQo+IEVudm95w6nCoDogbWFyZGkgMjggbWFp IDIwMTkgMTc6MjINCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTjsgWXVjaHVuZyBD aGVuZw0KPiBDY8KgOiB0Y3BtQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBbdGNwbV0gUHJvZ3Jl c3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gDQo+IFRGTyBpcyBhIG5ldyBSRkMN Cg0KW01lZF0gLi4ud2hpY2ggcmVsYXhlcyB0aGUgY29uc3RyYWludCBpbiA3OTMuIFRoaXMgaXMg ZXhhY3RseSB3aGF0IGFuIGFwcGxpY2F0aW9uLXN1cHBsaWVkIGNvb2tpZSB3b3VsZCBiZSBkb2lu Zy4NCg0KSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kIHdoeSBURk8gd2Fzbid0IHRhZ2dlZCBhcyB1 cGRhdGluZyBSRkM3OTMuIA0KDQogYW5kIHNlcnZlciBpcyBvcHRpbmcgaW4gdG8gcmVjZWl2ZSBl YXJseSBkYXRhIHdoaWNoDQo+IGltcGxpZXMgYmVpbmcgYXdhcmUgb2YgdGhlIHJlcGxheSBpc3N1 ZXMuDQogSWYgdGhlIFRGTyBzdGF0ZSBtYWNoaW5lDQo+IHN1Y2NlZWRzICh2YWxpZCBjb29raWUg d2l0aCBkYXRhIGluIFNZTikgb25seSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBjYW4NCj4gcmV0cmll dmUgZGF0YSBldmVuIGJlZm9yZSBoYW5kc2hha2UgY29tcGxldGVzLg0KDQpbTWVkXSBUaGF0IHNh bWUgcHJvY2VkdXJlIGlzIGZvbGxvd2VkIHdpdGggYXBwbGljYXRpb24gc3VwcGxpZWQgY29va2ll cy4gQmVsb3cgYW4gZXhjZXJwdCBmcm9tIHRoZSBzcGVjOg0KDQogICBBIFRyYW5zcG9ydCBDb252 ZXJ0ZXIgdGhhdCBoYXMgYmVlbiBjb25maWd1cmVkIHRvIHVzZSB0aGUgb3B0aW9uYWwNCiAgIENv b2tpZSBUTFYgTVVTVCB2ZXJpZnkgdGhlIHByZXNlbmNlIG9mIHRoaXMgVExWIGluIHRoZSBwYXls b2FkIG9mIHRoZQ0KICAgcmVjZWl2ZWQgU1lOLiAgSWYgdGhpcyBUTFYgaXMgcHJlc2VudCwgdGhl IFRyYW5zcG9ydCBDb252ZXJ0ZXIgTVVTVA0KICAgdmFsaWRhdGUgdGhlIENvb2tpZSBieSBtZWFu cyBzaW1pbGFyIHRvIHRob3NlIGluIFNlY3Rpb24gNC4xLjIgb2YNCiAgIFtSRkM3NDEzXSAoaS5l LiwgSXNDb29raWVWYWxpZCkuICBJZiB0aGUgQ29va2llIGlzIHZhbGlkLCB0aGUNCiAgIGNvbm5l Y3Rpb24gZXN0YWJsaXNobWVudCBwcm9jZWR1cmUgY2FuIGNvbnRpbnVlLiAgT3RoZXJ3aXNlLCB0 aGUNCiAgIFRyYW5zcG9ydCBDb252ZXJ0ZXIgTVVTVCByZXR1cm4gYW4gRXJyb3IgVExWIHNldCB0 byAiTm90IEF1dGhvcml6ZWQiDQogICBhbmQgY2xvc2UgdGhlIGNvbm5lY3Rpb24uDQoNCj4gDQo+ IFdpdGhvdXQgVEZPLCB0aGUgc3RhbmRhcmQgc29ja2V0cyBBUEkgZG9lcyBub3QgYWxsb3cgYW4g YXBwbGljYXRpb24gdG8NCj4gcmVjZWl2ZSBkYXRhIGJlZm9yZSAzV0hTIGNvbXBsZXRlcywgZXZl biBpZiBkYXRhIGlzIHJlY2VpdmVkIGluIHRoZSBTWU4uDQoNCltNZWRdIE9saXZpZXIgYWxyZWFk eSBjbGFyaWZpZWQgdGhlIEFQSSBwb2ludDoNCg0KIkFub3RoZXIgcG9pbnQgaXMgdGhlIHNvY2tl dCBBUEkuIEN1cnJlbnRseSwgTGludXggYW5kIE1hY09TIGRlY291cGxlIHRoZSB0cmFuc21pc3Np b24gb2YgZGF0YSBpbnNpZGUgdGhlIFNZTiBmcm9tIHRoZSB1dGlsaXNhdGlvbiBvZiB0aGUgVEZP IG9wdGlvbi4gVGhpcyBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgYSBjbGllbnQgdG8gc2VuZCBkYXRh IGluc2lkZSB0aGUgU1lOIHdpdGhvdXQgZW5hYmxpbmcgVEZPLiBPbiBXaW5kb3dzLCB0aGUgQVBJ IHNlZW1zIHRvIGZvcmNlIHRoZSB1dGlsaXNhdGlvbiBvZiBURk8gd2hlbiB0aGVyZSBpcyBkYXRh IGluIHRoZSBTWU4uIEFzIGluZGljYXRlZCBlYXJsaWVyLCBSRkM3OTMgZG9lcyBub3QgbWFuZGF0 ZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIFRGTyB0byBwbGFjZSBkYXRhIGluc2lkZSB0aGUgU1lOLiIg DQoNCj4gV2hhdCB5b3Ugc2VlbSB0byBiZSBhc2tpbmcgZm9yIGlzIGEgbW9kaWZpY2F0aW9uIG9m IDc5MyBhbmQvb3IgQVBJDQo+IGJlaGF2aW9yIHdoaWNoIHdpbGwgbmVlZCBhIG5ldyBvcHQtaW4g c29ja2V0IG9wdGlvbiBmb3IgcHJlc2VydmluZyBjb21wYXQNCj4gZm9yIGV4aXN0aW5nIGFwcGxp Y2F0aW9ucy4NCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ IFNlbnQ6IE1vbmRheSwgTWF5IDI3LCAyMDE5IDQ6MzggQU0NCj4gVG86IFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgWXVjaHVuZyBDaGVuZw0KPiA8eWNoZW5n PTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gQ2M6IHRjcG1AaWV0Zi5vcmcNCj4gU3Vi amVjdDogUkU6IFt0Y3BtXSBQcm9ncmVzc2luZyBkcmFmdC1pZXRmLXRjcG0tY29udmVydGVycw0K PiANCj4gSGkgUHJhdmVlbiwNCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiANCj4gQ2hlZXJz LA0KPiBNZWQNCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDog UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gW21haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tXSBFbnZv ecOpwqA6DQo+ID4gdmVuZHJlZGkgMjQgbWFpIDIwMTkgMTg6NDUgw4DCoDogWXVjaHVuZyBDaGVu ZzsgQk9VQ0FEQUlSIE1vaGFtZWQNCj4gPiBUR0kvT0xOIENjwqA6IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9ucyBPYmpldMKgOiBSRTogW3RjcG1dIFByb2dyZXNzaW5nDQo+ID4gZHJhZnQtaWV0Zi10 Y3BtLWNvbnZlcnRlcnMNCj4gPg0KPiA+IEFncmVlZCBhbmQgSSBoYWQgcmFpc2VkIHRoZSBzYW1l IHF1ZXN0aW9uIGJlZm9yZTogIiBJc24ndCBwYXNzaW5nIGRhdGENCj4gPiBpbiB0aGUgU1lOIHVw IHRvIHRoZSBhcHBsaWNhdGlvbiBiZWZvcmUgM1dIUyBpbnZhbGlkIHBlciBSRkMgNzkzPw0KPiAN Cj4gW01lZF0gVGhpcyBpcyBzaW1pbGFyIHRvIHdoYXQgVEZPIGRvZXMuIEJvdGggKGkuZS4sIFRG TyBhbmQgdGhlDQo+IGFwcGxpY2F0aW9uLWJhc2VkIGNvb2tpZSkgYXJlIHJlbGF4aW5nIHRoYXQg Y29uc3RyYWludCBmcm9tIDc5My4NCj4gDQo+ICBIb3cgaXMgdGhlDQo+ID4gY29udmVydGVyIChU KSBleHRyYWN0aW5nIHRoZSBzZXJ2ZXIgSVAgYWRkcmVzcyBhbmQgcG9ydCBmcm9tIHRoZSBTWU4N Cj4gPiBwYXlsb2FkPyBJcyBpdCBydW5uaW5nIHNvbWUgY3VzdG9tIFRDUCBpbXBsZW1lbnRhdGlv biB0aGF0IHZpb2xhdGVzDQo+IDc5Mz8iDQo+ID4gNzQxMyBhbGxvd3MgbmlsLWNvb2tpZSBhbmQg YXBwIGNhbiBlbmNvZGUgY29va2llIGFuZCBkYXRhIGluIFNZTiBpZiBpdA0KPiA+IHdhbnRzLiBJ ZiBURk8gb3B0aW9uIGlzIG5vdCB1c2VkIGF0IGFsbCB0aGVuIGl0IHdvdWxkIGJlIGEgY2hhbmdl IHRvDQo+ID4gNzkzIGFuZCBub3QgNzQxMy4NCj4gDQo+IFtNZWRdIFRoaXMgaXMgd2hhdCB0aGUg aW5pdGlhbCBtZXNzYWdlIGZyb20gT2xpdmllciB0cmllZCB0byBhZGRyZXNzLiBUaGUNCj4gaXNz dWUgaXMgd2hhdCBpcyB0aGUgcG9pbnQgaW4gZW5jbG9zaW5nIHRoZSBURk8gb3B0aW9uIGlmIHRo ZSBjb29raWUgaXMNCj4gc3VwcGxpZWQgYnkgdGhlIGFwcGxpY2F0aW9uPyBUaGUgc2FtZSBwcm90 ZWN0aW9uIGxldmVsIGNhbiBiZSBwcm92aWRlZA0KPiB3aXRoIHRoZSBhcHBsaWNhdGlvbi1zdXBw bGllZCBjb29raWUgd2l0aG91dCByZXF1aXJpbmcgdG8gaW5zZXJ0IHRoZSBURk8NCj4gb3B0aW9u Lg0KPiANCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdGNw bSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWXVjaHVuZyBDaGVuZw0KPiA+ IFNlbnQ6IEZyaWRheSwgTWF5IDI0LCAyMDE5IDg6MDEgQU0NCj4gPiBUbzogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbQ0KPiA+IENjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1A aWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFt0Y3BtXSBQcm9ncmVzc2luZyBkcmFmdC1pZXRm LXRjcG0tY29udmVydGVycw0KPiA+DQo+ID4gT24gVGh1LCBNYXkgMjMsIDIwMTkgYXQgMTE6MzQg UE0gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEhp IFl1Y2h1bmcsDQo+ID4gPg0KPiA+ID4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ID4gPg0KPiA+ID4g Q2hlZXJzLA0KPiA+ID4gTWVkDQo+ID4gPg0KPiA+ID4gPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gPiA+ID4gRGUgOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIFl1Y2h1bmcNCj4gPiA+ID4gQ2hlbmcgRW52b3nDqSA6IGpldWRpIDIzIG1h aSAyMDE5IDE4OjM4IMOAIDogT2xpdmllciBCb25hdmVudHVyZSBDYyA6DQo+ID4gPiA+IHRjcG1A aWV0Zi5vcmcgRXh0ZW5zaW9ucyBPYmpldCA6IFJlOiBbdGNwbV0gUHJvZ3Jlc3NpbmcNCj4gPiA+ ID4gZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gPiA+ID4NCj4gPiA+ID4gT24gVHVlLCBN YXkgMjEsIDIwMTkgYXQgNDo1MiBBTSBPbGl2aWVyIEJvbmF2ZW50dXJlDQo+ID4gPiA+IDxvbGl2 aWVyLmJvbmF2ZW50dXJlQHRlc3NhcmVzLm5ldD4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBZdWNodW5nLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBXZSBiZWxp ZXZlIHRoYXQgYSBzcGVjaWFsaXNlZCBUQ1AgYXBwbGljYXRpb24gc2hvdWxkIGJlDQo+ID4gPiA+ ID4gPj4gYWxsb3dlZCB0bw0KPiA+ID4gPiB1c2UgaXRzIG93biBjb29raWUgaW5zaWRlIHRoZSBw YXlsb2FkIGluc3RlYWQgb2YgcmVseWluZyBvbiB0aGUNCj4gPiA+ID4gVENQIGhlYWRlciB0byB1 c2UgZmFzdCBvcGVuLiBUaGUgMC1SVFQgY29udmVydCBwcm90b2NvbCBpcyBvbmUNCj4gPiA+ID4g ZXhhbXBsZSwgYnV0IHRoZXJlIGNvdWxkIGJlIG90aGVycy4gTG9va2luZyBhdCBvdGhlciBhcHBs aWNhdGlvbg0KPiA+ID4gPiBsYXllciBwcm90b2NvbHMsIEkgbm90aWNlZCB0aGF0IFRMUzEuMyAo cmZjODQ0NikgYWxzbyBpbmNsdWRlcyBhDQo+ID4gPiA+IGNvb2tpZSB3aGljaCBpcyBtYWlubHkg ZGVzaWduZWQgZW5hYmxlIHNlcnZlcnMgdG8gZ2V0IGENCj4gPiA+ID4gY29uZmlybWF0aW9uIG9m IHRoZSByZWFjaGFiaWxpdHkgb2YgdGhlIGNsaWVudCBJUCBhZGRyZXNzZXMgZm9yDQo+ID4gPiA+ IERUTFMsIGJ1dCB0aGUgc2FtZSBhcHByb2FjaCBjb3VsZCBiZSB1c2VkIHdoZW4gVExTIHNlbmRz IGl0cw0KPiA+ID4gPiBpbml0aWFsIGRhdGEgaW4gdGhlIFNZTiBhcw0KPiA+IHdlbGwuDQo+ID4g PiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBBbm90aGVyIHBvaW50IHRoYXQgc2hvdWxkIGJlIGNsYXJp ZmllZCBpbiBSRkM3NDEzIGFyZSBob3cNCj4gPiA+ID4gPiA+PiBtaWRkbGVib3hlcw0KPiA+ID4g PiBzaG91bGQgaGFuZGxlIFNZTiBwYWNrZXRzIGNvbnRhaW5pbmcgYSBub24temVybyBwYXlsb2Fk LiBBY2NvcmRpbmcNCj4gPiA+ID4gdG8gUkZDNzkzLCBzdWNoIHBhY2tldHMgYXJlIHZhbGlkIFRD UCBwYWNrZXRzLiBUaGUgVEZPIG9wdGlvbiwNCj4gPiA+ID4gZGVmaW5lZCBpbg0KPiA+ID4gPiBS RkM3MzE0IGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIGFuIGluZGljYXRp b24gdGhhdA0KPiA+ID4gPiBpcyByZXF1aXJlZCB0byDigJxhdXRob3Jpc2XigJ0gdGhlIHV0aWxp c2F0aW9uIG9mIHBheWxvYWQgaW5zaWRlIGEgU1lODQo+ID4gcGFja2V0Lg0KPiA+ID4gPiBEdXJp bmcgdGhlIFByYWd1ZSBtZWV0aW5nLCBDaHJpc3RvcGggUGFhc2NoIG1lbnRpb25lZCBhdCB0aGUg bWlrZQ0KPiA+ID4gPiB0aGF0IHRoZXkgaGF2ZSBvbmUgYXBwbGljYXRpb24gdGhhdCB1c2VzIGRh dGEgaW5zaWRlIHRoZSBTWU4gYW5kDQo+ID4gPiA+IHRoZWlyIG1lYXN1cmVtZW50cyBpbmRpY2F0 ZSB0aGF0IHNlbmRpbmcgdGhpcyBTWU4gd2l0aG91dCB0aGUgVEZPDQo+ID4gPiA+IG9wdGlvbiBl bmFibGVzIGl0IHRvIHBhc3MgdGhyb3VnaCBtb3JlIG1pZGRsZWJveGVzIHRoYW4gd2hlbiB0aGUN Cj4gPiA+ID4gc2FtZSBTWU4gY29udGFpbnMgdGhlIFRGTyBvcHRpb24uDQo+ID4gPiA+ID4gPj4N Cj4gPiA+ID4gPiA+PiBBbm90aGVyIHBvaW50IGlzIHRoZSBzb2NrZXQgQVBJLiBDdXJyZW50bHks IExpbnV4IGFuZCBNYWNPUw0KPiA+ID4gPiA+ID4+IGRlY291cGxlDQo+ID4gPiA+IHRoZSB0cmFu c21pc3Npb24gb2YgZGF0YSBpbnNpZGUgdGhlIFNZTiBmcm9tIHRoZSB1dGlsaXNhdGlvbiBvZg0K PiA+ID4gPiB0aGUgVEZPIG9wdGlvbi4gVGhpcyBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgYSBjbGll bnQgdG8gc2VuZCBkYXRhDQo+ID4gPiA+IGluc2lkZSB0aGUgU1lOIHdpdGhvdXQgZW5hYmxpbmcg VEZPLiBPbiBXaW5kb3dzLCB0aGUgQVBJIHNlZW1zIHRvDQo+ID4gPiA+IGZvcmNlIHRoZSB1dGls aXNhdGlvbiBvZiBURk8gd2hlbiB0aGVyZSBpcyBkYXRhIGluIHRoZSBTWU4uIEFzDQo+ID4gPiA+ IGluZGljYXRlZCBlYXJsaWVyLCBSRkM3OTMgZG9lcyBub3QgbWFuZGF0ZSB0aGUgcHJlc2VuY2Ug b2YgdGhlIFRGTw0KPiA+ID4gPiB0byBwbGFjZSBkYXRhDQo+ID4gaW5zaWRlIHRoZSBTWU4uDQo+ ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+PiBUaGUgYXBwcm9hY2ggd2UgYXJlIHByb3Bvc2luZyBo YXMgdGhlIGJlbmVmaXRzIG9mIFJGQzc0MTMgYnV0DQo+ID4gPiA+ID4gPj4gd2l0aG91dA0KPiA+ ID4gPiBpdHMgZHJhd2JhY2tzLiBNb3Jlb3ZlciwgZ2l2ZW4gdGhhdCBSRkM3NDEzIGlzIEV4cGVy aW1lbnRhbCwgd2UNCj4gPiA+ID4gZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGhhcm0gaWYg d2UgcHJvY2VlZCB3aXRoIHRoZSBhcHByb2FjaA0KPiA+ID4gPiAwLXJ0dCBjb252ZXJ0IHByb3Rv Y29sIHdoaWxlIHRoZSBJRVRGIGNhbiBmdXJ0aGVyIHR3ZWFrIGFuZCBhZGp1c3QNCj4gPiA+ID4g dGhlIGFwcGxpY2FiaWxpdHkgc2NvcGUgb2YgUkZDNzQxMy4gRm9yIGV4YW1wbGUsIGFuIHVwZGF0 ZSBjYW4gYmUNCj4gPiA+ID4gcHJvcG9zZWQgdG8gUkZDNzQxMyB0byBjbGFyaWZ5IHRoYXQgc3Bl Y2lhbGl6ZWQgYXBwbGljYXRpb24tbGV2ZWwNCj4gPiA+ID4gcHJvdG9jb2xzIGNvdWxkIHBsYWNl IGNvb2tpZSBpbmZvcm1hdGlvbiBpbiB0aGVpciBwYXlsb2FkIGFuZCB0aHVzDQo+ID4gPiA+IG5v dA0KPiA+IHVzZSB0aGUgVEZPIG9wdGlvbi4NCj4gPiA+ID4gPiA+IEp1c3QgdG8gY29uZmlybTog eW91IG1lYW4gYW4gQVBJIHRoYXQgbGV0IGFwcGxpY2F0aW9uIHNldHMgdGhlDQo+ID4gPiA+ID4g PiBURk8gY29va2llIChvbiBlaXRoZXIgc2VydmVyIGFuZCBjbGllbnQpPw0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBObywgd2Ugc3VnZ2VzdCB0byBsZXQgc3BlY2lmaWMgYXBwbGlj YXRpb25zIHVzZSBkYXRhIGluIHRoZSBTWU4NCj4gPiA+ID4gPiB3aXRob3V0DQo+ID4gPiA+IHVz aW5nIHRoZSBURk8gY29va2llLiBUaG9zZSBhcHBsaWNhdGlvbnMgY2FuIG1hbmFnZSB0aGVpciBj b29raWUNCj4gPiA+ID4gaW5zaWRlIHRoZSBTWU4gcGF5bG9hZCBpZiBuZWVkZWQuIEluc3RlYWQg b2YgaGF2aW5nIFRGTyBjb29raWVzDQo+ID4gPiA+IHRoYXQgYXJlIG1hbmFnZWQgYnkgdGhlIFRD UCBzdGFjayBhbmQgaGF2ZSBsaW1pdGVkIHNpemUsIHRob3NlDQo+ID4gPiA+IHNwZWNpYWxpc2Vk IHByb3RvY29scyB3b3VsZCB1c2UgYXBwbGljYXRpb24tbGV2ZWwgY29va2llcyB3aGljaA0KPiA+ ID4gPiBjYW4gYmUgbG9uZ2VyIGFuZCBhcmUgbWFuYWdlZCBieSB0aGVzZSBhcHBsaWNhdGlvbiBw cm90b2NvbHMuDQo+ID4gPiA+IEkgc2VlLiB0aG91Z2ggSSBzdXBwb3NlIHRoaXMgcmVxdWlyZXMg Y2hhbmdpbmcgUkZDNzkzIG9mIG5vdA0KPiA+ID4gPiB1cGxvYWRpbmcgdGhlIGRhdGEgdG8gYXBw bGljYXRpb24gdW50aWwgM1dIUyBjb21wbGV0ZXMuDQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gW01l ZF0gVGhhdCBjb25zdHJhaW50IGNhbiBiZSByZWxheGVkIGZvbGxvd2luZyBhIHJhdGlvbmFsZSBz aW1pbGFyDQo+ID4gPiB0bw0KPiA+IHRoZSBvbmUgaW4gUkZDNzQxMy4NCj4gPiA+DQo+ID4gPiBJ cyB0aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IGEgY2hhbmdlIHRvIFJGQzc5MyB3b3Vs ZCBiZQ0KPiA+ID4gcmVxdWlyZWQNCj4gPiBoZXJlIGJ1dCBub3QgZm9yIFJGQzc0MTM/DQo+ID4g SXQncyBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiAtDQo+ID4NCj4gPiBSRkM3OTMgbG9uZyBhbGxv d3MgZGF0YS1pbi1TWU4gYnV0IHJlcXVpcmVzIGRhdGEgdG8gYmUgcG9zdGVkIGFmdGVyDQo+ID4g aGFuZHNoYWtlLiBSRkM3NDEzIHJlbGF4ZXMgdGhhdCBidXQgYWxzbyByZXF1aXJlcyBhIGNvb2tp ZS4NCj4gPg0KPiA+IFNvIGlmIHdlIHRoaW5rIHRoaXMgaXMgYW4gImV4dGVuc2lvbiIgdG8gVEZP LCB0aGVuIHBlcmhhcHMgZXh0ZW5kcw0KPiA+IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8g cGVyc29uYWxseSBJIGRvIHRoaW5rIHRoYXQgbWFrZXMgc2Vuc2UuDQo+ID4gSU1PIFRGTyBpbXBs ZW1lbnRhdGlvbiBwcm92aWRlcyBhIGdlbmVyaWMgd2F5IHRvIGRvIGRhdGEtaW4tU1lOLg0KPiA+ IEFwcGxpY2F0aW9uIGNhbiB1c2Ugd2hhdGV2ZXIgdGhleSBwcmVmZXIgdG8gcHJvdGVjdCBvciBv cHRpbWl6ZQ0KPiA+IGRhdGEtaW4tIFNZTi4gVEZPIGNvb2tpZSBpcyBqdXN0IGEgZGVmYXVsdCBz aW1wbGUgbWVjaGFuaXNtIGZvcg0KPiA+IGFwcGxpY2F0aW9uIHdobyBmaW5kcyB0aGF0IGFjY2Vw dGFibGUuDQo+ID4NCj4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IG90aGVyd2lzZSBvYnZp b3VzbHkgYXBwbGljYXRpb24gY2FuIHBsYWNlIGFueSBkYXRhIGluIHRoZWlyDQo+ID4gPiA+ID4g PiBUQ1ANCj4gPiA+ID4gcGF5bG9hZCBmb3IgaXRzDQo+ID4gPiA+ID4gPiBwdXJwb3Nlcy4NCj4g PiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgaXMgd2hhdCB3ZSBwcm9wb3NlZCBpbiBQcmFndWUsIGku ZS4gdXNpbmcgZGF0YSBpbiB0aGUgVENQDQo+ID4gPiA+ID4gU1lODQo+ID4gPiA+IHdpdGhvdXQg dGhlIFRGTyBvcHRpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9saXZpZXIN Cj4gPiA+ID4gPiAtLQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBEaXNjbGFpbWVy Og0KPiA+ID4gPiA+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUNCj4gPiA+ID4gPiAyRg0KPiA+ID4gPiA+IGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD13d3cudGVzc2FyZXMNCj4g PiA+ID4gPiAubmV0JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0Nk NjY0MTE1NzZkY2M0ZTljDQo+ID4gPiA+ID4gMmM5MzA4ZDZlMjk3YzE4YyU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2Mw0KPiA+ID4gPiA+IDY5NDU1Mzg3NDY5 NzI3NTQmYW1wO3NkYXRhPVpIZnQ0eWQ3OVIwSW04STI3S005ZEVUQ1lnRWhwYzN6bDlqSncNCj4g PiA+ID4gPiB2eFlaV2MlM0QmYW1wO3Jlc2VydmVkPTAlMkZtYWlsLWRpc2NsYWltZXIlMkYmYW1w O2RhdGE9MDIlN0MwMSU3DQo+ID4gPiA+ID4gQ3ByYXZiJTQwbQ0KPiA+ID4gPiA+IGljcm9zb2Z0 LmNvbSU3QzUyZjc2ZDZiNDg1MjRlYTMzZGZjMDhkNmUwNThiZGE4JTdDNzJmOTg4YmY4NmYxNDEN Cj4gPiA+ID4gPiBhZg0KPiA+ID4gPiA+IDkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0 MzA2OTA4MTYzNjc4MCZhbXA7c2RhdGE9aHhrZmo4YnkNCj4gPiA+ID4gPiBJTQ0KPiA+ID4gPiA+ IFR4aDJVd1FCanolMkJvUDhvQnczJTJGUmlZTUdHM0VNRW9yUTQlM0QmYW1wO3Jlc2VydmVkPTAN Cj4gPiA+ID4gPiA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGDQo+ID4gPiA+ID4gJTINCj4gPiA+ID4gPiBGd3d3LnRlc3NhcmVz Lm5ldCUyRm1haWwtZGlzY2xhaW1lciUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlDQo+ID4g PiA+ID4gNDANCj4gPiA+ID4gPiBtaWNyb3NvZnQuY29tJTdDNTJmNzZkNmI0ODUyNGVhMzNkZmMw OGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0DQo+ID4gPiA+ID4gMWENCj4gPiA+ID4gPiBmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTQzMDY5MDgxNjM2NzgwJmFtcDtzZGF0YT1oeGtm ajhiDQo+ID4gPiA+ID4geUkgTVR4aDJVd1FCanolMkJvUDhvQnczJTJGUmlZTUdHM0VNRW9yUTQl M0QmYW1wO3Jlc2VydmVkPTA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4g PiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ID4gPiB0Y3BtQGlldGYub3JnDQo+ID4gPiA+IGh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRg0KPiA+ID4gPiB3dw0KPiA+ID4gPiB3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZv JTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDANCj4gPiA+ID4gbWkNCj4gPiA+ID4g Y3Jvc29mdC5jb20lN0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJm ODZmMTQxYWY5DQo+ID4gPiA+IDFhDQo+ID4gPiA+IGIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz Njk0MzA2OTA4MTYzNjc4MCZhbXA7c2RhdGE9MWxyck1IOTJqSExoNQ0KPiA+ID4gPiBkcQ0KPiA+ ID4gPiBVNHEzM3lLJTJGS2cwTHZYSktHUjNnbGNuYkFlcjglM0QmYW1wO3Jlc2VydmVkPTANCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3 Lg0KPiA+IGlldGYNCj4gPiAub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuDQo+ID4gY29tJQ0KPiA+IDdDNTJmNzZkNmI0 ODUyNGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyUNCj4gPiA3QzElDQo+ID4gN0MwJTdDNjM2OTQzMDY5MDgxNjM2NzgwJmFtcDtzZGF0YT0xbHJy TUg5MmpITGg1ZHFVNHEzM3lLJTJGS2cwTHZYSktHUg0KPiA+IDNnbGMNCj4gPiBuYkFlcjglM0Qm YW1wO3Jlc2VydmVkPTANCg== From nobody Tue May 28 23:10:59 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673F412008B for ; Tue, 28 May 2019 23:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kDlptRYq0Doy for ; Tue, 28 May 2019 23:10:54 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09F3120045 for ; Tue, 28 May 2019 23:10:53 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 45DL1S1Tbtz1yqr; Wed, 29 May 2019 08:10:52 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45DL1S0mTvzDq8H; Wed, 29 May 2019 08:10:52 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0439.000; Wed, 29 May 2019 08:10:51 +0200 From: To: Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVFYyvctZJrLYG+E+k02U75BYIjaaBnMqA Date: Wed, 29 May 2019 06:10:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 06:10:57 -0000 SGkgWXVjaHVuZywgDQoNClRoaXMgc3BlYyBpcyBhbiBFeHBlcmltZW50IHdoaWNoIHJlbGF4ZXMg YSBjb25zdHJhaW50IGluIFJGQzc5MyBpbiB0aGUgKiBTQU1FICogIHdheSB0aGUgVEZPIEV4cGVy aW1lbnQgcmVsYXhlcyB0aGF0ICogU0FNRSAqIGNvbnN0cmFpbnQuIA0KDQpHaXZlbiB0aGF0IFJG Qzc0MTMgaXNuJ3QgdGFnZ2VkIGFzIHVwZGF0aW5nIFJGQzc5Mywgd2UgYXJlIGFzc3VtaW5nIHRo YXQgdGhlIHNhbWUgY29uY2x1c2lvbiBhcHBsaWVzIGZvciBvdXIgc3BlYy4gDQoNCkkgZG9uJ3Qg dGhpbmsgYW4gRXhwZXJpbWVudGFsIFJGQyBjYW4gYmUgdGFnZ2VkIGFzIHVwZGF0aW5nIFJGQzc5 MywgYW55d2F5LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IFl1Y2h1bmcgQ2hlbmcgW21haWx0bzp5Y2hlbmdAZ29vZ2xlLmNvbV0NCj4g RW52b3nDqcKgOiBtYXJkaSAyOCBtYWkgMjAxOSAyMTozNg0KPiDDgMKgOiBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbg0KPiBDY8KgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyB0Y3BtQGlldGYu b3JnDQo+IE9iamV0wqA6IFJlOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNv bnZlcnRlcnMNCj4gDQo+IE9uIFR1ZSwgTWF5IDI4LCAyMDE5IGF0IDg6MjIgQU0gUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4NCj4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQo+ID4NCj4gPiBURk8gaXMgYSBuZXcgUkZDIGFuZCBzZXJ2ZXIgaXMgb3B0aW5nIGlu IHRvIHJlY2VpdmUgZWFybHkgZGF0YSB3aGljaA0KPiBpbXBsaWVzIGJlaW5nIGF3YXJlIG9mIHRo ZSByZXBsYXkgaXNzdWVzLiBJZiB0aGUgVEZPIHN0YXRlIG1hY2hpbmUNCj4gc3VjY2VlZHMgKHZh bGlkIGNvb2tpZSB3aXRoIGRhdGEgaW4gU1lOKSBvbmx5IHRoZW4gdGhlIGFwcGxpY2F0aW9uIGNh bg0KPiByZXRyaWV2ZSBkYXRhIGV2ZW4gYmVmb3JlIGhhbmRzaGFrZSBjb21wbGV0ZXMuDQo+ID4N Cj4gPiBXaXRob3V0IFRGTywgdGhlIHN0YW5kYXJkIHNvY2tldHMgQVBJIGRvZXMgbm90IGFsbG93 IGFuIGFwcGxpY2F0aW9uIHRvDQo+IHJlY2VpdmUgZGF0YSBiZWZvcmUgM1dIUyBjb21wbGV0ZXMs IGV2ZW4gaWYgZGF0YSBpcyByZWNlaXZlZCBpbiB0aGUgU1lOLg0KPiBXaGF0IHlvdSBzZWVtIHRv IGJlIGFza2luZyBmb3IgaXMgYSBtb2RpZmljYXRpb24gb2YgNzkzIGFuZC9vciBBUEkNCj4gYmVo YXZpb3Igd2hpY2ggd2lsbCBuZWVkIGEgbmV3IG9wdC1pbiBzb2NrZXQgb3B0aW9uIGZvciBwcmVz ZXJ2aW5nIGNvbXBhdA0KPiBmb3IgZXhpc3RpbmcgYXBwbGljYXRpb25zLg0KPiANCj4geWVzIHRo YXQncyBteSBzZW5zZSBhcyB3ZWxsIChpLmUuIHRoaXMgZHJhZnQgcmVxdWlyZXMgYSBjaGFuZ2Ug aW4gUkZDNzkzKS4NCj4gDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSA8bW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbT4NCj4gPiBTZW50OiBNb25kYXksIE1heSAyNywgMjAxOSA0OjM4IEFNDQo+ ID4gVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgWXVj aHVuZyBDaGVuZw0KPiA8eWNoZW5nPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gPiBD YzogdGNwbUBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJFOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgZHJh ZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gPg0KPiA+IEhpIFByYXZlZW4sDQo+ID4NCj4gPiBQ bGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiBEZSA6IFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIFttYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbV0gRW52b3nDqSA6DQo+ID4gPiB2ZW5k cmVkaSAyNCBtYWkgMjAxOSAxODo0NSDDgCA6IFl1Y2h1bmcgQ2hlbmc7IEJPVUNBREFJUiBNb2hh bWVkDQo+ID4gPiBUR0kvT0xOIENjIDogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIE9iamV0IDog UkU6IFt0Y3BtXSBQcm9ncmVzc2luZw0KPiA+ID4gZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMN Cj4gPiA+DQo+ID4gPiBBZ3JlZWQgYW5kIEkgaGFkIHJhaXNlZCB0aGUgc2FtZSBxdWVzdGlvbiBi ZWZvcmU6ICIgSXNuJ3QgcGFzc2luZyBkYXRhDQo+ID4gPiBpbiB0aGUgU1lOIHVwIHRvIHRoZSBh cHBsaWNhdGlvbiBiZWZvcmUgM1dIUyBpbnZhbGlkIHBlciBSRkMgNzkzPw0KPiA+DQo+ID4gW01l ZF0gVGhpcyBpcyBzaW1pbGFyIHRvIHdoYXQgVEZPIGRvZXMuIEJvdGggKGkuZS4sIFRGTyBhbmQg dGhlDQo+IGFwcGxpY2F0aW9uLWJhc2VkIGNvb2tpZSkgYXJlIHJlbGF4aW5nIHRoYXQgY29uc3Ry YWludCBmcm9tIDc5My4NCj4gPg0KPiA+ICBIb3cgaXMgdGhlDQo+ID4gPiBjb252ZXJ0ZXIgKFQp IGV4dHJhY3RpbmcgdGhlIHNlcnZlciBJUCBhZGRyZXNzIGFuZCBwb3J0IGZyb20gdGhlIFNZTg0K PiA+ID4gcGF5bG9hZD8gSXMgaXQgcnVubmluZyBzb21lIGN1c3RvbSBUQ1AgaW1wbGVtZW50YXRp b24gdGhhdCB2aW9sYXRlcw0KPiA3OTM/Ig0KPiA+ID4gNzQxMyBhbGxvd3MgbmlsLWNvb2tpZSBh bmQgYXBwIGNhbiBlbmNvZGUgY29va2llIGFuZCBkYXRhIGluIFNZTiBpZiBpdA0KPiA+ID4gd2Fu dHMuIElmIFRGTyBvcHRpb24gaXMgbm90IHVzZWQgYXQgYWxsIHRoZW4gaXQgd291bGQgYmUgYSBj aGFuZ2UgdG8NCj4gPiA+IDc5MyBhbmQgbm90IDc0MTMuDQo+ID4NCj4gPiBbTWVkXSBUaGlzIGlz IHdoYXQgdGhlIGluaXRpYWwgbWVzc2FnZSBmcm9tIE9saXZpZXIgdHJpZWQgdG8gYWRkcmVzcy4N Cj4gVGhlIGlzc3VlIGlzIHdoYXQgaXMgdGhlIHBvaW50IGluIGVuY2xvc2luZyB0aGUgVEZPIG9w dGlvbiBpZiB0aGUgY29va2llDQo+IGlzIHN1cHBsaWVkIGJ5IHRoZSBhcHBsaWNhdGlvbj8gVGhl IHNhbWUgcHJvdGVjdGlvbiBsZXZlbCBjYW4gYmUgcHJvdmlkZWQNCj4gd2l0aCB0aGUgYXBwbGlj YXRpb24tc3VwcGxpZWQgY29va2llIHdpdGhvdXQgcmVxdWlyaW5nIHRvIGluc2VydCB0aGUgVEZP DQo+IG9wdGlvbi4NCj4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiBGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBZ dWNodW5nIENoZW5nDQo+ID4gPiBTZW50OiBGcmlkYXksIE1heSAyNCwgMjAxOSA4OjAxIEFNDQo+ ID4gPiBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiA+ID4gQ2M6IHRjcG1AaWV0 Zi5vcmcgRXh0ZW5zaW9ucyA8dGNwbUBpZXRmLm9yZz4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbdGNw bV0gUHJvZ3Jlc3NpbmcgZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4gPiA+DQo+ID4gPiBP biBUaHUsIE1heSAyMywgMjAxOSBhdCAxMTozNCBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl LmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IEhpIFl1Y2h1bmcsDQo+ID4gPiA+DQo+ID4g PiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+ IE1lZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+ ID4gPiA+IERlIDogdGNwbSBbbWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy dCBkZSBZdWNodW5nDQo+ID4gPiA+ID4gQ2hlbmcgRW52b3nDqSA6IGpldWRpIDIzIG1haSAyMDE5 IDE4OjM4IMOAIDogT2xpdmllciBCb25hdmVudHVyZSBDYw0KPiA6DQo+ID4gPiA+ID4gdGNwbUBp ZXRmLm9yZyBFeHRlbnNpb25zIE9iamV0IDogUmU6IFt0Y3BtXSBQcm9ncmVzc2luZw0KPiA+ID4g PiA+IGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiBU dWUsIE1heSAyMSwgMjAxOSBhdCA0OjUyIEFNIE9saXZpZXIgQm9uYXZlbnR1cmUNCj4gPiA+ID4g PiA8b2xpdmllci5ib25hdmVudHVyZUB0ZXNzYXJlcy5uZXQ+IHdyb3RlOg0KPiA+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IFl1Y2h1bmcsDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ ID4gPiA+ID4+IFdlIGJlbGlldmUgdGhhdCBhIHNwZWNpYWxpc2VkIFRDUCBhcHBsaWNhdGlvbiBz aG91bGQgYmUNCj4gPiA+ID4gPiA+ID4+IGFsbG93ZWQgdG8NCj4gPiA+ID4gPiB1c2UgaXRzIG93 biBjb29raWUgaW5zaWRlIHRoZSBwYXlsb2FkIGluc3RlYWQgb2YgcmVseWluZyBvbiB0aGUNCj4g PiA+ID4gPiBUQ1AgaGVhZGVyIHRvIHVzZSBmYXN0IG9wZW4uIFRoZSAwLVJUVCBjb252ZXJ0IHBy b3RvY29sIGlzIG9uZQ0KPiA+ID4gPiA+IGV4YW1wbGUsIGJ1dCB0aGVyZSBjb3VsZCBiZSBvdGhl cnMuIExvb2tpbmcgYXQgb3RoZXIgYXBwbGljYXRpb24NCj4gPiA+ID4gPiBsYXllciBwcm90b2Nv bHMsIEkgbm90aWNlZCB0aGF0IFRMUzEuMyAocmZjODQ0NikgYWxzbyBpbmNsdWRlcyBhDQo+ID4g PiA+ID4gY29va2llIHdoaWNoIGlzIG1haW5seSBkZXNpZ25lZCBlbmFibGUgc2VydmVycyB0byBn ZXQgYQ0KPiA+ID4gPiA+IGNvbmZpcm1hdGlvbiBvZiB0aGUgcmVhY2hhYmlsaXR5IG9mIHRoZSBj bGllbnQgSVAgYWRkcmVzc2VzIGZvcg0KPiA+ID4gPiA+IERUTFMsIGJ1dCB0aGUgc2FtZSBhcHBy b2FjaCBjb3VsZCBiZSB1c2VkIHdoZW4gVExTIHNlbmRzIGl0cw0KPiA+ID4gPiA+IGluaXRpYWwg ZGF0YSBpbiB0aGUgU1lOIGFzDQo+ID4gPiB3ZWxsLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4g PiA+ID4+IEFub3RoZXIgcG9pbnQgdGhhdCBzaG91bGQgYmUgY2xhcmlmaWVkIGluIFJGQzc0MTMg YXJlIGhvdw0KPiA+ID4gPiA+ID4gPj4gbWlkZGxlYm94ZXMNCj4gPiA+ID4gPiBzaG91bGQgaGFu ZGxlIFNZTiBwYWNrZXRzIGNvbnRhaW5pbmcgYSBub24temVybyBwYXlsb2FkLiBBY2NvcmRpbmcN Cj4gPiA+ID4gPiB0byBSRkM3OTMsIHN1Y2ggcGFja2V0cyBhcmUgdmFsaWQgVENQIHBhY2tldHMu IFRoZSBURk8gb3B0aW9uLA0KPiA+ID4gPiA+IGRlZmluZWQgaW4NCj4gPiA+ID4gPiBSRkM3MzE0 IGlzIG5vdCBhbmQgc2hvdWxkIG5vdCBiZSBjb25zaWRlcmVkIGFzIGFuIGluZGljYXRpb24gdGhh dA0KPiA+ID4gPiA+IGlzIHJlcXVpcmVkIHRvIOKAnGF1dGhvcmlzZeKAnSB0aGUgdXRpbGlzYXRp b24gb2YgcGF5bG9hZCBpbnNpZGUgYSBTWU4NCj4gPiA+IHBhY2tldC4NCj4gPiA+ID4gPiBEdXJp bmcgdGhlIFByYWd1ZSBtZWV0aW5nLCBDaHJpc3RvcGggUGFhc2NoIG1lbnRpb25lZCBhdCB0aGUg bWlrZQ0KPiA+ID4gPiA+IHRoYXQgdGhleSBoYXZlIG9uZSBhcHBsaWNhdGlvbiB0aGF0IHVzZXMg ZGF0YSBpbnNpZGUgdGhlIFNZTiBhbmQNCj4gPiA+ID4gPiB0aGVpciBtZWFzdXJlbWVudHMgaW5k aWNhdGUgdGhhdCBzZW5kaW5nIHRoaXMgU1lOIHdpdGhvdXQgdGhlIFRGTw0KPiA+ID4gPiA+IG9w dGlvbiBlbmFibGVzIGl0IHRvIHBhc3MgdGhyb3VnaCBtb3JlIG1pZGRsZWJveGVzIHRoYW4gd2hl biB0aGUNCj4gPiA+ID4gPiBzYW1lIFNZTiBjb250YWlucyB0aGUgVEZPIG9wdGlvbi4NCj4gPiA+ ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+PiBBbm90aGVyIHBvaW50IGlzIHRoZSBzb2NrZXQgQVBJ LiBDdXJyZW50bHksIExpbnV4IGFuZCBNYWNPUw0KPiA+ID4gPiA+ID4gPj4gZGVjb3VwbGUNCj4g PiA+ID4gPiB0aGUgdHJhbnNtaXNzaW9uIG9mIGRhdGEgaW5zaWRlIHRoZSBTWU4gZnJvbSB0aGUg dXRpbGlzYXRpb24gb2YNCj4gPiA+ID4gPiB0aGUgVEZPIG9wdGlvbi4gVGhpcyBtYWtlcyBpdCBw b3NzaWJsZSBmb3IgYSBjbGllbnQgdG8gc2VuZCBkYXRhDQo+ID4gPiA+ID4gaW5zaWRlIHRoZSBT WU4gd2l0aG91dCBlbmFibGluZyBURk8uIE9uIFdpbmRvd3MsIHRoZSBBUEkgc2VlbXMgdG8NCj4g PiA+ID4gPiBmb3JjZSB0aGUgdXRpbGlzYXRpb24gb2YgVEZPIHdoZW4gdGhlcmUgaXMgZGF0YSBp biB0aGUgU1lOLiBBcw0KPiA+ID4gPiA+IGluZGljYXRlZCBlYXJsaWVyLCBSRkM3OTMgZG9lcyBu b3QgbWFuZGF0ZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIFRGTw0KPiA+ID4gPiA+IHRvIHBsYWNlIGRh dGENCj4gPiA+IGluc2lkZSB0aGUgU1lOLg0KPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4+ IFRoZSBhcHByb2FjaCB3ZSBhcmUgcHJvcG9zaW5nIGhhcyB0aGUgYmVuZWZpdHMgb2YgUkZDNzQx MyBidXQNCj4gPiA+ID4gPiA+ID4+IHdpdGhvdXQNCj4gPiA+ID4gPiBpdHMgZHJhd2JhY2tzLiBN b3Jlb3ZlciwgZ2l2ZW4gdGhhdCBSRkM3NDEzIGlzIEV4cGVyaW1lbnRhbCwgd2UNCj4gPiA+ID4g PiBkb24ndCB0aGluayB0aGF0IHRoZXJlIGlzIGEgaGFybSBpZiB3ZSBwcm9jZWVkIHdpdGggdGhl IGFwcHJvYWNoDQo+ID4gPiA+ID4gMC1ydHQgY29udmVydCBwcm90b2NvbCB3aGlsZSB0aGUgSUVU RiBjYW4gZnVydGhlciB0d2VhayBhbmQgYWRqdXN0DQo+ID4gPiA+ID4gdGhlIGFwcGxpY2FiaWxp dHkgc2NvcGUgb2YgUkZDNzQxMy4gRm9yIGV4YW1wbGUsIGFuIHVwZGF0ZSBjYW4gYmUNCj4gPiA+ ID4gPiBwcm9wb3NlZCB0byBSRkM3NDEzIHRvIGNsYXJpZnkgdGhhdCBzcGVjaWFsaXplZCBhcHBs aWNhdGlvbi1sZXZlbA0KPiA+ID4gPiA+IHByb3RvY29scyBjb3VsZCBwbGFjZSBjb29raWUgaW5m b3JtYXRpb24gaW4gdGhlaXIgcGF5bG9hZCBhbmQgdGh1cw0KPiA+ID4gPiA+IG5vdA0KPiA+ID4g dXNlIHRoZSBURk8gb3B0aW9uLg0KPiA+ID4gPiA+ID4gPiBKdXN0IHRvIGNvbmZpcm06IHlvdSBt ZWFuIGFuIEFQSSB0aGF0IGxldCBhcHBsaWNhdGlvbiBzZXRzIHRoZQ0KPiA+ID4gPiA+ID4gPiBU Rk8gY29va2llIChvbiBlaXRoZXIgc2VydmVyIGFuZCBjbGllbnQpPw0KPiA+ID4gPiA+ID4NCj4g PiA+ID4gPiA+DQo+ID4gPiA+ID4gPiBObywgd2Ugc3VnZ2VzdCB0byBsZXQgc3BlY2lmaWMgYXBw bGljYXRpb25zIHVzZSBkYXRhIGluIHRoZSBTWU4NCj4gPiA+ID4gPiA+IHdpdGhvdXQNCj4gPiA+ ID4gPiB1c2luZyB0aGUgVEZPIGNvb2tpZS4gVGhvc2UgYXBwbGljYXRpb25zIGNhbiBtYW5hZ2Ug dGhlaXIgY29va2llDQo+ID4gPiA+ID4gaW5zaWRlIHRoZSBTWU4gcGF5bG9hZCBpZiBuZWVkZWQu IEluc3RlYWQgb2YgaGF2aW5nIFRGTyBjb29raWVzDQo+ID4gPiA+ID4gdGhhdCBhcmUgbWFuYWdl ZCBieSB0aGUgVENQIHN0YWNrIGFuZCBoYXZlIGxpbWl0ZWQgc2l6ZSwgdGhvc2UNCj4gPiA+ID4g PiBzcGVjaWFsaXNlZCBwcm90b2NvbHMgd291bGQgdXNlIGFwcGxpY2F0aW9uLWxldmVsIGNvb2tp ZXMgd2hpY2gNCj4gPiA+ID4gPiBjYW4gYmUgbG9uZ2VyIGFuZCBhcmUgbWFuYWdlZCBieSB0aGVz ZSBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQo+ID4gPiA+ID4gSSBzZWUuIHRob3VnaCBJIHN1cHBv c2UgdGhpcyByZXF1aXJlcyBjaGFuZ2luZyBSRkM3OTMgb2Ygbm90DQo+ID4gPiA+ID4gdXBsb2Fk aW5nIHRoZSBkYXRhIHRvIGFwcGxpY2F0aW9uIHVudGlsIDNXSFMgY29tcGxldGVzLg0KPiA+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPiA+IFtNZWRdIFRoYXQgY29uc3RyYWludCBjYW4gYmUgcmVsYXhl ZCBmb2xsb3dpbmcgYSByYXRpb25hbGUgc2ltaWxhcg0KPiA+ID4gPiB0bw0KPiA+ID4gdGhlIG9u ZSBpbiBSRkM3NDEzLg0KPiA+ID4gPg0KPiA+ID4gPiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciBy ZWFzb24gd2h5IGEgY2hhbmdlIHRvIFJGQzc5MyB3b3VsZCBiZQ0KPiA+ID4gPiByZXF1aXJlZA0K PiA+ID4gaGVyZSBidXQgbm90IGZvciBSRkM3NDEzPw0KPiA+ID4gSXQncyBhbiBpbnRlcmVzdGlu ZyBxdWVzdGlvbiAtDQo+ID4gPg0KPiA+ID4gUkZDNzkzIGxvbmcgYWxsb3dzIGRhdGEtaW4tU1lO IGJ1dCByZXF1aXJlcyBkYXRhIHRvIGJlIHBvc3RlZCBhZnRlcg0KPiA+ID4gaGFuZHNoYWtlLiBS RkM3NDEzIHJlbGF4ZXMgdGhhdCBidXQgYWxzbyByZXF1aXJlcyBhIGNvb2tpZS4NCj4gPiA+DQo+ ID4gPiBTbyBpZiB3ZSB0aGluayB0aGlzIGlzIGFuICJleHRlbnNpb24iIHRvIFRGTywgdGhlbiBw ZXJoYXBzIGV4dGVuZHMNCj4gPiA+IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8gcGVyc29u YWxseSBJIGRvIHRoaW5rIHRoYXQgbWFrZXMgc2Vuc2UuDQo+ID4gPiBJTU8gVEZPIGltcGxlbWVu dGF0aW9uIHByb3ZpZGVzIGEgZ2VuZXJpYyB3YXkgdG8gZG8gZGF0YS1pbi1TWU4uDQo+ID4gPiBB cHBsaWNhdGlvbiBjYW4gdXNlIHdoYXRldmVyIHRoZXkgcHJlZmVyIHRvIHByb3RlY3Qgb3Igb3B0 aW1pemUNCj4gPiA+IGRhdGEtaW4tIFNZTi4gVEZPIGNvb2tpZSBpcyBqdXN0IGEgZGVmYXVsdCBz aW1wbGUgbWVjaGFuaXNtIGZvcg0KPiA+ID4gYXBwbGljYXRpb24gd2hvIGZpbmRzIHRoYXQgYWNj ZXB0YWJsZS4NCj4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gPiBvdGhl cndpc2Ugb2J2aW91c2x5IGFwcGxpY2F0aW9uIGNhbiBwbGFjZSBhbnkgZGF0YSBpbiB0aGVpcg0K PiA+ID4gPiA+ID4gPiBUQ1ANCj4gPiA+ID4gPiBwYXlsb2FkIGZvciBpdHMNCj4gPiA+ID4gPiA+ ID4gcHVycG9zZXMuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gVGhpcyBpcyB3aGF0IHdlIHBy b3Bvc2VkIGluIFByYWd1ZSwgaS5lLiB1c2luZyBkYXRhIGluIHRoZSBUQ1ANCj4gPiA+ID4gPiA+ IFNZTg0KPiA+ID4gPiA+IHdpdGhvdXQgdGhlIFRGTyBvcHRpb24uDQo+ID4gPiA+ID4gPg0KPiA+ ID4gPiA+ID4NCj4gPiA+ID4gPiA+IE9saXZpZXINCj4gPiA+ID4gPiA+IC0tDQo+ID4gPiA+ID4g Pg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IERpc2NsYWltZXI6DQo+ID4gPiA+ID4gPiBodHRw czovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlDQo+ID4gPiA+ID4gPiAyRg0KPiA+ID4gPiA+ID4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPXd3dy50ZXNzYXJlcw0KPiA+ID4gPiA+ID4gLm5l dCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDZDY2NDExNTc2ZGNj NGU5Yw0KPiA+ID4gPiA+ID4gMmM5MzA4ZDZlMjk3YzE4YyU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2Mw0KPiA+ID4gPiA+ID4gNjk0NTUzODc0Njk3Mjc1NCZh bXA7c2RhdGE9WkhmdDR5ZDc5UjBJbThJMjdLTTlkRVRDWWdFaHBjM3psOWpKdw0KPiA+ID4gPiA+ ID4gdnhZWldjJTNEJmFtcDtyZXNlcnZlZD0wJTJGbWFpbC1kaXNjbGFpbWVyJTJGJmFtcDtkYXRh PTAyJTdDMDElNw0KPiA+ID4gPiA+ID4gQ3ByYXZiJTQwbQ0KPiA+ID4gPiA+ID4gaWNyb3NvZnQu Y29tJTdDNTJmNzZkNmI0ODUyNGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MQ0K PiA+ID4gPiA+ID4gYWYNCj4gPiA+ID4gPiA+IDkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz Njk0MzA2OTA4MTYzNjc4MCZhbXA7c2RhdGE9aHhrZmo4YnkNCj4gPiA+ID4gPiA+IElNDQo+ID4g PiA+ID4gPiBUeGgyVXdRQmp6JTJCb1A4b0J3MyUyRlJpWU1HRzNFTUVvclE0JTNEJmFtcDtyZXNl cnZlZD0wDQo+ID4gPiA+ID4gPiA8aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGDQo+ID4gPiA+ID4gPiAlMg0KPiA+ID4gPiA+ID4g Rnd3dy50ZXNzYXJlcy5uZXQlMkZtYWlsLWRpc2NsYWltZXIlMkYmYW1wO2RhdGE9MDIlN0MwMSU3 Q3ByYXZiJQ0KPiA+ID4gPiA+ID4gNDANCj4gPiA+ID4gPiA+IG1pY3Jvc29mdC5jb20lN0M1MmY3 NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJmODZmMTQNCj4gPiA+ID4gPiA+ IDFhDQo+ID4gPiA+ID4gPiBmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTQzMDY5MDgx NjM2NzgwJmFtcDtzZGF0YT1oeGtmajhiDQo+ID4gPiA+ID4gPiB5SSBNVHhoMlV3UUJqeiUyQm9Q OG9CdzMlMkZSaVlNR0czRU1Fb3JRNCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4gPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ ID4gPiA+IHRjcG1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkYNCj4gPiA+ID4gPiB3dw0K PiA+ID4gPiA+IHcuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRh PTAyJTdDMDElN0NwcmF2YiU0MA0KPiA+ID4gPiA+IG1pDQo+ID4gPiA+ID4gY3Jvc29mdC5jb20l N0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJmODZmMTQxYWY5DQo+ ID4gPiA+ID4gMWENCj4gPiA+ID4gPiBiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NDMwNjkw ODE2MzY3ODAmYW1wO3NkYXRhPTFscnJNSDkyakhMaDUNCj4gPiA+ID4gPiBkcQ0KPiA+ID4gPiA+ IFU0cTMzeUslMkZLZzBMdlhKS0dSM2dsY25iQWVyOCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPiA+ID4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ID4gdGNwbUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGd3d3Lg0KPiA+ID4gaWV0Zg0KPiA+ID4gLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRj cG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0Lg0KPiA+ID4gY29tJQ0KPiA+ ID4gN0M1MmY3NmQ2YjQ4NTI0ZWEzM2RmYzA4ZDZlMDU4YmRhOCU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JQ0KPiA+ID4gN0MxJQ0KPiA+ID4gN0MwJTdDNjM2OTQzMDY5MDgxNjM2 NzgwJmFtcDtzZGF0YT0xbHJyTUg5MmpITGg1ZHFVNHEzM3lLJTJGS2cwTHZYSktHUg0KPiA+ID4g M2dsYw0KPiA+ID4gbmJBZXI4JTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Wed May 29 00:50:06 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3A3120242 for ; Wed, 29 May 2019 00:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.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 qzb5jLeskKzY for ; Wed, 29 May 2019 00:49:50 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 B2C4A12012C for ; Wed, 29 May 2019 00:49:49 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id t4so936654wrx.7 for ; Wed, 29 May 2019 00:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to:content-transfer-encoding; bh=zgFaEUa93G5+PFzZ77/+5LDDJVD3Tf8Itmt+YdFZ728=; b=mhj2K5opftWvlQr94NnNEwCZ8Oc78N4d1RvqfoRL+J8sF2ViUZeEdGLLrs5S52vieO qp2ZkfmBajYTR1r53FldooQ50wezph/HQI0I6FzenXH3euXGDbmlBeKRyelUi+VtR0TK mgOHoXBz2U2FrzSqyD3UEcTadw5idTfdFut5wFSpoZzDiurQT3SfKn0vqLswdGuViZdG bf5gSKEE1eqQ8C+x225aVS2+kq7xDlbdGcj+tfMw18tfCH2iC/+GNJQPCyA4aqEMKoiS MJA32JLfS+Zqd9k7yIIlv4+iFKCZV1YHHpP5MIlR8nj53kcYdoyRx1Lpf1B0R23OwON0 8uDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:content-transfer-encoding; bh=zgFaEUa93G5+PFzZ77/+5LDDJVD3Tf8Itmt+YdFZ728=; b=CBpd48YJPcRr3eNWEMq7hkz55So5M708ypqcayEZMO3o9BsnTeAqeWhnsqXxduJLv7 wh0+8zCCNx0MB0KC8u+nr07OZBljifcO4HEDFnhXHZRzVtla9Po2swiYRPHZsZsxmpFG vc3ncZ+Q+XFmJXWIOezNIRyfCROZk55FcqfgxjzAuiwy0v+lDMBHdDlnbGCCVP81XKFs +HLThOYT15+sZtQvn7MtGCnZnIZQdwgXU0DbOOAznRm82vWOkzRwuQ3J2QM655TqtVx/ oMBX4yGeoC3dX9nx5qCpFCTT/4yq5dZKh+Vr6SYkV8pnHVfPjQPjjkHBRnEdNgsvoUMs z63g== X-Gm-Message-State: APjAAAW97xAfvEOuUpV7XTR594bXXdp/o1hcDG0je87AcruvT/ArtK6m JcY6wdlxzeeVqvc6ueQiIb/Wz9xGTbk7cCF7y9p58avyJ2C1vITyAQqmjYwXQxThinSoTwz4 X-Google-Smtp-Source: APXvYqzIB4bIEeKtLpm3LblOoQJ5AIF1Dqg1IPF9etutlbsM6yDvQ0wXqtkYZvFmxH1OlKlr79iLvg== X-Received: by 2002:adf:e481:: with SMTP id i1mr1582067wrm.113.1559116187817; Wed, 29 May 2019 00:49:47 -0700 (PDT) Received: from [10.44.66.8] (hag0-main.tessares.net. [87.98.252.165]) by smtp.gmail.com with ESMTPSA id f65sm5680963wmg.45.2019.05.29.00.49.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 00:49:47 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Olivier Bonaventure In-Reply-To: Date: Wed, 29 May 2019 09:49:45 +0200 Cc: "mohamed.boucadair@orange.com" , Yuchung Cheng , "tcpm@ietf.org" Message-Id: <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3445.104.11) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 07:50:05 -0000 Praveen, > On 28 May 2019, at 17:22, Praveen Balasubramanian wrote: >=20 > TFO is a new RFC and server is opting in to receive early data which impl= ies being aware of the replay issues. The same applies to draft-ietf-tcpm-converters, the server opts to receive = early data and is aware of the replay issues. > If the TFO state machine succeeds (valid cookie with data in SYN) only th= en the application can retrieve data even before handshake completes. >=20 The only difference with RFC7413 is that the server itself manages the cook= ie and checks its validity. Once the cookie has been validated, it can proc= ess the other elements of the payload. > Without TFO, the standard sockets API does not allow an application to re= ceive data before 3WHS completes, even if data is received in the SYN. > What you seem to be asking for is a modification of 793 and/or API behavi= or which will need a new opt-in socket option for preserving compat for exi= sting applications.=20 Yes, but as already mentioned, this behaviour is already implemented on the= Linux and Apple stacks. This has probably been motivated by other use case= s. Olivier > -----Original Message----- > From: mohamed.boucadair@orange.com =20 > Sent: Monday, May 27, 2019 4:38 AM > To: Praveen Balasubramanian ; Yuchung Cheng > Cc: tcpm@ietf.org > Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters >=20 > Hi Praveen, >=20 > Please see inline.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Praveen Balasubramanian [mailto:pravb@microsoft.com] Envoy=C3=A9 := =20 >> vendredi 24 mai 2019 18:45 =C3=80 : Yuchung Cheng; BOUCADAIR Mohamed=20 >> TGI/OLN Cc : tcpm@ietf.org Extensions Objet : RE: [tcpm] Progressing=20 >> draft-ietf-tcpm-converters >>=20 >> Agreed and I had raised the same question before: " Isn't passing data= =20 >> in the SYN up to the application before 3WHS invalid per RFC 793? >=20 > [Med] This is similar to what TFO does. Both (i.e., TFO and the applicati= on-based cookie) are relaxing that constraint from 793.=20 >=20 > How is the >> converter (T) extracting the server IP address and port from the SYN=20 >> payload? Is it running some custom TCP implementation that violates 793?= " >> 7413 allows nil-cookie and app can encode cookie and data in SYN if it= =20 >> wants. If TFO option is not used at all then it would be a change to=20 >> 793 and not 7413. >=20 > [Med] This is what the initial message from Olivier tried to address. The= issue is what is the point in enclosing the TFO option if the cookie is su= pplied by the application? The same protection level can be provided with t= he application-supplied cookie without requiring to insert the TFO option. = =20 >=20 >>=20 >> -----Original Message----- >> From: tcpm On Behalf Of Yuchung Cheng >> Sent: Friday, May 24, 2019 8:01 AM >> To: mohamed.boucadair@orange.com >> Cc: tcpm@ietf.org Extensions >> Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters >>=20 >> On Thu, May 23, 2019 at 11:34 PM wrote: >>>=20 >>> Hi Yuchung, >>>=20 >>> Please see inline. >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung=20 >>>> Cheng Envoy=C3=A9 : jeudi 23 mai 2019 18:38 =C3=80 : Olivier Bonaventu= re Cc : >>>> tcpm@ietf.org Extensions Objet : Re: [tcpm] Progressing=20 >>>> draft-ietf-tcpm-converters >>>>=20 >>>> On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure=20 >>>> wrote: >>>>>=20 >>>>> Yuchung, >>>>>=20 >>>>>>>=20 >>>>>>> We believe that a specialised TCP application should be=20 >>>>>>> allowed to >>>> use its own cookie inside the payload instead of relying on the=20 >>>> TCP header to use fast open. The 0-RTT convert protocol is one=20 >>>> example, but there could be others. Looking at other application=20 >>>> layer protocols, I noticed that TLS1.3 (rfc8446) also includes a=20 >>>> cookie which is mainly designed enable servers to get a=20 >>>> confirmation of the reachability of the client IP addresses for=20 >>>> DTLS, but the same approach could be used when TLS sends its=20 >>>> initial data in the SYN as >> well. >>>>>>>=20 >>>>>>> Another point that should be clarified in RFC7413 are how=20 >>>>>>> middleboxes >>>> should handle SYN packets containing a non-zero payload. According=20 >>>> to RFC793, such packets are valid TCP packets. The TFO option,=20 >>>> defined in >>>> RFC7314 is not and should not be considered as an indication that=20 >>>> is required to =E2=80=9Cauthorise=E2=80=9D the utilisation of payload = inside a SYN >> packet. >>>> During the Prague meeting, Christoph Paasch mentioned at the mike=20 >>>> that they have one application that uses data inside the SYN and=20 >>>> their measurements indicate that sending this SYN without the TFO=20 >>>> option enables it to pass through more middleboxes than when the=20 >>>> same SYN contains the TFO option. >>>>>>>=20 >>>>>>> Another point is the socket API. Currently, Linux and MacOS=20 >>>>>>> decouple >>>> the transmission of data inside the SYN from the utilisation of=20 >>>> the TFO option. This makes it possible for a client to send data=20 >>>> inside the SYN without enabling TFO. On Windows, the API seems to=20 >>>> force the utilisation of TFO when there is data in the SYN. As=20 >>>> indicated earlier, RFC793 does not mandate the presence of the TFO=20 >>>> to place data >> inside the SYN. >>>>>>>=20 >>>>>>> The approach we are proposing has the benefits of RFC7413 but=20 >>>>>>> without >>>> its drawbacks. Moreover, given that RFC7413 is Experimental, we=20 >>>> don't think that there is a harm if we proceed with the approach=20 >>>> 0-rtt convert protocol while the IETF can further tweak and adjust=20 >>>> the applicability scope of RFC7413. For example, an update can be=20 >>>> proposed to RFC7413 to clarify that specialized application-level=20 >>>> protocols could place cookie information in their payload and thus=20 >>>> not >> use the TFO option. >>>>>> Just to confirm: you mean an API that let application sets the=20 >>>>>> TFO cookie (on either server and client)? >>>>>=20 >>>>>=20 >>>>> No, we suggest to let specific applications use data in the SYN=20 >>>>> without >>>> using the TFO cookie. Those applications can manage their cookie=20 >>>> inside the SYN payload if needed. Instead of having TFO cookies=20 >>>> that are managed by the TCP stack and have limited size, those=20 >>>> specialised protocols would use application-level cookies which=20 >>>> can be longer and are managed by these application protocols. >>>> I see. though I suppose this requires changing RFC793 of not=20 >>>> uploading the data to application until 3WHS completes. >>>>=20 >>>=20 >>> [Med] That constraint can be relaxed following a rationale similar=20 >>> to >> the one in RFC7413. >>>=20 >>> Is there any particular reason why a change to RFC793 would be=20 >>> required >> here but not for RFC7413? >> It's an interesting question - >>=20 >> RFC793 long allows data-in-SYN but requires data to be posted after=20 >> handshake. RFC7413 relaxes that but also requires a cookie. >>=20 >> So if we think this is an "extension" to TFO, then perhaps extends >> RFC7413 not changing RFC793? personally I do think that makes sense. >> IMO TFO implementation provides a generic way to do data-in-SYN. >> Application can use whatever they prefer to protect or optimize=20 >> data-in- SYN. TFO cookie is just a default simple mechanism for=20 >> application who finds that acceptable. >>=20 >>>=20 >>>>>=20 >>>>>> otherwise obviously application can place any data in their=20 >>>>>> TCP >>>> payload for its >>>>>> purposes. >>>>>=20 >>>>> This is what we proposed in Prague, i.e. using data in the TCP=20 >>>>> SYN >>>> without the TFO option. >>>>>=20 >>>>>=20 >>>>> Olivier >>>>> -- >>>>>=20 >>>>>=20 >>>>> Disclaimer: >>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F% >>>>> 2F=20 >>>>> https://nam06.safelinks.protection.outlook.com/?url=3Dwww.tessares >>>>> .net&data=3D02%7C01%7Cpravb%40microsoft.com%7Cd66411576dcc4e9c >>>>> 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 >>>>> 6945538746972754&sdata=3DZHft4yd79R0Im8I27KM9dETCYgEhpc3zl9jJw >>>>> vxYZWc%3D&reserved=3D0%2Fmail-disclaimer%2F&data=3D02%7C01%7 >>>>> Cpravb%40m=20 >>>>> icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141 >>>>> af=20 >>>>> 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhxkfj8by >>>>> IM >>>>> Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0 >>>>> >>>> %2 >>>>> Fwww.tessares.net%2Fmail-disclaimer%2F&data=3D02%7C01%7Cpravb% >>>>> 40=20 >>>>> microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f14 >>>>> 1a=20 >>>>> f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhxkfj8b >>>>> yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0> >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F >>>> ww=20 >>>> w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40 >>>> mi=20 >>>> crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af9 >>>> 1a=20 >>>> b2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3D1lrrMH92jHLh5 >>>> dq >>>> U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&reserved=3D0 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> ietf=20 >> .org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft. >> com%=20 >> 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db47% >> 7C1%=20 >> 7C0%7C636943069081636780&sdata=3D1lrrMH92jHLh5dqU4q33yK%2FKg0LvXJKGR >> 3glc >> nbAer8%3D&reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 From nobody Wed May 29 09:27:55 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C7112015F for ; Wed, 29 May 2019 09:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 PO6QvP8Tw8Xp for ; Wed, 29 May 2019 09:27:50 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0277B1201D7 for ; Wed, 29 May 2019 09:27:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=NDKpNtD5yNKMPECpSlHPlPBZa/6+RJ7ehf5vvGAIV/Nlma9wciYjkXTIWjyNVKR95hsuDiJMdcceIuDt6ZMQoMQDepv0ozSjGBTMyHx6FxKu6OXmyDT/JWS/JU9zWHmy81Yq6tfpuJOxYmf99B4dWWTBGOOEcLVjEz3n6dLQCWA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pIl/lxKm7M60FLrtzSRPwHrq67erdEFdcMkpK2WMLkw=; b=AxOZKxWWQLdF0XGvUmGvVAxZ7Vkxd3DGQZHVRZ0r/LPhzXxyKNVm4nocOIM4NbmpXnDqsVfGtVOM8UjzOO+tu8SoJTZtu/wgQSto+ffS/mEKrDM2/SnnQm356kGswRcRGGnRA2b0oQg0Y8PUO847V0Hg4kN2qj3v3cdBAM07Tfw= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pIl/lxKm7M60FLrtzSRPwHrq67erdEFdcMkpK2WMLkw=; b=ROmg9uu3CD65DpyKwA3UbagQ7Cyt1pAHIO65Osuq7FRG03CXHZVGTvULCuBSi8WvQx2HzqEDZG5i+SbZgiU/cWVHw9JwjEJrJe32SLIyv5B/nKRuOrrEWymsVss5x/YnXFrTDGAS/d+WjXJn5M3PtQpLbmAjz3e/w9HjBH3TT04= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (2603:10b6:302:a::13) by MW2PR2101MB1001.namprd21.prod.outlook.com (2603:10b6:302:4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.1; Wed, 29 May 2019 16:27:41 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::1486:9c49:385b:f1a2%4]) with mapi id 15.20.1965.003; Wed, 29 May 2019 16:27:41 +0000 From: Praveen Balasubramanian To: Olivier Bonaventure CC: "mohamed.boucadair@orange.com" , Yuchung Cheng , "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVDy6HMMq1d9rUjkC05hHsqCIciaZ0Q0IAgAE1qACAA3SNAIABd2QegAAbJQCABGLcAIABzvvggAEV9YCAAI+/EA== Date: Wed, 29 May 2019 16:27:41 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> In-Reply-To: <4258DCF5-1588-4B97-9C05-F0722E053072@tessares.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=pravb@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-05-29T16:27:40.5468642Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=445b61bd-9082-4beb-83c2-a998571e086e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:f:a201:d1d6:6aa7:8c15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5eb7184-264b-4525-09d8-08d6e45292b2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1001; x-ms-traffictypediagnostic: MW2PR2101MB1001: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(366004)(376002)(136003)(199004)(189003)(13464003)(99286004)(7696005)(6916009)(14454004)(486006)(8936002)(476003)(76176011)(64756008)(6436002)(66476007)(6506007)(53546011)(229853002)(25786009)(46003)(4326008)(102836004)(86362001)(446003)(81166006)(8676002)(81156014)(2906002)(11346002)(186003)(52396003)(74316002)(6116002)(33656002)(30864003)(52536014)(66446008)(73956011)(66946007)(53936002)(6246003)(66556008)(6306002)(9686003)(55016002)(76116006)(54906003)(966005)(316002)(68736007)(10090500001)(7736002)(478600001)(71190400001)(22452003)(256004)(14444005)(5660300002)(8990500004)(10290500003)(305945005)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1001; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kZn5M/63Dmwxg89n8Xg0P/uqqCV1vZTsT0jkQcJTn2T0ov0Am3/VmKgmBM8H2axSuo0l4nbqCAtMUNgAT+oaVZ9fAbZYvPzMX6OWiypvqKCMXGp1oaUGqXQPUvBhOXZ5/b6MYc16q258HDuJL0YoL9kMUOZeDmljmhOMHq1NDCO/Bkw52SPhCH3VqLJwtIxyZl9eT3ZDRqoE57xPU9g1Xyz9r4fpMccyfLzO4gNRZDohII8TP5s/60hF+ozdRpI4PrQw2iBLR8tjwjrdOqvCJLGz/YzQ4re4X+3029eww0bDxSE3UP7yIkzrtwTyVgKwG4KB0JJQZfQ+hMnJ1wiAXscbsVtR6MpAhNaxxp85U1Z7EZNKWQEL6Ij9mupuUIl/c4YKXbYSmKufdeRcYqIWA0Aq38/jdSMEOddcVAY/NQI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5eb7184-264b-4525-09d8-08d6e45292b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 16:27:41.8676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pravb@ntdev.microsoft.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1001 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 16:27:54 -0000 VGhlc2UgYXJlIHR3byBkaWZmZXJlbnQgdGhpbmdzLg0KMS4gQWJpbGl0eSB0byBTRU5EIGRhdGEg aW4gU1lOIHBheWxvYWQgb24gY2xpZW50LiBUaGlzIGlzIG9ubHkgc3VwcG9ydGVkIG9uIExpbnV4 IGFuZCBtYWNPUyB3aGVuIFRGTyBBUEkgaXMgbm90IHVzZWQuIE9uIFdpbmRvd3MgdGhlIG9ubHkg d2F5IHRvIGFjaGlldmUgdGhpcyBpcyB1c2luZyB0aGUgVEZPIEFQSS4gSWYgVEZPIEFQSSBpcyBu b3QgdXNlZCBXaW5kb3dzIHN0YWNrIHdpbGwgYnVmZmVyIHRoZSBkYXRhIHRvIGJlIHNlbnQgKmFm dGVyKiAzV0hTIGNvbXBsZXRlcy4gDQoyLiBBYmlsaXR5IHRvIFJFQ0VJVkUgZGF0YSBpbiBTWU4g cGF5bG9hZCBvbiBzZXJ2ZXIuIFRoaXMgaXMgb25seSBzdXBwb3J0ZWQgb24gYWxsIE9TICphZnRl ciogM1dIUyBpcyBjb21wbGV0ZWQuIFRoaXMgaXMgcGVyIFJGQyA3OTMuIFRoZSBvbmx5IGV4Y2Vw dGlvbiBpcyBpZiBURk8gQVBJIGlzIHVzZWQsIGFuZCB0aGVuIGlmIGNvb2tpZSBpcyB2YWxpZGF0 ZWQgdGhlIGFwcGxpY2F0aW9uIHdpbGwgIHJlY2VpdmUgZWFybHktZGF0YS4gVGhlcmUgaXMgbm8g d2F5IHRvIHJldHJpZXZlIGVhcmx5IGRhdGEgb3RoZXJ3aXNlLiANCg0KWXVjaHVuZyBhbmQgSSBh cmUgcG9pbnRpbmcgdG8gYnVsbGV0IDIgYXMgcmVxdWlyaW5nIGEgUkZDIG1vZGlmaWNhdGlvbiAv IEFQSSBtb2RpZmljYXRpb24uIERvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2xpdmllciBCb25hdmVudHVyZSA8b2xpdmllci5ib25hdmVu dHVyZUB0ZXNzYXJlcy5uZXQ+IA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjksIDIwMTkgMTI6NTAg QU0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNj OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29v Z2xlLmNvbT47IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gUHJvZ3Jlc3Npbmcg ZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCg0KUHJhdmVlbiwNCg0KPiBPbiAyOCBNYXkgMjAx OSwgYXQgMTc6MjIsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29mdC5j b21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gVEZPIGlzIGEgbmV3IFJGQyBhbmQgc2Vy dmVyIGlzIG9wdGluZyBpbiB0byByZWNlaXZlIGVhcmx5IGRhdGEgd2hpY2ggaW1wbGllcyBiZWlu ZyBhd2FyZSBvZiB0aGUgcmVwbGF5IGlzc3Vlcy4NCg0KVGhlIHNhbWUgYXBwbGllcyB0byBkcmFm dC1pZXRmLXRjcG0tY29udmVydGVycywgdGhlIHNlcnZlciBvcHRzIHRvIHJlY2VpdmUgZWFybHkg ZGF0YSBhbmQgaXMgYXdhcmUgb2YgdGhlIHJlcGxheSBpc3N1ZXMuDQoNCj4gSWYgdGhlIFRGTyBz dGF0ZSBtYWNoaW5lIHN1Y2NlZWRzICh2YWxpZCBjb29raWUgd2l0aCBkYXRhIGluIFNZTikgb25s eSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBjYW4gcmV0cmlldmUgZGF0YSBldmVuIGJlZm9yZSBoYW5k c2hha2UgY29tcGxldGVzLg0KPiANCg0KVGhlIG9ubHkgZGlmZmVyZW5jZSB3aXRoIFJGQzc0MTMg aXMgdGhhdCB0aGUgc2VydmVyIGl0c2VsZiBtYW5hZ2VzIHRoZSBjb29raWUgYW5kIGNoZWNrcyBp dHMgdmFsaWRpdHkuIE9uY2UgdGhlIGNvb2tpZSBoYXMgYmVlbiB2YWxpZGF0ZWQsIGl0IGNhbiBw cm9jZXNzIHRoZSBvdGhlciBlbGVtZW50cyBvZiB0aGUgcGF5bG9hZC4NCg0KPiBXaXRob3V0IFRG TywgdGhlIHN0YW5kYXJkIHNvY2tldHMgQVBJIGRvZXMgbm90IGFsbG93IGFuIGFwcGxpY2F0aW9u IHRvIHJlY2VpdmUgZGF0YSBiZWZvcmUgM1dIUyBjb21wbGV0ZXMsIGV2ZW4gaWYgZGF0YSBpcyBy ZWNlaXZlZCBpbiB0aGUgU1lOLg0KPiBXaGF0IHlvdSBzZWVtIHRvIGJlIGFza2luZyBmb3IgaXMg YSBtb2RpZmljYXRpb24gb2YgNzkzIGFuZC9vciBBUEkgYmVoYXZpb3Igd2hpY2ggd2lsbCBuZWVk IGEgbmV3IG9wdC1pbiBzb2NrZXQgb3B0aW9uIGZvciBwcmVzZXJ2aW5nIGNvbXBhdCBmb3IgZXhp c3RpbmcgYXBwbGljYXRpb25zLiANCg0KWWVzLCBidXQgYXMgYWxyZWFkeSBtZW50aW9uZWQsIHRo aXMgYmVoYXZpb3VyIGlzIGFscmVhZHkgaW1wbGVtZW50ZWQgb24gdGhlIExpbnV4IGFuZCBBcHBs ZSBzdGFja3MuIFRoaXMgaGFzIHByb2JhYmx5IGJlZW4gbW90aXZhdGVkIGJ5IG90aGVyIHVzZSBj YXNlcy4NCg0KDQpPbGl2aWVyDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tPg0KPiBTZW50OiBNb25kYXksIE1heSAyNywgMjAxOSA0OjM4IEFNDQo+IFRvOiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IFl1Y2h1bmcgQ2hlbmcg DQo+IDx5Y2hlbmc9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPg0KPiBDYzogdGNwbUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSRTogW3RjcG1dIFByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGNwbS1j b252ZXJ0ZXJzDQo+IA0KPiBIaSBQcmF2ZWVuLA0KPiANCj4gUGxlYXNlIHNlZSBpbmxpbmUuIA0K PiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0N Cj4+IERlIDogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gW21haWx0bzpwcmF2YkBtaWNyb3NvZnQu Y29tXSBFbnZvecOpIDogDQo+PiB2ZW5kcmVkaSAyNCBtYWkgMjAxOSAxODo0NSDDgCA6IFl1Y2h1 bmcgQ2hlbmc7IEJPVUNBREFJUiBNb2hhbWVkIA0KPj4gVEdJL09MTiBDYyA6IHRjcG1AaWV0Zi5v cmcgRXh0ZW5zaW9ucyBPYmpldCA6IFJFOiBbdGNwbV0gUHJvZ3Jlc3NpbmcgDQo+PiBkcmFmdC1p ZXRmLXRjcG0tY29udmVydGVycw0KPj4gDQo+PiBBZ3JlZWQgYW5kIEkgaGFkIHJhaXNlZCB0aGUg c2FtZSBxdWVzdGlvbiBiZWZvcmU6ICIgSXNuJ3QgcGFzc2luZyANCj4+IGRhdGEgaW4gdGhlIFNZ TiB1cCB0byB0aGUgYXBwbGljYXRpb24gYmVmb3JlIDNXSFMgaW52YWxpZCBwZXIgUkZDIDc5Mz8N Cj4gDQo+IFtNZWRdIFRoaXMgaXMgc2ltaWxhciB0byB3aGF0IFRGTyBkb2VzLiBCb3RoIChpLmUu LCBURk8gYW5kIHRoZSBhcHBsaWNhdGlvbi1iYXNlZCBjb29raWUpIGFyZSByZWxheGluZyB0aGF0 IGNvbnN0cmFpbnQgZnJvbSA3OTMuIA0KPiANCj4gSG93IGlzIHRoZQ0KPj4gY29udmVydGVyIChU KSBleHRyYWN0aW5nIHRoZSBzZXJ2ZXIgSVAgYWRkcmVzcyBhbmQgcG9ydCBmcm9tIHRoZSBTWU4g DQo+PiBwYXlsb2FkPyBJcyBpdCBydW5uaW5nIHNvbWUgY3VzdG9tIFRDUCBpbXBsZW1lbnRhdGlv biB0aGF0IHZpb2xhdGVzIDc5Mz8iDQo+PiA3NDEzIGFsbG93cyBuaWwtY29va2llIGFuZCBhcHAg Y2FuIGVuY29kZSBjb29raWUgYW5kIGRhdGEgaW4gU1lOIGlmIA0KPj4gaXQgd2FudHMuIElmIFRG TyBvcHRpb24gaXMgbm90IHVzZWQgYXQgYWxsIHRoZW4gaXQgd291bGQgYmUgYSBjaGFuZ2UgDQo+ PiB0bw0KPj4gNzkzIGFuZCBub3QgNzQxMy4NCj4gDQo+IFtNZWRdIFRoaXMgaXMgd2hhdCB0aGUg aW5pdGlhbCBtZXNzYWdlIGZyb20gT2xpdmllciB0cmllZCB0byBhZGRyZXNzLiBUaGUgaXNzdWUg aXMgd2hhdCBpcyB0aGUgcG9pbnQgaW4gZW5jbG9zaW5nIHRoZSBURk8gb3B0aW9uIGlmIHRoZSBj b29raWUgaXMgc3VwcGxpZWQgYnkgdGhlIGFwcGxpY2F0aW9uPyBUaGUgc2FtZSBwcm90ZWN0aW9u IGxldmVsIGNhbiBiZSBwcm92aWRlZCB3aXRoIHRoZSBhcHBsaWNhdGlvbi1zdXBwbGllZCBjb29r aWUgd2l0aG91dCByZXF1aXJpbmcgdG8gaW5zZXJ0IHRoZSBURk8gb3B0aW9uLiAgDQo+IA0KPj4g DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdGNwbSA8dGNwbS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWXVjaHVuZyBDaGVuZw0KPj4gU2VudDogRnJpZGF5 LCBNYXkgMjQsIDIwMTkgODowMSBBTQ0KPj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20NCj4+IENjOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQo+PiBT dWJqZWN0OiBSZTogW3RjcG1dIFByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJz DQo+PiANCj4+IE9uIFRodSwgTWF5IDIzLCAyMDE5IGF0IDExOjM0IFBNIDxtb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIaSBZdWNodW5nLA0KPj4+IA0KPj4+ IFBsZWFzZSBzZWUgaW5saW5lLg0KPj4+IA0KPj4+IENoZWVycywNCj4+PiBNZWQNCj4+PiANCj4+ Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+IERlIDogdGNwbSBbbWFpbHRvOnRj cG0tYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBZdWNodW5nIA0KPj4+PiBDaGVuZyBF bnZvecOpIDogamV1ZGkgMjMgbWFpIDIwMTkgMTg6Mzggw4AgOiBPbGl2aWVyIEJvbmF2ZW50dXJl IENjIDoNCj4+Pj4gdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIE9iamV0IDogUmU6IFt0Y3BtXSBQ cm9ncmVzc2luZyANCj4+Pj4gZHJhZnQtaWV0Zi10Y3BtLWNvbnZlcnRlcnMNCj4+Pj4gDQo+Pj4+ IE9uIFR1ZSwgTWF5IDIxLCAyMDE5IGF0IDQ6NTIgQU0gT2xpdmllciBCb25hdmVudHVyZSANCj4+ Pj4gPG9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0PiB3cm90ZToNCj4+Pj4+IA0KPj4+ Pj4gWXVjaHVuZywNCj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gV2UgYmVsaWV2ZSB0aGF0IGEg c3BlY2lhbGlzZWQgVENQIGFwcGxpY2F0aW9uIHNob3VsZCBiZSBhbGxvd2VkIA0KPj4+Pj4+PiB0 bw0KPj4+PiB1c2UgaXRzIG93biBjb29raWUgaW5zaWRlIHRoZSBwYXlsb2FkIGluc3RlYWQgb2Yg cmVseWluZyBvbiB0aGUgVENQIA0KPj4+PiBoZWFkZXIgdG8gdXNlIGZhc3Qgb3Blbi4gVGhlIDAt UlRUIGNvbnZlcnQgcHJvdG9jb2wgaXMgb25lIGV4YW1wbGUsIA0KPj4+PiBidXQgdGhlcmUgY291 bGQgYmUgb3RoZXJzLiBMb29raW5nIGF0IG90aGVyIGFwcGxpY2F0aW9uIGxheWVyIA0KPj4+PiBw cm90b2NvbHMsIEkgbm90aWNlZCB0aGF0IFRMUzEuMyAocmZjODQ0NikgYWxzbyBpbmNsdWRlcyBh IGNvb2tpZSANCj4+Pj4gd2hpY2ggaXMgbWFpbmx5IGRlc2lnbmVkIGVuYWJsZSBzZXJ2ZXJzIHRv IGdldCBhIGNvbmZpcm1hdGlvbiBvZiANCj4+Pj4gdGhlIHJlYWNoYWJpbGl0eSBvZiB0aGUgY2xp ZW50IElQIGFkZHJlc3NlcyBmb3IgRFRMUywgYnV0IHRoZSBzYW1lIA0KPj4+PiBhcHByb2FjaCBj b3VsZCBiZSB1c2VkIHdoZW4gVExTIHNlbmRzIGl0cyBpbml0aWFsIGRhdGEgaW4gdGhlIFNZTiAN Cj4+Pj4gYXMNCj4+IHdlbGwuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBbm90aGVyIHBvaW50IHRoYXQg c2hvdWxkIGJlIGNsYXJpZmllZCBpbiBSRkM3NDEzIGFyZSBob3cgDQo+Pj4+Pj4+IG1pZGRsZWJv eGVzDQo+Pj4+IHNob3VsZCBoYW5kbGUgU1lOIHBhY2tldHMgY29udGFpbmluZyBhIG5vbi16ZXJv IHBheWxvYWQuIEFjY29yZGluZyANCj4+Pj4gdG8gUkZDNzkzLCBzdWNoIHBhY2tldHMgYXJlIHZh bGlkIFRDUCBwYWNrZXRzLiBUaGUgVEZPIG9wdGlvbiwgDQo+Pj4+IGRlZmluZWQgaW4NCj4+Pj4g UkZDNzMxNCBpcyBub3QgYW5kIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBhcyBhbiBpbmRpY2F0 aW9uIHRoYXQgDQo+Pj4+IGlzIHJlcXVpcmVkIHRvIOKAnGF1dGhvcmlzZeKAnSB0aGUgdXRpbGlz YXRpb24gb2YgcGF5bG9hZCBpbnNpZGUgYSBTWU4NCj4+IHBhY2tldC4NCj4+Pj4gRHVyaW5nIHRo ZSBQcmFndWUgbWVldGluZywgQ2hyaXN0b3BoIFBhYXNjaCBtZW50aW9uZWQgYXQgdGhlIG1pa2Ug DQo+Pj4+IHRoYXQgdGhleSBoYXZlIG9uZSBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgZGF0YSBpbnNp ZGUgdGhlIFNZTiBhbmQgDQo+Pj4+IHRoZWlyIG1lYXN1cmVtZW50cyBpbmRpY2F0ZSB0aGF0IHNl bmRpbmcgdGhpcyBTWU4gd2l0aG91dCB0aGUgVEZPIA0KPj4+PiBvcHRpb24gZW5hYmxlcyBpdCB0 byBwYXNzIHRocm91Z2ggbW9yZSBtaWRkbGVib3hlcyB0aGFuIHdoZW4gdGhlIA0KPj4+PiBzYW1l IFNZTiBjb250YWlucyB0aGUgVEZPIG9wdGlvbi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEFub3RoZXIg cG9pbnQgaXMgdGhlIHNvY2tldCBBUEkuIEN1cnJlbnRseSwgTGludXggYW5kIE1hY09TIA0KPj4+ Pj4+PiBkZWNvdXBsZQ0KPj4+PiB0aGUgdHJhbnNtaXNzaW9uIG9mIGRhdGEgaW5zaWRlIHRoZSBT WU4gZnJvbSB0aGUgdXRpbGlzYXRpb24gb2YgdGhlIA0KPj4+PiBURk8gb3B0aW9uLiBUaGlzIG1h a2VzIGl0IHBvc3NpYmxlIGZvciBhIGNsaWVudCB0byBzZW5kIGRhdGEgaW5zaWRlIA0KPj4+PiB0 aGUgU1lOIHdpdGhvdXQgZW5hYmxpbmcgVEZPLiBPbiBXaW5kb3dzLCB0aGUgQVBJIHNlZW1zIHRv IGZvcmNlIA0KPj4+PiB0aGUgdXRpbGlzYXRpb24gb2YgVEZPIHdoZW4gdGhlcmUgaXMgZGF0YSBp biB0aGUgU1lOLiBBcyBpbmRpY2F0ZWQgDQo+Pj4+IGVhcmxpZXIsIFJGQzc5MyBkb2VzIG5vdCBt YW5kYXRlIHRoZSBwcmVzZW5jZSBvZiB0aGUgVEZPIHRvIHBsYWNlIA0KPj4+PiBkYXRhDQo+PiBp bnNpZGUgdGhlIFNZTi4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBhcHByb2FjaCB3ZSBhcmUgcHJv cG9zaW5nIGhhcyB0aGUgYmVuZWZpdHMgb2YgUkZDNzQxMyBidXQgDQo+Pj4+Pj4+IHdpdGhvdXQN Cj4+Pj4gaXRzIGRyYXdiYWNrcy4gTW9yZW92ZXIsIGdpdmVuIHRoYXQgUkZDNzQxMyBpcyBFeHBl cmltZW50YWwsIHdlIA0KPj4+PiBkb24ndCB0aGluayB0aGF0IHRoZXJlIGlzIGEgaGFybSBpZiB3 ZSBwcm9jZWVkIHdpdGggdGhlIGFwcHJvYWNoIA0KPj4+PiAwLXJ0dCBjb252ZXJ0IHByb3RvY29s IHdoaWxlIHRoZSBJRVRGIGNhbiBmdXJ0aGVyIHR3ZWFrIGFuZCBhZGp1c3QgDQo+Pj4+IHRoZSBh cHBsaWNhYmlsaXR5IHNjb3BlIG9mIFJGQzc0MTMuIEZvciBleGFtcGxlLCBhbiB1cGRhdGUgY2Fu IGJlIA0KPj4+PiBwcm9wb3NlZCB0byBSRkM3NDEzIHRvIGNsYXJpZnkgdGhhdCBzcGVjaWFsaXpl ZCBhcHBsaWNhdGlvbi1sZXZlbCANCj4+Pj4gcHJvdG9jb2xzIGNvdWxkIHBsYWNlIGNvb2tpZSBp bmZvcm1hdGlvbiBpbiB0aGVpciBwYXlsb2FkIGFuZCB0aHVzIA0KPj4+PiBub3QNCj4+IHVzZSB0 aGUgVEZPIG9wdGlvbi4NCj4+Pj4+PiBKdXN0IHRvIGNvbmZpcm06IHlvdSBtZWFuIGFuIEFQSSB0 aGF0IGxldCBhcHBsaWNhdGlvbiBzZXRzIHRoZSANCj4+Pj4+PiBURk8gY29va2llIChvbiBlaXRo ZXIgc2VydmVyIGFuZCBjbGllbnQpPw0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IE5vLCB3ZSBzdWdn ZXN0IHRvIGxldCBzcGVjaWZpYyBhcHBsaWNhdGlvbnMgdXNlIGRhdGEgaW4gdGhlIFNZTiANCj4+ Pj4+IHdpdGhvdXQNCj4+Pj4gdXNpbmcgdGhlIFRGTyBjb29raWUuIFRob3NlIGFwcGxpY2F0aW9u cyBjYW4gbWFuYWdlIHRoZWlyIGNvb2tpZSANCj4+Pj4gaW5zaWRlIHRoZSBTWU4gcGF5bG9hZCBp ZiBuZWVkZWQuIEluc3RlYWQgb2YgaGF2aW5nIFRGTyBjb29raWVzIA0KPj4+PiB0aGF0IGFyZSBt YW5hZ2VkIGJ5IHRoZSBUQ1Agc3RhY2sgYW5kIGhhdmUgbGltaXRlZCBzaXplLCB0aG9zZSANCj4+ Pj4gc3BlY2lhbGlzZWQgcHJvdG9jb2xzIHdvdWxkIHVzZSBhcHBsaWNhdGlvbi1sZXZlbCBjb29r aWVzIHdoaWNoIGNhbiANCj4+Pj4gYmUgbG9uZ2VyIGFuZCBhcmUgbWFuYWdlZCBieSB0aGVzZSBh cHBsaWNhdGlvbiBwcm90b2NvbHMuDQo+Pj4+IEkgc2VlLiB0aG91Z2ggSSBzdXBwb3NlIHRoaXMg cmVxdWlyZXMgY2hhbmdpbmcgUkZDNzkzIG9mIG5vdCANCj4+Pj4gdXBsb2FkaW5nIHRoZSBkYXRh IHRvIGFwcGxpY2F0aW9uIHVudGlsIDNXSFMgY29tcGxldGVzLg0KPj4+PiANCj4+PiANCj4+PiBb TWVkXSBUaGF0IGNvbnN0cmFpbnQgY2FuIGJlIHJlbGF4ZWQgZm9sbG93aW5nIGEgcmF0aW9uYWxl IHNpbWlsYXIgDQo+Pj4gdG8NCj4+IHRoZSBvbmUgaW4gUkZDNzQxMy4NCj4+PiANCj4+PiBJcyB0 aGVyZSBhbnkgcGFydGljdWxhciByZWFzb24gd2h5IGEgY2hhbmdlIHRvIFJGQzc5MyB3b3VsZCBi ZSANCj4+PiByZXF1aXJlZA0KPj4gaGVyZSBidXQgbm90IGZvciBSRkM3NDEzPw0KPj4gSXQncyBh biBpbnRlcmVzdGluZyBxdWVzdGlvbiAtDQo+PiANCj4+IFJGQzc5MyBsb25nIGFsbG93cyBkYXRh LWluLVNZTiBidXQgcmVxdWlyZXMgZGF0YSB0byBiZSBwb3N0ZWQgYWZ0ZXIgDQo+PiBoYW5kc2hh a2UuIFJGQzc0MTMgcmVsYXhlcyB0aGF0IGJ1dCBhbHNvIHJlcXVpcmVzIGEgY29va2llLg0KPj4g DQo+PiBTbyBpZiB3ZSB0aGluayB0aGlzIGlzIGFuICJleHRlbnNpb24iIHRvIFRGTywgdGhlbiBw ZXJoYXBzIGV4dGVuZHMNCj4+IFJGQzc0MTMgbm90IGNoYW5naW5nIFJGQzc5Mz8gcGVyc29uYWxs eSBJIGRvIHRoaW5rIHRoYXQgbWFrZXMgc2Vuc2UuDQo+PiBJTU8gVEZPIGltcGxlbWVudGF0aW9u IHByb3ZpZGVzIGEgZ2VuZXJpYyB3YXkgdG8gZG8gZGF0YS1pbi1TWU4uDQo+PiBBcHBsaWNhdGlv biBjYW4gdXNlIHdoYXRldmVyIHRoZXkgcHJlZmVyIHRvIHByb3RlY3Qgb3Igb3B0aW1pemUNCj4+ IGRhdGEtaW4tIFNZTi4gVEZPIGNvb2tpZSBpcyBqdXN0IGEgZGVmYXVsdCBzaW1wbGUgbWVjaGFu aXNtIGZvciANCj4+IGFwcGxpY2F0aW9uIHdobyBmaW5kcyB0aGF0IGFjY2VwdGFibGUuDQo+PiAN Cj4+PiANCj4+Pj4+IA0KPj4+Pj4+IG90aGVyd2lzZSBvYnZpb3VzbHkgYXBwbGljYXRpb24gY2Fu IHBsYWNlIGFueSBkYXRhIGluIHRoZWlyIFRDUA0KPj4+PiBwYXlsb2FkIGZvciBpdHMNCj4+Pj4+ PiBwdXJwb3Nlcy4NCj4+Pj4+IA0KPj4+Pj4gVGhpcyBpcyB3aGF0IHdlIHByb3Bvc2VkIGluIFBy YWd1ZSwgaS5lLiB1c2luZyBkYXRhIGluIHRoZSBUQ1AgU1lODQo+Pj4+IHdpdGhvdXQgdGhlIFRG TyBvcHRpb24uDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gT2xpdmllcg0KPj4+Pj4gLS0NCj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+PiBEaXNjbGFpbWVyOg0KPj4+Pj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJQ0KPj4+Pj4gMkYgDQo+ Pj4+PiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 d3d3LnRlc3NhcmVzDQo+Pj4+PiAubmV0JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jv c29mdC5jb20lN0NkNjY0MTE1NzZkY2M0ZTljDQo+Pj4+PiAyYzkzMDhkNmUyOTdjMThjJTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzDQo+Pj4+PiA2OTQ1NTM4 NzQ2OTcyNzU0JmFtcDtzZGF0YT1aSGZ0NHlkNzlSMEltOEkyN0tNOWRFVENZZ0VocGMzemw5akp3 DQo+Pj4+PiB2eFlaV2MlM0QmYW1wO3Jlc2VydmVkPTAlMkZtYWlsLWRpc2NsYWltZXIlMkYmYW1w O2RhdGE9MDIlN0MwMSU3DQo+Pj4+PiBDcHJhdmIlNDBtIA0KPj4+Pj4gaWNyb3NvZnQuY29tJTdD NTJmNzZkNmI0ODUyNGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MQ0KPj4+Pj4g YWYgDQo+Pj4+PiA5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY5NDMwNjkwODE2MzY3ODAm YW1wO3NkYXRhPWh4a2ZqOGJ5DQo+Pj4+PiBJTQ0KPj4+Pj4gVHhoMlV3UUJqeiUyQm9QOG9CdzMl MkZSaVlNR0czRU1Fb3JRNCUzRCZhbXA7cmVzZXJ2ZWQ9MA0KPj4+Pj4gPGh0dHBzOi8vbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRg0KPj4+Pj4g JTINCj4+Pj4+IEZ3d3cudGVzc2FyZXMubmV0JTJGbWFpbC1kaXNjbGFpbWVyJTJGJmFtcDtkYXRh PTAyJTdDMDElN0NwcmF2YiUNCj4+Pj4+IDQwIA0KPj4+Pj4gbWljcm9zb2Z0LmNvbSU3QzUyZjc2 ZDZiNDg1MjRlYTMzZGZjMDhkNmUwNThiZGE4JTdDNzJmOTg4YmY4NmYxNA0KPj4+Pj4gMWEgDQo+ Pj4+PiBmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2OTQzMDY5MDgxNjM2NzgwJmFtcDtz ZGF0YT1oeGtmajhiDQo+Pj4+PiB5SSBNVHhoMlV3UUJqeiUyQm9QOG9CdzMlMkZSaVlNR0czRU1F b3JRNCUzRCZhbXA7cmVzZXJ2ZWQ9MD4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiB0Y3BtIG1h aWxpbmcgbGlzdA0KPj4+PiB0Y3BtQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vbmFtMDYuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRg0KPj4+PiB3dyAN Cj4+Pj4gdy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIl N0MwMSU3Q3ByYXZiJTQwDQo+Pj4+IG1pIA0KPj4+PiBjcm9zb2Z0LmNvbSU3QzUyZjc2ZDZiNDg1 MjRlYTMzZGZjMDhkNmUwNThiZGE4JTdDNzJmOTg4YmY4NmYxNDFhZjkNCj4+Pj4gMWEgDQo+Pj4+ IGIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0MzA2OTA4MTYzNjc4MCZhbXA7c2RhdGE9MWxy ck1IOTJqSExoNQ0KPj4+PiBkcQ0KPj4+PiBVNHEzM3lLJTJGS2cwTHZYSktHUjNnbGNuYkFlcjgl M0QmYW1wO3Jlc2VydmVkPTANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHRjcG0gbWFpbGluZyBsaXN0DQo+PiB0Y3BtQGlldGYub3Jn DQo+PiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuDQo+PiBpZXRmIA0KPj4gLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRnRjcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0Lg0KPj4gY29tJSAN Cj4+IDdDNTJmNzZkNmI0ODUyNGVhMzNkZmMwOGQ2ZTA1OGJkYTglN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyUNCj4+IDdDMSUgDQo+PiA3QzAlN0M2MzY5NDMwNjkwODE2MzY3ODAm YW1wO3NkYXRhPTFscnJNSDkyakhMaDVkcVU0cTMzeUslMkZLZzBMdlhKS0dSDQo+PiAzZ2xjDQo+ PiBuYkFlcjglM0QmYW1wO3Jlc2VydmVkPTANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9y Zw0KPiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFt cDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxYTE0Mzc2NGFkODk0YjEy N2RiNDA4ZDZlNDBhNGNlZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY5NDcxMzAyMzM3MjU5MzYmYW1wO3NkYXRhPXg1UGRTaXIwVk8wNDBkZUZkaU9lbUJK MW16OTM5TGRZRkxRSlJXZnFmQnMlM0QmYW1wO3Jlc2VydmVkPTANCg0KDQotLSANCg0KDQpEaXNj bGFpbWVyOiBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3cudGVzc2FyZXMubmV0JTJGbWFpbC1kaXNjbGFpbWVyJTJGJmFt cDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxYTE0Mzc2NGFkODk0YjEy N2RiNDA4ZDZlNDBhNGNlZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3 QzAlN0M2MzY5NDcxMzAyMzM3MjU5MzYmYW1wO3NkYXRhPTJrbiUyQnElMkZpZ29iaUhPbDZKUEFO WUVhalF1cGlFdGtGazlSWEdqa2tPUVFZJTNEJmFtcDtyZXNlcnZlZD0wIA0KPGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy50ZXNzYXJlcy5uZXQlMkZtYWlsLWRpc2NsYWltZXIlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3By YXZiJTQwbWljcm9zb2Z0LmNvbSU3QzFhMTQzNzY0YWQ4OTRiMTI3ZGI0MDhkNmU0MGE0Y2VmJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjk0NzEzMDIzMzcy NTkzNiZhbXA7c2RhdGE9MmtuJTJCcSUyRmlnb2JpSE9sNkpQQU5ZRWFqUXVwaUV0a0ZrOVJYR2pr a09RUVklM0QmYW1wO3Jlc2VydmVkPTA+DQoNCg0K From nobody Wed May 29 14:46:22 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7552120148 for ; Wed, 29 May 2019 14:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xsN1VfRpsphc for ; Wed, 29 May 2019 14:46:15 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 1D9AE120169 for ; Wed, 29 May 2019 14:46:15 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id d9so2799763wrx.0 for ; Wed, 29 May 2019 14:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZDof5Sb34nMsPfzavyxwbAeHgkPxSS70jc9x6AHZVM8=; b=rmOSEryJR7mb7117BXZBl/FtJDWEwiHU4Y/XeH2r6qpJZtUlKETnvkvBWd5tAXGfW7 QI9MSC2SSpZ+YkFTYLujXA2zsVv/Ys7BpPBu4qMZ2Rjy+W/xmhPPLCpbZSs5JsdTnsSO 4z1XPQtwGha9XXmFMqITdMYCiI3MPo0XFBeF3ceFPSUtioymKvf1rRA7cCUfp+palrT8 XZ5FXPLwP0zKjJ5rMQ6y3A+NguASPEuiLHQJRp4BDqHkYx4r4k6+rAFt6SqzCCqOhJ8p MP4l301YSW1U7rWhSlHKrQMuToeTE/H9hkdg10N4v6kd+WCHFPO9gO8eqrLvJ8yxwoGS 1xDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZDof5Sb34nMsPfzavyxwbAeHgkPxSS70jc9x6AHZVM8=; b=IDPl2zuoCSZxCPsM6UkE+Tv484jQDE3b/wJl9QwuT6xVHixl7cxeM33UjlaImkt2rd 1O1JsY0XBZNYciVsELchHUo9LnTRoNasgL/g8iO4yRnyZ5XByQ5g9EXi0ZueNCSbismY blpYPLCEt4woEbzO/WUrV78tVat7o954Ay2ybdFbLO3YjayqV3ST7Jg7jXqKdcWPU9VI z9IbJ81IV56y3mmq7QRAcbNTzyg1IhD27kRLxt2pwFdo7RBbnHMcD9+ozn8chsYBquva dYHP7KtolBmTRX3sdWtSL3HbIHp8hnSMJlZwLAnOh10jbgKJ7pkWMc6j1+OxDGHliir6 y7gg== X-Gm-Message-State: APjAAAXVEmgGgcqsJE1YIFF4aLl7NkXYF6Sh8u8Jqj3ho7F9in4IiXdJ 9sVJwkfK1UYwSsybuMnoutF5MgPKTMdz2hhalDW2oQ== X-Google-Smtp-Source: APXvYqwtjmczaJdlQ4wZYScDbetkzpJ92T+2rAPR4bfHp5feXsc5Kpco1BsamwWNpX3ZvAf80fw+3ktU/O06lUC6ZYI= X-Received: by 2002:a5d:69cf:: with SMTP id s15mr143770wrw.75.1559166373034; Wed, 29 May 2019 14:46:13 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Yuchung Cheng Date: Wed, 29 May 2019 14:45:35 -0700 Message-ID: To: mohamed.boucadair@orange.com Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 21:46:20 -0000 On Tue, May 28, 2019 at 11:10 PM wrote: > > Hi Yuchung, > > This spec is an Experiment which relaxes a constraint in RFC793 in the * = SAME * way the TFO Experiment relaxes that * SAME * constraint. > > Given that RFC7413 isn't tagged as updating RFC793, we are assuming that = the same conclusion applies for our spec. > > I don't think an Experimental RFC can be tagged as updating RFC793, anywa= y. ?Which of my emails asks to tag this draft as RFC793-update? I merely pointed out, if TFO is not used, as the draft and the original email refer to, the draft should be explicit this requires a change in RFC793. It's rather vague. draft-06 "" Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry data inside its payload but forbids the receiver from delivering it to the application until completion of the three-way-handshake. This restriction was motivated by two concerns. First, duplicate SYNs can cause problems for some applications that rely on TCP [RFC7413]. Second, TCP suffers from SYN flooding attacks [RFC4987]. TCP Fast Open [RFC7413] solves these two problems for applications that can tolerate replays by using the TCP Fast Open option that includes a cookie. However, the utilization of this option consumes space in the limited TCP extended header. Furthermore, there are situations, as noted in Section 7.3 of [RFC7413] where it is possible to accept the payload of SYN packets without creating additional security risks such as a network where addresses cannot be spoofed and the Transport Converter only serves a set of hosts that are identified by these addresses. For these reasons, this specification does not mandate the use of the TCP Fast Open option when the Client sends a connection establishment packet towards a Transport Converter. The Convert protocol includes an optional Cookie TLV that provides similar protection as the TCP Fast Open option without consuming space in the extended TCP header." RFC7413 2. Data in SYN Standard TCP already allows data to be carried in SYN packets ([RFC793], Section 3.4) but forbids the receiver from delivering it to the application until the 3WHS is completed. This is because TCP's initial handshake serves to capture old or duplicate SYNs. To enable applications to exchange data in a TCP handshake, TFO removes the constraint and allows data in SYN packets to be delivered to the application. This change to TCP semantic raises two issues (discussed in the following subsections) that make TFO unsuitable for certain applications. Therefore, TCP implementations MUST NOT use TFO by default, but only use TFO if requested explicitly by the application on a per-service- port basis. Applications need to evaluate TFO applicability as described in Section 6 before using TFO. > > Cheers, > Med > > > -----Message d'origine----- > > De : Yuchung Cheng [mailto:ycheng@google.com] > > Envoy=C3=A9 : mardi 28 mai 2019 21:36 > > =C3=80 : Praveen Balasubramanian > > Cc : BOUCADAIR Mohamed TGI/OLN; tcpm@ietf.org > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > On Tue, May 28, 2019 at 8:22 AM Praveen Balasubramanian > > wrote: > > > > > > TFO is a new RFC and server is opting in to receive early data which > > implies being aware of the replay issues. If the TFO state machine > > succeeds (valid cookie with data in SYN) only then the application can > > retrieve data even before handshake completes. > > > > > > Without TFO, the standard sockets API does not allow an application t= o > > receive data before 3WHS completes, even if data is received in the SYN= . > > What you seem to be asking for is a modification of 793 and/or API > > behavior which will need a new opt-in socket option for preserving comp= at > > for existing applications. > > > > yes that's my sense as well (i.e. this draft requires a change in RFC79= 3). > > > > > > > > > > > -----Original Message----- > > > From: mohamed.boucadair@orange.com > > > Sent: Monday, May 27, 2019 4:38 AM > > > To: Praveen Balasubramanian ; Yuchung Cheng > > > > > Cc: tcpm@ietf.org > > > Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters > > > > > > Hi Praveen, > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De : Praveen Balasubramanian [mailto:pravb@microsoft.com] Envoy=C3= =A9 : > > > > vendredi 24 mai 2019 18:45 =C3=80 : Yuchung Cheng; BOUCADAIR Mohame= d > > > > TGI/OLN Cc : tcpm@ietf.org Extensions Objet : RE: [tcpm] Progressin= g > > > > draft-ietf-tcpm-converters > > > > > > > > Agreed and I had raised the same question before: " Isn't passing d= ata > > > > in the SYN up to the application before 3WHS invalid per RFC 793? > > > > > > [Med] This is similar to what TFO does. Both (i.e., TFO and the > > application-based cookie) are relaxing that constraint from 793. > > > > > > How is the > > > > converter (T) extracting the server IP address and port from the SY= N > > > > payload? Is it running some custom TCP implementation that violates > > 793?" > > > > 7413 allows nil-cookie and app can encode cookie and data in SYN if= it > > > > wants. If TFO option is not used at all then it would be a change t= o > > > > 793 and not 7413. > > > > > > [Med] This is what the initial message from Olivier tried to address. > > The issue is what is the point in enclosing the TFO option if the cooki= e > > is supplied by the application? The same protection level can be provid= ed > > with the application-supplied cookie without requiring to insert the TF= O > > option. > > > > > > > > > > > -----Original Message----- > > > > From: tcpm On Behalf Of Yuchung Cheng > > > > Sent: Friday, May 24, 2019 8:01 AM > > > > To: mohamed.boucadair@orange.com > > > > Cc: tcpm@ietf.org Extensions > > > > Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > > > > > On Thu, May 23, 2019 at 11:34 PM wro= te: > > > > > > > > > > Hi Yuchung, > > > > > > > > > > Please see inline. > > > > > > > > > > Cheers, > > > > > Med > > > > > > > > > > > -----Message d'origine----- > > > > > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung > > > > > > Cheng Envoy=C3=A9 : jeudi 23 mai 2019 18:38 =C3=80 : Olivier Bo= naventure Cc > > : > > > > > > tcpm@ietf.org Extensions Objet : Re: [tcpm] Progressing > > > > > > draft-ietf-tcpm-converters > > > > > > > > > > > > On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure > > > > > > wrote: > > > > > > > > > > > > > > Yuchung, > > > > > > > > > > > > > > >> > > > > > > > >> We believe that a specialised TCP application should be > > > > > > > >> allowed to > > > > > > use its own cookie inside the payload instead of relying on the > > > > > > TCP header to use fast open. The 0-RTT convert protocol is one > > > > > > example, but there could be others. Looking at other applicatio= n > > > > > > layer protocols, I noticed that TLS1.3 (rfc8446) also includes = a > > > > > > cookie which is mainly designed enable servers to get a > > > > > > confirmation of the reachability of the client IP addresses for > > > > > > DTLS, but the same approach could be used when TLS sends its > > > > > > initial data in the SYN as > > > > well. > > > > > > > >> > > > > > > > >> Another point that should be clarified in RFC7413 are how > > > > > > > >> middleboxes > > > > > > should handle SYN packets containing a non-zero payload. Accord= ing > > > > > > to RFC793, such packets are valid TCP packets. The TFO option, > > > > > > defined in > > > > > > RFC7314 is not and should not be considered as an indication th= at > > > > > > is required to =E2=80=9Cauthorise=E2=80=9D the utilisation of p= ayload inside a SYN > > > > packet. > > > > > > During the Prague meeting, Christoph Paasch mentioned at the mi= ke > > > > > > that they have one application that uses data inside the SYN an= d > > > > > > their measurements indicate that sending this SYN without the T= FO > > > > > > option enables it to pass through more middleboxes than when th= e > > > > > > same SYN contains the TFO option. > > > > > > > >> > > > > > > > >> Another point is the socket API. Currently, Linux and MacO= S > > > > > > > >> decouple > > > > > > the transmission of data inside the SYN from the utilisation of > > > > > > the TFO option. This makes it possible for a client to send dat= a > > > > > > inside the SYN without enabling TFO. On Windows, the API seems = to > > > > > > force the utilisation of TFO when there is data in the SYN. As > > > > > > indicated earlier, RFC793 does not mandate the presence of the = TFO > > > > > > to place data > > > > inside the SYN. > > > > > > > >> > > > > > > > >> The approach we are proposing has the benefits of RFC7413 = but > > > > > > > >> without > > > > > > its drawbacks. Moreover, given that RFC7413 is Experimental, we > > > > > > don't think that there is a harm if we proceed with the approac= h > > > > > > 0-rtt convert protocol while the IETF can further tweak and adj= ust > > > > > > the applicability scope of RFC7413. For example, an update can = be > > > > > > proposed to RFC7413 to clarify that specialized application-lev= el > > > > > > protocols could place cookie information in their payload and t= hus > > > > > > not > > > > use the TFO option. > > > > > > > > Just to confirm: you mean an API that let application sets = the > > > > > > > > TFO cookie (on either server and client)? > > > > > > > > > > > > > > > > > > > > > No, we suggest to let specific applications use data in the S= YN > > > > > > > without > > > > > > using the TFO cookie. Those applications can manage their cooki= e > > > > > > inside the SYN payload if needed. Instead of having TFO cookies > > > > > > that are managed by the TCP stack and have limited size, those > > > > > > specialised protocols would use application-level cookies which > > > > > > can be longer and are managed by these application protocols. > > > > > > I see. though I suppose this requires changing RFC793 of not > > > > > > uploading the data to application until 3WHS completes. > > > > > > > > > > > > > > > > [Med] That constraint can be relaxed following a rationale simila= r > > > > > to > > > > the one in RFC7413. > > > > > > > > > > Is there any particular reason why a change to RFC793 would be > > > > > required > > > > here but not for RFC7413? > > > > It's an interesting question - > > > > > > > > RFC793 long allows data-in-SYN but requires data to be posted after > > > > handshake. RFC7413 relaxes that but also requires a cookie. > > > > > > > > So if we think this is an "extension" to TFO, then perhaps extends > > > > RFC7413 not changing RFC793? personally I do think that makes sense= . > > > > IMO TFO implementation provides a generic way to do data-in-SYN. > > > > Application can use whatever they prefer to protect or optimize > > > > data-in- SYN. TFO cookie is just a default simple mechanism for > > > > application who finds that acceptable. > > > > > > > > > > > > > > > > > > > > > > > > otherwise obviously application can place any data in their > > > > > > > > TCP > > > > > > payload for its > > > > > > > > purposes. > > > > > > > > > > > > > > This is what we proposed in Prague, i.e. using data in the TC= P > > > > > > > SYN > > > > > > without the TFO option. > > > > > > > > > > > > > > > > > > > > > Olivier > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > Disclaimer: > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3= A%2F% > > > > > > > 2F > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dwww.tes= sares > > > > > > > .net&data=3D02%7C01%7Cpravb%40microsoft.com%7Cd66411576dc= c4e9c > > > > > > > 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C63 > > > > > > > 6945538746972754&sdata=3DZHft4yd79R0Im8I27KM9dETCYgEhpc3z= l9jJw > > > > > > > vxYZWc%3D&reserved=3D0%2Fmail-disclaimer%2F&data=3D02= %7C01%7 > > > > > > > Cpravb%40m > > > > > > > icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f= 141 > > > > > > > af > > > > > > > 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhxk= fj8by > > > > > > > IM > > > > > > > Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0 > > > > > > > > > > > > > %2 > > > > > > > Fwww.tessares.net%2Fmail-disclaimer%2F&data=3D02%7C01%7Cp= ravb% > > > > > > > 40 > > > > > > > microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86= f14 > > > > > > > 1a > > > > > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3Dhx= kfj8b > > > > > > > yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=3D0= > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > tcpm mailing list > > > > > > tcpm@ietf.org > > > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2F > > > > > > ww > > > > > > w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpra= vb%40 > > > > > > mi > > > > > > crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141= af9 > > > > > > 1a > > > > > > b2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=3D1lrrMH92= jHLh5 > > > > > > dq > > > > > > U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&reserved=3D0 > > > > > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww. > > > > ietf > > > > .org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= soft. > > > > com% > > > > 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db= 47% > > > > 7C1% > > > > 7C0%7C636943069081636780&sdata=3D1lrrMH92jHLh5dqU4q33yK%2FKg0Lv= XJKGR > > > > 3glc > > > > nbAer8%3D&reserved=3D0 From nobody Fri May 31 05:17:13 2019 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2355E12009C for ; Fri, 31 May 2019 05:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xzKnjxFfak-G for ; Fri, 31 May 2019 05:17:09 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F2312008F for ; Fri, 31 May 2019 05:17:09 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45Fk373lHlz7w7C; Fri, 31 May 2019 14:17:07 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 45Fk3732FczCqkj; Fri, 31 May 2019 14:17:07 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([fe80::b43f:9973:861e:42af%21]) with mapi id 14.03.0439.000; Fri, 31 May 2019 14:17:07 +0200 From: To: Yuchung Cheng CC: "tcpm@ietf.org" Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters Thread-Index: AQHVFmfwiaNp2b0xbUChdFcAEBfRmqaFJeMw Date: Fri, 31 May 2019 12:17:06 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9301E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 12:17:12 -0000 SGkgWXVjaHVuZywgDQoNClRoYW5rIHlvdSBmb3IgY2xhcmlmeWluZyB5b3VyIGNvbmNlcm4uIEJl bG93IGEgdGV4dCBwcm9wb3NhbCB0byBhZGRyZXNzIHRoaXMgY29tbWVudDoNCg0KPiBJIG1lcmVs eSBwb2ludGVkIG91dCwgaWYgVEZPIGlzIG5vdCB1c2VkLCBhcyB0aGUgZHJhZnQgYW5kIHRoZQ0K PiBvcmlnaW5hbCBlbWFpbCByZWZlciB0bywgdGhlIGRyYWZ0IHNob3VsZCBiZSBleHBsaWNpdCB0 aGlzIHJlcXVpcmVzIGENCj4gY2hhbmdlIGluIFJGQzc5My4gSXQncyByYXRoZXIgdmFndWUuDQog DQpVUERBVEVEOg0KDQogICBTdGFuZGFyZCBUQ1AgKFtSRkMwNzkzXSwgU2VjdGlvbiAzLjQpIGFs bG93cyBhIFNZTiBwYWNrZXQgdG8gY2FycnkNCiAgIGRhdGEgaW5zaWRlIGl0cyBwYXlsb2FkIGJ1 dCBmb3JiaWRzIHRoZSByZWNlaXZlciBmcm9tIGRlbGl2ZXJpbmcgaXQNCiAgIHRvIHRoZSBhcHBs aWNhdGlvbiB1bnRpbCBjb21wbGV0aW9uIG9mIHRoZSB0aHJlZS13YXktaGFuZHNoYWtlLiAgVG8N CiAgIGVuYWJsZSBhcHBsaWNhdGlvbnMgdG8gZXhjaGFuZ2UgZGF0YSBpbiBhIFRDUCBoYW5kc2hh a2UsIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gZm9sbG93cyBhbiBhcHByb2FjaCBzaW1pbGFyIHRv IFRDUCBGYXN0IE9wZW4gW1JGQzc0MTNdDQogICBhbmQgdGh1cyByZW1vdmVzIHRoZSBjb25zdHJh aW50IGJ5IGFsbG93aW5nIGRhdGEgaW4gU1lOIHBhY2tldHMgdG8gYmUNCiAgIGRlbGl2ZXJlZCB0 byB0aGUgYXBwbGljYXRpb24uDQoNCiAgIEFzIGRpc2N1c3NlZCBpbiBbUkZDNzQxM10sIHN1Y2gg Y2hhbmdlIHRvIFRDUCBzZW1hbnRpYyByYWlzZXMgdHdvDQogICBpc3N1ZXMuICBGaXJzdCwgZHVw bGljYXRlIFNZTnMgY2FuIGNhdXNlIHByb2JsZW1zIGZvciBzb21lDQogICBhcHBsaWNhdGlvbnMg dGhhdCByZWx5IG9uIFRDUC4gIFNlY29uZCwgVENQIHN1ZmZlcnMgZnJvbSBTWU4gZmxvb2RpbmcN CiAgIGF0dGFja3MgW1JGQzQ5ODddLiAgVEZPIHNvbHZlcyB0aGVzZSB0d28gcHJvYmxlbXMgZm9y IGFwcGxpY2F0aW9ucw0KICAgdGhhdCBjYW4gdG9sZXJhdGUgcmVwbGF5cyBieSB1c2luZyB0aGUg VENQIEZhc3QgT3BlbiBvcHRpb24gdGhhdA0KICAgaW5jbHVkZXMgYSBjb29raWUuICBIb3dldmVy LCB0aGUgdXRpbGl6YXRpb24gb2YgdGhpcyBvcHRpb24gY29uc3VtZXMNCiAgIHNwYWNlIGluIHRo ZSBsaW1pdGVkIFRDUCBleHRlbmRlZCBoZWFkZXIuICBGdXJ0aGVybW9yZSwgdGhlcmUgYXJlDQog ICBzaXR1YXRpb25zLCBhcyBub3RlZCBpbiBTZWN0aW9uIDcuMyBvZiBbUkZDNzQxM10gd2hlcmUg aXQgaXMgcG9zc2libGUNCiAgIHRvIGFjY2VwdCB0aGUgcGF5bG9hZCBvZiBTWU4gcGFja2V0cyB3 aXRob3V0IGNyZWF0aW5nIGFkZGl0aW9uYWwNCiAgIHNlY3VyaXR5IHJpc2tzIHN1Y2ggYXMgYSBu ZXR3b3JrIHdoZXJlIGFkZHJlc3NlcyBjYW5ub3QgYmUgc3Bvb2ZlZA0KICAgYW5kIHRoZSBUcmFu c3BvcnQgQ29udmVydGVyIG9ubHkgc2VydmVzIGEgc2V0IG9mIGhvc3RzIHRoYXQgYXJlDQogICBp ZGVudGlmaWVkIGJ5IHRoZXNlIGFkZHJlc3Nlcy4NCg0KICAgRm9yIHRoZXNlIHJlYXNvbnMsIHRo aXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBtYW5kYXRlIHRoZSB1c2Ugb2YgdGhlDQogICBUQ1Ag RmFzdCBPcGVuIG9wdGlvbiB3aGVuIHRoZSBDbGllbnQgc2VuZHMgYSBjb25uZWN0aW9uIGVzdGFi bGlzaG1lbnQNCiAgIHBhY2tldCB0b3dhcmRzIGEgVHJhbnNwb3J0IENvbnZlcnRlci4gIFRoZSBD b252ZXJ0IHByb3RvY29sIGluY2x1ZGVzDQogICBhbiBvcHRpb25hbCBDb29raWUgVExWIHRoYXQg cHJvdmlkZXMgc2ltaWxhciBwcm90ZWN0aW9uIGFzIHRoZSBUQ1ANCiAgIEZhc3QgT3BlbiBvcHRp b24gd2l0aG91dCBjb25zdW1pbmcgc3BhY2UgaW4gdGhlIGV4dGVuZGVkIFRDUCBoZWFkZXIuDQoN Cg0KQmV0dGVyPw0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0t LS0NCj4gRGXCoDogWXVjaHVuZyBDaGVuZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXQ0KPiBF bnZvecOpwqA6IG1lcmNyZWRpIDI5IG1haSAyMDE5IDIzOjQ2DQo+IMOAwqA6IEJPVUNBREFJUiBN b2hhbWVkIFRHSS9PTE4NCj4gQ2PCoDogdGNwbUBpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogW3Rj cG1dIFByb2dyZXNzaW5nIGRyYWZ0LWlldGYtdGNwbS1jb252ZXJ0ZXJzDQo+IA0KPiBPbiBUdWUs IE1heSAyOCwgMjAxOSBhdCAxMToxMCBQTSA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4g d3JvdGU6DQo+ID4NCj4gPiBIaSBZdWNodW5nLA0KPiA+DQo+ID4gVGhpcyBzcGVjIGlzIGFuIEV4 cGVyaW1lbnQgd2hpY2ggcmVsYXhlcyBhIGNvbnN0cmFpbnQgaW4gUkZDNzkzIGluIHRoZSAqDQo+ IFNBTUUgKiAgd2F5IHRoZSBURk8gRXhwZXJpbWVudCByZWxheGVzIHRoYXQgKiBTQU1FICogY29u c3RyYWludC4NCj4gPg0KPiA+IEdpdmVuIHRoYXQgUkZDNzQxMyBpc24ndCB0YWdnZWQgYXMgdXBk YXRpbmcgUkZDNzkzLCB3ZSBhcmUgYXNzdW1pbmcgdGhhdA0KPiB0aGUgc2FtZSBjb25jbHVzaW9u IGFwcGxpZXMgZm9yIG91ciBzcGVjLg0KPiA+DQo+ID4gSSBkb24ndCB0aGluayBhbiBFeHBlcmlt ZW50YWwgUkZDIGNhbiBiZSB0YWdnZWQgYXMgdXBkYXRpbmcgUkZDNzkzLA0KPiBhbnl3YXkuDQo+ ID9XaGljaCBvZiBteSBlbWFpbHMgYXNrcyB0byB0YWcgdGhpcyBkcmFmdCBhcyBSRkM3OTMtdXBk YXRlPw0KPiANCj4gSSBtZXJlbHkgcG9pbnRlZCBvdXQsIGlmIFRGTyBpcyBub3QgdXNlZCwgYXMg dGhlIGRyYWZ0IGFuZCB0aGUNCj4gb3JpZ2luYWwgZW1haWwgcmVmZXIgdG8sIHRoZSBkcmFmdCBz aG91bGQgYmUgZXhwbGljaXQgdGhpcyByZXF1aXJlcyBhDQo+IGNoYW5nZSBpbiBSRkM3OTMuIEl0 J3MgcmF0aGVyIHZhZ3VlLg0K