Re: [Potential Spoof] Re: Getting to consensus on packet number encryption

Roberto Peon <fenix@fb.com> Tue, 01 May 2018 23:23 UTC

Return-Path: <prvs=86592f1e95=fenix@fb.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8F126DFB for <quic@ietfa.amsl.com>; Tue, 1 May 2018 16:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_DKIMWL_WL_MED=-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=fb.com header.b=FHS6bSTO; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UYpxShu9
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 7WNdETwz3_Eq for <quic@ietfa.amsl.com>; Tue, 1 May 2018 16:23:04 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 B2B7B127078 for <quic@ietf.org>; Tue, 1 May 2018 16:23:04 -0700 (PDT)
Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w41NHqAe029910; Tue, 1 May 2018 16:22:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=facebook; bh=ixBUHQH54IUOASaGCJpUUcnk2PHWRBwjlQ4aveBD2+c=; b=FHS6bSTO0v/3hOTGFAk5YhbIul26uTtulM+a5nQmFroQcXnSJ0UV72mvs3wr2UinOAGp TjSXhsrhskQ8663DyvepaluO0mUbkpXpBGX+o7Qpzsf8snhS+xf/ZEfAM/6GWow8xhRQ JA5l6kyLg+F6vRTUUzbQKzuRtt4IrFmiF7Q=
Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2hpvw4ruf7-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 01 May 2018 16:22:30 -0700
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.29) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 1 May 2018 19:22:28 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ixBUHQH54IUOASaGCJpUUcnk2PHWRBwjlQ4aveBD2+c=; b=UYpxShu9nl82sfHcJ8Tvs6ewXmw+T0LeQrUCvDPEO/GVnu3n0fUpQ7CzlKFhTPbgtn9jF8KCPHAjzkhkIrFyAvc5UIfDWfiPZHbHp9zMLSD+z2P5ZYWFHH3o7erGzuG3VMEXhsIqGs9R1xR/lDC8mzWo1HxUidSLcqsZRWOat4c=
Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0373.namprd15.prod.outlook.com (10.163.109.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.24; Tue, 1 May 2018 23:22:26 +0000
Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e]) by BY2PR15MB0775.namprd15.prod.outlook.com ([fe80::6c4c:bbf3:ec3b:d45e%14]) with mapi id 15.20.0715.024; Tue, 1 May 2018 23:22:26 +0000
From: Roberto Peon <fenix@fb.com>
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, Ted Hardie <ted.ietf@gmail.com>
CC: "Salz, Rich" <rsalz@akamai.com>, Benjamin Kaduk <bkaduk@akamai.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Topic: [Potential Spoof] Re: Getting to consensus on packet number encryption
Thread-Index: AQHT4aNDwsND+KyhPEGdsYUFiGhpMg==
Date: Tue, 01 May 2018 23:22:26 +0000
Message-ID: <01AE46C6-682C-4A21-84CD-1D8DAD6F49D9@fb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-originating-ip: [2620:10d:c090:200::6:ddb8]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR15MB0373; 7:kFfGahr4wPaMLx7KodNfmZz9u4yk/o9LAdqlcxmxJ4cka6gY8Ko910PtMumm/uDdPgCid9pO0FntAmGIwEC1Z2J0zLfVPUkV9VLwsMNap4+TJtqCBOze8jG4qdDsv6nBzI6kg1PdftIkxwtfpgV2iCh2lbulg0JIKg8GOV0qK8rDDRNd3bnvJf99U4Qo2VBuZ8ymyFL00RhJXbBch8dJy6lxGA3QfPlI2BrQF54w00Fl5udKEV2zXeLOELylHuB5; 20:D2n4Ew9CE3icH3qdXnOqvtxeX2TgneuUHOIhK3q5cBwr3yryztlEYA5CrB+8sfLj09yf5DEdNxORPCnM/2yoEgR1P87PeWAqNfe7UH9MU+iExFZhDRuEGArLtEV0YbgsyX3RSlRdsRXRjls5hdjwpqY07ukv3TiBn3LWrPQ7AUA=
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BY2PR15MB0373;
x-ms-traffictypediagnostic: BY2PR15MB0373:
x-microsoft-antispam-prvs: <BY2PR15MB0373E36267D564DDE9E259D8CD810@BY2PR15MB0373.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(89211679590171)(189930954265078)(85827821059158)(67672495146484)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231254)(11241501184)(944501410)(52105095)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BY2PR15MB0373; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0373;
x-forefront-prvs: 06592CCE58
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(39860400002)(366004)(189003)(199004)(102836004)(45080400002)(8936002)(6506007)(14454004)(86362001)(3280700002)(6246003)(39060400002)(478600001)(7736002)(236005)(6512007)(5250100002)(6306002)(4326008)(2900100001)(316002)(97736004)(99286004)(68736007)(59450400001)(54896002)(53546011)(53936002)(33656002)(606006)(6116002)(2906002)(25786009)(81166006)(5660300001)(58126008)(83716003)(81156014)(105586002)(110136005)(82746002)(54906003)(486006)(8676002)(36756003)(3660700001)(229853002)(186003)(2616005)(106356001)(6486002)(6436002)(46003)(476003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0373; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: NtxvJdoD5XiqfmGJxh1FlIIeWCVxJ7ECPB6h4lLjhPK2m6f4POurc/ByIbecTvquHaw44KmuT0gubvh9i4Gcq7eGdPVZwv7VB2s4IVMfRSnDn87pgMY59+gHraessqSiYO4/VY691bKEgdHvF7FjSyVybN2GWpicxv2DoeWL+KCXMhnqt1E6qiOZ2SmpxTuB
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_01AE46C6682C4A2184CD1D8DAD6F49D9fbcom_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: fbb85b17-895b-431a-00cd-08d5afba669a
X-MS-Exchange-CrossTenant-Network-Message-Id: fbb85b17-895b-431a-00cd-08d5afba669a
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2018 23:22:26.1064 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0373
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-01_13:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2HXOUGwHQgjDC1h8-MvchaBhSyQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 May 2018 23:23:07 -0000

I’d suggest we start working on it now.
This is only partly a joke ☺
-=R

From: QUIC <quic-bounces@ietf.org> on behalf of Roberto Peon <fenix@fb.com>
Date: Tuesday, May 1, 2018 at 4:21 PM
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, Ted Hardie <ted.ietf@gmail.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, Benjamin Kaduk <bkaduk@akamai.com>, IETF QUIC WG <quic@ietf.org>
Subject: [Potential Spoof] Re: Getting to consensus on packet number encryption

Yup. I know.
Prism was eye-opening partially because of the fact that the packets were not going across the internet, but rather within a secure network.

I believe that ossification alone is a good enough reason to do PNE.
The cherry for me is that it, along with other actions/mitigations, makes linkability more difficult for malicious actors.
CRIME and related was eye-opening because it exposed the power of the observable side-channel.

-=R

From: QUIC <quic-bounces@ietf.org> on behalf of Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
Date: Tuesday, May 1, 2018 at 9:35 AM
To: Ted Hardie <ted.ietf@gmail.com>, Roberto Peon <fenix@fb.com>
Cc: "Salz, Rich" <rsalz@akamai.com>, Benjamin Kaduk <bkaduk@akamai.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Getting to consensus on packet number encryption

This is not about putting plaintext data on the network, this is about not adding PNE which is intended for preventing ossification. So I don’t understand what the trust issue being referred to is in case of the rare misconfig.

Within a DC several things are different – the deployment may need different congestion control like DCTCP, different settings for various transport parameters (like minrto and max ACK delay), larger flow control window etc. This is true for TCP today. The out of box default uses the handshake RTT to make a determination of what’s intra-DC but there is rich configuration to override the default and set it based on 4-tuple filters.

And there workloads like cloud storage and live migration that are by virtue of deployment intra-DC. These cannot be load shifted as they use private IP address space.

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, May 1, 2018 8:55 AM
To: Roberto Peon <fenix@fb.com>
Cc: Salz, Rich <rsalz@akamai.com>; Benjamin Kaduk <bkaduk@akamai.com>; Praveen Balasubramanian <pravb@microsoft.com>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Getting to consensus on packet number encryption

On Tue, May 1, 2018 at 8:13 AM, Roberto Peon <fenix@fb.com<mailto:fenix@fb.com>> wrote:
Also, Prism.

-=R



That's a little more succinct than I would be, but yes.  How does an application know that the flow it is initiating will traverse a topology that is deemed to be within a controlled environment?  You can say "configuration" but I fear it will turn up on a post-it  <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fi.kinja-2Dimg.com-252Fgawker-2Dmedia-252Fimage-252Fupload-252Fs-2D-2DEdu6LPu9-2D-2D-252Fc-5Fscale-252Cf-5Fauto-252Cfl-5Fprogressive-252Cq-5F80-252Cw-5F800-252F194thbtyencs0jpg.jpg-26data-3D02-257C01-257Cpravb-2540microsoft.com-257C4da44e8ac1df4708ad8808d5af7bfca8-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C1-257C636607869411258976-26sdata-3DProlSHkbF2SgMH3qdQN-252BZFokXvsEBf-252F3o9MaUnil0g8-253D-26reserved-3D0&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=TuVfzypo-CZLo522lgMRrLpKxcFaHvW9kdNSI57lXT0&s=By2d_to7XzLEgAL3Or9cZc2Aykye-PZEenFQDviAUlw&e=> if you do.  Loads shift, resources move, and suddenly you find that host which used to be in the same rack, being down, has load-shifted to the next instance,  in a datacenter 500 miles away across a very different network.

Many modern deployments are also in someone else's data center, so saying "Data center networks" doesn't say much about why you're trusting the network inside.
Ted

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>>
Date: 5/1/18 5:25 AM (GMT-08:00)
To: Benjamin Kaduk <bkaduk=40akamai.com@dmarc.ietf.org<mailto:40akamai.com@dmarc.ietf.org>>, Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org<mailto:40microsoft.com@dmarc.ietf.org>>
Cc: IETF QUIC WG <quic@ietf.org<mailto:quic@ietf.org>>
Subject: Re: Getting to consensus on packet number encryption

    > I disagree that we need any more data for not doing PNE in the datacenter. Why would we add an extra encrypt-decrypt step for no obvious benefit?

I am concerned that people will mis-interpret the meaning of a datacenter, and think that a bunch of servers, or even a rack, in an open colo space is a "datacenter."  Computers keep getting faster.