From nobody Wed Apr 1 03:45:02 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B37843A0800; Wed, 1 Apr 2020 03:44:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Mohit Sethi via Datatracker To: Cc: taps@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158573789268.30918.7424398883276797270@ietfa.amsl.com> Reply-To: Mohit Sethi Date: Wed, 01 Apr 2020 03:44:52 -0700 Archived-At: Subject: [Taps] Iotdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2020 10:44:53 -0000 Reviewer: Mohit Sethi Review result: Ready with Nits This document provides a summary of common security protocols. It then discusses the interfaces that exist between applications and security protocols as well as security protocols and transport services. Major issues: The document header says that this document is about interfaces between security protocols and transport services. Yet, later on, I find that the document is also discussing the interfaces between security protocols and applications. Perhaps you could add 'applications' to the title -> 'Interaction Between Applications, Security Protocols, and Transport Services' Editorial issues: - Instead of saying 'This protocol obsoletes TCP MD5 "signature" options', can we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' - Please expand 'and IPsec AH [RFC4302]' -> IP Authentication Header - Are you talking about cryptographic agility here 'security protocols: confidentiality, privacy protections, and agility.' ? - Consider changing 'interface surface exposed '-> interface exposed by'. Otherwise it sounds too similar to attack surface exposed. - Expand EAP and reference RFC3748. - Perhaps you could say that Source Address Validation (SAV) to prevent DoS is relevant for protocols that use unreliable transport? From nobody Thu Apr 2 05:03:39 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6723A10E6; Thu, 2 Apr 2020 05:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IUv6EJFv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZaSFIFKn 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 T_ENLp00-518; Thu, 2 Apr 2020 05:03:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7769C3A10BE; Thu, 2 Apr 2020 05:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3088; q=dns/txt; s=iport; t=1585829001; x=1587038601; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ozbwvFpa/bQy2JrLY0TSBugla4Oc2PCylNwMIO1uZcc=; b=IUv6EJFvCH59KHzfV7cvJOU2wEslivPrGNybZ91LnXsDMAVGgUVVeMUK 2o3a9R1DcTKDLD7y0dZZu+1JZZStFvv81hRoY6Xa0ZbFNNjzUj4usclKn 4vJZSccPrsEHVdt5U9mypKoZZ0XjZMDWCYJrjwLrVks0LE1NlSDGbRQrU 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AwvkJKhZIWBLJFaREsKTHYoT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavncT08F8dPfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQDr04Ve/5BdJa1mGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBe4FUUAVsWCAECyqEG4NFA4ptgl+YHoFCgRADVAoBAQE?= =?us-ascii?q?MAQEYCwoCBAEBhEQCF4IpJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQM?= =?us-ascii?q?BARARBA0MAQEsCwELBAIBCBEDAQIDAhEVAgICJQsUAQgIAgQBDQUigwQBgks?= =?us-ascii?q?DLgEOpBcCgTmIYnV/M4J/AQEFhTIYggwDBoEOKollgkwagUE/gTgggk0+gmc?= =?us-ascii?q?BAYEeRz+CUzKCLI1ogxqQLY9XCoI9kmeENB2CTIg1kHGPKZwWAgQCBAUCDgE?= =?us-ascii?q?BBYFpIoFXcBUaISoBgj5QGA2OHQ0WFYM7hRSFQXQCC4Eci10tghQBAQ?= X-IronPort-AV: E=Sophos;i="5.72,335,1580774400"; d="scan'208";a="750077511" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2020 12:03:20 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 032C3KZs008303 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 2 Apr 2020 12:03:20 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 07:03:20 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Apr 2020 07:03:19 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Apr 2020 07:03:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k2L7gqX0KB5s9j1moSGRvgiLv8TTCtgAT+p4Aeu2ApiSQsRmMnzGGtHzFjP+aasdKprEYBvSsmm079YUSb5kQAa6qenUqVy0kSXZJVWqfV4n4HiGyDh+aDbqIrtWPe44LZEHAEFJzAfBuK7bKNCoAV1+0tHHhtwyh2XHXe3HM2DBChGigAqUaDCPTzmKnI70/z5DOmxuE8uhmviYjYclOnd0sGXffwiD7sOeEm73e6vM6KZUi5L6+Fy7C4WGA6eRJY7Mx6dAHHyy9u12bLvPxBlO5NRIdIvvePKF22iUJFl2Y3zKxHI/mE53VL3nnFy/yaQVfC3p3eMw337kzw5Pwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ozbwvFpa/bQy2JrLY0TSBugla4Oc2PCylNwMIO1uZcc=; b=NXJKXkQyJaRmHWuhHAeYsAPKEaBGBQ+fCP8U6eeofy8ZwuU3JkQC223WFSPY0LqeCWPndIZG2LSEMdxMztUKJl+CP4A6godtzgJhDBfK4N0RhxvJ1N7nBt+9f8yEpDMEdjr/oqHdZZ7p6srQrWXpIRpRGEpnLa+jJZqgBoGjIJNbj/znekB+MzReu4+0XOa/HOcIdhnzjs8SG1QhWlgEyfP9lxVxql7BJQ8c2b9HWQcE8EvpFuY6BSwWUJiV3RhjTVatqEKOMDa3pXRx4Dw6a6rPO1+vFh1HLR9P/7OElv+vhrz0ZOmK/cUgnwvcuje3OhUr8eiuMez482KbfzIjBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ozbwvFpa/bQy2JrLY0TSBugla4Oc2PCylNwMIO1uZcc=; b=ZaSFIFKn+SOGs/EqEmsEC7eJef+9K11cosd9jSeCUxJgBaftjL1svqqt5zHCJWA2N+trYO2RfE90KahQuOnWPhgicfjdV3us5TeNETLlm+EIzFSbKLnhvuIgXJ6godHwllNZ74HjZ9AZnUGkijLX/L8n7WZ4UCt+I20ExQRUGVk= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB0076.namprd11.prod.outlook.com (2603:10b6:4:6b::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 12:03:18 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 12:03:18 +0000 From: "Eric Vyncke (evyncke)" To: Mohit Sethi , "iot-directorate@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" , "taps@ietf.org" Thread-Topic: [Iot-directorate] Iotdir telechat review of draft-ietf-taps-transport-security-11 Thread-Index: AQHWCBKtQZhKlC2S9E+3hLwrcn7MGqhl3sYA Date: Thu, 2 Apr 2020 12:03:18 +0000 Message-ID: <5C72A1F6-DAD5-484A-B62E-FD26F83ADE20@cisco.com> References: <158573789268.30918.7424398883276797270@ietfa.amsl.com> In-Reply-To: <158573789268.30918.7424398883276797270@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:ad33:1e6:78ba:617b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d584cad-36c3-4f9d-b15b-08d7d6fdd548 x-ms-traffictypediagnostic: DM5PR11MB0076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(6486002)(110136005)(4326008)(33656002)(54906003)(5660300002)(2906002)(966005)(71200400001)(316002)(478600001)(36756003)(6506007)(6512007)(66946007)(81166006)(76116006)(186003)(53546011)(91956017)(2616005)(15650500001)(86362001)(66556008)(66446008)(8936002)(64756008)(8676002)(66476007)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IGhZPutcNkQol/9gilAgPZVmjX9tYbfECZB97hhJRDuAJ/0+kzKMN0LR6DFR9t5W9E3K/Guh2yDfaGMQhZmJA/C0be+coSoC9kLQsUiz7WOtwgLO0KVXiUT7v2crMnH2oGTn3bce+Do1D5n74NIUmprLgOrz6KWGCWilwzgvgFA0NHh5Zu7mlNod50Y0DRId6Xv/f2nwMlBCrLkg88Hdd6nUHefbxaj/BYQOnL5bWz1JBo1ZKcKlwKqqp0LkDzy/H8I295SKdcdR3uobL5KNVrTgv6yxSj01fQCgOnYo/cXPOQpUAwCpcqioLrN3I/LJ3Rm9rpRS/nJ5PnWGimXdpRe6ES+1b/4Rm7q670xvEjd5dg8ra5QDZM4uV6O6g479l+BRMg5tj3AEoP5IMcphpYEz/2L9BdNakdWs+cDSCZs9sAoRV7xYNp8pQtSTLPIZZEvE1S7razglFeMoYkr7bY9FMpToDFd9kSFCCl0nNr6yXuGgbMqUvMMDwPZJ23RwniiElUImi9aqNTTTHnU1rw== x-ms-exchange-antispam-messagedata: bZVYVHsYflGtfzFMqJqeLwON51axJW25q0HBg+Hob8CqXksRvuE+47TF2vWJ4UGYAhMBD9hKZymMk6pUZS4ujmNbKMRrHTMsinZLlmqTD8a+apI7bUhb3aTjISq7V+mLFi1bdunXfVCefEjcQAL2DyDFvScIN6DHPGi9rt3McbxESkrCHLqdqYYaa0B52BTZ4DtYNQvF/EZyRpby7e3ydA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <74FDC60FF17EB2459D77073CBEF2D79F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1d584cad-36c3-4f9d-b15b-08d7d6fdd548 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 12:03:18.8186 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JAFz9n9BsbHjOP24zZzwH5Njv5Fzzfr4ZWJV/5SMAEL5ikOMZ+n3aI2veIvRLeng8KCOLptgvRhJS6gFcgGXHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0076 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Taps] [Iot-directorate] Iotdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 12:03:31 -0000 VGhhbmsgeW91IE1vaGl0IGZvciB0aGUgcmV2aWV3Lg0KDQpJIHdpbGwgdGFrZSBpdCBpbnRvIGFj Y291bnQgZm9yIG15IGJhbGxvdCBwb3NpdGlvbi4NCg0KUmVnYXJkcw0KDQotw6lyaWMNCg0K77u/ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElvdC1kaXJlY3RvcmF0ZSA8aW90LWRp cmVjdG9yYXRlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpSZXBseS1UbzogTW9oaXQgU2V0aGkgPG1v aGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAxIEFwcmlsIDIwMjAg YXQgMTI6NDUNClRvOiAiaW90LWRpcmVjdG9yYXRlQGlldGYub3JnIiA8aW90LWRpcmVjdG9yYXRl QGlldGYub3JnPg0KQ2M6ICJsYXN0LWNhbGxAaWV0Zi5vcmciIDxsYXN0LWNhbGxAaWV0Zi5vcmc+ LCAiZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydC1zZWN1cml0eS5hbGxAaWV0Zi5vcmciIDxkcmFm dC1pZXRmLXRhcHMtdHJhbnNwb3J0LXNlY3VyaXR5LmFsbEBpZXRmLm9yZz4sICJ0YXBzQGlldGYu b3JnIiA8dGFwc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtJb3QtZGlyZWN0b3JhdGVdIElvdGRpciB0 ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydC1zZWN1cml0eS0xMQ0K DQogICAgUmV2aWV3ZXI6IE1vaGl0IFNldGhpDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0 aCBOaXRzDQogICAgDQogICAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHN1bW1hcnkgb2YgY29t bW9uIHNlY3VyaXR5IHByb3RvY29scy4gSXQgdGhlbg0KICAgIGRpc2N1c3NlcyB0aGUgaW50ZXJm YWNlcyB0aGF0IGV4aXN0IGJldHdlZW4gYXBwbGljYXRpb25zIGFuZCBzZWN1cml0eSBwcm90b2Nv bHMNCiAgICBhcyB3ZWxsIGFzIHNlY3VyaXR5IHByb3RvY29scyBhbmQgdHJhbnNwb3J0IHNlcnZp Y2VzLg0KICAgIA0KICAgIE1ham9yIGlzc3VlczogVGhlIGRvY3VtZW50IGhlYWRlciBzYXlzIHRo YXQgdGhpcyBkb2N1bWVudCBpcyBhYm91dCBpbnRlcmZhY2VzDQogICAgYmV0d2VlbiBzZWN1cml0 eSBwcm90b2NvbHMgYW5kIHRyYW5zcG9ydCBzZXJ2aWNlcy4gWWV0LCBsYXRlciBvbiwgSSBmaW5k IHRoYXQNCiAgICB0aGUgZG9jdW1lbnQgaXMgYWxzbyBkaXNjdXNzaW5nIHRoZSBpbnRlcmZhY2Vz IGJldHdlZW4gc2VjdXJpdHkgcHJvdG9jb2xzIGFuZA0KICAgIGFwcGxpY2F0aW9ucy4gUGVyaGFw cyB5b3UgY291bGQgYWRkICdhcHBsaWNhdGlvbnMnIHRvIHRoZSB0aXRsZSAtPiAnSW50ZXJhY3Rp b24NCiAgICBCZXR3ZWVuIEFwcGxpY2F0aW9ucywgU2VjdXJpdHkgUHJvdG9jb2xzLCBhbmQgVHJh bnNwb3J0IFNlcnZpY2VzJw0KICAgIA0KICAgIEVkaXRvcmlhbCBpc3N1ZXM6DQogICAgLSBJbnN0 ZWFkIG9mIHNheWluZyAnVGhpcyBwcm90b2NvbCBvYnNvbGV0ZXMgVENQIE1ENSAic2lnbmF0dXJl IiBvcHRpb25zJywgY2FuDQogICAgd2Ugc2F5ICdUQ1AtQU8gb2Jzb2xldGVzLi4uLicgdG8gYXZv aWQgY29uZnVzaW9uIG9mIHdoYXQgaXMgJ3RoaXMnIC0gUGxlYXNlDQogICAgZXhwYW5kICdhbmQg SVBzZWMgQUggW1JGQzQzMDJdJyAtPiBJUCBBdXRoZW50aWNhdGlvbiBIZWFkZXIgLSBBcmUgeW91 IHRhbGtpbmcNCiAgICBhYm91dCBjcnlwdG9ncmFwaGljIGFnaWxpdHkgaGVyZSAnc2VjdXJpdHkg cHJvdG9jb2xzOiBjb25maWRlbnRpYWxpdHksIHByaXZhY3kNCiAgICBwcm90ZWN0aW9ucywgYW5k IGFnaWxpdHkuJyA/IC0gQ29uc2lkZXIgY2hhbmdpbmcgJ2ludGVyZmFjZSBzdXJmYWNlIGV4cG9z ZWQgJy0+DQogICAgaW50ZXJmYWNlIGV4cG9zZWQgYnknLiBPdGhlcndpc2UgaXQgc291bmRzIHRv byBzaW1pbGFyIHRvIGF0dGFjayBzdXJmYWNlDQogICAgZXhwb3NlZC4gLSBFeHBhbmQgRUFQIGFu ZCByZWZlcmVuY2UgUkZDMzc0OC4gLSBQZXJoYXBzIHlvdSBjb3VsZCBzYXkgdGhhdA0KICAgIFNv dXJjZSBBZGRyZXNzIFZhbGlkYXRpb24gKFNBVikgdG8gcHJldmVudCBEb1MgaXMgcmVsZXZhbnQg Zm9yIHByb3RvY29scyB0aGF0DQogICAgdXNlIHVucmVsaWFibGUgdHJhbnNwb3J0Pw0KICAgIA0K ICAgIA0KICAgIC0tIA0KICAgIElvdC1kaXJlY3RvcmF0ZSBtYWlsaW5nIGxpc3QNCiAgICBJb3Qt ZGlyZWN0b3JhdGVAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lvdC1kaXJlY3RvcmF0ZQ0KICAgIA0KDQo= From nobody Thu Apr 2 05:59:24 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A570E3A1103 for ; Thu, 2 Apr 2020 05:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 6FzSbxRvvk7S for ; Thu, 2 Apr 2020 05:59:20 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59A733A10F4 for ; Thu, 2 Apr 2020 05:59:19 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 65C8C1B000AD for ; Thu, 2 Apr 2020 13:59:17 +0100 (BST) To: taps WG References: From: Gorry Fairhurst Message-ID: <7ef1ed7e-ea1b-3bf3-cfad-cbb1f3aec7ae@erg.abdn.ac.uk> Date: Thu, 2 Apr 2020 13:59:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------767C99B342E272783A451C77" Content-Language: en-GB Archived-At: Subject: Re: [Taps] [ietf-tapswg/api-drafts] Reliable Data Transfer (Message) default - from Kyle Rose's review (#520) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 12:59:23 -0000 This is a multi-part message in MIME format. --------------767C99B342E272783A451C77 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We seem to need to decide what "Reliable Data Transfer" means to an Application. My point. expanding here a little, is: TAPS has to by default do something if the app doesn't say what it wants. So this is really about the default service chosen by TAPS.  A safe assumption is that an app not designed for reordering, loss, duplication etc  will receive the default service, that's why I think this should be "Reliable Data Transfer". Apps that CAN handle all of these need to tell the TAPS Interface that they do not need a "Reliable Data Transfer". If the app does not do this, and happens to exist on a stack that only supports datagrams, then it would not be able to connect. Gorry On 02/04/2020 13:32, mwelzl wrote: > > List discussion: > > *Kyle:* > > 7.4.7. Reliable Data Transfer (Message) > > * The default isn't "true", it's whatever the underlying > connection had, right? > > *@philsbln *: > > Ack > > *@mwelzl *: > > I agree too, but doesn’t this warrant some more discussion? > I think our defaults all translate into things that can work in > some way when TCP is used - with “Reliable Data Transfer” being an > exception, as it just can’t work in a UDP-only system. Are there > others? I think I’ll open an issue for this one. > > *@gorryfair *: > > I don't agree at all - To me this was just the default behaviour > of the API. > > I think the default needs to be "reliable" and an app will have to > over-ride that to get datagram/unreliable operation. That doesn't > mean if you have only UDP (for instance) that you can't offer > TAPS, to me it simply means you always need to say that the app > wants this service. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or unsubscribe > . > --------------767C99B342E272783A451C77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

We seem to need to decide what "Reliable Data Transfer" means to an Application.

My point. expanding here a little, is:

TAPS has to by default do something if the app doesn't say what it wants. So this is really about the default service chosen by TAPS.  A safe assumption is that an app not designed for reordering, loss, duplication etc  will receive the default service, that's why I think this should be "Reliable Data Transfer".

Apps that CAN handle all of these need to tell the TAPS Interface that they do not need a "Reliable Data Transfer". If the app does not do this, and happens to exist on a stack that only supports datagrams, then it would not be able to connect.

Gorry

On 02/04/2020 13:32, mwelzl wrote:

List discussion:

Kyle:

7.4.7. Reliable Data Transfer (Message)

  • The default isn't "true", it's whatever the underlying connection had, right?

@philsbln:

Ack

@mwelzl:

I agree too, but doesn’t this warrant some more discussion?
I think our defaults all translate into things that can work in some way when TCP is used - with “Reliable Data Transfer” being an exception, as it just can’t work in a UDP-only system. Are there others? I think I’ll open an issue for this one.

@gorryfair:

I don't agree at all - To me this was just the default behaviour of the API.

I think the default needs to be "reliable" and an app will have to over-ride that to get datagram/unreliable operation. That doesn't mean if you have only UDP (for instance) that you can't offer TAPS, to me it simply means you always need to say that the app wants this service.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

--------------767C99B342E272783A451C77-- From nobody Thu Apr 2 07:54:45 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465763A1072 for ; Thu, 2 Apr 2020 07:54:09 -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, 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 AgwMgRZV_Wdv for ; Thu, 2 Apr 2020 07:53:58 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 7B53D3A0FFD for ; Thu, 2 Apr 2020 07:53:57 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jK1EB-00035B-59 for taps@ietf.org; Thu, 02 Apr 2020 16:53:55 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jK1E9-000Efs-S2 for taps@ietf.org; Thu, 02 Apr 2020 16:53:55 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <13BF9A2E-795C-41A1-BDD8-B49AED81D503@ifi.uio.no> Date: Thu, 2 Apr 2020 16:53:53 +0200 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; 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: E94C1AA9464104A86F1E51D5DF39B2A414764AB1 Archived-At: Subject: [Taps] Kyle Rose's review of the API draft X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 14:54:10 -0000 Hi, I sifted through the review now, trying to address some easy things, = removing some more things that were already addressed, creating issues = for things that require some discussion=E2=80=A6 as a result, we now = have new PR #515, issues #520 - #526, and here is one item thatI=E2=80=99d= like to check with Kyle via this email: 5.2. Specifying Transport Properties * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried = output of selected properties seems like a shortcut that will lead to = some confusion. MW: I agree; partially addressed: s/Required/Require wherever it's a = Preference level. Kyle: FWIW, my objection to the other issue (using a normative term as = an indication of what was chosen) isn't that it's underspecified, only = that it's confusing. I put it roughly in the same category as specifying = -1 as an error indicator in an abstract API. Is the idea that the output = parameters could be fed into the protocol selection logic for a = subsequent connection to select the same protocol? Is that useful? Philipp Tiesel: We had text saying that these should turn into Boolean = when queried and should reflect whether the protocol stack chosen = provides the feature. I will have to double-check whether this text is = still in the description of the preference type. MW: I found this text: "Querying a Selection Property after = establishment yields the value Require for properties of the selected = protocol and path, Avoid for properties avoided during selection, and = Ignore for all other properties." - this seems ok to me. Kyle? Cheers, Michael - - - PS: I believe that the ones below are resolved, but I'm repeating them = here in case someone disagrees with an answer: 11.1.10. Capacity Profile * Very little of this section is about capacity. Traffic Profile? Gorry Fairhurst: > I don't much like Traffic Profile - to a traffic profile specifies the = characteristics of the traffic the sender is transmitting, not the = treatment that traffic expects from the network service. 5.2.11. Provisioning Domain Instance or Type * What about ordering of similar interfaces? I have a 2-SIM cellphone = with wifi. Philipp Tiesel: > Each cellular provider will have a unique PVD. 8.2. Receive Events * "A call to Receive will be paired with a single Receive Event" or = possibly multiple ReceivedPartial Events? * Also, can the draft be consistent about Receive vs. Received, et al.? MW: I can't find a consistency problem; I think that some such things = were already fixed with recent PR's, perhaps this problem has = self-resolved. From nobody Thu Apr 2 12:35:32 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAA3A1043 for ; Thu, 2 Apr 2020 12:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=krose.org 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 6MqIZsPUnjWS for ; Thu, 2 Apr 2020 12:35:29 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 577993A103F for ; Thu, 2 Apr 2020 12:35:29 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id o70so2796224ybg.10 for ; Thu, 02 Apr 2020 12:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2/MrSLF6tC3sGBUcE3MzuanIQ8PkqW6YEuzC2pd1/L8=; b=q+QGPS+bWMwcYwgD4egeUNTwZWWXZ7uitIqWkgPunAt7bfjjuk3x0g0X8Vnv8FQ3io o734vurefr45/SA13is2+krjkoSG99jPAihK+nz6ylVz63fMFH/uvcLG2rpmzwKJEKSz 3SHfv0eabrAl8vi7K1PEDIwccNDMr3s+PiMXg= 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=2/MrSLF6tC3sGBUcE3MzuanIQ8PkqW6YEuzC2pd1/L8=; b=o0QyDbyUDcgcw0VJ30I71t96KEGRI3B+vThnZVDLn0/LUgy0GeqbTV0LYDYqeOGnlE NCGTaodwl+/s1y7nYdX5QZHgvB4b4+4aglLlx4d+cBhy387ZGLlHA+oecm3C7MFgi2x1 ddRpOROWY1fzJrQ4yVQWFdS8VDD83R1IfbFHTJ+6gAOOMbKAzoXcAZmLKyTGP4yE7Amy pS0Pfj9dR+gAFsYTOQEjeiCcJuRix7zzlW/9ZMJP4asVkj3ozbjyOgg6NFXoiGVi3l/Y /xJTgeDRea0mKwErtQeUGBFFfpJPAWN8ol37OQjRz6wvlMe6DPCAKR8SHTOecKA3k0JL ix/Q== X-Gm-Message-State: AGi0PuZgIjkRmDUud8JFwJjeXbLMyGUCAXVtMONh+w4SfmT/KZ+KAc7R XbKRDCCjKHzlkASCZIQAW2uO8o6iW2RmLl0mBuTXK6Qihnk= X-Google-Smtp-Source: APiQypLiceigIDULdO6Oxo72pjYXERYaAciyaf3ZRxOWSfv3bcKit8bzoLGvL/RBV5Hqi7xEuJce4hgwYcFIs6z9fXE= X-Received: by 2002:a25:4ac4:: with SMTP id x187mr7578592yba.401.1585856126981; Thu, 02 Apr 2020 12:35:26 -0700 (PDT) MIME-Version: 1.0 References: <7ef1ed7e-ea1b-3bf3-cfad-cbb1f3aec7ae@erg.abdn.ac.uk> In-Reply-To: <7ef1ed7e-ea1b-3bf3-cfad-cbb1f3aec7ae@erg.abdn.ac.uk> From: Kyle Rose Date: Thu, 2 Apr 2020 15:35:15 -0400 Message-ID: To: Gorry Fairhurst Cc: taps WG Content-Type: multipart/alternative; boundary="0000000000001d301405a253e7b3" Archived-At: Subject: Re: [Taps] [ietf-tapswg/api-drafts] Reliable Data Transfer (Message) default - from Kyle Rose's review (#520) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 19:35:32 -0000 --0000000000001d301405a253e7b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm okay with this. On Thu, Apr 2, 2020 at 8:59 AM Gorry Fairhurst wrote= : > We seem to need to decide what "Reliable Data Transfer" means to an > Application. > > My point. expanding here a little, is: > > TAPS has to by default do something if the app doesn't say what it wants. > So this is really about the default service chosen by TAPS. A safe > assumption is that an app not designed for reordering, loss, duplication > etc will receive the default service, that's why I think this should be > "Reliable Data Transfer". > > Apps that CAN handle all of these need to tell the TAPS Interface that > they do not need a "Reliable Data Transfer". If the app does not do this, > and happens to exist on a stack that only supports datagrams, then it wou= ld > not be able to connect. > > Gorry > On 02/04/2020 13:32, mwelzl wrote: > > List discussion: > > *Kyle:* > > 7.4.7. Reliable Data Transfer (Message) > > - The default isn't "true", it's whatever the underlying connection > had, right? > > *@philsbln *: > > Ack > > *@mwelzl *: > > I agree too, but doesn=E2=80=99t this warrant some more discussion? > I think our defaults all translate into things that can work in some way > when TCP is used - with =E2=80=9CReliable Data Transfer=E2=80=9D being an= exception, as it > just can=E2=80=99t work in a UDP-only system. Are there others? I think I= =E2=80=99ll open > an issue for this one. > > *@gorryfair *: > > I don't agree at all - To me this was just the default behaviour of the > API. > > I think the default needs to be "reliable" and an app will have to > over-ride that to get datagram/unreliable operation. That doesn't mean if > you have only UDP (for instance) that you can't offer TAPS, to me it simp= ly > means you always need to say that the app wants this service. > > =E2=80=94 > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > , or unsubscribe > > . > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --0000000000001d301405a253e7b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I&#= 39;m okay with this.

On Thu, Apr 2, 2020 at 8:59 AM Gorry Fairhurs= t <gorry@erg.abdn.ac.uk> = wrote:
=20 =20 =20

We seem to need to decide what "Reliable Data Transfer" me= ans to an Application.

My point. expanding here a little, is:

TAPS has to by default do something if the app doesn't say what it wants. So this is really about the default service chosen by TAPS.=C2=A0 A safe assumption is that an app not designed for reordering, loss, duplication etc=C2=A0 will receive the default service, that's why I think this should be "Reliable Data Tr= ansfer".

Apps that CAN handle all of these need to tell the TAPS Interface that they do not need a "Reliable Data Transfer". If the ap= p does not do this, and happens to exist on a stack that only supports datagrams, then it would not be able to connect.

Gorry

On 02/04/2020 13:32, mwelzl wrote:
=20

List discussion:

Kyle:

7.4.7. Reliable Data Transfer (Message)

  • The default isn't "true", it's whatever the= underlying connection had, right?

= @philsbln:

Ack

@m= welzl:

I agree too, but doesn=E2=80=99t this warrant some more discussi= on?
I think our defaults all translate into things that can work in some way when TCP is used - with =E2=80=9CReliable Data Transf= er=E2=80=9D being an exception, as it just can=E2=80=99t work in a UDP-only system. Are there others? I think I=E2=80=99ll open an issue for = this one.

@gorryfair:

I don't agree at all - To me this was just the default behaviour of the API.

I think the default needs to be "reliable" and an app = will have to over-ride that to get datagram/unreliable operation. That doesn't mean if you have only UDP (for instance) that yo= u can't offer TAPS, to me it simply means you always need to sa= y that the app wants this service.

=E2=80=94
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.3D"=

=20
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--0000000000001d301405a253e7b3-- From nobody Thu Apr 2 13:42:22 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CCF3A1933 for ; Thu, 2 Apr 2020 13:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=krose.org 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 md8fvHEbIcx6 for ; Thu, 2 Apr 2020 13:42:17 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 171273A1934 for ; Thu, 2 Apr 2020 13:42:16 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id g6so2903359ybh.12 for ; Thu, 02 Apr 2020 13:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8cXIh+PLdq5RgQ99doUBg5cKBxFXwIrgx0Ef3dHIpN0=; b=qqoWlD4KhkipCmfP90cJs9wzEmwWf1KaIGA10nIVqngeJpHeuGU9OONS00uqrh6PST EISr66VUSoeARSPyhkJ6jz3rZSBjEMX5hfGGxSX66c+f23S2riSa0Q1BcEQxsJLo82re +0BQeybF84AMxfyjQ0Uusm0oGkQCB10SqupoY= 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=8cXIh+PLdq5RgQ99doUBg5cKBxFXwIrgx0Ef3dHIpN0=; b=UljqEZvPTKxPZ48xWZY7R5K7NUvp4r0q/ABdBhGJHOXsVKILsw4wnxS4ye25ag4ORR bIm+W2wwkH16A2G2rves/CxjFjHwQvv960UKfBW1xX+2lwUkIYLeZxoCEY1ZblaVhkts mFM8+wgAAFICHHpS0VaFRd2WAPcB/iADPXT+DOdMVye4IT00zi9zP5K0A9YcgG2CkKum rFTkfhv7tRY79Pmra1OG6TiSErnCQDQQ+UbRe35nKQIJUo7bMWyaMjvPGXPgUF8loNBe D17CxL5GVqyyqWRk9nMn0E6CfnKWMsD4RPTsTf5cL8fvCJjuSZJFyTNDxrdaAm1N2pe4 plRw== X-Gm-Message-State: AGi0Pub+tuD+/MeA0peZPtonNUwjniuD0/3qTiti+QD+jTlyJ7/JmHHt P8N3VheQkRuvFAylmtLVFOWGYF43SMG9kYvCF57r/Q== X-Google-Smtp-Source: APiQypJOl3KRsN6QN30aI7FN41LHaFFiwFgifhaHqmu1jFlT6taI27b2GBxNZbdPF5OAiWyZkerpQOlvUU1BjTFJz+A= X-Received: by 2002:a25:4b46:: with SMTP id y67mr8288515yba.379.1585860135888; Thu, 02 Apr 2020 13:42:15 -0700 (PDT) MIME-Version: 1.0 References: <13BF9A2E-795C-41A1-BDD8-B49AED81D503@ifi.uio.no> In-Reply-To: <13BF9A2E-795C-41A1-BDD8-B49AED81D503@ifi.uio.no> From: Kyle Rose Date: Thu, 2 Apr 2020 16:42:04 -0400 Message-ID: To: Michael Welzl Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="000000000000103e1505a254d602" Archived-At: Subject: Re: [Taps] Kyle Rose's review of the API draft X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 20:42:21 -0000 --000000000000103e1505a254d602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl wrote: > Hi, > > I sifted through the review now, trying to address some easy things, > removing some more things that were already addressed, creating issues fo= r > things that require some discussion=E2=80=A6 as a result, we now have new= PR #515, > issues #520 - #526, and here is one item thatI=E2=80=99d like to check wi= th Kyle > via this email: > > 5.2. Specifying Transport Properties > > * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried > output of selected properties seems like a shortcut that will lead to som= e > confusion. > > MW: I agree; partially addressed: s/Required/Require wherever it's a > Preference level. > > Kyle: FWIW, my objection to the other issue (using a normative term as an > indication of what was chosen) isn't that it's underspecified, only that > it's confusing. I put it roughly in the same category as specifying -1 as > an error indicator in an abstract API. Is the idea that the output > parameters could be fed into the protocol selection logic for a subsequen= t > connection to select the same protocol? Is that useful? > > Philipp Tiesel: We had text saying that these should turn into Boolean > when queried and should reflect whether the protocol stack chosen provide= s > the feature. I will have to double-check whether this text is still in th= e > description of the preference type. > > MW: I found this text: "Querying a Selection Property after establishment > yields the value Require for properties of the selected protocol and path= , > Avoid for properties avoided during selection, and Ignore for all other > properties." - this seems ok to me. Kyle? > I don't have a strong opinion about it. I just find it potentially confusing. Just in case, the alternative I had in mind was having an output enum something like { Selected, Avoided, Ignored } independent of the input type. As long as you understand this and are still okay with the interface you've chosen, that is fine by me. If you go with the existing approach, I wonder if "Avoid" should be "Prohibit", analogous to "Require" for selected properties. (Similarly, maybe the opposite of "Selected" is "Prohibited" in my alternative approach.) > 11.1.10. Capacity Profile > > * Very little of this section is about capacity. Traffic Profile? > > Gorry Fairhurst: > > I don't much like Traffic Profile - to a traffic profile specifies the > characteristics of the traffic the sender is transmitting, not the > treatment that traffic expects from the network service. > I'm trying to think of "capacity" as "path and protocol selection and network treatment", but it's just not clicking. Maybe there's a term of art definition of "capacity" I'm just not familiar with. I buy "capacity" as "network treatment", but path selection and protocol selection are both properties of the traffic as defined by the endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, not something I feel especially strongly about.) 5.2.11. Provisioning Domain Instance or Type > > * What about ordering of similar interfaces? I have a 2-SIM cellphone wit= h > wifi. > > Philipp Tiesel: > > Each cellular provider will have a unique PVD. > SGTM. > 8.2. Receive Events > > * "A call to Receive will be paired with a single Receive Event" or > possibly multiple ReceivedPartial Events? > > * Also, can the draft be consistent about Receive vs. Received, et al.? > > MW: I can't find a consistency problem; I think that some such things wer= e > already fixed with recent PR's, perhaps this problem has self-resolved. > Also LGTM. Thanks for the thoroughness, BTW. This is also the kick in the ass I needed to get back to looking at this. :-) --000000000000103e1505a254d602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

I sifted through the review now, trying to address some easy things, removi= ng some more things that were already addressed, creating issues for things= that require some discussion=E2=80=A6 as a result, we now have new PR #515= , issues #520 - #526, and here is one item thatI=E2=80=99d like to check wi= th Kyle via this email:

5.2. Specifying Transport Properties

* Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output= of selected properties seems like a shortcut that will lead to some confus= ion.

MW: I agree;=C2=A0 partially addressed: s/Required/Require wherever it'= s a Preference level.

Kyle: FWIW, my objection to the other issue (using a normative term as an i= ndication of what was chosen) isn't that it's underspecified, only = that it's confusing. I put it roughly in the same category as specifyin= g -1 as an error indicator in an abstract API. Is the idea that the output = parameters could be fed into the protocol selection logic for a subsequent = connection to select the same protocol? Is that useful?

Philipp Tiesel: We had text saying that these should turn into Boolean when= queried and should reflect whether the protocol stack chosen provides the = feature. I will have to double-check whether this text is still in the desc= ription of the preference type.

MW: I found this text: "Querying a Selection Property after establishm= ent yields the value Require for properties of the selected protocol and pa= th, Avoid for properties avoided during selection, and Ignore for all other= properties."=C2=A0 =C2=A0- this seems ok to me. Kyle?

I don't have a strong opinion about it. I just find it potentially con= fusing. Just in case, the alternative I had in mind was having an output en= um something like { Selected, Avoided, Ignored } independent of the input t= ype. As long as you understand this and are still okay with the interface y= ou've chosen, that is fine by me.

If you go with the existing approach, I wonder if "Avoid&= quot; should be "Prohibit", analogous to "Require" for = selected properties. (Similarly, maybe the opposite of "Selected"= is "Prohibited" in my alternative approach.)
=C2=A0
11.1.10.= Capacity Profile

* Very little of this section is about capacity. Traffic Profile?

Gorry Fairhurst:
> I don't much like Traffic Profile - to a traffic profile specifies= the characteristics of the traffic the sender is transmitting, not the tre= atment that traffic expects from the network service.
=
I'= ;m trying to think of "capacity" as "path and protocol selec= tion and network treatment", but it's just not clicking. Maybe the= re's a term of art definition of "capacity" I'm just not = familiar with. I buy "capacity" as "network treatment",= but path selection and protocol selection are both properties of the traff= ic as defined by the endpoints, is it not? Maybe "Capacity and Traffic= Profile"? (Again, not something I feel especially strongly about.)

5.2.11. Provisioning Domain Instance or Type

* What about ordering of similar interfaces? I have a 2-SIM cellphone with = wifi.

Philipp Tiesel:
> Each cellular provider will have a unique PVD.
SGTM.
=C2=A0
Also LGTM.

Thanks for the thoroughness, B= TW. This is also the kick in the ass I needed to get back to looking at thi= s. :-)

--000000000000103e1505a254d602-- From nobody Fri Apr 3 01:02:20 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F83A13B0 for ; Fri, 3 Apr 2020 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 m5faq1uAsADm for ; Fri, 3 Apr 2020 01:02:17 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 E34333A13AD for ; Fri, 3 Apr 2020 01:02:16 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1jKHFD-0001fX-Rn for taps@ietf.org; Fri, 03 Apr 2020 08:00:03 +0000 Content-Type: multipart/alternative; boundary="===============5296213647120462421==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 03 Apr 2020 08:00:03 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 08:02:19 -0000 --===============5296213647120462421== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+7/-2/=F0=9F=92=AC14) 7 issues created: - 7.3.1 Sent (from Kyle Rose's review) (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/526 [API] = - single messageContext object for both sends and receives (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/525 [API] = - What constitutes trust verification prior to the handshake? (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/524 [API] = - Registry for "interface instance or type" (from Kyle Rose's review) (b= y mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/523 [API] = - Idempotency vs replay-safe (from Kyle Rose's review) (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/522 = - IANA registry of property names or namespaces - from Kyle Rose's review= (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/521 = - Reliable Data Transfer (Message) default - from Kyle Rose's review (by = mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/520 = 6 issues received 14 new comments: - #522 Idempotency vs replay-safe (from Kyle Rose's review) (5 by squaro= oticus, mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/522 [API] [discuss] = - #520 Reliable Data Transfer (Message) default - from Kyle Rose's review= (3 by abrunstrom, gorryfair, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/520 [API] [discuss] = - #438 Retransmit notify (3 by mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/438 [API] [ready for t= ext] = - #418 Use of normative language in Arch (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] [di= scuss] = - #525 single messageContext object for both sends and receives (1 by mwe= lzl) https://github.com/ietf-tapswg/api-drafts/issues/525 [API] = - #494 Comments on DSCP text (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/494 [API] = 2 issues closed: - Retransmit notify https://github.com/ietf-tapswg/api-drafts/issues/438 = [API] [ready for text] = - Comments on DSCP text https://github.com/ietf-tapswg/api-drafts/issues/= 494 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC2) 1 pull requests submitted: - Closes #515. + addresses a few more of the easy things from Kyle's rev= iew. (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/527 = 1 pull requests received 2 new comments: - #433 Editorial nits to improve consistency (2 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/433 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============5296213647120462421== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday April 03, 2020

Issues

ietf-tapswg/api-drafts (+7/-2/=F0=9F=92=AC14)

7 issues created:

6 issues received 14 new comments:

2 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC2)

1 pull requests submitted:

1 pull requests received 2 new comments:

Repositories tracked by this digest:

--===============5296213647120462421==-- From nobody Fri Apr 3 03:20:16 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475D33A16E7 for ; Fri, 3 Apr 2020 03:20:14 -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, HTML_MESSAGE=0.001, 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 o35re_skyF58 for ; Fri, 3 Apr 2020 03:20:09 -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 4B5093A16E9 for ; Fri, 3 Apr 2020 03:20:08 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jKJQj-000EVH-OL; Fri, 03 Apr 2020 12:20:05 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jKJQh-0003ld-RK; Fri, 03 Apr 2020 12:20:05 +0200 From: Michael Welzl Message-Id: <552113A1-A2BE-407C-8DC5-A1379BCAB81A@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_79D3D7E5-4B0D-4EEE-AE6A-D73C95EE7DE5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 3 Apr 2020 12:20:03 +0200 In-Reply-To: Cc: "taps@ietf.org" To: Kyle Rose References: <13BF9A2E-795C-41A1-BDD8-B49AED81D503@ifi.uio.no> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8647572227B03A3244988DF2CFCB1AD77DD2D9F3 Archived-At: Subject: Re: [Taps] Kyle Rose's review of the API draft X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 10:20:14 -0000 --Apple-Mail=_79D3D7E5-4B0D-4EEE-AE6A-D73C95EE7DE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Apr 2, 2020, at 10:42 PM, Kyle Rose wrote: >=20 > On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl > wrote: > Hi, >=20 > I sifted through the review now, trying to address some easy things, = removing some more things that were already addressed, creating issues = for things that require some discussion=E2=80=A6 as a result, we now = have new PR #515, issues #520 - #526, and here is one item thatI=E2=80=99d= like to check with Kyle via this email: >=20 > 5.2. Specifying Transport Properties >=20 > * Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried = output of selected properties seems like a shortcut that will lead to = some confusion. >=20 > MW: I agree; partially addressed: s/Required/Require wherever it's a = Preference level. >=20 > Kyle: FWIW, my objection to the other issue (using a normative term as = an indication of what was chosen) isn't that it's underspecified, only = that it's confusing. I put it roughly in the same category as specifying = -1 as an error indicator in an abstract API. Is the idea that the output = parameters could be fed into the protocol selection logic for a = subsequent connection to select the same protocol? Is that useful? >=20 > Philipp Tiesel: We had text saying that these should turn into Boolean = when queried and should reflect whether the protocol stack chosen = provides the feature. I will have to double-check whether this text is = still in the description of the preference type. >=20 > MW: I found this text: "Querying a Selection Property after = establishment yields the value Require for properties of the selected = protocol and path, Avoid for properties avoided during selection, and = Ignore for all other properties." - this seems ok to me. Kyle? >=20 > I don't have a strong opinion about it. I just find it potentially = confusing. Just in case, the alternative I had in mind was having an = output enum something like { Selected, Avoided, Ignored } independent of = the input type. As long as you understand this and are still okay with = the interface you've chosen, that is fine by me. I got it now, and I think your proposal is much better. I=E2=80=99ll do = this in a PR. > If you go with the existing approach, I wonder if "Avoid" should be = "Prohibit", analogous to "Require" for selected properties. (Similarly, = maybe the opposite of "Selected" is "Prohibited" in my alternative = approach.) > =20 > 11.1.10. Capacity Profile >=20 > * Very little of this section is about capacity. Traffic Profile? >=20 > Gorry Fairhurst: > > I don't much like Traffic Profile - to a traffic profile specifies = the characteristics of the traffic the sender is transmitting, not the = treatment that traffic expects from the network service. >=20 > I'm trying to think of "capacity" as "path and protocol selection and = network treatment", but it's just not clicking. Maybe there's a term of = art definition of "capacity" I'm just not familiar with. I buy = "capacity" as "network treatment", but path selection and protocol = selection are both properties of the traffic as defined by the = endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, not = something I feel especially strongly about.) I also don=E2=80=99t have a strong opinion about this, but I=E2=80=99ll = leave it for Gorry to answer. > 5.2.11. Provisioning Domain Instance or Type >=20 > * What about ordering of similar interfaces? I have a 2-SIM cellphone = with wifi. >=20 > Philipp Tiesel: > > Each cellular provider will have a unique PVD. >=20 > SGTM. > =20 > 8.2. Receive Events >=20 > * "A call to Receive will be paired with a single Receive Event" or = possibly multiple ReceivedPartial Events? >=20 > * Also, can the draft be consistent about Receive vs. Received, et = al.? >=20 > MW: I can't find a consistency problem; I think that some such things = were already fixed with recent PR's, perhaps this problem has = self-resolved. >=20 > Also LGTM. >=20 > Thanks for the thoroughness, BTW. This is also the kick in the ass I = needed to get back to looking at this. :-) Thanks to you for your careful review! Cheers, Michael --Apple-Mail=_79D3D7E5-4B0D-4EEE-AE6A-D73C95EE7DE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,


On Apr = 2, 2020, at 10:42 PM, Kyle Rose <krose@krose.org> wrote:

On Thu, Apr = 2, 2020 at 10:54 AM Michael Welzl <michawe@ifi.uio.no> = wrote:
Hi,

I sifted through = the review now, trying to address some easy things, removing some more = things that were already addressed, creating issues for things that = require some discussion=E2=80=A6 as a result, we now have new PR #515, = issues #520 - #526, and here is one item thatI=E2=80=99d like to check = with Kyle via this email:

5.2. Specifying = Transport Properties

* Using the same enum = (Require(d[sic])/Avoid/Ignore) for the queried output of selected = properties seems like a shortcut that will lead to some confusion.

MW: I agree;  partially addressed: = s/Required/Require wherever it's a Preference level.

Kyle: FWIW, my objection to the other issue (using a = normative term as an indication of what was chosen) isn't that it's = underspecified, only that it's confusing. I put it roughly in the same = category as specifying -1 as an error indicator in an abstract API. Is = the idea that the output parameters could be fed into the protocol = selection logic for a subsequent connection to select the same protocol? = Is that useful?

Philipp Tiesel: We had text = saying that these should turn into Boolean when queried and should = reflect whether the protocol stack chosen provides the feature. I will = have to double-check whether this text is still in the description of = the preference type.

MW: I found this text: = "Querying a Selection Property after establishment yields the value = Require for properties of the selected protocol and path, Avoid for = properties avoided during selection, and Ignore for all other = properties."   - this seems ok to me. Kyle?

I = don't have a strong opinion about it. I just find it potentially = confusing. Just in case, the alternative I had in mind was having an = output enum something like { Selected, Avoided, Ignored } independent of = the input type. As long as you understand this and are still okay with = the interface you've chosen, that is fine by = me.

I = got it now, and I think your proposal is much better. I=E2=80=99ll do = this in a PR.


If = you go with the existing approach, I wonder if "Avoid" should be = "Prohibit", analogous to "Require" for selected properties. (Similarly, = maybe the opposite of "Selected" is "Prohibited" in my alternative = approach.)
 
11.1.10. = Capacity Profile

* Very little of this = section is about capacity. Traffic Profile?

Gorry Fairhurst:
> I don't much like Traffic = Profile - to a traffic profile specifies the characteristics of the = traffic the sender is transmitting, not the treatment that traffic = expects from the network service.

I'm trying to think = of "capacity" as "path and protocol selection and network treatment", = but it's just not clicking. Maybe there's a term of art definition of = "capacity" I'm just not familiar with. I buy "capacity" as "network = treatment", but path selection and protocol selection are both = properties of the traffic as defined by the endpoints, is it not? Maybe = "Capacity and Traffic Profile"? (Again, not something I feel especially = strongly about.)

I also don=E2=80=99t have a strong opinion about this, = but I=E2=80=99ll leave it for Gorry to answer.


5.2.11. Provisioning Domain = Instance or Type

* What about ordering of = similar interfaces? I have a 2-SIM cellphone with wifi.

Philipp Tiesel:
> Each cellular provider = will have a unique PVD.

SGTM.
 
8.2. Receive = Events

* "A call to Receive will be paired = with a single Receive Event" or possibly multiple ReceivedPartial = Events?

* Also, can the draft be consistent = about Receive vs. Received, et al.?

MW: I = can't find a consistency problem; I think that some such things were = already fixed with recent PR's, perhaps this problem has = self-resolved.

Also LGTM.

Thanks for the thoroughness, BTW. This is = also the kick in the ass I needed to get back to looking at this. = :-)

Thanks to you for your careful = review!

Cheers,
Michael

= --Apple-Mail=_79D3D7E5-4B0D-4EEE-AE6A-D73C95EE7DE5-- From nobody Fri Apr 3 04:42:43 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4123A1008 for ; Fri, 3 Apr 2020 04:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 sA6STZ0snrQu for ; Fri, 3 Apr 2020 04:42:34 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 240E73A0F29 for ; Fri, 3 Apr 2020 04:42:33 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5B9211B00199; Fri, 3 Apr 2020 12:42:27 +0100 (BST) To: Michael Welzl , Kyle Rose Cc: "taps@ietf.org" References: <13BF9A2E-795C-41A1-BDD8-B49AED81D503@ifi.uio.no> <552113A1-A2BE-407C-8DC5-A1379BCAB81A@ifi.uio.no> From: Gorry Fairhurst Message-ID: <19517833-0379-82ae-3f83-8aee18a9ac1f@erg.abdn.ac.uk> Date: Fri, 3 Apr 2020 12:42:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <552113A1-A2BE-407C-8DC5-A1379BCAB81A@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------4B3C4504141AC5BE967DA6D9" Content-Language: en-GB Archived-At: Subject: Re: [Taps] Kyle Rose's review of the API draft X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 11:42:42 -0000 This is a multi-part message in MIME format. --------------4B3C4504141AC5BE967DA6D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit See below. On 03/04/2020 11:20, Michael Welzl wrote: > Hi, > > >> On Apr 2, 2020, at 10:42 PM, Kyle Rose > > wrote: >> >> On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl > > wrote: >> >> Hi, >> >> I sifted through the review now, trying to address some easy >> things, removing some more things that were already addressed, >> creating issues for things that require some discussion… as a >> result, we now have new PR #515, issues #520 - #526, and here is >> one item thatI’d like to check with Kyle via this email: >> >> 5.2. Specifying Transport Properties >> >> * Using the same enum (Require(d[sic])/Avoid/Ignore) for the >> queried output of selected properties seems like a shortcut that >> will lead to some confusion. >> >> MW: I agree;  partially addressed: s/Required/Require wherever >> it's a Preference level. >> >> Kyle: FWIW, my objection to the other issue (using a normative >> term as an indication of what was chosen) isn't that it's >> underspecified, only that it's confusing. I put it roughly in the >> same category as specifying -1 as an error indicator in an >> abstract API. Is the idea that the output parameters could be fed >> into the protocol selection logic for a subsequent connection to >> select the same protocol? Is that useful? >> >> Philipp Tiesel: We had text saying that these should turn into >> Boolean when queried and should reflect whether the protocol >> stack chosen provides the feature. I will have to double-check >> whether this text is still in the description of the preference type. >> >> MW: I found this text: "Querying a Selection Property after >> establishment yields the value Require for properties of the >> selected protocol and path, Avoid for properties avoided during >> selection, and Ignore for all other properties."  - this seems ok >> to me. Kyle? >> >> >> I don't have a strong opinion about it. I just find it potentially >> confusing. Just in case, the alternative I had in mind was having an >> output enum something like { Selected, Avoided, Ignored } independent >> of the input type. As long as you understand this and are still okay >> with the interface you've chosen, that is fine by me. > > I got it now, and I think your proposal is much better. I’ll do this > in a PR. > > >> If you go with the existing approach, I wonder if "Avoid" should be >> "Prohibit", analogous to "Require" for selected properties. >> (Similarly, maybe the opposite of "Selected" is "Prohibited" in my >> alternative approach.) >> >> 11.1.10. Capacity Profile >> >> * Very little of this section is about capacity. Traffic Profile? >> >> Gorry Fairhurst: >> > I don't much like Traffic Profile - to a traffic profile >> specifies the characteristics of the traffic the sender is >> transmitting, not the treatment that traffic expects from the >> network service. >> >> >> I'm trying to think of "capacity" as "path and protocol selection and >> network treatment", but it's just not clicking. Maybe there's a term >> of art definition of "capacity" I'm just not familiar with. I buy >> "capacity" as "network treatment", but path selection and protocol >> selection are both properties of the traffic as defined by the >> endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, >> not something I feel especially strongly about.) > > I also don’t have a strong opinion about this, but I’ll leave it for > Gorry to answer. > > To me: Traffic profile makes me think of TSpec, MF-Classifier, etc. Something that I can define within a network device that will decide what forwarding behaviour I see, and how I may police to this. in DS, this could be defined as "A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile." [RFC2475]. To me this isn't that? Capacity is about how fast a sender can currently send along a path. My expectations for accessing capacity might be related to the treatement I tell the network that I wish to receive, such as the DSCP that is set. However, this isn't a capacity specification, and a capacity profile is just about OK to me - but not perfect, because the description doesn't "profile" capacity. I'd be OK with a range of words here - and not OK with some others. Other possibilities could be: "Network Service" "Network Service Marking" Or even more-specific: "DS Marking" I would be very happy to think upon others - but the keyword space is limited and we should avoid overlap with terms that mean something else :-). Gorry >> 5.2.11. Provisioning Domain Instance or Type >> >> * What about ordering of similar interfaces? I have a 2-SIM >> cellphone with wifi. >> >> Philipp Tiesel: >> > Each cellular provider will have a unique PVD. >> >> >> SGTM. >> >> 8.2. Receive Events >> >> * "A call to Receive will be paired with a single Receive Event" >> or possibly multiple ReceivedPartial Events? >> >> * Also, can the draft be consistent about Receive vs. Received, >> et al.? >> >> MW: I can't find a consistency problem; I think that some such >> things were already fixed with recent PR's, perhaps this problem >> has self-resolved. >> >> >> Also LGTM. >> >> Thanks for the thoroughness, BTW. This is also the kick in the ass I >> needed to get back to looking at this. :-) > > Thanks to you for your careful review! > > Cheers, > Michael > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps -- G. Fairhurst, School of Engineering --------------4B3C4504141AC5BE967DA6D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

See below.

On 03/04/2020 11:20, Michael Welzl wrote:
Hi,


On Apr 2, 2020, at 10:42 PM, Kyle Rose <krose@krose.org> wrote:

On Thu, Apr 2, 2020 at 10:54 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

I sifted through the review now, trying to address some easy things, removing some more things that were already addressed, creating issues for things that require some discussion… as a result, we now have new PR #515, issues #520 - #526, and here is one item thatI’d like to check with Kyle via this email:

5.2. Specifying Transport Properties

* Using the same enum (Require(d[sic])/Avoid/Ignore) for the queried output of selected properties seems like a shortcut that will lead to some confusion.

MW: I agree;  partially addressed: s/Required/Require wherever it's a Preference level.

Kyle: FWIW, my objection to the other issue (using a normative term as an indication of what was chosen) isn't that it's underspecified, only that it's confusing. I put it roughly in the same category as specifying -1 as an error indicator in an abstract API. Is the idea that the output parameters could be fed into the protocol selection logic for a subsequent connection to select the same protocol? Is that useful?

Philipp Tiesel: We had text saying that these should turn into Boolean when queried and should reflect whether the protocol stack chosen provides the feature. I will have to double-check whether this text is still in the description of the preference type.

MW: I found this text: "Querying a Selection Property after establishment yields the value Require for properties of the selected protocol and path, Avoid for properties avoided during selection, and Ignore for all other properties."   - this seems ok to me. Kyle?

I don't have a strong opinion about it. I just find it potentially confusing. Just in case, the alternative I had in mind was having an output enum something like { Selected, Avoided, Ignored } independent of the input type. As long as you understand this and are still okay with the interface you've chosen, that is fine by me.

I got it now, and I think your proposal is much better. I’ll do this in a PR.


If you go with the existing approach, I wonder if "Avoid" should be "Prohibit", analogous to "Require" for selected properties. (Similarly, maybe the opposite of "Selected" is "Prohibited" in my alternative approach.)
 
11.1.10. Capacity Profile

* Very little of this section is about capacity. Traffic Profile?

Gorry Fairhurst:
> I don't much like Traffic Profile - to a traffic profile specifies the characteristics of the traffic the sender is transmitting, not the treatment that traffic expects from the network service.

I'm trying to think of "capacity" as "path and protocol selection and network treatment", but it's just not clicking. Maybe there's a term of art definition of "capacity" I'm just not familiar with. I buy "capacity" as "network treatment", but path selection and protocol selection are both properties of the traffic as defined by the endpoints, is it not? Maybe "Capacity and Traffic Profile"? (Again, not something I feel especially strongly about.)

I also don’t have a strong opinion about this, but I’ll leave it for Gorry to answer.


To me:

Traffic profile makes me think of TSpec, MF-Classifier, etc. Something that I can define within a network device that will decide what forwarding behaviour I see, and how I may police to this. in DS, this could be defined as "A traffic profile specifies the temporal properties of a traffic stream selected by a classifier. It provides rules for determining whether a particular packet is in-profile or out-of-profile." [RFC2475]. To me this isn't that?

Capacity is about how fast a sender can currently send along a path. My expectations for accessing capacity might be related to the treatement I tell the network that I wish to receive, such as the DSCP that is set. However, this isn't a capacity specification, and a capacity profile is just about OK to me - but not perfect, because the description doesn't "profile" capacity.

I'd be OK with a range of words here - and not OK with some others.

Other possibilities could be:

"Network Service"

"Network Service Marking"

Or even more-specific:

"DS Marking"

I would be very happy to think upon others - but the keyword space is limited and we should avoid overlap with terms that mean something else :-).

Gorry


5.2.11. Provisioning Domain Instance or Type

* What about ordering of similar interfaces? I have a 2-SIM cellphone with wifi.

Philipp Tiesel:
> Each cellular provider will have a unique PVD.

SGTM.
 
8.2. Receive Events

* "A call to Receive will be paired with a single Receive Event" or possibly multiple ReceivedPartial Events?

* Also, can the draft be consistent about Receive vs. Received, et al.?

MW: I can't find a consistency problem; I think that some such things were already fixed with recent PR's, perhaps this problem has self-resolved.

Also LGTM.

Thanks for the thoroughness, BTW. This is also the kick in the ass I needed to get back to looking at this. :-)

Thanks to you for your careful review!

Cheers,
Michael


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

-- 
G. Fairhurst, School of Engineering
--------------4B3C4504141AC5BE967DA6D9-- From nobody Fri Apr 3 05:10:06 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6723A18D1; Fri, 3 Apr 2020 05:10:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Haberman via Datatracker To: Cc: last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158591580027.17912.14591985076306660054@ietfa.amsl.com> Reply-To: Brian Haberman Date: Fri, 03 Apr 2020 05:10:00 -0700 Archived-At: Subject: [Taps] Intdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 12:10:01 -0000 Reviewer: Brian Haberman Review result: Ready with Issues This document is a survey of network security protocols and their interaction with transport and application protocols. It is clearly written and easy to read. I have a minor comment on the contents of this draft. It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft. Some notable omissions include SSH, L2TP, and GRE. These seem like interesting omissions given their popularity in a number of deployment scenarios. Not a showstopper in my opinion, but interesting to note. From nobody Fri Apr 3 05:51:14 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBFC3A07AD; Fri, 3 Apr 2020 05:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 zpe5ijaG1nYy; Fri, 3 Apr 2020 05:51:04 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 817CA3A07B1; Fri, 3 Apr 2020 05:51:03 -0700 (PDT) Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E619E1B000AD; Fri, 3 Apr 2020 13:50:55 +0100 (BST) To: Brian Haberman , int-dir@ietf.org Cc: last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org References: <158591580027.17912.14591985076306660054@ietfa.amsl.com> From: Gorry Fairhurst Message-ID: <59caf50b-6602-978c-f3b4-955c42d73f79@erg.abdn.ac.uk> Date: Fri, 3 Apr 2020 13:50:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <158591580027.17912.14591985076306660054@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------246C35820444AD81993F8625" Content-Language: en-GB Archived-At: Subject: Re: [Taps] Intdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 12:51:06 -0000 This is a multi-part message in MIME format. --------------246C35820444AD81993F8625 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think GRE (the one I know more) should be mentioned as existing somehow. ... even if the WG doesn't want to add an analysis of GRE! A suggested starting text blob proposal for GRE could be: Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. GRE tunnels do not by default provide security features. [RFC2890] describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header to implement security functions. [RFC8086] specifies a method of encapsulating network protocol packets using GRE in UDP. GRE can be used in combination with IPsec (see RFC2890). Gorry On 03/04/2020 13:10, Brian Haberman via Datatracker wrote: > Reviewer: Brian Haberman > Review result: Ready with Issues > > This document is a survey of network security protocols and their interaction > with transport and application protocols. It is clearly written and easy to > read. I have a minor comment on the contents of this draft. > > It is not abundantly clear what the criteria was for selecting the subset of > security protocols included in this draft. Some notable omissions include SSH, > L2TP, and GRE. These seem like interesting omissions given their popularity in > a number of deployment scenarios. Not a showstopper in my opinion, but > interesting to note. > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------246C35820444AD81993F8625 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think GRE (the one I know more) should be mentioned as existing somehow.

... even if the WG doesn't want to add an analysis of GRE!

A suggested starting text blob proposal for GRE could be:

Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol.  GRE tunnels do not by default provide security features. [RFC2890] describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header to implement security functions. [RFC8086] specifies a method of encapsulating network protocol
packets using GRE in UDP. GRE can be used in combination with IPsec (see RFC2890). 

Gorry
On 03/04/2020 13:10, Brian Haberman via Datatracker wrote:
Reviewer: Brian Haberman
Review result: Ready with Issues

This document is a survey of network security protocols and their interaction
with transport and application protocols. It is clearly written and easy to
read. I have a minor comment on the contents of this draft.

It is not abundantly clear what the criteria was for selecting the subset of
security protocols included in this draft. Some notable omissions include SSH,
L2TP, and GRE. These seem like interesting omissions given their popularity in
a number of deployment scenarios. Not a showstopper in my opinion, but
interesting to note.


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--------------246C35820444AD81993F8625-- From nobody Mon Apr 6 10:12:32 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E41FD3A0BD7; Mon, 6 Apr 2020 10:12:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <158619313391.2395.109717988578779678@ietfa.amsl.com> Date: Mon, 06 Apr 2020 10:12:13 -0700 Archived-At: Subject: [Taps] Robert Wilton's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:12:14 -0000 Robert Wilton has entered the following ballot position for draft-ietf-taps-transport-security-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As incoming AD I found that document really useful and informative - thank you. As a minor nit, I found the English around the usage of the term "Transport Services", that I wasn't familiar with prior to reading this document, slightly tricky to parse in the introduction, particularly because the term isn't defined until the Terminology in section 3. E.g. in the second paragraph it isn't clear to me what a "Transport Services system" real means. Possibly replace "a Transport Services system may need to support" with "a Transport Service may need to support"? Similarly, perhaps change " One of the goals of Transport Services is to define a common interface for using transport protocols" to " One of the goals of Transport Service definitions is to define a common interface for using transport protocols"? From nobody Tue Apr 7 04:47:54 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5543A00D4; Tue, 7 Apr 2020 04:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158626006908.2960.9357245521194910843@ietfa.amsl.com> Date: Tue, 07 Apr 2020 04:47:49 -0700 Archived-At: Subject: [Taps] Warren Kumari's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 11:47:50 -0000 Warren Kumari has entered the following ballot position for draft-ietf-taps-transport-security-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Not much that I can add, other than that I really like these type of documents - the IETF has a huge number of documents, and it's really hard for people to know where to start, especially with this sort of topic. From nobody Tue Apr 7 22:48:48 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 777623A0DFA; Tue, 7 Apr 2020 22:48:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158632492387.9927.14911806705395970669@ietfa.amsl.com> Date: Tue, 07 Apr 2020 22:48:44 -0700 Archived-At: Subject: [Taps] Barry Leiba's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 05:48:47 -0000 Barry Leiba has entered the following ballot position for draft-ietf-taps-transport-security-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this helpful document. Just some editorial comments beyond what others have mentioned: — Section 1 — It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. It’s funny that this carefully expands every abbreviation except “SRTP”. Please do that one too. Ubiquitous IETF protocols such as (D)TLS, as well as non-standard protocols such as gQUIC, are both included The word “both” doesn’t work here. I think a reasonable fix is just to remove the single word. Maybe a better fix is to slightly reword, as, “Ubiquitous IETF protocols such as (D)TLS are included, and so are non-standard protocols such as gQUIC, despite...” — Section 1.1 — For example, a security protocol that expects to run over a reliable stream of bytes, like TLS, restrict the set of transport protocols that can be used Number agreement: make it “restricts” to match the singular subject “a security protocol”. — Section 2 — Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. 
You don’t need both “examples include” and “etc.”; I suggest eliminating the latter (and sticking in an “and”). — Section 3.1.1 — to marshal (possibly encrypted) data from one peer to the other. Possibly? I understand you’re covering the handshake there as well, but for a summary as (reasonably) brief as this I think it’s misleading to say “possibly”. — Section 3.2.1 — ZRTP [RFC6189] is an alternative key agreement and identity management protocols for SRTP. Number agreement: “protocol” — Section 3.4.3 — For key establishment, OpenVPN can use TLS as a handshake protocol or pre-shared keys. This reads oddly, as though there are two things OpenVPN can use TLS for. I would make it, “...or it can use pre-shared keys.” — Section 5.1 — * Extensions (Application-Layer Protocol Negotiation) (EXT): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN [RFC7301]. Isn’t the expansion of “ALPN” misplaced here? From nobody Wed Apr 8 05:59:35 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A643A0A29 for ; Wed, 8 Apr 2020 05:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 vrTsiUQSkX_Q for ; Wed, 8 Apr 2020 05:59:32 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on20608.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::608]) (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 75A103A0A20 for ; Wed, 8 Apr 2020 05:59:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AAqMtWauVErGeI9rgOC3zJ09GXZroUOB9O75TlM42hCAODdfqYTVyuC+gWfXXlcjF3anQTtUFIJXIPOpv275O5GdO7Etj3Vd7RomRbJjVQwubhY62JMAzyEth06/RY6MEvAEhtqj6Tfcbsv3rk4uO4uvrQY3TRwq6MderMTiBbIHS8Jc5e6AepyhnnZGdaSjyBZzQVjEjJMImq9wYNsQ2mQR5eNsHSxcVIH/nv2xPriLhGqFRzvEB7ctRT0FweNz9xgQ0tAplsY8YzI1yQ5N6QVPVybj1+A29OJMJEAkbVyTRriZtL9xRohy++sCA9iCPDH5lBvXfkl9erRmtxreVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fIltRAHD2PgLGgk/GCP+fcE15J4F3kIbzoOAL/qUPAM=; b=mNoaG3GytuQ+2LKtqapVEvICUyYil7DoOg35uEXQntVfzzJ9yj35ga7kMkNbLlgDabcwLXKiLPoOc+v4QILjs21cpCENEcbmWG7VcEfkt09fsi6f07LAW0GYQTVmSaBgldEs/ew9kajTpxlW/pxhQnsQii5vhnbTN/hFj+xugF34Tuhd5f2enFsczgNrb+BPKnL+wBI0eO3Gf2DJV8I4WYszkC+FoZb9ENjUeyjI6UEsRtysKafEiP9V9RSnskbIV04+y25MHwFbSv23+JWoXnU1+RD0tVcQuypEdDD3o7O1GmbHAIKjfLuvVpCyRnVIZ9ARLUHJkutS3nkzjFNdjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fIltRAHD2PgLGgk/GCP+fcE15J4F3kIbzoOAL/qUPAM=; b=IlGBd8pCyCSP0FIPsV96Y2cVctg7MvCpX84K6gaIKIiH2P4/DfkJ3XqdGufsiZ9XrFmpBA7UEwxgijz+6fvHH1/XtFGcqE8P4pfFjsnE80Dw2SlkYs8qv+YuTGbZK7SXip5Jzyhvg09zmqGHQwWQA6MdrfXbtDV6S4/qh/nscqs= Received: from AM0PR07MB4691.eurprd07.prod.outlook.com (52.135.149.158) by AM0PR07MB4052.eurprd07.prod.outlook.com (52.134.83.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Wed, 8 Apr 2020 12:59:29 +0000 Received: from AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::298a:36c6:fff4:f8f8]) by AM0PR07MB4691.eurprd07.prod.outlook.com ([fe80::298a:36c6:fff4:f8f8%3]) with mapi id 15.20.2900.012; Wed, 8 Apr 2020 12:59:28 +0000 From: Mirja Kuehlewind To: "taps@ietf.org" Thread-Topic: Review of draft-ietf-taps-impl Thread-Index: AQHWDaWJ9pe6D/7Pv0OTHBrysD/52g== Date: Wed, 8 Apr 2020 12:59:28 +0000 Message-ID: <91325950-E2AE-45E2-B751-833E6DE2D529@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mirja.kuehlewind@ericsson.com; x-originating-ip: [2003:de:e727:100:3800:cca8:d6ef:25f7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa2151bc-953e-4fba-d514-08d7dbbcac53 x-ms-traffictypediagnostic: AM0PR07MB4052: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4691.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(6506007)(316002)(6486002)(71200400001)(6512007)(33656002)(36756003)(86362001)(64756008)(186003)(478600001)(5660300002)(44832011)(76116006)(66946007)(91956017)(66556008)(66476007)(66446008)(8676002)(81166007)(2906002)(8936002)(2616005)(6916009)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0NF5GG1mo3fkRX4D69oSoM9QcnRfiGmOSQvp/UwvWqP62HMH2s8U4hh2LZH0PAYNWAIIwcTVRK0Fp4+WpgKnh8Zt3HcxEDKp7eVF05TcYKth6D+gIyQ5HD8eybGjC14HRIt8BEO3Nl/SgPM1o3T+00+2rahv0wG9ZkLVjXu791PiDl+WEcLhR6c9vdwDPxgVWfURzXjrfc3zMCLERS4oGt6Ua3vzXIjesqHJ7kMyQCLic1toHmFpqEupsG7icKOOEQzpyQ+pr6GHZHJ8BfyqJxZ5nsXoEXJBlH9nbMD675580l7uReZXAvhp2czeykdFaaamNtcuNag3V3xCc8Kl8HPKTSmJbuDJBBEI9ZTTSEssszQBvFRHX/CEicUPHG1ierZRv7KffbBgkhJA/H7ofjHJ+kkjrskXHHhL5YEHyEnMFDYdmidMt2T5Q5/JKH5n x-ms-exchange-antispam-messagedata: S+Oh19R3552nwdZ8CjPYfq6l8cYQ7kuKvEGV6ZEWEvj3iUHSnhapr1ftUmgEo/2RJz4KQq497v51nxwZdBKEPPxjBfWHtzuYpbg8KiabtZiNiRASoWxt+ywoalr+8d5iakpgwsJI4JaX4/QTJxK8uJn0tTFZ015pB9RtwBU8XuxvTRiJjgj5Hvkpb72oOGgkwWhlHijJLDnl/qA0pffAgw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <6946CA73F14BCB40914B15526DC6EC86@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa2151bc-953e-4fba-d514-08d7dbbcac53 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 12:59:28.7134 (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-CrossTenant-userprincipalname: +924C2OiwGfkgUNdR9jGsk24eBDAxGPlwDr7kaEIsnsIbbG23umti/KNogGc2HkZlDxdFR7oRWidUO3AsdmnkGxb5Yu1S8PdxqtScSh5rAA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4052 Archived-At: Subject: [Taps] Review of draft-ietf-taps-impl X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 12:59:34 -0000 SGkgYWxsLA0KDQpmb3IgdGhvc2Ugd2hvIGRvbid0IGZvbGxvdyBjbG9zZWx5IHRoZSBhY3Rpdml0 aWVzIG9uIGdpdGh1YiBhbmQgZGlkbid0IHNlZSBteSBzcGFtLCBJIGhhdmUgcmV2aWV3ZWQgZHJh ZnQtaWV0Zi10YXBzLWltcGwgYW5kIG9wZW4gYSBjb3VwbGUgb2YgaXNzdWVzIChhbmQgc29tZSBt aW5vciBQUnMgdGhhdCBldmVuIG1vc3RseSBnb3QgbWVyZ2VkIGFscmVhZHkuIFRoYW5rcyEpLiBJ IHRoaW5rIHRoaXMgZG9jdW1lbnQgaXMgaW4gcmVhbGx5IGdvb2Qgc2hhcGUgKFRoYW5rcyBmb3Ig dGhlIGdvb2Qgd29yayB0byB0aGUgYXV0aG9ycykgYW5kIG1vc3QgKGJpZ2dlcikgaXNzdWVzIGFy ZSBwcm9iYWJseSBzb21laG93IHJlbGF0ZWQgdG8gdGhlIEFQSSB3b3JrLiANCg0KSSB0aGluayB0 aGUgdHdvIG1haW4gdG91Y2ggcG9pbnRzIGFyZSBzdGlsbCB0aGUgZnJhbWVycyAoaXNzdWUgIzQ1 NyksIGFuZCB0aGUgTVAgaW50ZXJmYWNlIChpc3N1ZXMgIzQzNyBhbmQgIzU0NSwgUFIgIzUxMiku IEkgZ3Vlc3MgYm90aCB0b3BpY3Mgd291bGQgYmVuZWZpdCBmcm9tIG1vcmUgaW50ZXJhY3RpdmUg ZGlzY3Vzc2lvbiBkdXJpbmcgdGhlIGludGVyaW0uIA0KDQpUaGUgb3RoZXIgc2xpZ2h0bHkgYmln Z2VyIHRvcGljIG1pZ2h0IGJlIG9uIHRoZSB1c2Ugb2YgdGhlIHRlcm0gInBhdGgiIChpc3N1ZSAj NTMzKS4NCg0KSSBhbHNvIHRyaWVkIHRvIHRoaW5rIGFib3V0IHRoZSBxdWVzdGlvbiBpZiB0aGUg aW1wbGVtZW50YXRpb24gZ3VpZGFuY2UgaXMgImNvbXBsZXRlIiBvciBpZiB0aGVyZSBpcyBhbnl0 aGluZyB3ZSBhcmUgY3VycmVudGx5IG1pc3NpbmcgZW50aXJlbHkuIEkgdGhpbmsgdGhlIGNvdmVy YWdlIGlzIHJlYWxseSBnb29kIGFuZCBhbGwgSW1wb3J0YW50IHBvaW50cyBhcmUgd2VsbCBjb3Zl cmVkLCBob3dldmVyLCBhbSB3b25kZXJpbmcgaWYgd2UgbmVlZCB0by9jYW4gc2F5IG1vcmUgYWJv dXQgc2VjdXJpdHksIGUuZy4gY2VydGlmaWNhdGUgaGFuZGxpbmcgKGlzc3VlICM1NDgpPw0KDQpR dWVzdGlvbiB0byBhbGw6IGFyZSB0aGVyZSBvdGhlciB0aGluZ3MgdGhhdCBhcmUgbm90IGNvdmVy ZWQgeWV0IChlLmcuIG1vcmUgb24gbXVsdGljYXN0IF9fICk/DQoNCk1pcmphDQoNCg0KDQo= From nobody Wed Apr 8 15:35:38 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E09023A18E9; Wed, 8 Apr 2020 15:35:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158638531056.18357.11401006659618104728@ietfa.amsl.com> Date: Wed, 08 Apr 2020 15:35:10 -0700 Archived-At: Subject: [Taps] Benjamin Kaduk's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2020 22:35:11 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-taps-transport-security-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do wonder whether the Generic Security Service API (RFC 2743) was considered by the WG in the production of this document. It reflects a somewhat dated snapshot of what was believed to be necessary security APIs, but may not be entirely without value for this type of survey. It's a little surprising to not list a reference for QUIC in its mentions in Sections 1 and 3, with the first reference occuring in Section 3.3.1. Section 1 set, protocols that do not offer new features are omitted. For example, newer protocols such as WireGuard make unique design choices that have implications and limitations on application usage. In nit: "implications for" and "limitations on". protection. Despite these improvements, neither protocol sees general use and both lack critical properties important for emergent transport security protocols: confidentiality, privacy protections, and agility. Such protocols are thus omitted from this survey. I don't think I see how TCP-AO and IPsec AH lack "agility". Could you clarify what was intended? Section 1.2 It is not a goal to allow software implementations to automatically switch between different security protocols, even where their interfaces to transport and applications are equivalent. Even between versions, security protocols have subtly different guarantees and vulnerabilities. [...] Another impactful distinction between security protocols is in how they name and authenticate the communications peer -- I can't imagine writing a useful API that tries to abstract out the X.509 DNS-ID naming for TLS, SSH host key fingerprints, etc. Section 2 Should we reference RFC 8095 at the appropriate definitions [that we duplicate from it]? * Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. A Transport Protocol services an application. (whether directly or with an intermediating security protocol?) Section 3.1.1 protocol. The handshake protocol is used to authenticate peers, negotiate protocol options, such as cryptographic algorithms, and derive session-specific keying material. The record protocol is used to marshal (possibly encrypted) data from one peer to the other. My inference is that the "possibly encrypted" is supposed to refer to the encryption performed by the TLS record layer itself, as opposed to having already-encrypted data supplied to TLS as "Application Data". If correct, I'd suggest rewording to "is used to marshal and, once the handshake has sufficiently progressed, encrypt, data from one peer to the other". Section 3.1.2 DTLS doesn't provide "the same security guarantees as TLS" in the general case. Specifically, redord replay detection is only optional in DTLS whereas it is inherently provided in TLS. Section 3.4.2 WireGuard is an IP-layer protocol designed as an alternative to IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate IP Please move the location of the reference; it currently scans like it's a reference for IPsec(!). Section 5.1 * Identities and Private Keys (IPK): The application can provide its identities (certificates) and private keys, or mechanisms to access these, to the security protocol to use during handshakes. I think it would be more accurate to say "provide its identity, credentials (e.g., certificates), and private keys" -- a certificate is not exactly an identity, but rather an attestation thereof provided by a (nominally) trusted authority. Not all security protocols use certificates in all cases, so I also think the "e.g." is appropriate. Section 5.2 * Source Address Validation (SAV): The handshake protocol may delegate validation of the remote peer that has sent data to the transport protocol or application. This involves sending a cookie exchange to avoid DoS attacks. I'm not sure I understand the intent of using the word "delegate" here. * Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to connection mobility, which may reset address and state validation and induce state changes such as use of a new Connection Identifier (CID). I think it's expected that DTLS 1.3 will do this (though I note that you aren't currently referencing DTLS 1.3). Section 8 omitted from this survey. All security protocols surveyed generally improve privacy by reducing information leakage via encryption. nit: I suggest "improve privacy by using encryption to reduce information leakage" (to avoid the misparse of "reducing (information (leakage via encryption))"). From nobody Wed Apr 8 18:17:29 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B624C3A1CA5; Wed, 8 Apr 2020 18:17:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158639504371.21661.11551525700396114665@ietfa.amsl.com> Date: Wed, 08 Apr 2020 18:17:23 -0700 Archived-At: Subject: [Taps] Alissa Cooper's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 01:17:24 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-taps-transport-security-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- To a non-expert it struck me as a bit odd that Dan Bernstein is mentioned as the designer of CurveCP but no one is mentioned as the designer of MinimalT. From nobody Thu Apr 9 05:28:58 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC843A1077; Thu, 9 Apr 2020 03:01:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net, mohit.m.sethi@ericsson.com, brian@innovationslab.net, int-dir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158642650492.8627.16111048765603393250@ietfa.amsl.com> Date: Thu, 09 Apr 2020 03:01:44 -0700 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2020 05:28:57 -0700 Subject: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 10:01:45 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-taps-transport-security-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. It is really easy to read. Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that I am wrongly asserting the lack of IPv6 support for CurveCP else the easy way to clear my DISCUSS would be to mention this limitation in section 3 even if the focus of this I-D is on the API. Please find below some non-blocking COMMENTs. An answer will be appreciated. I hope that this helps to improve the document, Regards, -éric == DISCUSS == I question the inclusion of CurveCP in the mix as per https://curvecp.org/addressing.html it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3. (and I hope to be corrected about CurveCP IPv6 support). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + Gorry Fairhurst's about GRE Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction. -- Section 1 -- Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined. -- Section 3 -- Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ? An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API). From nobody Thu Apr 9 05:29:01 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5F3A097A; Thu, 9 Apr 2020 05:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 BueXx_1aymMj; Thu, 9 Apr 2020 05:15:51 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0625.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::625]) (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 2C8E93A00D3; Thu, 9 Apr 2020 05:15:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Of5x4I/+ZmA8SxmA5hgkt6GYK+yO+6pAcP9vkQ1+VHWjslpxlFeRrRwJrx+2kk9zodVsf1xBjO1Dk/4TRc4JWIA8CRzNI8ZbofPgtWI06lWLmN5pP7+jHdLmvHslY55R0vO5eTFNSCX/iYO8OOLVsQ/invLUNPcmT9hlaA6lujv/DAWuXZTRCWMSGoP10Dwm+6ENitEFTrlhW06G3OAJBLz3RmGjkewRKojaRSFth2fMCeHNdDRdR6ABGuEaBW1no5VnhcAL9FXsp9pMV9Vf+431Q+ojxRUOLF4ZKzq3i2ZnMYvcnzMEov+Su45bAhKOOIP8+pTEGCeeRVOgfz0PGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5p/CX1hCJOXGyLryLK++eFfTkNIe7uk5a32vyowQf4=; b=HUGndvO5EDnw5mzc0JAz0L6l/w1d5OIW3BjHvekye2TcbOOCGrJxZP0kJCREhrLKMf23hsjZOczokJHVAZeRQM6Ey3sGzeMfqbrbyWWHFvbFPkvrGjVLCxlt28cymzsPNgBMF4RYSBjy7Xd/JG7tQVg4P72ZHRr0PcI4AsqBS9ANPP+cDXV5/MCN3FT8CBUyh8oFjTnaP//bF8fOdKPl7coHka2OTDJoUCb1bqLGeWJ6lu+E4JgIZW6ZJkCzJUUoo7F2yfgmLzelwiHUY93BXXR/sUUv0be8wEIn3VT2Re7c/Kol4RANN6+hzdhkFoirjIXEtx8WysxAqsjBrpV1YQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5p/CX1hCJOXGyLryLK++eFfTkNIe7uk5a32vyowQf4=; b=qB6yiZH+pHq9z4azbEIl5FV0f8zsDgmtmNY/MbIPqlYHjzMSRxP8FLWLtbUNOFKbppBy3YQLbKOO/HFNFJ8GBkhP/0Jt+wrlVRiUJTMv/0wSz7r3wanriTzxXXeEBOEqc0qFkFu/cGBanU+rcS9cUCnk4+qopCOfqRZ5QXAlzZc= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3802.eurprd07.prod.outlook.com (2603:10a6:7:89::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Thu, 9 Apr 2020 12:15:47 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2900.012; Thu, 9 Apr 2020 12:15:47 +0000 From: Magnus Westerlund To: "iesg@ietf.org" , "evyncke@cisco.com" CC: "brian@innovationslab.net" , Mohit Sethi M , "draft-ietf-taps-transport-security@ietf.org" , "philipp@tiesel.net" , "int-dir@ietf.org" , "taps-chairs@ietf.org" , "taps@ietf.org" , "caw@heapingbits.net" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRhcHMtdHJh?= =?utf-8?Q?nsport-security-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWDlXqWLSSULahQE2VBetBTFRtmahwtISA Date: Thu, 9 Apr 2020 12:15:47 +0000 Message-ID: <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> In-Reply-To: <158642650492.8627.16111048765603393250@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f94628a3-cb23-44f3-e4aa-08d7dc7fbc4a x-ms-traffictypediagnostic: HE1PR0702MB3802:|HE1PR0702MB3802: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(396003)(366004)(346002)(316002)(66446008)(81156014)(66556008)(2616005)(54906003)(66616009)(186003)(110136005)(64756008)(15650500001)(66946007)(26005)(81166007)(4326008)(44832011)(6506007)(76116006)(224303003)(2906002)(966005)(99936003)(86362001)(5660300002)(36756003)(6512007)(8936002)(478600001)(71200400001)(66476007)(6486002)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zFIgx4HV3nUlizB9ML4VWbkvWG6/B/lA2Mvht6PAU+A++R0zHJaZu14ClvaDbdGag+lbsRXJNXo+tE9ojPizdrj1iecVORhirQu9emjKnxv5/QGydd2bAfYlZnUlLoY0FVqiqdoREoBcJQ4BnVInGqbhInyh35/WHvUm/9DEhQNHaE2+h2FhR7V4hBK0RWnInUG9rLsTGlsR+XtmVXruyJlgBsA2eqLnFfoG0Yda/TTfk7fYn9X+zgYPMc2qyCJNDL7/4OM9tPdoF4ZogB+r77GstT79Vqdw8AA1jvPnMwpp8kEYfNUeABdomeHlYR+9/g9LhL/MftsZUALyrgo/8rFJ69pr3raiWoSCVnNA2q5IWVaGWO7PLeBlt4sgr+PiCIuzWdlKJhKzk/3GkazHjLNLGTWqKEPSelBPrSor7L1U9gFJA3RGNyzDT4EeW/zIBMb4+oBGHV0v3DprR9DvjPB1v3ZTmMHmJL1/w4sSBWTrPcdDFlrKja4YPIbn7lL2NRENkVW0blwhmlpqaY/aA7ndfVPc0uCiLauu0PzAnY/TnBUBAP5nDZvStThVk9Xy x-ms-exchange-antispam-messagedata: MbmNC3b0HEd5j1a4mhYvrYA1CMo0MjFWYmkKwK9AG2OZ3eY3WIRMhdUtVM+t6+p9JkLedtaSMlm7loo5HTRhTaMbynQnjfmDtyl6lBErgnivPAxAoyiMoOBpgKnBbFk9q/Ow7H2uBWNrjCDepkRLIA== Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-YccPNQcHpprPGiDIQr5Z" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f94628a3-cb23-44f3-e4aa-08d7dc7fbc4a X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 12:15:47.2637 (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-CrossTenant-userprincipalname: ScUdtiPf96qYI3bqvbovucm+NtwZP0YREMQptjq8DU57hIOrvC5tHLNJVx6a99ZduzSrSbyFMsKigiUgbh1CpRzPHXu/kYitWUq5bS1jEr4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3802 Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2020 05:28:57 -0700 Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 12:15:57 -0000 --=-YccPNQcHpprPGiDIQr5Z Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Aren't you going a bit to far now with this discuss? Yes, IETF stream procotocols are expected to support IPv6. This is a non-IETF devleoped secu= rity protocol which is investigated from the perspective of its features to infl= uence considerations of required API surface for security features. All discussed= in relation to a set of aspects where the only one having to do with addressin= g is source-address valdiation and which CurveCP do not support as particular relevant.=20 I don't see how it is going to affect or impact that future work in TAPS WG= . Why do you think an aspect of a protocol that isn't discussed being relevan= t to mention?=20 If you have a good reason fine then a disclaimer could be added. But I don'= t see how it would not result in a unconnected comment on a specific protocol whi= ch has no connection to the purpose of the document. Cheers Magnus On Thu, 2020-04-09 at 03:01 -0700, =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-taps-transport-security-11: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. It is really easy to read. >=20 > Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that= I am > wrongly asserting the lack of IPv6 support for CurveCP else the easy way = to > clear my DISCUSS would be to mention this limitation in section 3 even if= the > focus of this I-D is on the API. >=20 > Please find below some non-blocking COMMENTs. An answer will be appreciat= ed. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D DISCUSS =3D=3D >=20 > I question the inclusion of CurveCP in the mix as per >=20 https://protect2.fireeye.com/v1/url?k=3Dc6d9b121-9a0dbd7f-c6d9f1ba-8691959e= d9b7-6efcfea6e017deb9&q=3D1&e=3Dd62bfe3e-4eac-4ef1-877e-ac1f40b4418d&u=3Dht= tps%3A%2F%2Fcurvecp.org%2Faddressing.html > it does not seem to support IPv6. At the > bare minimum, the I-D should mention this restriction in section 3. (and = I > hope > to be corrected about CurveCP IPv6 support). >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Please respond to the IoT-directorate review by Mohit: >=20 https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTv= GB2x0s > Please respond to the INT-DIR review by Brian: > https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I= + > Gorry Fairhurst's about GRE >=20 > Generic comment about the intended transport: all protocols analyzed in t= his > document are point to point (no multicast), this should probably be menti= oned > in the introduction. >=20 > -- Section 1 -- > Is there any reason why the integrity property of IPsec AH is not mention= ed ? > Same also applies in section 2 when "security protocol" is defined. >=20 > -- Section 3 -- > Use the wording of "record protocol" generically while the term "record > protocol" is defined in section 2 as a blocked data transport (like in TL= S). > Suggest the use of "data transfer protocol" ? >=20 > An important property of such protocols is to be able to traverse a NAPT = box > (that I hate)... I suggest to mention whether the analyzed protocols supp= ort > NAT-traversal in this description section or even in the analysis parts a= s > having a different view (application and network layers seeing possibly > different IP addresses so a potential impact on the API). >=20 >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-YccPNQcHpprPGiDIQr5Z Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQwOTEyMTU0NVowLwYJKoZIhvcN AQkEMSIEIOwe2WrA5FvLwy48VUO1BXTKTBXk3oQgq9AVgC9yI0n1MGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAAg3Tm2xgGaTE 48vrUkPE1YZoQBlHX1HDrgKKmD0bM7ifH0oBBtKmDUurnYF3y78jCwxv9qShenlqKdPUnMC9FVSY jBMuAJTnyuKU3QM2lSWD8y/2SjRYybr5Fy7BPG6Jttu/nW1YGOpfzme0nFZtuPHyCBmSMkK0fZ99 Lh5ciW8zruK3JgMW07kOiHfdmKFKlDx0JSR3OXN9WUGHJ3HvIxv10V0tEXMdjAt1gCcknqm2jCoW 2wzf34+WASEEbSZwOIGaUXywLRDgAUPCNAesla6Fg4Z3OzvKuUZHXnkIJZChjKgitzQN86cUyJvf XFwmIxeTtRlGQmPOCYRC5CsgaQAAAAAAAA== --=-YccPNQcHpprPGiDIQr5Z-- From nobody Thu Apr 9 05:33:35 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BDC3A0776; Thu, 9 Apr 2020 05:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cQtyeCQx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UERbGku6 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 fa4kw6qKdT54; Thu, 9 Apr 2020 05:32:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DBB3A0A1D; Thu, 9 Apr 2020 05:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8260; q=dns/txt; s=iport; t=1586435555; x=1587645155; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m3rgNWPWZ5OuYess/EZ6NqxKdNpVgnghWz4sxskOeGY=; b=cQtyeCQx7wrbbqKV2/m17GpMkZX2Keutgox2+wdXqD+nwZIJSeI14luB 5v0gum2hAJpYaKjhprMqEv+0iT5SoarxIDnziehg8ZrXgv3E6kuWRjeUV ihbR08eSXSjieWOZPhhS9y/FhvdOYsgqsd6/7erLuNs+sA2WenvHiEe8+ c=; X-IPAS-Result: =?us-ascii?q?A0C/AgCMFI9e/40NJK1mGwEBAQEBAQEFAQEBEQEBAwMBA?= =?us-ascii?q?QGBe4FUJCwFbFggBAsqhByDRgOKa06BbCWBAZcfgUKBEANUCgEBAQwBAR4PA?= =?us-ascii?q?gQBAYREAheBdyQ4EwIDAQEBAwIDAQEBAQUBAQECAQUEbYVWDIVwAQEBAQMSE?= =?us-ascii?q?REMAQEwAQYBCwICAgEIEQMBAgECAiMDAgICGRcUAQUDCAIEAQkEBSKDBAGCS?= =?us-ascii?q?wMuAQ4DpRACgTmIYnWBMoJ/AQEFgTIBE0GDSRiCDgMGBYEJKosUgR8agUE/g?= =?us-ascii?q?REnDBCCGDU+gmcCAQEBARiBFAESASEXgnsygiyOEoJCO6AzCoI/h3iPRB2CU?= =?us-ascii?q?IhBhGGHSoRag2GKcAxpiSuPIINsAgQCBAUCDgEBBYFpImdYEQdwFWUBgj5QG?= =?us-ascii?q?A2RIjiDO4UUhUF0AgEKgRyOHwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AUNSsxRCMbeG6Soayray+UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuIeD7aSc5EexJVURu+DewNk0GUJ+kNUffqXCz8zMeXw?= =?us-ascii?q?7nO1opdMLyHIOaz9yt0Py/8IHSZAMOgyehZbR1L1O9qgCD/sIXmoBlbK02z1?= =?us-ascii?q?PFpXZTM+JR2StkKEmSkBD1+srVntZ7/j5Vuu49+sIISqj8c6kiBbxfFyg9cm?= =?us-ascii?q?0=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.72,362,1580774400"; d="scan'208";a="449470659" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 12:32:33 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 039CWX1K028838 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2020 12:32:33 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 07:32:33 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 08:32:32 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 9 Apr 2020 07:32:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEe20GenDG4p7keWo2VKcsg/97DIALN1Gs4UqDvi/K4UGupdD5QJz0Gv5RNTZCdvcrVhn7DyClincdUrLVyA8tl5eMeuCdiS6w6RXT1XmW/yq8zlgfSLMdUGS/4IrTipht1BuxE4z18nRIvv1Kqd79mjKvZTcXN2v4NpaWHRUInwRWL/83+rS/V1Xbr0lVP1IkGrIZEDlTIj4/jI4rsVOGNrTvha65vrcW7TVYjiztRFFwjwLZ+EVBrlKJRRO4Onz1kudkgEBHqekdNYP5hOzMNv20aPxmwFKFgC6HBtODWrr8MyijRZs+TTGyz3q3s4fkVTL33GfLUxcNDjU/SqMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3rgNWPWZ5OuYess/EZ6NqxKdNpVgnghWz4sxskOeGY=; b=MgGFNTTjBP8shai+ecZ567aiHGir0NJJpXXempzI3MF2m5OWDOoq4P9MUQp9kdRRbKkFFl5fkLMkDXYjTLTTtQBSXu5HaZV7eTN/Lfu4zj6DoxdurGM7ZaRqH+rNNQBaGuN2YSsCpXnmOQZ2ptDfFhjaftFgQBG4fwi5ztrSNsYB8SXhlmtCEmmfFB31qVNxFAP4XQb2AY8eSmZVIid1FN50Jqhktdsh3Vz+TcgA4eV+RjiCIUwg7p9DEIBCb54xl9ba6/pelaiCPGnYe4/0uimfpBVJE036eSvN/50BzYXSS0QvmTDNZ/ZRns+/ZlnpI540N/vW32xkWoO/B3ujkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m3rgNWPWZ5OuYess/EZ6NqxKdNpVgnghWz4sxskOeGY=; b=UERbGku6TpN4tQw7hMEQUMzZo3sclyajKLf8s1XPhLvg4C/cOGmNQ+C9OH6mt0Zi14a2Y9LlFyH7u6jaxxGennw4sl7PdFrjbm+tQ3XGK/y0LR9C/fjO/tEMCeKqdk0uAcGd/EZde5b+5ELjZbtpuB08zPMW5VkcNRzWR8fMf4Y= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1628.namprd11.prod.outlook.com (2603:10b6:4:c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Thu, 9 Apr 2020 12:32:30 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2878.018; Thu, 9 Apr 2020 12:32:30 +0000 From: "Eric Vyncke (evyncke)" To: Magnus Westerlund , "iesg@ietf.org" CC: "brian@innovationslab.net" , "taps-chairs@ietf.org" , "philipp@tiesel.net" , Mohit Sethi M , "int-dir@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "caw@heapingbits.net" , "taps@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRhcHMtdHJh?= =?utf-8?Q?nsport-security-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWDlXlmLl+pE4XrEKlI+/geqSkX6hwtIeAgAAmMwA= Date: Thu, 9 Apr 2020 12:32:30 +0000 Message-ID: <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> In-Reply-To: <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:4c24:3036:65e7:5e26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 292ddfa4-e18d-4e76-042d-08d7dc821266 x-ms-traffictypediagnostic: DM5PR11MB1628: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(346002)(136003)(366004)(966005)(316002)(2616005)(54906003)(6486002)(6512007)(186003)(110136005)(53546011)(6506007)(224303003)(15650500001)(33656002)(478600001)(8936002)(36756003)(76116006)(64756008)(66556008)(66476007)(66946007)(91956017)(2906002)(81156014)(66446008)(71200400001)(81166007)(86362001)(4326008)(5660300002)(7416002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pcpTQyG0J9rHaDjgKdmhz6T2nsZAxJiSIbCzBhGhPqU8YTtiSmfP3wtx6CMyjc9PIZscnpj5DHQUvMWbACOheOTxZMuUlcsmDapgcqULWRERqIM3CK6py9QarhMewCOE8n9xXoYGuAOU076C9Cxo7U2oZsrGql/f6D+TneU4bIdTaXR00OkbzjEPIICNamRbyH6PtFTH6euibryB5r48GUk87n5+JhgbXCLbakO/IyC2b80cs6p+ibFWEQtQnTPhmr3a5N7Ja2ZM1ylBU85R3UjsLzA1HEtBLI6FfsfFShkgwLR8Kd7d+/k6qFOJnlB1F3xnKb7rkIlMQ4LpB68+J5usz3I0m3Rrt73em2O+AEc9htXkslyXQwl6Qi66Hgb/4O/9ZD9MVjWl8D9QHB9nvzZYrOSTX8oeuceBrMgl807VwRz7zsID4rVcrGFOfw2lqmcMPnjCBwPiD0HB6qeXNNzu7+/jQy9hmiYBXAIPhpQyN5uUlkxVM5D3bcS7Qza3IT+oeePDXJXnbZFZ72Cm/w== x-ms-exchange-antispam-messagedata: KGFa9vFhLy/ywrJiOji7Oe+HNeyR46D2UaF4Kx1V9keqoNA2tcho96nxHI867Cskniw+9nHIvs3AsE4luiJRX4kwQnLuw+4PaH5za1eRSbaOeR7F+NwboxKJKQ6ag20162CP8/apZ06U/U9jg1F4i6gmEUFBUOcIYJDNPSiRLTnxmCVL0KEkKgltuSNrRp/ccLH89v0niG5JucU9Y7sWBw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <80258F953CE1F64BB6E191DA24CFDD03@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 292ddfa4-e18d-4e76-042d-08d7dc821266 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 12:32:30.7659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vKLW05OgQFJPuVOi5itj5Yq8gqynRC6IDvLcN9EeCIuApYmiP97KTbbNHiZEEx3UqAsCsbDM7KQAOK2CcBg4Kg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1628 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 09 Apr 2020 05:33:34 -0700 Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 12:32:42 -0000 TWFnbnVzDQoNCkEgc2ltcGxlIG1lbnRpb24gb2YgdGhlIGxhY2sgb2YgSVB2NiBpbiBzZWN0aW9u IDMgb2YgdGhlIGRlc2NyaXB0aW9uIHdvdWxkIGJlIG1vcmUgdGhhbiBlbm91Z2ggZm9yIG1lLg0K DQotw6lyaWMNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGllc2cgPGll c2ctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJz ZGF5LCA5IEFwcmlsIDIwMjAgYXQgMTQ6MTYNClRvOiAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0 Zi5vcmc+LCBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+DQpDYzogImJyaWFuQGlubm92 YXRpb25zbGFiLm5ldCIgPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD4sICJ0YXBzLWNoYWlyc0Bp ZXRmLm9yZyIgPHRhcHMtY2hhaXJzQGlldGYub3JnPiwgInBoaWxpcHBAdGllc2VsLm5ldCIgPHBo aWxpcHBAdGllc2VsLm5ldD4sIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24u Y29tPiwgImludC1kaXJAaWV0Zi5vcmciIDxpbnQtZGlyQGlldGYub3JnPiwgImRyYWZ0LWlldGYt dGFwcy10cmFuc3BvcnQtc2VjdXJpdHlAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXRhcHMtdHJhbnNw b3J0LXNlY3VyaXR5QGlldGYub3JnPiwgImNhd0BoZWFwaW5nYml0cy5uZXQiIDxjYXdAaGVhcGlu Z2JpdHMubmV0PiwgInRhcHNAaWV0Zi5vcmciIDx0YXBzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IMOJcmljIFZ5bmNrZSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydC1zZWN1 cml0eS0xMTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KICAgIEhpIEVyaWMsDQogICAg DQogICAgQXJlbid0IHlvdSBnb2luZyBhIGJpdCB0byBmYXIgbm93IHdpdGggdGhpcyBkaXNjdXNz PyBZZXMsIElFVEYgc3RyZWFtDQogICAgcHJvY290b2NvbHMgYXJlIGV4cGVjdGVkIHRvIHN1cHBv cnQgSVB2Ni4gVGhpcyBpcyBhIG5vbi1JRVRGIGRldmxlb3BlZCBzZWN1cml0eQ0KICAgIHByb3Rv Y29sIHdoaWNoIGlzIGludmVzdGlnYXRlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBpdHMgZmVh dHVyZXMgdG8gaW5mbHVlbmNlDQogICAgY29uc2lkZXJhdGlvbnMgb2YgcmVxdWlyZWQgQVBJIHN1 cmZhY2UgZm9yIHNlY3VyaXR5IGZlYXR1cmVzLiBBbGwgZGlzY3Vzc2VkIGluDQogICAgcmVsYXRp b24gdG8gYSBzZXQgb2YgYXNwZWN0cyB3aGVyZSB0aGUgb25seSBvbmUgaGF2aW5nIHRvIGRvIHdp dGggYWRkcmVzc2luZyBpcw0KICAgIHNvdXJjZS1hZGRyZXNzIHZhbGRpYXRpb24gYW5kIHdoaWNo IEN1cnZlQ1AgZG8gbm90IHN1cHBvcnQgYXMgcGFydGljdWxhcg0KICAgIHJlbGV2YW50LiANCiAg ICANCiAgICBJIGRvbid0IHNlZSBob3cgaXQgaXMgZ29pbmcgdG8gYWZmZWN0IG9yIGltcGFjdCB0 aGF0IGZ1dHVyZSB3b3JrIGluIFRBUFMgV0cuLg0KICAgIA0KICAgIFdoeSBkbyB5b3UgdGhpbmsg YW4gYXNwZWN0IG9mIGEgcHJvdG9jb2wgdGhhdCBpc24ndCBkaXNjdXNzZWQgYmVpbmcgcmVsZXZh bnQgdG8NCiAgICBtZW50aW9uPyANCiAgICANCiAgICBJZiB5b3UgaGF2ZSBhIGdvb2QgcmVhc29u IGZpbmUgdGhlbiBhIGRpc2NsYWltZXIgY291bGQgYmUgYWRkZWQuIEJ1dCBJIGRvbid0IHNlZQ0K ICAgIGhvdyBpdCB3b3VsZCBub3QgcmVzdWx0IGluIGEgdW5jb25uZWN0ZWQgY29tbWVudCBvbiBh IHNwZWNpZmljIHByb3RvY29sIHdoaWNoDQogICAgaGFzIG5vIGNvbm5lY3Rpb24gdG8gdGhlIHB1 cnBvc2Ugb2YgdGhlIGRvY3VtZW50Lg0KICAgIA0KICAgIENoZWVycw0KICAgIA0KICAgIE1hZ251 cw0KICAgIA0KICAgIA0KICAgIA0KICAgIE9uIFRodSwgMjAyMC0wNC0wOSBhdCAwMzowMSAtMDcw MCwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCiAgICA+IMOJcmljIFZ5bmNr ZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICA+IGRy YWZ0LWlldGYtdGFwcy10cmFuc3BvcnQtc2VjdXJpdHktMTE6IERpc2N1c3MNCiAgICA+IA0KICAg ID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsDQogICAgPiBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KICAgID4gaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIHJlZmVy IHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEu aHRtbA0KICAgID4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy4NCiAgICA+IA0KICAgID4gDQogICAgPiBUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQogICAg PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRhcHMtdHJhbnNw b3J0LXNlY3VyaXR5Lw0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KICAgID4gRElTQ1VTUzoNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IA0KICAgID4gVGhh bmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50LiBJdCBpcyByZWFsbHkg ZWFzeSB0byByZWFkLg0KICAgID4gDQogICAgPiBOZXZlcnRoZWxlc3MsIEkgYW0gYmFsbG90aW5n IGEgRElTQ1VTUyAoc2VlIGJlbG93KSwgSSBzaW5jZXJlbHkgaG9wZSB0aGF0IEkgYW0NCiAgICA+ IHdyb25nbHkgYXNzZXJ0aW5nIHRoZSBsYWNrIG9mIElQdjYgc3VwcG9ydCBmb3IgQ3VydmVDUCBl bHNlIHRoZSBlYXN5IHdheSB0bw0KICAgID4gY2xlYXIgbXkgRElTQ1VTUyB3b3VsZCBiZSB0byBt ZW50aW9uIHRoaXMgbGltaXRhdGlvbiBpbiBzZWN0aW9uIDMgZXZlbiBpZiB0aGUNCiAgICA+IGZv Y3VzIG9mIHRoaXMgSS1EIGlzIG9uIHRoZSBBUEkuDQogICAgPiANCiAgICA+IFBsZWFzZSBmaW5k IGJlbG93IHNvbWUgbm9uLWJsb2NraW5nIENPTU1FTlRzLiBBbiBhbnN3ZXIgd2lsbCBiZSBhcHBy ZWNpYXRlZC4NCiAgICA+IA0KICAgID4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3Zl IHRoZSBkb2N1bWVudCwNCiAgICA+IA0KICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gLcOp cmljDQogICAgPiANCiAgICA+ID09IERJU0NVU1MgPT0NCiAgICA+IA0KICAgID4gSSBxdWVzdGlv biB0aGUgaW5jbHVzaW9uIG9mIEN1cnZlQ1AgaW4gdGhlIG1peCBhcyBwZXINCiAgICA+IA0KICAg IGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9YzZkOWIxMjEtOWEwZGJkN2Yt YzZkOWYxYmEtODY5MTk1OWVkOWI3LTZlZmNmZWE2ZTAxN2RlYjkmcT0xJmU9ZDYyYmZlM2UtNGVh Yy00ZWYxLTg3N2UtYWMxZjQwYjQ0MThkJnU9aHR0cHMlM0ElMkYlMkZjdXJ2ZWNwLm9yZyUyRmFk ZHJlc3NpbmcuaHRtbA0KICAgID4gIGl0IGRvZXMgbm90IHNlZW0gdG8gc3VwcG9ydCBJUHY2LiBB dCB0aGUNCiAgICA+IGJhcmUgbWluaW11bSwgdGhlIEktRCBzaG91bGQgbWVudGlvbiB0aGlzIHJl c3RyaWN0aW9uIGluIHNlY3Rpb24gMy4gKGFuZCBJDQogICAgPiBob3BlDQogICAgPiB0byBiZSBj b3JyZWN0ZWQgYWJvdXQgQ3VydmVDUCBJUHY2IHN1cHBvcnQpLg0KICAgID4gDQogICAgPiANCiAg ICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+IENPTU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQog ICAgPiANCiAgICA+IFBsZWFzZSByZXNwb25kIHRvIHRoZSBJb1QtZGlyZWN0b3JhdGUgcmV2aWV3 IGJ5IE1vaGl0Og0KICAgID4gDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNo L21zZy9pb3QtZGlyZWN0b3JhdGUveFRWT3ZRN2tJNzhzRFBaUXVWc1R2R0IyeDBzDQogICAgPiBQ bGVhc2UgcmVzcG9uZCB0byB0aGUgSU5ULURJUiByZXZpZXcgYnkgQnJpYW46DQogICAgPiBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2ludC1kaXIvMklIUGd1a2FBQU12TWpP N1RYdm9fdWpjSV9JICsNCiAgICA+IEdvcnJ5IEZhaXJodXJzdCdzIGFib3V0IEdSRQ0KICAgID4g DQogICAgPiBHZW5lcmljIGNvbW1lbnQgYWJvdXQgdGhlIGludGVuZGVkIHRyYW5zcG9ydDogYWxs IHByb3RvY29scyBhbmFseXplZCBpbiB0aGlzDQogICAgPiBkb2N1bWVudCBhcmUgcG9pbnQgdG8g cG9pbnQgKG5vIG11bHRpY2FzdCksIHRoaXMgc2hvdWxkIHByb2JhYmx5IGJlIG1lbnRpb25lZA0K ICAgID4gaW4gdGhlIGludHJvZHVjdGlvbi4NCiAgICA+IA0KICAgID4gLS0gU2VjdGlvbiAxIC0t DQogICAgPiBJcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGUgaW50ZWdyaXR5IHByb3BlcnR5IG9m IElQc2VjIEFIIGlzIG5vdCBtZW50aW9uZWQgPw0KICAgID4gU2FtZSBhbHNvIGFwcGxpZXMgaW4g c2VjdGlvbiAyIHdoZW4gInNlY3VyaXR5IHByb3RvY29sIiBpcyBkZWZpbmVkLg0KICAgID4gDQog ICAgPiAtLSBTZWN0aW9uIDMgLS0NCiAgICA+IFVzZSB0aGUgd29yZGluZyBvZiAicmVjb3JkIHBy b3RvY29sIiBnZW5lcmljYWxseSB3aGlsZSB0aGUgdGVybSAicmVjb3JkDQogICAgPiBwcm90b2Nv bCIgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIgYXMgYSBibG9ja2VkIGRhdGEgdHJhbnNwb3J0IChs aWtlIGluIFRMUykuDQogICAgPiBTdWdnZXN0IHRoZSB1c2Ugb2YgImRhdGEgdHJhbnNmZXIgcHJv dG9jb2wiID8NCiAgICA+IA0KICAgID4gQW4gaW1wb3J0YW50IHByb3BlcnR5IG9mIHN1Y2ggcHJv dG9jb2xzIGlzIHRvIGJlIGFibGUgdG8gdHJhdmVyc2UgYSBOQVBUIGJveA0KICAgID4gKHRoYXQg SSBoYXRlKS4uLiBJIHN1Z2dlc3QgdG8gbWVudGlvbiB3aGV0aGVyIHRoZSBhbmFseXplZCBwcm90 b2NvbHMgc3VwcG9ydA0KICAgID4gTkFULXRyYXZlcnNhbCBpbiB0aGlzIGRlc2NyaXB0aW9uIHNl Y3Rpb24gb3IgZXZlbiBpbiB0aGUgYW5hbHlzaXMgcGFydHMgYXMNCiAgICA+IGhhdmluZyBhIGRp ZmZlcmVudCB2aWV3IChhcHBsaWNhdGlvbiBhbmQgbmV0d29yayBsYXllcnMgc2VlaW5nIHBvc3Np Ymx5DQogICAgPiBkaWZmZXJlbnQgSVAgYWRkcmVzc2VzIHNvIGEgcG90ZW50aWFsIGltcGFjdCBv biB0aGUgQVBJKS4NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICAtLSANCiAgICBDaGVlcnMN CiAgICANCiAgICBNYWdudXMgV2VzdGVybHVuZCANCiAgICANCiAgICANCiAgICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQogICAgTmV0d29ya3MsIEVyaWNzc29uIFJlc2VhcmNoDQogICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgIEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0K ICAgIFRvcnNoYW1uc2dhdGFuIDIzICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0K ICAgIFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1 bmRAZXJpY3Nzb24uY29tDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 9 05:41:37 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696683A07D3; Thu, 9 Apr 2020 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=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 8cbMSaqWLeAJ; Thu, 9 Apr 2020 05:41:26 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60075.outbound.protection.outlook.com [40.107.6.75]) (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 AAC033A07B5; Thu, 9 Apr 2020 05:41:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HM+f2bQeSDeLpao/8x5RvzvKgSbMH9crRT1jcECo6JX6zBCS8Lo4xQD2vgnRCBzaMDODfSp3PGyQt6bDSf9owW/KG7fW9nTBhgrA6IKBceax7JPfF6K7wz4DSPW3d9AmJ62QeWNm+a4WXIfTPT0yWK4jVip7bmLG8zckhLzrEgWomVoZyjxpfnhMK2HhalnPx1qz4lSMhhZQ5IyY9sbVX4xlhKJ5DRQZ858WOOXXS72cIC5jlH+RV2lwdMvNhQ8MlX6G33yJ5zOzavizmQ1V8MN69WM5pgR4+DYFIlHRk04+4NoUJq8pCNRd0fo9kIy+hRYTaoIiqYemyKTWADsRlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10oVErSzbULrxyv7CEOckQfu9/wq6EkUlj98jxJwwsU=; b=Vz/cbWmZin1xWDcHDxuFNMZH8I59M+J8VwqfHte+/7PLAoiHJiFcU3B2tiEP0GyxQDmpNwx2nzcd0HK8EzifejYCPZLaQwVVD1xVJqSduCqMFT1rmlXudgYaPrkYuJinUkSarL7XaHR9GXuDGCNppnNINAp6zTi7PuoEpWumSbn0GWsMBQnuf7AS+mcbOATnFastGt+r9HMkNs1dbyB0dz8M9wzMpUiSIj+frEc2w80rlna9d/h+gHOEdu1cHK1kTdJfZgcdlS9fIXMCYMuHePB0cKDqxeyDqxNzkEAm5bVVmaXJTl7nZBVlS0l9WneOlAygYFWmfR65KPCOrgTYMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=10oVErSzbULrxyv7CEOckQfu9/wq6EkUlj98jxJwwsU=; b=hvb49Q0yDKEOn4BoOrcY7deQFZQUy1VaeESGRa2xOUqJITviPIJic/uqbiejqsR5ea4tth+jDFqtwFeY3SfPBkIwm7e+RrN4tUGDqn5YGNPMojUKEl5EPM9nbIVwDGj9BYmv/SbuFEACVWL6wEWt9+0HP+/QoWNZqirXFbzO7aw= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3627.eurprd07.prod.outlook.com (2603:10a6:7:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Thu, 9 Apr 2020 12:41:23 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2900.012; Thu, 9 Apr 2020 12:41:23 +0000 From: Magnus Westerlund To: "evyncke=40cisco.com@dmarc.ietf.org" , "iesg@ietf.org" CC: "brian@innovationslab.net" , "taps-chairs@ietf.org" , "philipp@tiesel.net" , Mohit Sethi M , "int-dir@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "caw@heapingbits.net" , "taps@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRhcHMtdHJh?= =?utf-8?Q?nsport-security-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWDlXqWLSSULahQE2VBetBTFRtmahwtISAgAAErgCAAAIo4A== Date: Thu, 9 Apr 2020 12:41:22 +0000 Message-ID: References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> In-Reply-To: <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> 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=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89c4e0e1-030f-4890-74f8-08d7dc834fa6 x-ms-traffictypediagnostic: HE1PR0702MB3627:|HE1PR0702MB3627: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(396003)(376002)(136003)(76116006)(66616009)(2906002)(66946007)(66556008)(66446008)(5660300002)(86362001)(44832011)(64756008)(8936002)(99936003)(66476007)(55016002)(26005)(186003)(52536014)(316002)(9686003)(33656002)(54906003)(6506007)(71200400001)(110136005)(224303003)(81166007)(81156014)(478600001)(558084003)(4326008)(7696005); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4XPr2AD08ldOOuu6JRbJ/k4WS7s8iV9K7ow9FUN0FBwCJ2sFkoe6dORnaGAf327N6CB4nr31lWdtthiaTr4A23SOz4ELKXQWA8QgAT0bDE9agyBzbC/91GFZAlH4Zik4qsHNsxs0xXFHwyiz6R28p43OsOZ1my3UF9QJyRns3TltlbViJFfBGxedyrozXDeyrwrmkF2/PEgtv5VyYMSdacwIjTEq7opr3xjx07Uynhk/dhuDiIZoryIW5CNrojpboXej84YMyFY6jOjTQPPgyOGnTKGYNgjpv8gCIO2hbNiPsxFKe6ioLYJ68BJ+MTsqYHVVqQRkdm+ihKLpULTpaf+qDo1O2mI4vTJPg/13/pzrYjvxL11mZMd4ueloVz4cGLi1+iLkzxEMc319xK/eipv67qTQT/+0o9PQFt+d6+9PCmG6RYr6LQUtw6/ahVpN x-ms-exchange-antispam-messagedata: EfR5cbko0tpoq75fXOJKsYb+9g7gPlTpVLtRK/abvSj+o2YFxxMeU5jgh3AqYS5EVJaCcmhaj3NAG9UYVyBUS5bl+GBWfcCskzbStUIdpF3TDkfeSS7/J9J6NOUWZjmFdvABVWqsBvlP0bNOsTaavQ== Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_015B_01D60E7C.EFF2F920" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89c4e0e1-030f-4890-74f8-08d7dc834fa6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 12:41:23.0530 (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-CrossTenant-userprincipalname: 7BQGmhb3Ldfn3yNUkjEtZ1ziUwQvjYG2+zXLlEiPB6aJUmpo8tGVkLMoR2J6Eia8yvk067/oEvGgZrGW8fm9plBkCmbFOiH0HGUvWXNsixA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3627 Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 12:41:28 -0000 ------=_NextPart_000_015B_01D60E7C.EFF2F920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > A simple mention of the lack of IPv6 in section 3 of the description would > be > more than enough for me. Yes, but why do you consider that relevant for this document? Cheers Magnus ------=_NextPart_000_015B_01D60E7C.EFF2F920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw 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+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0yMDA0MDkxMjQxMjFaMCMGCSqGSIb3DQEJBDEWBBRydKePkQ1Cw20iPu3vnCsziEnC FzBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBACMreK03UNSGOun1vt1+88bV0dFdp1Wn5RZyGOeqNyaSHTMV h5vum39/9QAtf+/zXnaYIw37yGAN6cvDrqWw9D9wiEMSKlsnBa1QbgKcmp21g5UhEFFwqAGFxpOX TYMcl/xDDCfj0vPleqdGKUwOy58Pu+iUCGMDf5eLyDyqEY7BIgJsLTZbPr4jieBI8LyyIpB6N3Hw HRtVSxQ+W99XAgXiPk07F4tpal8pmu+UZF/XHu1P/NlXkaY/gu4dFYEBcyomSphWJ/nbPjfCoaKs pzwzL4ZGWSivFUfPyLROWZhBBwNlCDH5fpC7kNNq/EnhM8lDdZzgpW+IsYlfXNd/110AAAAAAAA= ------=_NextPart_000_015B_01D60E7C.EFF2F920-- From nobody Thu Apr 9 06:40:27 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5892E3A0B55; Thu, 9 Apr 2020 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Ee++nTQY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jhYfYJ2m 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 k_Nina1uH-lV; Thu, 9 Apr 2020 06:40:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC1B3A0B34; Thu, 9 Apr 2020 06:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1988; q=dns/txt; s=iport; t=1586439617; x=1587649217; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NaJFfsGtbtTRnfbY8JJo0NLwlAQTG3//d25P+2ruSDQ=; b=Ee++nTQYyB3aKFgGTQeO8UjSYHFVmXfQCtLREOKLmKWiPaD2tx3iv2sf W2TGOQwYIc7WQHJuGIEh3gUMWkHwX2RZd+4KtaiW0jUs2AwnGixUbjFgv uHDeptbrWPj2u8lnrjXFjVvoupb4vvFmClXF2mKmayx6/SpEsP5vOjW3L 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AdSsh5xfpvTLOuze5K0Y+7BK4lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AABmJI9e/5JdJa1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYFTUAWBRCAECyqEHINGA4prToIRmCCBLoEkA1QKAQE?= =?us-ascii?q?BDAEBLQIEAQGERAIXgXgkNgcOAgMBAQsBAQUBAQECAQUEbYVWDIVwAQEBAQI?= =?us-ascii?q?BEhERDAEBNwELBAIBCBEDAQIDAiYCAgIwFQUDCAIEAQ0FIoMEgkwDDiABpTU?= =?us-ascii?q?CgTmIYnWBMoJ/AQEFhTkYgg4JgQ4qAYwyGoFBP4E4HIJNPoJnBIFjgxIygiy?= =?us-ascii?q?Nb4JlO6AzCoI/jViJZBYHnBaDYYtlnDcCBAIEBQIOAQEFgVkKKIFXcBVlAYI?= =?us-ascii?q?+UBgNkSI4gzuKVXQCAQqBHI4fAQE?= X-IronPort-AV: E=Sophos;i="5.72,362,1580774400"; d="scan'208";a="744109488" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Apr 2020 13:40:16 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 039DeFAQ029761 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Apr 2020 13:40:15 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 08:40:15 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 08:40:15 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 9 Apr 2020 08:40:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PYot+bPYY0EljuLeadUVsFnYxbwzT4GhDfK8iWjtkf6PT6aNXbEnVeUt6NnQa4BOyRIw6hFemSbpgywOkU/+9F0Mxlf7/CM3l062PO3Cl9TUYotrMaHRNBCQ+GgKpW4RS8jvxfUvHiv63dRnyC/h0SjoziX4ifhMUzRHSXSgd5NjCIvRnpvpLtJ0LZzNwWE+dnGhF1vnGW0iFHqmmrXnfu5f30OaWeT7GPecxZ2RlFdJF8JP234ZLlhppA6ohYJqC7z62b6EdoAXV9Vpg7sVMkIrXR9hN25scJS8RfckEU2xca5YtTIkGFu8cOSKTSoRzFx0UCiYUp04hVehwjTilQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaJFfsGtbtTRnfbY8JJo0NLwlAQTG3//d25P+2ruSDQ=; b=iNNkH1AiB+bAGVBze8h3/tByl6PSFEjEpDHSy/EOWkNLLoyf1bnHpy6dTzIoU//HJCLs2N4f3rlmAzAhxpij4lwQrcUGIUVCZo4wGSVd6CaiPnVvQqmvH8SjkIIeJ7ZWK63sImaI5G9du3n7A2gxFtc8ipn3yiHV6cqd9BNsX5D0qfp5uRAGz5/RFZPTHEu/LYY6x1DvHA1oAiTHm42nlrwWtyHdJ4fEULp4gPHbr6Oux5RSkz0lTgOH/A41vNE+fZNUDLvgsOCnajJBdmLIgxNFCOXfcafuTOnQNi33E3QKAAnkG1xlQrLStt2eL+pLC0CoFIKYSe+G3HcgmxGS5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NaJFfsGtbtTRnfbY8JJo0NLwlAQTG3//d25P+2ruSDQ=; b=jhYfYJ2mWzZMLTOR2bryZYX2ZMwF9/osvtaWn7tEHVZEn4GkdyfrllsZ1SKpFcNYVAECGUHQ5ZCtWa7TtwfIZgSi6D6/B/FJkaKxMbGWgiJT+Tk7ooWhQtEKdMbkGTzSP2KhBggIu7EO9N7vyc1fVYrRKwKMtPuSDr0tdOGzXxk= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1258.namprd11.prod.outlook.com (2603:10b6:3:14::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 9 Apr 2020 13:40:14 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2878.018; Thu, 9 Apr 2020 13:40:14 +0000 From: "Eric Vyncke (evyncke)" To: Magnus Westerlund , "evyncke=40cisco.com@dmarc.ietf.org" , "iesg@ietf.org" CC: "brian@innovationslab.net" , "int-dir@ietf.org" , Mohit Sethi M , "taps-chairs@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "philipp@tiesel.net" , "caw@heapingbits.net" , "taps@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRhcHMtdHJh?= =?utf-8?Q?nsport-security-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWDlXlmLl+pE4XrEKlI+/geqSkX6hwtIeAgAAmMwD//+DzAIAAMfkA Date: Thu, 9 Apr 2020 13:40:14 +0000 Message-ID: References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:4c24:3036:65e7:5e26] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50ab777a-7de2-41b1-abb7-08d7dc8b88b8 x-ms-traffictypediagnostic: DM5PR11MB1258: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(376002)(346002)(54906003)(76116006)(66476007)(71200400001)(15650500001)(66946007)(478600001)(6486002)(7416002)(36756003)(6512007)(66446008)(5660300002)(66556008)(86362001)(53546011)(91956017)(81166007)(224303003)(81156014)(8936002)(316002)(186003)(2616005)(110136005)(33656002)(2906002)(6506007)(64756008)(4326008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wFhuKryn6bNIxVLyMV3GDW2aIjQ9azR/s5ENwe7ir/5+OtBMbyAtXvbmbUwkut9Wtk6/4hPdT9PL7f3ONtmTBuv00r3Yj+Qdl1F8vdqGv8Ii3/YG/GuG8FtXSQ3qDYZw4MDeAFA1FmMwfhPjr5+A/AbvXU5k/lO9okzFczi+kuGBW82f3j3lMWZMT9oRYaNGwk45USfQP9ihvBLjIsMbY546TSP+a9P6Xu3ETQx88rUGTY96BaADbG+ZSgk47ZpRVNEfSmnV8B6rGHDNz9grpg0i6kBnsybZaKnbGUF5+SbYMk7l/WNeH8G9D7OI0Jg1LC7VEPQNPJzbi8wV5bOntw280nu+ZSrMalU/rzeel6tFOYAUFdrY1/mewAMlghO15q10eqj5Exm3LgnspsR3Xsn4ZnqBb8HPrAqBlyoXR9vgwbGcjlx6iMkvm9v8YZ4E x-ms-exchange-antispam-messagedata: qeeL0Vu65kvcuu0DZLEv2lOiApgQGWyC627yKTTcCP8ldRvzMt9o5yRF/RRrO2s5a+IBlGiYjAEVa1gUg0hF8F27kwVwjoyiKc5gmCeraFjy7G2Iq3KltkCPcx85zibBqNrNBbpCFL130wy/0Lu3OdbxvXUkKD2pcDEUtlHOSgVuY9yB7UE7GBJUccpfGjvKHsJ1p5A7J4nVkaYAf+tcxQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <68E56AB3B981364C92057CF6F2D88476@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50ab777a-7de2-41b1-abb7-08d7dc8b88b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 13:40:14.7713 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fD0XLNy49ELJM6TwyGgBBrJpw3cHcGiJD5/FfS8GB/v1AqvJ3vTMPN3RFt9obJDv8ojGwkCuo+yC46bs10d5gg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1258 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:40:22 -0000 TWFnbnVzLA0KDQpXaGlsZSBteSBjb21tZW50IGlzIG5vdCBkaXJlY3RlZCB0byB0aGUgY29yZSBv ZiB0aGUgZG9jdW1lbnQsIEkgYmVsaWV2ZSB0aGF0IHdoZW4gb25lIElFVEYgZG9jdW1lbnQgcmVm ZXJzIGluIHRoZSBzZWN0aW9uIDMsICcgVHJhbnNwb3J0IFNlY3VyaXR5IFByb3RvY29sIERlc2Ny aXB0aW9ucycsIHRvIG5vbi1JRVRGIHByb3RvY29scywgdGhlbiBpbiBvcmRlciB0byBhdm9pZCBh bnkgJ0lFVEYgYmxlc3NpbmcnIG9mIHRoaXMgcHJvdG9jb2wsIGl0IHNob3VsZCBjbGVhcmx5IHN0 YXRlIHRoZSBpbXBvcnRhbnQgcHJvdG9jb2wgbGltaXRhdGlvbnMgd2hlbiBkZXNjcmliaW5nIHRo aXMgcHJvdG9jb2wuDQoNClJlZ2FyZHMNCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmQ9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmc+DQpEYXRlOiBUaHVyc2RheSwgOSBBcHJpbCAyMDIwIGF0IDE0OjQxDQpUbzog ImV2eW5ja2U9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIDxldnluY2tlPTQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPiwgImllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3JnPg0KQ2M6ICJi cmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQiIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ+LCAiaW50 LWRpckBpZXRmLm9yZyIgPGludC1kaXJAaWV0Zi5vcmc+LCBNb2hpdCBTZXRoaSBNIDxtb2hpdC5t LnNldGhpQGVyaWNzc29uLmNvbT4sICJ0YXBzLWNoYWlyc0BpZXRmLm9yZyIgPHRhcHMtY2hhaXJz QGlldGYub3JnPiwgImRyYWZ0LWlldGYtdGFwcy10cmFuc3BvcnQtc2VjdXJpdHlAaWV0Zi5vcmci IDxkcmFmdC1pZXRmLXRhcHMtdHJhbnNwb3J0LXNlY3VyaXR5QGlldGYub3JnPiwgInBoaWxpcHBA dGllc2VsLm5ldCIgPHBoaWxpcHBAdGllc2VsLm5ldD4sICJjYXdAaGVhcGluZ2JpdHMubmV0IiA8 Y2F3QGhlYXBpbmdiaXRzLm5ldD4sICJ0YXBzQGlldGYub3JnIiA8dGFwc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJFOiDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdGFwcy10cmFu c3BvcnQtc2VjdXJpdHktMTE6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCiAgICA+DQog ICAgPiBBIHNpbXBsZSBtZW50aW9uIG9mIHRoZSBsYWNrIG9mIElQdjYgaW4gc2VjdGlvbiAzIG9m IHRoZSBkZXNjcmlwdGlvbiB3b3VsZCANCiAgICA+IGJlDQogICAgPiBtb3JlIHRoYW4gZW5vdWdo IGZvciBtZS4NCiAgICANCiAgICBZZXMsIGJ1dCB3aHkgZG8geW91IGNvbnNpZGVyIHRoYXQgcmVs ZXZhbnQgZm9yIHRoaXMgZG9jdW1lbnQ/DQogICAgDQogICAgQ2hlZXJzDQogICAgDQogICAgTWFn bnVzDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Apr 9 06:47:00 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C596E3A0B6E; Thu, 9 Apr 2020 06:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.403 X-Spam-Level: X-Spam-Status: No, score=-1.403 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 2p3ddsKppyaN; Thu, 9 Apr 2020 06:46:49 -0700 (PDT) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) (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 24F173A0B69; Thu, 9 Apr 2020 06:46:49 -0700 (PDT) Received: by mail-io1-f68.google.com with SMTP id n20so3878484ioa.4; Thu, 09 Apr 2020 06:46:49 -0700 (PDT) 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=WP/jp5ntvlQpXpvvpWoEfTreXLa70RTn+RHrYXRmU2c=; b=Hs/R0CqjjI+oTgCW66n7UytfnfV4FcfdpZIukRyedOSTSkiVEdnwbDF8JcsifeW6R3 ryrlyHGKLRAR+H4KY0SW2dul19g/7n3L+rVO7TsSxeVMJ3x2+rUbqrx9Pk8r//yTcY2v WgeLGLGtzz9y0DfnNDnUGqPPTeSKbKAndpZW2obBjanNWIudrapchHEqIFQPkdO4keu3 eLyXeZCGI7Mgg/MSIYvvWbYNaDLgY06+GyuSrRi0WOhtPixVHV4nT1lDEGGz7eZhfsbo cc4f4i29YelzZMOxes72gC/5vgwy42p5Q+6gqeFM1I+tYWLaY1iQRBKeX989Zj8Qo3St YWcA== X-Gm-Message-State: AGi0PuYzKSkBV7SW7F59yUPg9hzjT4wyFuqthqXCV9t1UwLRahAYRSZK BG0ATKrdFxpUWpBkpfYpF8By7tvkfX/SD+5u+GrvkT8s X-Google-Smtp-Source: APiQypLWMSg1I7qde02z7091BZfPpOClRNe9tTtdr/d1Ry7NMB2LuJON7XiK9pwDJpsJ/qH4nc7e1cGKltDR82zGma0= X-Received: by 2002:a5e:df4b:: with SMTP id g11mr7234465ioq.84.1586440008253; Thu, 09 Apr 2020 06:46:48 -0700 (PDT) MIME-Version: 1.0 References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> In-Reply-To: From: Barry Leiba Date: Thu, 9 Apr 2020 09:46:37 -0400 Message-ID: To: "Eric Vyncke (evyncke)" Cc: Magnus Westerlund , "iesg@ietf.org" , "brian@innovationslab.net" , "philipp@tiesel.net" , Mohit Sethi M , "taps-chairs@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "int-dir@ietf.org" , "caw@heapingbits.net" , "taps@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 13:46:54 -0000 I have to agree with Magnus here: I think this is really a stretch. Barry On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke (evyncke) wrote: > > Magnus, > > While my comment is not directed to the core of the document, I believe t= hat when one IETF document refers in the section 3, ' Transport Security Pr= otocol Descriptions', to non-IETF protocols, then in order to avoid any 'IE= TF blessing' of this protocol, it should clearly state the important protoc= ol limitations when describing this protocol. > > Regards > > -=C3=A9ric > > =EF=BB=BF-----Original Message----- > From: iesg on behalf of Magnus Westerlund > Date: Thursday, 9 April 2020 at 14:41 > To: "evyncke=3D40cisco.com@dmarc.ietf.org" , "iesg@ietf.org" > Cc: "brian@innovationslab.net" , "int-dir@ietf.= org" , Mohit Sethi M , "taps-= chairs@ietf.org" , "draft-ietf-taps-transport-securit= y@ietf.org" , "philipp@tiesel.= net" , "caw@heapingbits.net" , "ta= ps@ietf.org" > Subject: RE: =C3=89ric Vyncke's Discuss on draft-ietf-taps-transport-secu= rity-11: (with DISCUSS and COMMENT) > > > > > A simple mention of the lack of IPv6 in section 3 of the descriptio= n would > > be > > more than enough for me. > > Yes, but why do you consider that relevant for this document? > > Cheers > > Magnus > > > > From nobody Thu Apr 9 07:01:30 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE1E3A0BBC for ; Thu, 9 Apr 2020 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=krose.org 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 1ZpYF271--dy for ; Thu, 9 Apr 2020 07:01:11 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 C55733A0747 for ; Thu, 9 Apr 2020 07:01:05 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id l84so5781532ybb.1 for ; Thu, 09 Apr 2020 07:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zOVghcbg02tswPxPappPWcfQOHWa5zVejgzsFGbeXmE=; b=C7xU3AIvRzgkRgcM3KGFAqreo4hmtizUnjVCg0W/wl/4Zjpjs0eDnnSm4fRy/E8UHQ 2bgHANWY+bzP0eC3KJpwm2sNlhEE5h2oYVJD9wwK/kzJj57HhV2khfzFZBTESUtaBvaG gDcJO6fRqjSm8b53y6ctLLddTvf+PPzSOj1mU= 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=zOVghcbg02tswPxPappPWcfQOHWa5zVejgzsFGbeXmE=; b=c/ALoHxRFr3bfjA32oIRhSss9SphAUfPE18dXHwsD+g02P5arkgotRiX8BGuGKNqUt 2+l2PxMCVPR2CLdcyEhN2J06CajFCB7wNOi2KG+rEEvmkFHpXBAFo8FUiX2v/uJX6Fi9 2COyN+UwDaP9D6DWKufr7RtmwupZY6wKMnq9zBwC0mpoV0K4GE4SIgAtdVThv5DiYQIc HKYwLEodJEVK5neW2ydrcJ+Qud+r117h2L9qvgIV0UhYbwXhC5n0pVvot344PxkbKcpp YCOrxluJtbRJSRWEwvmkBHBok+bPQCY5OdDrMRZyCoWaup3tZodtaxmgG2TOrtjrDZO9 oUdQ== X-Gm-Message-State: AGi0PuZb0oe7gWF5hJZfk04F1Ev0lP3xVL3Hmq3+Wv1U4jnl6t2OCl/x aLPv1YG6Mbc7lkyMtFgLo0VO7YmKa+z7xy314tXxkQ== X-Google-Smtp-Source: APiQypKy/W4KMO7agURkxwJ4n0puY4EbSMj8dypOf/IeVuXji3gYwT4bCY121QrYqMkkjJooRMcuDHahEgYBYTaRz3A= X-Received: by 2002:a25:6757:: with SMTP id b84mr21466245ybc.396.1586440864304; Thu, 09 Apr 2020 07:01:04 -0700 (PDT) MIME-Version: 1.0 References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> In-Reply-To: From: Kyle Rose Date: Thu, 9 Apr 2020 10:00:52 -0400 Message-ID: To: Barry Leiba Cc: "Eric Vyncke (evyncke)" , Magnus Westerlund , "iesg@ietf.org" , "brian@innovationslab.net" , "philipp@tiesel.net" , Mohit Sethi M , "taps-chairs@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "int-dir@ietf.org" , "caw@heapingbits.net" , "taps@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ca4c405a2dc0c19" Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:01:16 -0000 --0000000000002ca4c405a2dc0c19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. This document is not an endorsement of any of the protocols mentioned, merely an analysis from a security perspective. Mentioning IPv6 here would be a non-sequitur. On Thu, Apr 9, 2020 at 9:46 AM Barry Leiba wrote: > I have to agree with Magnus here: I think this is really a stretch. > > Barry > > On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke (evyncke) > wrote: > > > > Magnus, > > > > While my comment is not directed to the core of the document, I believe > that when one IETF document refers in the section 3, ' Transport Security > Protocol Descriptions', to non-IETF protocols, then in order to avoid any > 'IETF blessing' of this protocol, it should clearly state the important > protocol limitations when describing this protocol. > > > > Regards > > > > -=C3=A9ric > > > > =EF=BB=BF-----Original Message----- > > From: iesg on behalf of Magnus Westerlund > > > Date: Thursday, 9 April 2020 at 14:41 > > To: "evyncke=3D40cisco.com@dmarc.ietf.org" 40cisco.com@dmarc.ietf.org>, "iesg@ietf.org" > > Cc: "brian@innovationslab.net" , " > int-dir@ietf.org" , Mohit Sethi M < > mohit.m.sethi@ericsson.com>, "taps-chairs@ietf.org" , > "draft-ietf-taps-transport-security@ietf.org" < > draft-ietf-taps-transport-security@ietf.org>, "philipp@tiesel.net" < > philipp@tiesel.net>, "caw@heapingbits.net" , " > taps@ietf.org" > > Subject: RE: =C3=89ric Vyncke's Discuss on > draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) > > > > > > > > A simple mention of the lack of IPv6 in section 3 of the > description would > > > be > > > more than enough for me. > > > > Yes, but why do you consider that relevant for this document? > > > > Cheers > > > > Magnus > > > > > > > > > --0000000000002ca4c405a2dc0c19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agr= eed. This document is not an endorsement of any of the protocols mentioned,= merely an analysis from a security perspective. Mentioning IPv6 here would= be a non-sequitur.


On Thu, Apr 9, 2020 at 9:46 AM Barry Leiba <barryleiba@computer.org> wrote:
I have to agree with = Magnus here: I think this is really a stretch.

Barry

On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke (evyncke)
<evyncke=3D40cisco.com@dmarc.ietf.org> wrote:
>
> Magnus,
>
> While my comment is not directed to the core of the document, I believ= e that when one IETF document refers in the section 3, ' Transport Secu= rity Protocol Descriptions', to non-IETF protocols, then in order to av= oid any 'IETF blessing' of this protocol, it should clearly state t= he important protocol limitations when describing this protocol.
>
> Regards
>
> -=C3=A9ric
>
> =EF=BB=BF-----Original Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of Magnus Westerlund <magnus= .westerlund=3D40ericsson.com@dmarc.ietf.org>
> Date: Thursday, 9 April 2020 at 14:41
> To: "evyncke=3D40cisco.com@dmarc.ietf.org" <evyncke=3D40cisco.com@dmarc.iet= f.org>, "ies= g@ietf.org" <iesg@ietf.org>
> Cc: "brian@innovationslab.net" <brian@innovationslab.net>, "int-dir@ietf.org" &= lt;int-dir@ietf.org>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, "taps-chairs@ietf.org" <= taps-chairs@ietf.= org>, "draft-ietf-taps-transport-security@ietf.org&qu= ot; <draft-ietf-taps-transport-security@ietf.org>, "philipp@tiesel.net" <philipp= @tiesel.net>, "caw@heapingbits.net" <caw@heapingbits.net>, "taps@ietf.org" <taps@ietf.org>
> Subject: RE: =C3=89ric Vyncke's Discuss on draft-ietf-taps-transpo= rt-security-11: (with DISCUSS and COMMENT)
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A simple mention of the lack of IPv6 in sectio= n 3 of the description would
>=C2=A0 =C2=A0 =C2=A0> be
>=C2=A0 =C2=A0 =C2=A0> more than enough for me.
>
>=C2=A0 =C2=A0 =C2=A0Yes, but why do you consider that relevant for this= document?
>
>=C2=A0 =C2=A0 =C2=A0Cheers
>
>=C2=A0 =C2=A0 =C2=A0Magnus
>
>
>
>
--0000000000002ca4c405a2dc0c19-- From nobody Thu Apr 9 07:38:12 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8553A07A6; Thu, 9 Apr 2020 07:38:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158644309093.3622.11128003590990110741@ietfa.amsl.com> Date: Thu, 09 Apr 2020 07:38:10 -0700 Archived-At: Subject: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-taps-transport-security-11=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:38:11 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-taps-transport-security-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is really easy to read. After discussion with Magnus and Barry, I have cleared my DISCUSS but I still hope for a fix to my previous DISCUSS Please find below some non-blocking COMMENTs. An answer will still be appreciated. I hope that this helps to improve the document, Regards, -éric == previous DISCUSS == I question the inclusion of CurveCP in the mix as per https://curvecp.org/addressing.html it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3 or rename section 3 from "protocol descriptions" into something less exhaustive. (and I hope to be corrected about CurveCP IPv6 support). == COMMENT == Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + Gorry Fairhurst's about GRE Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction. -- Section 1 -- Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined. -- Section 3 -- Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ? An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API). From nobody Thu Apr 9 07:58:55 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDC73A0921; Thu, 9 Apr 2020 07:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 bzSqQOU8SN-e; Thu, 9 Apr 2020 07:58:47 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20053.outbound.protection.outlook.com [40.107.2.53]) (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 23C333A091B; Thu, 9 Apr 2020 07:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VwRCiQ7i8dqvXA5j+SauskouDI15JAuWIrC9pg1Lg5MTNADGDGgIGCigwbOo6TkRcnc68aD07+1/qUXpa7L2RxTEeAD4gGfMLFzDDVGn91i5azm6MRJTqeJlNJo+zNOQZ6nwDNlI7xKi8htcpnrhucHcnZJuTj8rROinyLb4ehyXYHHUah0dm3XmVY/QRQcnTClbW284dfSLGwketGldQhFSa3HY9Ymmse+ONEMgW1m9GOA5/B+UnYfndWTcdsXHXLJIN14A+5jrIx74ZxuUgKkmT16iWwCjoCqQKokJ8tZoEp+xajBlsdM9yO96mU4JaC9sQBSzDg7efkivAe+vEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LSYAYNhI6xhP2PC0iREkxw5rn0RE3CAyhCo7Nll7LFM=; b=l4B3NvU0KlXxIL8yevUlJzZIIDsdnCZpkIHWIsna0I6JipWJHvajnuy1YikXqI4i60NqIS/prjslcEcgzPAupe3UB3z8bGDMyAtfzp/JYfJ6ZxPX2E9IAGgi968yderEbw+Jc/rLpgw2kNDsponphTpgpZvMFRww/WWDloAZsxe9VvsBoUJKO7358+se44HDRFtLctTb10uxr6JtQUOBvbKbbnVyk1Gmx/TzeCyVGB1fFei3YAcJY0+U/Q9iJkhXDbBRvrBdG7rxoeyKIQ7qWKHW4MCVgP53hBDYqyHTosY1j87sHEVBo6USHXYz4KyiyQwBnD0ufMrJP/o14vkvpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LSYAYNhI6xhP2PC0iREkxw5rn0RE3CAyhCo7Nll7LFM=; b=f8Ijh5HRPV6cW6nYpdY82txiu68iJ44TXq6WJ5BeKLJJCh/pr6okfRnn5OgAzluhQ5QzfrXqoSI7vD6TmIzaOydM8oHN+5T3bNaAeK2uYRS+KC+p8G2Vu5Cqi/O8SFLuYsVJ7jTkXYuI9eFqGRgNYrkTUohVuAzoHM7sKWUhniA= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3595.eurprd07.prod.outlook.com (2603:10a6:7:87::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.13; Thu, 9 Apr 2020 14:58:32 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2900.012; Thu, 9 Apr 2020 14:58:32 +0000 From: Magnus Westerlund To: "krose@krose.org" , "barryleiba@computer.org" CC: "evyncke=40cisco.com@dmarc.ietf.org" , "brian@innovationslab.net" , "philipp@tiesel.net" , Mohit Sethi M , "taps-chairs@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "int-dir@ietf.org" , "iesg@ietf.org" , "taps@ietf.org" , "magnus.westerlund=40ericsson.com@dmarc.ietf.org" , "caw@heapingbits.net" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXRhcHMtdHJh?= =?utf-8?Q?nsport-security-11:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWDlXqWLSSULahQE2VBetBTFRtmahwtISAgAAErgCAAAIo4IAAEMUAgAAByYCAAAP7AIAADO4w Date: Thu, 9 Apr 2020 14:58:32 +0000 Message-ID: References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> In-Reply-To: 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=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.118.23] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 608c5a76-6dfb-4739-22df-08d7dc967896 x-ms-traffictypediagnostic: HE1PR0702MB3595:|HE1PR0702MB3595: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0368E78B5B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(346002)(376002)(396003)(86362001)(55016002)(478600001)(52536014)(66446008)(66616009)(316002)(110136005)(9686003)(76116006)(66946007)(54906003)(81166007)(66556008)(71200400001)(64756008)(6506007)(66476007)(53546011)(224303003)(99936003)(44832011)(33656002)(186003)(26005)(2906002)(5660300002)(7696005)(15650500001)(4326008)(8936002)(7416002)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3edgvhCSNi8haeQTZgRmGXx55sfMK6L9/cuwkmJRA+euETAEa54cgToWyWxaeHhtLyJoEXpAksCw6SB4gxqn+01E9W/mpceb810qJ3NjNUu23KAODEt0s+HcrGcQ3WA7kxuxOXP236pjwOCyt8h5nrta/GWjSSMjip4Tt0SuSs9TwtItVAUHrIDZAohQl2v+KRwL/tOQb2wb5/ttzkOAV1EJYMIPnj6BAfs8Pw5AoxyR9ZITfCO71JxSzJuIWzAHGrI51omAO5V208YJ3p158BW4y1Taey0S9itzqk1Z51NIZJ5oreB9R4XaVIKkzB86kEwZTzvU71FbTqulpy1ZK8qd7CEiPLBfAqdK84gi123gkUzjyj5W6ja6L/KaweyF0WJN0sHQIRsLbFvyHqKSSQGb1sYuU8cuNt+nqJjK1HwuyHq1l5FcKt4E4/5aAR9u x-ms-exchange-antispam-messagedata: V4GDKD3fjwG8NVStOnsOKvDaQRmvY0gB74CMqHIOQCIQYMTKTfvX2mRmKaw8eLvXr02paA0kUjZE7NpyjF6EByH2WwxCUtdXdaYhRiaUIrFvGjw7MnW2U4Eubu0PYJZ+Kw5R5UQfHrKCIfZtqJLNnQ== Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_015F_01D60E90.18B7DA70" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 608c5a76-6dfb-4739-22df-08d7dc967896 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 14:58:32.1385 (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-CrossTenant-userprincipalname: 8Mou1VuJzgrUt+64Gj1L2XspyGq9aQ//3Np3KE9IF/D5Qvf11y2aNDeyDSkkE3MVTuUZCKLLPSxI2X48LgNmSBT3NTiLjEZtlLmEK7yomWI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3595 Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:58:50 -0000 ------=_NextPart_000_015F_01D60E90.18B7DA70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0160_01D60E90.18B7DA70" ------=_NextPart_001_0160_01D60E90.18B7DA70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 Eric and I have discussed this and the proposal is a clarifying change = to the initial statement in Section 3: =20 OLD: =20 This section contains brief descriptions of the various security protocols currently used to protect data being sent over a network. =20 NEW:=20 =20 This section contains brief transport and security descriptions of = the various security protocols currently used to protect data being sent over a network. =20 The purpose of this change to clarify that these descriptions are only = concerning relevant aspects of transport and security.=20 =20 Are the WG and authors ok with the above change?=20 =20 Cheers =20 Magnus =20 =20 From: iesg On Behalf Of Kyle Rose Sent: den 9 april 2020 16:01 To: Barry Leiba Cc: Eric Vyncke (evyncke) ; = brian@innovationslab.net; philipp@tiesel.net; Mohit Sethi M = ; taps-chairs@ietf.org; = draft-ietf-taps-transport-security@ietf.org; int-dir@ietf.org; = iesg@ietf.org; taps@ietf.org; Magnus Westerlund = ; caw@heapingbits.net Subject: Re: =C3=89ric Vyncke's Discuss on = draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) =20 Agreed. This document is not an endorsement of any of the protocols = mentioned, merely an analysis from a security perspective. Mentioning = IPv6 here would be a non-sequitur. =20 =20 On Thu, Apr 9, 2020 at 9:46 AM Barry Leiba > wrote: I have to agree with Magnus here: I think this is really a stretch. Barry On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke (evyncke) > wrote: > > Magnus, > > While my comment is not directed to the core of the document, I = believe that when one IETF document refers in the section 3, ' Transport = Security Protocol Descriptions', to non-IETF protocols, then in order to = avoid any 'IETF blessing' of this protocol, it should clearly state the = important protocol limitations when describing this protocol. > > Regards > > -=C3=A9ric > > =EF=BB=BF-----Original Message----- > From: iesg > on = behalf of Magnus Westerlund = > > Date: Thursday, 9 April 2020 at 14:41 > To: "evyncke=3D40cisco.com@dmarc.ietf.org = " = >, "iesg@ietf.org = " > > Cc: "brian@innovationslab.net " = >, = "int-dir@ietf.org " >, Mohit Sethi M >, "taps-chairs@ietf.org = " >, = "draft-ietf-taps-transport-security@ietf.org = " = >, = "philipp@tiesel.net " >, "caw@heapingbits.net = " >, "taps@ietf.org " = > > Subject: RE: =C3=89ric Vyncke's Discuss on = draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) > > > > > A simple mention of the lack of IPv6 in section 3 of the = description would > > be > > more than enough for me. > > Yes, but why do you consider that relevant for this document? > > Cheers > > Magnus > > > > ------=_NextPart_001_0160_01D60E90.18B7DA70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

Eric and I have discussed this and = the proposal is a clarifying change to the initial statement in Section = 3:

 

OLD:

 

=C2=A0=C2=A0 This = section contains brief descriptions of the various = security

=C2=A0=C2=A0 = protocols currently used to protect data being sent over a = network.

 

NEW:

 

=C2=A0=C2=A0 This section contains brief transport and =
security descriptions of the various =
security
=C2=A0=C2=A0 =
protocols currently used to protect data being sent over a =
network.

 

The purpose of this change to = clarify that these descriptions are only concerning relevant aspects of = transport and security.

 

Are the WG and authors ok with the = above change?

 

Cheers

 

Magnus

 

 

From: iesg = <iesg-bounces@ietf.org> On Behalf Of Kyle = Rose
Sent: den 9 april 2020 16:01
To: Barry Leiba = <barryleiba@computer.org>
Cc: Eric Vyncke (evyncke) = <evyncke=3D40cisco.com@dmarc.ietf.org>; brian@innovationslab.net; = philipp@tiesel.net; Mohit Sethi M <mohit.m.sethi@ericsson.com>; = taps-chairs@ietf.org; draft-ietf-taps-transport-security@ietf.org; = int-dir@ietf.org; iesg@ietf.org; taps@ietf.org; Magnus Westerlund = <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org>; = caw@heapingbits.net
Subject: Re: =C3=89ric Vyncke's Discuss on = draft-ietf-taps-transport-security-11: (with DISCUSS and = COMMENT)

 

Agreed. This document = is not an endorsement of any of the protocols mentioned, merely an = analysis from a security perspective. Mentioning IPv6 here would be a = non-sequitur.

 

 

On = Thu, Apr 9, 2020 at 9:46 AM Barry Leiba <barryleiba@computer.org> = wrote:

I have to = agree with Magnus here: I think this is really a = stretch.

Barry

On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke = (evyncke)
<evyncke=3D40cisco.com@dmarc.ietf.org> = wrote:
>
> Magnus,
>
> While my comment is not = directed to the core of the document, I believe that when one IETF = document refers in the section 3, ' Transport Security Protocol = Descriptions', to non-IETF protocols, then in order to avoid any 'IETF = blessing' of this protocol, it should clearly state the important = protocol limitations when describing this protocol.
>
> = Regards
>
> -=C3=A9ric
>
> = =EF=BB=BF-----Original Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of Magnus = Westerlund <magnus..westerlund=3D40ericsson.com@dmarc.ietf.org>
> Date: = Thursday, 9 April 2020 at 14:41
> To: "evyncke=3D40cisco.com@dmarc.ietf.org" <evyncke=3D40cisco.com@dmarc.ietf.org>, "iesg@ietf.org" = <iesg@ietf.org>
> Cc: "brian@innovationslab.net" <brian@innovationslab.net>, "int-dir@ietf.org" <int-dir@ietf.org>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, "taps-chairs@ietf.org" <taps-chairs@ietf.org>, "draft-ietf-taps-transport-security@ietf.org" = <draft-ietf-taps-transport-security@ietf.org>, = "philipp@tiesel.net" <philipp@tiesel.net>, "caw@heapingbits.net" <caw@heapingbits.net>, "taps@ietf.org" = <taps@ietf.org>
> Subject: RE: =C3=89ric = Vyncke's Discuss on draft-ietf-taps-transport-security-11: (with DISCUSS = and COMMENT)
>
>     >
>  =    > A simple mention of the lack of IPv6 in section 3 of = the description would
>     > be
>  =    > more than enough for me.
>
>    =  Yes, but why do you consider that relevant for this = document?
>
>    =  Cheers
>
>    =  Magnus
>
>
>
>

<= /div>
------=_NextPart_001_0160_01D60E90.18B7DA70-- ------=_NextPart_000_015F_01D60E90.18B7DA70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw 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+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0yMDA0MDkxNDU4MzBaMCMGCSqGSIb3DQEJBDEWBBRj2mfA09wtdVnQPrrZIk1FHncB xjBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBAAzt2dXFPP5UkRd6us8728N7yBzRLJcVcjCBduugkKDqfLMl bJO6+GT4Ryqhs0xPN1/UGE4e655Z9JBTCn6A+CwUWG7YgsaliGxVq+TUwFSoiedI6yjezebZfx8t SaorTnxG+AAA9VAbUqBE6+mxQ1V6mnzG4Xz9xWDO3PTOQJpXOXIXrmQJfXfc8xQcUZU0C8NBocG4 26Iy1h5Yjj+qPbhswgE16k5bdEnrMkyKbGCmIB04LUJkJm0aCvgI11SpBh1y+KTW/C/F8QCqExaY 6Sl2E3QsoDi1N76Kp55I1lIYmQFA5We5jujgxRA0YalUe8/YnZEBwA2uDxosTjs0sZgAAAAAAAA= ------=_NextPart_000_015F_01D60E90.18B7DA70-- From nobody Thu Apr 9 13:35:30 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CBC3A0DE4; Thu, 9 Apr 2020 13:35:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net, philipp@tiesel.net X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <158646452438.12141.3985915802666927956@ietfa.amsl.com> Date: Thu, 09 Apr 2020 13:35:24 -0700 Archived-At: Subject: [Taps] Martin Duke's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 20:35:25 -0000 Martin Duke has entered the following ballot position for draft-ietf-taps-transport-security-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- These taps Informational RFCs are going to be bound together and make a great textbook someday. One nit: In section 5.3, you note that TLS supports key export. IIRC, this is only TLS 1.3. It might be worthwhile to specify it is 1.3 only. From nobody Thu Apr 9 15:03:47 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43F53A1009; Thu, 9 Apr 2020 15:03:45 -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, SPF_HELO_NONE=0.001, 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 USlA3eBfdzTB; Thu, 9 Apr 2020 15:03:44 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AA4B63A1006; Thu, 9 Apr 2020 15:03:43 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 039M3X3U017208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 18:03:35 -0400 Date: Thu, 9 Apr 2020 15:03:32 -0700 From: Benjamin Kaduk To: Martin Duke Cc: The IESG , philipp@tiesel.net, taps@ietf.org, taps-chairs@ietf.org, caw@heapingbits.net, draft-ietf-taps-transport-security@ietf.org Message-ID: <20200409220332.GG88064@kduck.mit.edu> References: <158646452438.12141.3985915802666927956@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <158646452438.12141.3985915802666927956@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Taps] Martin Duke's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 22:03:46 -0000 On Thu, Apr 09, 2020 at 01:35:24PM -0700, Martin Duke via Datatracker wrote: > Martin Duke has entered the following ballot position for > draft-ietf-taps-transport-security-11: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > These taps Informational RFCs are going to be bound together and make a great > textbook someday. > > One nit: In section 5.3, you note that TLS supports key export. IIRC, this is > only TLS 1.3. It might be worthwhile to specify it is 1.3 only. The TLS Exporter mechanism is defined by RFC 5705 for TLS non-1.3. -Ben From nobody Fri Apr 10 01:02:21 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431EE3A196B for ; Fri, 10 Apr 2020 01:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 2LivW7xFS46Y for ; Fri, 10 Apr 2020 01:02:18 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 DC7303A1966 for ; Fri, 10 Apr 2020 01:02:17 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1jMoa6-0006qL-3X for taps@ietf.org; Fri, 10 Apr 2020 08:00:06 +0000 Content-Type: multipart/alternative; boundary="===============3660023676453340640==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 10 Apr 2020 08:00:06 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 08:02:20 -0000 --===============3660023676453340640== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+17/-8/=F0=9F=92=AC22) 17 issues created: - Implementation details for QUIC missing (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/553 [Implementation] = - What HTTP/2 transport? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/552 [Implementation] = - Close for HTTP (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/551 [Implementation] = - What's PRIMITIVENAME? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/549 = - Certificates and other security parameters (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/548 [Implementation] = - flushing cache state (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/546 [Implementation] = - More guidance needed on Handling Path Changes (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/545 = - minIncompleteLength when receiving data on streams (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/543 [Implementation] = - Batching Sends (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/542 [Implementation] = - Message Properties in API and Implementation draft (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/540 [API] [Implementat= ion] = - Listeners and ports (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/539 [API] [Implementat= ion] = - Interface for app-driven racing of "unconnected" protocols? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/538 [Implementation] = - Recommendations for Delayed Racing (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/537 = - Branching Order-of-Operations (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/536 [Implementation] = - What's a path...? (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/533 [Implementation] = - (hopefully) minor point about properties terminology (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/531 [Implementation] = - Create an enum for querying properties (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/528 [API] = 15 issues received 22 new comments: - #539 Listeners and ports (5 by mirjak, mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/539 [API] [Implementat= ion] = - #533 What's a path...? (3 by mirjak, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/533 [Implementation] = - #441 Questions on Connection Groups (2 by britram, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/441 [API] = - #416 add example for "information about the received Message"? (1 by br= itram) https://github.com/ietf-tapswg/api-drafts/issues/416 [Architecture] [ed= itorial] [ready for text] = - #418 Use of normative language in Arch (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/418 [Architecture] [di= scuss] = - #549 What's PRIMITIVENAME? (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/549 [Implementation] = - #455 Message context (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/455 [API] = - #520 Reliable Data Transfer (Message) default - from Kyle Rose's review= (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/520 [API] [discuss] = - #457 Framers again... (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/457 [API] [Implementat= ion] [discuss] = - #522 Idempotency vs replay-safe (from Kyle Rose's review) (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/522 [API] [discuss] = - #519 Architecture: normative arch language (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/519 [Architecture] [di= scuss] = - #524 What constitutes trust verification prior to the handshake? (1 by = mirjak) https://github.com/ietf-tapswg/api-drafts/issues/524 [API] = - #525 single messageContext object for both sends and receives (1 by mir= jak) https://github.com/ietf-tapswg/api-drafts/issues/525 [API] = - #531 (hopefully) minor point about properties terminology (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/531 [Implementation] = - #413 Do we need to say more about authentication and encryption? (1 by = britram) https://github.com/ietf-tapswg/api-drafts/issues/413 [Architecture] [re= ady for text] = 8 issues closed: - What's PRIMITIVENAME? https://github.com/ietf-tapswg/api-drafts/issues/= 549 [Implementation] = - Bandwidth Efficiency as a term in API https://github.com/ietf-tapswg/ap= i-drafts/issues/515 [API] = - Receive semantics https://github.com/ietf-tapswg/api-drafts/issues/454 = [API] = - What's meant by "type of Message"? https://github.com/ietf-tapswg/api-d= rafts/issues/450 [API] = - Privacy considerations section https://github.com/ietf-tapswg/api-draft= s/issues/177 [API] [Implementation] [ready for text] = - Use of normative language in Arch https://github.com/ietf-tapswg/api-dr= afts/issues/418 [Architecture] [discuss] = - add example for "information about the received Message"? https://githu= b.com/ietf-tapswg/api-drafts/issues/416 [Architecture] [editorial] [ready f= or text] = - Do we need to say more about authentication and encryption? https://git= hub.com/ietf-tapswg/api-drafts/issues/413 [Architecture] [ready for text] = Pull requests ------------- * ietf-tapswg/api-drafts (+10/-9/=F0=9F=92=AC5) 10 pull requests submitted: - preamble text in security considerations section (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/554 = - Text around "PRIMITIVENAME" in implementation draft (issue #549) (by mw= elzl) https://github.com/ietf-tapswg/api-drafts/pull/550 = - Add reference to draft-ietf-tcpm-2140bis (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/547 = - Editorial edits on fast open (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/544 = - Added a selection property for a special communication pattern (by mwel= zl) https://github.com/ietf-tapswg/api-drafts/pull/541 = - Adjust level of branching related subsections (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/535 = - RFC references for mDNS and DNS-SD (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/534 = - Add reference to RFC8445 on first occurrence of ICE (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/532 = - Introduce the term Message early on (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/530 = - No reference abstract (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/529 = 5 pull requests received 5 new comments: - #544 Editorial edits on fast open (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/544 = - #483 Minor API nits (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/483 [API] = - #527 Closes #515. + addresses a few more of the easy things from Kyle'= s review. (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/527 = - #532 Add reference to RFC8445 on first occurrence of ICE (1 by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/532 = - #535 Adjust level of branching related subsections (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/535 = 9 pull requests merged: - Text around "PRIMITIVENAME" in implementation draft (issue #549) https://github.com/ietf-tapswg/api-drafts/pull/550 = - preamble text in security considerations section https://github.com/ietf-tapswg/api-drafts/pull/554 = - Closes #515. + addresses a few more of the easy things from Kyle's rev= iew. https://github.com/ietf-tapswg/api-drafts/pull/527 = - Adjust level of branching related subsections https://github.com/ietf-tapswg/api-drafts/pull/535 = - Introduce the term Message early on https://github.com/ietf-tapswg/api-drafts/pull/530 = - No reference in abstract https://github.com/ietf-tapswg/api-drafts/pull/529 = - Add reference to RFC8445 on first occurrence of ICE https://github.com/ietf-tapswg/api-drafts/pull/532 = - RFC references for mDNS and DNS-SD https://github.com/ietf-tapswg/api-drafts/pull/534 = - Minor API nits https://github.com/ietf-tapswg/api-drafts/pull/483 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============3660023676453340640== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday April 10, 2020

Issues

ietf-tapswg/api-drafts (+17/-8/=F0=9F=92=AC22)

17 issues created:

15 issues received 22 new comments:

8 issues closed:

Pull requests

ietf-tapswg/api-drafts (+10/-9/=F0=9F=92=AC5)

10 pull requests submitted:

5 pull requests received 5 new comments:

9 pull requests merged:

Repositories tracked by this digest:

--===============3660023676453340640==-- From nobody Mon Apr 13 10:30:02 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39033A19E9; Mon, 13 Apr 2020 10:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 flfxj9rjV29K; Mon, 13 Apr 2020 10:29:50 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 0D1933A19E1; Mon, 13 Apr 2020 10:29:49 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 03DHMEQZ050461; Mon, 13 Apr 2020 10:29:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=gRtVxsA2y+ZpoU6v6RANTSquFRqzwk4hgeY4012ZL34=; b=f4XxRjSmOm7M8YsDEhNwSmKcrQ2ZK0lJs/1YHzFiGfrC3eWNXLIj/ch0Xrd+cQAyxcnw 2UgsLAECXBDc3vZblRo5aTKZ4SEGt4kykgWrGLqgrzeCbW1pLDKAPeEQCW7OsksFPk+R 99lLILPxsdtTSXeQcuRmXBZYqrEZLFDjrP2E++JILov8e2tP8x9jdE1yNtw9mspX25LZ +wAwpB598mpSNP+etx2gps7Vmd7XgTqQuDiUwHAPDIicMPUJN9lf4NamGz8eWWSQW3dK aGIllk3D2Nt58A/2dLVcZdS1JnkP+KskQ1mZ5pd/KKAVmuGWOVWH5wj0u9YlEzPd5VjS Ew== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp03.apple.com with ESMTP id 30bx4h7def-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Apr 2020 10:29:49 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q8Q00VD1LXNWUJ0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Mon, 13 Apr 2020 10:29:48 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q8Q00U00LQ6VM00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 13 Apr 2020 10:29:48 -0700 (PDT) X-Va-A: X-Va-T-CD: fa628b2f79844893b71f4d5f3cd39427 X-Va-E-CD: 32c271aac45d61a3c4d314c2715fc097 X-Va-R-CD: 2eaad1679a8d30e9d7cb8bd89a817621 X-Va-CD: 0 X-Va-ID: 9b5e5949-b9f5-4432-bf6c-2f4fdb7e5d09 X-V-A: X-V-T-CD: fa628b2f79844893b71f4d5f3cd39427 X-V-E-CD: 32c271aac45d61a3c4d314c2715fc097 X-V-R-CD: 2eaad1679a8d30e9d7cb8bd89a817621 X-V-CD: 0 X-V-ID: a6e17b6c-f50d-4ed8-9547-6ac050da9b76 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-13_08:2020-04-13, 2020-04-13 signatures=0 Received: from [17.234.69.124] (unknown [17.234.69.124]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q8Q00O9SLXK1400@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 13 Apr 2020 10:29:48 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <393C5C22-17B4-49EC-A71A-B8C7140F0320@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_B0242775-78B5-46FC-805E-0253D181A132" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Mon, 13 Apr 2020 10:29:44 -0700 In-reply-to: Cc: "taps-chairs@ietf.org" , "draft-ietf-taps-transport-security@ietf.org" , "int-dir@ietf.org" , "iesg@ietf.org" , "taps@ietf.org" To: Magnus Westerlund References: <158642650492.8627.16111048765603393250@ietfa.amsl.com> <33e2fe4c9f68ee3fea18ed7109f210ea9374e1d8.camel@ericsson.com> <894AC91E-8128-42F0-8E6B-1A66EF84CF43@cisco.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-13_08:2020-04-13, 2020-04-13 signatures=0 Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-taps?= =?utf-8?q?-transport-security-11=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 17:29:52 -0000 --Apple-Mail=_B0242775-78B5-46FC-805E-0253D181A132 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 9, 2020, at 7:58 AM, Magnus Westerlund = wrote: >=20 > Hi, > =20 > Eric and I have discussed this and the proposal is a clarifying change = to the initial statement in Section 3: > =20 > OLD: > =20 > This section contains brief descriptions of the various security > protocols currently used to protect data being sent over a network. > =20 > NEW:=20 > =20 > This section contains brief transport and security descriptions of = the various security > protocols currently used to protect data being sent over a network. > =20 > The purpose of this change to clarify that these descriptions are only = concerning relevant aspects of transport and security.=20 > =20 > Are the WG and authors ok with the above change?=20 That change sounds fine to me, as an author. We=E2=80=99ll incorporate = that in our update. Best, Tommy > =20 > Cheers > =20 > Magnus > =20 > =20 > From: iesg On Behalf Of Kyle Rose > Sent: den 9 april 2020 16:01 > To: Barry Leiba > Cc: Eric Vyncke (evyncke) ; = brian@innovationslab.net; philipp@tiesel.net; Mohit Sethi M = ; taps-chairs@ietf.org; = draft-ietf-taps-transport-security@ietf.org; int-dir@ietf.org; = iesg@ietf.org; taps@ietf.org; Magnus Westerlund = ; caw@heapingbits.net > Subject: Re: =C3=89ric Vyncke's Discuss on = draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) > =20 > Agreed. This document is not an endorsement of any of the protocols = mentioned, merely an analysis from a security perspective. Mentioning = IPv6 here would be a non-sequitur. > =20 > =20 > On Thu, Apr 9, 2020 at 9:46 AM Barry Leiba > wrote: > I have to agree with Magnus here: I think this is really a stretch. >=20 > Barry >=20 > On Thu, Apr 9, 2020 at 9:40 AM Eric Vyncke (evyncke) > > wrote: > > > > Magnus, > > > > While my comment is not directed to the core of the document, I = believe that when one IETF document refers in the section 3, ' Transport = Security Protocol Descriptions', to non-IETF protocols, then in order to = avoid any 'IETF blessing' of this protocol, it should clearly state the = important protocol limitations when describing this protocol. > > > > Regards > > > > -=C3=A9ric > > > > =EF=BB=BF-----Original Message----- > > From: iesg > on = behalf of Magnus Westerlund = > > > Date: Thursday, 9 April 2020 at 14:41 > > To: "evyncke=3D40cisco.com@dmarc.ietf.org = " >, "iesg@ietf.org = " > > > Cc: "brian@innovationslab.net " = >, = "int-dir@ietf.org " >, Mohit Sethi M >, "taps-chairs@ietf.org = " >, = "draft-ietf-taps-transport-security@ietf.org = " = >, = "philipp@tiesel.net " >, "caw@heapingbits.net = " >, "taps@ietf.org " = > > > Subject: RE: =C3=89ric Vyncke's Discuss on = draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT) > > > > > > > > A simple mention of the lack of IPv6 in section 3 of the = description would > > > be > > > more than enough for me. > > > > Yes, but why do you consider that relevant for this document? > > > > Cheers > > > > Magnus > > > > > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Apple-Mail=_B0242775-78B5-46FC-805E-0253D181A132 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 9, 2020, at 7:58 AM, Magnus Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> = wrote:

Hi,
 
Eric = and I have discussed this and the proposal is a clarifying change to the = initial statement in Section 3:
 
OLD:
 
   = This section contains brief descriptions of the various security
   protocols currently used to protect = data being sent over a network.
 
NEW: 
 
   This section contains brief transport and =
security descriptions of the various security
   protocols currently used to =
protect data being sent over a network.
 
The = purpose of this change to clarify that these descriptions are only = concerning relevant aspects of transport and security. 
 
Are the = WG and authors ok with the above change? 

That change sounds fine to me, as an = author. We=E2=80=99ll incorporate that in our update.

Best,
Tommy
 
Cheers
 
Magnus
 
 
From: iesg = <iesg-bounces@ietf.org> On Behalf = Of Kyle Rose
Sent: den 9 april 2020 16:01
To: Barry Leiba <barryleiba@computer.org>
Cc: Eric = Vyncke (evyncke) <evyncke=3D40cisco.com@dmarc.ietf.org>; brian@innovationslab.net; philipp@tiesel.net; = Mohit Sethi M <mohit.m.sethi@ericsson.com>; taps-chairs@ietf.org; = draft-ietf-taps-transport-security@ietf.org; int-dir@ietf.org; iesg@ietf.org; taps@ietf.org; Magnus = Westerlund <magnus.westerlund=3D40ericsson.com@dmarc.ietf.org>; caw@heapingbits.net
Subject: Re: =C3=89ric Vyncke's = Discuss on draft-ietf-taps-transport-security-11: (with DISCUSS and = COMMENT)
 
Agreed. This document is not an = endorsement of any of the protocols mentioned, merely an analysis from a = security perspective. Mentioning IPv6 here would be a non-sequitur.
 
 
On Thu, Apr 9, 2020 at = 9:46 AM Barry Leiba <barryleiba@computer.org> wrote:
I have to agree with = Magnus here: I think this is really a stretch.

Barry

On Thu, Apr 9, 2020 at = 9:40 AM Eric Vyncke (evyncke)
<evyncke=3D40cisco.com@dmarc.ietf.org> wrote:
>> Magnus,
>
> While my = comment is not directed to the core of the document, I believe that when = one IETF document refers in the section 3, ' Transport Security Protocol = Descriptions', to non-IETF protocols, then in order to avoid any 'IETF = blessing' of this protocol, it should clearly state the important = protocol limitations when describing this protocol.
>
> Regards
>
> -=C3=A9ric>
> =EF=BB=BF-----Original = Message-----
> From: iesg <iesg-bounces@ietf.org> on behalf of Magnus Westerlund = <magnus..westerlund=3D40ericsson.com@dmarc.ietf.org>
> = Date: Thursday, 9 April 2020 at 14:41
> To: "evyncke=3D40cisco.com@dmarc.ietf.org" <evyncke=3D40cisco.com@dmarc.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
> Cc: "brian@innovationslab.net" <brian@innovationslab.net>, "int-dir@ietf.org" = <int-dir@ietf.org>, = Mohit Sethi M <mohit.m.sethi@ericsson.com>, "taps-chairs@ietf.org" = <taps-chairs@ietf.org>, "draft-ietf-taps-transport-security@ietf.org" <draft-ietf-taps-transport-security@ietf.org>, "philipp@tiesel.net" = <philipp@tiesel.net>, "caw@heapingbits.net" = <caw@heapingbits.net>, "taps@ietf.org" <taps@ietf.org>
> Subject: RE: =C3=89ric= Vyncke's Discuss on draft-ietf-taps-transport-security-11: (with = DISCUSS and COMMENT)
>
>    =  >
>     > A simple mention = of the lack of IPv6 in section 3 of the description would
>     > be
>  =    > more than enough for me.
>
>     Yes, but why do you consider that = relevant for this document?
>
>  =    Cheers
>
>    =  Magnus
>
>
>
>
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_B0242775-78B5-46FC-805E-0253D181A132-- From nobody Wed Apr 15 08:49:49 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE43A0B1C; Wed, 15 Apr 2020 08:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158696570597.6243.17363184130849112053@ietfa.amsl.com> Reply-To: Paul Wouters Date: Wed, 15 Apr 2020 08:48:26 -0700 Archived-At: Subject: [Taps] Secdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 15:48:26 -0000 Reviewer: Paul Wouters Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Has Nits Compared to my last review (-09) a lot of text has been removed, reducing the technical details and giving a briefer (but arguably cleaner) overview. I do still have a personal preference of dropping CurveCP and MinimalT as I don't really think these are anything but abandoned research items. I have never seen or heard of these being deployed. I would be more tempted to list openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite some deployment. If the intent is really to show different kind of API's, than there are other esoteric examples that could be included, such as Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but with the ability to generate session keys for encrypted bulk transport (eg for video/audio or file transfer) Section 5.1 "Session Cache Management (CM):" which does not include IKEv2/IPsec, even though it does have session resumption (RFC 5723). I guess this is because the section limits itself to "the application" that can restart the session. But for IKEv2/IPsec the same could be said. An application that after a long idle period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 session resumption. WireGuard does not have this capability as there are no API/hooks for packet trigger tunnel events (AFAIK) "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support PSK based authentication - only public key based authentication. While I understand the IKEv2 entry (PSKs are used for authentication of peers), I am not sure the ESP entry should be here. ESP does not "authenticate peers", unless you call "being able to decrypt and authenticate packets" as an instance of "authenticating peer" Section 5.2 This states "This can call into the application to offload validation.". This "can" is only not supported by WireGuard, as all of this is happening inside the kernel. Maybe a note could be useful here? "Source Address Validation" - It is a little unclear why TCP based protocols are not listed here. They (implicitly) do source address validation. Perhaps the introduction in this paragraph can state this more explicitly. Eg "for those protocols that do not use TCP and therefor do not have builtin source address validation ......." From nobody Wed Apr 15 15:44:00 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0C3A0D23 for ; Wed, 15 Apr 2020 15:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=apple.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 lzHrQc1Uu6DZ for ; Wed, 15 Apr 2020 15:43:51 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 DD6783A0CA8 for ; Wed, 15 Apr 2020 15:43:43 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 03FMfprp053499; Wed, 15 Apr 2020 15:43:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=TftxfL1eqenRMhaetJULJB4Z0yNr18Tnfn8UAK/xl+s=; b=MmaHywoWzUM/Zx0to6jgIlZfeRjmfEZtDIVYckO7oZj4eIR9rgcMQj1lZJyYGwp27yNo 7ouTCJsu3XbZAc6bP9rQ84kbOhXRMpldO94M/hg9QsR+AJNH2+/9/5ZM+jJzhMn7pJF7 /eRw12Ein4Dfd5eT2J2nvZHsKAUU2AcVkaGqbfBGGpDki4OtSFV98KSZ/+Z/zGcpNry4 thQMWunIQyLM2h4Zbe5LCMCc1ymP2RKrSq7aFN1vrXcPPDCxIsiMB2I28/rPwxEQFkka 1f9mR1nl3VjtTkWWwBNsk3NlLLHKOLV06BSXCqJMzcVgc+2wv4whBNmLKCgf4zrWh4xs 1w== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 30dn6emwwf-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Apr 2020 15:43:39 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q8U00EO1PSQ2640@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 15 Apr 2020 15:43:38 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q8U00M00P60LI00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 15 Apr 2020 15:43:38 -0700 (PDT) X-Va-A: X-Va-T-CD: 09b2ff12df31caba240a5392fcddf7c6 X-Va-E-CD: f400dc8286809dcb395c58ac21bd189b X-Va-R-CD: 14640eaf818470e267c77a585b5c7ca0 X-Va-CD: 0 X-Va-ID: 5a129424-7770-4fdb-9697-d697a4bc71ba X-V-A: X-V-T-CD: 09b2ff12df31caba240a5392fcddf7c6 X-V-E-CD: f400dc8286809dcb395c58ac21bd189b X-V-R-CD: 14640eaf818470e267c77a585b5c7ca0 X-V-CD: 0 X-V-ID: 048958d7-4529-42a2-99e4-34419bc11cd8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-15_08:2020-04-14, 2020-04-15 signatures=0 Received: from [17.232.172.243] (unknown [17.232.172.243]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q8U00QJ4PSNWM00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 15 Apr 2020 15:43:38 -0700 (PDT) From: Tommy Pauly Message-id: <0EAF19EA-DBFF-4F7A-AEBF-55B11DA9AE45@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_834A041F-4F80-45D3-A2D0-02EEFBFFD59B" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 15 Apr 2020 15:43:35 -0700 In-reply-to: Cc: "taps@ietf.org" , Magnus Westerlund , Zaheduzzaman Sarker To: Aaron Falk References: <18805F34-42FE-42D8-AE3D-5D9AE2111A9A@gmail.com> <81D5CFCB-634F-41E0-AC22-D7BAFCC34D33@gmail.com> <7cfeb3b3682826b7cbc0033d4bf691808f8e9bd2.camel@ericsson.com> <350953BF-B45A-49EF-9AAD-369A6347A04B@gmail.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-15_08:2020-04-14, 2020-04-15 signatures=0 Archived-At: Subject: Re: [Taps] TAPS April Interim Scheduling X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2020 22:43:59 -0000 --Apple-Mail=_834A041F-4F80-45D3-A2D0-02EEFBFFD59B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Aaron, I=E2=80=99d like to add one topic to the agenda (which seems pretty open = at this point, mainly being issue review), specifically on handling = Multicast and Multiplexing with Connection Groups. We=E2=80=99ve recognized that our text in the TAPS specs around = multicast has been lacking for a while, and as I've been working on = better implementation support for multicast, I think there are some = concrete additions we can make to the API that would improve things.=20 Could we use 15 minutes on this? Thanks, Tommy > On Mar 24, 2020, at 8:33 AM, Aaron Falk wrote: >=20 > OK, let=E2=80=99s do the meeting at the time described below (April = 17, 1600 UTC). I=E2=80=99m attaching an .ics file for those with fancy = calendars. :) Agenda to come. >=20 > --aaron >=20 --Apple-Mail=_834A041F-4F80-45D3-A2D0-02EEFBFFD59B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Aaron,

I=E2=80=99d = like to add one topic to the agenda (which seems pretty open at this = point, mainly being issue review), specifically on handling Multicast = and Multiplexing with Connection Groups.

We=E2=80=99ve recognized that our text = in the TAPS specs around multicast has been lacking for a while, and as = I've been working on better implementation support for multicast, I = think there are some concrete additions we can make to the API that = would improve things. 

Could we use 15 minutes on this?

Thanks,
Tommy

On Mar 24, 2020, at 8:33 AM, = Aaron Falk <aaron.falk@gmail.com> wrote:

OK, = let=E2=80=99s do the meeting at the time described below (April 17, 1600 = UTC).  I=E2=80=99m attaching an .ics file for those with fancy = calendars. :)  Agenda to come.

--aaron


= --Apple-Mail=_834A041F-4F80-45D3-A2D0-02EEFBFFD59B-- From nobody Thu Apr 16 03:35:47 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D303A141F; Thu, 16 Apr 2020 03:35:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares via Datatracker To: Cc: last-call@ietf.org, taps@ietf.org, draft-ietf-taps-transport-security.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158703333468.25896.8984664151253035199@ietfa.amsl.com> Reply-To: Susan Hares Date: Thu, 16 Apr 2020 03:35:34 -0700 Archived-At: Subject: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 10:35:42 -0000 Reviewer: Susan Hares Review result: Ready Greetings: This is an ops-dir review that looks at the operational aspects of any draft. Overall: Thank you for a clear and well-written document. This draft is well written and clear. One minor editorial nitty-nit. One personal plea from the IDR co-chair(WG that maintains BGP), and co-author of BGP (RFC4771). Personal plea: You've clear stated the BGP issue up front. TCP MD5 is bad (due to privacy issues) and TCP-AO is not deployed.. Has the TAPs given any thought to what might be a replacement that could utilize some of the modern TCP. Would any of your co-authors be willing to chat about this issue? The very minor editorial nitty-nit. Would you please check the order of the items in the pre-shared key import (PSKI) [p. 13-14] to see that it is the same order as the table. From nobody Thu Apr 16 08:31:43 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4543A0BB9; Thu, 16 Apr 2020 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 EZlOxeq33Wzh; Thu, 16 Apr 2020 08:31:37 -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 6194B3A0BB7; Thu, 16 Apr 2020 08:31:37 -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=1e7JGrXPwB5J70Y82HlPOu4TE352wTeb0jJ/bbZv5eY=; b=SfvTabxf8XlY4cZiA9RG72Z8f Zyt8YxdRz0OOQJ5BDYtPSiZwDdUbjghLoG1M0w4DFySMA+ULU+0WEP7m6pj5vTAI6+0SrVAslq49C 2VaKfGdwvRPAaIsO8wolfz8OqW2R0yYD3AMvOZP+1JLkFibH4jyNoDK9epV9oDHAUF3TjQbi7uOBb ibvFrt9mIvXgQGOdD+Mw72W4DHSkmyM91Vj4hnEJpxcCY/kBZlydFWihQxOdKKR6tgHyPBX6LRJc0 okC0Rlnxv3424b2HMXVVdSK/5Iy9yUT85o6pGfVophZrBHFf7TnDGFgrrWSOT6yL4vTYS7PW+9pM3 5NIiYzT9w==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64195 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jP6UF-003muF-37; Thu, 16 Apr 2020 11:31:35 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Joseph Touch In-Reply-To: <158703333468.25896.8984664151253035199@ietfa.amsl.com> Date: Thu, 16 Apr 2020 08:31:30 -0700 Cc: ops-dir@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> References: <158703333468.25896.8984664151253035199@ietfa.amsl.com> To: Susan Hares X-Mailer: Apple Mail (2.3608.60.0.2.5) X-OutGoing-Spam-Status: No, score=-0.5 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: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 15:31:40 -0000 Hi, Susan, > On Apr 16, 2020, at 3:35 AM, Susan Hares via Datatracker = wrote: >=20 > Reviewer: Susan Hares > ... > Personal plea:=20 > You've clear stated the BGP issue up front.=20 > TCP MD5 is bad (due to privacy issues) and TCP-AO=20 > is not deployed.. It is available in Cisco IOS at least. Its biggest drawback appears to = be a lack of open-source implementations. > Has the TAPs given any thought to=20 > what might be a replacement that could utilize some of the modern=20 > TCP. =20 Given the problem with TCP-AO deployment is that there is no free = implementation and low implementation by vendors, how exactly would a = new solution with even less implemented code help? Joe= From nobody Thu Apr 16 09:25:53 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EDE3A0D86; Thu, 16 Apr 2020 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 T_kPsShA9vCW; Thu, 16 Apr 2020 09:25:32 -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 589AB3A0DC8; Thu, 16 Apr 2020 09:18:36 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 6318525A12; Thu, 16 Apr 2020 18:18:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1587053914; bh=LNCpqJ8w8Qt470tW2PYDJ5RL6iF/57l8c0I4bXFK/rg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ufMzuKf9V8vUDjmrRKfOhgKz2ssmIxy4dcocYJZ3zn4t6n/QvhhNjcVWraJNlklZW IGYrpaYELsZjI843f+5Im2WPzBPlJq10fLbvvisvEdNscIEFgd4oa9Fn8r101Vzopd Z6X141VtbRejJeltCRxc6T8/w8KQVbp98Ceb0QZ8= 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 vA-MZ4SPFLM4; Thu, 16 Apr 2020 18:18:32 +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; Thu, 16 Apr 2020 18:18:32 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.209]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 16 Apr 2020 18:18:32 +0200 From: "Scharf, Michael" To: Joseph Touch , Susan Hares CC: "last-call@ietf.org" , "ops-dir@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" , "taps@ietf.org" Thread-Topic: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 Thread-Index: AQHWFAQoq8z0cso+UkeJRH+eZgOe7Kh76cgQ Date: Thu, 16 Apr 2020 16:18:32 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DA73BD7@rznt8114.rznt.rzdir.fht-esslingen.de> References: <158703333468.25896.8984664151253035199@ietfa.amsl.com> <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> In-Reply-To: <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:25:35 -0000 > Hi, Susan, >=20 > > On Apr 16, 2020, at 3:35 AM, Susan Hares via Datatracker > wrote: > > > > Reviewer: Susan Hares > > ... > > Personal plea: > > You've clear stated the BGP issue up front. > > TCP MD5 is bad (due to privacy issues) and TCP-AO > > is not deployed.. >=20 > It is available in Cisco IOS at least. Its biggest drawback appears to be= a lack of > open-source implementations. According to reference [1], Nokia SROS implements TCP-AO as well. As far as= I can see, RFC 5925 and RFC 5926 are explicitly listed as supported in [1]= . So, apparently two major router vendors have running code for TCP-AO. But this seems really off-topic for draft-ietf-taps-transport-security. Michael [1] Nokia SROS documentation at https://documentation.nokia.com/cgi-bin/dba= ccessfilename.cgi/3HE15811AAAATQZZA01_V1_7450%20ESS%207750%20SR%207950%20XR= S%20and%20VSR%20Basic%20System%20Configuration%20Guide%2020.2.R1.pdf > > Has the TAPs given any thought to > > what might be a replacement that could utilize some of the modern > > TCP. >=20 > Given the problem with TCP-AO deployment is that there is no free > implementation and low implementation by vendors, how exactly would a new > solution with even less implemented code help? >=20 > Joe > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Apr 16 09:39:11 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF62F3A0E53 for ; Thu, 16 Apr 2020 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=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 12koVlrXSLsp for ; Thu, 16 Apr 2020 09:39:08 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 8A4543A0E4B for ; Thu, 16 Apr 2020 09:39:08 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id t11so1894761pgg.2 for ; Thu, 16 Apr 2020 09:39:08 -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=r4zq2r/bYhrUpC1k0Uq0LtreEzCGZY1w/GvNu7gQq/4=; b=pD3xhlo84ktzRTwCxfEbzXJqVDjBusR1BibKuNcjRrZZxCv9G1VFjqP+jTRaxdwZwq V1oaJROxQt73N6P6R65SfNBJG/pzynFaG6feiZYO7NCSPJmc/H+WzUN56wnNfHNVuS+m acEaYhjTjBam69sRfVQBchW+4SdObh5sCcstldTh8epX1aV7e1YM87UEWIjzFpq+KT2I eh5yQFaW9uUmCpxfLuRZM1TO3YtmgKdRdLU1CwRoJkJkYQlS+ni49tkvcSWmQ/ijHkfO d94ZE5v89P7jKGJWLVyfDlEQr89H2cuJY9sE1Gfom90x8UxsS1ikSW4/+ZpaCnbye2+z 5Biw== 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=r4zq2r/bYhrUpC1k0Uq0LtreEzCGZY1w/GvNu7gQq/4=; b=k1BJmrIQLa1KheGkrzRg6lJ0+0Ny9zGbcd8owmjj+fdHr1A/t+AQYpJKAe2hez8lOi SewnzGUYvGhrj1Ie9v76bnbeW/UDx2IzcjZfw3msICR0iEW/my/XqDOre6M6z+hHi+DS +33Aomrfch9wnAje6wOClT1UDwqAnJxo4IvMxHTVEi+KIvb0bVxl+rQoYMgLBnTFLwGI tKzX/vqpFKSxI5WirjNOXvTMxAc5wOYin6URrt3vFkaxJjXrJ8HKcFe5e4zEbjiBHkAc oMojrxjzcnjdehPDUt1qz+TFktxyN3XCRHatOZN8KLLnM2o1FbK5YEU/lSoDs2R9kTaf I8kg== X-Gm-Message-State: AGi0PuZr4PTvkMzw8TvjFK9qWfs62MaXOOWudfzpJQYr0pVn9h0VxAmj WK1YQc8+3vQl2evNbXLgOdWK6RRiVm7p429yJ0Y= X-Google-Smtp-Source: APiQypIBuVRtrUamH+FcOBWqChEBYyVp5qR4uSYrGoVCsrhhdJ8F5i/WB7mUGVFjaO+TkyjBaFpjBpPhpvkNCQYpUTc= X-Received: by 2002:a63:d904:: with SMTP id r4mr32654020pgg.323.1587055147821; Thu, 16 Apr 2020 09:39:07 -0700 (PDT) MIME-Version: 1.0 References: <18805F34-42FE-42D8-AE3D-5D9AE2111A9A@gmail.com> <81D5CFCB-634F-41E0-AC22-D7BAFCC34D33@gmail.com> <7cfeb3b3682826b7cbc0033d4bf691808f8e9bd2.camel@ericsson.com> <350953BF-B45A-49EF-9AAD-369A6347A04B@gmail.com> <0EAF19EA-DBFF-4F7A-AEBF-55B11DA9AE45@apple.com> In-Reply-To: <0EAF19EA-DBFF-4F7A-AEBF-55B11DA9AE45@apple.com> From: Aaron Falk Date: Thu, 16 Apr 2020 12:38:56 -0400 Message-ID: To: Tommy Pauly Cc: "taps@ietf.org" , Magnus Westerlund , Zaheduzzaman Sarker Content-Type: multipart/alternative; boundary="00000000000053315305a36b12dc" Archived-At: Subject: Re: [Taps] TAPS April Interim Scheduling X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:39:10 -0000 --00000000000053315305a36b12dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, no problem. On Wed, Apr 15, 2020 at 6:43 PM Tommy Pauly wrote: > Hi Aaron, > > I=E2=80=99d like to add one topic to the agenda (which seems pretty open = at this > point, mainly being issue review), specifically on handling Multicast and > Multiplexing with Connection Groups. > > We=E2=80=99ve recognized that our text in the TAPS specs around multicast= has been > lacking for a while, and as I've been working on better implementation > support for multicast, I think there are some concrete additions we can > make to the API that would improve things. > > Could we use 15 minutes on this? > > Thanks, > Tommy > > On Mar 24, 2020, at 8:33 AM, Aaron Falk wrote: > > OK, let=E2=80=99s do the meeting at the time described below (April 17, 1= 600 > UTC). I=E2=80=99m attaching an .ics file for those with fancy calendars.= :) > Agenda to come. > > --aaron > > > --00000000000053315305a36b12dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, no problem.=C2=A0

On Wed, Apr 15, 2020 at 6:43 PM= Tommy Pauly <tpauly@apple.com&g= t; wrote:
Hi Aaron,

I=E2=80=99= d like to add one topic to the agenda (which seems pretty open at this poin= t, mainly being issue review), specifically on handling Multicast and Multi= plexing with Connection Groups.

We=E2=80=99ve reco= gnized that our text in the TAPS specs around multicast has been lacking fo= r a while, and as I've been working on better implementation support fo= r multicast, I think there are some concrete additions we can make to the A= PI that would improve things.=C2=A0

Could we use 1= 5 minutes on this?

Thanks,
Tommy

On Mar 24, 2020, at 8:33 AM, Aar= on Falk <aaron= .falk@gmail.com> wrote:

OK, let=E2=80=99s do the meeting at the time described below (April 17, = 1600 UTC).=C2=A0 I=E2=80=99m attaching an .ics file for those with fancy ca= lendars. :) =C2=A0Agenda to come.

--aaron


--00000000000053315305a36b12dc-- From nobody Thu Apr 16 09:56:32 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF803A0EC3; Thu, 16 Apr 2020 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 SyMXdPw9PCq2; Thu, 16 Apr 2020 09:56:21 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 35BE83A112B; Thu, 16 Apr 2020 09:55:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Joseph Touch'" Cc: , , , References: <158703333468.25896.8984664151253035199@ietfa.amsl.com> <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> In-Reply-To: <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> Date: Thu, 16 Apr 2020 12:55:29 -0400 Message-ID: <009001d6140f$d6346030$829d2090$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQCxyBZWHy51XSpfJdx0FkoOJmBzXgIi2NOyqrN2NJA= X-Antivirus: AVG (VPS 200415-0, 04/15/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 16:56:27 -0000 Joe: I have come to the same conclusion that an open-source TCP-AO is the next step for TCP-AO. I still hoping for some fairy dust ... to fix the BGP TCP security problem. If you have any ... let me know Susan Hares -----Original Message----- From: Joseph Touch [mailto:touch@strayalpha.com] Sent: Thursday, April 16, 2020 11:32 AM To: Susan Hares Cc: ops-dir@ietf.org; last-call@ietf.org; draft-ietf-taps-transport-security.all@ietf.org; taps@ietf.org Subject: Re: [Taps] Opsdir telechat review of draft-ietf-taps-transport-security-11 Hi, Susan, > On Apr 16, 2020, at 3:35 AM, Susan Hares via Datatracker wrote: > > Reviewer: Susan Hares > ... > Personal plea: > You've clear stated the BGP issue up front. > TCP MD5 is bad (due to privacy issues) and TCP-AO is not deployed.. It is available in Cisco IOS at least. Its biggest drawback appears to be a lack of open-source implementations. > Has the TAPs given any thought to > what might be a replacement that could utilize some of the modern > TCP. Given the problem with TCP-AO deployment is that there is no free implementation and low implementation by vendors, how exactly would a new solution with even less implemented code help? Joe From nobody Thu Apr 16 10:11:09 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663C3A0416; Thu, 16 Apr 2020 10:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 6Bs_Hrm0TzAM; Thu, 16 Apr 2020 10:10:58 -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 D0BB33A0415; Thu, 16 Apr 2020 10:10:57 -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=Box8w5KT1AhSycNPBPz6AEgkGQDuK38Di765EOjE+Hs=; b=QradY/zOGHbnpZKAaXXHbTmc7 GfnqM6C6R+2ngLIlUW7URsARH64/ApELeF7LOzIeaq8YRb7Ae1irVro2pdZfO36WCdT1Msrjgy4jP 0q7ZSl1IFsoC/d/lLeYGvhExOQQV9SAklqhW/SmKO6m0TkS6QpLXEljaZK45D0jEskHuDt8P0VpsG 1CQ0cEv0AhHTGPBfnhoLEqDxryvh+6eBfbx8ol2DNlajl4gHlmnAGgohXQgCkM9ZkxGDj+eXez6Pl Vp/LJHVKcK3/KQHvjjXOU3+Qzt4l90BMlyg3qMAvoAQNlFMT1lGdCrUMpUjp0GzM6ehAtNrpVGJJv CKtnzQcOA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64738 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jP82P-001ObZ-JW; Thu, 16 Apr 2020 13:10:57 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Joseph Touch In-Reply-To: <009001d6140f$d6346030$829d2090$@ndzh.com> Date: Thu, 16 Apr 2020 10:10:52 -0700 Cc: last-call@ietf.org, ops-dir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158703333468.25896.8984664151253035199@ietfa.amsl.com> <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> <009001d6140f$d6346030$829d2090$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3608.60.0.2.5) X-OutGoing-Spam-Status: No, score=-0.5 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: [Taps] [Last-Call] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:11:00 -0000 > On Apr 16, 2020, at 9:55 AM, Susan Hares wrote: >=20 > Joe:=20 >=20 > I have come to the same conclusion that an open-source TCP-AO is the = next > step for TCP-AO. >=20 > I still hoping for some fairy dust ... to fix the BGP TCP security = problem.=20 > If you have any ... let me know=20 We have a fix for the security problem. What we lack is a fix for the = freeloader problem.=20 Other than declaring TCP MD5 a hazard and actively abandoning it, = there=E2=80=99s too much of a fallback. One step might be for the IETF to prohibit support for TCP MD5 in all = new work - e.g., there=E2=80=99s pending work in TCPM to develop a YANG = model that includes MD5 =E2=80=9Cfor legacy support=E2=80=9D, but that = only serves to feed the problem.=20 But a new solution isn=E2=80=99t going to make freeloading easier. Joe From nobody Thu Apr 16 10:19:33 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FDE3A0799; Thu, 16 Apr 2020 10:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1adxoHIHg_Kc; Thu, 16 Apr 2020 10:19:26 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 BDF3F3A077C; Thu, 16 Apr 2020 10:19:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.170.25.188; From: "Susan Hares" To: "'Joseph Touch'" Cc: , , , References: <158703333468.25896.8984664151253035199@ietfa.amsl.com> <87F84D2D-ED5D-445A-ABA3-416AD0F3F9BD@strayalpha.com> <009001d6140f$d6346030$829d2090$@ndzh.com> In-Reply-To: Date: Thu, 16 Apr 2020 13:19:10 -0400 Message-ID: <000001d61413$252f7690$6f8e63b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCxyBZWHy51XSpfJdx0FkoOJmBzXgIi2NOyAi72vOsBl8uUNqqVSADg Content-Language: en-us X-Antivirus: AVG (VPS 200415-0, 04/15/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Taps] [Last-Call] Opsdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 17:19:28 -0000 +1 --- unfortunately for the social engineering on TCP-MD5 Freeloading does not having impeding crisis=20 requiring BGP peer to have social distance from non-secure = peer.=20 (smile)=20 Sue -----Original Message----- From: Joseph Touch [mailto:touch@strayalpha.com]=20 Sent: Thursday, April 16, 2020 1:11 PM To: Susan Hares Cc: last-call@ietf.org; ops-dir@ietf.org; = draft-ietf-taps-transport-security.all@ietf.org; taps@ietf.org Subject: Re: [Last-Call] [Taps] Opsdir telechat review of = draft-ietf-taps-transport-security-11 > On Apr 16, 2020, at 9:55 AM, Susan Hares wrote: >=20 > Joe:=20 >=20 > I have come to the same conclusion that an open-source TCP-AO is the=20 > next step for TCP-AO. >=20 > I still hoping for some fairy dust ... to fix the BGP TCP security = problem.=20 > If you have any ... let me know We have a fix for the security problem. What we lack is a fix for the = freeloader problem.=20 Other than declaring TCP MD5 a hazard and actively abandoning it, = there=E2=80=99s too much of a fallback. One step might be for the IETF to prohibit support for TCP MD5 in all = new work - e.g., there=E2=80=99s pending work in TCPM to develop a YANG = model that includes MD5 =E2=80=9Cfor legacy support=E2=80=9D, but that = only serves to feed the problem.=20 But a new solution isn=E2=80=99t going to make freeloading easier. Joe From nobody Thu Apr 16 11:23:20 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488BA3A0AEA for ; Thu, 16 Apr 2020 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 RgLFpPZppJ0j for ; Thu, 16 Apr 2020 11:23:14 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 DEB993A0ADE for ; Thu, 16 Apr 2020 11:23:13 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id 03GIMgX3022890; Thu, 16 Apr 2020 11:23:08 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=zzkMxD76l39u7ppsGlkVnsT86QlOinReK8eXvxLbjXY=; b=XpG0MSgrvl7bBcxU8FOl//vpU5Vp4V79RnljWc/8Et/9Be7WJKF8CMo0zZ1DtT6ILorg VIviMugYyFAenykt0PHld9l5qa/+lpgYqwIopXB2kEYhh51iID5zvwa2Epeo2Uel/G2+ wu1ZdB1z61FpqdttfptnVqjMgVgGK1DzC/ZGUEAqRM0AXgC6kSfH+jlojQy8pVXfLKyI ZzK3heKtGcQ6mYNP/LHycfhA9CzWboK111hEU7YqYAHNLjV2nNc2CZdu/MUCyG1J4eIe nYZQ0B7y0XswzrO9Mfh5w+FWLtZQ//Vk2fKDfDqGs9XLMrvpF8YtM9AQB064tAQ/86fR 8Q== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 30dn6fx535-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Apr 2020 11:23:08 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q8W005578EJRL50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 16 Apr 2020 11:23:07 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q8W00Z005XNSE00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 16 Apr 2020 11:23:07 -0700 (PDT) X-Va-A: X-Va-T-CD: 3b5b0545e8f79774acacb730c166ee3f X-Va-E-CD: 98e3b477d67032cbc648418bb83c025c X-Va-R-CD: 0509383821a74218a8b47012d2a1a8fa X-Va-CD: 0 X-Va-ID: d50b35fe-6819-4604-94e3-0258be993a55 X-V-A: X-V-T-CD: 3b5b0545e8f79774acacb730c166ee3f X-V-E-CD: 98e3b477d67032cbc648418bb83c025c X-V-R-CD: 0509383821a74218a8b47012d2a1a8fa X-V-CD: 0 X-V-ID: 74c8db49-f9e6-45d1-b8f0-7456504df6e3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-16_07:2020-04-14, 2020-04-16 signatures=0 Received: from [17.235.18.165] (unknown [17.235.18.165]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q8W00NOL8EEXJ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 16 Apr 2020 11:23:05 -0700 (PDT) From: Tommy Pauly Message-id: <757E3076-49D3-4C0C-BAFD-65A2D4981D82@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_65AA1496-CCEC-4249-A4B3-1FC718EF31E7" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Thu, 16 Apr 2020 11:23:02 -0700 In-reply-to: <7b6f1f49-5594-da76-bbc0-c1352323889e@erg.abdn.ac.uk> Cc: Aaron Falk , taps WG To: Gorry Fairhurst References: <7b6f1f49-5594-da76-bbc0-c1352323889e@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-16_08:2020-04-14, 2020-04-16 signatures=0 Archived-At: Subject: Re: [Taps] April interim: - My promised review of normative arch language (derived from github). X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2020 18:23:19 -0000 --Apple-Mail=_65AA1496-CCEC-4249-A4B3-1FC718EF31E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for these details, Gorry! I finally got around to making this PR. Please take a look, and we=E2=80=99= ll discuss tomorrow: https://github.com/ietf-tapswg/api-drafts/pull/564 = Best, Tommy > On Mar 25, 2020, at 9:02 AM, Gorry Fairhurst = wrote: >=20 > As promised, >=20 > I did a review of the arch draft and the PR that was recently done. = There were comments that requested to remove some normative language = that has been implemented in the current draft - where my review agreed, = I have not commented further below. However, the latest revision, also = did not retain the discussion of what I suggested should be normative. I = have worked through the various comments in github and summarise them = here (since these comments are now burried in the git, see 502 et al). >=20 > So here goes: >=20 > Overall review: I think we need to keep the normative language for the = key features that differentiate the API. I'd really like to use = REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not = protocol operation requirements, but are implementation requirements to = conform. This includes requirements based on Minset - where the WG = dervied this API: This is after all why the WG worked on Minset as the = basis of the API. >=20 > ---- >=20 > The following are key requirements, that define the TAPS architecture: >=20 > * It is RECOMMENDED that functionality that is common across multiple = transport protocols is made accessible through a unified set of TAPS = interface calls. As a baseline, a Transport Services API is = RECOMMENDED/REQUIRED to allow access to the minimal set of features = offered by transport protocols {{?I-D.ietf-taps-minset}}. >=20 > * TAPS automates the selection of protocols and features, based on a = set of Properties supplied through the TAPS interface. It is RECOMMENDED = that a TAPS system offers Properties that are common to multiple = transport protocols. Specifying common Properties enables a system to = appropriately select between protocols that offer equivalent features. = This design permits evolution of the transport protocols and functions = without affecting the programs using the system. >=20 > * Applications using the TAPS API are REQUIRED to be robust to the = automated selection provided by TAPS, including the possibility to = express requirements and preferences that constrain the choices that can = be made by the system. In normal use, TAPS Systems are RECOMMENDED to = be designed so that all selection decisions result in consistent choices = for the same network conditions when they have the same set of = preferences. This is intended to provide predictable outcomes to the = application using the transport service. >=20 > * Applications using TAPS MAY explicitly require or prevent the use of = specific transport features (and transport protocols) using the = "REQUIRED" and "PROHIBIT" preferences. This allows an application to = constrain the set of protocols and features that will be selected for = the transport service. It is RECOMMENDED that the default usage by = applications does not unecessarily restrict this selection, so that the = system can make informed choices (e.g., based on the availability of = interfaces or set of transport protocols available for the specified = remote endpoint). >=20 >=20 > --- >=20 > After thought, here is my specific poposal of what to do next: >=20 > (a) I suggest we group all the requirements on architecture as short = one or two sentence blocks (preferably as a bullet or definition list) = collected into a single subsection, so they are easy to find and read = and we say that these are the key architectural requirements. I suggest = we insert this new requirements text either their own section, or in = section 1.3 (although I am open to other places where we can call-out = the architectural requirements). >=20 > (b) We need to decide if these are architectural requirements and if = there are more or less in total. I am of course open to more refined = wording:-). >=20 > (c) We could also explicitly say there are additional requirements in = racing in section XX. >=20 > (d) If this plan seems appropriate, I would then suggest to use lower = case within the remainder of document (we could refer to the = requirements subsection, if we thought necessary). >=20 > Thoughts please, but review now completed! >=20 > Gorry >=20 >=20 > --- >=20 >=20 > Additional Language NiT: >=20 > I think the word /assumes/ is not a good choice of word. >=20 > OLD: >=20 > and it assumes an implementation that can use multiple IP addresses, = multiple protocols, multiple paths, and provide multiple application = streams >=20 > NEW: >=20 > and it can provide benefit when an implementation can use multiple IP = addresses, multiple protocols, multiple paths, and provide multiple = application streams. >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_65AA1496-CCEC-4249-A4B3-1FC718EF31E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for these details, Gorry!

I finally got around to making this PR. = Please take a look, and we=E2=80=99ll discuss tomorrow:

https://github.com/ietf-tapswg/api-drafts/pull/564

Best,
Tommy

On Mar 25, 2020, at 9:02 AM, = Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

As = promised,

I did a review of the arch draft = and the PR that was recently done. There were comments that requested to = remove some normative language that has been implemented in the current = draft - where my review agreed, I have not commented further below. = However, the latest revision, also did not retain the discussion of what = I suggested should be normative. I have worked through the various = comments in github and summarise them here (since these comments are now = burried in the git, see 502 et al).

So here = goes:

Overall review: I think we need to = keep the normative language for the key features that differentiate the = API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and = SHOULD - because these are not protocol operation requirements, but are = implementation requirements to conform. This includes requirements based = on Minset - where the WG dervied this API: This is after all why the WG = worked on Minset as the basis of the API.

----

The following are key = requirements, that define the TAPS architecture:

* It is RECOMMENDED that functionality that is common across = multiple transport protocols is made accessible through a unified set of = TAPS interface calls. As a baseline, a Transport Services API is = RECOMMENDED/REQUIRED to allow access to the minimal set of features = offered by transport protocols {{?I-D.ietf-taps-minset}}.

* TAPS automates the selection of protocols = and features, based on a set of Properties supplied through the TAPS = interface. It is RECOMMENDED that a TAPS system offers Properties that = are common to multiple transport protocols. Specifying common Properties = enables a system to appropriately select between protocols that offer = equivalent features. This design permits evolution of the transport = protocols and functions without affecting the programs using the = system.

* Applications using the TAPS API = are REQUIRED to be robust to the automated selection provided by TAPS, = including the possibility to express requirements and preferences that = constrain the choices that can be made by the system.  In normal = use, TAPS Systems are RECOMMENDED to be designed so that all selection = decisions result in consistent choices for the same network conditions = when they have the same set of preferences. This is intended to provide = predictable outcomes to the application using the transport service.

* Applications using TAPS MAY explicitly = require or prevent the use of specific transport features (and transport = protocols) using the "REQUIRED" and "PROHIBIT" preferences. This allows = an application to constrain the set of protocols and features that will = be selected for the transport service. It is RECOMMENDED that the = default usage by applications does not unecessarily restrict this = selection, so that the system can make informed choices (e.g., based on = the availability of interfaces or set of transport protocols available = for the specified remote endpoint).


---

After thought, here is my = specific poposal of what to do next:

(a) I = suggest we group all the requirements on architecture as short one or = two sentence blocks (preferably as a bullet or definition list) = collected into a single subsection, so they are easy to find and read = and we say that these are the key architectural requirements. I suggest = we insert this new requirements text either their own section, or in = section 1.3 (although I am open to other places where we can call-out = the architectural requirements).

(b) We = need to decide if these are architectural requirements and if there are = more or less in total. I am of course open to more refined = wording:-).

(c) We could also explicitly = say there are additional requirements in racing  in section XX.

(d) If this plan seems appropriate, I would = then suggest to use lower case within the remainder of document (we = could refer to the requirements subsection, if we thought necessary).

Thoughts please, but review now completed!

Gorry


---


Additional = Language NiT:

I think the word /assumes/ is = not a good choice of word.

OLD:

and it assumes an implementation that can use = multiple IP addresses, multiple protocols, multiple paths, and provide = multiple application streams

NEW:

and it can provide benefit when an = implementation can use multiple IP addresses, multiple protocols, = multiple paths, and provide multiple application streams.

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_65AA1496-CCEC-4249-A4B3-1FC718EF31E7-- From nobody Fri Apr 17 01:02:20 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3EC3A1004 for ; Fri, 17 Apr 2020 01:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 xCqj8YUe7QXW for ; Fri, 17 Apr 2020 01:02:17 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 D24E83A1000 for ; Fri, 17 Apr 2020 01:02:16 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1jPLuv-0004gM-B1 for taps@ietf.org; Fri, 17 Apr 2020 08:00:05 +0000 Content-Type: multipart/alternative; boundary="===============3419349814536286406==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 17 Apr 2020 08:00:05 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2020 08:02:19 -0000 --===============3419349814536286406== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+1/-5/=F0=9F=92=AC27) 1 issues created: - Add signal that inbound data was 0-RTT (by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/563 = 14 issues received 27 new comments: - #521 IANA registry of property names or namespaces - from Kyle Rose's r= eview (8 by mirjak, squarooticus, mwelzl, gorryfair, philsbln) https://github.com/ietf-tapswg/api-drafts/issues/521 [API] [discuss] = - #522 Idempotency vs replay-safe (from Kyle Rose's review) (3 by squaro= oticus, mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/522 [API] [discuss] = - #563 Add signal that inbound data was 0-RTT (2 by mirjak, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/563 = - #362 -impl should say more about use of ALPN (2 by abrunstrom, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/362 [Implementation] = - #542 Batching Sends (2 by abrunstrom, mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/542 [Implementation] = - #543 minIncompleteLength when receiving data on streams (2 by mirjak, m= welzl) https://github.com/ietf-tapswg/api-drafts/issues/543 [Implementation] = - #486 Appendix A.1. / Adding preference properties (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/486 [API] = - #523 Registry for "interface instance or type" (from Kyle Rose's revie= w) (1 by squarooticus) https://github.com/ietf-tapswg/api-drafts/issues/523 [API] = - #524 What constitutes trust verification prior to the handshake? (1 by = squarooticus) https://github.com/ietf-tapswg/api-drafts/issues/524 [API] = - #525 single messageContext object for both sends and receives (1 by mwe= lzl) https://github.com/ietf-tapswg/api-drafts/issues/525 [API] = - #526 7.3.1 Sent (from Kyle Rose's review) (1 by squarooticus) https://github.com/ietf-tapswg/api-drafts/issues/526 [API] = - #531 (hopefully) minor point about properties terminology (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/531 [Implementation] = - #537 Recommendations for Delayed Racing (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/537 [Implementation] = - #539 Listeners and ports (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/539 [API] [Implementat= ion] = 5 issues closed: - Listeners and ports https://github.com/ietf-tapswg/api-drafts/issues/53= 9 [API] [Implementation] = - -impl should say more about use of ALPN https://github.com/ietf-tapswg/= api-drafts/issues/362 [Implementation] [future work] = - What constitutes trust verification prior to the handshake? https://git= hub.com/ietf-tapswg/api-drafts/issues/524 [API] = - 7.3.1 Sent (from Kyle Rose's review) https://github.com/ietf-tapswg/a= pi-drafts/issues/526 [API] = - Appendix A.1. / Adding preference properties https://github.com/ietf-ta= pswg/api-drafts/issues/486 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+9/-1/=F0=9F=92=AC4) 9 pull requests submitted: - Consolidate normative language in architecture (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/564 = - Connection state diagram (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/562 = - Replaced "idempotent" with "safely replayable" everywhere. (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/561 = - Architecture NiT: /assumes/ (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/560 = - Referencing RFC 7231 and quoting its idempotency definition (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/559 = - Clarifications about per-connection vs per-message defaults (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/558 = - Define a new type to use when selection properties are queried; closes = #528. (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/557 = - API: state "Ephemeral port used when no Local Endpoint specified" (by m= welzl) https://github.com/ietf-tapswg/api-drafts/pull/556 = - remove sentence about re-using the same object as suggested by @tfpauly= (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/555 = 3 pull requests received 4 new comments: - #561 Replace "idempotent" with "safely replayable" everywhere (2 by mir= jak, mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/561 [API] [Implementatio= n] = - #512 Update Multipath properties - closes #437 (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/512 [API] = - #556 API: state "Ephemeral port used when no Local Endpoint specified" = (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/556 = 1 pull requests merged: - API: state "Ephemeral port used when no Local Endpoint specified" https://github.com/ietf-tapswg/api-drafts/pull/556 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============3419349814536286406== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday April 17, 2020

Issues

ietf-tapswg/api-drafts (+1/-5/=F0=9F=92=AC27)

1 issues created:

14 issues received 27 new comments:

5 issues closed:

Pull requests

ietf-tapswg/api-drafts (+9/-1/=F0=9F=92=AC4)

9 pull requests submitted:

3 pull requests received 4 new comments:

1 pull requests merged:

Repositories tracked by this digest:

 --===============3419349814536286406==-- From nobody Wed Apr 22 10:02:44 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95813A1178; Wed, 22 Apr 2020 10:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 0eOzKLAa_HOF; Wed, 22 Apr 2020 10:02:31 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 6B5803A1133; Wed, 22 Apr 2020 10:02:22 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MH0vxF051608; Wed, 22 Apr 2020 10:02:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=bG2V2L9avrGt7ZhlEpEz9tk5itcF/vFAZpVvShVvaD8=; b=TbVqu9dFfB7vKTQlDJUOxi+hwuXNSqdvZf9SYXgBVERxeYWmBuL73/Qb+4EKTJHkEq+q 6f6DHjAOWr+yxB9ZDxhmV7bJO2AmJNhhJG3XNHiiBjetw1bCsUTdrmF1rLnpUrVgEIwf wSjtJkBt+yCfPJWzI08yGOROWWHci1X7gGwfa0NDczNuGu8ZjPJ8yd18YY7JWEJOxDqd nSaTFU+dX6uJA/UldFA9MHY95irDKaW+F1Hmm9lJ977w4LT9Xx5fICi+Fl5N9auorfcX eJtPRiDAsqbCg6679IP60EPIBx7bbxi/9DRZqbRwg8dM3BB3I3mrh/U2HH8g1MkIJH9Z Mg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 30hg84va2r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:02:19 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q97006658NUVHI0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 22 Apr 2020 10:02:18 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700G008MIVV00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:02:18 -0700 (PDT) X-Va-A: X-Va-T-CD: 173914e0cf39131f94a57ecc1dc8517a X-Va-E-CD: 1ae98740bcc3c89e4e81a61c96faf25a X-Va-R-CD: 20bd44fe62fe53e439044afe46466d72 X-Va-CD: 0 X-Va-ID: 0f63d5d9-92fd-4b45-8df1-4f8e4d955f9b X-V-A: X-V-T-CD: 173914e0cf39131f94a57ecc1dc8517a X-V-E-CD: 1ae98740bcc3c89e4e81a61c96faf25a X-V-R-CD: 20bd44fe62fe53e439044afe46466d72 X-V-CD: 0 X-V-ID: cad89e11-f920-4347-b740-99201aee0fb3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700ZLP8NSJT00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:02:17 -0700 (PDT) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_F811BEC9-96EE-4556-82DB-13D3970EC449" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:02:16 -0700 In-reply-to: <158543611048.7466.9233997230237897172@ietfa.amsl.com> Cc: The IESG , Philipp Tiesel , taps@ietf.org, taps-chairs@ietf.org, caw@heapingbits.net, draft-ietf-taps-transport-security@ietf.org To: Murray Kucherawy References: <158543611048.7466.9233997230237897172@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Murray Kucherawy's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:02:34 -0000 --Apple-Mail=_F811BEC9-96EE-4556-82DB-13D3970EC449 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Murray, Thanks for the review! You can find an updated version of the document, = that incorporates the nits you point out, here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Thanks, Tommy > On Mar 28, 2020, at 3:55 PM, Murray Kucherawy via Datatracker = wrote: >=20 > Murray Kucherawy has entered the following ballot position for > draft-ietf-taps-transport-security-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This is a really useful summary, especially for people without deep = background > in transport security. It'll make a great reference document. >=20 > Section 4.3: > * "Specific" should be "Specifically" > * "They have a dependencies on" -- should be "dependency" >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_F811BEC9-96EE-4556-82DB-13D3970EC449 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Murray,

Thanks for = the review! You can find an updated version of the document, that = incorporates the nits you point out, here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

Thanks,
Tommy

On Mar 28, 2020, at 3:55 PM, = Murray Kucherawy via Datatracker <noreply@ietf.org> wrote:

Murray= Kucherawy has entered the following ballot position for
draft-ietf-taps-transport-security-11: Yes

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

This is a really useful summary, = especially for people without deep background
in transport = security.  It'll make a great reference document.

Section 4.3:
* "Specific" should be = "Specifically"
* "They have a dependencies on" -- should = be "dependency"



_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_F811BEC9-96EE-4556-82DB-13D3970EC449-- From nobody Wed Apr 22 10:05:30 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39FC3A1080; Wed, 22 Apr 2020 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 isrFP8zYO1bs; Wed, 22 Apr 2020 10:05:20 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 C75273A1078; Wed, 22 Apr 2020 10:05:19 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MH2pjt030458; Wed, 22 Apr 2020 10:05:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wZdjGAiQ2QpIFCH012qq1JWQwmcQoI9ylvqWBEcYMk0=; b=D1njAdXIEp3Z1XpEvYQddCpjeuLVrwqVDFp46UJSBWvZcbHR7AfhV74yscJGEkm5J3pz Lb/rE6xBlx3bfY1zlQacWP0GpdpgaS3fgx/cLPBAxTOYms0hbE1mj9JbiYZhGYKwoKsS yRTKkS2T7+MyYRNVs/MKzs4qvGRYQSNXBxJf8k2UmiN/wralJcrbx1MbfRPzr0+2TCln Q688mXl2A4hNy4mn42JiJPNW08/2hvm/Rk05X+MCPIhqE0eHADHFatzSFVWoBsKmzZ42 ojyicrWkQ992o4N69q2izjUQiTsHwZT7TizUy19OxOXlMFWp+8aaquFoZivsY7lLOa2v TA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp01.apple.com with ESMTP id 30hj73ba40-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:05:15 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700NR88SQ4200@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 22 Apr 2020 10:05:14 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700L008PIX600@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:05:14 -0700 (PDT) X-Va-A: X-Va-T-CD: ed5c3ce2e09ef5aa6ff6961241871657 X-Va-E-CD: 05ca45ebcf6d66e50370884a8fba8dcc X-Va-R-CD: 6b1e0eddcc6b9537037ebf8d4d2de0e0 X-Va-CD: 0 X-Va-ID: d09f40ae-6149-49bd-b164-b1a98820722e X-V-A: X-V-T-CD: ed5c3ce2e09ef5aa6ff6961241871657 X-V-E-CD: 05ca45ebcf6d66e50370884a8fba8dcc X-V-R-CD: 6b1e0eddcc6b9537037ebf8d4d2de0e0 X-V-CD: 0 X-V-ID: 0f997f2f-793a-4ba8-9f5f-e9f7804c191d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700ZVC8SNJT00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:05:14 -0700 (PDT) From: Tommy Pauly Message-id: <11E692BD-0C31-4A96-A247-96C380D7999E@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_770DDBED-9580-4868-BF06-08AEC10B8B23" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:05:11 -0700 In-reply-to: <5C72A1F6-DAD5-484A-B62E-FD26F83ADE20@cisco.com> Cc: "iot-directorate@ietf.org" , "last-call@ietf.org" , "draft-ietf-taps-transport-security.all@ietf.org" , "taps@ietf.org" To: "Eric Vyncke (evyncke)" , Mohit Sethi References: <158573789268.30918.7424398883276797270@ietfa.amsl.com> <5C72A1F6-DAD5-484A-B62E-FD26F83ADE20@cisco.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:05:22 -0000 --Apple-Mail=_770DDBED-9580-4868-BF06-08AEC10B8B23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mohit, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Regarding the title, we believe that the current version is correct, = since "Transport Services=E2=80=9D itself is about the interaction = between apps and transport protocols; thus by adding security to the = mix, we are still referring to the interface to applications. More = importantly, the authors believe that the first sentence of the abstract = does indicate this clearly: "This document provides a survey of commonly used or notable network = security protocols, with a focus on how they interact and integrate with = applications and transport protocols.=E2=80=9D We did incorporate the editorial points you brought up. Thanks for = pointing those out! Thanks, Tommy > On Apr 2, 2020, at 5:03 AM, Eric Vyncke (evyncke) = wrote: >=20 > Thank you Mohit for the review. >=20 > I will take it into account for my ballot position. >=20 > Regards >=20 > -=C3=A9ric >=20 > =EF=BB=BF-----Original Message----- > From: Iot-directorate on behalf of = Mohit Sethi via Datatracker > Reply-To: Mohit Sethi > Date: Wednesday, 1 April 2020 at 12:45 > To: "iot-directorate@ietf.org" > Cc: "last-call@ietf.org" , = "draft-ietf-taps-transport-security.all@ietf.org" = , "taps@ietf.org" = > Subject: [Iot-directorate] Iotdir telechat review of = draft-ietf-taps-transport-security-11 >=20 > Reviewer: Mohit Sethi > Review result: Ready with Nits >=20 > This document provides a summary of common security protocols. It = then > discusses the interfaces that exist between applications and = security protocols > as well as security protocols and transport services. >=20 > Major issues: The document header says that this document is about = interfaces > between security protocols and transport services. Yet, later on, I = find that > the document is also discussing the interfaces between security = protocols and > applications. Perhaps you could add 'applications' to the title -> = 'Interaction > Between Applications, Security Protocols, and Transport Services' >=20 > Editorial issues: > - Instead of saying 'This protocol obsoletes TCP MD5 "signature" = options', can > we say 'TCP-AO obsoletes....' to avoid confusion of what is 'this' = - Please > expand 'and IPsec AH [RFC4302]' -> IP Authentication Header - Are = you talking > about cryptographic agility here 'security protocols: = confidentiality, privacy > protections, and agility.' ? - Consider changing 'interface surface = exposed '-> > interface exposed by'. Otherwise it sounds too similar to attack = surface > exposed. - Expand EAP and reference RFC3748. - Perhaps you could = say that > Source Address Validation (SAV) to prevent DoS is relevant for = protocols that > use unreliable transport? >=20 >=20 > --=20 > Iot-directorate mailing list > Iot-directorate@ietf.org > https://www.ietf.org/mailman/listinfo/iot-directorate >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call --Apple-Mail=_770DDBED-9580-4868-BF06-08AEC10B8B23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mohit,

Thanks for = the review! You can find an updated version of the document = here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

Regarding the title, we believe that = the current version is correct, since "Transport Services=E2=80=9D = itself is about the interaction between apps and transport protocols; = thus by adding security to the mix, we are still referring to the = interface to applications. More importantly, the authors believe that = the first sentence of the abstract does indicate this clearly:

"This document provides = a survey of commonly used or notable network security protocols, with a = focus on how they interact and integrate with applications and = transport protocols.=E2=80=9D

We did incorporate the editorial points = you brought up. Thanks for pointing those out!

Thanks,
Tommy

On Apr 2, 2020, at 5:03 AM, Eric Vyncke = (evyncke) <evyncke=3D40cisco.com@dmarc.ietf.org> wrote:

Thank = you Mohit for the review.

I will take it = into account for my ballot position.

Regards

-=C3=A9ric

=EF=BB=BF-----Original Message-----
From: Iot-directorate <iot-directorate-bounces@ietf.org> on behalf of Mohit = Sethi via Datatracker <noreply@ietf.org>
Reply-To: Mohit Sethi = <mohit.m.sethi@ericsson.com>
Date: = Wednesday, 1 April 2020 at 12:45
To: "iot-directorate@ietf.org" <iot-directorate@ietf.org>
Cc: "last-call@ietf.org" = <last-call@ietf.org>, "draft-ietf-taps-transport-security.all@ietf.org" <draft-ietf-taps-transport-security.all@ietf.org>, "taps@ietf.org" <taps@ietf.org>
Subject: [Iot-directorate] Iotdir telechat review of = draft-ietf-taps-transport-security-11

=    Reviewer: Mohit Sethi
=    Review result: Ready with Nits

   This document provides a summary of common = security protocols. It then
   discusses = the interfaces that exist between applications and security protocols
   as well as security protocols and = transport services.

=    Major issues: The document header says that this = document is about interfaces
   between = security protocols and transport services. Yet, later on, I find that
   the document is also discussing the = interfaces between security protocols and
=    applications. Perhaps you could add 'applications' to = the title -> 'Interaction
   Between = Applications, Security Protocols, and Transport Services'

   Editorial issues:
   - Instead of saying 'This protocol = obsoletes TCP MD5 "signature" options', can
=    we say 'TCP-AO obsoletes....' to avoid confusion of = what is 'this' - Please
   expand 'and = IPsec AH [RFC4302]' -> IP Authentication Header - Are you talking
   about cryptographic agility here 'security = protocols: confidentiality, privacy
=    protections, and agility.' ? - Consider changing = 'interface surface exposed '->
=    interface exposed by'. Otherwise it sounds too similar = to attack surface
   exposed. - Expand EAP = and reference RFC3748. - Perhaps you could say that
=    Source Address Validation (SAV) to prevent DoS is = relevant for protocols that
   use = unreliable transport?


=    --
   Iot-directorate = mailing list
   Iot-directorate@ietf.org
=    https://www.ietf.org/mailman/listinfo/iot-directorate


--
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call

= --Apple-Mail=_770DDBED-9580-4868-BF06-08AEC10B8B23-- From nobody Wed Apr 22 10:07:00 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254703A1080; Wed, 22 Apr 2020 10:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 WjV3A6E2C_An; Wed, 22 Apr 2020 10:06:57 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 9FBD93A1078; Wed, 22 Apr 2020 10:06:57 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MH3B0A006480; Wed, 22 Apr 2020 10:06:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=iLoa211vpIydczjjTYsXa2cqzjwwIJeoMj1zDvvDYDU=; b=L/GSox6uUHZk8VJOFx6wmg1MRu43YKk97qwkMys+nbTSX2hk7IGihbQ5CflOmVkjdb0C h3ZJGGdUxsU93cgd1IZ0mpaeHCTLU+uv8HqUnhlKtWu5gpvRrq1C6VSzeB952REnogen /eftQgOpg6VyvMwS4HvTyI5RwolZmq9bv5xIDpw4JEn4IlHzyB/TZ2sk6qB4xQBtQEtr u0bTZ90X/nGl5l6TVGWwZoBEThAPF/F+oIBPSiJsiDPD/LCx3Ur4U6tH7ZWNCCd8Yo0H MTQcTv+dv1GrH7Rk99L4XDehFUaSz2BfLGRvU8tz43p42oL5CzYy05kaDdRXQ4dt/WVg KA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp02.apple.com with ESMTP id 30hhyh26hj-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:06:57 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q97004478VI0980@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:06:54 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700L008PIX500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:06:54 -0700 (PDT) X-Va-A: X-Va-T-CD: d95fcd35aa404efb0fffbb8d55224633 X-Va-E-CD: 6b4d5a61bbb8fd376cfbb1aa7d04077d X-Va-R-CD: c6dd971ec176bf7e1f436e0bcf5f43eb X-Va-CD: 0 X-Va-ID: 8941235d-e905-4f5e-a169-876120fd6ca8 X-V-A: X-V-T-CD: d95fcd35aa404efb0fffbb8d55224633 X-V-E-CD: 6b4d5a61bbb8fd376cfbb1aa7d04077d X-V-R-CD: c6dd971ec176bf7e1f436e0bcf5f43eb X-V-CD: 0 X-V-ID: 951dc5f9-5a95-477f-98a1-f8741ae94280 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q97005SZ8VHC300@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:06:54 -0700 (PDT) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_865B6BD0-1F0C-4DF5-B416-32EE22D84BC0" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:06:52 -0700 In-reply-to: <158591580027.17912.14591985076306660054@ietfa.amsl.com> Cc: int-dir@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org To: Brian Haberman References: <158591580027.17912.14591985076306660054@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Intdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:06:59 -0000 --Apple-Mail=_865B6BD0-1F0C-4DF5-B416-32EE22D84BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = The authors discussed, and believe that SSH, L2TP, and GRE do not expose = significant new surfaces for transports and applications compared to the = existing protocols surveyed. We did, however, add specific text and = references to those protocols in the introduction as explanation. Thanks, Tommy > On Apr 3, 2020, at 5:10 AM, Brian Haberman via Datatracker = wrote: >=20 > Reviewer: Brian Haberman > Review result: Ready with Issues >=20 > This document is a survey of network security protocols and their = interaction > with transport and application protocols. It is clearly written and = easy to > read. I have a minor comment on the contents of this draft. >=20 > It is not abundantly clear what the criteria was for selecting the = subset of > security protocols included in this draft. Some notable omissions = include SSH, > L2TP, and GRE. These seem like interesting omissions given their = popularity in > a number of deployment scenarios. Not a showstopper in my opinion, but > interesting to note. >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_865B6BD0-1F0C-4DF5-B416-32EE22D84BC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Brian,

Thanks for = the review! You can find an updated version of the document = here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

The authors discussed, and believe that = SSH, L2TP, and GRE do not expose significant new surfaces for transports = and applications compared to the existing protocols surveyed. We did, = however, add specific text and references to those protocols in the = introduction as explanation.

Thanks,
Tommy

On Apr 3, 2020, at 5:10 AM, Brian Haberman = via Datatracker <noreply@ietf.org> wrote:

Reviewer: Brian Haberman
Review result: Ready = with Issues

This document is a survey of = network security protocols and their interaction
with = transport and application protocols. It is clearly written and easy = to
read. I have a minor comment on the contents of this = draft.

It is not abundantly clear what the = criteria was for selecting the subset of
security = protocols included in this draft. Some notable omissions include SSH,
L2TP, and GRE. These seem like interesting omissions given = their popularity in
a number of deployment scenarios. Not = a showstopper in my opinion, but
interesting to note.


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_865B6BD0-1F0C-4DF5-B416-32EE22D84BC0-- From nobody Wed Apr 22 10:08:25 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988CA3A0D63; Wed, 22 Apr 2020 10:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=apple.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 dWKX9ata7kNJ; Wed, 22 Apr 2020 10:08:17 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 346463A0D7F; Wed, 22 Apr 2020 10:08:14 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MH0uZX007733; Wed, 22 Apr 2020 10:08:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=tSkmUPedDUs8Gk11UCCBJLWh3kH8raC8fe1m336gOOQ=; b=Z8ACGZWBBFdX01cgCPYvlHH6gcXKQ13dmUni+ORPnidJGRUsazbqdOt50tZKuxDycK2C jhJ0b576s5+WAWU8bO2a7IqBnM4hHm7Xd3qHrJMFJXjAmfjh6M9c5Vukn0l42EwcjOAa JCmsU+miFGAhztbkToowkgywpUb8UHdphrMVhOfY0TNmCPatAJCf6giMu+KlTDxksDi8 qufo28Jkao7ie8ejVFXjFoj39kvTvqLoGL6OzqzmrvrPeDHlvMzDV43pBtUrY46ArtYB rppv/0ugRSWOKWlgwmIr7AnTceR9SZ3dBjWeMVVRFe2ImO/1P+axvbNOTOu8C75wyt/t GA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30hfm8pxbh-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:08:09 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700A1H8XLQ3D0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 22 Apr 2020 10:08:09 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700L008PIX600@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:08:09 -0700 (PDT) X-Va-A: X-Va-T-CD: 75d70f6cde7a363ec960c7178b706cdc X-Va-E-CD: 2bb83428a9756c48b88a9f4f77c4e0c3 X-Va-R-CD: b52259295f4b1f943a26df9705ea137f X-Va-CD: 0 X-Va-ID: 237e6ecd-48e6-450b-82bc-356f1660874f X-V-A: X-V-T-CD: 75d70f6cde7a363ec960c7178b706cdc X-V-E-CD: 2bb83428a9756c48b88a9f4f77c4e0c3 X-V-R-CD: b52259295f4b1f943a26df9705ea137f X-V-CD: 0 X-V-ID: b3e5f4ad-bb2c-48d9-841c-8b6e8451e4eb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q97005VA8XHC300@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:08:08 -0700 (PDT) From: Tommy Pauly Message-id: <083D32FB-6EAA-4AF8-B996-5DA6D98D6150@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_0450E4A3-43B8-4DD7-8847-69AD7D2790BB" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:08:04 -0700 In-reply-to: <158619313391.2395.109717988578779678@ietfa.amsl.com> Cc: The IESG , philipp@tiesel.net, taps@ietf.org, taps-chairs@ietf.org, caw@heapingbits.net, draft-ietf-taps-transport-security@ietf.org To: Robert Wilton References: <158619313391.2395.109717988578779678@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Robert Wilton's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:08:19 -0000 --Apple-Mail=_0450E4A3-43B8-4DD7-8847-69AD7D2790BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Robert, Thanks for the review, and I=E2=80=99m glad this was a useful reference = for you. You can find an updated version of the document here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = We have added new text to address all of the editorial points you = brought up. Thanks, Tommy > On Apr 6, 2020, at 10:12 AM, Robert Wilton via Datatracker = wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-taps-transport-security-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > As incoming AD I found that document really useful and informative - = thank you. >=20 > As a minor nit, I found the English around the usage of the term = "Transport > Services", that I wasn't familiar with prior to reading this document, = slightly > tricky to parse in the introduction, particularly because the term = isn't > defined until the Terminology in section 3. >=20 > E.g. in the second paragraph it isn't clear to me what a "Transport = Services > system" real means. Possibly replace "a Transport Services system may = need to > support" with "a Transport Service may need to support"? >=20 > Similarly, perhaps change " One of the goals of Transport Services is = to define > a common interface for using transport protocols" to " One of the = goals of > Transport Service definitions is to define a common interface for = using > transport protocols"? >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_0450E4A3-43B8-4DD7-8847-69AD7D2790BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Robert,

Thanks for = the review, and I=E2=80=99m glad this was a useful reference for you. = You can find an updated version of the document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

We have added new text to address all = of the editorial points you brought up.

Thanks,
Tommy

On Apr 6, 2020, at 10:12 AM, Robert Wilton = via Datatracker <noreply@ietf.org> wrote:

Robert= Wilton has entered the following ballot position for
draft-ietf-taps-transport-security-11: Yes

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

As incoming AD I found that = document really useful and informative - thank you.

As a minor nit, I found the English around the usage of the = term "Transport
Services", that I wasn't familiar with = prior to reading this document, slightly
tricky to parse = in the introduction, particularly because the term isn't
defined until the Terminology in section 3.

E.g. in the second paragraph it isn't clear to me what a = "Transport Services
system" real means.  Possibly = replace "a Transport Services system may need to
support" = with "a Transport Service may need to support"?

Similarly, perhaps change " One of the goals of Transport = Services is to define
a common interface for using = transport protocols" to " One of the goals of
Transport = Service definitions is to define a common interface for using
transport protocols"?



_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_0450E4A3-43B8-4DD7-8847-69AD7D2790BB-- From nobody Wed Apr 22 10:11:37 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E233A1095; Wed, 22 Apr 2020 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 rmMdO-AGKy4p; Wed, 22 Apr 2020 10:11:33 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 236683A1080; Wed, 22 Apr 2020 10:11:33 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MH7CoE012801; Wed, 22 Apr 2020 10:11:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=hk1zcUaoUMr8FKdqeSVrEvhAOc5HspIwKs+a5NklbD8=; b=l+nI9qtGhHO7Vg1ofPban+6nGnIJ9xAhHRFo0TC+41chl9jgVrr2CLE3l/sFdm5fLrEf MeZkfKsopgyn8SO9WQK/T3Zlo+GtgxuFN4SdXv0hIyagXsV1H+Oq25MvudpgHxDfmTC7 YCpHztaLlZhxTZJa3T+lU7WE76Y7Ao2OflF9w23y4LPHcKioscKyqS7ugJ+/uE+YUP/T kke6PHQHButak85BbyQKAP2/R59YP+FjzV6h7uv/5FrlkWf5qRMoUYbMQrAwHiy8Shhh 42yriQM3jeY2NSo3A/IM11JGSWr072o6ql2Fb3DKvYiGUKoBbuyq4kqVi2e2anvPsqkT Cw== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by nwk-aaemail-lapp02.apple.com with ESMTP id 30hhyh2985-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:11:29 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700NCV93542A0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 22 Apr 2020 10:11:29 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700L008PIX500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:11:29 -0700 (PDT) X-Va-A: X-Va-T-CD: 5e0758ac758adaea6a44b8b32ea89e72 X-Va-E-CD: e2683231398be4050a86e8e77efb761c X-Va-R-CD: 74216d21bb5feab0c413ccca5648d3ac X-Va-CD: 0 X-Va-ID: f6117657-ba5c-4b10-aca7-41730340027e X-V-A: X-V-T-CD: 5e0758ac758adaea6a44b8b32ea89e72 X-V-E-CD: e2683231398be4050a86e8e77efb761c X-V-R-CD: 74216d21bb5feab0c413ccca5648d3ac X-V-CD: 0 X-V-ID: dc6b8727-3494-4c50-8a23-a834a81a58b6 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700JMN9341E00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:11:29 -0700 (PDT) From: Tommy Pauly Message-id: <1C6D2F3A-D3CE-4474-A36C-EDEBB0475AEA@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_9B8D147B-1549-472B-836C-DE23DF6E4725" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:11:28 -0700 In-reply-to: <158632492387.9927.14911806705395970669@ietfa.amsl.com> Cc: The IESG , draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net To: Barry Leiba References: <158632492387.9927.14911806705395970669@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Barry Leiba's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:11:35 -0000 --Apple-Mail=_9B8D147B-1549-472B-836C-DE23DF6E4725 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barry, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Responses to your individual points inline. > On Apr 7, 2020, at 10:48 PM, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-taps-transport-security-11: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this helpful document. Just some editorial comments beyond = what > others have mentioned: >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > It examines Transport Layer Security > (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google > QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating > Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, > CurveCP, and MinimalT. >=20 > It=E2=80=99s funny that this carefully expands every abbreviation = except =E2=80=9CSRTP=E2=80=9D.=20 > Please do that one too. Expanded! >=20 > Ubiquitous IETF protocols such as (D)TLS, as well as non-standard > protocols such as gQUIC, are both included >=20 > The word =E2=80=9Cboth=E2=80=9D doesn=E2=80=99t work here. I think a = reasonable fix is just to remove > the single word. Maybe a better fix is to slightly reword, as, = =E2=80=9CUbiquitous > IETF protocols such as (D)TLS are included, and so are non-standard = protocols > such as gQUIC, despite...=E2=80=9D Fixed by removing the word. >=20 > =E2=80=94 Section 1.1 =E2=80=94 >=20 > For example, a security > protocol that expects to run over a reliable stream of bytes, like > TLS, restrict the set of transport protocols that can be used > Number agreement: make it =E2=80=9Crestricts=E2=80=9D to match the = singular subject =E2=80=9Ca security > protocol=E2=80=9D. Fixed. >=20 > =E2=80=94 Section 2 =E2=80=94 >=20 > Examples include > confidentiality, reliable delivery, ordered delivery, message- > versus-stream orientation, etc. >=20 > You don=E2=80=99t need both =E2=80=9Cexamples include=E2=80=9D and = =E2=80=9Cetc.=E2=80=9D; I suggest eliminating the > latter (and sticking in an =E2=80=9Cand=E2=80=9D). Fixed. >=20 > =E2=80=94 Section 3.1.1 =E2=80=94 >=20 > to marshal (possibly encrypted) data from one peer to the other. >=20 > Possibly? I understand you=E2=80=99re covering the handshake there as = well, but for a > summary as (reasonably) brief as this I think it=E2=80=99s misleading = to say =E2=80=9Cpossibly=E2=80=9D. This is now: "The record protocol is used to marshal and, once the handshake has = sufficiently progressed, encrypt, data from one peer to the other. " >=20 > =E2=80=94 Section 3.2.1 =E2=80=94 >=20 > ZRTP [RFC6189] is an alternative key agreement and identity > management protocols for SRTP. >=20 > Number agreement: =E2=80=9Cprotocol=E2=80=9D Fixed! >=20 > =E2=80=94 Section 3.4.3 =E2=80=94 >=20 > For key establishment, OpenVPN can use TLS as a handshake protocol = or > pre-shared keys. >=20 > This reads oddly, as though there are two things OpenVPN can use TLS = for. I > would make it, =E2=80=9C...or it can use pre-shared keys.=E2=80=9D Changed to: "For key establishment, OpenVPN can either use TLS as a handshake = protocol or use pre-shared keys." >=20 > =E2=80=94 Section 5.1 =E2=80=94 >=20 > * Extensions (Application-Layer Protocol Negotiation) (EXT): The > application enables or configures extensions that are to be > negotiated by the security protocol, such as ALPN [RFC7301]. >=20 > Isn=E2=80=99t the expansion of =E2=80=9CALPN=E2=80=9D misplaced here? This is now written out in expanded form "Application-Layer Protocol = Negotiation (ALPN) [RFC7301]" >=20 >=20 Thanks, Tommy --Apple-Mail=_9B8D147B-1549-472B-836C-DE23DF6E4725 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barry,

Thanks for = the review! You can find an updated version of the document = here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

Responses to your individual points = inline.


On Apr = 7, 2020, at 10:48 PM, Barry Leiba via Datatracker <noreply@ietf.org> = wrote:

Barry Leiba has entered the following ballot position for
draft-ietf-taps-transport-security-11: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thanks for this helpful document. =  Just some editorial comments beyond what
others have = mentioned:

=E2=80=94 Section 1 =E2=80=94

  It examines Transport Layer = Security
  (TLS), Datagram Transport Layer = Security (DTLS), IETF QUIC, Google
  QUIC = (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating
=   Security Protocol (IKEv2 + ESP), SRTP (with DTLS), = WireGuard,
  CurveCP, and MinimalT.

It=E2=80=99s funny that this carefully expands = every abbreviation except =E2=80=9CSRTP=E2=80=9D.
Please = do that one too.

Expanded!

=   Ubiquitous IETF protocols such as (D)TLS, as well as = non-standard
  protocols such as gQUIC, are = both included

The word =E2=80=9Cboth=E2=80=9D= doesn=E2=80=99t work here.  I think a reasonable fix is just to = remove
the single word.  Maybe a better fix is to = slightly reword, as, =E2=80=9CUbiquitous
IETF protocols = such as (D)TLS are included, and so are non-standard protocols
such as gQUIC, despite...=E2=80=9D

Fixed by = removing the word.

=E2=80=94 Section 1.1 =E2=80=94=

  For example, a security
  protocol that expects to run over a reliable = stream of bytes, like
  TLS, restrict the set = of transport protocols that can be used
Number agreement: = make it =E2=80=9Crestricts=E2=80=9D to match the singular subject =E2=80=9C= a security
protocol=E2=80=9D.

Fixed.

=E2=80=94 Section 2 =E2=80=94

     Examples include
=      confidentiality, reliable delivery, = ordered delivery, message-
=      versus-stream orientation, etc.

You don=E2=80=99t need both =E2=80=9Cexamples = include=E2=80=9D and =E2=80=9Cetc.=E2=80=9D; I suggest eliminating = the
latter (and sticking in an =E2=80=9Cand=E2=80=9D).

Fixed.

=E2=80=94 Section 3.1.1 =E2=80=94

  to marshal (possibly encrypted) = data from one peer to the other.

Possibly? =  I understand you=E2=80=99re covering the handshake there as well, = but for a
summary as (reasonably) brief as this I think = it=E2=80=99s misleading to say =E2=80=9Cpossibly=E2=80=9D.

This is = now:

"The record protocol is used to = marshal and, once the handshake has sufficiently progressed, encrypt, = data from one peer to the other. "

=E2=80=94 = Section 3.2.1 =E2=80=94

  ZRTP = [RFC6189] is an alternative key agreement and identity
=   management protocols for SRTP.

Number agreement: =E2=80=9Cprotocol=E2=80=9D

Fixed!

=E2=80=94 Section 3.4.3 =E2=80=94

  For key establishment, OpenVPN = can use TLS as a handshake protocol or
=   pre-shared keys.

This reads = oddly, as though there are two things OpenVPN can use TLS for. =  I
would make it, =E2=80=9C...or it can use = pre-shared keys.=E2=80=9D

Changed to:

"For = key establishment, OpenVPN can either use TLS as a handshake protocol or = use pre-shared keys."

=E2=80=94 = Section 5.1 =E2=80=94

  * =  Extensions (Application-Layer Protocol Negotiation) (EXT): The
     application enables or = configures extensions that are to be
=      negotiated by the security protocol, such = as ALPN [RFC7301].

Isn=E2=80=99t the = expansion of =E2=80=9CALPN=E2=80=9D misplaced here?

This is = now written out in expanded form "Application-Layer Protocol Negotiation = (ALPN) [RFC7301]"



Thanks,
Tommy

= --Apple-Mail=_9B8D147B-1549-472B-836C-DE23DF6E4725-- From nobody Wed Apr 22 10:12:43 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F03A1089; Wed, 22 Apr 2020 10:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 Jq43_EqtGRlL; Wed, 22 Apr 2020 10:12:34 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 C6BB33A0F9C; Wed, 22 Apr 2020 10:12:33 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHB0Yv003456; Wed, 22 Apr 2020 10:12:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=lYpZ7IEXzVBnI0o2cDR0jfelS0faejNIzuwRBIPEsyY=; b=Q10oTImsOVezSUHD7AgaOOKrfwtRZbTI9PLdSQktkpS0uJua0IgN+WT9kcx9XjFXSfTT C0IROFCoOFNpAdRpa3Ppuquc01vJAVDwRzfgD881egGhrVdbf7JloujRGbMJAFg6ZV8P vWsKRkXVUDmEBHhyBsJzKdYAnfsdIBO7WtAwkzGZagSLnBq0IHaH+L3f52URN5wF2knQ 0qrUAIxUW4En+P8G4DnX2ljgaoNQtrvdFYUMyLby4rUQ0zhS0FGG1U3M4rO0tyVhMO1r pp+T4Rw8vQ5a+mioo+1tkwNF7A0Ony6rxvCSPoKcoOMkNclhCFx9/mPk99F+biWzgHLv bA== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 30hg84vfhx-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:12:31 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700NLD94S42B0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Wed, 22 Apr 2020 10:12:28 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q9700L008PIX000@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:12:28 -0700 (PDT) X-Va-A: X-Va-T-CD: cbb9ccbb70784dd93466f531081e02f7 X-Va-E-CD: fffb8d30529800167947152eb6201ac6 X-Va-R-CD: 2dc23fa9b27d0da740a4514276edc035 X-Va-CD: 0 X-Va-ID: 9b9f605c-3da0-45a5-bacc-2525495e3926 X-V-A: X-V-T-CD: cbb9ccbb70784dd93466f531081e02f7 X-V-E-CD: fffb8d30529800167947152eb6201ac6 X-V-R-CD: 2dc23fa9b27d0da740a4514276edc035 X-V-CD: 0 X-V-ID: 80a23547-de65-4c51-8728-2b4f80834184 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700JMN9341E00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:12:27 -0700 (PDT) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_B64DD3F9-5607-4653-B671-AC82447488AE" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:12:27 -0700 In-reply-to: <158639504371.21661.11551525700396114665@ietfa.amsl.com> Cc: The IESG , philipp@tiesel.net, taps@ietf.org, taps-chairs@ietf.org, caw@heapingbits.net, draft-ietf-taps-transport-security@ietf.org To: Alissa Cooper References: <158639504371.21661.11551525700396114665@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Alissa Cooper's Yes on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:12:37 -0000 --Apple-Mail=_B64DD3F9-5607-4653-B671-AC82447488AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alissa, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = We=E2=80=99ve made this more equivalent by removing the mention of the = author in the text, and leaving it for the reference for both. Thanks, Tommy > On Apr 8, 2020, at 6:17 PM, Alissa Cooper via Datatracker = wrote: >=20 > Alissa Cooper has entered the following ballot position for > draft-ietf-taps-transport-security-11: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > To a non-expert it struck me as a bit odd that Dan Bernstein is = mentioned as > the designer of CurveCP but no one is mentioned as the designer of = MinimalT. >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_B64DD3F9-5607-4653-B671-AC82447488AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Alissa,

Thanks for = the review! You can find an updated version of the document = here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

We=E2=80=99ve made this more equivalent = by removing the mention of the author in the text, and leaving it for = the reference for both.

Thanks,
Tommy

On Apr = 8, 2020, at 6:17 PM, Alissa Cooper via Datatracker <noreply@ietf.org> = wrote:

Alissa Cooper has entered the following ballot position = for
draft-ietf-taps-transport-security-11: Yes

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

To a non-expert it struck me as a = bit odd that Dan Bernstein is mentioned as
the designer of = CurveCP but no one is mentioned as the designer of MinimalT.



_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_B64DD3F9-5607-4653-B671-AC82447488AE-- From nobody Wed Apr 22 10:24:13 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE13A1111; Wed, 22 Apr 2020 10:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=apple.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 4-Ub-fqGA1QJ; Wed, 22 Apr 2020 10:23:57 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 A6A813A1110; Wed, 22 Apr 2020 10:23:57 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHKuj2009135; Wed, 22 Apr 2020 10:23:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=dnYCwFc+wpr0aO5NfdHrhOEj6oZDwWjXzFin+d7tKgs=; b=wQpKfOtjL9UOp74rlw+gEQLZ3CDeKV8jVlvabYyBoq/6/Mfni05Ey6kYsBEzchPCQu+B CZN37UNUhWm2RUVmkVsxL3TjZRB4xgev+iB9qzffaYTs5lhOb5Jfm4cMElCg/PtgX7yg nNrDBsgZj5IXIAQQhum8JM1/uebP46foY7ccoHYCVy+YaSK6i09ADXiEMKXcpjUv6iPT 8KRt8WnVL8rXABhKbCI7FGZ/Bm19tYkVi6dUMMQdaw/+V37d6uN2YxX49SWeOJj/sKgy zjt/VfubZ09JlbSO4jejpgmlsqbmV2dfJo0XlQyWVbCQyLLNxfbDGMkwsAhp3cCIJIDs TA== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30hfm8q7h4-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:23:54 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700S2S9NU94H0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Wed, 22 Apr 2020 10:23:54 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q97008009LGLW00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:23:54 -0700 (PDT) X-Va-A: X-Va-T-CD: 944ab79e26fa5c26e077ae600b45fa8b X-Va-E-CD: da1b44503e97f19d3df8cf7f6731a981 X-Va-R-CD: 9245970122e752b1cfd3f6910998d0f5 X-Va-CD: 0 X-Va-ID: f4ac5973-4c18-4953-a3ff-6bd8c5e1e605 X-V-A: X-V-T-CD: 944ab79e26fa5c26e077ae600b45fa8b X-V-E-CD: da1b44503e97f19d3df8cf7f6731a981 X-V-R-CD: 9245970122e752b1cfd3f6910998d0f5 X-V-CD: 0 X-V-ID: 83a06544-a874-4859-81cb-a89051618d89 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700VUJ9NR7700@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:23:53 -0700 (PDT) From: Tommy Pauly Message-id: <027BEF88-CB63-4F2F-90E2-9A407EC19D93@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_ABC44262-2C03-4700-9B21-8AE4E63CB4A5" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:23:51 -0700 In-reply-to: <158638531056.18357.11401006659618104728@ietfa.amsl.com> Cc: The IESG , draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net To: Benjamin Kaduk References: <158638531056.18357.11401006659618104728@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Benjamin Kaduk's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:24:01 -0000 --Apple-Mail=_ABC44262-2C03-4700-9B21-8AE4E63CB4A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, Thanks for the detailed review! You can find an updated version of the = document here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = We did rename IKEv2 + ESP to simply IPsec, at the recommendation of = ipsecme. We explain those individual protocols in the IPsec section, but = do not reference them elsewhere. Responses to your specific points inline. > On Apr 8, 2020, at 3:35 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-taps-transport-security-11: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I do wonder whether the Generic Security Service API (RFC 2743) was > considered by the WG in the production of this document. It reflects = a > somewhat dated snapshot of what was believed to be necessary security > APIs, but may not be entirely without value for this type of survey. Thanks for the pointer to that document. We did review it (and I for one = had not seen it before!). We chose not to add a reference for now, as = there didn=E2=80=99t seem any obvious place to put a reference. That = document seems to specify a specific generic API, whereas we=E2=80=99re = more talking about how the shape of security protocols fit into = transports. >=20 > It's a little surprising to not list a reference for QUIC in its > mentions in Sections 1 and 3, with the first reference occuring in > Section 3.3.1. We=E2=80=99ve moved the reference for this earlier in the document. >=20 > Section 1 >=20 > set, protocols that do not offer new features are omitted. For > example, newer protocols such as WireGuard make unique design = choices > that have implications and limitations on application usage. In >=20 > nit: "implications for" and "limitations on=E2=80=9D. Indeed! Fixed. >=20 > protection. Despite these improvements, neither protocol sees > general use and both lack critical properties important for emergent > transport security protocols: confidentiality, privacy protections, > and agility. Such protocols are thus omitted from this survey. >=20 > I don't think I see how TCP-AO and IPsec AH lack "agility". Could you > clarify what was intended? Removed this, and just list confidentiality and privacy protections now. >=20 > Section 1.2 >=20 > It is not a goal to allow software implementations to automatically > switch between different security protocols, even where their > interfaces to transport and applications are equivalent. Even > between versions, security protocols have subtly different = guarantees > and vulnerabilities. [...] >=20 > Another impactful distinction between security protocols is in how = they > name and authenticate the communications peer -- I can't imagine = writing > a useful API that tries to abstract out the X.509 DNS-ID naming for = TLS, > SSH host key fingerprints, etc. Good point! Added: "Different security protocols also can use incompatible notions of peer = identity and authentication, and cryptographic options. It is not a goal = to identify a common set of representations for these concepts." >=20 > Section 2 >=20 > Should we reference RFC 8095 at the appropriate definitions [that we > duplicate from it]? Added the reference. >=20 > * Transport Protocol: an implementation that provides one or more > different transport services using a specific framing and header > format on the wire. A Transport Protocol services an = application. >=20 > (whether directly or with an intermediating security protocol?) Used your suggested text. >=20 > Section 3.1.1 >=20 > protocol. The handshake protocol is used to authenticate peers, > negotiate protocol options, such as cryptographic algorithms, and > derive session-specific keying material. The record protocol is = used > to marshal (possibly encrypted) data from one peer to the other. >=20 > My inference is that the "possibly encrypted" is supposed to refer to > the encryption performed by the TLS record layer itself, as opposed to > having already-encrypted data supplied to TLS as "Application Data". = If > correct, I'd suggest rewording to "is used to marshal and, once the > handshake has sufficiently progressed, encrypt, data from one peer to > the other". Used your suggested text. >=20 > Section 3.1.2 >=20 > DTLS doesn't provide "the same security guarantees as TLS" in the > general case. Specifically, redord replay detection is only optional = in > DTLS whereas it is inherently provided in TLS. We added a reference to DTLS 1.3, and shameless lift the text from that = draft: "DTLS modifies the protocol to make sure it can still provide equivalent = security guarantees to TLS with the exception of order = protection/non-replayability." >=20 > Section 3.4.2 >=20 > WireGuard is an IP-layer protocol designed as an alternative to = IPsec > [WireGuard] for certain use cases. It uses UDP to encapsulate IP >=20 > Please move the location of the reference; it currently scans like = it's > a reference for IPsec(!). Good point, fixed! >=20 > Section 5.1 >=20 > * Identities and Private Keys (IPK): The application can provide = its > identities (certificates) and private keys, or mechanisms to > access these, to the security protocol to use during handshakes. >=20 > I think it would be more accurate to say "provide its identity, > credentials (e.g., certificates), and private keys" -- a certificate = is > not exactly an identity, but rather an attestation thereof provided by = a > (nominally) trusted authority. Not all security protocols use > certificates in all cases, so I also think the "e.g." is appropriate. Fixed. >=20 > Section 5.2 >=20 > * Source Address Validation (SAV): The handshake protocol may > delegate validation of the remote peer that has sent data to the > transport protocol or application. This involves sending a = cookie > exchange to avoid DoS attacks. >=20 > I'm not sure I understand the intent of using the word "delegate" = here. Changed to "The handshake protocol may interact with the transport = protocol or application to validate the address of the remote peer that = has sent data.=E2=80=9D >=20 > * Mobility Events (ME): The record protocol can be signaled that it > is being migrated to another transport or interface due to > connection mobility, which may reset address and state validation > and induce state changes such as use of a new Connection > Identifier (CID). >=20 > I think it's expected that DTLS 1.3 will do this (though I note that = you > aren't currently referencing DTLS 1.3). Added a reference to DTLS 1.3 and listed it here. >=20 > Section 8 >=20 > omitted from this survey. All security protocols surveyed generally > improve privacy by reducing information leakage via encryption. >=20 > nit: I suggest "improve privacy by using encryption to reduce > information leakage" (to avoid the misparse of "reducing (information > (leakage via encryption))"). Used your suggested text. Thanks, Tommy --Apple-Mail=_ABC44262-2C03-4700-9B21-8AE4E63CB4A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

Thanks for the = detailed review! You can find an updated version of the document = here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

We did rename IKEv2 + ESP to simply = IPsec, at the recommendation of ipsecme. We explain those individual = protocols in the IPsec section, but do not reference them = elsewhere.

Responses to your specific points inline.

On Apr = 8, 2020, at 3:35 PM, Benjamin Kaduk via Datatracker <noreply@ietf.org> = wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-taps-transport-security-11: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I do wonder whether the Generic = Security Service API (RFC 2743) was
considered by the WG = in the production of this document.  It reflects a
somewhat dated snapshot of what was believed to be necessary = security
APIs, but may not be entirely without value for = this type of survey.

Thanks for = the pointer to that document. We did review it (and I for one had not = seen it before!). We chose not to add a reference for now, as there = didn=E2=80=99t seem any obvious place to put a reference. That document = seems to specify a specific generic API, whereas we=E2=80=99re more = talking about how the shape of security protocols fit into = transports.

It's a little surprising to = not list a reference for QUIC in its
mentions in Sections = 1 and 3, with the first reference occuring in
Section = 3.3.1.

We=E2=80=99ve moved the reference for this earlier in = the document.

Section 1

  set, protocols that do not offer new features = are omitted.  For
  example, newer = protocols such as WireGuard make unique design choices
=   that have implications and limitations on application usage. =  In

nit: "implications for" and = "limitations on=E2=80=9D.

Indeed! Fixed.

=   protection.  Despite these improvements, neither = protocol sees
  general use and both lack = critical properties important for emergent
=   transport security protocols: confidentiality, privacy = protections,
  and agility.  Such = protocols are thus omitted from this survey.

I don't think I see how TCP-AO and IPsec AH lack "agility". =  Could you
clarify what was intended?

Removed = this, and just list confidentiality and privacy protections now.

Section 1.2

=   It is not a goal to allow software implementations to = automatically
  switch between different = security protocols, even where their
=   interfaces to transport and applications are equivalent. =  Even
  between versions, security = protocols have subtly different guarantees
=   and vulnerabilities.  [...]

Another impactful distinction between security protocols is = in how they
name and authenticate the communications peer = -- I can't imagine writing
a useful API that tries to = abstract out the X.509 DNS-ID naming for TLS,
SSH host key = fingerprints, etc.

Good point! Added:

"Different security protocols also can use = incompatible notions of peer identity and authentication, and = cryptographic options. It is not a goal to identify a common set of = representations for these concepts."

Section 2

Should we reference = RFC 8095 at the appropriate definitions [that we
duplicate = from it]?

Added the reference.

=   *  Transport Protocol: an implementation that provides = one or more
     different = transport services using a specific framing and header
=      format on the wire.  A Transport = Protocol services an application.

(whether = directly or with an intermediating security protocol?)

Used = your suggested text.


Section = 3.1.1

  protocol.  The = handshake protocol is used to authenticate peers,
=   negotiate protocol options, such as cryptographic = algorithms, and
  derive session-specific = keying material.  The record protocol is used
=   to marshal (possibly encrypted) data from one peer to the = other.

My inference is that the "possibly = encrypted" is supposed to refer to
the encryption = performed by the TLS record layer itself, as opposed to
having already-encrypted data supplied to TLS as "Application = Data".  If
correct, I'd suggest rewording to "is used = to marshal and, once the
handshake has sufficiently = progressed, encrypt, data from one peer to
the other".

Used your = suggested text.

Section 3.1.2

DTLS doesn't provide "the same security guarantees as TLS" in = the
general case.  Specifically, redord replay = detection is only optional in
DTLS whereas it is = inherently provided in TLS.

We added a = reference to DTLS 1.3, and shameless lift the text from that = draft:

"DTLS modifies the protocol = to make sure it can still provide equivalent security guarantees to TLS = with the exception of order protection/non-replayability."

Section 3.4.2

=   WireGuard is an IP-layer protocol designed as an alternative = to IPsec
  [WireGuard] for certain use cases. =  It uses UDP to encapsulate IP

Please = move the location of the reference; it currently scans like it's
a reference for IPsec(!).

Good = point, fixed!

Section 5.1

  *  Identities and Private Keys (IPK): The = application can provide its
=      identities (certificates) and private = keys, or mechanisms to
=      access these, to the security protocol to = use during handshakes.

I think it would be = more accurate to say "provide its identity,
credentials = (e.g., certificates), and private keys" -- a certificate is
not exactly an identity, but rather an attestation thereof = provided by a
(nominally) trusted authority.  Not all = security protocols use
certificates in all cases, so I = also think the "e.g." is appropriate.

Fixed.

Section 5.2

=   *  Source Address Validation (SAV): The handshake = protocol may
     delegate = validation of the remote peer that has sent data to the
=      transport protocol or application. =  This involves sending a cookie
=      exchange to avoid DoS attacks.

I'm not sure I understand the intent of using = the word "delegate" here.

Changed to "The handshake protocol may interact with = the transport protocol or application to validate the address of the = remote peer that has sent data.=E2=80=9D

=   *  Mobility Events (ME): The record protocol can be = signaled that it
     is being = migrated to another transport or interface due to
=      connection mobility, which may reset = address and state validation
=      and induce state changes such as use of a = new Connection
     Identifier = (CID).

I think it's expected that DTLS 1.3 = will do this (though I note that you
aren't currently = referencing DTLS 1.3).

Added a reference to DTLS 1.3 and listed it here.

Section 8

=   omitted from this survey.  All security protocols = surveyed generally
  improve privacy by = reducing information leakage via encryption.

nit: I suggest "improve privacy by using encryption to = reduce
information leakage" (to avoid the misparse of = "reducing (information
(leakage via encryption))").

Used your = suggested text.

Thanks,
Tommy

= --Apple-Mail=_ABC44262-2C03-4700-9B21-8AE4E63CB4A5-- From nobody Wed Apr 22 10:28:32 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7415E3A112F; Wed, 22 Apr 2020 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=apple.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 krp5bpOpS-w1; Wed, 22 Apr 2020 10:28:27 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 32ED33A1130; Wed, 22 Apr 2020 10:28:27 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHN8hY030830; Wed, 22 Apr 2020 10:28:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=SHF89Uqet8IJvx1X9+AnkqKIE9fckyHnLbZWDn7+S8E=; b=OjUOtqjzV3VomfEMOLMUibJ0WrQg2CWKFbsKPb+VG1znTAjPbkYLlB8YmmCVnxzeYei2 9H/DTo92LsQMfYB53EgJzJBYTbm0WCkZ/KE+c+wl42IYgh3iCRantnRHX9TkRQMO/dvu MSflWbuzX9stdcFfJFakm3gAH3Qe28HXcHpBhHdobkaD2fFVfBDCdgdwcbsQmpC67mtB D/53h/5QdX/DBOoN9AcaQ5U9NSaH/cIhFVFNYH58Wsnb4hiAicyo/VM/GMxVKqogq1bz 2LlmQp3Ljr7bDXW9ST7c+L+RxEr/KHyPezGXmA41A8ieIyAMb8ZVWU/l1PQeXxkQ3xCV Vw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 30hj73bpy1-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:28:23 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q9700YJW9VAAB00@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:28:22 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q97008009LGLW00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:28:22 -0700 (PDT) X-Va-A: X-Va-T-CD: 8d1cba59968dbf39b3744d73f081bcdc X-Va-E-CD: 63423d8a375a17b595eac335f35848d7 X-Va-R-CD: b13196f5449c1b7b5961009ccff7c73e X-Va-CD: 0 X-Va-ID: a39a014b-4d42-4802-8ae2-e16836dcb351 X-V-A: X-V-T-CD: 8d1cba59968dbf39b3744d73f081bcdc X-V-E-CD: 63423d8a375a17b595eac335f35848d7 X-V-R-CD: b13196f5449c1b7b5961009ccff7c73e X-V-CD: 0 X-V-ID: 726c69a7-f990-4e9c-830c-86efc4dcd3de X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700VAC9V67710@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:28:20 -0700 (PDT) From: Tommy Pauly Message-id: <6EB77D3C-E0B2-45C2-A8B5-B7F31EDBC722@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_95C4B1A6-C233-497C-AE6C-86EB05AAAC2D" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:28:18 -0700 In-reply-to: <158644309093.3622.11128003590990110741@ietfa.amsl.com> Cc: The IESG , draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net To: =?utf-8?Q?=C3=89ric_Vyncke?= References: <158644309093.3622.11128003590990110741@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-taps-transport-security-11=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:28:30 -0000 --Apple-Mail=_95C4B1A6-C233-497C-AE6C-86EB05AAAC2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Responses to your specific points inline. > On Apr 9, 2020, at 7:38 AM, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-taps-transport-security-11: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for the work put into this document. It is really easy to = read. >=20 > After discussion with Magnus and Barry, I have cleared my DISCUSS but = I still > hope for a fix to my previous DISCUSS We incorporated the sentence that Magnus suggested. Thanks for agreeing = to this! >=20 > Please find below some non-blocking COMMENTs. An answer will still be > appreciated. >=20 > I hope that this helps to improve the document, >=20 > Regards, >=20 > -=C3=A9ric >=20 > =3D=3D previous DISCUSS =3D=3D >=20 > I question the inclusion of CurveCP in the mix as per > https://curvecp.org/addressing.html it does not seem to support IPv6. = At the > bare minimum, the I-D should mention this restriction in section 3 or = rename > section 3 from "protocol descriptions" into something less exhaustive. >=20 > (and I hope to be corrected about CurveCP IPv6 support). >=20 > =3D=3D COMMENT =3D=3D >=20 > Please respond to the IoT-directorate review by Mohit: > = https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsT= vGB2x0s > Please respond to the INT-DIR review by Brian: > = https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I = + > Gorry Fairhurst's about GRE We=E2=80=99ve responded individually to these reviews now. >=20 > Generic comment about the intended transport: all protocols analyzed = in this > document are point to point (no multicast), this should probably be = mentioned > in the introduction. Added: "This document only surveys point-to-point protocols; multicast = protocols are out of scope." >=20 > -- Section 1 -- > Is there any reason why the integrity property of IPsec AH is not = mentioned ? > Same also applies in section 2 when "security protocol" is defined. Added a note that AH provides integrity. >=20 > -- Section 3 -- > Use the wording of "record protocol" generically while the term = "record > protocol" is defined in section 2 as a blocked data transport (like in = TLS). > Suggest the use of "data transfer protocol" ? I believe the use of =E2=80=9Crecord protocol=E2=80=9D here is correct, = as the delineated data transport indeed is what we are referring to. >=20 > An important property of such protocols is to be able to traverse a = NAPT box > (that I hate)... I suggest to mention whether the analyzed protocols = support > NAT-traversal in this description section or even in the analysis = parts as > having a different view (application and network layers seeing = possibly > different IP addresses so a potential impact on the API). Thanks for bringing this up. We discussed as authors, and we don=E2=80=99t= believe that interaction with NAT traversal is in scope for our = analysis. There are, of course, transport protocols that handle this; = and some security protocols (like IKEv2) have specific NAT-T extensions. = However, this support does not modify or affect the contract between the = security and transport protocols to my understanding. Thanks, Tommy --Apple-Mail=_95C4B1A6-C233-497C-AE6C-86EB05AAAC2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eric,

Thanks for the = review! You can find an updated version of the document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

Responses to your specific points = inline.

On Apr 9, 2020, at 7:38 AM, =C3=89ric Vyncke via Datatracker = <noreply@ietf.org> wrote:

=C3=89= ric Vyncke has entered the following ballot position for
draft-ietf-taps-transport-security-11: No Objection

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-secu= rity/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thank you for the work put into = this document. It is really easy to read.

After discussion with Magnus and Barry, I have cleared my = DISCUSS but I still
hope for a fix to my previous = DISCUSS

We incorporated the sentence that Magnus suggested. = Thanks for agreeing to this!

Please find = below some non-blocking COMMENTs. An answer will still be
appreciated.

I hope that this = helps to improve the document,

Regards,

-=C3=A9ric

=3D=3D = previous DISCUSS =3D=3D

I question the = inclusion of CurveCP in the mix as per
https://curvecp.org/addressing.html it does not seem to = support IPv6. At the
bare minimum, the I-D should mention = this restriction in section 3 or rename
section 3 from = "protocol descriptions" into something less exhaustive.

(and I hope to be corrected about CurveCP IPv6 support).

=3D=3D COMMENT =3D=3D

Please respond to the IoT-directorate review by Mohit:
https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI= 78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR = review by Brian:
https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7T= Xvo_ujcI_I +
Gorry Fairhurst's about GRE

We=E2=80=99v= e responded individually to these reviews now.

Generic comment about the intended transport: all protocols = analyzed in this
document are point to point (no = multicast), this should probably be mentioned
in the = introduction.

Added:= "This document only surveys point-to-point protocols; multicast = protocols are out of scope."

-- Section 1 = --
Is there any reason why the integrity property of IPsec = AH is not mentioned ?
Same also applies in section 2 when = "security protocol" is defined.

Added a = note that AH provides integrity.

-- Section 3 = --
Use the wording of "record protocol" generically while = the term "record
protocol" is defined in section 2 as a = blocked data transport (like in TLS).
Suggest the use of = "data transfer protocol" ?
I believe the use of =E2=80=9Crecord protocol=E2=80= =9D here is correct, as the delineated data transport indeed is what we = are referring to.


An important = property of such protocols is to be able to traverse a NAPT box
(that I hate)... I suggest to mention whether the analyzed = protocols support
NAT-traversal in this description = section or even in the analysis parts as
having a = different view (application and network layers seeing possibly
different IP addresses so a potential impact on the API).

Thanks for = bringing this up. We discussed as authors, and we don=E2=80=99t believe = that interaction with NAT traversal is in scope for our analysis. There = are, of course, transport protocols that handle this; and some security = protocols (like IKEv2) have specific NAT-T extensions. However, this = support does not modify or affect the contract between the security and = transport protocols to my understanding.

Thanks,
Tommy

= --Apple-Mail=_95C4B1A6-C233-497C-AE6C-86EB05AAAC2D-- From nobody Wed Apr 22 10:40:34 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60523A107A; Wed, 22 Apr 2020 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=apple.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 oIsNYnnfg3Oy; Wed, 22 Apr 2020 10:40:29 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 A989A3A1085; Wed, 22 Apr 2020 10:40:28 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHKubf009136; Wed, 22 Apr 2020 10:40:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=vJ2b6JqtxWjFG+u9sMDweo9mmEjM58RJYgtSwdMi6j8=; b=MCIsuQViGhsylvm/vHzVxPxJ+kgibuO6VrAYCmxRziXxJqR4np+lqnaqsLBM4hjFKhos ATIWDajEl9HESPGpWLY7f/LqBhrfwzKJnAbtkiTV8tYaC53vNH+iPK5nCoB9nCRVNDqT q8aI2oqCu1D4nmLiCGCTLm8R1oBaFdHP2spTXnAtMS/EW9TYCPbZdtthubciKOCSrhec uiaEy3dwPbB0acrLijVhFtuIPychPwpT/ll3fhy1z2bwXwzig50bd4DVTPZsAqZo4iqj 3vPkzh/4nXDmWbwPbUDZ82H5rNbOLjzjXpOVe5DxizKIYXzr8+Twk26gQWu26QLc1RAA Og== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30hfm8qg38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:40:27 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q97007EYAFE4O40@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q97008009LCHV00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT) X-Va-A: X-Va-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0 X-Va-E-CD: 7d5012b5022cd168c2069f5acb778cdc X-Va-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017 X-Va-CD: 0 X-Va-ID: bdeca734-cb6c-49b6-bdc4-53d326a446d7 X-V-A: X-V-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0 X-V-E-CD: 7d5012b5022cd168c2069f5acb778cdc X-V-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017 X-V-CD: 0 X-V-ID: 7691e565-f993-4609-a630-8f1b3c4d2fa9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700F9FAFBRC00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:25 -0700 (PDT) From: Tommy Pauly Message-id: <27E233E4-CD15-477C-9FE2-A6191ADB6E0F@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:40:23 -0700 In-reply-to: <158696570597.6243.17363184130849112053@ietfa.amsl.com> Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org To: Paul Wouters References: <158696570597.6243.17363184130849112053@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [Taps] Secdir telechat review of draft-ietf-taps-transport-security-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:40:32 -0000 --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Responses inline. > On Apr 15, 2020, at 8:48 AM, Paul Wouters via Datatracker = wrote: >=20 > Reviewer: Paul Wouters > Review result: Has Nits >=20 > I have reviewed this document as part of the security directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written primarily for the benefit of the security area = directors. > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > The summary of the review is Has Nits >=20 > Compared to my last review (-09) a lot of text has been removed, = reducing the > technical details and giving a briefer (but arguably cleaner) = overview. >=20 > I do still have a personal preference of dropping CurveCP and MinimalT = as I > don't really think these are anything but abandoned research items. I = have > never seen or heard of these being deployed. I would be more tempted = to list > openconnect (draft-mavrogiannopoulos-openconnect) which actually does = see quite > some deployment. If the intent is really to show different kind of = API's, than > there are other esoteric examples that could be included, such as > Off-The-Record(OTR) or Signal, which are mostly encrypted chat = programs, but > with the ability to generate session keys for encrypted bulk transport = (eg for > video/audio or file transfer) We discussed for Signal and OTR. Our sense was that these protocols are = more asynchronous application-layer protocols that are akin to MLS, that = can be more independent from a transport layer. >=20 > Section 5.1 >=20 > "Session Cache Management (CM):" which does not include IKEv2/IPsec, = even > though it does have session resumption (RFC 5723). I guess this is = because the > section limits itself to "the application" that can restart the = session. But > for IKEv2/IPsec the same could be said. An application that after a = long idle > period sends a packet, triggers a kernel ACQUIRE, which triggers an = IKEv2 > session resumption. WireGuard does not have this capability as there = are no > API/hooks for packet trigger tunnel events (AFAIK) Indeed, this refers to an explicit interface for cache management. >=20 > "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not = support > PSK based authentication - only public key based authentication. We discussed that WireGuard uses the IKpsk2 Noise pattern (see = https://www.wireguard.com/protocol/, and = https://noiseexplorer.com/patterns/IKpsk2/), in which a responder uses = its PSK to additionally authenticate a connection. > While I > understand the IKEv2 entry (PSKs are used for authentication of = peers), I am > not sure the ESP entry should be here. ESP does not "authenticate = peers", > unless you call "being able to decrypt and authenticate packets" as an = instance > of "authenticating peer" We=E2=80=99ve changed the reference to be IPsec as a unit for IKEv2 + = ESP in these lists. >=20 > Section 5.2 >=20 > This states "This can call into the application to offload = validation.". This > "can" is only not supported by WireGuard, as all of this is happening = inside > the kernel. Maybe a note could be useful here? Switched to "This can offload validation or occur transparently to the = application." >=20 > "Source Address Validation" - It is a little unclear why TCP based = protocols > are not listed here. They (implicitly) do source address validation. = Perhaps > the introduction in this paragraph can state this more explicitly. Eg = "for > those protocols that do not use TCP and therefor do not have builtin = source > address validation ......." We clarify here that: "Of the protocols listed above that depend on the transport for message = framing, some do have well-defined mappings for sending their messages = over byte-stream transports like TCP.=E2=80=9D Thanks, Tommy >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul,

Thanks for the review! You can find an updated version of the = document here:

https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

Responses inline.


On Apr 15, 2020, at 8:48 AM, = Paul Wouters via Datatracker <noreply@ietf.org> wrote:

Reviewer: Paul Wouters
Review result: Has = Nits

I have reviewed this document as part = of the security directorate's  ongoing
effort to = review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the = security area directors.
Document editors and WG chairs = should treat these comments just like any other
last call = comments.

The summary of the review is Has = Nits

Compared to my last review (-09) a lot = of text has been removed, reducing the
technical details = and giving a briefer (but arguably cleaner) overview.

I do still have a personal preference of dropping CurveCP and = MinimalT as I
don't really think these are anything but = abandoned research items. I have
never seen or heard of = these being deployed. I would be more tempted to list
openconnect (draft-mavrogiannopoulos-openconnect) which = actually does see quite
some deployment. If the intent is = really to show different kind of API's, than
there are = other esoteric examples that could be included, such as
Off-The-Record(OTR) or Signal, which are mostly encrypted = chat programs, but
with the ability to generate session = keys for encrypted bulk transport (eg for
video/audio or = file transfer)

We discussed for Signal and OTR. Our sense was that = these protocols are more asynchronous application-layer protocols that = are akin to MLS, that can be more independent from a transport layer.

Section 5.1

= "Session Cache Management (CM):" which does not include IKEv2/IPsec, = even
though it does have session resumption (RFC 5723). I = guess this is because the
section limits itself to "the = application" that can restart the session. But
for = IKEv2/IPsec the same could be said. An application that after a long = idle
period sends a packet, triggers a kernel ACQUIRE, = which triggers an IKEv2
session resumption. WireGuard = does not have this capability as there are no
API/hooks = for packet trigger tunnel events (AFAIK)

Indeed,= this refers to an explicit interface for cache = management.


"Pre-Shared = Key Import (PSKI):" lists WireGuard, but AFAIK it does not support
PSK based authentication - only public key based = authentication.

We = discussed that WireGuard uses the IKpsk2 Noise pattern (see https://www.wireguard.com/protocol/, = and https://noiseexplorer.com/patterns/IKpsk2/), in which a = responder uses its PSK to additionally authenticate a = connection.

While I
understand the IKEv2 = entry (PSKs are used for authentication of peers), I am
not = sure the ESP entry should be here. ESP does not "authenticate peers",
unless you call "being able to decrypt and authenticate = packets" as an instance
of "authenticating peer"

We=E2=80= =99ve changed the reference to be IPsec as a unit for IKEv2 + ESP in = these lists.


Section 5.2

This states "This can call into the application to offload = validation.".  This
"can" is only not supported by = WireGuard, as all of this is happening inside
the kernel. = Maybe a note could be useful here?

Switched = to "This can offload validation or occur transparently to the = application."

"Source Address Validation" - = It is a little unclear why TCP based protocols
are not = listed here. They (implicitly) do source address validation. Perhaps
the introduction in this paragraph can state this more = explicitly. Eg "for
those protocols that do not use TCP = and therefor do not have builtin source
address validation = ......."

We clarify here that:

"Of the protocols listed above that depend on the = transport for message framing, some do have well-defined mappings for = sending their messages over byte-stream transports like = TCP.=E2=80=9D

Thanks,
Tommy



_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354-- From nobody Wed Apr 22 10:52:44 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68C3A0FE0; Wed, 22 Apr 2020 10:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, 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 ndfv_lmGl5hu; Wed, 22 Apr 2020 10:52:30 -0700 (PDT) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) (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 826163A07AB; Wed, 22 Apr 2020 10:52:30 -0700 (PDT) Received: by mail-il1-f193.google.com with SMTP id i16so2800695ils.12; Wed, 22 Apr 2020 10:52:30 -0700 (PDT) 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=7Z3iKl6B8Jv8Dtqc4HMKzht0l/ZF/Fcyfw+mNS3srpg=; b=tdGhwoYZ0yC45WPxh3tUOrMl5AlaVBsh463qvGyyp3xw5yr2aSTyl74vV0Mtj/vW9V gvyJG1Dp7IAUtS9grg8xEfZNr/8+7UG9iB+wxrVlv31pScCIErqtIqXxmKyHSnUtUNt1 AMtEYFqZa5I6uD+QBylCcszRmP3nBub54ACEUvsXSdQk3AiLztLr7GvSPHkbWKr5CVIs qZMB815/ROf+kTYBwlqfQf3F/WY3U3xYt4jcfyuJeXxLM08aGVTkHLxPbMkxjh7qO3nw XclkvykhkbM5KYxiGmcQn/ckb41py0RC3RNv7cPb5knOqSxa34yn4Z0oFE+ZSo9BHh/q N+xA== X-Gm-Message-State: AGi0Pua1y4GwLmwIDRmDTYPwTJwI3uB0Ok6Fc0KjpEf1lyIGC4ucFInm 1eYYOCQ49lVLjqr0ppPf7ZN4eMTO18jJw7cN+WE= X-Google-Smtp-Source: APiQypIQ/8YyC0cZurN3qRST6rz/KP/zkO6+UpY8R3J2DkUKMygYJr8zFcTP0tuKlPpDjyQAdtnf5kt1FxnmhcZj4B4= X-Received: by 2002:a92:1d5c:: with SMTP id d89mr27550522ild.140.1587577949500; Wed, 22 Apr 2020 10:52:29 -0700 (PDT) MIME-Version: 1.0 References: <158632492387.9927.14911806705395970669@ietfa.amsl.com> <1C6D2F3A-D3CE-4474-A36C-EDEBB0475AEA@apple.com> In-Reply-To: <1C6D2F3A-D3CE-4474-A36C-EDEBB0475AEA@apple.com> From: Barry Leiba Date: Wed, 22 Apr 2020 13:52:18 -0400 Message-ID: To: Tommy Pauly Cc: The IESG , draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , Christopher Wood Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Barry Leiba's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 17:52:34 -0000 Thanks, Tommy... all good! Barry On Wed, Apr 22, 2020 at 1:11 PM Tommy Pauly wrote: > > Hi Barry, > > Thanks for the review! You can find an updated version of the document he= re: > > https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ie= tf-taps-transport-security.html > > Responses to your individual points inline. > > > On Apr 7, 2020, at 10:48 PM, Barry Leiba via Datatracker wrote: > > Barry Leiba has entered the following ballot position for > draft-ietf-taps-transport-security-11: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this helpful document. Just some editorial comments beyond wh= at > others have mentioned: > > =E2=80=94 Section 1 =E2=80=94 > > It examines Transport Layer Security > (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google > QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating > Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, > CurveCP, and MinimalT. > > It=E2=80=99s funny that this carefully expands every abbreviation except = =E2=80=9CSRTP=E2=80=9D. > Please do that one too. > > > Expanded! > > > Ubiquitous IETF protocols such as (D)TLS, as well as non-standard > protocols such as gQUIC, are both included > > The word =E2=80=9Cboth=E2=80=9D doesn=E2=80=99t work here. I think a rea= sonable fix is just to remove > the single word. Maybe a better fix is to slightly reword, as, =E2=80=9C= Ubiquitous > IETF protocols such as (D)TLS are included, and so are non-standard proto= cols > such as gQUIC, despite...=E2=80=9D > > > Fixed by removing the word. > > > =E2=80=94 Section 1.1 =E2=80=94 > > For example, a security > protocol that expects to run over a reliable stream of bytes, like > TLS, restrict the set of transport protocols that can be used > Number agreement: make it =E2=80=9Crestricts=E2=80=9D to match the singul= ar subject =E2=80=9Ca security > protocol=E2=80=9D. > > > Fixed. > > > =E2=80=94 Section 2 =E2=80=94 > > Examples include > confidentiality, reliable delivery, ordered delivery, message- > versus-stream orientation, etc. > > You don=E2=80=99t need both =E2=80=9Cexamples include=E2=80=9D and =E2=80= =9Cetc.=E2=80=9D; I suggest eliminating the > latter (and sticking in an =E2=80=9Cand=E2=80=9D). > > > Fixed. > > > =E2=80=94 Section 3.1.1 =E2=80=94 > > to marshal (possibly encrypted) data from one peer to the other. > > Possibly? I understand you=E2=80=99re covering the handshake there as we= ll, but for a > summary as (reasonably) brief as this I think it=E2=80=99s misleading to = say =E2=80=9Cpossibly=E2=80=9D. > > > This is now: > > "The record protocol is used to marshal and, once the handshake has suffi= ciently progressed, encrypt, data from one peer to the other. " > > > =E2=80=94 Section 3.2.1 =E2=80=94 > > ZRTP [RFC6189] is an alternative key agreement and identity > management protocols for SRTP. > > Number agreement: =E2=80=9Cprotocol=E2=80=9D > > > Fixed! > > > =E2=80=94 Section 3.4.3 =E2=80=94 > > For key establishment, OpenVPN can use TLS as a handshake protocol or > pre-shared keys. > > This reads oddly, as though there are two things OpenVPN can use TLS for.= I > would make it, =E2=80=9C...or it can use pre-shared keys.=E2=80=9D > > > Changed to: > > "For key establishment, OpenVPN can either use TLS as a handshake protoco= l or use pre-shared keys." > > > =E2=80=94 Section 5.1 =E2=80=94 > > * Extensions (Application-Layer Protocol Negotiation) (EXT): The > application enables or configures extensions that are to be > negotiated by the security protocol, such as ALPN [RFC7301]. > > Isn=E2=80=99t the expansion of =E2=80=9CALPN=E2=80=9D misplaced here? > > > This is now written out in expanded form "Application-Layer Protocol Nego= tiation (ALPN) [RFC7301]" > > > > > Thanks, > Tommy > From nobody Thu Apr 23 09:20:40 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 544A13A0BF0; Thu, 23 Apr 2020 09:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <158765883826.23473.5468189432827541343@ietfa.amsl.com> Date: Thu, 23 Apr 2020 09:20:38 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-12.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 16:20:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of the Interaction Between Security Protocols and Transport Services Authors : Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-12.txt Pages : 23 Date : 2020-04-23 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-12 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 24 01:02:23 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8863A3A0EE2 for ; Fri, 24 Apr 2020 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ZfajTyeJ56wR for ; Fri, 24 Apr 2020 01:02:19 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 BFDAE3A03EC for ; Fri, 24 Apr 2020 01:02:17 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1jRtFm-0006yy-Hw for taps@ietf.org; Fri, 24 Apr 2020 08:00:06 +0000 Content-Type: multipart/alternative; boundary="===============1229132386364742717==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 24 Apr 2020 08:00:06 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2020 08:02:22 -0000 --===============1229132386364742717== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+4/-7/=F0=9F=92=AC12) 4 issues created: - How do you add multiple IP addresses/interfaces to an endpoint? (by mir= jak) https://github.com/ietf-tapswg/api-drafts/issues/571 = - NiTs in section 1 (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/569 [API] [editorial] = - Namespaces based on IANA protocol numbers registry (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/568 [API] [discuss] [h= elp wanted] = - Three oddities in the abstract? (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/567 [API] [editorial] = 8 issues received 12 new comments: - #523 Registry for "interface instance or type" (from Kyle Rose's revie= w) (4 by tfpauly, csperkins) https://github.com/ietf-tapswg/api-drafts/issues/523 [API] [ready for t= ext] = - #477 Is format of message an implementation detail? (2 by mwelzl, csper= kins) https://github.com/ietf-tapswg/api-drafts/issues/477 [API] = - #441 Questions on Connection Groups (1 by csperkins) https://github.com/ietf-tapswg/api-drafts/issues/441 [API] = - #518 Architecture NiT: /assumes/ (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/518 [Architecture] [re= ady for text] = - #457 Framers again... (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/457 [API] [Implementat= ion] [discuss] = - #567 Three oddities in the abstract? (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/567 [API] [editorial] = - #568 Namespaces based on IANA protocol numbers registry (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/568 [API] [discuss] = - #537 Recommendations for Delayed Racing (1 by csperkins) https://github.com/ietf-tapswg/api-drafts/issues/537 [Implementation] = 7 issues closed: - Three oddities in the abstract? https://github.com/ietf-tapswg/api-draf= ts/issues/567 [API] [editorial] = - single messageContext object for both sends and receives https://github= .com/ietf-tapswg/api-drafts/issues/525 [API] = - Create an enum for querying properties https://github.com/ietf-tapswg/a= pi-drafts/issues/528 [API] [ready for text] = - Idempotency vs replay-safe (from Kyle Rose's review) https://github.co= m/ietf-tapswg/api-drafts/issues/522 [API] [discuss] = - Architecture NiT: /assumes/ https://github.com/ietf-tapswg/api-drafts/i= ssues/518 [Architecture] [ready for text] = - Add state diagram to section "Connection State and Ordering of Operatio= ns and Events" https://github.com/ietf-tapswg/api-drafts/issues/466 [API] = - Reliable Data Transfer (Message) default - from Kyle Rose's review http= s://github.com/ietf-tapswg/api-drafts/issues/520 [API] [discuss] = Pull requests ------------- * ietf-tapswg/api-drafts (+5/-8/=F0=9F=92=AC4) 5 pull requests submitted: - NiTs in section 1 (by gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/573 = - Update draft-ietf-taps-interface.md (by gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/572 = - clarify that taps interface types are implementation specific, fix #523= (by britram) https://github.com/ietf-tapswg/api-drafts/pull/570 = - clarify framers in preconnection, fix #427 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/566 = - Sentence about minIncompleteLength when rcv. on streams (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/565 [Implementation] = 3 pull requests received 4 new comments: - #512 Update Multipath properties - closes #437 (2 by philsbln, tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/512 [API] = - #541 Added a selection property for a special communication pattern (1 = by csperkins) https://github.com/ietf-tapswg/api-drafts/pull/541 [API] = - #564 Consolidate normative language in architecture (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/564 [Architecture] = 8 pull requests merged: - Consolidate normative language in architecture https://github.com/ietf-tapswg/api-drafts/pull/564 [Architecture] = - NiTs in section 1 https://github.com/ietf-tapswg/api-drafts/pull/573 [API] [editorial] = - Fix three oddities in the abstract of draft-ietf-taps-interface https://github.com/ietf-tapswg/api-drafts/pull/572 [API] [editorial] = - Define a new type to use when selection properties are queried https://github.com/ietf-tapswg/api-drafts/pull/557 [API] = - Replace "idempotent" with "safely replayable" everywhere https://github.com/ietf-tapswg/api-drafts/pull/561 [API] [Implementatio= n] = - Architecture NiT: /assumes/ https://github.com/ietf-tapswg/api-drafts/pull/560 [Architecture] = - Connection state diagram https://github.com/ietf-tapswg/api-drafts/pull/562 [API] = - Clarifications about per-connection vs per-message defaults https://github.com/ietf-tapswg/api-drafts/pull/558 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============1229132386364742717== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday April 24, 2020

Issues

ietf-tapswg/api-drafts (+4/-7/=F0=9F=92=AC12)

4 issues created:

8 issues received 12 new comments:

7 issues closed:

Pull requests

ietf-tapswg/api-drafts (+5/-8/=F0=9F=92=AC4)

5 pull requests submitted:

3 pull requests received 4 new comments:

8 pull requests merged:

Repositories tracked by this digest:

--===============1229132386364742717==-- From nobody Sat Apr 25 05:44:16 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED423A0D40 for ; Sat, 25 Apr 2020 05:44:14 -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, 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 GsKtMMuYGLim for ; Sat, 25 Apr 2020 05:44:12 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 906583A0D3D for ; Sat, 25 Apr 2020 05:44:11 -0700 (PDT) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jSKAD-0005BC-FQ for taps@ietf.org; Sat, 25 Apr 2020 14:44:09 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jSKAC-0007n2-Ob for taps@ietf.org; Sat, 25 Apr 2020 14:44:09 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Sat, 25 Apr 2020 14:44:07 +0200 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; 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: 356F89671C840F2BD962B988701983F8EC0885C8 Archived-At: Subject: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 12:44:15 -0000 Dear all, I know way too little about rendezvous mechanisms, so I may get this = completely wrong - please bear with me! It may be that I describe an issue that=E2=80=99s a non-issue. But, if I = do understand this right, maybe that=E2=80=99s something which needs = fixing? Ok, here it goes=E2=80=A6 Our current Rendezvous text in the API draft says the following: "The Rendezvous() Action causes the Preconnection to listen on the Local = Endpoint for an incoming Connection from the Remote Endpoint, while = simultaneously trying to establish a Connection from the Local Endpoint = to the Remote Endpoint. This corresponds to a TCP simultaneous open, for = example.=E2=80=9D Now, if an application chooses unreliable data transmission, it may get = SCTP with partial reliability, or it may (in the future) get QUIC with = datagrams, or whatever=E2=80=A6 and then, the protocol may be able to = do what=E2=80=99s needed (something similar to a simultaneous open). However, in case of UDP: - Listening is quite okay, - =E2=80=9Csimultaneously trying to establish a Connection=E2=80=9D = really means nothing - no packet will be sent. I believe that applications doing this over UDP will implement their own = =E2=80=9CSYN=E2=80=9D-type signal for this - but then it=E2=80=99s up to = the application, which, over TAPS, would need to: - create a passive connection, - send a Message from that same connection, i.e. using the same local = address and port (I believe?) - which is a matter of configuring the = local endpoint, and doable if the underlying transport system can pull = it off. I think there=E2=80=99s nothing in our API preventing an = application from doing this. If all of the above is correct, the problem that I see is that an = application may ask for unreliable transmission, and then have one case = in which calling =E2=80=9CRendezvous=E2=80=9D is the right thing to do, = and another case in which it is not - so it would need to be able to = distinguish between these two cases: is it a protocol with = Rendezvous-capability, or do I have to do it myself. Maybe, in case of = UDP, the call to Rendezvous should just fail, and our text should say = that Rendezvous failing would inform the application that it would have = to implement it by itself, by issuing Listen and then sending a Message = to the peer. Thoughts? Am I completely off track, or is this something that needs a = text fix? Cheers, Michael From nobody Sat Apr 25 14:24:55 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2273A0986; Sat, 25 Apr 2020 14:24:53 -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, SPF_HELO_NONE=0.001, 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 4eBJ-JBIiRJb; Sat, 25 Apr 2020 14:24:51 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 750803A0988; Sat, 25 Apr 2020 14:24:51 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03PLOb3w029333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 25 Apr 2020 17:24:39 -0400 Date: Sat, 25 Apr 2020 14:24:36 -0700 From: Benjamin Kaduk To: Tommy Pauly Cc: The IESG , draft-ietf-taps-transport-security@ietf.org, taps-chairs@ietf.org, taps@ietf.org, Philipp Tiesel , caw@heapingbits.net Message-ID: <20200425212436.GK27494@kduck.mit.edu> References: <158638531056.18357.11401006659618104728@ietfa.amsl.com> <027BEF88-CB63-4F2F-90E2-9A407EC19D93@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <027BEF88-CB63-4F2F-90E2-9A407EC19D93@apple.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Taps] Benjamin Kaduk's No Objection on draft-ietf-taps-transport-security-11: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 21:24:54 -0000 Hi Tommy, also inline. On Wed, Apr 22, 2020 at 10:23:51AM -0700, Tommy Pauly wrote: > Hi Ben, > > Thanks for the detailed review! You can find an updated version of the document here: > > https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html > > We did rename IKEv2 + ESP to simply IPsec, at the recommendation of ipsecme. We explain those individual protocols in the IPsec section, but do not reference them elsewhere. > > Responses to your specific points inline. > > > On Apr 8, 2020, at 3:35 PM, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-taps-transport-security-11: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I do wonder whether the Generic Security Service API (RFC 2743) was > > considered by the WG in the production of this document. It reflects a > > somewhat dated snapshot of what was believed to be necessary security > > APIs, but may not be entirely without value for this type of survey. > > Thanks for the pointer to that document. We did review it (and I for one had not seen it before!). We chose not to add a reference for now, as there didn’t seem any obvious place to put a reference. That document seems to specify a specific generic API, whereas we’re more talking about how the shape of security protocols fit into transports. Thanks for taking a look. I can't say I'm surprised that it ended up not really matching what you're doing, but think it was worth the time to check. > > It's a little surprising to not list a reference for QUIC in its > > mentions in Sections 1 and 3, with the first reference occuring in > > Section 3.3.1. > > We’ve moved the reference for this earlier in the document. > > > > Section 1 > > > > set, protocols that do not offer new features are omitted. For > > example, newer protocols such as WireGuard make unique design choices > > that have implications and limitations on application usage. In > > > > nit: "implications for" and "limitations on”. > > Indeed! Fixed. > > > > protection. Despite these improvements, neither protocol sees > > general use and both lack critical properties important for emergent > > transport security protocols: confidentiality, privacy protections, > > and agility. Such protocols are thus omitted from this survey. > > > > I don't think I see how TCP-AO and IPsec AH lack "agility". Could you > > clarify what was intended? > > Removed this, and just list confidentiality and privacy protections now. > > > > Section 1.2 > > > > It is not a goal to allow software implementations to automatically > > switch between different security protocols, even where their > > interfaces to transport and applications are equivalent. Even > > between versions, security protocols have subtly different guarantees > > and vulnerabilities. [...] > > > > Another impactful distinction between security protocols is in how they > > name and authenticate the communications peer -- I can't imagine writing > > a useful API that tries to abstract out the X.509 DNS-ID naming for TLS, > > SSH host key fingerprints, etc. > > Good point! Added: > > "Different security protocols also can use incompatible notions of peer identity and authentication, and cryptographic options. It is not a goal to identify a common set of representations for these concepts." Thanks. > > Section 2 > > > > Should we reference RFC 8095 at the appropriate definitions [that we > > duplicate from it]? > > Added the reference. > > > > * Transport Protocol: an implementation that provides one or more > > different transport services using a specific framing and header > > format on the wire. A Transport Protocol services an application. > > > > (whether directly or with an intermediating security protocol?) > > Used your suggested text. > > > > > Section 3.1.1 > > > > protocol. The handshake protocol is used to authenticate peers, > > negotiate protocol options, such as cryptographic algorithms, and > > derive session-specific keying material. The record protocol is used > > to marshal (possibly encrypted) data from one peer to the other. > > > > My inference is that the "possibly encrypted" is supposed to refer to > > the encryption performed by the TLS record layer itself, as opposed to > > having already-encrypted data supplied to TLS as "Application Data". If > > correct, I'd suggest rewording to "is used to marshal and, once the > > handshake has sufficiently progressed, encrypt, data from one peer to > > the other". > > Used your suggested text. > > > > Section 3.1.2 > > > > DTLS doesn't provide "the same security guarantees as TLS" in the > > general case. Specifically, redord replay detection is only optional in > > DTLS whereas it is inherently provided in TLS. > > We added a reference to DTLS 1.3, and shameless lift the text from that draft: > > "DTLS modifies the protocol to make sure it can still provide equivalent security guarantees to TLS with the exception of order protection/non-replayability." Oh good, someone other than me has put some thought into whether that's the only point of divergence, becuase I did not put a huge amount of thought into it... Reusing the text from DTLS 1.3 sounds reasonable (though I guess my AD Evaluation of DTLS 1.3 could in theory produce changes ... all the more reason to clear that part of my backlog) > > Section 3.4.2 > > > > WireGuard is an IP-layer protocol designed as an alternative to IPsec > > [WireGuard] for certain use cases. It uses UDP to encapsulate IP > > > > Please move the location of the reference; it currently scans like it's > > a reference for IPsec(!). > > Good point, fixed! > > > > Section 5.1 > > > > * Identities and Private Keys (IPK): The application can provide its > > identities (certificates) and private keys, or mechanisms to > > access these, to the security protocol to use during handshakes. > > > > I think it would be more accurate to say "provide its identity, > > credentials (e.g., certificates), and private keys" -- a certificate is > > not exactly an identity, but rather an attestation thereof provided by a > > (nominally) trusted authority. Not all security protocols use > > certificates in all cases, so I also think the "e.g." is appropriate. > > Fixed. > > > > Section 5.2 > > > > * Source Address Validation (SAV): The handshake protocol may > > delegate validation of the remote peer that has sent data to the > > transport protocol or application. This involves sending a cookie > > exchange to avoid DoS attacks. > > > > I'm not sure I understand the intent of using the word "delegate" here. > > Changed to "The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.” Ah, thanks. You would think that the name of the bullet point being "source address validation" would key me into using that interpretation of "validation" and not a cryptographic one, and yet I still managed to confuse myself the first time I read the old text. Thanks for the updates! -Ben > > * Mobility Events (ME): The record protocol can be signaled that it > > is being migrated to another transport or interface due to > > connection mobility, which may reset address and state validation > > and induce state changes such as use of a new Connection > > Identifier (CID). > > > > I think it's expected that DTLS 1.3 will do this (though I note that you > > aren't currently referencing DTLS 1.3). > > Added a reference to DTLS 1.3 and listed it here. > > > > Section 8 > > > > omitted from this survey. All security protocols surveyed generally > > improve privacy by reducing information leakage via encryption. > > > > nit: I suggest "improve privacy by using encryption to reduce > > information leakage" (to avoid the misparse of "reducing (information > > (leakage via encryption))"). > > Used your suggested text. > > Thanks, > Tommy > From nobody Sat Apr 25 14:26:52 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE73A099C; Sat, 25 Apr 2020 14:26:49 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 nb7pyMxSNW_q; Sat, 25 Apr 2020 14:26:47 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7B9E23A099B; Sat, 25 Apr 2020 14:26:47 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03PLQaYP029720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 25 Apr 2020 17:26:38 -0400 Date: Sat, 25 Apr 2020 14:26:36 -0700 From: Benjamin Kaduk To: Tommy Pauly Cc: =?iso-8859-1?Q?=C9ric?= Vyncke , Philipp Tiesel , taps-chairs@ietf.org, caw@heapingbits.net, draft-ietf-taps-transport-security@ietf.org, The IESG , taps@ietf.org Message-ID: <20200425212636.GL27494@kduck.mit.edu> References: <158644309093.3622.11128003590990110741@ietfa.amsl.com> <6EB77D3C-E0B2-45C2-A8B5-B7F31EDBC722@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6EB77D3C-E0B2-45C2-A8B5-B7F31EDBC722@apple.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Taps] =?iso-8859-1?q?=C9ric_Vyncke=27s_No_Objection_on_draft-ie?= =?iso-8859-1?q?tf-taps-transport-security-11=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2020 21:26:49 -0000 On Wed, Apr 22, 2020 at 10:28:18AM -0700, Tommy Pauly wrote: > Hi Eric, > > Thanks for the review! You can find an updated version of the document here: > > https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html > > Responses to your specific points inline. > > > On Apr 9, 2020, at 7:38 AM, ric Vyncke via Datatracker wrote: > > > > -- Section 1 -- > > Is there any reason why the integrity property of IPsec AH is not mentioned ? > > Same also applies in section 2 when "security protocol" is defined. > > Added a note that AH provides integrity. I note that per https://mailarchive.ietf.org/arch/msg/ipsec/ykyUCKWzn9i0jBgHKhIVApJPLJk/ we may not want to be adding new mention of AH. -Ben From nobody Sun Apr 26 23:56:07 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7B3A0E76; Sun, 26 Apr 2020 23:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=if2UzYl1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D4DiSQBR 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 NoY3d6NVmxXl; Sun, 26 Apr 2020 23:55:59 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C04F23A0E75; Sun, 26 Apr 2020 23:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2300; q=dns/txt; s=iport; t=1587970558; x=1589180158; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jkGatcU3fHKag1XNvshWaWSFeSdu1thre8FzVMtRPgI=; b=if2UzYl10RBvIOxiRXTFGgRtck9wZit4jbh0KxDtigmBuMOwtNhcDN+I A3HntjqiVcDLKEhZwIMMoXIjH6OH/lllxO0yit+KAfGsZIgeOulybTGbd 4V5EocTa3GIYyYo680l3MXEKCKQ9Ff93b25EvArhJQKt+JD9ZfK8qgqP4 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AzKsk6BwDpEN9StfXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuIF1z9J/3nRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AADAgaZe/5NdJa1mDgwBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQE8gUeBVFEFbFggBAsqhB+DRgOKcYI6JZgvglI?= =?us-ascii?q?DVAsBAQEMAQEnBgIEAQGERAIXgg8kOBMCAwEBCwEBBQEBAQIBBQRthVYMhXE?= =?us-ascii?q?BAQEBAxIREQwBATcBCwQCAQgQAQMBAgECAiYCAgIwFQUDCAIEAQ0FIoMEAYJ?= =?us-ascii?q?LAy4BDqYyAoE5iGF2gTKDAAEBBYUnGIIOAwaBDiqCY4laGoFBP4ERJwwQgk0?= =?us-ascii?q?+gmcCAQGEdTKCLZB/PKBrCoJFiA+KR2eEQx2DDpltg2iMEolIkz4CBAIEBQI?= =?us-ascii?q?OAQEFgWkigVZwFWUBggoBATJQGA2RNDiDOoJkgjCFBD50AgsoAgYBBwEBAwk?= =?us-ascii?q?Be44gAQE?= X-IronPort-AV: E=Sophos;i="5.73,323,1583193600"; d="scan'208";a="469316876" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Apr 2020 06:55:37 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 03R6tbJb012441 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2020 06:55:37 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 01:55:36 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 02:55:35 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Apr 2020 02:55:35 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XA26oD6nyg0pwP18AoQWzMFsWlSVFvMvKG4OKNzoFPXfnRTiAOEoa1Eu25ausagGwtWk28BG1D1VYHOqkiyETeuD7sFc//TqqJlmtGHR8qLFk2oAiR5CEIau3E7EkJdRKS2h1TCayPn0dvaRpTwgkieQ3mM9B4nzu6uNF8pvKQsguOS227VRwSYnugmSNMNvfYAbpXG7TLS+vcCw+pehA8m8LFMlfI0Ep58ngYkuH4iv5HkJoMWxzIHYEZzUByGK6HrDaBReEj/9Ly6A7FoyroRbYknFdx3ljEqUzPOUmEUteH7VpAwbfYjRlrVsGAwvU5pT5os9tffL//11bizfhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkGatcU3fHKag1XNvshWaWSFeSdu1thre8FzVMtRPgI=; b=iVpPctL+lbs38M9YUoKYeA4n/pYwyM5G5QxberQoF+dXqvAHqoceK/YnzBzV4CNDPfZLqOCUGVliaXNEs2jyw+3NMKMdEKedujYXFV997P9zUX5JF45Jxy1sjY/QwlslirfHORE3GkaC4IRz2FlpVGbc0BARGGhh6XeMRt19kqfHHXWNKJGno637gUxTkYDmCOw7bzFcGoJTAkgUFLzKg/DQHnPqpRvSoAnVGFynzyaLZjDMnl56+y+vVJVxP4J93msQDuJs403gwFA678FvCbL6LjanjZmwYM5whrHSR9bgvYJ3o2TySaNNvZTuIOfkyXCi7S8T/e23FXFNHrFLWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jkGatcU3fHKag1XNvshWaWSFeSdu1thre8FzVMtRPgI=; b=D4DiSQBRorPgAmODaUfQyZvJ8MZzUP1sTJXqMAd48nx55DE81Jvh9Gpjx3jo+kpNW9cF47cHd5g6z7CfeaEs9GfbmqVCh64YrS2bcZKDRhOTImZ9XZwTa30TWMo6G5FmyKigAQa/ObaIhx7A8S7pMqa8kCHa7aZuMvK5TJ7FLko= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1324.namprd11.prod.outlook.com (2603:10b6:3:15::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 06:55:34 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::7458:f0d0:22b2:6b0c%9]) with mapi id 15.20.2937.020; Mon, 27 Apr 2020 06:55:34 +0000 From: "Eric Vyncke (evyncke)" To: Benjamin Kaduk , Tommy Pauly CC: Philipp Tiesel , "taps-chairs@ietf.org" , "caw@heapingbits.net" , "draft-ietf-taps-transport-security@ietf.org" , The IESG , "taps@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdGFw?= =?utf-8?Q?s-transport-security-11:_(with_COMMENT)?= Thread-Index: AQHWGMtxVbZswaG6wkS1yx53TaKU3KiKXs4AgAJS04A= Date: Mon, 27 Apr 2020 06:55:34 +0000 Message-ID: <1E5731A6-5077-4B29-9672-E338CC085106@cisco.com> References: <158644309093.3622.11128003590990110741@ietfa.amsl.com> <6EB77D3C-E0B2-45C2-A8B5-B7F31EDBC722@apple.com> <20200425212636.GL27494@kduck.mit.edu> In-Reply-To: <20200425212636.GL27494@kduck.mit.edu> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:59e:b0ed:2f21:237d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c3888b9-9a79-4a93-7f9a-08d7ea77fbf1 x-ms-traffictypediagnostic: DM5PR11MB1324: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(2616005)(4326008)(110136005)(54906003)(91956017)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(86362001)(186003)(316002)(478600001)(71200400001)(36756003)(6512007)(6506007)(53546011)(966005)(8936002)(6486002)(81156014)(5660300002)(33656002)(2906002)(224303003)(15650500001)(83080400001); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QcLylD78yGV89QLuWOUs99oSKEvkmzAEJCjTZ3F7x8OKPDN1nPkaMiqRN2vuqNUVUz6c9aOb7vUZmTSxDgW0BXRtRwmqVPAFw9BOiHAO+G6pIpZXjZq+nLYfQa1Dt60lurYoQ/sGU5PxKj7meRAmXzq5LSQdrQfHqKneDHkEPZ1gyg9+dsnEqz1dtI0MbLEMNfG13romlhGRIbJhwwSfxGEm2jR5k0Zm8ulxuweu7tdawTW/m+h5UUtJBpaJRrnjaS8y+8K03NVGUxkd5YUuZUFOXC0uICl2tJ6AGVIRVUyncBSkCQV8i2Hcng3hg9a329DqhpocJf8LUvg41nZbgZMBurqtEbnWHA1art+OCSIgZ8RubnL5AACxFFDAnqkJrllL1cLXRM7QXsuZuEuG1zyKMjKt1UYIADp0FlT1pz/+lKgtPBTusrt/M0L9ctUU9V1suAyamjcHBU32E58xjr40dgP/gIAvqvgdtqMoe9dfFHJA/BdQ5GmNjFiPWmkXfwm1/9pSXeZv5TAr23VQyQ== x-ms-exchange-antispam-messagedata: GjbYF1o2e6VYsmBwwm55HqGhBBhyjIawlV35dXL2btOhABrZiiq42tNO+NL0VHxMKHIhrVP39inaDRVBYxZPR7Eq04HHBHBD92J1pAEzpFRTeXkC5J0wpsYvsV73berYhQ8ZY4bqBlxhnSReKZOhhb9iEyZNCkQiKXOtCxtRXVks24mX7FtTZLcSKLeoktI5dj9ajv04uIYjQeeHQN2lDmr5rfxQgj9mXJfY+OQ6g2zJa2UmG+h19su225Bvdi1Jq2JQ555Sb4ZLQWS0If9d30Mza7f/q1WBWNv+Gqvh5ofv1/wcT4sFpPTGSuATDWT+keL4riZSrY3qfuwXc5KLjo4e51xQoemezNPtZm5VQMDHQ+ID7aaAhvmZe2vuhk3u+hqY5r6/CJLfrV/cCSSylSbBPQ6t3otH70mlLsQTXHUCdQ1dqtY1h3Cp8g/S0hiz21DRCEdFljYnwyVifW9GtF3PliYlcdQ4uUu/rG7lAJnxg7fYVKaHPKoulqzEzQFQ3gfTFcD2wbHhhY3fp+9OBshhyqhnOjaF06Nu/WpSBepsBUKkvEW7BAXVmuCbT8YMh5yYfIv02fuxlO+gJxO3dbUAkxtY8tnHu+WigQHD5NjR6S1j/vj8jQ7QmD1a1Aj4DvBGTGqWXz2VhN+RwmF5LuSznm6NML191QZWYEWe8jIFtPrpLy7y7fdmz0mTSt2jGI7aKfNlWIDKfPshu/h9Wb0tjtZg7trV1mGZJfUgP7VjrJP0CfO2FFt6z1w7QrugnZ+i1MUubmWVRuBNDxUNNmXvKAH8YGnZZ+qEhIJYRD6EL4OC3ryRBCKuH2sErByghTaseago8UeM6ikW3cIJzVN8bl2emP9tTWhNmSNbI84= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <347A099F770380438D864B40AE25BAE4@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4c3888b9-9a79-4a93-7f9a-08d7ea77fbf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 06:55:34.3031 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1GoUq8qvoIqbWYStwTGYMWEcH/RLX3po6VuSNX1oy+WlS6XtAx2HJ38noVBCykU0gMbOp5CGwmK+GPR2s85O5Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1324 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Taps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-taps-transport-security-11=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 06:56:05 -0000 QmVuLCB0aGFuayB5b3UgZm9yIHRoZSBub3RpY2UuDQoNClNvLCBpdCBzZWVtcyB0aGF0IG15IHN1 Z2dlc3Rpb24gd2FzIG5vdCB1cC10by1kYXRlIHdydCBJUHNlYyBhbmQgQUguDQoNCi3DqXJpYw0K DQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW5qYW1pbiBLYWR1ayA8 a2FkdWtAbWl0LmVkdT4NCkRhdGU6IFNhdHVyZGF5LCAyNSBBcHJpbCAyMDIwIGF0IDIzOjI2DQpU bzogVG9tbXkgUGF1bHkgPHRwYXVseT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBF cmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBQaGlsaXBwIFRpZXNlbCA8cGhpbGlwcEB0 aWVzZWwubmV0PiwgInRhcHMtY2hhaXJzQGlldGYub3JnIiA8dGFwcy1jaGFpcnNAaWV0Zi5vcmc+ LCAiY2F3QGhlYXBpbmdiaXRzLm5ldCIgPGNhd0BoZWFwaW5nYml0cy5uZXQ+LCAiZHJhZnQtaWV0 Zi10YXBzLXRyYW5zcG9ydC1zZWN1cml0eUBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtdGFwcy10cmFu c3BvcnQtc2VjdXJpdHlAaWV0Zi5vcmc+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sICJ0YXBz QGlldGYub3JnIiA8dGFwc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiDDiXJpYyBWeW5ja2UncyBO byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi10YXBzLXRyYW5zcG9ydC1zZWN1cml0eS0xMTogKHdp dGggQ09NTUVOVCkNCg0KICAgIE9uIFdlZCwgQXByIDIyLCAyMDIwIGF0IDEwOjI4OjE4QU0gLTA3 MDAsIFRvbW15IFBhdWx5IHdyb3RlOg0KICAgID4gSGkgRXJpYywNCiAgICA+IA0KICAgID4gVGhh bmtzIGZvciB0aGUgcmV2aWV3ISBZb3UgY2FuIGZpbmQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRo ZSBkb2N1bWVudCBoZXJlOg0KICAgID4gDQogICAgPiBodHRwczovL2lldGYtdGFwc3dnLmdpdGh1 Yi5pby9kcmFmdC1pZXRmLXRhcHMtdHJhbnNwb3J0LXNlY3VyaXR5L2RyYWZ0LWlldGYtdGFwcy10 cmFuc3BvcnQtc2VjdXJpdHkuaHRtbCA8aHR0cHM6Ly9pZXRmLXRhcHN3Zy5naXRodWIuaW8vZHJh ZnQtaWV0Zi10YXBzLXRyYW5zcG9ydC1zZWN1cml0eS9kcmFmdC1pZXRmLXRhcHMtdHJhbnNwb3J0 LXNlY3VyaXR5Lmh0bWw+DQogICAgPiANCiAgICA+IFJlc3BvbnNlcyB0byB5b3VyIHNwZWNpZmlj IHBvaW50cyBpbmxpbmUuDQogICAgPiANCiAgICA+ID4gT24gQXByIDksIDIwMjAsIGF0IDc6Mzgg QU0sIMOJcmljIFZ5bmNrZSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3Rl Og0KICAgID4gPiANCiAgICA+ID4gLS0gU2VjdGlvbiAxIC0tDQogICAgPiA+IElzIHRoZXJlIGFu eSByZWFzb24gd2h5IHRoZSBpbnRlZ3JpdHkgcHJvcGVydHkgb2YgSVBzZWMgQUggaXMgbm90IG1l bnRpb25lZCA/DQogICAgPiA+IFNhbWUgYWxzbyBhcHBsaWVzIGluIHNlY3Rpb24gMiB3aGVuICJz ZWN1cml0eSBwcm90b2NvbCIgaXMgZGVmaW5lZC4NCiAgICA+IA0KICAgID4gQWRkZWQgYSBub3Rl IHRoYXQgQUggcHJvdmlkZXMgaW50ZWdyaXR5Lg0KDQogICAgSSBub3RlIHRoYXQgcGVyDQogICAg aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pcHNlYy95a3lVQ0tXem45aTBq QmdIS2hJVkFwSlBMSmsvIHdlDQogICAgbWF5IG5vdCB3YW50IHRvIGJlIGFkZGluZyBuZXcgbWVu dGlvbiBvZiBBSC4NCg0KICAgIC1CZW4NCg0K From nobody Mon Apr 27 01:45:41 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DB53A12C9 for ; Mon, 27 Apr 2020 01:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=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 M5IKf247Ebqy for ; Mon, 27 Apr 2020 01:45:36 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2040.outbound.protection.outlook.com [40.107.21.40]) (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 C99BF3A12AE for ; Mon, 27 Apr 2020 01:45:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oSwjKQQk0mlyFKWgUSkLu/U5c4+AQUhcLSRThFuh41jm64mW30B5xKAy1mKVGWRWk1aK/6U4sjQnnI8IKQC80VWkugh5dtWvtQSx7zL2FFg3OK8Dn7nj31DBL907iIwYNuNomW1BrfZs4RA0qUu51pr9gaTkHNIjjE/EYdykVpv0T6Y9gmUCsFT0LfuL7CYrZBntMYBo7eyZ50R1enN7nlKDVfYal8AvVDeHY1ltM6WhrpBgpr7yTy96ILMFQUxpkUpHP/FXjlwgnRj4J5XAGmco+QLiDQhujgtkzdLXWlKG7rJLXoIVq/WVJ950mWieK9sRKDw9+23MsKJpfGpc3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dx8IdkLv4cCXnA8RkpKABauqIqEa3486vj/8dJI1Pag=; b=Vmphz43aTJ7nk04mqLuxP/d/xoT793a453fzfGGv77OAgJHH+Z1N6Wx4ugAvVpSWo1UwKpDyyqhpBgIY2bY1lGUH1DmNHfu2lE0R/Hm9mO+FL0LnF81fXenGuMcq42J/7zlhfXyYHAWWfqoCOR01jtmb+HgibdmLqZUHbpGAXMf/YShfb8k+WJNim/M0DqRRgkliFR6lXG6vWrQQtqpuvZDDf9h99Td5zYLgbWZdwE/y6k+vo0/4Gi3rB16LZCT79Nav9Cd/gnGq5iPGfW9Errsp3l+PMAjRoyIZI9WeWDoU0PedaGDfz9zhr3GGP1A2Ngr6syuq2qWS1nRlb8mzwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dx8IdkLv4cCXnA8RkpKABauqIqEa3486vj/8dJI1Pag=; b=JcYsM1kiPB4z2jeKuRmRLUxzpyJ8nKlF1fpIsLbmiuWv8MTXI0I1OkEwD1Bj7C/bcUbg3/qhV+E8CxBWj+j91BOx7xUE8hZjHFXCOECb50yO5+glTpFBegC4pOugynhXMi/16e4fAzh+3BOAaSSdVczoVY3ySkxaxAgMlTOtjuU= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3610.eurprd07.prod.outlook.com (2603:10a6:7:7f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.12; Mon, 27 Apr 2020 08:45:33 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 08:45:32 +0000 From: Magnus Westerlund To: "michawe@ifi.uio.no" , "taps@ietf.org" Thread-Topic: [Taps] UDP rendezvous Thread-Index: AQHWGv9EAtpm6aBMDECQrPBg/ZpIZ6iMqnsA Date: Mon, 27 Apr 2020 08:45:32 +0000 Message-ID: <8cfb8dd7ecc313564133b995e8c6780550457c6c.camel@ericsson.com> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [98.128.243.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ee265010-5a9b-4319-e9a8-08d7ea8758f1 x-ms-traffictypediagnostic: HE1PR0702MB3610: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(66616009)(66556008)(64756008)(66476007)(66946007)(44832011)(2616005)(86362001)(5660300002)(6512007)(71200400001)(2906002)(478600001)(966005)(8936002)(36756003)(8676002)(110136005)(6486002)(26005)(66446008)(76116006)(186003)(316002)(6506007)(99936003)(81156014)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H5NDQyCYvVQLF9SybTv0YTV7Ml+qltrmsg2RcO0sVtSP3s61DYlXRIIM0K7iyhH8BqcmmPRt1MaFSK4MUoCjF0gLscSf8hk03HsLln+pwADTrPFsH6xiSxGsT+S0g82cCVplcp5DHqPPhzEXIGckZhEmJHyVfW5Oa4zbakNyybCN6YmVESkC1ZFLh7MDmIRaNLzXD6ftcPm/Hsp08Lh1D8IlxP3lm9QGNd8xCcCHWAloycjmQERZaCb3Jg9eML68DI/o+8C9VC8uAuoLPBrDnPTgUPvlzEIr9xqOHsCa+0HFz9DP0u29RH2eV1OY3krDxb3jwio4S0VW5OayVf19aYu9mWUkQMDaZskCmjyHDsJSQplfLEWn+gPqjI5QcmX/Q1zTZRzP8tYEsFic4+Wy7wa6XaKEiik7RQreT6GX3XVm+d6V+vTX917WHLuiIFyWgemV1Z3jlqc7kN5ZWFEG9qH0EF/kEwE5Jw9gx5NplhE1BzW2/fn5jmPIDqqy9TKjUBP2kuWU1JhxAagFdHLskJZ/hVA+JRb/Qfuu/OqEKnf9vE30jujBO/fm/6JNYir+ x-ms-exchange-antispam-messagedata: eLl8UHNhAa4dOy0cIGBnjxRnWyrRuvQqr67UtzfvzIlpEifkf6yRz+Ie+FQjllhy2pkN9ilBvpGETUYVLXuMkmc+VEL/XWVIn0Ott/KITHu+LBHnPQmxNCY+AWbCOJdFUOQquFx17CxFSOpWwYoGXvbz+9mmiYZGR8CgKODjhMzeNvORTkLPjO8+P7axZKlk6uWV3bI2/h41/MbP+CP1rz1NeSjIBeWwkty3LswUPOTSyuBHCVCmliGUkesiVzh1+AO2GfMDtxN0GjTC8uLjpDDrBbgt+40J1UpoRI4Y289THeLIqdDh1q95OzjiNF78ucZ9KeO8MpNfy6cyA9s7/Fpxt4488LuMup9F6vqAM4Hh2wNJ7bJHJ++RVm6CvuDBzS4WEWM8tBPUqOGd4FICuyuT9+MY+Dph8Lf4ru6yo/QHWWZ/YikiZkU8tBMNb289j5yfqGRXz849wevf5MJNIgISJjOZU4iigvpRsqVBAETshRXkxec1CYin5zJ2AyUjxEtvgWtuJBDv4eEeSgM9G7qZdzybonF8kAuAAzK2MERFOE2tAdSGu2olWZVVkSrkCZyGwqr8NGZ6QbtNcDqzBDAayz/2hSay1gLM15QzTfu5ZiGFSdAD/qEI2h9nTqELFp/L8FAiRWFXyqIBgP2vYVbeuIP+69RtsbocVhhZoSKduAlFmzuVmBhV4ENti9rdKh5F3uC94N5v+ylAhVDA9jQVJwInqAaof1RnBIggDfXsYF/YbJGyEk16R4LMuFpqBtuZFTb2hNgN85vU8z6k+I0FHq3F9DXxW77HbWQ3Z1A= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-0uwhfDYT51VdtmAuNlh6" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee265010-5a9b-4319-e9a8-08d7ea8758f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 08:45:32.8408 (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-CrossTenant-userprincipalname: 7EkPJ0Ee5/YkISlKyEQ/3NpRwQSJI1lx0zZbGFV7fuGFMnJrSUayjXNXxy5U0LbZ1fb9ankXIuD+XTbv2fqVYXrPiFnXkhC/GVv7C9O7eyg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3610 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 08:45:40 -0000 --=-0uwhfDYT51VdtmAuNlh6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, (This is intended as an individual contribution) So I a bit thin on the TAPS context for your discussion her. However, the p= art of the UDP rendezvous I have more familarity.=20 So lets discuss this from the context of ICE (RFC 8445) and especially with= the Trickle (https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/) and PAC = ( https://datatracker.ietf.org/doc/draft-ietf-ice-pac/) extensions.=20 You maybe also have to consider if the interface needs to cater for rendezv= ous servers and such protocols, like TURN (RFC8656) or HIP. These protocols basically moves your UDP listener port to a relay server, i.e. you suddenly= have a UDP port with a address and port beyond the local host. I note that these ports can have some filtering behaviour on them. For example TURN needs you= to send outgoing traffic towards the address + ports from where you like to re= ceive traffic.=20 So an easy answer would be say that this is all application land, and then = I think you are throwing away a lot of the functionality of TAPS interface. A= s you basically need one or more UDP sockets with a listener and tight sending capability.=20 However, if one actually like to have an interface that tries to do the bes= t here. Then one maybe like to have an API with baked in ICE functionality. T= hus requesting an UDP port with rendezvous capabilities would require configuri= ng STUN and TURN servers. The STUN and TURN server configuration would be to l= earn the hosts server reflexive candidates and relay candidates. Then generating= ICE credentials, receive peer(s) credential, and a list of candidates (potentia= lly empty initially). And with Trickle your list of remote peer candidates will= be dynamically updated over time. It would also require asynchronous feedback towards the application as the layer learn more candidates for reaching the local application. I would also note that the timeout horizon for these operations are a minimal of approximately 40 seconds and depending on candi= date additions etc it can grow to several minutes.=20 There is also the mode when one would basically prepare a UDP port for rendezvous, which would mean gathering candidates, establish relay server candidates etc but simply hold waiting for remote candidates and during tha= t time maintain these candidates which requires periodic keep-alive messages.= =20 So this may be way beyond what you asked for. However, normal listening UDP= has limited utility in the face of stateful firewalls.=20 Cheers Magnus Westerlund =20 On Sat, 2020-04-25 at 14:44 +0200, Michael Welzl wrote: > Dear all, >=20 > I know way too little about rendezvous mechanisms, so I may get this > completely wrong - please bear with me! > It may be that I describe an issue that=E2=80=99s a non-issue. But, if I = do understand > this right, maybe that=E2=80=99s something which needs fixing? >=20 > Ok, here it goes=E2=80=A6 >=20 > Our current Rendezvous text in the API draft says the following: > "The Rendezvous() Action causes the Preconnection to listen on the Local > Endpoint for an incoming Connection from the Remote Endpoint, while > simultaneously trying to establish a Connection from the Local Endpoint t= o the > Remote Endpoint. This corresponds to a TCP simultaneous open, for example= .=E2=80=9D >=20 > Now, if an application chooses unreliable data transmission, it may get S= CTP > with partial reliability, or it may (in the future) get QUIC with datagra= ms, > or whatever=E2=80=A6 and then, the protocol may be able to do what=E2=80= =99s needed > (something similar to a simultaneous open). >=20 > However, in case of UDP: > - Listening is quite okay, > - =E2=80=9Csimultaneously trying to establish a Connection=E2=80=9D reall= y means nothing - no > packet will be sent. >=20 > I believe that applications doing this over UDP will implement their own > =E2=80=9CSYN=E2=80=9D-type signal for this - but then it=E2=80=99s up to = the application, which, over > TAPS, would need to: > - create a passive connection, > - send a Message from that same connection, i.e. using the same local add= ress > and port (I believe?) - which is a matter of configuring the local endpoi= nt, > and doable if the underlying transport system can pull it off. I think th= ere=E2=80=99s > nothing in our API preventing an application from doing this. >=20 > If all of the above is correct, the problem that I see is that an applica= tion > may ask for unreliable transmission, and then have one case in which call= ing > =E2=80=9CRendezvous=E2=80=9D is the right thing to do, and another case i= n which it is not - > so it would need to be able to distinguish between these two cases: is it= a > protocol with Rendezvous-capability, or do I have to do it myself. Maybe= , in > case of UDP, the call to Rendezvous should just fail, and our text should= say > that Rendezvous failing would inform the application that it would have t= o > implement it by itself, by issuing Listen and then sending a Message to t= he > peer. >=20 > Thoughts? Am I completely off track, or is this something that needs a te= xt > fix? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-0uwhfDYT51VdtmAuNlh6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyNzA4NDU0NFowLwYJKoZIhvcN AQkEMSIEIAnM99pR3p9JtMVTM5Fn7b3H2jbbHS3NwJA6uESkjZxnMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAn0xntISkucYw EkkqKtkF7GU80HQgVtWgueYczGe8aGOl5A4uQr8T9fWzG0EIfUV5jq5vEw8larrDVIYzvCrMeTo6 70xKz11jR0xZ0DwT4sGQUajHpMh6Cu7sfxZaXmcCaqUXvzNiw6jiOlim/AL9Jhik5xcqvxfwPYNa h6fJ+94/7ne/yUaZovCCQt09v2o2yD39TGexMFe5O7o0iKS2AWVPIxjbp6R4t52U5UCrNeECPoZS EEsFgSR+O+Ug6gfeA9tIMzPHCb2AIdFJHD1XeDc66ToFawMZ3Qz1fom/4aLrqPA7RF60iJs8raJy lWg/8UCXpTx05mQVoBGUUlUYAQAAAAAAAA== --=-0uwhfDYT51VdtmAuNlh6-- From nobody Mon Apr 27 03:23:18 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1388E3A0979 for ; Mon, 27 Apr 2020 03:23:16 -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, 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 k38dfMdOzPCZ for ; Mon, 27 Apr 2020 03:23:13 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 0DA5E3A097C for ; Mon, 27 Apr 2020 03:23:13 -0700 (PDT) Received: from [81.187.2.149] (port=44293 helo=[192.168.0.80]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jT0up-0004kB-9K; Mon, 27 Apr 2020 11:23:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Colin Perkins In-Reply-To: Date: Mon, 27 Apr 2020 11:23:02 +0100 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 10:23:16 -0000 Hi, This is one of the areas where the drafts likely need expanding, but I = think the model is: 1) application configures STUN (and maybe also TURN) local endpoints 2) application calls Resolve() on these, to find server reflexive = candidates 3) application shares these candidates with its peer, via out-of-band = means, and receives remote endpoint candidates from the peer 4) application adds remote endpoints for the peer=E2=80=99s candidates 5) application calls Rendezvous(), which performs the ICE-style probing = to find a working path, based on the candidates, then returns s = Connection This relies on the Endpoint abstraction supporting STUN, which is maybe = implicit in the drafts.=20 Also, as usual with TAPS, the application doesn=E2=80=99t say that it = wants UDP. It says it wants, e.g., RTP preferably over an unreliable = connection, and this higher-level protocool gives the de-framer the = ability to distinguish the STUN packets from the data packets. Colin > On 25 Apr 2020, at 13:44, Michael Welzl wrote: >=20 > I know way too little about rendezvous mechanisms, so I may get this = completely wrong - please bear with me! > It may be that I describe an issue that=E2=80=99s a non-issue. But, if = I do understand this right, maybe that=E2=80=99s something which needs = fixing? >=20 > Ok, here it goes=E2=80=A6 >=20 > Our current Rendezvous text in the API draft says the following: > "The Rendezvous() Action causes the Preconnection to listen on the = Local Endpoint for an incoming Connection from the Remote Endpoint, = while simultaneously trying to establish a Connection from the Local = Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous = open, for example.=E2=80=9D >=20 > Now, if an application chooses unreliable data transmission, it may = get SCTP with partial reliability, or it may (in the future) get QUIC = with datagrams, or whatever=E2=80=A6 and then, the protocol may be able = to do what=E2=80=99s needed (something similar to a simultaneous open). >=20 > However, in case of UDP: > - Listening is quite okay, > - =E2=80=9Csimultaneously trying to establish a Connection=E2=80=9D = really means nothing - no packet will be sent. >=20 > I believe that applications doing this over UDP will implement their = own =E2=80=9CSYN=E2=80=9D-type signal for this - but then it=E2=80=99s = up to the application, which, over TAPS, would need to: > - create a passive connection, > - send a Message from that same connection, i.e. using the same local = address and port (I believe?) - which is a matter of configuring the = local endpoint, and doable if the underlying transport system can pull = it off. I think there=E2=80=99s nothing in our API preventing an = application from doing this. >=20 > If all of the above is correct, the problem that I see is that an = application may ask for unreliable transmission, and then have one case = in which calling =E2=80=9CRendezvous=E2=80=9D is the right thing to do, = and another case in which it is not - so it would need to be able to = distinguish between these two cases: is it a protocol with = Rendezvous-capability, or do I have to do it myself. Maybe, in case of = UDP, the call to Rendezvous should just fail, and our text should say = that Rendezvous failing would inform the application that it would have = to implement it by itself, by issuing Listen and then sending a Message = to the peer. >=20 > Thoughts? Am I completely off track, or is this something that needs a = text fix? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=20 Colin Perkins https://csperkins.org/ From nobody Mon Apr 27 04:38:18 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252C73A067A for ; Mon, 27 Apr 2020 04:38:16 -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, 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 GZYREQ7RzZaf for ; Mon, 27 Apr 2020 04:38:14 -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 CE7723A0A0E for ; Mon, 27 Apr 2020 04:38:13 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jT25S-000CEJ-Qd; Mon, 27 Apr 2020 13:38:10 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jT25R-00048q-D2; Mon, 27 Apr 2020 13:38:10 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Apr 2020 13:38:07 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> References: To: Colin Perkins X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; 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: 0140BBE6EA93F8FFEDA17FC9626A121B750D3E91 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 11:38:16 -0000 Hi, I=E2=80=99m answering this email, but Magnus, consider yourself answered = too with a big THANK YOU for your thorough explanation! I agree that we want some (much!) of this functionality =E2=80=9Cunder = the hood=E2=80=9D if possible. And, of course, I agree that we don=E2=80=99= t want the application to be aware of e.g. UDP specifically if we can = avoid it. I think we=E2=80=99re all on the same page on that; but I = think that, indeed, the text in the API draft needs some fixing. Colin, thank you very much for outlining the 5 steps below: they give a = very good context for this conversation. So, I answer in line below: > On Apr 27, 2020, at 12:23 PM, Colin Perkins wrote: >=20 > Hi, >=20 > This is one of the areas where the drafts likely need expanding, but I = think the model is: >=20 > 1) application configures STUN (and maybe also TURN) local endpoints >=20 > 2) application calls Resolve() on these, to find server reflexive = candidates These two steps are reflected in the API as it stands, and so this is = already reasonably clear, I think. IMO, nothing to do here. > 3) application shares these candidates with its peer, via out-of-band = means, and receives remote endpoint candidates from the peer Based on Magnus=E2=80=99 email, I suppose that this *could* be done in = standard ways with trickle, and hence theoretically put =E2=80=9Cunder = the hood=E2=80=9D too. But, I think that keeping this in the application space for the sake of = TAPS is quite reasonable. This step is perhaps implicit in the text, but = I think it=E2=80=99s pretty obvious that it would need to happen. People = doing rendezvous will have to be aware of this step anyway, so I see no = real problem here. > 4) application adds remote endpoints for the peer=E2=80=99s candidates My first hiccup: I don=E2=80=99t see that this is supported in our = current API - how would one add remote endpoints? I think, the way we = have it, there=E2=80=99s only one for each Connection. Have I overlooked something? > 5) application calls Rendezvous(), which performs the ICE-style = probing to find a working path, based on the candidates, then returns s = Connection THIS would be really good, but it=E2=80=99s not at all how I read the = current text. It says: "The Rendezvous() Action causes the Preconnection to listen on the Local = Endpoint for an incoming Connection from the Remote Endpoint, while = simultaneously trying to establish a Connection from the Local Endpoint = to the Remote Endpoint. This corresponds to a TCP simultaneous open, for = example.=E2=80=9D My interpretation of this sentence is that Rendezvous doesn=E2=80=99t do = much more than listen + send something, using the same local ports. For = TCP, I would have implemented this functionality by just doing an active = connect, using a pre-configured local port (TCP will retry sending SYNs, = and if both sides issue this call with the correct ports, I guess it all = works out eventually). However, from below, it seems to me that such an = implementation would be doing way too little! > This relies on the Endpoint abstraction supporting STUN, which is = maybe implicit in the drafts.=20 Yes - there is text there about STUN configuration, but nothing about it = in the Rendezvous text (unless I missed it, apologies if I have!). And = it=E2=80=99s not just STUN, it=E2=80=99s the ICE-style probing, with = various candidates supplied, that=E2=80=99s missing. > Also, as usual with TAPS, the application doesn=E2=80=99t say that it = wants UDP. It says it wants, e.g., RTP preferably over an unreliable = connection, and this higher-level protocool gives the de-framer the = ability to distinguish the STUN packets from the data packets. Okay, I understand this=E2=80=A6 but what happens if UDP *is* the = protocol that is available (not e.g. RTP), and the application calls = Rendezvous? (I guess failing, with a useful error code, is the best choice, then?) Again, just to be clear, I agree with everything you say here, and I = thank you (and Magnus) again for explaining it to me! - I just want to = get the text right. Actually, I was just trying to understand how to = implement this call=E2=80=99s functionality, and was left puzzled. Cheers, Michael From nobody Mon Apr 27 04:55:50 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B983A041D for ; Mon, 27 Apr 2020 04:55:49 -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, 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 gmARHD2bFvlY for ; Mon, 27 Apr 2020 04:55:47 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 060EE3A041A for ; Mon, 27 Apr 2020 04:55:47 -0700 (PDT) Received: from [81.187.2.149] (port=34309 helo=[192.168.0.80]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jT2MP-0004yw-4y; Mon, 27 Apr 2020 12:55:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Colin Perkins In-Reply-To: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> Date: Mon, 27 Apr 2020 12:55:40 +0100 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <91F3869D-D908-489F-82E2-2BEADA357C2A@csperkins.org> References: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 11:55:49 -0000 > On 27 Apr 2020, at 12:38, Michael Welzl wrote: >=20 > Hi, >=20 > I=E2=80=99m answering this email, but Magnus, consider yourself = answered too with a big THANK YOU for your thorough explanation! >=20 > I agree that we want some (much!) of this functionality =E2=80=9Cunder = the hood=E2=80=9D if possible. And, of course, I agree that we don=E2=80=99= t want the application to be aware of e.g. UDP specifically if we can = avoid it. I think we=E2=80=99re all on the same page on that; but I = think that, indeed, the text in the API draft needs some fixing. >=20 > Colin, thank you very much for outlining the 5 steps below: they give = a very good context for this conversation. So, I answer in line below: >=20 >> On Apr 27, 2020, at 12:23 PM, Colin Perkins = wrote: >>=20 >> Hi, >>=20 >> This is one of the areas where the drafts likely need expanding, but = I think the model is: >>=20 >> 1) application configures STUN (and maybe also TURN) local endpoints >>=20 >> 2) application calls Resolve() on these, to find server reflexive = candidates >=20 > These two steps are reflected in the API as it stands, and so this is = already reasonably clear, I think. IMO, nothing to do here. >=20 >=20 >> 3) application shares these candidates with its peer, via out-of-band = means, and receives remote endpoint candidates from the peer >=20 > Based on Magnus=E2=80=99 email, I suppose that this *could* be done in = standard ways with trickle, and hence theoretically put =E2=80=9Cunder = the hood=E2=80=9D too. > But, I think that keeping this in the application space for the sake = of TAPS is quite reasonable. This step is perhaps implicit in the text, = but I think it=E2=80=99s pretty obvious that it would need to happen. = People doing rendezvous will have to be aware of this step anyway, so I = see no real problem here. This has to be done by the applications, since it will involve the = signalling protocol (SIP, WebRTC, etc). >> 4) application adds remote endpoints for the peer=E2=80=99s = candidates >=20 > My first hiccup: I don=E2=80=99t see that this is supported in our = current API - how would one add remote endpoints? I think, the way we = have it, there=E2=80=99s only one for each Connection. > Have I overlooked something? They go on the Preconnection. The allow multiple remotes there. >> 5) application calls Rendezvous(), which performs the ICE-style = probing to find a working path, based on the candidates, then returns s = Connection >=20 > THIS would be really good, but it=E2=80=99s not at all how I read the = current text. It says: >=20 > "The Rendezvous() Action causes the Preconnection to listen on the = Local Endpoint for an incoming Connection from the Remote Endpoint, = while simultaneously trying to establish a Connection from the Local = Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous = open, for example.=E2=80=9D >=20 > My interpretation of this sentence is that Rendezvous doesn=E2=80=99t = do much more than listen + send something, using the same local ports. = For TCP, I would have implemented this functionality by just doing an = active connect, using a pre-configured local port (TCP will retry = sending SYNs, and if both sides issue this call with the correct ports, = I guess it all works out eventually). However, from below, it seems to = me that such an implementation would be doing way too little! It sends the STUN packets to probe connectivity. I read this as = =E2=80=9Cestablish a Connection=E2=80=9D, but we maybe need to clarify = the wording (or just give an additional example). >> This relies on the Endpoint abstraction supporting STUN, which is = maybe implicit in the drafts.=20 >=20 > Yes - there is text there about STUN configuration, but nothing about = it in the Rendezvous text (unless I missed it, apologies if I have!). = And it=E2=80=99s not just STUN, it=E2=80=99s the ICE-style probing, with = various candidates supplied, that=E2=80=99s missing. >=20 >=20 >> Also, as usual with TAPS, the application doesn=E2=80=99t say that it = wants UDP. It says it wants, e.g., RTP preferably over an unreliable = connection, and this higher-level protocool gives the de-framer the = ability to distinguish the STUN packets from the data packets. >=20 > Okay, I understand this=E2=80=A6 but what happens if UDP *is* the = protocol that is available (not e.g. RTP), and the application calls = Rendezvous? > (I guess failing, with a useful error code, is the best choice, then?) Applications don=E2=80=99t use raw UDP or TCP =E2=80=93 they always run = some protocol, however trivial inside it, so there=E2=80=99s a framer. > Again, just to be clear, I agree with everything you say here, and I = thank you (and Magnus) again for explaining it to me! - I just want to = get the text right. Actually, I was just trying to understand how to = implement this call=E2=80=99s functionality, and was left puzzled. >=20 > Cheers, > Michael Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Mon Apr 27 05:59:24 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465C93A0982 for ; Mon, 27 Apr 2020 05:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=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 usJY9AWVSHvE for ; Mon, 27 Apr 2020 05:59:20 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50045.outbound.protection.outlook.com [40.107.5.45]) (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 9D2663A098B for ; Mon, 27 Apr 2020 05:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HaS69aV+DjAWCrOjpCqL0jEwjIjMBk5vUxGsvUFBCB+Yj4/oh6MmMOZpCWbu9IGKREin4EJ61W6zFb3mfKDALybt1zjPdt/czpU6yYjWxs7IAL2GFjyT0NYS3FrGhi3c8nJUGOuwUPx3vOk+D1T5dZcTc8Az/DQyfeerTaH/jJAA2c8jCDPgE8vSC3x53V12TEuEIFpECBxulRkrfprwp/Mf42byICinNi6OQoWVJWM3AKbLRjDJ1y8J3dLa9u9+obpEJ02nI3RJXAbGPbQjsWBn+KLrXWw2RAAldx+lw0jrUOG/T7cWhuIe7QOIpHLYYda0b0ekxuDAA6JzAkMCIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qiMkKQLoX8npyqj61Ob626Vu+Lj2jg1jR1oTqVEhO94=; b=WvhE6jpyQKH+6T5sGpCN63qv5462gkBmEbM5/5d2WwJVpcOPVIIVbyOJp6kwq0nhNtcjckQTAK5QOi3lLocQVnYpcOr4oTo3wFiETRuAhrb0YM3E8J/RqVUg5v9bySK86Vw8rswZyCh1/vLinQ4BBl1rmgO6QXZRQ5GrCiT0CfyUj2G6tez7xCGz5+qjjiWIc/OCTjBmtCOvzuONPd0GePr/V6gxgmQLEFCbMjMBECQjnNeG0JngV/mqAJTVmyPefip1ZM9x0Dg8TzsloDNiXbcUxd0l/saG6py8TzPJl4UiFjSkfsOX3+W2gxHzJlhb/BWUVe08wdw0BgkuOLdQ6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qiMkKQLoX8npyqj61Ob626Vu+Lj2jg1jR1oTqVEhO94=; b=Bj4b2bc1rkUvAot4WCMjRSR01wJXxIUQ3n4SbYc97Fnj1bcmtVcY7biv0ixWDiO4SdfrQDpnFKGGR0KhXH72JIq68pjOGbCR/aE6BU06qEndr4E4v0Fv4hecr0Xg2S8fhGTDtXNN9CqbSznqv4CpXW49TA8wuj4LX6/z2AY+QjY= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3676.eurprd07.prod.outlook.com (2603:10a6:7:8d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.14; Mon, 27 Apr 2020 12:59:16 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2958.014; Mon, 27 Apr 2020 12:59:16 +0000 From: Magnus Westerlund To: "michawe@ifi.uio.no" , "csp@csperkins.org" CC: "taps@ietf.org" Thread-Topic: [Taps] UDP rendezvous Thread-Index: AQHWGv9EAtpm6aBMDECQrPBg/ZpIZ6iMxaoAgAAU+4CAABa5gA== Date: Mon, 27 Apr 2020 12:59:16 +0000 Message-ID: References: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> In-Reply-To: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [98.128.243.138] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01ad6dd4-82f9-45f2-7389-08d7eaaacac6 x-ms-traffictypediagnostic: HE1PR0702MB3676: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2000; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(39860400002)(136003)(346002)(66616009)(66476007)(66946007)(66556008)(6486002)(76116006)(99936003)(478600001)(2906002)(26005)(186003)(53546011)(6506007)(5660300002)(2616005)(966005)(44832011)(81156014)(4326008)(316002)(6512007)(8936002)(64756008)(86362001)(110136005)(66446008)(8676002)(71200400001)(36756003)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YZSAt5Y8GXiUQZHYtaLQq9SJwoLxKNYYbG/LCehjGplXEZ71D4pSMMElj8SnSPjL3jpKV4H2x6oXOAIeMUDOfDDyQmfJgSYRTADV1LlpWabZbMWFwrbbkrzFb40mcpf3TyRJdz2coTSHKY1+OdsqhBLKusz7kZvqNk8jUdoB2lnkj871hh6nI7rpet0ElniHdV0rGjvhiMDMbcHbrBFk8JrpEWPUlfRDYUyRzULWa43l1RWBFBcaKMtrBi0wbyigc1z7MqXEnrjPco6UEInz4TiWFHPBReYGmzCBVdgmCyMo6IrMmoagYlSBBxEkEOS357nGLAKUgh3841Vp8AsIj3SheyCCzxgu0SLWBuLcRyguMmCFfafEoqzskrXQYeIqPpkHtb/9PTY9PVdDbBjUWdk61PqU6lDZcPnbkyrCVgc8oL4fuO4Z22nEd1pnEeFq2Jc3WhVo0QO04AW/XPg2Da3ZlbioL/gjh0n4LbDSksdMCl9h9E/sZwfhGj1959sJt4UgVzPPLqnXj+M82QVEt6ly2iz0UPVTiLZANK9eZ/pj1wJ7TVwzGLp8eFMgWSbj x-ms-exchange-antispam-messagedata: YCj46T7GFg7nkjSuUHVkEpZIWxazMC4/ZHN01kz3sLL/Lwok47FXH7yjLEjIweMq8z79kXz27SPfaEoB+5KXycucBb5QOk5p7OrRVHn7V+i/46tQhH3clREH9r6AH+oTMxkU5RFDLxbMJPOC96x1UQNZIP/LKlPpVW3N8hctxnCmlqDVJf8+/c9dLAovIr1cYfafpuelQiNzDM10soL0MGmsVWuXj1GNyxzUVsX6XETehUsgoFgJEr4VG+YGyXQjxWLdWDa/C7ummBE0F9CC1KBT0ZUptp0OYlDoRiSDQpqmiwARjEbM7kHEdSHoqx7/TI0/oLxOFWbMMdvH3M0+VtHwbNfxtBx42fTQdpBcIur9Rp46aAQZBm4dJ5rL3F9t0jQFHQxzQS04BK368X8Czoiu9cFSfFhJOpKhAekpz9lwX+aIXlfqmwoYduSszjY5XvqB2PNalK4mIUYimI6lCsFREVLfM0is9EE8mUmZZXLcqUejRUOj/ubKI23O5nFgwccPqjta9EPKRoFRQZX9MRbrmzfq2VdK2lfle8KBt8ajK37RJSD5/Kn184SnY+ww1u/EX35d6M4Dg2/e2z0wi+pVaJ155BtKH2j9NTKZtOy3gECFVqucRfVg4PddAmg3c31JDEfVJxVOsxgH+XYpDJKICvkmB7v655GpD1LFqK1qNubkJAq3qxxnKuUCfH1sZKHljArAJhlcQcEzztwxZywHHWuGyUFOBMtTtbP5K/z8v7wflKxZ6MvhNP63z2okunOLRANSsa2mipgcr2fRs6j7w9JPbCeBPVtY7YJusok= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-4rb84VvPV1UnhDcwF5Qa" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01ad6dd4-82f9-45f2-7389-08d7eaaacac6 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 12:59:16.2218 (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-CrossTenant-userprincipalname: sS4dzKjD7ipALWJSZrAWpfdInSZBjuvCoYDzac0iaYU6vu1XT2E7iadAin3ytfieWkr60w+SvWZCeCF81yT/NxAmGcibJVqosC8d6rgY1Mw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3676 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 12:59:23 -0000 --=-4rb84VvPV1UnhDcwF5Qa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Michael if you want an example of an API that contains the ICE related rendezvous aspects it is the WebRTC. https://www.w3.org/TR/webrtc/ You will find the ICEserver with configuration information. Note also how candidates are handled. I would also note the possibility to enable or disa= ble trickling of candidates. Which is possibly something an application could w= ant to indicate. I know the ICE parts is only a part of the complete WebRTC API= so there is a lot to wade through here.=20 I would also note that there might be an other aspect of embedding ICE unde= r the hood is the potential to use this as a method to update the path used betwe= en two peers during an ongoing communication session. There are two takes on t= his. Either the more standards compliant way of triggering an ICE restart, which involved application interaction through a new candidate exchange.=20 Or the less so which is to not really terminate ICE. And instead keep your checklist alive and continously verify what candidate pairs that actually w= ork and use re-occuring nomination to move the application datagram flow betwee= n working candidate pairs ( https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/). I would recommend avoiding the later, but wanted to mention it for completeness.= =20 As I haven't been active in TAPS, I would appreciate any pointers to where = the WG is in regards to the need for parameter exchange that need to be done by= the application using the TAPS interface, rather than letting the lower layers handle that aspect.=20 Cheers Magnus On Mon, 2020-04-27 at 13:38 +0200, Michael Welzl wrote: > Hi, >=20 > I=E2=80=99m answering this email, but Magnus, consider yourself answered = too with a > big THANK YOU for your thorough explanation! >=20 > I agree that we want some (much!) of this functionality =E2=80=9Cunder th= e hood=E2=80=9D if > possible. And, of course, I agree that we don=E2=80=99t want the applicat= ion to be > aware of e.g. UDP specifically if we can avoid it. I think we=E2=80=99re = all on the > same page on that; but I think that, indeed, the text in the API draft ne= eds > some fixing. >=20 > Colin, thank you very much for outlining the 5 steps below: they give a v= ery > good context for this conversation. So, I answer in line below: >=20 > > On Apr 27, 2020, at 12:23 PM, Colin Perkins wrote: > >=20 > > Hi, > >=20 > > This is one of the areas where the drafts likely need expanding, but I = think > > the model is: > >=20 > > 1) application configures STUN (and maybe also TURN) local endpoints > >=20 > > 2) application calls Resolve() on these, to find server reflexive candi= dates >=20 > These two steps are reflected in the API as it stands, and so this is alr= eady > reasonably clear, I think. IMO, nothing to do here. >=20 >=20 > > 3) application shares these candidates with its peer, via out-of-band m= eans, > > and receives remote endpoint candidates from the peer >=20 > Based on Magnus=E2=80=99 email, I suppose that this *could* be done in st= andard ways > with trickle, and hence theoretically put =E2=80=9Cunder the hood=E2=80= =9D too. > But, I think that keeping this in the application space for the sake of T= APS > is quite reasonable. This step is perhaps implicit in the text, but I thi= nk > it=E2=80=99s pretty obvious that it would need to happen. People doing re= ndezvous will > have to be aware of this step anyway, so I see no real problem here. >=20 >=20 > > 4) application adds remote endpoints for the peer=E2=80=99s candidates >=20 > My first hiccup: I don=E2=80=99t see that this is supported in our curren= t API - how > would one add remote endpoints? I think, the way we have it, there=E2=80= =99s only one > for each Connection. > Have I overlooked something? >=20 >=20 > > 5) application calls Rendezvous(), which performs the ICE-style probing= to > > find a working path, based on the candidates, then returns s Connection >=20 > THIS would be really good, but it=E2=80=99s not at all how I read the cur= rent text. It > says: >=20 > "The Rendezvous() Action causes the Preconnection to listen on the Local > Endpoint for an incoming Connection from the Remote Endpoint, while > simultaneously trying to establish a Connection from the Local Endpoint t= o the > Remote Endpoint. This corresponds to a TCP simultaneous open, for example= .=E2=80=9D >=20 > My interpretation of this sentence is that Rendezvous doesn=E2=80=99t do = much more > than listen + send something, using the same local ports. For TCP, I woul= d > have implemented this functionality by just doing an active connect, usin= g a > pre-configured local port (TCP will retry sending SYNs, and if both sides > issue this call with the correct ports, I guess it all works out eventual= ly). > However, from below, it seems to me that such an implementation would be = doing > way too little! >=20 >=20 > > This relies on the Endpoint abstraction supporting STUN, which is maybe > > implicit in the drafts.=20 >=20 > Yes - there is text there about STUN configuration, but nothing about it = in > the Rendezvous text (unless I missed it, apologies if I have!). And it=E2= =80=99s not > just STUN, it=E2=80=99s the ICE-style probing, with various candidates su= pplied, > that=E2=80=99s missing. >=20 >=20 > > Also, as usual with TAPS, the application doesn=E2=80=99t say that it w= ants UDP. It > > says it wants, e.g., RTP preferably over an unreliable connection, and = this > > higher-level protocool gives the de-framer the ability to distinguish t= he > > STUN packets from the data packets. >=20 > Okay, I understand this=E2=80=A6 but what happens if UDP *is* the protoco= l that is > available (not e.g. RTP), and the application calls Rendezvous? > (I guess failing, with a useful error code, is the best choice, then?) >=20 > Again, just to be clear, I agree with everything you say here, and I than= k you > (and Magnus) again for explaining it to me! - I just want to get the te= xt > right. Actually, I was just trying to understand how to implement this ca= ll=E2=80=99s > functionality, and was left puzzled. >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-4rb84VvPV1UnhDcwF5Qa Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyNzEyNTkyN1owLwYJKoZIhvcN AQkEMSIEIDr6lMAl1dV37bJrNG8bhGCpUhI80ovRdDS3jhwg8B6gMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAMGD/xx66Zdpe Cq7Pg5GCp3hBSQ7mGjwEY01/duqwHelpZMHo79xU2dUL7e+r29Kcym3s5EIuaRSu18iP83Azbahv /ifA9YL8aZDehWw6glRqFqib8+iKfH58WzZmV8VfPuTvLSMuhxg7BeZfr80Mi0OWHI1PAXp7+4u9 iaE91ygCcBUZvZVh0fufSPHLRqBqKPkSbLhx1nKmbUrUlphCFB4cxzozs1BWLG5lEAnp4fA3Q2Tf qmZTbtJtc0N7fAexUMIyE/KVbPehrZ2qCAxdyLtvPpHIM9lfeOHaktAJAEdNgPL3n3YOZNayI86l kmnC3KztM+Y3d1WEeWuOCPXR8gAAAAAAAA== --=-4rb84VvPV1UnhDcwF5Qa-- From nobody Mon Apr 27 06:43:27 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373763A0ACA for ; Mon, 27 Apr 2020 06:43:25 -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, HTML_MESSAGE=0.001, 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 N24YDBMHIfPW for ; Mon, 27 Apr 2020 06:43:22 -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 05BAA3A0AC9 for ; Mon, 27 Apr 2020 06:43:21 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jT42Y-000Aqa-UP; Mon, 27 Apr 2020 15:43:18 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx10.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jT42U-0009Fi-81; Mon, 27 Apr 2020 15:43:18 +0200 From: Michael Welzl Message-Id: <061B4D0A-EB81-4BC8-ABF0-8ACA3E2FFA36@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_B9A37066-282A-4B2A-971C-C53899622E75" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 27 Apr 2020 15:43:13 +0200 In-Reply-To: <91F3869D-D908-489F-82E2-2BEADA357C2A@csperkins.org> Cc: "taps@ietf.org" To: Colin Perkins References: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> <91F3869D-D908-489F-82E2-2BEADA357C2A@csperkins.org> X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 17D28DAE1232D8F5251914BBD9739E9CE5B553C0 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 13:43:26 -0000 --Apple-Mail=_B9A37066-282A-4B2A-971C-C53899622E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 27, 2020, at 1:55 PM, Colin Perkins wrote: >=20 >=20 >=20 >> On 27 Apr 2020, at 12:38, Michael Welzl wrote: >>=20 >> Hi, >>=20 >> I=E2=80=99m answering this email, but Magnus, consider yourself = answered too with a big THANK YOU for your thorough explanation! >>=20 >> I agree that we want some (much!) of this functionality =E2=80=9Cunder = the hood=E2=80=9D if possible. And, of course, I agree that we don=E2=80=99= t want the application to be aware of e.g. UDP specifically if we can = avoid it. I think we=E2=80=99re all on the same page on that; but I = think that, indeed, the text in the API draft needs some fixing. >>=20 >> Colin, thank you very much for outlining the 5 steps below: they give = a very good context for this conversation. So, I answer in line below: >>=20 >>> On Apr 27, 2020, at 12:23 PM, Colin Perkins = wrote: >>>=20 >>> Hi, >>>=20 >>> This is one of the areas where the drafts likely need expanding, but = I think the model is: >>>=20 >>> 1) application configures STUN (and maybe also TURN) local endpoints >>>=20 >>> 2) application calls Resolve() on these, to find server reflexive = candidates >>=20 >> These two steps are reflected in the API as it stands, and so this is = already reasonably clear, I think. IMO, nothing to do here. >>=20 >>=20 >>> 3) application shares these candidates with its peer, via = out-of-band means, and receives remote endpoint candidates from the peer >>=20 >> Based on Magnus=E2=80=99 email, I suppose that this *could* be done = in standard ways with trickle, and hence theoretically put =E2=80=9Cunder = the hood=E2=80=9D too. >> But, I think that keeping this in the application space for the sake = of TAPS is quite reasonable. This step is perhaps implicit in the text, = but I think it=E2=80=99s pretty obvious that it would need to happen. = People doing rendezvous will have to be aware of this step anyway, so I = see no real problem here. >=20 > This has to be done by the applications, since it will involve the = signalling protocol (SIP, WebRTC, etc). Ok; got it. >>> 4) application adds remote endpoints for the peer=E2=80=99s = candidates >>=20 >> My first hiccup: I don=E2=80=99t see that this is supported in our = current API - how would one add remote endpoints? I think, the way we = have it, there=E2=80=99s only one for each Connection. >> Have I overlooked something? >=20 > They go on the Preconnection. The allow multiple remotes there. Aha! (yes that=E2=80=99s allowed, I saw that text now) >>> 5) application calls Rendezvous(), which performs the ICE-style = probing to find a working path, based on the candidates, then returns s = Connection >>=20 >> THIS would be really good, but it=E2=80=99s not at all how I read the = current text. It says: >>=20 >> "The Rendezvous() Action causes the Preconnection to listen on the = Local Endpoint for an incoming Connection from the Remote Endpoint, = while simultaneously trying to establish a Connection from the Local = Endpoint to the Remote Endpoint. This corresponds to a TCP simultaneous = open, for example.=E2=80=9D >>=20 >> My interpretation of this sentence is that Rendezvous doesn=E2=80=99t = do much more than listen + send something, using the same local ports. = For TCP, I would have implemented this functionality by just doing an = active connect, using a pre-configured local port (TCP will retry = sending SYNs, and if both sides issue this call with the correct ports, = I guess it all works out eventually). However, from below, it seems to = me that such an implementation would be doing way too little! >=20 > It sends the STUN packets to probe connectivity. I read this as = =E2=80=9Cestablish a Connection=E2=80=9D, but we maybe need to clarify = the wording (or just give an additional example). I think so. To me, as someone who only has a faint idea of how these = things work, =E2=80=9Cestablish a Connection=E2=80=9D would have been = way less than that. Or, something else: AFAIK STUN is only use to the = STUN server, but one wouldn=E2=80=99t use STUN packets to then try to = connect to the peer, right? Rather SIP, or something. VERY sorry if = this is all a silly misunderstanding on my behalf, which is quite = possible! >>> This relies on the Endpoint abstraction supporting STUN, which is = maybe implicit in the drafts.=20 >>=20 >> Yes - there is text there about STUN configuration, but nothing about = it in the Rendezvous text (unless I missed it, apologies if I have!). = And it=E2=80=99s not just STUN, it=E2=80=99s the ICE-style probing, with = various candidates supplied, that=E2=80=99s missing. >>=20 >>=20 >>> Also, as usual with TAPS, the application doesn=E2=80=99t say that = it wants UDP. It says it wants, e.g., RTP preferably over an unreliable = connection, and this higher-level protocool gives the de-framer the = ability to distinguish the STUN packets from the data packets. >>=20 >> Okay, I understand this=E2=80=A6 but what happens if UDP *is* the = protocol that is available (not e.g. RTP), and the application calls = Rendezvous? >> (I guess failing, with a useful error code, is the best choice, = then?) >=20 > Applications don=E2=80=99t use raw UDP or TCP =E2=80=93 they always = run some protocol, however trivial inside it, so there=E2=80=99s a = framer. =E2=80=A6 okay, so you=E2=80=99re saying the sender-side framer could = supply that first type of message that is sent to the peer when = rendezvous() is called (and the first one to expect from the peer)? = That would sound reasonable to me - but, I thought framers are = associated with a Message (or, rather, its messageContext) - but we=E2=80=99= re not sending a Message yet. Shouldn't the rendezvous() Action have = optional Message and messageContext parameters, then? >> Again, just to be clear, I agree with everything you say here, and I = thank you (and Magnus) again for explaining it to me! - I just want to = get the text right. Actually, I was just trying to understand how to = implement this call=E2=80=99s functionality, and was left puzzled. >>=20 >> Cheers, >> Michael >=20 > Cheers, > Colin >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ --Apple-Mail=_B9A37066-282A-4B2A-971C-C53899622E75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 27, 2020, at 1:55 PM, Colin Perkins <csp@csperkins.org> = wrote:



On 27 = Apr 2020, at 12:38, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

I=E2=80= =99m answering this email, but Magnus, consider yourself answered too = with a big THANK YOU for your thorough explanation!

I agree that we want some (much!) of this functionality = =E2=80=9Cunder the hood=E2=80=9D if possible. And, of course, I agree = that we don=E2=80=99t want the application to be aware of e.g. UDP = specifically if we can avoid it. I think we=E2=80=99re all on the same = page on that; but I think that, indeed, the text in the API draft needs = some fixing.

Colin, thank you very much for = outlining the 5 steps below: they give a very good context for this = conversation. So, I answer in line below:

On Apr 27, 2020, at = 12:23 PM, Colin Perkins <csp@csperkins.org> wrote:

Hi,

This is one of the areas = where the drafts likely need expanding, but I think the model is:

1) application configures STUN (and maybe also = TURN) local endpoints

2) application calls = Resolve() on these, to find server reflexive candidates

These two steps are reflected in = the API as it stands, and so this is already reasonably clear, I think. = IMO, nothing to do here.


3) application shares = these candidates with its peer, via out-of-band means, and receives = remote endpoint candidates from the peer

Based on Magnus=E2=80=99 email, I suppose that this *could* = be done in standard ways with trickle, and hence theoretically put = =E2=80=9Cunder the hood=E2=80=9D too.
But, I think that = keeping this in the application space for the sake of TAPS is quite = reasonable. This step is perhaps implicit in the text, but I think = it=E2=80=99s pretty obvious that it would need to happen. People doing = rendezvous will have to be aware of this step anyway, so I see no real = problem here.

This has to be done by the applications, since it will = involve the signalling protocol (SIP, WebRTC, etc).

Ok; got = it.


4)= application adds remote endpoints for the peer=E2=80=99s candidates

My first hiccup: I don=E2=80=99t = see that this is supported in our current API - how would one add remote = endpoints? I think, the way we have it, there=E2=80=99s only one for = each Connection.
Have I overlooked something?

They go on the Preconnection. The allow multiple remotes = there.

Aha!
(yes that=E2=80=99s allowed, I saw that = text now)


5)= application calls Rendezvous(), which performs the ICE-style probing to = find a working path, based on the candidates, then returns s = Connection

THIS would be = really good, but it=E2=80=99s not at all how I read the current text. It = says:

"The Rendezvous() Action causes the = Preconnection to listen on the Local Endpoint for an incoming Connection = from the Remote Endpoint, while simultaneously trying to establish a = Connection from the Local Endpoint to the Remote Endpoint. This = corresponds to a TCP simultaneous open, for example.=E2=80=9D

My interpretation of this sentence is that = Rendezvous doesn=E2=80=99t do much more than listen + send something, = using the same local ports. For TCP, I would have implemented this = functionality by just doing an active connect, using a pre-configured = local port (TCP will retry sending SYNs, and if both sides issue this = call with the correct ports, I guess it all works out eventually). = However, from below, it seems to me that such an implementation would be = doing way too little!

It sends the STUN packets to probe connectivity. I read this = as =E2=80=9Cestablish a Connection=E2=80=9D, but we maybe need to = clarify the wording (or just give an additional example).

I think so. = To me, as someone who only has a faint idea of how these things work, = =E2=80=9Cestablish a Connection=E2=80=9D would have been way less than = that. Or, something else: AFAIK STUN is only use to the STUN server, but = one wouldn=E2=80=99t use STUN packets to then try to connect to the = peer, right? Rather SIP, or something.  VERY sorry if this is all a = silly misunderstanding on my behalf, which is quite = possible!


This relies on the Endpoint abstraction supporting STUN, = which is maybe implicit in the drafts. 

Yes - there is text there about = STUN configuration, but nothing about it in the Rendezvous text (unless = I missed it, apologies if I have!). And it=E2=80=99s not just STUN, = it=E2=80=99s the ICE-style probing, with various candidates supplied, = that=E2=80=99s missing.


Also, as usual with = TAPS, the application doesn=E2=80=99t say that it wants UDP. It says it = wants, e.g., RTP preferably over an unreliable connection, and this = higher-level protocool gives the de-framer the ability to distinguish = the STUN packets from the data packets.

Okay, I understand this=E2=80=A6 but what happens if UDP *is* = the protocol that is available (not e.g. RTP), and the application calls = Rendezvous?
(I guess failing, with a useful error code, is = the best choice, then?)

Applications don=E2=80=99t use = raw UDP or TCP =E2=80=93 they always run some protocol, however trivial = inside it, so there=E2=80=99s a framer.

=E2=80=A6 okay, so you=E2=80=99re saying the = sender-side framer could supply that first type of message that is sent = to the peer when rendezvous() is called (and the first one to expect = from the peer)?  That would sound reasonable to me - but, I thought = framers are associated with a Message (or, rather, its messageContext) - = but we=E2=80=99re not sending a Message yet. Shouldn't the rendezvous() = Action have optional Message and messageContext parameters, = then?


Again, just to be clear, I agree with = everything you say here, and I thank you (and Magnus) again for = explaining it to me!   - I just want to get the text right. = Actually, I was just trying to understand how to implement this call=E2=80= =99s functionality, and was left puzzled.

Cheers,
Michael

Cheers,
Colin



-- 
Colin Perkins
https://csperkins.org/

= --Apple-Mail=_B9A37066-282A-4B2A-971C-C53899622E75-- From nobody Mon Apr 27 06:51:14 2020 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5FC3A0AF3 for ; Mon, 27 Apr 2020 06:51:11 -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, 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 2bq9jNlUMdgB for ; Mon, 27 Apr 2020 06:51:09 -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 ED1F33A0AEF for ; Mon, 27 Apr 2020 06:51:08 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1jT4A6-000Ch7-48; Mon, 27 Apr 2020 15:51:06 +0200 Received: from ti0182q160-4479.bb.online.no ([84.202.168.179] helo=[192.168.1.4]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1jT4A4-0003xs-Sp; Mon, 27 Apr 2020 15:51:06 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Michael Welzl In-Reply-To: Date: Mon, 27 Apr 2020 15:51:04 +0200 Cc: "csp@csperkins.org" , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <05A1D6E3-88A4-4D9D-A482-34210B2E956C@ifi.uio.no> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 84.202.168.179 is neither permitted nor denied by domain of ifi.uio.no) client-ip=84.202.168.179; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.4]; 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: 85754BC5276B4DB5565787699F30E3FD9D7945A7 Archived-At: Subject: Re: [Taps] UDP rendezvous X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 13:51:12 -0000 Hi, Thanks again! I knew that WebRTC plays all these tricks but must admit = to never having dug into the ICE details. Regarding =E2=80=9Cwhere the WG is in regards to=E2=80=A6=E2=80=9D - I = think Colin=E2=80=99s previous email with the 5 steps is a good summary = of what TAPS is intending to do wrt. rendezvous mechanisms. Cheers, Michael > On Apr 27, 2020, at 2:59 PM, Magnus Westerlund = wrote: >=20 > Hi, >=20 > Michael if you want an example of an API that contains the ICE related > rendezvous aspects it is the WebRTC. https://www.w3.org/TR/webrtc/ >=20 > You will find the ICEserver with configuration information. Note also = how > candidates are handled. I would also note the possibility to enable or = disable > trickling of candidates. Which is possibly something an application = could want > to indicate. I know the ICE parts is only a part of the complete = WebRTC API so > there is a lot to wade through here.=20 >=20 >=20 > I would also note that there might be an other aspect of embedding ICE = under the > hood is the potential to use this as a method to update the path used = between > two peers during an ongoing communication session. There are two takes = on this. > Either the more standards compliant way of triggering an ICE restart, = which > involved application interaction through a new candidate exchange.=20 >=20 > Or the less so which is to not really terminate ICE. And instead keep = your > checklist alive and continously verify what candidate pairs that = actually work > and use re-occuring nomination to move the application datagram flow = between > working candidate pairs ( > https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/). I = would > recommend avoiding the later, but wanted to mention it for = completeness.=20 >=20 > As I haven't been active in TAPS, I would appreciate any pointers to = where the > WG is in regards to the need for parameter exchange that need to be = done by the > application using the TAPS interface, rather than letting the lower = layers > handle that aspect.=20 >=20 > Cheers >=20 > Magnus >=20 >=20 > On Mon, 2020-04-27 at 13:38 +0200, Michael Welzl wrote: >> Hi, >>=20 >> I=E2=80=99m answering this email, but Magnus, consider yourself = answered too with a >> big THANK YOU for your thorough explanation! >>=20 >> I agree that we want some (much!) of this functionality =E2=80=9Cunder = the hood=E2=80=9D if >> possible. And, of course, I agree that we don=E2=80=99t want the = application to be >> aware of e.g. UDP specifically if we can avoid it. I think we=E2=80=99r= e all on the >> same page on that; but I think that, indeed, the text in the API = draft needs >> some fixing. >>=20 >> Colin, thank you very much for outlining the 5 steps below: they give = a very >> good context for this conversation. So, I answer in line below: >>=20 >>> On Apr 27, 2020, at 12:23 PM, Colin Perkins = wrote: >>>=20 >>> Hi, >>>=20 >>> This is one of the areas where the drafts likely need expanding, but = I think >>> the model is: >>>=20 >>> 1) application configures STUN (and maybe also TURN) local endpoints >>>=20 >>> 2) application calls Resolve() on these, to find server reflexive = candidates >>=20 >> These two steps are reflected in the API as it stands, and so this is = already >> reasonably clear, I think. IMO, nothing to do here. >>=20 >>=20 >>> 3) application shares these candidates with its peer, via = out-of-band means, >>> and receives remote endpoint candidates from the peer >>=20 >> Based on Magnus=E2=80=99 email, I suppose that this *could* be done = in standard ways >> with trickle, and hence theoretically put =E2=80=9Cunder the hood=E2=80= =9D too. >> But, I think that keeping this in the application space for the sake = of TAPS >> is quite reasonable. This step is perhaps implicit in the text, but I = think >> it=E2=80=99s pretty obvious that it would need to happen. People = doing rendezvous will >> have to be aware of this step anyway, so I see no real problem here. >>=20 >>=20 >>> 4) application adds remote endpoints for the peer=E2=80=99s = candidates >>=20 >> My first hiccup: I don=E2=80=99t see that this is supported in our = current API - how >> would one add remote endpoints? I think, the way we have it, = there=E2=80=99s only one >> for each Connection. >> Have I overlooked something? >>=20 >>=20 >>> 5) application calls Rendezvous(), which performs the ICE-style = probing to >>> find a working path, based on the candidates, then returns s = Connection >>=20 >> THIS would be really good, but it=E2=80=99s not at all how I read the = current text. It >> says: >>=20 >> "The Rendezvous() Action causes the Preconnection to listen on the = Local >> Endpoint for an incoming Connection from the Remote Endpoint, while >> simultaneously trying to establish a Connection from the Local = Endpoint to the >> Remote Endpoint. This corresponds to a TCP simultaneous open, for = example.=E2=80=9D >>=20 >> My interpretation of this sentence is that Rendezvous doesn=E2=80=99t = do much more >> than listen + send something, using the same local ports. For TCP, I = would >> have implemented this functionality by just doing an active connect, = using a >> pre-configured local port (TCP will retry sending SYNs, and if both = sides >> issue this call with the correct ports, I guess it all works out = eventually). >> However, from below, it seems to me that such an implementation would = be doing >> way too little! >>=20 >>=20 >>> This relies on the Endpoint abstraction supporting STUN, which is = maybe >>> implicit in the drafts.=20 >>=20 >> Yes - there is text there about STUN configuration, but nothing about = it in >> the Rendezvous text (unless I missed it, apologies if I have!). And = it=E2=80=99s not >> just STUN, it=E2=80=99s the ICE-style probing, with various = candidates supplied, >> that=E2=80=99s missing. >>=20 >>=20 >>> Also, as usual with TAPS, the application doesn=E2=80=99t say that = it wants UDP. It >>> says it wants, e.g., RTP preferably over an unreliable connection, = and this >>> higher-level protocool gives the de-framer the ability to = distinguish the >>> STUN packets from the data packets. >>=20 >> Okay, I understand this=E2=80=A6 but what happens if UDP *is* the = protocol that is >> available (not e.g. RTP), and the application calls Rendezvous? >> (I guess failing, with a useful error code, is the best choice, = then?) >>=20 >> Again, just to be clear, I agree with everything you say here, and I = thank you >> (and Magnus) again for explaining it to me! - I just want to get = the text >> right. Actually, I was just trying to understand how to implement = this call=E2=80=99s >> functionality, and was left puzzled. >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > --=20 > Cheers >=20 > Magnus Westerlund=20 >=20 >=20 > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Mon Apr 27 08:25:46 2020 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E07C83A0D2B; Mon, 27 Apr 2020 08:25:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rfc-editor@rfc-editor.org, taps-chairs@ietf.org, magnus.westerlund@ericsson.com, draft-ietf-taps-transport-security@ietf.org, taps@ietf.org, Philipp Tiesel , The IESG , caw@heapingbits.net, philipp@tiesel.net MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158800113489.16024.290222408516972229@ietfa.amsl.com> Date: Mon, 27 Apr 2020 08:25:34 -0700 Archived-At: Subject: [Taps] Document Action: 'A Survey of the Interaction Between Security Protocols and Transport Services' to Informational RFC (draft-ietf-taps-transport-security-12.txt) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 15:25:35 -0000 The IESG has approved the following document: - 'A Survey of the Interaction Between Security Protocols and Transport Services' (draft-ietf-taps-transport-security-12.txt) as Informational RFC This document is the product of the Transport Services Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ Technical Summary This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a Transport Services system may need to support. Moreover, this document defines a minimal set of security features that a secure transport system should provide. Working Group Summary The work has strong consensus in the WG. An early Secdir review raised concerns against including non-IETF protocols without stable specification, e.g., Wiregugrd, CurveCP, and MinimalT, while not describing other popular IETF protocols. The authors decided to keep these protocols in the document as there have unique features they wanted to include, and to add the protocols requested by the Secdir review. Document Quality There was good amounts of review in the WG last call. Further focusing of the document was done as result of the IETF last call. Personnel The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.