Re: [tcpm] Progressing draft-ietf-tcpm-converters

Praveen Balasubramanian <pravb@microsoft.com> Wed, 29 May 2019 16:27 UTC

Return-Path: <pravb@microsoft.com>
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 <tcpm@ietfa.amsl.com>; 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 <tcpm@ietfa.amsl.com>; 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 <tcpm@ietf.org>; 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 <pravb@microsoft.com>
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>
CC: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Yuchung Cheng <ycheng@google.com>, "tcpm@ietf.org" <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: <MW2PR2101MB1049AF12221F9EE37133F603B61F0@MW2PR2101MB1049.namprd21.prod.outlook.com>
References: <F92BF1E2-60EB-4E48-84A4-1C82589A056A@tessares.net> <CAK6E8=f-TAUWs3x4P9XHUHbvRhOqBhH9GU910Yoy5v_0vzUxAQ@mail.gmail.com> <A0496204-331F-4D8E-A1C1-83D3E1CE759B@tessares.net> <CAK6E8=e0RVzfRA0j=y8EZK0HonH6vaMBL6m-U3L+8cNO-zpqqw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAK6E8=cDrLB0Oop2act7jCe_CYnNd2gJZU06ZHg_zJXXh_VOXg@mail.gmail.com> <MW2PR2101MB1049E8330D990998817F1A82B6020@MW2PR2101MB1049.namprd21.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MW2PR2101MB10493385260DA9D53B92B1A4B61E0@MW2PR2101MB1049.namprd21.prod.outlook.com> <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: <MW2PR2101MB1001790475C86FFDDC577FD9B61F0@MW2PR2101MB1001.namprd21.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/tcpm/Tkfq0zJxDtlAuWuRf45mXeM3ri8>
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 16:27:54 -0000

These are two different things.
1. Ability to SEND data in SYN payload on client. This is only supported on Linux and macOS when TFO API is not used. On Windows the only way to achieve this is using the TFO API. If TFO API is not used Windows stack will buffer the data to be sent *after* 3WHS completes. 
2. Ability to RECEIVE data in SYN payload on server. This is only supported on all OS *after* 3WHS is completed. This is per RFC 793. The only exception is if TFO API is used, and then if cookie is validated the application will  receive early-data. There is no way to retrieve early data otherwise. 

Yuchung and I are pointing to bullet 2 as requiring a RFC modification / API modification. Does this make sense?

-----Original Message-----
From: Olivier Bonaventure <olivier.bonaventure@tessares.net> 
Sent: Wednesday, May 29, 2019 12:50 AM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: mohamed.boucadair@orange.com; Yuchung Cheng <ycheng@google.com>; tcpm@ietf.org
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters

Praveen,

> On 28 May 2019, at 17:22, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org> wrote:
> 
> TFO is a new RFC and server is opting in to receive early data which implies 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 then the application can retrieve data even before handshake completes.
> 

The only difference with RFC7413 is that the server itself manages the cookie and checks its validity. Once the cookie has been validated, it can process the other elements of the payload.

> Without TFO, the standard sockets API does not allow an application to 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 compat for existing applications. 

Yes, but as already mentioned, this behaviour is already implemented on the Linux and Apple stacks. This has probably been motivated by other use cases.


Olivier


> -----Original Message-----
> From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> Sent: Monday, May 27, 2019 4:38 AM
> To: Praveen Balasubramanian <pravb@microsoft.com>; Yuchung Cheng 
> <ycheng=40google.com@dmarc.ietf.org>
> 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é : 
>> vendredi 24 mai 2019 18:45 À : 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 application-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 supplied by the application? The same protection level can be provided with the application-supplied cookie without requiring to insert the TFO option.  
> 
>> 
>> -----Original Message-----
>> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
>> Sent: Friday, May 24, 2019 8:01 AM
>> To: mohamed.boucadair@orange.com
>> Cc: tcpm@ietf.org Extensions <tcpm@ietf.org>
>> Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
>> 
>> On Thu, May 23, 2019 at 11:34 PM <mohamed.boucadair@orange.com> 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é : jeudi 23 mai 2019 18:38 À : 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 
>>>> <olivier.bonaventure@tessares.net> 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 “authorise” the utilisation of payload 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=https%3A%2F%
>>>>> 2F 
>>>>> https://nam06.safelinks.protection.outlook.com/?url=www.tessares
>>>>> .net&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cd66411576dcc4e9c
>>>>> 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
>>>>> 6945538746972754&amp;sdata=ZHft4yd79R0Im8I27KM9dETCYgEhpc3zl9jJw
>>>>> vxYZWc%3D&amp;reserved=0%2Fmail-disclaimer%2F&amp;data=02%7C01%7
>>>>> Cpravb%40m 
>>>>> icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141
>>>>> af 
>>>>> 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8by
>>>>> IM
>>>>> Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F
>>>>> %2
>>>>> Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%
>>>>> 40 
>>>>> microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f14
>>>>> 1a 
>>>>> f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8b
>>>>> yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0>
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>> ww 
>>>> w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40
>>>> mi 
>>>> crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af9
>>>> 1a 
>>>> b2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=1lrrMH92jHLh5
>>>> dq
>>>> U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&amp;reserved=0
>> 
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf 
>> .org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.
>> com% 
>> 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db47%
>> 7C1% 
>> 7C0%7C636943069081636780&amp;sdata=1lrrMH92jHLh5dqU4q33yK%2FKg0LvXJKGR
>> 3glc
>> nbAer8%3D&amp;reserved=0
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=x5PdSir0VO040deFdiOemBJ1mz939LdYFLQJRWfqfBs%3D&amp;reserved=0


-- 


Disclaimer: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=2kn%2Bq%2FigobiHOl6JPANYEajQupiEtkFk9RXGjkkOQQY%3D&amp;reserved=0 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=2kn%2Bq%2FigobiHOl6JPANYEajQupiEtkFk9RXGjkkOQQY%3D&amp;reserved=0>