From nobody Thu Oct 1 02:18:55 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356623A0EE3 for ; Thu, 1 Oct 2020 02:18:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160154393377.459.16436020833916984279@ietfa.amsl.com> Date: Thu, 01 Oct 2020 02:18:54 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 09:18:54 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-10-08 Reviewer LC end Draft Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-07 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-07 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-10 Phillip Hallam-Baker R2020-03-09 draft-ietf-calext-jscalendar-31 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-26 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Christian Huitema 2020-10-08 draft-ietf-opsawg-model-automation-framework-06 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-10 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-19 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-11 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-07 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-12 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-13 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-11 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-12 Paul Wouters 2020-05-25 draft-ietf-capport-architecture-10 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Chris Lonvick 2020-10-15 draft-ietf-lisp-pubsub-06 David Mandelberg 2020-10-26 draft-ietf-lisp-nexagon-04 Next in the reviewer rotation: Catherine Meadows Alexey Melnikov Daniel Migault Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Francesca Palombini From nobody Thu Oct 1 05:34:56 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF363A0FF7; Thu, 1 Oct 2020 05:34:51 -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, RCVD_IN_DNSWL_BLOCKED=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 lIChWyASIqDZ; Thu, 1 Oct 2020 05:34:50 -0700 (PDT) Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) (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 038D73A0FF5; Thu, 1 Oct 2020 05:34:46 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id x14so5356624oic.9; Thu, 01 Oct 2020 05:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=7TYw5l3NjOVYfCvB7HzCELnoSxw9kmUSSBytsaielDk=; b=XqFIMGzFB6+1/FggVbozKfUcX24sOOLCWjj2Y5KDWQ3UHKMcoHmdSSdM7bmi+tLisf DEH11gVRcBopGvFTXTyJbPysPiK/HN0x/kv/RVhT011HM2n706Gt5tUh2d9WQL8lN2HN K7IGfqFXHicyed5SgtYaOrLYoIWB7ogfuVGAPcn0CSvfaS8rCbHolIzfchREhegrrxoW 0T7iNRAh3Y/IVUWM8CtPy04V22heq8lJS1oW3sjd7hwRCadHC36MpP0SfJrqw/6jwxYv GEj7vZ8nUl7e1SeSvmr2Tq1zD88f4SzUehL8W4xoEruvAhHFYiLyn6OUnUBMmFm9xBW+ 96Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=7TYw5l3NjOVYfCvB7HzCELnoSxw9kmUSSBytsaielDk=; b=sWuz5ydt5+QqaY8zjIHTCDblP7NvqmwYgb6Kuyzz6uWxyYmimO9y8MjUoP+Kk5Zeak pBAequamsjuzzHtucAkgQ0zEXuWiNM4gKxiDVQjhZ4YpNjbEV1pMk8NZK+oW6U49+uov GZY1V6sSQC7e6h5GZjEj4yUpHXJxrKi5k2MzOKJ3BoNVJ32FIP+MQIDiN3qgQU/YEtmS vS2CFDD7MqSnybiamQSzJzyStlZhLhx5TMneIziHPZcZtx6Q635AEsqCtoZMy8kPtS8b pNQh8Qga2NX46MIg06vD9f6G6+38vVDC7IOVj4j1/urQ684iXA8BeTnKGtBd0zfAeqtO Zgqw== X-Gm-Message-State: AOAM530X6qwNT87R7O9yzACr7c/kdikpKaTce/YNquC1K+2zq05TQQcZ PkktFspmMs0v/9fG+wcMawMPVAc8cjI= X-Google-Smtp-Source: ABdhPJzl5jA1mbTVXTA3M8Eb8YxKknunCbciqFcx62OG/IorTgTqEpNwKx6U+6ey9kkALlQKI7qQjw== X-Received: by 2002:aca:843:: with SMTP id 64mr4121647oii.135.1601555685041; Thu, 01 Oct 2020 05:34:45 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2602:306:8b74:aad0:4964:9254:8747:be5d]) by smtp.googlemail.com with ESMTPSA id r131sm419242oig.50.2020.10.01.05.34.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 05:34:44 -0700 (PDT) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-lisp-pubsub.all@ietf.org From: Chris Lonvick Message-ID: Date: Thu, 1 Oct 2020 07:34:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [secdir] SECDIR review of draft-ietf-lisp-pubsub-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 12:34:51 -0000 Hi, 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. This is an "Early Review Request" so I'm going to mark the draft as READY WITH NITS. It appears that there's a raft of drafts of LISP documents progressing together through the WG that cross-reference each other in that they all provide foundation and support for their collective features. (I'll admit that I haven't been keeping up.) So if my nits have been addressed in another document, that just means that I didn't dig far or deep enough so please consider giving a pointer in the Security Considerations of this document so others won't similarly be left adrift. In this document, and the associated others that I peered into, the term "nonce" seems to be used more as a "token" than, well, what I consider to be a nonce. In one case it may be a random value, but in several others the value is stored, compared, and reused.  This is inconsistent with the IETF's Security Glossary RFC 4949. Also, there is a reference to increasing the nonce for a particular use. However, I saw no discussion of what to do when the value exceeds the field space. Other than that, the document appears to be well written and well thought out. Best regards, Chris From nobody Thu Oct 1 08:05:16 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25183A109D; Thu, 1 Oct 2020 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 RzbdqtD4G5wn; Thu, 1 Oct 2020 08:05:13 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30051.outbound.protection.outlook.com [40.107.3.51]) (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 84BA63A10C5; Thu, 1 Oct 2020 08:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ap8aUcuQ0LiCGFvcg+20z5rGBoQwuoYbcWP97bFad7f6XWvH+QCfO0rlBo4eZvTHBPklUl/cKCg5r14RdbqvijGgvJcod0nvtsx46x1jaAhXCd6ExP1ycED+ca42qaV7Hesye/WOFA/5ZBQCp+nvdJ675C3ymcoAz3LV1fgDoJ9eJjj4x2+/j90cJSESfIe7ai7gAOfwqNClaHFHAR/U5mOSTF/kZd1HmPP3/W8O6VJbAUofFWmgUaDqaSndKAX489NnzyMhxNzyTqVKvNtNoQ2Ytx1gs9FY4+DR7OB0k9dZQ2B7XCbtX7Qrx0jzzIDIpkgq+p34D8HAC3S/rls+Ew== 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=7thAfScPm2bVSBzEDjul7kBxxle+/HtvC2TdsCSsRFE=; b=EdxuszL1sY8BqgRmxhV4oyKI/1olM/RzM9VRNgt7W/igGIPpEghxEhZvLfnizXwSUFPkUNiM9cv7ZrTPju5t/1Vt2g1A/Wa8FRU6baA6Ai+NDQ/x64R6PoGfOk7+/an7TojBTjQhXdVUXf6fnzghVeaxfr4ex+F6wlcs4r/+hTsx5RzVWF6d+1hKV9jVatc53SLfDoXHgvMnCgVuw+vsNfujqqdUMk2I4EYmokYsoTvFotBOY0yHoItuSAyvRAHsw2DnYBpeRtmkmZrMxn4SLYCSOPrwCkwX9sLRYGuz5ExUnzbjoaA7OnfQiPTpv8NQSgf7BZKwcZZ20vv8ITZvHg== 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=7thAfScPm2bVSBzEDjul7kBxxle+/HtvC2TdsCSsRFE=; b=JaXms4FlrNqBqgOkuS5AbUUn8h251zJPu1rvYdl7pjsgegYSkhSPdj6yG9qZhgRaDBpC0wFDCuRHJCkR5pKrOMQvnpcdk15JkdUwEObxrGAZFUVMvsuKu06z6SbPF2OEEYXN0bOa+QmoKTCdRv19VXLcXSDCslXyOi2cVC8S0q8= Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM0PR07MB5409.eurprd07.prod.outlook.com (2603:10a6:208:100::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.13; Thu, 1 Oct 2020 15:05:06 +0000 Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9%6]) with mapi id 15.20.3433.035; Thu, 1 Oct 2020 15:05:06 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Grossman, Ethan A." , Stephen Farrell , "secdir@ietf.org" CC: "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" Thread-Topic: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 Thread-Index: AQHWkp6pkKliTan2Cky0cNPan4qVfal4PT2AgAqiVSA= Date: Thu, 1 Oct 2020 15:05:06 +0000 Message-ID: References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dolby.com; dkim=none (message not signed) header.d=none;dolby.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [94.21.192.99] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dcf7612e-8624-4135-f45e-08d8661b6213 x-ms-traffictypediagnostic: AM0PR07MB5409: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CGFnBibW97lGh2XYJignWwse/B6mJOQZ0DPp7QPN5EDI2eJt63rVGkLpPnaGND5DPxcatRMlMRnVT04FC/UwN4bek/qXLkhqJoOXjhl9Tx+qWGvD0iRemixR754c/oqMOaPQH+b6trf5C65YSAQI1JPyr6GOP+KD6/HClcocrXWSFObFGlOlr9bLGDYjPWVJ2FT/zCiu05rlAB/D4hw2WXBUuMsBLOIJxk6dCFYTccX1ku5xPrvgxmMLDaa3VnE2tusKlfmTA8n+lEtym3BpquSgZPGoYDaQUC4ElPQc/mSz6M8hVDT03x8ThG31+ETwUkNYH2UsaUBk9l7HdXjpnfBVqgI7fw8kiOLEgSMuKmHvRQckZ2qFIROqcaFfakhSVBUoWwW0afULOwB2J3qwDQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3603.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(83080400001)(316002)(110136005)(53546011)(6506007)(478600001)(54906003)(71200400001)(33656002)(4326008)(186003)(86362001)(2906002)(5660300002)(8676002)(9686003)(8936002)(66446008)(66556008)(66476007)(7696005)(64756008)(76116006)(52536014)(55016002)(966005)(66946007)(26005)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 4149FeDQojej1wYlHiFZnUQB8IJ8ZdKsKUK2r5ke2oIU1Kb2xEBsGmDmHeESMO4NRekPNTLpaSBViCUxs43OrBlSQy0Z7jJJWjlkz8Kya/fvUGhcO97JB670EcnSGw6p1Or0T2B7Bw0v0mt5hVVp4TC/mIyfwckMC4BVf3a9z77EjuxPbSU5QYVfRQGD+D7O+S0G7b+1UWV2dJAstbcDYqxL33vZiHWO8JwX+TG241ptRteJ57qcYysFAEFSOu3SmEBRErbqg157+O/XkHx9T/bTqr6udyRfPvH/Ym5GrCVgcRT/hufO6Rh4uf+mT9hg7DUTBKCeujZfRissfDXTjvvnDtds1l9GJzbM+QyE/hNnDuCgNrb3qsktfMWw3SGVw/BRYlYyV5FOZf8QEmhcVZEFrEohuntV+FynvjCVo2x73eLgMkPNpzjtuZs4deJYect43SdmsG7y0qUxNahj4Qjs8uGRYzNA7iE7VhtabNl577f9YjvntRlaRoAV9mZm0O8omKGF2GG9aaz5s8osB9QU9LUMqUSjGF5FgQJkvsa6E8+3+sERlM8/PM2nQZpnag7wfrFsiK4T2MFRKAR4hvxT7cwRA4nqxy8cFQ3OFzmTGxRJQeYlFNGMjn4+q8q9imjF722yTyhUF8WbgxfD6A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3603.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dcf7612e-8624-4135-f45e-08d8661b6213 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 15:05:06.7650 (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: doD8qvc057onq3iBFmp9hQmXHBtaEdLrnoul7XeIzicq9fQLBNLCvjoaEzn6NOD0qo/BiYhcKk09hbKUwyeRTv1vSmltDS0yQNDUwiLLK2k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5409 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:05:16 -0000 Hi Stephen / Ethan, Many thanks for the review.=20 Draft-ietf-detnet-mpls-over-udp-ip focuses on the scenario where two DetNet MPLS nodes are interconnected via an IP sub-network and covers data plane aspects. Security aspects of DetNet are covered in DetNet Security draft.=20 DetNet flows are identified using a "6-tuple", what includes UDP, TCP, etc. In my view using UDP/IP encapsulation between DetNet nodes - covered in draft-ietf-detnet-mpls-over-udp-ip - is a subset of the general DetNet IP=20 flow case, where the 6-tuple is used for DetNet flow identification. So,=20 no extra security scenario here. Thanks & Cheers Bala'zs -----Original Message----- From: Grossman, Ethan A. =20 Sent: Thursday, September 24, 2020 10:28 PM To: Stephen Farrell ; secdir@ietf.org Cc: last-call@ietf.org; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-ip= .all@ietf.org Subject: RE: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-ove= r-udp-ip-06 Thanks Stephen. FWIW it isn't too late to add some text to the DetNet Secur= ity draft regarding DetNet over UDP, if someone can think up something usef= ul to say. I suppose one could simply mention UDP in the same breath as TCP= (implying that the same general security guidelines apply, if that's our s= tance).=20 Any thoughts (from anyone)?=20 Thanks, Ethan (as Editor, DetNet Security draft) -----Original Message----- From: detnet On Behalf Of Stephen Farrell via Dat= atracker Sent: Thursday, September 24, 2020 11:15 AM To: secdir@ietf.org Cc: last-call@ietf.org; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-ip= .all@ietf.org Subject: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-ud= p-ip-06 Reviewer: Stephen Farrell Review result: Ready (Sorry for the missed review deadline.) Other than general doubts about "I'll only use this in one administrative d= omain", the only specific thing that concerned me here was that draft-ietf-= detnet-security doesn't seem to include any analysis of detnet/UDP (and ind= eed says that detnet runs over IP) and the security considerations section = here is purely by reference. Given that draft-ietf-detnet-security seems to= have done a reasonable job of analysis, it's a pity to not have that for t= he detnet/UDP case. All that said, I don't have any concrete problems to hi= ghlight with detnet/UDP, though of course I've not been thinking about this= as $dayjob, so there may be issues there. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Oct 1 08:12:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF873A0BF2; Thu, 1 Oct 2020 08:12:34 -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, 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 (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 1WcvkhyDWmlt; Thu, 1 Oct 2020 08:12:33 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 840583A0AFE; Thu, 1 Oct 2020 08:12:33 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id w2so3312787wmi.1; Thu, 01 Oct 2020 08:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OtMOKqGoprrWxMxhrIxTq2FueUH6ziHN851QmzqXcU0=; b=CfrqOLK1FPjEpIammBTwZCyVbKcz04rzd5iGw+Y85jZg25EeEOimVKsoNAyn+Bp0aD Wl13ZujCCP6lgD9tYAXYiczP6jQB9Tp2Ublclr27ocQGQLCabaVfjt5iHgx6r3rsjDMk OO/Ld4eDrgI6+mYupNFg/Sn22zl5TmPzkqBWBV9UgowQlMjRqJUjmpWzFx0kaDkcjNSI VwqME/l0Jlv83fhNaLQ3ZshCROhxqTYpypycCDR6TrWBSzD+OhSewzuQYDkG2Ale+W0N 4RSAlNhBe9lC6IY7GJBprlyCq3DuXptl3wt1iUD1mwPB0M2HVJrOxV8xx29bZOre0Zta LsIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OtMOKqGoprrWxMxhrIxTq2FueUH6ziHN851QmzqXcU0=; b=cJop6yNibudoNWNReoK5uT8B++gUwXz4zjthiTOWgHgP5J8lKDnpp3lwBvJY6hGDVW y80DIaTG2dutcPCSvfMWTEyK7td4TmnLlZyuxabVSvu37LY2U5iH143E+VPkrj17PDc/ 2hCp6d5pVJkVDTbfEZstdqC6f1nHm7ILWfE6yzczk1KyGzUSwbxIk/0H05QruxuQ5q8W wOOAeOt8L3PA9W9YSZL6bTfvvjp+Bt1AOLt9wykUtfAqApJC8GRpQZ7xKS7nXoAAR7Wx Bug2S/cYk+dEJ8WDd0zAq1617KT2gqul/QBYytoORQhm2kekrJbDdnu3fkiH6Plv4l1V q8UQ== X-Gm-Message-State: AOAM530k+SouSt3IYuB0tGeMbGL1f+6CWHJrMI2qZ2y3ne2vIp3xCjKs iGctLFazO7uXA52iRqg5tfY= X-Google-Smtp-Source: ABdhPJy3Qog/uU0w4F0XNOrpJB5n0SQk53BibwA0BUKn6mx7VFmWSJRsqe7DD7pJ3qgfQUehMrSvTw== X-Received: by 2002:a05:600c:2186:: with SMTP id e6mr476579wme.189.1601565151809; Thu, 01 Oct 2020 08:12:31 -0700 (PDT) Received: from broadband.bt.com ([2a00:23c5:3395:c901:d1e7:4113:7587:7b0f]) by smtp.gmail.com with ESMTPSA id n6sm369703wmd.22.2020.10.01.08.12.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2020 08:12:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Stewart Bryant In-Reply-To: Date: Thu, 1 Oct 2020 16:12:29 +0100 Cc: Stewart Bryant , Stephen Farrell , "secdir@ietf.org" , "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> To: "Grossman, Ethan A." X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 15:12:35 -0000 > On 24 Sep 2020, at 21:28, Grossman, Ethan A. wrote: >=20 > Thanks Stephen. FWIW it isn't too late to add some text to the DetNet = Security draft regarding DetNet over UDP, if someone can think up = something useful to say. I suppose one could simply mention UDP in the = same breath as TCP (implying that the same general security guidelines = apply, if that's our stance).=20 > Any thoughts (from anyone)?=20 Ethan I would be rather surprised if anyone tried to run a deterministic = application over TCP. TCP would undo all the temporal determinism and or course it looks after = packet loss. - Stewart From nobody Thu Oct 1 10:44:07 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FB63A1181; Thu, 1 Oct 2020 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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=dolby.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 q5NKrz2K2iGJ; Thu, 1 Oct 2020 10:43:58 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2109.outbound.protection.outlook.com [40.107.243.109]) (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 563CF3A1180; Thu, 1 Oct 2020 10:43:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PdItf1ZY61oiWgm+13MdVlAdt6Bxw2sxkGDN1sFLawaTZESJHCPgEAqayIF8IfnN7oxq8S98vU/3thKHh2tT4CKHBowMqgNs2FLnE0hkNcc8IMXBzBg12URV0WVQPQnWuYI2L9JOg/bmnsuv5THP/mNRSw79FrpVLCgkCtrsMzRQxs5h/mLMGn9GvxWfNaVoxoCpEJSfPJkt6dQLl98Rdn4Vmm6bD1ag6j0O4TnCfydUFrgHj0c6SR5Am5UK2vPCqUAnBl0bYdCEz/VlSHT8LqLIr2NRQljw/OYlTIRYav9GQJHKHhdzKd31zcc45SIxpuphoziJ/Ybx3lFoTSxgEw== 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=CNbLkrWaUlyCC8ZlJtVTPcVRZxj8hnJM+fudrQQzQc4=; b=QlvzBvPodHkyHG/sqzmTlQh6wEfCX7+C8lH4w/nfgxkPoebDAPmbvCZ5n1ZgPWSgzOPJ1mKaEtv28eTIsCOru+vFm56UGIjV/uiGsBT3v7QWdyPcyosDEEKvZ3jkEISXy0qopQQaDpYxxlAmzkJuSJfLwCSkZbgDxnFdoIvZyg+MEfDawjLmK/KOC02znGQ/p1OjMvLaRXzcLxUQrD+IePpxYbkIreoIhv4HBwTc0pVOX/KlqfToqdue0lbhYSLX+nUOmZUbwizV3VEh/AHFeaDQr+qfe6Xnpys6ENiE5uY+ICI/QhDHFxOeIHovD+LchNvPnW5v5qbr+2EVqGyCeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dolby.com; dmarc=pass action=none header.from=dolby.com; dkim=pass header.d=dolby.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolby.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CNbLkrWaUlyCC8ZlJtVTPcVRZxj8hnJM+fudrQQzQc4=; b=CbgFD0wbfmsmzdJ1mRAEMj3RTPg9eOFuWZekTA58PuZo6dDWQVyPODgvGTzzxN/voPmwllDGn+ai1n9HM2zjz7SRG7eotGmoLqoS8hkhtfdW2njriqDMYWHofdHJuWNYNLCYctfTbXf4kmb6KUsBtnrn+A6qzN4DNAhUlAFq4B8= Received: from BY5PR06MB6611.namprd06.prod.outlook.com (2603:10b6:a03:23d::20) by BYAPR06MB5206.namprd06.prod.outlook.com (2603:10b6:a03:c1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.25; Thu, 1 Oct 2020 17:43:55 +0000 Received: from BY5PR06MB6611.namprd06.prod.outlook.com ([fe80::6d84:5adb:4cb5:f730]) by BY5PR06MB6611.namprd06.prod.outlook.com ([fe80::6d84:5adb:4cb5:f730%8]) with mapi id 15.20.3433.038; Thu, 1 Oct 2020 17:43:55 +0000 From: "Grossman, Ethan A." To: Stewart Bryant CC: Stephen Farrell , "secdir@ietf.org" , "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" Thread-Topic: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 Thread-Index: AQHWkp7QtLhjU0mW50S8oNMAEUQjo6l4Ol6ggAqq8oCAABDtoA== Date: Thu, 1 Oct 2020 17:43:54 +0000 Message-ID: References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> In-Reply-To: <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=dolby.com; x-originating-ip: [104.129.202.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9fcd0191-ee5c-456e-f526-08d866319171 x-ms-traffictypediagnostic: BYAPR06MB5206: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 63aZzuR4vXn23ylhdgHJx1r30xNSvVK+GjTkoPX4esISuUAkUuBAvpRR4GWYirPvb5pQd/YOISjdxkH18i62xxz0AGfJ8GKssuwWAcMSQpovzi/cr+OJXox+j6uJEV+Vj/QYaf/D5s6JO3XV+OFS4JUl8CTPgzz9ADeoET1GnWT5bFbkhCokMKXHLmNhqXYraGV5ec694DaGgKYHi4Y16dxHtJq3oIs/xL2amImggxXl9WXADJAH5NLrF/8scFU+kyoB8e8UD2UpLSS2KQXSaMZYRxrObxSthYXcTY+SwDK+WGDa77uUwtTvefwQGWA4dVNQIs2JUlkSYC5OC4W68RFfmFuHHbG8ConfkwX6cqkDcHqt9upac9ZbnpTyOY3+ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR06MB6611.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(366004)(136003)(376002)(396003)(346002)(5660300002)(83380400001)(33656002)(8936002)(8676002)(6916009)(54906003)(66946007)(86362001)(76116006)(53546011)(55236004)(26005)(64756008)(2906002)(66476007)(9686003)(66446008)(55016002)(66556008)(71200400001)(52536014)(7696005)(4326008)(478600001)(316002)(186003)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ItO0LYjh+j/GuVvL0eIBtd6LA8NmvwyQDH6Qx+L1fxYcBSWY5wF3d1Yn+/WGM1h+nco6yqZo+CpIeHLif8ThVC+0UBp4g7FZcXOG1Q58yT8uh11RGKyKvXTI3upXT1Fcmsdop7Uw7EXm7JUFJ0M/smUjtuEu77AsAWJwRY6zFS8+jDyOYIFr1Nx7eCK5LnWjchlZOSZDZgy8ZPtMawyBTPbId7kiK7qvSqC4yJ8lMPvjXw+Gf9j/GwxOLEVsrvbuMqUM4mn2Se2JmC30BZca2vkCii5gKDVvOTupmtP8ByPumMKXBrgozq/Mtj1eJahVBfRMt/+iIR9eTJieR6o+BXzB+o5QXB/D2W8JNQ1EM4nDAVWHBS1MhnjCk2SgGe37v2KcxUG/avnGYI3leuGdoN1zERYA8pFcYMuanRMivlJIyiQajYao0dr7YZPw5PhaC3Z/t8MB4wifdxD/+2KPCenWzK/xLo/ZY5RpkNMmEDLrPqBWPC5/NV3dy9vFL24bnQqiz50oYYTc1zQT1QeeT8W/03q7Nwbp/lFSlaACSgZwYpGNsLIkUSW9A0vI62/gLW3cIlvqR+++x1lE7/kfL+qYFa0sGjRbSFjw0seKc6QKX0KfjYo2itYE78OLa0iCAMYOMcwIXMSnsXShErJPIA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR06MB6611.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fcd0191-ee5c-456e-f526-08d866319171 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 17:43:55.0648 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sqZDfzJZUcxO6Nz/EncoQr9JAa5abOs/yJvfws0Ke6XNJaea9tHD34D6JSBoR6Kw6WukVX3iQa7vbDo0L4uEZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR06MB5206 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 17:44:00 -0000 Yeah the thought occurred to me "why would we mention anything above IP at = all?" I checked the Security draft and there is actually no relevant mentio= n of TCP or UDP. So I think this is a no-op as far as the Security draft is= concerned. Of course I could be missing something, so please correct me if= necessary, but that's my current understanding.=20 Ethan. -----Original Message----- From: Stewart Bryant =20 Sent: Thursday, October 1, 2020 8:12 AM To: Grossman, Ethan A. Cc: Stewart Bryant ; Stephen Farrell ; secdir@ietf.org; last-call@ietf.org; detnet@ietf.org; draf= t-ietf-detnet-mpls-over-udp-ip.all@ietf.org Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-ove= r-udp-ip-06 > On 24 Sep 2020, at 21:28, Grossman, Ethan A. wrote: >=20 > Thanks Stephen. FWIW it isn't too late to add some text to the DetNet Sec= urity draft regarding DetNet over UDP, if someone can think up something us= eful to say. I suppose one could simply mention UDP in the same breath as T= CP (implying that the same general security guidelines apply, if that's our= stance).=20 > Any thoughts (from anyone)?=20 Ethan I would be rather surprised if anyone tried to run a deterministic applicat= ion over TCP. TCP would undo all the temporal determinism and or course it looks after pa= cket loss. - Stewart From nobody Thu Oct 1 12:05:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BBC3A0E48; Thu, 1 Oct 2020 12:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=joelhalpern.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 xvu_ZaZEFWDz; Thu, 1 Oct 2020 12:05:29 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 6B9643A0E46; Thu, 1 Oct 2020 12:05:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4C2Myd2C22z1nvpN; Thu, 1 Oct 2020 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1601579129; bh=LmuL0B01meMeqT/EOwvzN89hFIvvv3vpDTag4q1DQMk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WmlxAv2Cu8GC2E9p6XLh1pX+gsnbf5w4d/EQmhia56PZW8Jbv3+l5qZ2eqvOWf4bw i3k9mOwfQGMx3HD7RfslFH+vfC3ZV8SNqI2k4dr6UDwuM7b3F+FttkwMj1gsHl7apB zTHoVS6E58UI1+55JvfFsN2pCS56QnlI7LheEttM= X-Quarantine-ID: <2_O1i3_6FNLd> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4C2Myc2xtfz1nvcS; Thu, 1 Oct 2020 12:05:28 -0700 (PDT) To: Chris Lonvick , "secdir@ietf.org" , draft-ietf-lisp-pubsub.all@ietf.org References: From: "Joel M. Halpern" Message-ID: <54e37d9a-8daf-c582-cb43-73114345843b@joelhalpern.com> Date: Thu, 1 Oct 2020 15:05:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-pubsub-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 19:05:31 -0000 Thank you Chris. That is helpful, and I am confident the authors will clean up the terminology. Yours, Joel On 10/1/2020 8:34 AM, Chris Lonvick wrote: > Hi, > > 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. > > This is an "Early Review Request" so I'm going to mark the draft as > READY WITH NITS. > > It appears that there's a raft of drafts of LISP documents progressing > together through the WG that cross-reference each other in that they all > provide foundation and support for their collective features. (I'll > admit that I haven't been keeping up.) So if my nits have been addressed > in another document, that just means that I didn't dig far or deep > enough so please consider giving a pointer in the Security > Considerations of this document so others won't similarly be left adrift. > > In this document, and the associated others that I peered into, the term > "nonce" seems to be used more as a "token" than, well, what I consider > to be a nonce. In one case it may be a random value, but in several > others the value is stored, compared, and reused.  This is inconsistent > with the IETF's Security Glossary RFC 4949. > > Also, there is a reference to increasing the nonce for a particular use. > However, I saw no discussion of what to do when the value exceeds the > field space. > > Other than that, the document appears to be well written and well > thought out. > > Best regards, > > Chris > From nobody Thu Oct 1 12:35:58 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8FC3A005C; Thu, 1 Oct 2020 12:35:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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 (2048-bit key) header.d=dell.com header.b=j3/Q4nuy; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=AABvcGLj 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 KCAzoBm2kkIx; Thu, 1 Oct 2020 12:35:48 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 0CA963A003F; Thu, 1 Oct 2020 12:35:47 -0700 (PDT) Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091JM5Vq001548; Thu, 1 Oct 2020 15:35:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=R1REqzhthhYwq8hL6AbQJqZEbcxvlwyFuhuBdCMEUkw=; b=j3/Q4nuy7Vhgi2cglhmL8yRW8sRKcqFggORP8Wzd5WYHWnegnNg6Fuiyn2ddm0/PUaaM 0LP1thxHfaJQ/qeAkPHl6kbYlnoxeVGojAuIURsN2HM1go7AsHzNSVejg2tuk2rhSDSd qdu26/4hudPKgZ/7oXxBfy4i/TB+tlkwQP+P0t0YpTgU/w01o6XMNEhuXZhIUgEC7VVD 5VXwdQIq1W164ExSZ8OxhnwnjmHRxjceGGs5cLi/F+qcskgXz+GE47tYmGdxeuPU2uIi oZNes8jyTshvGzNmYXQtmq5CtcOf2M/8ZWZdVQJ0/mBgahMqwjNLtV8V3rr1NflmYqRA nA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 33t1nm363e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Oct 2020 15:35:41 -0400 Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 091JYtbX051679; Thu, 1 Oct 2020 15:35:40 -0400 Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2053.outbound.protection.outlook.com [104.47.44.53]) by mx0a-00154901.pphosted.com with ESMTP id 33wmkj0pr7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 01 Oct 2020 15:35:40 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GVwfgFgp6XjnkuQAJIPiPA5N4/Sd1M152RJ6Fv382Wb/Arfnl4nqXC7218B/V8rT0Gco0w7vemry+f/5LLNwY2My7RcvoTcNCiEx4BpJy+KndqOG5MhBys/aYkuVeg6LKy7edV+vikbQiSPMnevVjCRByDL8wb6UPIKZ4ufhXvfjiDjkFRNqnDAGl4YayQVxlJGOd4hy5j1kqGl/ihpkMNw/rTcoi9SbirkNArqhqGT1la1SlneJMHFBozO0IXFZ3PJYH5F2sSuIGNZB2U4ifZAanL8xsKhsTbElX2cFniUOO93fFn2DCvnEyD0ajkHCGV4KQYoheTMivbVP9AMNgQ== 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=R1REqzhthhYwq8hL6AbQJqZEbcxvlwyFuhuBdCMEUkw=; b=Tex8w4UcIByQ4J9QZE2DGQTvkORedE0jX8jPlxUzasARZ4wQm1mn0GIgR8kuIvYreF6ny/BvKEJJktzjT4tJJLPgsj0ykImCXr0tjfSoNVerXd1xwWH34SouI1gsrUywqVq1Dmq53jLAry8DXhFRWBfRvzQ/CApeTHsrHXL6zCfXoDvDIRbfTLVGATvLQgZPceqwt6ayEjZ8r/7kxsp25bRjwoAsNIW2Ci3MvdQg2L8JFukVQDEoApDeup6wPflsApJSfT7/wdfTwzPFu/b3q0hzdIh4GqLSpA9LIuRbxlhgVRvMI3DBo4WGcdyhydz1ULn/xpBb7QajNPbb8ceR7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R1REqzhthhYwq8hL6AbQJqZEbcxvlwyFuhuBdCMEUkw=; b=AABvcGLjwpjpbHdiyEjhZW87a4+b8BZ3edw9q/J4+bFR9KiXOuhdsPtrtg8G7h3ZmnImlTzY5YUaqYb2scZXZ/8fIGr1wUlHK6n/AH/Njhw58E5ru+ZU4aYMTlQiHI/xRT5fdi89+1FXM7M2gJT7YlpvM8tqiOvK8gUtMEiamb4= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB4061.namprd19.prod.outlook.com (2603:10b6:208:1ef::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Thu, 1 Oct 2020 19:35:36 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b423:5f36:f591:2fcd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b423:5f36:f591:2fcd%6]) with mapi id 15.20.3433.034; Thu, 1 Oct 2020 19:35:36 +0000 From: "Black, David" To: Stewart Bryant , "Grossman, Ethan A." CC: "secdir@ietf.org" , "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" , Stephen Farrell , "Black, David" Thread-Topic: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 Thread-Index: AQHWmAVHkKliTan2Cky0cNPan4qVfamDISEw Date: Thu, 1 Oct 2020 19:35:36 +0000 Message-ID: References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> In-Reply-To: <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-10-01T19:28:27.3431644Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=f746dcf1-0135-4cdd-8a84-7fd8227feb67; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=dell.com; x-originating-ip: [72.74.71.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 785ffc23-4314-4c30-1b34-08d866412bab x-ms-traffictypediagnostic: MN2PR19MB4061: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ePg6Ku6P1QgTizbtPiQwxd7rf9F2+Uh0z9e7oeTA2jWqFAEF61Xr3Wpks+GcqKWFYV02l5XZelmU/mqHeIG0Iqc68F7FyocltHi886LV7NOCbP2Yawr8tM2ArAvw6t+5uerZ3VoEx2/p9k+3Sa0UYqPRyMET/N+qjYROYak9UEalf7AA14xUNsKORZE0T0eB1C5beHmvpVp0oVRHHVVQlsiCAfE/lvWnXzPOXvdmUJxXzyyNiz6KTW1KtP0i8AZlLx19ir+ZOFIJ9Yuauh11GtRTYjrZ1kLy9GoMpbk6WBdWzrkSUZD3WP5JSHG9xQRtRgYJsQdxV04lXraW+X01ieEEhceH+G7S9FJ8FcdIJPaBwympwU+jdLYeCAPHzGUgA7rBbwpVRjWk1oB5pa6rGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(376002)(346002)(366004)(54906003)(110136005)(8936002)(316002)(33656002)(186003)(26005)(83380400001)(966005)(2906002)(9686003)(107886003)(4326008)(55016002)(8676002)(478600001)(66946007)(66476007)(76116006)(53546011)(66556008)(64756008)(5660300002)(86362001)(7696005)(71200400001)(52536014)(6506007)(786003)(83080400001)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: oQh3cHAX8OecK5eM5Vw8l7Pi/r68K4UUK4z1usVqtPT+oPa2urRx4XtJ+GS6q2H8HJ3eVWPEVI0fcVF1vlKX7lZ5UkGhCwF9enhZSH73rUcrE8eGW6l2V1t7D0yJ5ViBoIPeH3zm5H8tjiNt8DGCrLX1p1gxZ+8TyqKa5mhRHI3e2yrzCDvZwLDEctgUOpV7G8XYWGXiHtiFoUZPLJazS9kIMNJ+aJAEdO9oCIHwIbur/ybaMZWUFcQ2ha5GAKkuuLuLTlo5DsfAfm5/A+8lt2nrq7JHNohWBKvBOs4LxAfjDDelb5dbxLJXXEPUWtlelHQ8OY2K1W6PHNO87qxc/D/pgQN0mQgwejpBulDnwOH28LJRLe1wBV6rVp8/XtvK4qIkrglmrC7D252spnIpZNxlkedk6V+5cQfTTODbmng6vPc5iZZO8b6UdqNuq/M9ThAwZsdnWWGUtk5naPU1FaM3LeN1i1mA9HT4G3jlpETJwQxkXVOMxr8IMl7CrG4PN6azFdcz0Vjdj8pIKWCy7Xy3InAVfJtXYYtqO2+IjaQLsyBodqcjNhI8+FoPZiNnR89KQcBewH9osXPLswN5mB2PtEPAq7AbAFN4gbL9Ls4zQX0nuAWBPEawuBi4A2qLH/L3yWgM8+VZrQBmAEkgNQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 785ffc23-4314-4c30-1b34-08d866412bab X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 19:35:36.3142 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +naaxFZWTuKbhIEJd+1957P/3pwkQbm7tJlWoVRprQc+z5WZhwagIYGKg6gFUgbr1Z4OfY1fRbQU+BjTsJRh6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB4061 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-01_07:2020-10-01, 2020-10-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 mlxscore=0 phishscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 priorityscore=1501 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010010157 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 spamscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010010157 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 19:35:50 -0000 Playing devil's advocate for a moment ... > I would be rather surprised if anyone tried to run a deterministic applic= ation over > TCP. >=20 > TCP would undo all the temporal determinism and or course it looks after = packet > loss. ... IF the DetNet service defines packet loss as a failure case, i.e., some= thing that can't happen unless something in the network has actually failed= and the preferred failure behavior is late delivery rather than non-delive= ry of impacted data, THEN TCP may be useful/appropriate. OTOH, use of TCP = increases the DetNet attack surface, as (in contrast to UDP), causing a dro= p or otherwise triggering retransmission becomes a way to attack the DetNet= service by increasing the amount of traffic sent into limited reserved net= work capacity and also by delaying delivery of received data to the determi= nistic application. I've lost track of the original context, so I'm not able to suggest specifi= c text and where to add it or make changes. Thanks, --David > -----Original Message----- > From: detnet On Behalf Of Stewart Bryant > Sent: Thursday, October 1, 2020 11:12 AM > To: Grossman, Ethan A. > Cc: secdir@ietf.org; last-call@ietf.org; Stewart Bryant; detnet@ietf.org;= draft- > ietf-detnet-mpls-over-udp-ip.all@ietf.org; Stephen Farrell > Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-o= ver-udp- > ip-06 >=20 >=20 > [EXTERNAL EMAIL] >=20 >=20 >=20 > > On 24 Sep 2020, at 21:28, Grossman, Ethan A. wrote: > > > > Thanks Stephen. FWIW it isn't too late to add some text to the DetNet S= ecurity > draft regarding DetNet over UDP, if someone can think up something useful= to > say. I suppose one could simply mention UDP in the same breath as TCP (im= plying > that the same general security guidelines apply, if that's our stance). > > Any thoughts (from anyone)? >=20 > Ethan >=20 > I would be rather surprised if anyone tried to run a deterministic applic= ation over > TCP. >=20 > TCP would undo all the temporal determinism and or course it looks after = packet > loss. >=20 > - Stewart >=20 >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Oct 1 18:16:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5C23A0A9C; Thu, 1 Oct 2020 18:16:39 -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=ZFAeoCzX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nrB1fFPg 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 anDx-6eQ-9WS; Thu, 1 Oct 2020 18:16:38 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957C23A0A99; Thu, 1 Oct 2020 18:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3060; q=dns/txt; s=iport; t=1601601397; x=1602810997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=75MKVA6QeY3rPY39hwPr9RjLdBRNsotoQh5anhhQVeo=; b=ZFAeoCzXJsWDQXGS9xhxh712thuK3x6biNW4Wi0pR6xocs4Fgmj0DPFH 3WTIYZVF1XFylxxE2T/D/7kHVqbHBcu7j3cT+wVTIKTcMaK4Ri/XMcJu7 AAOAPxdTLywb3faFypvbt7tyENDiUz2zUYhRLOtkII9wSl3zLnAOROE/Q I=; X-IronPort-AV: E=Sophos;i="5.77,325,1596499200"; d="scan'208";a="836045471" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Oct 2020 01:16:04 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0921G4T4025498 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Oct 2020 01:16:04 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 1 Oct 2020 20:16:03 -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, 1 Oct 2020 20:16:03 -0500 Received: from NAM11-BN8-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, 1 Oct 2020 20:16:03 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cepFXP6SunKwPJBhFq97IUs7AewFyGE1mB+DkjELSVo82Q3PaU1j8abMhU3JTkJlTp42TGZ1mtdo8wDynAkzY3Al4DjgLgtHMQWhtgtsMl+wW1MS7e0/wHP1TlTAopBY2DANZfguTvpotu9WYlp2nwELhFkHPr2UYqdg2Am+1jtdSHSqzulmeU2d8IblIZKnkK3RgZXZE7D6gDR8ot/gq4V+Dbi7aoJ9XUt6Jn7fZnn1WsS+UX+no+hGhf+sYYj5IRz5J2gj1SROOiDihvHmbHF3XrNHH1btKvTweDnu5ON1eH0T0F73tg29egVpzOAlNlGzy2k6q2z43nIBVWDAKQ== 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=75MKVA6QeY3rPY39hwPr9RjLdBRNsotoQh5anhhQVeo=; b=aqKt1FjCDhNlHqZXs9EGDk8zXGmfLwsgDwsWUGKbDonmIEz+ypxlcqb5U9KvSA58VbZyJXxRO/Pn7cdbS08ndhXXUDvTqo8f4CIwFiLOsr8IYKVCh6Lbd5ntT9vQS6Cx51eCk12mDtx5HxQVLdRBuohkqZ28ioCclY2gZn1fu65nazVwkZcUWkvZmMNCFT1I7IkegbMCbkKwUrME4Q4BS7OnrdztxlabX/+F1TF1DiQbAyTcB6PDVXtQz8CFrY+ycJQOHbyC1L2JPw1Z6OdOB+/LMbVJ20k3DZwFhUKWc6Hw7kEaObYaWSvIoRd8Ia+N0kOdgtLP7h9/zzSQIeF02w== 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=75MKVA6QeY3rPY39hwPr9RjLdBRNsotoQh5anhhQVeo=; b=nrB1fFPgTFWzW5wsUPdbErqQqCrCVnh6LoW2ElVIFwLNOLtz0ZqZAuJH6iyQ5sTunjrjpcbH0NdjsSLOF++zQpx+q3EhrUHwSVsi/40gqkqbr3eVgvbSlWcEZO2FzUGcaGs7oBWSp8bTCCjDcDKGRYucGDFpugQg9QujHSOuTIw= Received: from BY5PR11MB4273.namprd11.prod.outlook.com (2603:10b6:a03:1c9::32) by BY5PR11MB4259.namprd11.prod.outlook.com (2603:10b6:a03:1be::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.38; Fri, 2 Oct 2020 01:16:00 +0000 Received: from BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::8418:5d05:31b6:c225]) by BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::8418:5d05:31b6:c225%3]) with mapi id 15.20.3391.030; Fri, 2 Oct 2020 01:16:00 +0000 From: "Alberto Rodriguez Natal (natal)" To: Chris Lonvick , "Joel M. Halpern" CC: "secdir@ietf.org" , "draft-ietf-lisp-pubsub.all@ietf.org" Thread-Topic: SECDIR review of draft-ietf-lisp-pubsub-06 Thread-Index: AQHWl+9PLxIjCp6uzUyWBT8sMqgoD6mDG8aA///yLoA= Date: Fri, 2 Oct 2020 01:16:00 +0000 Message-ID: <4EDE4838-BA3A-4181-9CE4-521963AB62AB@cisco.com> References: <54e37d9a-8daf-c582-cb43-73114345843b@joelhalpern.com> In-Reply-To: <54e37d9a-8daf-c582-cb43-73114345843b@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.5.88.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 283634c5-0622-4476-4a0a-08d86670b934 x-ms-traffictypediagnostic: BY5PR11MB4259: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ift41yX7EXElhQ6FnQ1/KUj3YItdsN9t/vsuk6Vdr3+yCnEpCaOUOO8f6dtxBMDP2oziT+o0tcRt8gKxBKyIiSqp0MGdkKkUlytaEPau48qZNXAWyi/4Zl72uO47fwkhEHfofwiVzgSbBHpxmr3ujbsx0f7pL5Vc8/jxNldpALot8m7b6fi97kmEDqS9pAhNl6hhIn9Gve58jgC06zNnUnbd3tjlD591d236DWrK3JzZ6AOzOGJV6TQURuEJXt2fUTQuvsyNR9aZ9Ax9VT6itvtxArVmlXZS0SDtr+kCJNaJUnCDw5EKpW4sV6dcsZHo x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4273.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(136003)(366004)(376002)(86362001)(71200400001)(6512007)(66946007)(76116006)(66476007)(66556008)(64756008)(66446008)(2616005)(36756003)(8676002)(33656002)(5660300002)(8936002)(478600001)(4326008)(53546011)(54906003)(110136005)(2906002)(6486002)(186003)(83380400001)(6506007)(26005)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EMYoELfYAnJS2wy6DO3W4o5OKSq6kJ6nX/B5kvZUBvJtqv1AH2RlnQGDIhIQClULqlStOEL60alPLbohTZbW5iH9i/82iIu5PETY3dXTn/7O2oPH/bGZ10Xagz9kMOUUmOZy85jXWmZcd04SrMM3sZuV1dC8wfQ08coVddDuvSI2iz+IPfKKdIiGBToLb1amxpGB7ume41Ip7XD9kJ9khNq12352LvDn21EVLPiedgtMlc4PhjkNhZatpD9s5MeNLrNPOHVXHF4sTd+ydnJYSegt2dr1x4Shqxx9jM0XnkuSWTQTAJyDhB8i4XSkBMYT9t/QLFgAiPgTEVjX9HzylXTxe+wrYiTZ0yigaLp50fyiSwb78PyIrC8x6CYR25BKaXD4HoHXEcvOtwoin0qHL7eKCMjRUn6wkxu2VJgISlV6jeAElKc7NFqvzS7EjZPHvmieAjJekzvHbvNsYfLq8l4YC3tS8FdKd0c6JKK5tPhGc/zDh4Rc+beT/kQNZGjGs8hlAIkfqT2w1OZn/wy+NFSQFt9730Ib7kTM+DGHnnXMDojE7f2x58tWePtceG5kft8oVM8ds/sytBR2w4f+b4aqAoQ7RYSN7U8uMTryq0tCwMTwI9dllWvZg17xk9X17wuKOwkAmTQqBp/Nw2n//A== Content-Type: text/plain; charset="utf-8" Content-ID: <5A2B7E9CDB9F5A4E81A260F351601FC5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4273.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 283634c5-0622-4476-4a0a-08d86670b934 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 01:16:00.1497 (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: Jyp7wYdf8oD82akj454+mUg0bAw1aSnRxtdE3FUfByvZlD6iyw3qgIknab2iuwaK X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4259 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-lisp-pubsub-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 01:16:40 -0000 VGhhbmtzIGEgbG90IGZvciB0aGUgcmV2aWV3IENocmlzLCB0aGlzIGlzIG11Y2ggYXBwcmVjaWF0 ZWQgZmVlZGJhY2suIFdlIHdpbGwgc3VibWl0IGEgbmV3IGl0ZXJhdGlvbiBvZiB0aGUgZG9jdW1l bnQgYWRkcmVzc2luZyB5b3VyIGNvbW1lbnRzLg0KDQpUaGFua3MgYWxzbyBKb2VsIGZvciBmYWNp bGl0YXRpbmcgdGhlIHJldmlldy4NCg0KQmVzdCwNCkFsYmVydG8NCg0K77u/T24gMTAvMS8yMCwg MTI6MDYgUE0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToN Cg0KICAgIFRoYW5rIHlvdSBDaHJpcy4gICBUaGF0IGlzIGhlbHBmdWwsIGFuZCBJIGFtIGNvbmZp ZGVudCB0aGUgYXV0aG9ycyB3aWxsIA0KICAgIGNsZWFuIHVwIHRoZSB0ZXJtaW5vbG9neS4NCg0K ICAgIFlvdXJzLA0KICAgIEpvZWwNCg0KICAgIE9uIDEwLzEvMjAyMCA4OjM0IEFNLCBDaHJpcyBM b252aWNrIHdyb3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+IEkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MgDQogICAg PiBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nl c3NlZCBieSB0aGUgSUVTRy4gDQogICAgPiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJp bWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgDQogICAgPiBhcmVhIGRpcmVj dG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSAN CiAgICA+IGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K ICAgID4gDQogICAgPiBUaGlzIGlzIGFuICJFYXJseSBSZXZpZXcgUmVxdWVzdCIgc28gSSdtIGdv aW5nIHRvIG1hcmsgdGhlIGRyYWZ0IGFzIA0KICAgID4gUkVBRFkgV0lUSCBOSVRTLg0KICAgID4g DQogICAgPiBJdCBhcHBlYXJzIHRoYXQgdGhlcmUncyBhIHJhZnQgb2YgZHJhZnRzIG9mIExJU1Ag ZG9jdW1lbnRzIHByb2dyZXNzaW5nIA0KICAgID4gdG9nZXRoZXIgdGhyb3VnaCB0aGUgV0cgdGhh dCBjcm9zcy1yZWZlcmVuY2UgZWFjaCBvdGhlciBpbiB0aGF0IHRoZXkgYWxsIA0KICAgID4gcHJv dmlkZSBmb3VuZGF0aW9uIGFuZCBzdXBwb3J0IGZvciB0aGVpciBjb2xsZWN0aXZlIGZlYXR1cmVz LiAoSSdsbCANCiAgICA+IGFkbWl0IHRoYXQgSSBoYXZlbid0IGJlZW4ga2VlcGluZyB1cC4pIFNv IGlmIG15IG5pdHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCANCiAgICA+IGluIGFub3RoZXIgZG9jdW1l bnQsIHRoYXQganVzdCBtZWFucyB0aGF0IEkgZGlkbid0IGRpZyBmYXIgb3IgZGVlcCANCiAgICA+ IGVub3VnaCBzbyBwbGVhc2UgY29uc2lkZXIgZ2l2aW5nIGEgcG9pbnRlciBpbiB0aGUgU2VjdXJp dHkgDQogICAgPiBDb25zaWRlcmF0aW9ucyBvZiB0aGlzIGRvY3VtZW50IHNvIG90aGVycyB3b24n dCBzaW1pbGFybHkgYmUgbGVmdCBhZHJpZnQuDQogICAgPiANCiAgICA+IEluIHRoaXMgZG9jdW1l bnQsIGFuZCB0aGUgYXNzb2NpYXRlZCBvdGhlcnMgdGhhdCBJIHBlZXJlZCBpbnRvLCB0aGUgdGVy bSANCiAgICA+ICJub25jZSIgc2VlbXMgdG8gYmUgdXNlZCBtb3JlIGFzIGEgInRva2VuIiB0aGFu LCB3ZWxsLCB3aGF0IEkgY29uc2lkZXIgDQogICAgPiB0byBiZSBhIG5vbmNlLiBJbiBvbmUgY2Fz ZSBpdCBtYXkgYmUgYSByYW5kb20gdmFsdWUsIGJ1dCBpbiBzZXZlcmFsIA0KICAgID4gb3RoZXJz IHRoZSB2YWx1ZSBpcyBzdG9yZWQsIGNvbXBhcmVkLCBhbmQgcmV1c2VkLiAgVGhpcyBpcyBpbmNv bnNpc3RlbnQgDQogICAgPiB3aXRoIHRoZSBJRVRGJ3MgU2VjdXJpdHkgR2xvc3NhcnkgUkZDIDQ5 NDkuDQogICAgPiANCiAgICA+IEFsc28sIHRoZXJlIGlzIGEgcmVmZXJlbmNlIHRvIGluY3JlYXNp bmcgdGhlIG5vbmNlIGZvciBhIHBhcnRpY3VsYXIgdXNlLiANCiAgICA+IEhvd2V2ZXIsIEkgc2F3 IG5vIGRpc2N1c3Npb24gb2Ygd2hhdCB0byBkbyB3aGVuIHRoZSB2YWx1ZSBleGNlZWRzIHRoZSAN CiAgICA+IGZpZWxkIHNwYWNlLg0KICAgID4gDQogICAgPiBPdGhlciB0aGFuIHRoYXQsIHRoZSBk b2N1bWVudCBhcHBlYXJzIHRvIGJlIHdlbGwgd3JpdHRlbiBhbmQgd2VsbCANCiAgICA+IHRob3Vn aHQgb3V0Lg0KICAgID4gDQogICAgPiBCZXN0IHJlZ2FyZHMsDQogICAgPiANCiAgICA+IENocmlz DQogICAgPiANCg0K From nobody Fri Oct 2 04:20:30 2020 Return-Path: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@amazonses.watsen.net> X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FFA3A15C3; Fri, 2 Oct 2020 04:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 MXZxjh-F5QE4; Fri, 2 Oct 2020 04:20:22 -0700 (PDT) Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DD23A15C1; Fri, 2 Oct 2020 04:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1601637618; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=112F6c+AZZkoAf53im10KaL8T+6upaTyW03lQVNDbbc=; b=ivStbwmgNGzf5ac4tYmm1PJa9a9HgKGc1/JAmyCncLhRHqmzrr67cIIUCyy9Q4bc 7iqk0luNra/Mm5CzjYJdyamHh1DJFOG7599nKggfUk69TKl4PoV7GSfHVuUESUfpZ3C SGgpBpbQk8P4ahsDkyPd5mxJCIdPifpp8qzaaf/Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <160107496501.14047.597283542214697710@ietfa.amsl.com> Date: Fri, 2 Oct 2020 11:20:18 +0000 Cc: secdir@ietf.org, "netconf@ietf.org" , draft-ietf-netconf-trust-anchors.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-ID: <01000174e90a9186-0a4edb66-4120-44b7-a79f-7b9935f6d48f-000000@email.amazonses.com> References: <160107496501.14047.597283542214697710@ietfa.amsl.com> To: Yoav Nir X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.10.02-54.240.48.94 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-netconf-trust-anchors-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 11:20:24 -0000 [-last-call] Hi Yoav, Thank you for your review! The takeaway for me is that some = clarifications are needed, but otherwise the draft is fundamentally = okay. I will post an update, or perhaps just a GitHub commit, for your = review, when I get a chance. That said, my getting a chance will be = delayed as I have a major engagement I need to focus on now. This email = is just to let you know that your review has not been forgotten. Thanks again, Kent > On Sep 25, 2020, at 7:02 PM, Yoav Nir via Datatracker = wrote: >=20 > Reviewer: Yoav Nir > Review result: Has Issues >=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 document defines a YANG model for managing a trust anchor store. = It allows > two kinds of trust anchors: certificates and raw public keys. However, > certificates are not just containers for public keys. Certificates = include > attributes about key usage, path constraints and name constraints, all = of which > constrain the ability to use the public key, and are relevant for = trust > anchors. As far as I can tell the document does not include any = attributes to > equivalently constrain the use of the raw public keys. If the = intention is > that raw public keys will not be constrained, the document should = state this > explicitly. >=20 > Perhaps this is clear to the people who worked on the document, but = it's not > clear to me. Are the trust anchors managed with this module supposed = to be > used to establish trust for the NETCONF or RESTCONF connections? = Section 1.1 > seems to suggest that it does, but then how is the bootstrap problem = solved? > How do we establish the NETCONF connection the first time, and if we = are able > to do that, why do we need more certificates? If the answer is no, = and the > certificates are to be used by other protocols, then perhaps some = re-wording in > section 1.1 would help to show this. Currently, it says: "This = document > presents ... YANG modules that are part of a collection of RFCs ... = define > configuration modules for clients and servers of both the NETCONF and = RESTCONF > protocols." >=20 > The security considerations section is OK, especially sub-section 4.2. > Sub-section 4.1 has the following: >=20 > The YANG module defined in this document defines a mechanism called = a > "truststore" that, by its name, suggests that it will protect its > contents from unauthorized modification. >=20 > Perhaps this is my different perspective, but the name doesn't lead me = to > expect that it protects its contents. I think that the document = should either > just suggest that some mechanism to prevent unauthorized modification = should be > used, or to present such a mechanism in detail. The current text = suggests is > partially specific by mentioning digital signatures and non-volatile = storage, > but not explaining where the trust for the digital signature comes = from and > what policies govern its us: >=20 > In order to satisfy the expectations of a "truststore", it is > RECOMMENDED that implementations ensure that the truststore contents > are signed when persisted to non-volatile memory, to prevent > unauthorized modifications from being made undetected. >=20 > It is too vague to be a specification, but still unnecessarily = constrains the > solution space. I think the correct thing to do is to be explicitly = vague and > to just suggest some mechanism for protecting the content. >=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Fri Oct 2 05:21:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908343A0FAE; Fri, 2 Oct 2020 05:20:57 -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, 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 (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 Rgg5HpXWxhyE; Fri, 2 Oct 2020 05:20:55 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 155A13A0FAC; Fri, 2 Oct 2020 05:20:54 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id g4so1604484wrs.5; Fri, 02 Oct 2020 05:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W56w8sN3drbmvIfht40n68CpymbCPdunfFuIJjlDaxU=; b=QEjuFLnFqt7rsnc7CpOx7srmkz6+cI815xls/E9nRH7UkvOE5Gq9pC7Bto4IKiXVfb kKSpgWqlVDS4tBDdybHHjARX25YJ7jtgGwyxAAa5NxAqRYZ+FtU1JeD/ma1UloP68gHG keyv/TdJnBg2fXZMJj9GgYAs+FXtK/VahSu+yO1ArspDpaNIHrczP0X/kZ2PO7C1W8sd /xqzELlsIY0lU2VcC2j55hrnsgCsbJkhHi3CCdZqSoXidsLOdOPynhD6V71ImadC7KBP 8Eu7V43KuRO1QIOB2KCTJbsumbVg3N+ke6lPOqccnLrlhTb7Kz41w/HlHp0WkLgdmvKj qqOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W56w8sN3drbmvIfht40n68CpymbCPdunfFuIJjlDaxU=; b=L/WGpNTsGHGX8Ix+znsD9+SuUpGsylTQBCI/GbpocmDB5o87Y7PZcRSxUg4Sa86VN4 YYcVj/eB4OPiKwLVqYGPG2aesG9iMZQwb54B+9paacI/4NzT+h7S0GneinrDr0NcQEBC kpWV5A+wfJ0+YCOpyQ5dbE2tLVRhDlN3EJSXzbEAeCUMqYCNcTb+MiVr09hG3b8e5Sv7 MTywwmVTT0j5n6HS5+lY2h3xfZ9uHbp1SUsuiiUCgWdipffuJWpBhZNusRRgTYGThSMH iy4EOYdKcrl2ZlKMPIaaCBAjEu/BKjeOu5my0BQJ09B7Vb1uj+WbKrxHKZanfVHhS2pv xZjg== X-Gm-Message-State: AOAM531LemYt92YL+Tdp2aSylAcbo73y2WsRH/bS7A6c7QHTBmfzCsAx D5FWLwYdgpQ55i67mkARkak= X-Google-Smtp-Source: ABdhPJwXDxK6vtljym8JkU1wbBOutia0m3YiHMnbt1XuiW0sTuk/ZM3N89RI0IuTYFY0rakkWxhsbg== X-Received: by 2002:a5d:5583:: with SMTP id i3mr2702953wrv.119.1601641253144; Fri, 02 Oct 2020 05:20:53 -0700 (PDT) Received: from broadband.bt.com ([2a00:23c5:3395:c901:a8cd:8305:e9ef:e109]) by smtp.gmail.com with ESMTPSA id w7sm1569824wmc.43.2020.10.02.05.20.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 05:20:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Stewart Bryant In-Reply-To: Date: Fri, 2 Oct 2020 13:20:51 +0100 Cc: Stewart Bryant , "Grossman, Ethan A." , "secdir@ietf.org" , "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <4587A7BB-F83B-4A2A-89CF-CE36F922E277@gmail.com> References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> To: "Black, David" X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 12:20:58 -0000 David The way that I look at it, TCP will deliver a given byte fed into its = transmission stream in its own good time, delaying that byte until all = previous bytes are delivered. It will also keep trying to deliver that = byte as long as there is connectivity between source and sink. That is a = contrast with DetNet which is looking for fast delivery with possibly = some mitigation for packet loss. In such circumstances TCP is a = liability to the service that wanted deterministic characteristics. I = cannot therefore think of any good reason to pay the price of DetNet to = deliver TCP. If you do want to use a transport protocol that is more = sophisticated than UDP, then SCTP-PR is probably a better choice. - Stewart > On 1 Oct 2020, at 20:35, Black, David wrote: >=20 > Playing devil's advocate for a moment ... >=20 >> I would be rather surprised if anyone tried to run a deterministic = application over >> TCP. >>=20 >> TCP would undo all the temporal determinism and or course it looks = after packet >> loss. >=20 > ... IF the DetNet service defines packet loss as a failure case, i.e., = something that can't happen unless something in the network has actually = failed and the preferred failure behavior is late delivery rather than = non-delivery of impacted data, THEN TCP may be useful/appropriate. = OTOH, use of TCP increases the DetNet attack surface, as (in contrast to = UDP), causing a drop or otherwise triggering retransmission becomes a = way to attack the DetNet service by increasing the amount of traffic = sent into limited reserved network capacity and also by delaying = delivery of received data to the deterministic application. >=20 > I've lost track of the original context, so I'm not able to suggest = specific text and where to add it or make changes. >=20 > Thanks, --David >=20 >> -----Original Message----- >> From: detnet On Behalf Of Stewart Bryant >> Sent: Thursday, October 1, 2020 11:12 AM >> To: Grossman, Ethan A. >> Cc: secdir@ietf.org; last-call@ietf.org; Stewart Bryant; = detnet@ietf.org; draft- >> ietf-detnet-mpls-over-udp-ip.all@ietf.org; Stephen Farrell >> Subject: Re: [Detnet] Secdir last call review of = draft-ietf-detnet-mpls-over-udp- >> ip-06 >>=20 >>=20 >> [EXTERNAL EMAIL] >>=20 >>=20 >>=20 >>> On 24 Sep 2020, at 21:28, Grossman, Ethan A. = wrote: >>>=20 >>> Thanks Stephen. FWIW it isn't too late to add some text to the = DetNet Security >> draft regarding DetNet over UDP, if someone can think up something = useful to >> say. I suppose one could simply mention UDP in the same breath as TCP = (implying >> that the same general security guidelines apply, if that's our = stance). >>> Any thoughts (from anyone)? >>=20 >> Ethan >>=20 >> I would be rather surprised if anyone tried to run a deterministic = application over >> TCP. >>=20 >> TCP would undo all the temporal determinism and or course it looks = after packet >> loss. >>=20 >> - Stewart >>=20 >>=20 >>=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet From nobody Fri Oct 2 07:41:56 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820073A107C; Fri, 2 Oct 2020 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 BbysO9DMrNrH; Fri, 2 Oct 2020 07:41:46 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2054.outbound.protection.outlook.com [40.107.21.54]) (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 483733A1080; Fri, 2 Oct 2020 07:41:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AfNk+rg3P/lyuwY14ILw7MmiiZVzQexKYR95r2EYygnZY3Z2W8xdBvlfg1xcKjauvgNJ52W+9BKCu1fRJOH3kqg0L+kw7aJ52GFrNARUuuN8SVDLJ4hMIVArGkFCf5g8nyGCShK96hk4TrgrAeDrlbItnsuQ1L2DMOEXr9y4ppp4lFSGG0goNf4tbooHh/S2lbj9PjY0Jh5hMXeyzqRH3TSe/jQ1xJSj9N2vYNHMnNHSdI/C7Ytp5lZU0Yht5ejruoM6dLvUGJHmu6pGXcz/kGKE6bPdhjOemkvfwceEta/a/EYx0Am8SDdMZtKjLashjq73lT1Ku7yHckfVJXBI6g== 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=aNIFFjos8Ww+Mx5CEENClK0atH+oEzmd4L1v8q8erog=; b=DFqxbK7uyjEwMj2UsSZtKxuuScbOv/9YtOi7lqk6jK3L2E773cvGG3anMtubqtOaDCO3QSQaOJq3lP9t+gm1MiBoJ0dZqKFARE5VBo6dLqIhmRV08sQOoM/gzrdegwcMr1yS6OJzAIaNpLVK6yjZidP1EEyUKU8NpLC5L5d1fOX+31A3Ndj+w+4VLQrbnSePUYRpPmsbejX7kgvbQLOfgyQFJXsUsi6a7LyzY8c7thL0JsSG7DX8F1eoQNp9jwm/SRivHG2aFIjRa2tifpBE2eQa+4vE3n6U1xAfgj+xN9JX2xoelkQra+fNTeaZpI9NaO9rgxD5drl55mybhhnXxA== 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=aNIFFjos8Ww+Mx5CEENClK0atH+oEzmd4L1v8q8erog=; b=SKmKBZfu04+OdHGra73DYVa6P+2faqSQAS9yt65h8qXhI5c6T2ftN3akgkCrFCjbElODUEOOYO1feFBPw+ZPdOKhkbZclKFrEop4rVSNudA0Oj4SrOZqK6VReVQ+Qqzp4D+SDp32lWIfJNyqzjnoMEpoYGzAG9GhZV6tRRK24V0= Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM0PR07MB6339.eurprd07.prod.outlook.com (2603:10a6:20b:15f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.13; Fri, 2 Oct 2020 14:41:44 +0000 Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::59ca:540d:b7f3:58b9%6]) with mapi id 15.20.3455.013; Fri, 2 Oct 2020 14:41:43 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: Shawn Emery , secdir CC: "last-call@ietf.org" , "draft-ietf-detnet-flow-information-model.all@ietf.org" , Shawn Emery Thread-Topic: Review of draft-ietf-detnet-flow-information-model-10 Thread-Index: AQHWgwqeufaHlLUZg06rupGL9hskjKmEi8yA Date: Fri, 2 Oct 2020 14:41:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [94.21.192.99] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a8995da-8f65-44e5-57d6-08d866e1484e x-ms-traffictypediagnostic: AM0PR07MB6339: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U7nrBXQ+yt4Kawt9pG5EWtSGVGnYKjwTwDEYrrAnrKSac6pSLOJHlz3C3Cqbr9FfeI2aPFtL3iJPuJyElvbTjw/H0I91RDrCL7wzIbhZzKkT21WJUWRmvGjkmjNOKhkM7kV9FVKynryAGD7q/ZT+2TVRBmLFy5TcmTygZk7OlPX78SsGrCftSJ5pvW9hSLZjJ5T0R14PaAvp6KzIh7tS96YMwfMpV1eec1dpvoA555A6C87iZ6z4EQBVIn3OvrmoFRwaHP7pMjQ8Tu+ZNCSBphsmc5vdWNiiHWBbUarcutXTDbOFv/9IAFlVMPIDB2j9hfnCYgC0D1LKnP04mf2DkzGlD4mmiPsIOX6O+tfARZgqs0FxPC+Bgqt+K4gfHhGF0kMriQe0hIvz5HjJE95cWw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3603.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(64756008)(2906002)(66476007)(66556008)(85182001)(66446008)(66946007)(110136005)(33656002)(53546011)(86362001)(7696005)(76116006)(4326008)(6506007)(478600001)(316002)(54906003)(5660300002)(55016002)(52536014)(8676002)(9686003)(186003)(9326002)(8936002)(26005)(83380400001)(85202003)(83080400001)(166002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: stOqAk+VGp4xC5FK05sTgQ5YC3qRVRINUSZuwh6zWFbFAB1QUYtxBNucLo252/8o1KymLMMXHx9lpMLYZQJwJRQRiYpOviCKMD6GX02sOfXpklHnVxE9qHbg+HmlyMFq236i5RbSkQ3/dV2pzb6HQvk5sZXuzqrjdxQyNKP0/Cy04pTPqbjcV7Rnr9eTvQoTsP4NJoGokRpE1E8gzsugdQzSTDQG+P2qiIYSea462eQbGg7fcUzxEPK5z9Nk7PegHIGNZvMaOiR2kKnCuQt1GPxCVXttra/9HEFk+qonf/Ynrvr4KGciD5lnVp7a1v1eXNLuDrj5Ob/bBNUn8Yy8HE4YcmvblsYt2MEW3pElI16g3wnzHOjnJrKcUSTZamqVJCm9QkyVPmKvqdaqd+vrRZTuT5NQ5FFXOpfmnSmGsA2YSn/G5PVHcZmavgLokmNNBlWi7cx3tjN6zWPzx1VildKiysWI3WQN4rw58lPg+RnTc9ou7lOiWvseeBGo/GRoaVa2+4XMuqLXBfVkXrHX1nW9u/6rBQnEwI/SeFfw+MW5lHffYcRzt/J+3T8xnZdFJrIdaS4AJyHBEGSg1mokiFoOSOV50PdaxF6H/PlkTptqG3DjAXi+mqh++SxnllA6QidRRceaL/dIFehhiIfOMQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB3603941A6D7ACE625D703088AC310AM0PR0702MB3603_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3603.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a8995da-8f65-44e5-57d6-08d866e1484e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 14:41:43.8104 (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: 26lPCkcUSRYjozKpG3EIQ85IzbMTSKHTQC/NVEGDkmcClgg9isYu1t8FBYZzjfDEUylCvaTB4dHenhqqphjWuY9/izlE2GZ+VDSugPy8R1g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6339 Archived-At: Subject: Re: [secdir] Review of draft-ietf-detnet-flow-information-model-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 14:41:49 -0000 --_000_AM0PR0702MB3603941A6D7ACE625D703088AC310AM0PR0702MB3603_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2hhd24sDQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4gRHJhZnQtaWV0Zi1kZXRu ZXQtZmxvdy1pbmZvcm1hdGlvbi1tb2RlbCBpcyBhbg0KaW5mb3JtYXRpb25hbCBkcmFmdCBhbmQg ZGVzY3JpYmVzIG9ubHkgdGhlIGZsb3cgYW5kIHNlcnZpY2UgaW5mb3JtYXRpb24gbW9kZWwNCmZv ciBEZXROZXQuIFRoZSBXRyBpcyB3b3JraW5nIG9uIHRoZSBZQU5HIG1vZGVsIHdoaWNoIHdpbGwg Y2FsbCBvdXQgdGhlIHNlY3VyaXR5DQppbXBsaWNhdGlvbnMgb2YgYXR0cmlidXRlcywgcGVyIFlB TkcgbW9kZWwgZ3VpZGVsaW5lcy4NCihodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRldG5ldC15YW5nLykNCg0KVGhhbmtzIGZvciB0aGUgZWRpdG9yaWFsIGNvbW1l bnRzLCBJIHdpbGwgZml4IHRoZW0uDQoNClRoYW5rcyAmIENoZWVycw0KQmFsYeKAmXpzDQoNCg0K RnJvbTogU2hhd24gRW1lcnkgPHNoYXduLmVtZXJ5QGdtYWlsLmNvbT4NClNlbnQ6IFNhdHVyZGF5 LCBTZXB0ZW1iZXIgNSwgMjAyMCAxMjoyNyBBTQ0KVG86IHNlY2RpciA8c2VjZGlyQGlldGYub3Jn Pg0KQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kZXRuZXQtZmxvdy1pbmZvcm1h dGlvbi1tb2RlbC5hbGxAaWV0Zi5vcmc7IFNoYXduIEVtZXJ5IDxzZW1lcnlAdWNjcy5lZHU+DQpT dWJqZWN0OiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1kZXRuZXQtZmxvdy1pbmZvcm1hdGlvbi1tb2Rl bC0xMA0KDQpSZXZpZXdlcjogU2hhd24gTS4gRW1lcnkNClJldmlldyByZXN1bHQ6IFJlYWR5IHdp dGggbml0cw0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NClRoZXNlIGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eQ0KYXJl YSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg dGhlc2UNCmNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K DQpUaGlzIGluZm9ybWF0aW9uYWwgZHJhZnQgc3BlY2lmaWVzIGFuIGluZm9ybWF0aW9uIG1vZGVs IGZvciBEZXRlcm1pbmlzdGljIE5ldHdvcmtpbmcNCihEZXROZXQpLCBzcGVjaWZpY2FsbHkgZm9y IGRhdGEgYXQgdGhlIElQL01QTFMgbGF5ZXIuDQoNClRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uIGRvZXMgZXhpc3QgYW5kIHJlY29tbWVuZHMgY29uZmlkZW50aWFsaXR5DQpmb3Ig RGV0TmV0J3MgZXh0ZXJuYWwgaW50ZXJmYWNlcyBhbmQgdGhhdCB0aGUga25vd2xlZGdlIG9mIGZs b3dzIGFuZCBzZXJ2aWNlcw0KYXNzb2NpYXRlZCB3aXRoIGN1c3RvbWVycyBhbmQgbmV0d29yayBv cGVyYXRvcnMgY291bGQgYmUgdXNlZCBieSBhbiBhZHZlcnNhcnkNCnRvIGxhdW5jaCBhdHRhY2tz IGFnYWluc3QgdGhlc2UgbmV0d29ya3MuICBUaGUgc2VjdGlvbiBkZWZlcnMgbWl0aWdhdGlvbiBv ZiBzYWlkIGF0dGFja3MNCnRvIHRoZSBpZXRmLWRldG5ldC1zZWN1cml0eSBkcmFmdCBhbmQgZGVm ZXJzIHRvIFJGQyA4NjU1IGZvciBEZXROZXQncyBvdmVyYWxsIHNlY3VyaXR5DQpjb25zaWRlcmF0 aW9ucy4gIFRoZXNlIGRvY3VtZW50cyBwcm92aWRlIHNvbWUgY292ZXJhZ2UgaW4gcmVnYXJkcyB0 byB0aGUgZGF0YSBtb2RlbA0KcHJlc2VudGVkIGluIHRoaXMgZHJhZnQsIGJ1dCB1bmZvcnR1bmF0 ZWx5IGRvZXMgbm90IGRlc2NyaWJlIGhvdyBkcmFmdCBzcGVjaWZpYyBhdHRyaWJ1dGVzLCBlLmcu DQpEblNlcnZpY2VSYW5rIGNvdWxkIGJlIHVzZWQgYXMgYSBEb1MgYXR0YWNrLiAgSGF2aW5nIHNh aWQgdGhpcywgd2hlbiB0aGUgZGF0YSBtb2RlbCBkb2VzDQpiZWNvbWUgYSBZQU5HIG1vZGVsIHRo ZW4gRGV0TmV0IHdpbGwgbmVlZCB0byBleHBsaWNpdGx5IGNhbGwgb3V0IGVhY2ggb2YgdGhlc2Ug YXR0cmlidXRlcyB0aGF0DQpoYXZlIHNlY3VyaXR5IGltcGxpY2F0aW9ucywgcGVyIFlBTkcgbW9k ZWwgZ3VpZGVsaW5lcy4NCg0KR2VuZXJhbCBjb21tZW50czoNCg0KSGF2aW5nIHRoZSBkcmFmdC1p ZXRmLWRldG5ldC1zZWN1cml0eSBkcmFmdCBpcyBhIHJlYWxseSBnb29kIGlkZWEgdG8gaGVscCBh dWdtZW50IHRoaXMNCmFuZCBvdGhlciBEZXROZXQgZHJhZnRzLiAgSGF2aW5nIGEgY29tcHJlaGVu c2l2ZSBzZXQgb2YgdGhyZWF0cyBhbmQgaG93IHRvIG1pdGlnYXRlDQphZ2FpbnN0IHRoZW0gcHJv dmlkZXMgYSBnb29kIGZvdW5kYXRpb24gZm9yIG90aGVyIGF1dGhvcnMgdG8gdGhpbmsgYWJvdXQu DQoNCkVkaXRvcmlhbCBjb21tZW50czoNCg0Kcy9jYW4gZGlzdGluZ3Vpc2hlZC9jYW4gYmUgZGlz dGluZ3Vpc2hlZC8NCnMvZmxvdyB1c2luZywvZmxvdywgdXNpbmcvDQpzL3Jlc3VsdCBkYXRhL3Jl c3VsdCBpbiBkYXRhLw0KDQpTaGF3bi4NCi0tDQo= --_000_AM0PR0702MB3603941A6D7ACE625D703088AC310AM0PR0702MB3603_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpSb2JvdG87fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIFNoYXduLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYW55IHRoYW5r cyBmb3IgeW91ciByZXZpZXcuIERyYWZ0LWlldGYtZGV0bmV0LWZsb3ctaW5mb3JtYXRpb24tbW9k ZWwgaXMgYW4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5mb3JtYXRp b25hbCBkcmFmdCBhbmQgZGVzY3JpYmVzIG9ubHkgdGhlIGZsb3cgYW5kIHNlcnZpY2UgaW5mb3Jt YXRpb24gbW9kZWwNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIERl dE5ldC4gVGhlIFdHIGlzIHdvcmtpbmcgb24gdGhlIFlBTkcgbW9kZWwgd2hpY2ggd2lsbCBjYWxs IG91dCB0aGUgc2VjdXJpdHkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aW1wbGljYXRpb25zIG9mIGF0dHJpYnV0ZXMsIHBlciBZQU5HIG1vZGVsIGd1aWRlbGluZXMuIDxv OnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQteWFuZy8iPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGV0bmV0LXlhbmcvPC9hPik8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgZWRpdG9yaWFsIGNvbW1lbnRzLCBJ IHdpbGwgZml4IHRoZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyAmYW1wOyBDaGVl cnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhbGHigJl6czxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBTaGF3biBFbWVyeSAmbHQ7c2hhd24uZW1lcnlAZ21haWwuY29tJmd0 OyA8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIFNlcHRlbWJlciA1LCAyMDIwIDEyOjI3IEFN PGJyPg0KPGI+VG86PC9iPiBzZWNkaXIgJmx0O3NlY2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5D Yzo8L2I+IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kZXRuZXQtZmxvdy1pbmZvcm1h dGlvbi1tb2RlbC5hbGxAaWV0Zi5vcmc7IFNoYXduIEVtZXJ5ICZsdDtzZW1lcnlAdWNjcy5lZHUm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJldmlldyBvZiBkcmFmdC1pZXRmLWRldG5ldC1mbG93 LWluZm9ybWF0aW9uLW1vZGVsLTEwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+UmV2aWV3ZXI6IFNoYXduIE0uIEVtZXJ5PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpSb2JvdG8iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQ7Zm9udC1zaXplOjAuODc1cmVtIiBp ZD0ibV80MTAzNTkxOTQ0NjgzNTk3NTltXzQyMDQyMTMwNDA3MTkxNDQwOTFnbWFpbC1tXzQ1ODky MDM3MjA0MDc2Njg3MDBnbWFpbC06ODhtIj4NCjxkaXYgaWQ9Im1fNDEwMzU5MTk0NDY4MzU5NzU5 bV80MjA0MjEzMDQwNzE5MTQ0MDkxZ21haWwtbV80NTg5MjAzNzIwNDA3NjY4NzAwZ21haWwtOjg4 biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UmV2aWV3IHJl c3VsdDogUmVhZHkgd2l0aCBuaXRzPGJyPg0KPGJyPg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUnczxicj4NCm9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLjxicj4NClRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eTxicj4NCmFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBl ZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlPGJyPg0KY29tbWVudHMganVz dCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KVGhpcyBpbmZv cm1hdGlvbmFsIGRyYWZ0IHNwZWNpZmllcyBhbiBpbmZvcm1hdGlvbiBtb2RlbCBmb3IgRGV0ZXJt aW5pc3RpYyBOZXR3b3JraW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+KERldE5ldCksIHNwZWNpZmljYWxs eSBmb3IgZGF0YSBhdCB0aGUgSVAvTVBMUyBsYXllci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV80MTAzNTkx OTQ0NjgzNTk3NTltXzQyMDQyMTMwNDA3MTkxNDQwOTFnbWFpbC1tXzQ1ODkyMDM3MjA0MDc2Njg3 MDBnbWFpbC06ODhuIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGRvZXMg ZXhpc3QgYW5kIHJlY29tbWVuZHMgY29uZmlkZW50aWFsaXR5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Zm9y IERldE5ldCdzIGV4dGVybmFsIGludGVyZmFjZXMgYW5kIHRoYXQgdGhlIGtub3dsZWRnZSBvZiBm bG93cyBhbmQgc2VydmljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5hc3NvY2lhdGVkIHdpdGggY3VzdG9t ZXJzIGFuZCBuZXR3b3JrIG9wZXJhdG9ycyBjb3VsZCBiZSB1c2VkIGJ5IGFuIGFkdmVyc2FyeTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPnRvIGxhdW5jaCBhdHRhY2tzIGFnYWluc3QgdGhlc2UgbmV0d29ya3Mu Jm5ic3A7IFRoZSBzZWN0aW9uIGRlZmVycyBtaXRpZ2F0aW9uIG9mIHNhaWQgYXR0YWNrczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPnRvIHRoZSBpZXRmLWRldG5ldC1zZWN1cml0eSBkcmFmdCBhbmQgZGVmZXJz IHRvIFJGQyA4NjU1IGZvciBEZXROZXQncyBvdmVyYWxsIHNlY3VyaXR5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+Y29uc2lkZXJhdGlvbnMuJm5ic3A7IFRoZXNlIGRvY3VtZW50cyBwcm92aWRlIHNvbWUgY292 ZXJhZ2UgaW4gcmVnYXJkcyB0byB0aGUgZGF0YSBtb2RlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnByZXNl bnRlZCBpbiB0aGlzIGRyYWZ0LCBidXQgdW5mb3J0dW5hdGVseSBkb2VzIG5vdCBkZXNjcmliZSBo b3cgZHJhZnQgc3BlY2lmaWMgYXR0cmlidXRlcywgZS5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRuU2Vy dmljZVJhbmsgY291bGQgYmUgdXNlZCBhcyBhIERvUyBhdHRhY2suJm5ic3A7IEhhdmluZyBzYWlk IHRoaXMsIHdoZW4gdGhlIGRhdGEgbW9kZWwgZG9lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmJlY29tZSBh IFlBTkcgbW9kZWwgdGhlbiBEZXROZXQgd2lsbCBuZWVkIHRvIGV4cGxpY2l0bHkgY2FsbCBvdXQg ZWFjaCBvZiB0aGVzZSBhdHRyaWJ1dGVzIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5oYXZlIHNlY3Vy aXR5IGltcGxpY2F0aW9ucywgcGVyIFlBTkcgbW9kZWwgZ3VpZGVsaW5lcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5HZW5lcmFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IYXZpbmcgdGhlIGRyYWZ0LWll dGYtZGV0bmV0LXNlY3VyaXR5IGRyYWZ0IGlzIGEgcmVhbGx5IGdvb2QgaWRlYSB0byBoZWxwIGF1 Z21lbnQgdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmFuZCBvdGhlciBEZXROZXQgZHJhZnRzLiZuYnNw OyBIYXZpbmcgYSBjb21wcmVoZW5zaXZlIHNldCBvZiB0aHJlYXRzIGFuZCBob3cgdG8gbWl0aWdh dGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5hZ2FpbnN0IHRoZW0gcHJvdmlkZXMgYSBnb29kIGZvdW5kYXRp b24gZm9yIG90aGVyIGF1dGhvcnMgdG8gdGhpbmsgYWJvdXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+RWRpdG9yaWFsIGNvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnMvY2FuIGRpc3Rpbmd1aXNoZWQvY2FuIGJlIGRpc3Rp bmd1aXNoZWQvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+cy9mbG93IHVzaW5nLC9mbG93LCB1c2luZy88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5zL3Jlc3VsdCBkYXRhL3Jlc3VsdCBpbiBkYXRhLzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNoYXduLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR0702MB3603941A6D7ACE625D703088AC310AM0PR0702MB3603_-- From nobody Fri Oct 2 08:40:50 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49A13A165E; Fri, 2 Oct 2020 08:40:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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 (2048-bit key) header.d=dell.com header.b=VKWw6SSX; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=i0weTgT6 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 Fshs-FI4iwCe; Fri, 2 Oct 2020 08:40:40 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 DEF2F3A165D; Fri, 2 Oct 2020 08:40:39 -0700 (PDT) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 092FMv0g006431; Fri, 2 Oct 2020 11:40:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=pkJAj1lM5we2Ngw4ng6gvosTADuAwu/tRCCP8Y9OCGs=; b=VKWw6SSXrHXX/XmTP/Bu6zDssDk8xUFM14NKtQ5ZC0qGfysgIsHHX9xjcbdwMX/3Yj4l mAoMX1Db0oMAmwuJUlILqynW8qvhSr+CvWKQVc2IDFrR74CWEHIKtmgC1OwejIXWFBEJ 5aMiUD5ZI99vmtdhg+jBtXaKMI0CkVIr52waW+9qeo/s6WBxG7wub8HlgmqNUYTMahM0 RPbhb7azn5HuNP+sYf4r3oD6XrAZnF2x+idM42pizTBeElckeY2rxz1KUpnFKQgl4q2h PS+7BOKciRboVH/50u0LtpxT343BbPCGpAuPxKa25yyp7dqMNdx1ggsPDTHORUsLflLy RQ== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 33t1fyx6v1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Oct 2020 11:40:34 -0400 Received: from pps.filterd (m0142699.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 092FL8tB177606; Fri, 2 Oct 2020 11:40:33 -0400 Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2177.outbound.protection.outlook.com [104.47.59.177]) by mx0a-00154901.pphosted.com with ESMTP id 33x4catuh2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Oct 2020 11:40:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e6TQKqlCrJi24tbspWR2yDpLsupDAZ00oZHn+KP8tbV+xh9WljfTi/82/ZMgSqntBttLg6dV/YYNUghyaOtH40C1UWzLXokOQeeuVwOMbMkcaQqbHsCnDSKcQo3MXp0xwDT5fJPG//hOKMYRD68oKbnU1efM9fVX08G+mRUhJxKLZxzgQkmuZBnIOReTjUd6zDHunmSgBiMqyWcRpwLGm2vDcnI0r00F4+x8MZ7mX+zbuaj+xRqe2H1fQOuBLUzLEtQNUdYLr9vZ2jUNtSw5XUfzo3UOoCqN2UIfcYvMccqiu5XmVrEARG9u0xBpSEbY+bH2j5kyoHnxRp4BcRbFeQ== 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=pkJAj1lM5we2Ngw4ng6gvosTADuAwu/tRCCP8Y9OCGs=; b=AQewL/xBFWRSZWampWAv3IXISwgYimS4bQ3v4nAP6zqZu6fr5OUbG+seAQebRxi/x+4GvSimT/IE7QVC/TWco7rkJMWX2Z2JiUk3PN3G+R2GBEBr7o4fiBmXIzwY1po/2gkufeHh4RxBhHAXV18MI2WcODCxRP9ARfca0tX2QQeYWWoBgsR+pvW9GGgnrj+lKk1KZ70mEe5i8GKIYa9060bDeKfZJkQ5AwA9IxmmieLqTrbw2dkHS25UfDEy1g8YZzUFvaKKEkFfQSwwegrW00Fn6nd1ushgl/YY45+mMoPXiYKhXxsyh/kPQwnt2zJkM4YwsEscMjYPxTMEkyEfOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pkJAj1lM5we2Ngw4ng6gvosTADuAwu/tRCCP8Y9OCGs=; b=i0weTgT6l+W5d2VMB6owZN3d6cX0txTlCX3RQIvWFlYck7GWTv/qvEt+gnyaVgKzaMjzOICLGHECwst2cTYAJk8OyasfopIxeTQXiE78THwkptWvcHoKH6+25cUprASRedm1HXX0nL1qX0Pkpyrln8JQEK+qbnERepk04EaHKQI= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3933.namprd19.prod.outlook.com (2603:10b6:208:1e0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Fri, 2 Oct 2020 15:40:31 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b423:5f36:f591:2fcd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b423:5f36:f591:2fcd%6]) with mapi id 15.20.3433.039; Fri, 2 Oct 2020 15:40:31 +0000 From: "Black, David" To: Stewart Bryant CC: "Grossman, Ethan A." , "secdir@ietf.org" , "last-call@ietf.org" , "detnet@ietf.org" , "draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org" , Stephen Farrell , "Black, David" Thread-Topic: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 Thread-Index: AQHWmAVHkKliTan2Cky0cNPan4qVfamDISEwgAEbw4CAADamsA== Date: Fri, 2 Oct 2020 15:40:31 +0000 Message-ID: References: <160097130665.26261.15986068503995393539@ietfa.amsl.com> <3D90BF69-C0F5-4538-B029-D6D189463100@gmail.com> <4587A7BB-F83B-4A2A-89CF-CE36F922E277@gmail.com> In-Reply-To: <4587A7BB-F83B-4A2A-89CF-CE36F922E277@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-10-02T15:38:59.0401286Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=55017ebd-cb9f-416b-9016-e8a8e9ccdda0; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=dell.com; x-originating-ip: [72.74.71.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdde8a86-8293-402c-903f-08d866e97eef x-ms-traffictypediagnostic: MN2PR19MB3933: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1zh8+B5AKlWNN/vszhoU3YZ/pLj2cZ8kE5RRO8/5joLLeFZtr8iUPriMGWZ9T2+WkrTQu8LsPsiTViPG3dB1A4HFFrUTR069Ml7kh3ZfGk7Tvd8qmPY0DOWByxpG2sEXsWIdL7wi+/cMyoHh+JLcqNJJ24CUxcWIFe+5XY5IUepIFD2gZd95fHcGdMGH82jgMX3qpiWKwydeqbbOFC/F3LwHkw6hOYGeiZD6nBsrgDVoqRunMEbEN/PuH+shDsX4nRU79xE8Yjyay5rfXVrdpEqbjYUCCbEnbFP4cVBPthZL+jH1URq2O6sSZnT7vTfli3IcpqWqHqYUhpU1XWXgAl2dSvQTKQ5QH8IDlPf2MT5AUHLsmq96K/R4DbW6IO5GofyHoPJJbct3wDz8NjyFfQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(39860400002)(366004)(136003)(8676002)(4326008)(107886003)(186003)(55016002)(9686003)(83080400001)(26005)(83380400001)(33656002)(6916009)(8936002)(966005)(71200400001)(52536014)(66556008)(2906002)(66946007)(66476007)(64756008)(66446008)(478600001)(86362001)(5660300002)(53546011)(6506007)(316002)(76116006)(786003)(7696005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lqEqWMT0Dw6u6kiIgpLqz3f6VWBp9rVX+Nktcbo4UENlGg824Vsavned6HH03aXcPwc/5Ld7WAn+DWuZYbg12QCIHhHSchlVXjJdtWa/mJePrMi59MrD2ySTTJ3WrhVKi8IzDFkPIBIWoVvShaTbdGOANGwC4+Q5p0CK+5/RDT4Dp03kDuw6DMZpN8/qgnvZq5Rv+FIeGZ4+zacV2GJYGz3yltOY+fkhfsq5lEy84L36Es2RaKZ9sBsMhDtTT35C3QrTN+kSTzwXsnH4BZwi+btvrUU+t8bUW96TT5otDLgBi+ZlzuvZVKT3wP301nDSMnBxJCJ2ExzRBuV5mlfOgrH4eTUZX7jEUls+B0RssuH8C+XLOuvTD8B/bVXt0tY9m11ZX906IiK5U7z7qp0LxUY/3T0WH1awRxu1Dq2z2v3hCPuUvixm+rg+LJygNQwusdtP0tzUgZNp3doNNvNWE/+CnorKTEV2Qk/ypjDuSF/h2BQL1eLWukJSDn2tT7f+MW68zJtLSAECE7DSYau8Dp+79ONWt7K6yvJok4+0Yi2UlYhnNQJktpgWWfUx6T9Pm9+myZBVzNiq9lXwduLKWxgF7FoD5fGhigwI4jPmJzt82k1+4PNG/9fXjgVVkagL1QcOLzLi+vdeTx3/5ISaOQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdde8a86-8293-402c-903f-08d866e97eef X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2020 15:40:31.4822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ah5vzPFv32VsCCsyXmo3lnJVPzxOTw/nHqiJEoARFixOgGRPtH4JQ0FVVaD1f1ZH1+kCmFf03v55e1hyUoG5SA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3933 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-10-02_10:2020-10-02, 2020-10-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 impostorscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 bulkscore=0 mlxscore=0 adultscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010020120 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 malwarescore=0 phishscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010020120 Archived-At: Subject: Re: [secdir] [Detnet] Secdir last call review of draft-ietf-detnet-mpls-over-udp-ip-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 15:40:42 -0000 Stewart, Going back to my earlier note to identify the design choice: > > ... IF the DetNet service defines packet loss as a failure case, i.e., = something > > that can't happen unless something in the network has actually failed a= nd the > > preferred failure behavior is late delivery rather than non-delivery of= impacted > > data, THEN TCP may be useful/appropriate. =20 I read your note as advocating that the preferred failure behavior is non-d= elivery of impacted data, in which case, I would agree that TCP is not a go= od choice of protocol. Thanks, --David > -----Original Message----- > From: Stewart Bryant > Sent: Friday, October 2, 2020 8:21 AM > To: Black, David > Cc: Stewart Bryant; Grossman, Ethan A.; secdir@ietf.org; last-call@ietf.o= rg; > detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-ip.all@ietf.org; Stephen > Farrell > Subject: Re: [Detnet] Secdir last call review of draft-ietf-detnet-mpls-o= ver-udp- > ip-06 >=20 >=20 > [EXTERNAL EMAIL] >=20 > David >=20 > The way that I look at it, TCP will deliver a given byte fed into its tra= nsmission > stream in its own good time, delaying that byte until all previous bytes = are > delivered. It will also keep trying to deliver that byte as long as there= is > connectivity between source and sink. That is a contrast with DetNet whic= h is > looking for fast delivery with possibly some mitigation for packet loss. = In such > circumstances TCP is a liability to the service that wanted deterministic > characteristics. I cannot therefore think of any good reason to pay the p= rice of > DetNet to deliver TCP. If you do want to use a transport protocol that is= more > sophisticated than UDP, then SCTP-PR is probably a better choice. >=20 > - Stewart >=20 >=20 >=20 > > On 1 Oct 2020, at 20:35, Black, David wrote: > > > > Playing devil's advocate for a moment ... > > > >> I would be rather surprised if anyone tried to run a deterministic > >> application over TCP. > >> > >> TCP would undo all the temporal determinism and or course it looks > >> after packet loss. > > > > ... IF the DetNet service defines packet loss as a failure case, i.e., = something > that can't happen unless something in the network has actually failed and= the > preferred failure behavior is late delivery rather than non-delivery of i= mpacted > data, THEN TCP may be useful/appropriate. OTOH, use of TCP increases the > DetNet attack surface, as (in contrast to UDP), causing a drop or otherwi= se > triggering retransmission becomes a way to attack the DetNet service by > increasing the amount of traffic sent into limited reserved network capac= ity and > also by delaying delivery of received data to the deterministic applicati= on. > > > > I've lost track of the original context, so I'm not able to suggest spe= cific text and > where to add it or make changes. > > > > Thanks, --David > > > >> -----Original Message----- > >> From: detnet On Behalf Of Stewart Bryant > >> Sent: Thursday, October 1, 2020 11:12 AM > >> To: Grossman, Ethan A. > >> Cc: secdir@ietf.org; last-call@ietf.org; Stewart Bryant; > >> detnet@ietf.org; draft- ietf-detnet-mpls-over-udp-ip.all@ietf.org; > >> Stephen Farrell > >> Subject: Re: [Detnet] Secdir last call review of > >> draft-ietf-detnet-mpls-over-udp- > >> ip-06 > >> > >> > >> [EXTERNAL EMAIL] > >> > >> > >> > >>> On 24 Sep 2020, at 21:28, Grossman, Ethan A. wrote= : > >>> > >>> Thanks Stephen. FWIW it isn't too late to add some text to the > >>> DetNet Security > >> draft regarding DetNet over UDP, if someone can think up something > >> useful to say. I suppose one could simply mention UDP in the same > >> breath as TCP (implying that the same general security guidelines appl= y, if > that's our stance). > >>> Any thoughts (from anyone)? > >> > >> Ethan > >> > >> I would be rather surprised if anyone tried to run a deterministic > >> application over TCP. > >> > >> TCP would undo all the temporal determinism and or course it looks > >> after packet loss. > >> > >> - Stewart > >> > >> > >> > >> _______________________________________________ > >> detnet mailing list > >> detnet@ietf.org > >> https://www.ietf.org/mailman/listinfo/detnet From nobody Sat Oct 3 16:20:04 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B984F3A0983; Sat, 3 Oct 2020 16:19:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: opsawg@ietf.org, last-call@ietf.org, draft-ietf-opsawg-model-automation-framework.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160176719670.27275.17469866976212039001@ietfa.amsl.com> Reply-To: Christian Huitema Date: Sat, 03 Oct 2020 16:19:56 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 23:19:57 -0000 Reviewer: Christian Huitema Review result: Has Issues The document proposes an architecture for describing and provisioning services such as L3VPN or L2VPN. This is an ambitious architecture, aiming at providing end-to-end services over concatenations of network services provided by independent providers. I am concerned that the model does not expose trust boundaries during these providers, and that the security section does not discuss what happens when some providers try to game the system or otherwise fail to cooperate. The architecture organizes functions in three levels, service, network and device. Creation of services will trigger requirements on the networks, and then configuration of devices. Performance monitoring at the device level will inform service assurance and service optimizatio at the network level, and service assurance, optimization and diagnostic at the service level. The configurations and the performance measurements are described using Yang models. The Yang modules are designed to be accessed through secrure protocols, such as NETCONF over SSH or RESTCONF over HTTPS. This provides authentication of the servers and protection of the data, and allows implementation of access control. That's a good basis, but these processes only secure "point to point" interfaces between functions in the system. This presupposes honest cooperation between all actors, despite the fact that those actors often are in competition. The security considerations consider misconfiguration attacks such as the creation of forwarding loops, leakage of sensitive information, and traffic isolation issues. These are all interesting issues, but they are only mentioned in the architecture document as guidelines for the future development of actual services. I think issues such as the protection of sensitive information should be developed in the model itself, because they are generic. The document articulates a hierarchy of Yang modules. Why does it not articulate the trust boundaries between the different actors? In addition to three classes of issues listed in the security considerations, I am also concerned with possibilities of retaining or falsifying data. What if an actor hides or fakes performance monitoring data, either out of malice or due to faulty equipement? Will that disrupt the provision of the services? What tools are available to detect such behavior? What if a network provide overpromises, in order to attract contracts? I understand that the ultimate remedies lies in contract obligations and contract enforcement, but that enforcement has to be based on data. How is the architectur organizing the collection of the data? On a side note, I find that this architecture cites a large number of other drafts such as evpn, l2vpn, l3vpn, etc. These drafts in turn presumably cite the architecture, thus forcing the RFC production to organize all of them in a large publication cluster. Is it really required for the architecture document to cite all the documents that will later use it? From nobody Sat Oct 3 18:44:26 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2B3A0E80; Thu, 1 Oct 2020 02:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1601542841; bh=r5f1kAB8DMi1dXqUjpxGPMoOTTNKRFEGYmbuqc4Zk4k=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Vs/kZdKFnEobQspMLago/5CFs4B04/ioygiSKh5PYoKkF2w/U7N7wD8BK/gXgEW91 lFnNqUqfpH8b4VylOZ5ycVpDRTtaqxR0ZiqIVg7UzTpW9H6aqe2BJrala58GSlKGMN 5xikZtAxMCT76pPjNP8434In73bGn0olAmCwOkko= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Oct 1 02:00:40 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D203A0E73; Thu, 1 Oct 2020 02:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1601542840; bh=r5f1kAB8DMi1dXqUjpxGPMoOTTNKRFEGYmbuqc4Zk4k=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=EOTAnz13li0QoS7jJ9Q80vod8ePjLe/9OIox2K1Wr5yzn0McqJ1JrLYxifnrHE4C3 vlfh8QPePYQ0RXiQyVgGPtphWCJmA0M41xz5jJs/KGV1baZUPr2zTG9EyY7ESziGku xbqJT9us+BcvNg1E5zkhfNQNuBys7uISxx+qJyRE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899523A0E73 for ; Thu, 1 Oct 2020 02:00:37 -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 84q_F6mrlZFc for ; Thu, 1 Oct 2020 02:00:35 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 597A63A0E72 for ; Thu, 1 Oct 2020 02:00:35 -0700 (PDT) Received: from [93.30.120.228] (helo=[192.168.1.21]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNuS1-0007Pj-U1 for new-work@ietf.org; Thu, 01 Oct 2020 09:00:34 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Thu, 1 Oct 2020 11:00:33 +0200 To: new-work@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 03 Oct 2020 18:44:25 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Audiobooks Working Group (until 2020-10-30/31) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 09:00:43 -0000 Hello, Today W3C Advisory Committee Representatives received a proposal to review a draft charter for the Audiobooks Working Group: https://www.w3.org/2020/09/proposed-audiobooks-wg-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments on the proposed charter through 03:59 UTC/GMT on 2020-10-31 (23:59 Boston time on 2020-10-30). Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you have any questions or need further information, please contact Ivan Herman , Audiobooks WG Staff Contact. Thank you, Coralie Mercier, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Oct 5 01:02:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954993A0E3F; Mon, 5 Oct 2020 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 dDFqwN_hQ6Oi; Mon, 5 Oct 2020 01:02:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903DD3A0E10; Mon, 5 Oct 2020 01:02:15 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4C4Y3V0r7fz5wBH; Mon, 5 Oct 2020 10:02:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601884934; bh=8r2GI4/MGJ9PTxR6r0RWEew3mJsvylAEpPP3AigQ2/o=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sX5k9DRvjwCJ3GwUD44UXnbl7Z8u/fnG612fXstD3qinQODPULV15EsbHBuKV4jTZ jT5JKSjpbF8PRvupogAdv0K4DAXqkIht9eZM0LJqlhLNng66j8rGsHCMVQgXT1smR/ 2Z0vi31zP21GNvu+fi9prifnPv0mTSH/7Qw8I7L3QWn8TG/0mpwZhMBbNO8qaG0MOR RVhzUce740yrmClQHuoJHA+cwt66kLjOC7kYd+bKTpouybMTOtuspRp4X3LETqTR3i oIyeZtdPfFNXI/crq0PybdemUmkXCZFMq1GOpHRlOyPdBcYt1ycM4afKdpS1Awc6Iq 7xmiIC5GiBp+A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4C4Y3T6g64zyQY; Mon, 5 Oct 2020 10:02:13 +0200 (CEST) From: To: Christian Huitema , "secdir@ietf.org" CC: "opsawg@ietf.org" , "last-call@ietf.org" , "draft-ietf-opsawg-model-automation-framework.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 Thread-Index: AQHWmdu2f0CAI4IxOUWO20psGbaR5amIjiTA Date: Mon, 5 Oct 2020 08:02:13 +0000 Message-ID: <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160176719670.27275.17469866976212039001@ietfa.amsl.com> In-Reply-To: <160176719670.27275.17469866976212039001@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:02:22 -0000 SGkgQ2hyaXN0aWFuLCANCg0KVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiANCg0KUGxlYXNlIHNl ZSBpbmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZcKgOiBDaHJpc3RpYW4gSHVpdGVtYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3Jl cGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGRpbWFuY2hlIDQgb2N0b2JyZSAyMDIwIDAxOjIw DQo+IMOAwqA6IHNlY2RpckBpZXRmLm9yZw0KPiBDY8KgOiBvcHNhd2dAaWV0Zi5vcmc7IGxhc3Qt Y2FsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctbW9kZWwtDQo+IGF1dG9tYXRpb24tZnJh bWV3b3JrLmFsbEBpZXRmLm9yZw0KPiBPYmpldMKgOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLW9wc2F3Zy1tb2RlbC0NCj4gYXV0b21hdGlvbi1mcmFtZXdvcmstMDYNCj4g DQo+IFJldmlld2VyOiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiBSZXZpZXcgcmVzdWx0OiBIYXMgSXNz dWVzDQo+IA0KPiBUaGUgZG9jdW1lbnQgcHJvcG9zZXMgYW4gYXJjaGl0ZWN0dXJlIGZvciBkZXNj cmliaW5nIGFuZA0KPiBwcm92aXNpb25pbmcgc2VydmljZXMgc3VjaCBhcyBMM1ZQTiBvciBMMlZQ Ti4gVGhpcyBpcyBhbiBhbWJpdGlvdXMNCj4gYXJjaGl0ZWN0dXJlLCBhaW1pbmcgYXQgcHJvdmlk aW5nIGVuZC10by1lbmQgc2VydmljZXMgb3Zlcg0KPiBjb25jYXRlbmF0aW9ucyBvZiBuZXR3b3Jr IHNlcnZpY2VzIHByb3ZpZGVkIGJ5IGluZGVwZW5kZW50DQo+IHByb3ZpZGVycy4NCg0KW01lZF0g VGhlcmUgaXMgbm8gc3VjaCBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdCBidXQgd2UgY2FuIGFjY29t bW9kYXRlIHRoYXQgY2FzZS4gDQoNCiBJIGFtIGNvbmNlcm5lZCB0aGF0IHRoZSBtb2RlbCBkb2Vz IG5vdCBleHBvc2UgdHJ1c3QNCj4gYm91bmRhcmllcyBkdXJpbmcgdGhlc2UgcHJvdmlkZXJzLCBh bmQgdGhhdCB0aGUgc2VjdXJpdHkgc2VjdGlvbg0KPiBkb2VzIG5vdCBkaXNjdXNzIHdoYXQgaGFw cGVucyB3aGVuIHNvbWUgcHJvdmlkZXJzIHRyeSB0byBnYW1lIHRoZQ0KPiBzeXN0ZW0gb3Igb3Ro ZXJ3aXNlIGZhaWwgdG8gY29vcGVyYXRlLg0KDQpbTWVkXSBUaGUgdmFyaW91cyBibG9ja3MgZGlz Y3Vzc2VkIGluIHRoZSBkb2N1bWVudCBhcmUgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgKiogc2Ft ZSBwcm92aWRlciAqKi4gDQoNClRoYXQncyBzYWlkLCBpZiBhIHByb3ZpZGVyIHJlbGllcyB1cG9u IG90aGVyIHByb3ZpZGVycyB0byBkZWxpdmVyIGEgZ2l2ZW4gc2VydmljZSwgdGhlIG1vZGVsIHdp bGwgYXBwbHkgaW4gYSByZWN1cnNpdmUgbWFubmVyOiBUaGF0IGlzLCBhIG5ldHdvcmsgY2FuIGFj dCBhcyBhICJjdXN0b21lciIgYW5kIHJlcXVlc3Qgc2VydmljZXMgZnJvbSBvdGhlciBuZXR3b3Jr cy4gVGhlIHBlZXIgbmV0d29yayB3aWxsIHRoZW4gZm9sbG93IHRoZSB2YXJpb3VzIGxldmVscyBk ZXBpY3RlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIHRvIGRlbGl2ZXIgdGhlIHNlcnZpY2UuDQoNCkFu eSBmYWlsdXJlIG9mIGEgcGVlciBwcm92aWRlciB0byBkZWxpdmVyIGFuIGFncmVlZCBzZXJ2aWNl IGlzIGEgdmlvbGF0aW9uIG9mIHRoZSBzZXJ2aWNlIGxldmVsIGFncmVlbWVudC4gU3VjaCB2aW9s YXRpb24gaXMgZGV0ZWN0ZWQgYnkgbWVhbnMgb2YgdGhlIHNlcnZpY2UgZnVsZmlsbWVudC9hc3N1 cmFuY2UgYW5kIGFwcHJvcHJpYXRlIGNvdW50ZXItbWVhc3VyZXMgd2lsbCBiZSBmb2xsb3dlZC4g VGhlc2UgY291bnRlci1tZWFzdXJlcyBtYXkgYmUgdGVjaG5pY2FsIChzd2l0Y2ggdG8gYW5vdGhl ciBwcm92aWRlcikgYW5kL29yIGNvbnRyYWN0dWFsIChwZW5hbHRpZXMpLiANCg0KV2UgY2FuIGFk ZCB0aGUgZm9sbG93aW5nOiANCg0KICAgQSBwcm92aWRlciBtYXkgcmVseSB1cG9uIHNlcnZpY2Vz IG9mZmVyZWQgYnkgb3RoZXIgcHJvdmlkZXJzLg0KICAgQXBwcm9wcmlhdGUgbWVjaGFuaXNtcyBz aG91bGQgYmUgZW5hYmxlZCBieSB0aGUgcHJvdmlkZXIgdG8gbW9uaXRvcg0KICAgYW5kIGRldGVj dCBhIHNlcnZpY2UgZGlzcnVwdGlvbiBmcm9tIHRoZXNlIHByb3ZpZGVycy4gIFRoZQ0KICAgY2hh cmFjdGVyaXphdGlvbiBvZiBhIHNlcnZpY2UgZGlzcnVwdGlvbiAoaW5jbHVkaW5nLCBtZWFuIHRp bWUNCiAgIGJldHdlZW4gZmFpbHVyZXMsIG1lYW4gdGltZSB0byByZXBhaXIpLCB0aGUgZXNjYWxh dGlvbiBwcm9jZWR1cmUsIGFuZA0KICAgcGVuYWx0aWVzIGFyZSB1c3VhbGx5IGRvY3VtZW50ZWQg aW4gY29udHJhY3R1YWwgYWdyZWVtZW50cy4NCiAgIE1pc2JlaGF2aW5nIHBlZXIgcHJvdmlkZXJz IHdpbGwgdGh1cyBiZSBpZGVudGlmaWVkIGFuZCBhcHByb3ByaWF0ZQ0KICAgY291bnRlcm1lYXN1 cmVzIHdpbGwgYmUgYXBwbGllZC4NCg0KPiANCj4gVGhlIGFyY2hpdGVjdHVyZSBvcmdhbml6ZXMg ZnVuY3Rpb25zIGluIHRocmVlIGxldmVscywgc2VydmljZSwNCj4gbmV0d29yayBhbmQgZGV2aWNl LiBDcmVhdGlvbiBvZiBzZXJ2aWNlcyB3aWxsIHRyaWdnZXIgcmVxdWlyZW1lbnRzDQo+IG9uIHRo ZSBuZXR3b3JrcywgYW5kIHRoZW4gY29uZmlndXJhdGlvbiBvZiBkZXZpY2VzLiBQZXJmb3JtYW5j ZQ0KPiBtb25pdG9yaW5nIGF0IHRoZSBkZXZpY2UgbGV2ZWwgd2lsbCBpbmZvcm0gc2VydmljZSBh c3N1cmFuY2UgYW5kDQo+IHNlcnZpY2Ugb3B0aW1pemF0aW8gYXQgdGhlIG5ldHdvcmsgbGV2ZWws IGFuZCBzZXJ2aWNlIGFzc3VyYW5jZSwNCj4gb3B0aW1pemF0aW9uIGFuZCBkaWFnbm9zdGljIGF0 IHRoZSBzZXJ2aWNlIGxldmVsLiBUaGUgY29uZmlndXJhdGlvbnMNCj4gYW5kIHRoZSBwZXJmb3Jt YW5jZSBtZWFzdXJlbWVudHMgYXJlIGRlc2NyaWJlZCB1c2luZyBZYW5nIG1vZGVscy4NCj4gDQo+ IFRoZSBZYW5nIG1vZHVsZXMgYXJlIGRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHRocm91Z2ggc2Vj cnVyZQ0KPiBwcm90b2NvbHMsIHN1Y2ggYXMgTkVUQ09ORiBvdmVyIFNTSCBvciBSRVNUQ09ORiBv dmVyIEhUVFBTLiBUaGlzDQo+IHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzZXJ2ZXJz IGFuZCBwcm90ZWN0aW9uIG9mIHRoZSBkYXRhLA0KPiBhbmQgYWxsb3dzIGltcGxlbWVudGF0aW9u IG9mIGFjY2VzcyBjb250cm9sLiBUaGF0J3MgYSBnb29kIGJhc2lzLA0KPiBidXQgdGhlc2UgcHJv Y2Vzc2VzIG9ubHkgc2VjdXJlICJwb2ludCB0byBwb2ludCINCj4gaW50ZXJmYWNlcyBiZXR3ZWVu IGZ1bmN0aW9ucyBpbiB0aGUgc3lzdGVtLiBUaGlzIHByZXN1cHBvc2VzIGhvbmVzdA0KPiBjb29w ZXJhdGlvbiBiZXR3ZWVuIGFsbCBhY3RvcnMsIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB0aG9zZSBh Y3RvcnMNCj4gb2Z0ZW4gYXJlIGluIGNvbXBldGl0aW9uLg0KPiANCj4gVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGNvbnNpZGVyIG1pc2NvbmZpZ3VyYXRpb24gYXR0YWNrcyBzdWNoDQo+IGFz IHRoZSBjcmVhdGlvbiBvZiBmb3J3YXJkaW5nIGxvb3BzLCBsZWFrYWdlIG9mIHNlbnNpdGl2ZQ0K PiBpbmZvcm1hdGlvbiwgYW5kIHRyYWZmaWMgaXNvbGF0aW9uIGlzc3Vlcy4gVGhlc2UgYXJlIGFs bCBpbnRlcmVzdGluZw0KPiBpc3N1ZXMsIGJ1dCB0aGV5IGFyZSBvbmx5IG1lbnRpb25lZCBpbiB0 aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFzDQo+IGd1aWRlbGluZXMgZm9yIHRoZSBmdXR1cmUg ZGV2ZWxvcG1lbnQgb2YgYWN0dWFsIHNlcnZpY2VzLiBJIHRoaW5rDQo+IGlzc3VlcyBzdWNoIGFz IHRoZSBwcm90ZWN0aW9uIG9mIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBzaG91bGQgYmUNCj4gZGV2 ZWxvcGVkIGluIHRoZSBtb2RlbCBpdHNlbGYsIGJlY2F1c2UgdGhleSBhcmUgZ2VuZXJpYy4NCg0K W01lZF0gSXQgaXMgdXAgdG8gZWFjaCBpbmRpdmlkdWFsIG1vZGVsIHRvIGNhbGwgb3V0IHRob3Nl LCBub3QgdGhpcyBkb2N1bWVudC4gDQoNCiBUaGUNCj4gZG9jdW1lbnQgYXJ0aWN1bGF0ZXMgYSBo aWVyYXJjaHkgb2YgWWFuZyBtb2R1bGVzLiBXaHkgZG9lcyBpdCBub3QNCj4gYXJ0aWN1bGF0ZSB0 aGUgdHJ1c3QgYm91bmRhcmllcyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgYWN0b3JzPw0KDQpbTWVk XSBCZWNhdXNlIHRoZSBmb2N1cyBpcyBvbiB3aGF0IGhhcHBlbnMgd2l0aGluICAqKiBhIHNpbmds ZSBwcm92aWRlciAqKi4gVGhlIGludGVyYWN0aW9uIHdpdGggb3RoZXIgcHJvdmlkZXJzIGlzIG5v IG1vcmUgdGhhbiBhIHByb3ZpZGVyIGFjdGluZyBhcyBhICJjdXN0b21lciIgZm9yIGEgc2Vydmlj ZSBvZmZlcmVkIGJ5IGFub3RoZXIgcHJvdmlkZXIuIA0KDQpUaGUgY3VzdG9tZXItZmFjaW5nIGlu dGVyZmFjZSBpcyBvdXQgb2Ygc2NvcGUuIFdlIHRoaW5rIHRoaXMgdGhpcyBub3cgY2xhcmlmaWVk IHdpdGggdGhlIHJldmlldyBmcm9tIEJyaWFuLiANCg0KPiANCj4gSW4gYWRkaXRpb24gdG8gdGhy ZWUgY2xhc3NlcyBvZiBpc3N1ZXMgbGlzdGVkIGluIHRoZSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0 aW9ucywgSSBhbSBhbHNvIGNvbmNlcm5lZCB3aXRoIHBvc3NpYmlsaXRpZXMgb2YgcmV0YWluaW5n DQo+IG9yIGZhbHNpZnlpbmcgZGF0YS4gV2hhdCBpZiBhbiBhY3RvciBoaWRlcyBvciBmYWtlcyBw ZXJmb3JtYW5jZQ0KPiBtb25pdG9yaW5nIGRhdGEsIGVpdGhlciBvdXQgb2YgbWFsaWNlIG9yIGR1 ZSB0byBmYXVsdHkgZXF1aXBlbWVudD8NCg0KW01lZF0gQWxsIHRoZSBsZXZlbHMgYXJlIHVuZGVy IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgc2FtZSBwcm92aWRlci4gQW4gdW5kZXJseWluZyBs ZXZlbCBjYW4gcmVwb3J0IHBlcmZvcm1hbmNlIGRhdGEgYnV0IHRoZSBhYm92ZSBsZXZlbCBjYW4g YWxzbyBwcm9jZWVkIHdpdGggT0FNIGNoZWNrcyBhcyBwZXIgU2VjdGlvbiA0LjEuNC4gQW5vbWFs aWVzIGNhbiB0aHVzIGJlIGRldGVjdGVkIGxvY2FsbHkuICAgDQoNCj4gV2lsbCB0aGF0IGRpc3J1 cHQgdGhlIHByb3Zpc2lvbiBvZiB0aGUgc2VydmljZXM/IFdoYXQgdG9vbHMgYXJlDQo+IGF2YWls YWJsZSB0byBkZXRlY3Qgc3VjaCBiZWhhdmlvcj8gV2hhdCBpZiBhIG5ldHdvcmsgcHJvdmlkZQ0K PiBvdmVycHJvbWlzZXMsIGluIG9yZGVyIHRvIGF0dHJhY3QgY29udHJhY3RzPyBJIHVuZGVyc3Rh bmQgdGhhdCB0aGUNCj4gdWx0aW1hdGUgcmVtZWRpZXMgbGllcyBpbiBjb250cmFjdCBvYmxpZ2F0 aW9ucyBhbmQgY29udHJhY3QNCj4gZW5mb3JjZW1lbnQsIGJ1dCB0aGF0IGVuZm9yY2VtZW50IGhh cyB0byBiZSBiYXNlZCBvbiBkYXRhLiBIb3cgaXMNCj4gdGhlIGFyY2hpdGVjdHVyIG9yZ2FuaXpp bmcgdGhlIGNvbGxlY3Rpb24gb2YgdGhlIGRhdGE/DQoNCltNZWRdIFRoaXMgaXMgdGhlIHJvbGUg b2YgdGhlIGFzc3VyYW5jZSBmdW5jdGlvbnMuIFNlZSBhbHNvIHRoZSBORVcgdGV4dCBzdWdnZXN0 ZWQgYWJvdmUuICANCg0KPiANCj4gT24gYSBzaWRlIG5vdGUsIEkgZmluZCB0aGF0IHRoaXMgYXJj aGl0ZWN0dXJlIGNpdGVzIGEgbGFyZ2UgbnVtYmVyDQo+IG9mIG90aGVyIGRyYWZ0cyBzdWNoIGFz IGV2cG4sIGwydnBuLCBsM3ZwbiwgZXRjLiBUaGVzZSBkcmFmdHMgaW4NCj4gdHVybiBwcmVzdW1h Ymx5IGNpdGUgdGhlIGFyY2hpdGVjdHVyZSwgdGh1cyBmb3JjaW5nIHRoZSBSRkMNCj4gcHJvZHVj dGlvbiB0byBvcmdhbml6ZSBhbGwgb2YgdGhlbSBpbiBhIGxhcmdlIHB1YmxpY2F0aW9uIGNsdXN0 ZXIuDQo+IElzIGl0IHJlYWxseSByZXF1aXJlZCBmb3IgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCB0byBjaXRlIGFsbCB0aGUNCj4gZG9jdW1lbnRzIHRoYXQgd2lsbCBsYXRlciB1c2UgaXQ/DQoN CltNZWRdIE5vbmUgb2YgdGhlc2UgZHJhZnRzIGlzIG5vcm1hdGl2ZS4gVGhlcmUgaXMgbm90IHJp c2sgdG8gY3JlYXRlIGEgcHVibGljYXRpb24gY2x1c3Rlci4gDQoNCg0KCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsg eW91LgoK From nobody Mon Oct 5 08:33:36 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FE13A0B5E for ; Mon, 5 Oct 2020 08:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 kjfjedV0Vadj for ; Mon, 5 Oct 2020 08:33:28 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 827C83A0B5F for ; Mon, 5 Oct 2020 08:33:28 -0700 (PDT) Received: from xse471.mail2web.com ([66.113.197.217] helo=xse.mail2web.com) by mx105.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kPSUK-0000tM-VJ for secdir@ietf.org; Mon, 05 Oct 2020 17:33:23 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4C4kn80h8gz1V3H for ; Mon, 5 Oct 2020 08:20:28 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kPSHr-00088z-VY for secdir@ietf.org; Mon, 05 Oct 2020 08:20:28 -0700 Received: (qmail 22627 invoked from network); 5 Oct 2020 15:20:27 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.46.239]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Oct 2020 15:20:27 -0000 To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "opsawg@ietf.org" , "last-call@ietf.org" , "draft-ietf-opsawg-model-automation-framework.all@ietf.org" References: <160176719670.27275.17469866976212039001@ietfa.amsl.com> <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <7daed45f-5bd7-e2bc-8663-8ca2bea7fb82@huitema.net> Date: Mon, 5 Oct 2020 08:20:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.217 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDcQkv3rfK9nOh84B6FNp+WsRX qYbtEQV1z/L435ZRxFQ9JRr01hVIlwpzB50G+oyR+rYZvu7UEJiU3s27VgKHO7lwS3dBJTnTxDoD vBGGxph9w6EwXICYy0ePXtGEMhqrwBb733ZN4jAbrTI5wHo5JWU6UgOqKJ9sMwhVoOBGSAIboXtx P9OF0EfNs5TqNq2Yhy7LI0kfFnXdPP6btp4oBeJDeKRq5oPj2hFJhLx+qI3HlR3ootg7OlA3N5WN re/oppAGOX5cHTu1yz4pRT/9FGrxEaaKeSxe0Wrx6M4G5/WoLsdfEoJI0BNUQ4KpaNyNCwGqOUcw rXf55E8Tb8bmXq4yH8StrboPphDtmrtUkwkDMc9xayd+oZJo2heFY+g6kVWClPVvbW5lVyQanRxw 5rdY2rW50fd1ekaDpmIWc1Vmt3mnxMTQMQWbvBqEXskTQn6USYs98Imn+lZXe3dwYfgVB1xo6dCf BaU/iegBU8bHkXi9GLeWp7+HXTQ99TbN4nuZrRf7bMi0WRR6pZ+nWenxzl3kyuMsv/qfr4+QzXJX 0SU68ek9wyYNR7nSKrZbQsAM8hGlAkv+YXlQiOyIRazNjLvclnGzlTC8ZgkR3laIWqvAxiBHuIuS y5fCAlEkHWdEoOAn+pyn1FCAnUcslFACVO3tx78u0bG7If2TCVQtfNqznpbXSApsuXcqc2cE4v5n gYjCWliiVknmee8v8znzSXChKWk/itcbicJsIPcXdWV5hJvxxhlt4adIoo6yfqb5R4VemuUI6bcE ARsm0De6PaZO6/JToEyx4tmc5OljkPSpPXAVjl2oMr8a1xm0wfXUFMjTH2DyD8i5kO5bZlYFvf25 LVONYbYifH5OzZCwIgD/xDehea09OpnwSuobZrrGExMR7eTbBjMGDKI3ijhhJn7Muv/NHXl0o++8 3wM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 15:33:30 -0000 On 10/5/2020 1:02 AM, mohamed.boucadair@orange.com wrote: > Hi Christian,=20 > > Thank you for the review.=20 > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Christian Huitema via Datatracker [mailto:noreply@ietf.org] >> Envoy=C3=A9=C2=A0: dimanche 4 octobre 2020 01:20 >> =C3=80=C2=A0: secdir@ietf.org >> Cc=C2=A0: opsawg@ietf.org; last-call@ietf.org; draft-ietf-opsawg-model= - >> automation-framework.all@ietf.org >> Objet=C2=A0: Secdir last call review of draft-ietf-opsawg-model- >> automation-framework-06 >> >> Reviewer: Christian Huitema >> Review result: Has Issues >> >> The document proposes an architecture for describing and >> provisioning services such as L3VPN or L2VPN. This is an ambitious >> architecture, aiming at providing end-to-end services over >> concatenations of network services provided by independent >> providers. > [Med] There is no such assumption in the draft but we can accommodate t= hat case.=20 It seems I was led to the wrong conclusion by the exposition of the layering between services, networks and devices. If you in fact assume that all the "networks" involved in the provision of the service are under the same management, by a single operator, then you should say that loudly and clearly in the draft. > I am concerned that the model does not expose trust >> boundaries during these providers, and that the security section >> does not discuss what happens when some providers try to game the >> system or otherwise fail to cooperate. > [Med] The various blocks discussed in the document are within the scope= of the ** same provider **.=20 > > That's said, if a provider relies upon other providers to deliver a giv= en service, the model will apply in a recursive manner: That is, a networ= k can act as a "customer" and request services from other networks. The p= eer network will then follow the various levels depicted in the architect= ure to deliver the service. > > Any failure of a peer provider to deliver an agreed service is a violat= ion of the service level agreement. Such violation is detected by means o= f the service fulfilment/assurance and appropriate counter-measures will = be followed. These counter-measures may be technical (switch to another p= rovider) and/or contractual (penalties).=20 > > We can add the following:=20 > > A provider may rely upon services offered by other providers. > Appropriate mechanisms should be enabled by the provider to monitor > and detect a service disruption from these providers. The > characterization of a service disruption (including, mean time > between failures, mean time to repair), the escalation procedure, an= d > penalties are usually documented in contractual agreements. > Misbehaving peer providers will thus be identified and appropriate > countermeasures will be applied. Yes, please. >> The architecture organizes functions in three levels, service, >> network and device. Creation of services will trigger requirements >> on the networks, and then configuration of devices. Performance >> monitoring at the device level will inform service assurance and >> service optimizatio at the network level, and service assurance, >> optimization and diagnostic at the service level. The configurations >> and the performance measurements are described using Yang models. >> >> The Yang modules are designed to be accessed through secrure >> protocols, such as NETCONF over SSH or RESTCONF over HTTPS. This >> provides authentication of the servers and protection of the data, >> and allows implementation of access control. That's a good basis, >> but these processes only secure "point to point" >> interfaces between functions in the system. This presupposes honest >> cooperation between all actors, despite the fact that those actors >> often are in competition. >> >> The security considerations consider misconfiguration attacks such >> as the creation of forwarding loops, leakage of sensitive >> information, and traffic isolation issues. These are all interesting >> issues, but they are only mentioned in the architecture document as >> guidelines for the future development of actual services. I think >> issues such as the protection of sensitive information should be >> developed in the model itself, because they are generic. > [Med] It is up to each individual model to call out those, not this doc= ument.=20 I am concerned about that. If that's the approach, then it should be stated very forcefully, as in some kind of MUST requirement for the development of service descriptions. > > The >> document articulates a hierarchy of Yang modules. Why does it not >> articulate the trust boundaries between the different actors? > [Med] Because the focus is on what happens within ** a single provider= **. The interaction with other providers is no more than a provider acti= ng as a "customer" for a service offered by another provider.=20 > > The customer-facing interface is out of scope. We think this this now c= larified with the review from Brian.=20 I already asked that you state the single provider focus more clearly in introduction. I would appreciate if it was also called out in the security considerations. You assume that the various elements are under a single management authority, and thus are cooperating in good faith. Applying the model without that assumption opens the possibility of a range of attacks, in which competing actors might be dissimulating or manipulating information. You consider that out of scope, but then that also mean that the model should not be applied to orchestration of services across multiple operators. On the other end, there is the particular issue of the untrusted device. Consider the now classic scenario in which attackers manage to obtain the credential of some employees of the operator, maybe through a phishing attack. The attackers then use those credentials to gain access to a couple of network devices. Have you considered how they might leverage that access through the service architecture? Or, conversely, have you considered whether the architecture provides functions for the operator to detect and isolate such attacks? >> In addition to three classes of issues listed in the security >> considerations, I am also concerned with possibilities of retaining >> or falsifying data. What if an actor hides or fakes performance >> monitoring data, either out of malice or due to faulty equipement? > [Med] All the levels are under the responsibility of the same provider.= An underlying level can report performance data but the above level can = also proceed with OAM checks as per Section 4.1.4. Anomalies can thus be = detected locally. =20 > >> Will that disrupt the provision of the services? What tools are >> available to detect such behavior? What if a network provide >> overpromises, in order to attract contracts? I understand that the >> ultimate remedies lies in contract obligations and contract >> enforcement, but that enforcement has to be based on data. How is >> the architectur organizing the collection of the data? > [Med] This is the role of the assurance functions. See also the NEW tex= t suggested above. Yes, the new text is useful. >> On a side note, I find that this architecture cites a large number >> of other drafts such as evpn, l2vpn, l3vpn, etc. These drafts in >> turn presumably cite the architecture, thus forcing the RFC >> production to organize all of them in a large publication cluster. >> Is it really required for the architecture document to cite all the >> documents that will later use it? > [Med] None of these drafts is normative. There is not risk to create a = publication cluster.=20 I will leave that to you and the RFC Production Center. That was just a side remark. -- Christian Huitema From nobody Tue Oct 6 00:22:14 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DCE3A1207; Tue, 6 Oct 2020 00:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 2uv_EnqMVdN6; Tue, 6 Oct 2020 00:22:05 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71553A1253; Tue, 6 Oct 2020 00:22:04 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4C586g0V9tz1yX3; Tue, 6 Oct 2020 09:22:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1601968923; bh=ghC6YhhsiRfvwlR+63UD4Q1+Kngvscah65BFdTjhP8I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=AKR6W/7Bs+V//9BUfeo/6ztfkSwfa/VtxbMeEuL5RfK0L12Ek1H06cgBO8wmTXIeI jPLGNjs7jH30u/slK0w+vWQ7HpEKTP7T9STgF47g5TJkamKd6hYvkQ0dh00cnL+whp B9vCC9ILzt8005RRtIkr0vfHnj6cTmWRsmYwNOs3i1e2NtnmWKeOLAoy5HLIGlpHJx B2FC3iDCiLCpzjrxKURDm8+JrXvVbeS2TULnRhd5ip8j8DVn6obpXDDrlkO6d5X0T7 gjN+ECgNSCLhoE76Z2rzXhs/TaoFDNFmMhmyelGqrQjbQFo/idIbGmIy5AZbGDC/sU pOe4v+6E4eqIw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 4C586f6mrmz1xpZ; Tue, 6 Oct 2020 09:22:02 +0200 (CEST) From: To: Christian Huitema , "secdir@ietf.org" CC: "opsawg@ietf.org" , "last-call@ietf.org" , "draft-ietf-opsawg-model-automation-framework.all@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 Thread-Index: AQHWmyznzK6bClqu6UiOqq+yBh8iZqmKJs0Q Date: Tue, 6 Oct 2020 07:22:02 +0000 Message-ID: <27006_1601968923_5F7C1B1A_27006_382_1_787AE7BB302AE849A7480A190F8B93303154DA92@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160176719670.27275.17469866976212039001@ietfa.amsl.com> <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7daed45f-5bd7-e2bc-8663-8ca2bea7fb82@huitema.net> In-Reply-To: <7daed45f-5bd7-e2bc-8663-8ca2bea7fb82@huitema.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 07:22:07 -0000 SGkgQ2hyaXN0aWFuLCANCg0KWW91IG1hZGUgZ29vZCBwb2ludHMuIFRoYW5rcy4gDQoNCkkgd2Vu dCB3aXRoIHRoZSBmb2xsb3dpbmcgbW9kaWZpY2F0aW9ucyB0byB0cnkgdG8gYWRkcmVzcyB0aGVt Og0KDQoqIFVwZGF0ZSB0aGUgdGl0bGUgb2YgdGhlIGxheWVyaW5nIGFyY2hpdGVjdHVyZSB0byBp bnNpc3QgdGhlIHZpZXcgd2l0aGluIHRoZSBzYW1lIG9wZXJhdG9yOiAgDQoNCk9MRDogDQogRmln dXJlIDM6IExheWVyaW5nIGFuZCBSZXByZXNlbnRhdGlvbg0KDQpORVcNCiBGaWd1cmUgMzogTGF5 ZXJpbmcgYW5kIFJlcHJlc2VudGF0aW9uIFdpdGhpbiBhIE5ldHdvcmsgT3BlcmF0b3INCg0KQW5k IGFkZGVkIHRoaXMgTkVXIHRleHQgdG8gZnVydGhlciBpbnNpc3Qgb24gdGhpcyBhc3BlY3Q6IA0K DQogIkFsbCB0aGVzZSBlbGVtZW50cyAoaS5lLiwgT3JjaGVzdHJhdG9yKHMpLAkNCiBDb250cm9s bGVyKHMpLCBkZXZpY2UocykpIGFyZSB1bmRlciB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIHNh bWUJDQogb3BlcmF0b3IuIg0KDQoqIE1lbnRpb24gaG93IHRoZSBjb21wb3NpdGUgc2VydmljZSBj YXNlIGlzIGhhbmRsZWQ6IA0KDQpORVc6DQogQSBjb21wb3NpdGUgc2VydmljZSBvZmZlcmVkIGJ5 IGEgbmV0d29yayBvcGVyYXRvciBtYXkgcmVseSBvbgkNCiBzZXJ2aWNlcyB0aGF0IGFyZSBvZmZl cmVkIGJ5IG90aGVyIG9wZXJhdG9ycy4gIEluIHN1Y2ggY2FzZSwgdGhlCSANCiBuZXR3b3JrIG9w ZXJhdG9yIGFjdHMgYXMgYSAiQ3VzdG9tZXIiIHRvIHJlcXVlc3Qgc2VydmljZXMgZnJvbSBvdGhl cgkNCiBuZXR3b3Jrcy4gIFRoZSBvcGVyYXRvcnMgcHJvdmlkaW5nIHRoZXNlIHNlcnZpY2VzIHdp bGwgdGhlbiBmb2xsb3cJDQogdGhlIGxheWVyaW5nIGRlcGljdGVkIGluIEZpZ3VyZSAzLg0KDQoq IENvdmVyIHNlcnZpY2UgdmlvbGF0aW9uIChpbmNsdWRpbmcgImJhZCIgcGFydG5lcnMpOiANCg0K TkVXOg0KICAgQSBwcm92aWRlciBtYXkgcmVseSBvbiBzZXJ2aWNlcyBvZmZlcmVkIGJ5IG90aGVy IHByb3ZpZGVycyB0byBidWlsZA0KICAgY29tcG9zaXRlIHNlcnZpY2VzLiAgQXBwcm9wcmlhdGUg bWVjaGFuaXNtcyBzaG91bGQgYmUgZW5hYmxlZCBieSB0aGUNCiAgIHByb3ZpZGVyIHRvIG1vbml0 b3IgYW5kIGRldGVjdCBhIHNlcnZpY2UgZGlzcnVwdGlvbiBmcm9tIHRoZXNlDQogICBwcm92aWRl cnMuICBUaGUgY2hhcmFjdGVyaXphdGlvbiBvZiBhIHNlcnZpY2UgZGlzcnVwdGlvbiAoaW5jbHVk aW5nLA0KICAgbWVhbiB0aW1lIGJldHdlZW4gZmFpbHVyZXMsIG1lYW4gdGltZSB0byByZXBhaXIp LCB0aGUgZXNjYWxhdGlvbg0KICAgcHJvY2VkdXJlLCBhbmQgcGVuYWx0aWVzIGFyZSB1c3VhbGx5 IGRvY3VtZW50ZWQgaW4gY29udHJhY3R1YWwNCiAgIGFncmVlbWVudHMgKGUuZy4sIFNlY3Rpb24g Mi4xIG9mIFtSRkM0MTc2XSkuICBNaXNiZWhhdmluZyBwZWVyDQogICBwcm92aWRlcnMgd2lsbCB0 aHVzIGJlIGlkZW50aWZpZWQgYW5kIGFwcHJvcHJpYXRlIGNvdW50ZXJtZWFzdXJlcw0KICAgd2ls bCBiZSBhcHBsaWVkLg0KDQoqIEludGVybmFsIGxheWVyIG1pc2FsaWdubWVudCAoY29ycnVwdGVk IGRhdGEsIG1hbmlwdWxhdGVkIGRhdGEgcmVwb3J0aW5nLCAuLik6IA0KDQpORVc6DQogICBUbyBk ZXRlY3QgbWlzYWxpZ25tZW50IGJldHdlZW4gbGF5ZXJzIHRoYXQgbWlnaHQgYmUgaW5kdWNlZCBi eQ0KICAgbWlzYmVoYXZpbmcgbm9kZXMsIHVwcGVyIGxheWVycyBzaG91bGQgY29udGludW91c2x5 IG1vbml0b3IgdGhlDQogICBwZXJjZWl2ZWQgc2VydmljZSAoU2VjdGlvbiA0LjEuMykgYW5kIHNo b3VsZCBwcm9jZWVkIHdpdGggY2hlY2tzIHRvDQogICBhc3Nlc3MgdGhhdCB0aGUgcHJvdmlkZWQg c2VydmljZSBjb21wbGllcyB3aXRoIHRoZSBleHBlY3RlZCBzZXJ2aWNlDQogICBhbmQgdGhhdCB0 aGUgZGF0YSByZXBvcnRlZCBieSBhbiB1bmRlcmx5aW5nIGxheWVyIGlzIG1hdGNoaW5nIHRoZQ0K ICAgcGVyY2VpdmVkIHNlcnZpY2UgYnkgdGhlIGFib3ZlIGxheWVyLiAgVHlwaWNhbGx5LCBzdWNo IGNoZWNrcyBhcmUgdGhlDQogICByZXNwb25zaWJpbGl0eSBvZiB0aGUgc2VydmljZSBkaWFnbm9z aXMgKFNlY3Rpb24gNC4xLjQpLg0KDQoqIE1pc2JlaGF2aW5nIE5vZGVzOiANCg0KTkVXOg0KICAg TmV0d29yayBvcGVyYXRvcnMgc2hvdWxkIG1vbml0b3IgYW5kIGF1ZGl0IHRoZWlyIG5ldHdvcmtz IHRvIGRldGVjdA0KICAgbWlzYmVoYXZpbmcgbm9kZXMgYW5kIGFibm9ybWFsIGJlaGF2aW9ycy4g IEZvciBleGFtcGxlLCBPQU0gZGlzY3Vzc2VkDQogICBpbiBTZWN0aW9uIDQuMS40IGNhbiBiZSB1 c2VkIGZvciB0aGF0IHB1cnBvc2UuDQoNCk9uZSBwZW5kaW5nIGNvbW1lbnQgaXMgdGhpcyBvbmU6 ICANCg0KPiA+IFtNZWRdIEl0IGlzIHVwIHRvIGVhY2ggaW5kaXZpZHVhbCBtb2RlbCB0byBjYWxs IG91dCB0aG9zZSwgbm90DQo+IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBJIGFtIGNvbmNlcm5lZCBh Ym91dCB0aGF0LiBJZiB0aGF0J3MgdGhlIGFwcHJvYWNoLCB0aGVuIGl0IHNob3VsZCBiZQ0KPiBz dGF0ZWQgdmVyeSBmb3JjZWZ1bGx5LCBhcyBpbiBzb21lIGtpbmQgb2YgTVVTVCByZXF1aXJlbWVu dCBmb3IgdGhlDQo+IGRldmVsb3BtZW50IG9mIHNlcnZpY2UgZGVzY3JpcHRpb25zLg0KDQpNb2Rl bHMgbXVzdCBhbnl3YXkgY29tcGx5IHdpdGggaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvb3Bz L3dpa2kveWFuZy1zZWN1cml0eS1ndWlkZWxpbmVzLiBUaGVzZSBtb2RlbHMgbXVzdCBpZGVudGlm eSBzZW5zaXRpdmUgZGF0YSBhbmQgc28gb24uIEknbSBhZnJhaWQgdGhhdCBubyBjaGFuZ2UgaXMg bmVlZGVkIGZvciB0aGlzIG9uZS4gIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogQ2hyaXN0aWFuIEh1aXRlbWEgW21haWx0bzpodWl0ZW1h QGh1aXRlbWEubmV0XQ0KPiBFbnZvecOpwqA6IGx1bmRpIDUgb2N0b2JyZSAyMDIwIDE3OjIwDQo+ IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+Ow0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2PCoDogb3BzYXdnQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb3BzYXdnLW1vZGVsLQ0KPiBhdXRvbWF0aW9uLWZy YW1ld29yay5hbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtMYXN0LUNhbGxdIFNlY2RpciBs YXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtDQo+IG9wc2F3Zy1tb2RlbC1hdXRvbWF0aW9u LWZyYW1ld29yay0wNg0KPiANCj4gDQo+IE9uIDEwLzUvMjAyMCAxOjAyIEFNLCBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+IEhpIENocmlzdGlhbiwNCj4gPg0KPiA+IFRo YW5rIHlvdSBmb3IgdGhlIHJldmlldy4NCj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+ DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiA+PiBEZcKgOiBDaHJpc3RpYW4gSHVpdGVtYSB2aWEgRGF0YXRyYWNrZXIgW21haWx0 bzpub3JlcGx5QGlldGYub3JnXQ0KPiA+PiBFbnZvecOpwqA6IGRpbWFuY2hlIDQgb2N0b2JyZSAy MDIwIDAxOjIwIMOAwqA6IHNlY2RpckBpZXRmLm9yZyBDY8KgOg0KPiA+PiBvcHNhd2dAaWV0Zi5v cmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vcHNhd2ctbW9kZWwtDQo+ID4+IGF1 dG9tYXRpb24tZnJhbWV3b3JrLmFsbEBpZXRmLm9yZyBPYmpldMKgOiBTZWNkaXIgbGFzdCBjYWxs IHJldmlldw0KPiBvZg0KPiA+PiBkcmFmdC1pZXRmLW9wc2F3Zy1tb2RlbC0NCj4gPj4gYXV0b21h dGlvbi1mcmFtZXdvcmstMDYNCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IENocmlzdGlhbiBIdWl0ZW1h DQo+ID4+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gPj4NCj4gPj4gVGhlIGRvY3VtZW50 IHByb3Bvc2VzIGFuIGFyY2hpdGVjdHVyZSBmb3IgZGVzY3JpYmluZyBhbmQNCj4gcHJvdmlzaW9u aW5nDQo+ID4+IHNlcnZpY2VzIHN1Y2ggYXMgTDNWUE4gb3IgTDJWUE4uIFRoaXMgaXMgYW4gYW1i aXRpb3VzDQo+IGFyY2hpdGVjdHVyZSwNCj4gPj4gYWltaW5nIGF0IHByb3ZpZGluZyBlbmQtdG8t ZW5kIHNlcnZpY2VzIG92ZXIgY29uY2F0ZW5hdGlvbnMgb2YNCj4gPj4gbmV0d29yayBzZXJ2aWNl cyBwcm92aWRlZCBieSBpbmRlcGVuZGVudCBwcm92aWRlcnMuDQo+ID4gW01lZF0gVGhlcmUgaXMg bm8gc3VjaCBhc3N1bXB0aW9uIGluIHRoZSBkcmFmdCBidXQgd2UgY2FuDQo+IGFjY29tbW9kYXRl IHRoYXQgY2FzZS4NCj4gDQo+IEl0IHNlZW1zIEkgd2FzIGxlZCB0byB0aGUgd3JvbmcgY29uY2x1 c2lvbiBieSB0aGUgZXhwb3NpdGlvbiBvZiB0aGUNCj4gbGF5ZXJpbmcgYmV0d2VlbiBzZXJ2aWNl cywgbmV0d29ya3MgYW5kIGRldmljZXMuIElmIHlvdSBpbiBmYWN0DQo+IGFzc3VtZSB0aGF0IGFs bCB0aGUgIm5ldHdvcmtzIiBpbnZvbHZlZCBpbiB0aGUgcHJvdmlzaW9uIG9mIHRoZQ0KPiBzZXJ2 aWNlIGFyZSB1bmRlciB0aGUgc2FtZSBtYW5hZ2VtZW50LCBieSBhIHNpbmdsZSBvcGVyYXRvciwg dGhlbg0KPiB5b3Ugc2hvdWxkIHNheSB0aGF0IGxvdWRseSBhbmQgY2xlYXJseSBpbiB0aGUgZHJh ZnQuDQo+IA0KPiA+ICBJIGFtIGNvbmNlcm5lZCB0aGF0IHRoZSBtb2RlbCBkb2VzIG5vdCBleHBv c2UgdHJ1c3QNCj4gPj4gYm91bmRhcmllcyBkdXJpbmcgdGhlc2UgcHJvdmlkZXJzLCBhbmQgdGhh dCB0aGUgc2VjdXJpdHkgc2VjdGlvbg0KPiBkb2VzDQo+ID4+IG5vdCBkaXNjdXNzIHdoYXQgaGFw cGVucyB3aGVuIHNvbWUgcHJvdmlkZXJzIHRyeSB0byBnYW1lIHRoZQ0KPiBzeXN0ZW0NCj4gPj4g b3Igb3RoZXJ3aXNlIGZhaWwgdG8gY29vcGVyYXRlLg0KPiA+IFtNZWRdIFRoZSB2YXJpb3VzIGJs b2NrcyBkaXNjdXNzZWQgaW4gdGhlIGRvY3VtZW50IGFyZSB3aXRoaW4gdGhlDQo+IHNjb3BlIG9m IHRoZSAqKiBzYW1lIHByb3ZpZGVyICoqLg0KPiA+DQo+ID4gVGhhdCdzIHNhaWQsIGlmIGEgcHJv dmlkZXIgcmVsaWVzIHVwb24gb3RoZXIgcHJvdmlkZXJzIHRvIGRlbGl2ZXINCj4gYSBnaXZlbiBz ZXJ2aWNlLCB0aGUgbW9kZWwgd2lsbCBhcHBseSBpbiBhIHJlY3Vyc2l2ZSBtYW5uZXI6IFRoYXQN Cj4gaXMsIGEgbmV0d29yayBjYW4gYWN0IGFzIGEgImN1c3RvbWVyIiBhbmQgcmVxdWVzdCBzZXJ2 aWNlcyBmcm9tDQo+IG90aGVyIG5ldHdvcmtzLiBUaGUgcGVlciBuZXR3b3JrIHdpbGwgdGhlbiBm b2xsb3cgdGhlIHZhcmlvdXMgbGV2ZWxzDQo+IGRlcGljdGVkIGluIHRoZSBhcmNoaXRlY3R1cmUg dG8gZGVsaXZlciB0aGUgc2VydmljZS4NCj4gPg0KPiA+IEFueSBmYWlsdXJlIG9mIGEgcGVlciBw cm92aWRlciB0byBkZWxpdmVyIGFuIGFncmVlZCBzZXJ2aWNlIGlzIGENCj4gdmlvbGF0aW9uIG9m IHRoZSBzZXJ2aWNlIGxldmVsIGFncmVlbWVudC4gU3VjaCB2aW9sYXRpb24gaXMgZGV0ZWN0ZWQN Cj4gYnkgbWVhbnMgb2YgdGhlIHNlcnZpY2UgZnVsZmlsbWVudC9hc3N1cmFuY2UgYW5kIGFwcHJv cHJpYXRlDQo+IGNvdW50ZXItbWVhc3VyZXMgd2lsbCBiZSBmb2xsb3dlZC4gVGhlc2UgY291bnRl ci1tZWFzdXJlcyBtYXkgYmUNCj4gdGVjaG5pY2FsIChzd2l0Y2ggdG8gYW5vdGhlciBwcm92aWRl cikgYW5kL29yIGNvbnRyYWN0dWFsDQo+IChwZW5hbHRpZXMpLg0KPiA+DQo+ID4gV2UgY2FuIGFk ZCB0aGUgZm9sbG93aW5nOg0KPiA+DQo+ID4gICAgQSBwcm92aWRlciBtYXkgcmVseSB1cG9uIHNl cnZpY2VzIG9mZmVyZWQgYnkgb3RoZXIgcHJvdmlkZXJzLg0KPiA+ICAgIEFwcHJvcHJpYXRlIG1l Y2hhbmlzbXMgc2hvdWxkIGJlIGVuYWJsZWQgYnkgdGhlIHByb3ZpZGVyIHRvDQo+IG1vbml0b3IN Cj4gPiAgICBhbmQgZGV0ZWN0IGEgc2VydmljZSBkaXNydXB0aW9uIGZyb20gdGhlc2UgcHJvdmlk ZXJzLiAgVGhlDQo+ID4gICAgY2hhcmFjdGVyaXphdGlvbiBvZiBhIHNlcnZpY2UgZGlzcnVwdGlv biAoaW5jbHVkaW5nLCBtZWFuIHRpbWUNCj4gPiAgICBiZXR3ZWVuIGZhaWx1cmVzLCBtZWFuIHRp bWUgdG8gcmVwYWlyKSwgdGhlIGVzY2FsYXRpb24NCj4gcHJvY2VkdXJlLCBhbmQNCj4gPiAgICBw ZW5hbHRpZXMgYXJlIHVzdWFsbHkgZG9jdW1lbnRlZCBpbiBjb250cmFjdHVhbCBhZ3JlZW1lbnRz Lg0KPiA+ICAgIE1pc2JlaGF2aW5nIHBlZXIgcHJvdmlkZXJzIHdpbGwgdGh1cyBiZSBpZGVudGlm aWVkIGFuZA0KPiBhcHByb3ByaWF0ZQ0KPiA+ICAgIGNvdW50ZXJtZWFzdXJlcyB3aWxsIGJlIGFw cGxpZWQuDQo+IA0KPiBZZXMsIHBsZWFzZS4NCj4gDQo+ID4+IFRoZSBhcmNoaXRlY3R1cmUgb3Jn YW5pemVzIGZ1bmN0aW9ucyBpbiB0aHJlZSBsZXZlbHMsIHNlcnZpY2UsDQo+ID4+IG5ldHdvcmsg YW5kIGRldmljZS4gQ3JlYXRpb24gb2Ygc2VydmljZXMgd2lsbCB0cmlnZ2VyDQo+IHJlcXVpcmVt ZW50cyBvbg0KPiA+PiB0aGUgbmV0d29ya3MsIGFuZCB0aGVuIGNvbmZpZ3VyYXRpb24gb2YgZGV2 aWNlcy4gUGVyZm9ybWFuY2UNCj4gPj4gbW9uaXRvcmluZyBhdCB0aGUgZGV2aWNlIGxldmVsIHdp bGwgaW5mb3JtIHNlcnZpY2UgYXNzdXJhbmNlIGFuZA0KPiA+PiBzZXJ2aWNlIG9wdGltaXphdGlv IGF0IHRoZSBuZXR3b3JrIGxldmVsLCBhbmQgc2VydmljZSBhc3N1cmFuY2UsDQo+ID4+IG9wdGlt aXphdGlvbiBhbmQgZGlhZ25vc3RpYyBhdCB0aGUgc2VydmljZSBsZXZlbC4gVGhlDQo+IGNvbmZp Z3VyYXRpb25zDQo+ID4+IGFuZCB0aGUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnRzIGFyZSBkZXNj cmliZWQgdXNpbmcgWWFuZyBtb2RlbHMuDQo+ID4+DQo+ID4+IFRoZSBZYW5nIG1vZHVsZXMgYXJl IGRlc2lnbmVkIHRvIGJlIGFjY2Vzc2VkIHRocm91Z2ggc2VjcnVyZQ0KPiA+PiBwcm90b2NvbHMs IHN1Y2ggYXMgTkVUQ09ORiBvdmVyIFNTSCBvciBSRVNUQ09ORiBvdmVyIEhUVFBTLiBUaGlzDQo+ ID4+IHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBzZXJ2ZXJzIGFuZCBwcm90ZWN0aW9u IG9mIHRoZQ0KPiBkYXRhLA0KPiA+PiBhbmQgYWxsb3dzIGltcGxlbWVudGF0aW9uIG9mIGFjY2Vz cyBjb250cm9sLiBUaGF0J3MgYSBnb29kIGJhc2lzLA0KPiBidXQNCj4gPj4gdGhlc2UgcHJvY2Vz c2VzIG9ubHkgc2VjdXJlICJwb2ludCB0byBwb2ludCINCj4gPj4gaW50ZXJmYWNlcyBiZXR3ZWVu IGZ1bmN0aW9ucyBpbiB0aGUgc3lzdGVtLiBUaGlzIHByZXN1cHBvc2VzDQo+IGhvbmVzdA0KPiA+ PiBjb29wZXJhdGlvbiBiZXR3ZWVuIGFsbCBhY3RvcnMsIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB0 aG9zZQ0KPiBhY3RvcnMNCj4gPj4gb2Z0ZW4gYXJlIGluIGNvbXBldGl0aW9uLg0KPiA+Pg0KPiA+ PiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgY29uc2lkZXIgbWlzY29uZmlndXJhdGlvbiBh dHRhY2tzDQo+IHN1Y2ggYXMNCj4gPj4gdGhlIGNyZWF0aW9uIG9mIGZvcndhcmRpbmcgbG9vcHMs IGxlYWthZ2Ugb2Ygc2Vuc2l0aXZlDQo+IGluZm9ybWF0aW9uLA0KPiA+PiBhbmQgdHJhZmZpYyBp c29sYXRpb24gaXNzdWVzLiBUaGVzZSBhcmUgYWxsIGludGVyZXN0aW5nIGlzc3VlcywNCj4gYnV0 DQo+ID4+IHRoZXkgYXJlIG9ubHkgbWVudGlvbmVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1l bnQgYXMNCj4gZ3VpZGVsaW5lcw0KPiA+PiBmb3IgdGhlIGZ1dHVyZSBkZXZlbG9wbWVudCBvZiBh Y3R1YWwgc2VydmljZXMuIEkgdGhpbmsgaXNzdWVzDQo+IHN1Y2ggYXMNCj4gPj4gdGhlIHByb3Rl Y3Rpb24gb2Ygc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHNob3VsZCBiZSBkZXZlbG9wZWQgaW4NCj4g dGhlDQo+ID4+IG1vZGVsIGl0c2VsZiwgYmVjYXVzZSB0aGV5IGFyZSBnZW5lcmljLg0KPiA+IFtN ZWRdIEl0IGlzIHVwIHRvIGVhY2ggaW5kaXZpZHVhbCBtb2RlbCB0byBjYWxsIG91dCB0aG9zZSwg bm90DQo+IHRoaXMgZG9jdW1lbnQuDQo+IA0KPiBJIGFtIGNvbmNlcm5lZCBhYm91dCB0aGF0LiBJ ZiB0aGF0J3MgdGhlIGFwcHJvYWNoLCB0aGVuIGl0IHNob3VsZCBiZQ0KPiBzdGF0ZWQgdmVyeSBm b3JjZWZ1bGx5LCBhcyBpbiBzb21lIGtpbmQgb2YgTVVTVCByZXF1aXJlbWVudCBmb3IgdGhlDQo+ IGRldmVsb3BtZW50IG9mIHNlcnZpY2UgZGVzY3JpcHRpb25zLg0KPiANCj4gDQo+ID4NCj4gPiAg VGhlDQo+ID4+IGRvY3VtZW50IGFydGljdWxhdGVzIGEgaGllcmFyY2h5IG9mIFlhbmcgbW9kdWxl cy4gV2h5IGRvZXMgaXQgbm90DQo+ID4+IGFydGljdWxhdGUgdGhlIHRydXN0IGJvdW5kYXJpZXMg YmV0d2VlbiB0aGUgZGlmZmVyZW50IGFjdG9ycz8NCj4gPiBbTWVkXSBCZWNhdXNlIHRoZSBmb2N1 cyBpcyBvbiB3aGF0IGhhcHBlbnMgd2l0aGluICAqKiBhIHNpbmdsZQ0KPiBwcm92aWRlciAqKi4g VGhlIGludGVyYWN0aW9uIHdpdGggb3RoZXIgcHJvdmlkZXJzIGlzIG5vIG1vcmUgdGhhbiBhDQo+ IHByb3ZpZGVyIGFjdGluZyBhcyBhICJjdXN0b21lciIgZm9yIGEgc2VydmljZSBvZmZlcmVkIGJ5 IGFub3RoZXINCj4gcHJvdmlkZXIuDQo+ID4NCj4gPiBUaGUgY3VzdG9tZXItZmFjaW5nIGludGVy ZmFjZSBpcyBvdXQgb2Ygc2NvcGUuIFdlIHRoaW5rIHRoaXMgdGhpcw0KPiBub3cgY2xhcmlmaWVk IHdpdGggdGhlIHJldmlldyBmcm9tIEJyaWFuLg0KPiANCj4gSSBhbHJlYWR5IGFza2VkIHRoYXQg eW91IHN0YXRlIHRoZSBzaW5nbGUgcHJvdmlkZXIgZm9jdXMgbW9yZQ0KPiBjbGVhcmx5IGluIGlu dHJvZHVjdGlvbi4gSSB3b3VsZCBhcHByZWNpYXRlIGlmIGl0IHdhcyBhbHNvIGNhbGxlZA0KPiBv dXQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBZb3UgYXNzdW1lIHRoYXQgdGhlIHZh cmlvdXMNCj4gZWxlbWVudHMgYXJlIHVuZGVyIGEgc2luZ2xlIG1hbmFnZW1lbnQgYXV0aG9yaXR5 LCBhbmQgdGh1cyBhcmUNCj4gY29vcGVyYXRpbmcgaW4gZ29vZCBmYWl0aC4NCj4gQXBwbHlpbmcg dGhlIG1vZGVsIHdpdGhvdXQgdGhhdCBhc3N1bXB0aW9uIG9wZW5zIHRoZSBwb3NzaWJpbGl0eSBv Zg0KPiBhIHJhbmdlIG9mIGF0dGFja3MsIGluIHdoaWNoIGNvbXBldGluZyBhY3RvcnMgbWlnaHQg YmUgZGlzc2ltdWxhdGluZw0KPiBvciBtYW5pcHVsYXRpbmcgaW5mb3JtYXRpb24uIFlvdSBjb25z aWRlciB0aGF0IG91dCBvZiBzY29wZSwgYnV0DQo+IHRoZW4gdGhhdCBhbHNvIG1lYW4gdGhhdCB0 aGUgbW9kZWwgc2hvdWxkIG5vdCBiZSBhcHBsaWVkIHRvDQo+IG9yY2hlc3RyYXRpb24gb2Ygc2Vy dmljZXMgYWNyb3NzIG11bHRpcGxlIG9wZXJhdG9ycy4NCj4gDQo+IE9uIHRoZSBvdGhlciBlbmQs IHRoZXJlIGlzIHRoZSBwYXJ0aWN1bGFyIGlzc3VlIG9mIHRoZSB1bnRydXN0ZWQNCj4gZGV2aWNl Lg0KPiBDb25zaWRlciB0aGUgbm93IGNsYXNzaWMgc2NlbmFyaW8gaW4gd2hpY2ggYXR0YWNrZXJz IG1hbmFnZSB0bw0KPiBvYnRhaW4gdGhlIGNyZWRlbnRpYWwgb2Ygc29tZSBlbXBsb3llZXMgb2Yg dGhlIG9wZXJhdG9yLCBtYXliZQ0KPiB0aHJvdWdoIGEgcGhpc2hpbmcgYXR0YWNrLiBUaGUgYXR0 YWNrZXJzIHRoZW4gdXNlIHRob3NlIGNyZWRlbnRpYWxzDQo+IHRvIGdhaW4gYWNjZXNzIHRvIGEg Y291cGxlIG9mIG5ldHdvcmsgZGV2aWNlcy4gSGF2ZSB5b3UgY29uc2lkZXJlZA0KPiBob3cgdGhl eSBtaWdodCBsZXZlcmFnZSB0aGF0IGFjY2VzcyB0aHJvdWdoIHRoZSBzZXJ2aWNlDQo+IGFyY2hp dGVjdHVyZT8gT3IsIGNvbnZlcnNlbHksIGhhdmUgeW91IGNvbnNpZGVyZWQgd2hldGhlciB0aGUN Cj4gYXJjaGl0ZWN0dXJlIHByb3ZpZGVzIGZ1bmN0aW9ucyBmb3IgdGhlIG9wZXJhdG9yIHRvIGRl dGVjdCBhbmQNCj4gaXNvbGF0ZSBzdWNoIGF0dGFja3M/DQo+IA0KPiA+PiBJbiBhZGRpdGlvbiB0 byB0aHJlZSBjbGFzc2VzIG9mIGlzc3VlcyBsaXN0ZWQgaW4gdGhlIHNlY3VyaXR5DQo+ID4+IGNv bnNpZGVyYXRpb25zLCBJIGFtIGFsc28gY29uY2VybmVkIHdpdGggcG9zc2liaWxpdGllcyBvZg0K PiByZXRhaW5pbmcNCj4gPj4gb3IgZmFsc2lmeWluZyBkYXRhLiBXaGF0IGlmIGFuIGFjdG9yIGhp ZGVzIG9yIGZha2VzIHBlcmZvcm1hbmNlDQo+ID4+IG1vbml0b3JpbmcgZGF0YSwgZWl0aGVyIG91 dCBvZiBtYWxpY2Ugb3IgZHVlIHRvIGZhdWx0eQ0KPiBlcXVpcGVtZW50Pw0KPiA+IFtNZWRdIEFs bCB0aGUgbGV2ZWxzIGFyZSB1bmRlciB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIHNhbWUNCj4g cHJvdmlkZXIuIEFuIHVuZGVybHlpbmcgbGV2ZWwgY2FuIHJlcG9ydCBwZXJmb3JtYW5jZSBkYXRh IGJ1dCB0aGUNCj4gYWJvdmUgbGV2ZWwgY2FuIGFsc28gcHJvY2VlZCB3aXRoIE9BTSBjaGVja3Mg YXMgcGVyIFNlY3Rpb24gNC4xLjQuDQo+IEFub21hbGllcyBjYW4gdGh1cyBiZSBkZXRlY3RlZCBs b2NhbGx5Lg0KPiA+DQo+ID4+IFdpbGwgdGhhdCBkaXNydXB0IHRoZSBwcm92aXNpb24gb2YgdGhl IHNlcnZpY2VzPyBXaGF0IHRvb2xzIGFyZQ0KPiA+PiBhdmFpbGFibGUgdG8gZGV0ZWN0IHN1Y2gg YmVoYXZpb3I/IFdoYXQgaWYgYSBuZXR3b3JrIHByb3ZpZGUNCj4gPj4gb3ZlcnByb21pc2VzLCBp biBvcmRlciB0byBhdHRyYWN0IGNvbnRyYWN0cz8gSSB1bmRlcnN0YW5kIHRoYXQNCj4gdGhlDQo+ ID4+IHVsdGltYXRlIHJlbWVkaWVzIGxpZXMgaW4gY29udHJhY3Qgb2JsaWdhdGlvbnMgYW5kIGNv bnRyYWN0DQo+ID4+IGVuZm9yY2VtZW50LCBidXQgdGhhdCBlbmZvcmNlbWVudCBoYXMgdG8gYmUg YmFzZWQgb24gZGF0YS4gSG93IGlzDQo+IHRoZQ0KPiA+PiBhcmNoaXRlY3R1ciBvcmdhbml6aW5n IHRoZSBjb2xsZWN0aW9uIG9mIHRoZSBkYXRhPw0KPiA+IFtNZWRdIFRoaXMgaXMgdGhlIHJvbGUg b2YgdGhlIGFzc3VyYW5jZSBmdW5jdGlvbnMuIFNlZSBhbHNvIHRoZQ0KPiBORVcgdGV4dCBzdWdn ZXN0ZWQgYWJvdmUuDQo+IFllcywgdGhlIG5ldyB0ZXh0IGlzIHVzZWZ1bC4NCj4gPj4gT24gYSBz aWRlIG5vdGUsIEkgZmluZCB0aGF0IHRoaXMgYXJjaGl0ZWN0dXJlIGNpdGVzIGEgbGFyZ2UNCj4g bnVtYmVyIG9mDQo+ID4+IG90aGVyIGRyYWZ0cyBzdWNoIGFzIGV2cG4sIGwydnBuLCBsM3Zwbiwg ZXRjLiBUaGVzZSBkcmFmdHMgaW4NCj4gdHVybg0KPiA+PiBwcmVzdW1hYmx5IGNpdGUgdGhlIGFy Y2hpdGVjdHVyZSwgdGh1cyBmb3JjaW5nIHRoZSBSRkMgcHJvZHVjdGlvbg0KPiB0bw0KPiA+PiBv cmdhbml6ZSBhbGwgb2YgdGhlbSBpbiBhIGxhcmdlIHB1YmxpY2F0aW9uIGNsdXN0ZXIuDQo+ID4+ IElzIGl0IHJlYWxseSByZXF1aXJlZCBmb3IgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCB0byBj aXRlIGFsbA0KPiB0aGUNCj4gPj4gZG9jdW1lbnRzIHRoYXQgd2lsbCBsYXRlciB1c2UgaXQ/DQo+ ID4gW01lZF0gTm9uZSBvZiB0aGVzZSBkcmFmdHMgaXMgbm9ybWF0aXZlLiBUaGVyZSBpcyBub3Qg cmlzayB0bw0KPiBjcmVhdGUgYSBwdWJsaWNhdGlvbiBjbHVzdGVyLg0KPiANCj4gSSB3aWxsIGxl YXZlIHRoYXQgdG8geW91IGFuZCB0aGUgUkZDIFByb2R1Y3Rpb24gQ2VudGVyLiBUaGF0IHdhcw0K PiBqdXN0IGEgc2lkZSByZW1hcmsuDQo+IA0KPiAtLSBDaHJpc3RpYW4gSHVpdGVtYQ0KPiANCg0K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBx dWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Oct 7 19:48:19 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65953A0E09; Wed, 7 Oct 2020 19:48:17 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hKGOK2vs4Idn; Wed, 7 Oct 2020 19:48:15 -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 740683A0E37; Wed, 7 Oct 2020 19:48:15 -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 0982mAYu025850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 7 Oct 2020 22:48:12 -0400 Date: Wed, 7 Oct 2020 19:48:09 -0700 From: Benjamin Kaduk To: Donald Eastlake Cc: "Wessels, Duane" , secdir , "draft-ietf-dnsop-dns-zone-digest.all@ietf.org" Message-ID: <20201008024809.GS89563@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 02:48:18 -0000 Donald, thanks for the review -- it's always good to see the core agility and algorithm-strength questions well in hand. Duane, thanks for the updates -- as you saw, my discuss points were pretty boring process/mechanical-type stuff, and I'll respond to you shortly. -Ben On Mon, Sep 21, 2020 at 04:35:43PM -0400, Donald Eastlake wrote: > Hi Duane, > > Thanks, looks good to me. I'll check the draft when it comes out. > > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > > On Mon, Sep 21, 2020 at 1:31 PM Wessels, Duane > wrote: > > > Donald, > > > > Thanks again for this draft review and feedback. After discussions among > > the coauthors we have made the further changes that you suggest. Namely: > > > > - minimum digest length of 12 octets > > - added SHA512 as algorithm 2 > > - local policy allows some schemes / algorithms to be ignored > > - implementation status moved to an appendix > > > > I think there are no more outstanding issues. I will be posting an > > updated revision of the draft shortly. > > > > DW > > > > > > > On Sep 15, 2020, at 7:34 PM, Donald Eastlake wrote: > > > > > > Hi Duane, > > > > > > Thanks for accepting most of my suggestions. > > > > > > See my responses below at on the items we are still discussing. > > > > > > On Tue, Sep 15, 2020 at 11:38 AM Wessels, Duane > > wrote: > > > Thanks Don for the extensive review! tl;dr, we did accept most/many of > > your suggestions already, except these items may warrant further discussion: > > > > > > - minimum digest length > > > - more hash algorithms than SHA-384 > > > - local policy when verifying multiple digests > > > - implementation status section > > > > > > More responses inline below. > > > > > > DW > > > > > > > On Sep 12, 2020, at 6:53 PM, Donald Eastlake wrote: > > > > > > > ... > > > > > > > > 2) The minimum size of the Digest Field, 1 octet, seems too small. > > > > Typical minimum size for such a field in IETF protocols seems to be 96 > > > > bits or 12 octets, so that, at least with a strong hash function, you > > > > have a reasonable resistance against brute force attacks. Also, while > > > > it is fairly obvious, you might want to mention how a receiver > > > > determines the length of the Digest Field. > > > > > > > > OLD (Section 2.2.4) > > > > The Digest field must not be empty. > > > > > > > > NEW > > > > The Digest Field MUST NOT be shorter than 12 octets. If it is, the > > > > ZONEMD RR containing that short digest cannot be used to verify a > > > > zone. The length of the digest field is determined by deducting the > > > > fixed size of the Serial, Scheme, and Hash Algorithm fields from the > > > > RDATA size in the ZONEMD RR header. > > > > > > I'm not necessarily opposed to a minimum digest size. Do you envision > > > any complications with private use algorithms though? It seems a little > > > strange to allow private use algorithms whose digest value could be > > anything, > > > but requiring a minimum size (which could then simply be padded I know). > > > > > > Well, it looked to me like the draft already had a minimum Digest > > field, namely one octet, since it said the Digest Field couldn't be empty. > > As I recall, the digest didn't say what to do if the Digest field was zero > > length but I presume it would mean that the ZONEMD RR was malformed and > > thus could not be used to validate a zone. Seems like the minimum length > > would apply to private use algorithms also. See Section 5.2.2.1 of > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09 > > > > > > > 3) SHA384 / algorithm agility > > > > -- here are some thoughts/comments on SHA384 and algorithm agility: > > > ... > > > > > > > > 3c) SHA2-384 is just SHA2-512 with some different initialization > > > > values and with the 512 bit output truncated to 384. Thus the > > > > incremental effort of providing SHA2-512 in tiny if you have SHA2-384 > > > > (and vice versa). So, if SHA2-384 is mandatory, then you might as well > > > > make SHA2-512 mandatory also since you get it for probably <1% > > > > incremental effort. Having two mandatory algorithms with some people > > > > using one and some the other would provide some real confidence that > > > > implementations were actually looking at the Hash Algorithm Field, > > > > could handle Digest Fields of different length, etc., and the > > > > algorithm agility mechanisms might actually work. It currently looks a > > > > bit like only lip service is being paid to algorithm agility. > > > > > > In an earlier version of the draft, four algorithms were defined, > > although > > > none "past" SHA-384. There was a (Oct 2018) discussion to make SHA-384 > > > the mandatory algorithm and drop all the weaker ones. > > > > > > I'm not necessarily opposed to adding more mandatory-to-implement > > algorithms > > > if there is working group consensus about that, but it feels like a > > pretty > > > significant and late change? > > > > > > I agree it is a significant change in the draft. But, as I say, if > > you have SHA-384 you have 99+% of the crypto code you need for SHA-384 and > > SHA-512. Of course, SHA-512 has an even longer value, 64 bytes, but with > > just one or at most a few ZONEMD RRs at the zone apex, that does not seem > > to be a problem. Of my security comments, I rate adding a 2nd hash > > algorithm as the most important. It could be that the 2nd algorithm would > > be a SHOULD rather than a MUST. And, if a second algorithm is added, I > > think SHA-512 would be the easiest for implementers. > > > > > > > 3d) On algorithm agility generally: There is a reasonable provision in > > > > the ZONEMD RR for a hash algorithm identifier. But, given that this > > > > is Standards Track I would have expected there to be hash algorithms > > > > specified of different types with one a MUST implement and one a > > > > SHOULD implement -- possible more but at least that. Blake or SHA3 > > > > would be example of a different algorithm type from SHA2. But I admit > > > > that SHA2-384/512 is very strong and a break in it significant enough > > > > to make much difference seems very unlikely. > > > > > > Same as above. > > > > > > Response above. > > > > > > > 4) There is no mention of local policy. If at some point there are > > > > multiple hash algorithms and/or schemes specified (which could include > > > > private use algorithms and schemes), a ZONEMD zone validator would > > > > likely need a local policy as to which algorithm/scheme digest it will > > > > pay attention to. See, for example, the first paragraph of Section 4 > > > > which assumes any good digest should be good enough to validate the > > > > zone for any verifier. > > > > > > The draft-ietf-dnsop-dns-zone-digest-00 version did have the following > > text that spoke to this: > > > > > > > It is RECOMMENDED that implementations maintain a (possibly > > > > configurable) list of supported Digest Type algorithms ranked from > > > > most to least preferred. It is further RECOMMENDED that recipients > > > > use only their most preferred algorithm that is present in the zone > > > > for digest verification. > > > > > > > > As a matter of local policy, the recipient MAY require that all > > > > supported and present Digest Type algorithms verify the zone. > > > > > > There was a thread on DNSOP where we had agreement to > > > take those two paragraphs out: > > > > > > https://mailarchive.ietf.org/arch/msg/dnsop/RFCklH7Lx00bL-tOVRCAc0j5ftw/ > > > > > > I went and read that thread. I agree that the text removed was kind > > of complex. I was just worried that the text in Section 4 too strongly > > implied that an implementation must accept a zone if a ZONEMD validates. > > True, it does have text about "supporting" the Scheme and Hash Algorithm > > but conceivable you could support a Scheme and a Hash Algorithm but have a > > policy against accepting a ZONEMD RR that combined them and in any case I > > suspect the draft is using "supported" in the sense of "implemented". I'd > > be happy with adding just one sentence in Section 4 something like "The > > verifier MAY ignore a ZONEMD if the Scheme and Hash Algorithm violates > > local policy." > > > ... > > > > 6e. Actually, 240-254 seems like a lot of values for Private Use. Why > > > > would you need 15 private hash algorithms within one administrative > > > > area? If you think there are going to be lots of private/proprietary > > > > hashes (national vanity crypto?) that get used moderately widely, > > > > there should be a provision for "vendor specific" hash algorithms > > > > where the "Digest Field" actually starts with a "vendor" identifier. > > > > > > It seemed a reasonable amount to us, but if others think it should be > > > smaller that shouldn't be a problem. > > > > > > OK. It isn't gigantic or anything, just a bit larger than the 3 or > > 4 or so values I typically see. > > > > > > ... > > > > 12. Having an Implementation Status section (Section 10) is good while > > > > a draft is going through the approval process, but I think it is, as > > > > indicated in RFC 7942, inappropriate in a resulting standards track > > > > RFC. Furthermore, all of the disclaimer text given in RFC 7942 is > > > > missing here. So, I believe similar disclaimer text should be added > > > > and the RFC Editor should be requested to drop this section before > > > > publication. > > > > > > The authors feel it could be useful, even though it is expected to > > > become out-of-date. Looks like some other published RFCs have kept > > > their Implementation Status sections, sometimes as an appendix? > > > > > > OK... I think that if retained it would be much better as an > > appendix. > > > > > > ... > > > > ATTACHMENT > > > > > > > > Taking into account the above and to make other editorial suggestions, > > > > I have done an editing pass over the draft the results of which are > > > > attached. I hope you find it helpful. > > > > > > Thank you, we did find it very helpful. > > > > > > You're welcome. > > > > > > Donald > > > =============================== > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > > d3e3e3@gmail.com > > > > From nobody Wed Oct 7 19:52:31 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC53B3A0E47; Wed, 7 Oct 2020 19:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 (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 OC4B20PWqrjG; Wed, 7 Oct 2020 19:52:27 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 CADA33A0E30; Wed, 7 Oct 2020 19:52:27 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id o9so4363199ilo.0; Wed, 07 Oct 2020 19:52:27 -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=qJqPcqprPFpawvGxgjhI1tzJ1sO4TLiF3taPqBk7KUk=; b=kiZoleo+bmsHoQJP/CpEHOWicR8vLy+KVPzXakYY0Id7HtpbiVtjKOz5GGfCAr8mtz m8eq53FSjMjfHFrAQBtFbvvuaacQS2WoMLZNQ0MYj6G1KO2eSMi6Om2jDdPBE3fQwzL8 k8q35tV7jqjg81iqgTsyB+RLRtmjdpMZ39O9/bRPbtOSxl8oy2Ds32Kewd77zKAW/+2K XPWurIJqKXv/53qVnaOwMNyuDuhUL1eaptydBEl4DUDOi+8yc/yycIJjVvyrOEMAd2No s+0lw8oVwnmNk06jot0TgYLsXUr53/MvPzLBI4WisunF8rp3qBsZQkxkYA6241blMvER 270w== 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=qJqPcqprPFpawvGxgjhI1tzJ1sO4TLiF3taPqBk7KUk=; b=n2hh3rkejNNpA3FeerQiKQ1bQLu0psb+iyjnkw6xZ+xOuWVb+6WHXTo4xmmn/TuD+r rCW5N2Q0TdeRMKijPmlLLljbAQbJ0MMyZEHdn8H2xZ+u2x7VpN8d7vZy8UcssDKKaTdf IP3jC1EH8JofxmnEXXWskeMocqewus403omDf37ItpZfEyb+vGsXShbpPGpeqL7qpNRw koHJv0iFlrntW7ySQInaSixCwELUbzMNBBuhABDiOT5pWZy0gtW0/jwILWmXRMJQWGAX b4sLmY4Rgi5gBHa4tLup9wnTEhKuCFA6tmZF6a9rmvdRxsPFTfayrGiPju+7OUtuKw+P OHpQ== X-Gm-Message-State: AOAM533q0MBB/19amI/Fj6gBZ/fKkGm6Rj2FTXC7CXL9XuelWbrq414N Xc9k+lKTt1OuVHAE+D5Qc2h1pDCqKBYfAMJ589CsVfJ1 X-Google-Smtp-Source: ABdhPJx/JSZ103/DSqh3BP5/yNk2PtRKNC+rjkjFmLoVTrwwYAMzTkTTckhBokev4MwQIJpbQkOJoYyxNgWqOIP4Epk= X-Received: by 2002:a92:a1d1:: with SMTP id b78mr5395088ill.168.1602125546764; Wed, 07 Oct 2020 19:52:26 -0700 (PDT) MIME-Version: 1.0 References: <20201008024809.GS89563@kduck.mit.edu> In-Reply-To: <20201008024809.GS89563@kduck.mit.edu> From: Donald Eastlake Date: Wed, 7 Oct 2020 22:52:15 -0400 Message-ID: To: Benjamin Kaduk Cc: "Wessels, Duane" , secdir , "draft-ietf-dnsop-dns-zone-digest.all@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-dns-zone-digest-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 02:52:30 -0000 You're welcome. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Wed, Oct 7, 2020 at 10:48 PM Benjamin Kaduk wrote: > > Donald, thanks for the review -- it's always good to see the core > agility and algorithm-strength questions well in hand. > > Duane, thanks for the updates -- as you saw, my discuss points were pretty > boring process/mechanical-type stuff, and I'll respond to you shortly. > > -Ben > > On Mon, Sep 21, 2020 at 04:35:43PM -0400, Donald Eastlake wrote: > > Hi Duane, > > > > Thanks, looks good to me. I'll check the draft when it comes out. > > > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > d3e3e3@gmail.com > > > > > > On Mon, Sep 21, 2020 at 1:31 PM Wessels, Duane > > wrote: > > > > > Donald, > > > > > > Thanks again for this draft review and feedback. After discussions among > > > the coauthors we have made the further changes that you suggest. Namely: > > > > > > - minimum digest length of 12 octets > > > - added SHA512 as algorithm 2 > > > - local policy allows some schemes / algorithms to be ignored > > > - implementation status moved to an appendix > > > > > > I think there are no more outstanding issues. I will be posting an > > > updated revision of the draft shortly. > > > > > > DW > > > > > > > > > > On Sep 15, 2020, at 7:34 PM, Donald Eastlake wrote: > > > > > > > > Hi Duane, > > > > > > > > Thanks for accepting most of my suggestions. > > > > > > > > See my responses below at on the items we are still discussing. > > > > > > > > On Tue, Sep 15, 2020 at 11:38 AM Wessels, Duane > > > wrote: > > > > Thanks Don for the extensive review! tl;dr, we did accept most/many of > > > your suggestions already, except these items may warrant further discussion: > > > > > > > > - minimum digest length > > > > - more hash algorithms than SHA-384 > > > > - local policy when verifying multiple digests > > > > - implementation status section > > > > > > > > More responses inline below. > > > > > > > > DW > > > > > > > > > On Sep 12, 2020, at 6:53 PM, Donald Eastlake wrote: > > > > > > > > > ... > > > > > > > > > > 2) The minimum size of the Digest Field, 1 octet, seems too small. > > > > > Typical minimum size for such a field in IETF protocols seems to be 96 > > > > > bits or 12 octets, so that, at least with a strong hash function, you > > > > > have a reasonable resistance against brute force attacks. Also, while > > > > > it is fairly obvious, you might want to mention how a receiver > > > > > determines the length of the Digest Field. > > > > > > > > > > OLD (Section 2.2.4) > > > > > The Digest field must not be empty. > > > > > > > > > > NEW > > > > > The Digest Field MUST NOT be shorter than 12 octets. If it is, the > > > > > ZONEMD RR containing that short digest cannot be used to verify a > > > > > zone. The length of the digest field is determined by deducting the > > > > > fixed size of the Serial, Scheme, and Hash Algorithm fields from the > > > > > RDATA size in the ZONEMD RR header. > > > > > > > > I'm not necessarily opposed to a minimum digest size. Do you envision > > > > any complications with private use algorithms though? It seems a little > > > > strange to allow private use algorithms whose digest value could be > > > anything, > > > > but requiring a minimum size (which could then simply be padded I know). > > > > > > > > Well, it looked to me like the draft already had a minimum Digest > > > field, namely one octet, since it said the Digest Field couldn't be empty. > > > As I recall, the digest didn't say what to do if the Digest field was zero > > > length but I presume it would mean that the ZONEMD RR was malformed and > > > thus could not be used to validate a zone. Seems like the minimum length > > > would apply to private use algorithms also. See Section 5.2.2.1 of > > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2845bis-09 > > > > > > > > > 3) SHA384 / algorithm agility > > > > > -- here are some thoughts/comments on SHA384 and algorithm agility: > > > > ... > > > > > > > > > > 3c) SHA2-384 is just SHA2-512 with some different initialization > > > > > values and with the 512 bit output truncated to 384. Thus the > > > > > incremental effort of providing SHA2-512 in tiny if you have SHA2-384 > > > > > (and vice versa). So, if SHA2-384 is mandatory, then you might as well > > > > > make SHA2-512 mandatory also since you get it for probably <1% > > > > > incremental effort. Having two mandatory algorithms with some people > > > > > using one and some the other would provide some real confidence that > > > > > implementations were actually looking at the Hash Algorithm Field, > > > > > could handle Digest Fields of different length, etc., and the > > > > > algorithm agility mechanisms might actually work. It currently looks a > > > > > bit like only lip service is being paid to algorithm agility. > > > > > > > > In an earlier version of the draft, four algorithms were defined, > > > although > > > > none "past" SHA-384. There was a (Oct 2018) discussion to make SHA-384 > > > > the mandatory algorithm and drop all the weaker ones. > > > > > > > > I'm not necessarily opposed to adding more mandatory-to-implement > > > algorithms > > > > if there is working group consensus about that, but it feels like a > > > pretty > > > > significant and late change? > > > > > > > > I agree it is a significant change in the draft. But, as I say, if > > > you have SHA-384 you have 99+% of the crypto code you need for SHA-384 and > > > SHA-512. Of course, SHA-512 has an even longer value, 64 bytes, but with > > > just one or at most a few ZONEMD RRs at the zone apex, that does not seem > > > to be a problem. Of my security comments, I rate adding a 2nd hash > > > algorithm as the most important. It could be that the 2nd algorithm would > > > be a SHOULD rather than a MUST. And, if a second algorithm is added, I > > > think SHA-512 would be the easiest for implementers. > > > > > > > > > 3d) On algorithm agility generally: There is a reasonable provision in > > > > > the ZONEMD RR for a hash algorithm identifier. But, given that this > > > > > is Standards Track I would have expected there to be hash algorithms > > > > > specified of different types with one a MUST implement and one a > > > > > SHOULD implement -- possible more but at least that. Blake or SHA3 > > > > > would be example of a different algorithm type from SHA2. But I admit > > > > > that SHA2-384/512 is very strong and a break in it significant enough > > > > > to make much difference seems very unlikely. > > > > > > > > Same as above. > > > > > > > > Response above. > > > > > > > > > 4) There is no mention of local policy. If at some point there are > > > > > multiple hash algorithms and/or schemes specified (which could include > > > > > private use algorithms and schemes), a ZONEMD zone validator would > > > > > likely need a local policy as to which algorithm/scheme digest it will > > > > > pay attention to. See, for example, the first paragraph of Section 4 > > > > > which assumes any good digest should be good enough to validate the > > > > > zone for any verifier. > > > > > > > > The draft-ietf-dnsop-dns-zone-digest-00 version did have the following > > > text that spoke to this: > > > > > > > > > It is RECOMMENDED that implementations maintain a (possibly > > > > > configurable) list of supported Digest Type algorithms ranked from > > > > > most to least preferred. It is further RECOMMENDED that recipients > > > > > use only their most preferred algorithm that is present in the zone > > > > > for digest verification. > > > > > > > > > > As a matter of local policy, the recipient MAY require that all > > > > > supported and present Digest Type algorithms verify the zone. > > > > > > > > There was a thread on DNSOP where we had agreement to > > > > take those two paragraphs out: > > > > > > > > https://mailarchive.ietf.org/arch/msg/dnsop/RFCklH7Lx00bL-tOVRCAc0j5ftw/ > > > > > > > > I went and read that thread. I agree that the text removed was kind > > > of complex. I was just worried that the text in Section 4 too strongly > > > implied that an implementation must accept a zone if a ZONEMD validates. > > > True, it does have text about "supporting" the Scheme and Hash Algorithm > > > but conceivable you could support a Scheme and a Hash Algorithm but have a > > > policy against accepting a ZONEMD RR that combined them and in any case I > > > suspect the draft is using "supported" in the sense of "implemented". I'd > > > be happy with adding just one sentence in Section 4 something like "The > > > verifier MAY ignore a ZONEMD if the Scheme and Hash Algorithm violates > > > local policy." > > > > ... > > > > > 6e. Actually, 240-254 seems like a lot of values for Private Use. Why > > > > > would you need 15 private hash algorithms within one administrative > > > > > area? If you think there are going to be lots of private/proprietary > > > > > hashes (national vanity crypto?) that get used moderately widely, > > > > > there should be a provision for "vendor specific" hash algorithms > > > > > where the "Digest Field" actually starts with a "vendor" identifier. > > > > > > > > It seemed a reasonable amount to us, but if others think it should be > > > > smaller that shouldn't be a problem. > > > > > > > > OK. It isn't gigantic or anything, just a bit larger than the 3 or > > > 4 or so values I typically see. > > > > > > > > ... > > > > > 12. Having an Implementation Status section (Section 10) is good while > > > > > a draft is going through the approval process, but I think it is, as > > > > > indicated in RFC 7942, inappropriate in a resulting standards track > > > > > RFC. Furthermore, all of the disclaimer text given in RFC 7942 is > > > > > missing here. So, I believe similar disclaimer text should be added > > > > > and the RFC Editor should be requested to drop this section before > > > > > publication. > > > > > > > > The authors feel it could be useful, even though it is expected to > > > > become out-of-date. Looks like some other published RFCs have kept > > > > their Implementation Status sections, sometimes as an appendix? > > > > > > > > OK... I think that if retained it would be much better as an > > > appendix. > > > > > > > > ... > > > > > ATTACHMENT > > > > > > > > > > Taking into account the above and to make other editorial suggestions, > > > > > I have done an editing pass over the draft the results of which are > > > > > attached. I hope you find it helpful. > > > > > > > > Thank you, we did find it very helpful. > > > > > > > > You're welcome. > > > > > > > > Donald > > > > =============================== > > > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > > > d3e3e3@gmail.com > > > > > > > From nobody Thu Oct 8 12:28:31 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E47203A0C5F for ; Thu, 8 Oct 2020 12:28:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160218530945.17713.8539842511462652266@ietfa.amsl.com> Date: Thu, 08 Oct 2020 12:28:29 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 19:28:30 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-10-08 Reviewer LC end Draft Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-07 Last calls: Reviewer LC end Draft Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-09 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-07 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-11 Phillip Hallam-Baker R2020-03-09 draft-ietf-calext-jscalendar-31 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-26 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-10 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-19 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-11 David Mandelberg 2020-07-14 draft-ietf-idr-rfc8203bis-07 Catherine Meadows 2020-10-21 draft-ietf-6lo-blemesh-08 Alexey Melnikov 2020-10-21 draft-ietf-idr-flow-spec-v6-15 Daniel Migault 2020-10-19 draft-ietf-bess-mvpn-fast-failover-11 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-12 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Yaron Sheffer R2020-10-16 draft-ietf-tls-exported-authenticator-13 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-11 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-12 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Early review requests: Reviewer Due Draft David Mandelberg 2020-10-26 draft-ietf-lisp-nexagon-04 Next in the reviewer rotation: Yoav Nir Magnus Nystrom Hilarie Orman Francesca Palombini Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey From nobody Thu Oct 8 13:20:15 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07D3A0D07; Thu, 8 Oct 2020 13:20:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-idr-rfc8203bis.all@ietf.org, idr@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160218840397.1302.88701008790572541@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Thu, 08 Oct 2020 13:20:04 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-rfc8203bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 20:20:04 -0000 Reviewer: David Mandelberg Review result: Ready 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 Ready. The document seems pretty straightforward from a security perspective, and the Security Considerations section looks good. From nobody Thu Oct 8 13:21:25 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3CE3A0D3A; Thu, 8 Oct 2020 13:21:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-lisp-nexagon.all@ietf.org, lisp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160218848061.12936.5873889616190686198@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Thu, 08 Oct 2020 13:21:20 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 20:21:21 -0000 Reviewer: David Mandelberg Review result: Not Ready 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 Not ready. If I understand correctly, 64-bit Client EIDs serve as both identification and authentication for a client. How many clients will an EdgeRTR know about at a single time? How many EIDs can an attacker guess per second? If an attacker can guess 1024 EIDs per second, and there are 2^32 valid EIDs, I think that would mean it would take about 24 days on average to guess a (non-specific) EID. Are my numbers off? Is that acceptable? How does the Client XTR verify the authenticity of the data coming from Server XTRs? Is it relying on infrastructure security in the LISP and server networks, and the obscurity of its own Client EID? E.g., if a non-participant in the LISP network can get the Client EID and RLOC (e.g., by sniffing packets), could they spoof an unsolicited multicast packet to the client? If the above is possible, I think this part of the Security Considerations section should be fleshed out more, and possibly made mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is tunneled and its UDP content may be encrypted" The Security Considerations section says "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations" but as far as I can tell, that's the first mention of any mandatory encryption of H3-R15 information. How does that encryption work? I assume it wouldn't be that hard for an attacker to get legitimate access to a Mobility Client (e.g., by buying a car). What would stop them from sending the type of "fake-news" updates the Security Considerations section talks about? From nobody Fri Oct 9 07:48:16 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233313A0906 for ; Fri, 9 Oct 2020 07:48:10 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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=getnexar.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 DLZnL7sDWBbi for ; Fri, 9 Oct 2020 07:48:07 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 9086A3A08C7 for ; Fri, 9 Oct 2020 07:48:07 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id j136so10106735wmj.2 for ; Fri, 09 Oct 2020 07:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=OVaKnSw78Bey0krEm5EUwIVDmpfWcOeFs3g22j2lrXs=; b=mhmpaFxE0bdOw2eVrs3DFShnJieZhOlxnuiVy6c/PtaeFzxi/ioHlPU0CbKsglkgz/ PXzdE4Q63URxjUj6CcGhGM7XV1zBbbRplE/zPllmonrDD00zbzO57LA4DteyPVCz0HFk cbBBdI97/5xK+vgIRwkLjTHhaPkSq4ceGw/rw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=OVaKnSw78Bey0krEm5EUwIVDmpfWcOeFs3g22j2lrXs=; b=hGreTFLDu1vLQ6KWRXg2hkh6ksmncesDkKsaDk2jck2TetG5RNgAtHfHjP4Dk8FyaX 22gZ8qHWNhBgkjAsvXd1fiv/SEamzctJTJ6/akfUQ2rXiIAOaZb1HK+5VhHxg0cWJ+Sn l4k+4s9TAxXEkRtHC2aH7whdyDTLjDd1e3/ymnr9kOuUmhYkg0F79WLhqTm5NMZbdZQB EAeE7+sByMrjih2ppCJSVnpeF2yutX1ApBTzpHOBPdxmMERMRYxdd05tlFCWj8hm4cxZ 7ubqmleJVsFqOMoPN2zWpId2BPY5Oqaz0ZfsOXVyBoORgK1hb295jmSTp6G1Zjvsnv7p ZUdw== X-Gm-Message-State: AOAM532JIZLkB8A06C5Nft6jRGo1Jdrf2t1FlRMmpQtLf97l6KzY/6ZA KpJjPvpxpHMG7Au85fdRiGkZ3A== X-Google-Smtp-Source: ABdhPJz4mM8R1NHY2FebAE7xit2KSCKmn/Ga0piafoXCIYaoIDYHxLjqALWWefE7TSeEHr4yBJ7pvw== X-Received: by 2002:a1c:960a:: with SMTP id y10mr14242305wmd.128.1602254885821; Fri, 09 Oct 2020 07:48:05 -0700 (PDT) Received: from ?IPv6:2a02:14c:3cf:3500:1d1d:fa3d:2d38:7809? ([2a02:14c:3cf:3500:1d1d:fa3d:2d38:7809]) by smtp.gmail.com with ESMTPSA id a3sm11744685wmb.46.2020.10.09.07.48.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2020 07:48:05 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-07DEBE42-3A3B-448C-9805-FD066C8166A9 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Sharon Barkai In-Reply-To: <160218848061.12936.5873889616190686198@ietfa.amsl.com> Date: Fri, 9 Oct 2020 17:48:03 +0300 Cc: secdir@ietf.org, lisp@ietf.org, draft-ietf-lisp-nexagon.all@ietf.org Message-Id: <90E55F95-C6BB-4D30-814B-ECDF0CDC990A@getnexar.com> References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> To: Tero Kivinen X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 14:48:10 -0000 --Apple-Mail-07DEBE42-3A3B-448C-9805-FD066C8166A9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tero, really want to thank you for putting in the time, you clearly understo= od the draft completely and point to areas we invested thought on but can im= prove the wording. Before adjusting the draft would like to rehash together with the group, Joe= l, and Luigi the themes pointed, which are spot on, so to reach the best pos= sible language.=20 1) End to end encryption - Nexagon uses LISP tunnels end to end: - between EIDClients and EdgeRTRs - between ingress and egress EdgeRTR - between EdgeRTRs and H3EIDServices Depending on the specific nexagon network as service offered we would like t= o offer the option to encrypt all communications on these tunnels. We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies RFC2631 ke= y exchange over LISP tunnels, also DTLS was suggested. Should we determine one or just describe the geo privacy and commercial expo= sure if encryption is not used, especially on the tunnels between MobilityEI= DClients and EdgeRTRs? 2) Spoofing and imposters -=20 EdgeRTRs and H3EIDServices are provisioned in the service provider edge netw= ork. EdgeRTRs which are added to the network are provisioned with the mappin= g system, H3EIDServices are whitelist provisioned with their designated Edge= RTRs. We rely on the edge network routers to detect and stop spoofing using indust= ry standard double-lookup source/dest mechanisms. Should we state so? The MobilityEIDClients are behind mobile access networks and go through AAA s= tep before receiving ephemeral EIDs and EdgeRTR RLOCs as anchors.=20 This EID is based on their client ID credentials, and this EID is whitelist p= rovisioned by the AAA to the EdgeRTR given to the client as an anchor.=20 The ipv6 EIDs given to these clients reflect their credibility reputation an= d authorization level to pub-sub into the nexagon network. It is going to be= very hard to guess a valid EIDClient which an EdgeRTR expects after AAA to w= hitelist provision. These EIDs are temporary and expire after 15 minutes. Spoofed EIDClients which are sniffed are going to be detected by the EdgeRTR= s because of mismatched client RLOC. Spoofed client RLOCs are detected by th= e mobile packet core. Should we detail these aspects in security considerations ?=20 3) Fake news and client trust - This is a higher level concern as it is with many other protocols. Privacy a= nd reputation require trade-offs. The lisp-nexagon network uses crowd-source= d street sampling to reflect current geo-state. Even the most honest client m= ay still be wrong, have faulty vision gear, gps interruption, or buggy AI. M= alicious clients may try to manipulate geo-state to their advantage, clear t= heir path from traffic, or simply try to saw confusion.=20 For this reason all detections are corroborated and trust level of each clie= nt is constantly scored by the H3EIDServices and updates the AAA system. Thi= s credit score update reflects the behavior of the assigned ephemeral clien= t EID not the client, a car for ecample. But the AAA system knows which clie= nt ID credentials the EID map to. The AAA system does not need to know the g= eo association of these EID scores. They can be aggregated from all H3EIDSer= vices before handed to AAA. We can describe this general behavior even though its part of management and= orchestration and not part of the LISP-Nexagon interface specification. =20= After we clear these 3 key items to everyone satisfaction we can quickly tur= n around the doc to one more iteration.=20 Thank you in advance! --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker w= rote: >=20 > =EF=BB=BFReviewer: David Mandelberg > Review result: Not Ready >=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 Not ready. >=20 > If I understand correctly, 64-bit Client EIDs serve as both=20 > identification and authentication for a client. How many clients will an=20= > EdgeRTR know about at a single time? How many EIDs can an attacker guess=20= > per second? If an attacker can guess 1024 EIDs per second, and there are=20= > 2^32 valid EIDs, I think that would mean it would take about 24 days on=20= > average to guess a (non-specific) EID. Are my numbers off? Is that=20 > acceptable? >=20 > How does the Client XTR verify the authenticity of the data coming from=20= > Server XTRs? Is it relying on infrastructure security in the LISP and=20 > server networks, and the obscurity of its own Client EID? E.g., if a=20 > non-participant in the LISP network can get the Client EID and RLOC=20 > (e.g., by sniffing packets), could they spoof an unsolicited multicast=20 > packet to the client? >=20 > If the above is possible, I think this part of the Security=20 > Considerations section should be fleshed out more, and possibly made=20 > mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is=20 > tunneled and its UDP content may be encrypted" >=20 > The Security Considerations section says "The H3ServiceEIDs themselves=20 > decrypt and parse actual H3-R15 annotations" but as far as I can tell,=20 > that's the first mention of any mandatory encryption of H3-R15=20 > information. How does that encryption work? >=20 > I assume it wouldn't be that hard for an attacker to get legitimate=20 > access to a Mobility Client (e.g., by buying a car). What would stop=20 > them from sending the type of "fake-news" updates the Security=20 > Considerations section talks about? >=20 >=20 >=20 >=20 --Apple-Mail-07DEBE42-3A3B-448C-9805-FD066C8166A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Tero, really want to thank you for putting in t= he time, you clearly understood the draft completely and point to areas we i= nvested thought on but can improve the wording.

Before adjusting the draft w= ould like to rehash together with the group, Joel, and Luigi the themes poin= ted, which are spot on, so to reach the best possible language. 
<= div style=3D"direction: ltr;">

<= /div>
1) End to end encryption -

Nexagon uses LISP tunnels end to end:
- betwee= n EIDClients and EdgeRTRs
- between ingress and egre= ss EdgeRTR
- between EdgeRTRs and H3EIDServices

Depending on the specific  nexagon network as service offered we wou= ld like to offer the option to encrypt all communications on these tunnels.<= /div>

We could suggest IPSec, dra= ft-ietf-lisp-crypto-10 which specifies RFC2631 key exchange over LISP tunnel= s, also DTLS was suggested.

Should we det= ermine one or just describe the geo privacy and commercial exposure if encry= ption is not used, especially on the tunnels between MobilityEIDClients and E= dgeRTRs?

2) Spoofing and imposters - = ;

EdgeRTRs and H= 3EIDServices are provisioned in the service provider edge network. EdgeRTRs w= hich are added to the network are provisioned with the mapping system, H3EID= Services are whitelist provisioned with their designated EdgeRTRs.
We rely on the edge network routers t= o detect and stop spoofing using industry standard double-lookup source/dest=  mechanisms.
Should we stat= e so?

= The MobilityEIDClients are b= ehind mobile access networks and go through AAA step before receiving epheme= ral EIDs and EdgeRTR  RLOCs as anchors. 

This EID is based on their client ID credentials, and this EID is w= hitelist provisioned by the AAA to the EdgeRTR given to the client as an anc= hor. 

The ipv6 EIDs given to these c= lients reflect their credibility reputation and authorization level to pub-s= ub into the nexagon network. It is going to be very hard to guess a valid EIDClient which an= EdgeRTR expects after AAA to whitelist provision. These EIDs are temporary a= nd expire after 15 minutes.

Spoofed EIDCl= ients which are sniffed are going to be detected by the EdgeRTRs because of m= ismatched client RLOC. Spoofed client RLOCs are detected by the mobile packe= t core.

Should we detail these aspects in security considerations ?&= nbsp;

= 3) Fake news and client trus= t -

This is a higher level concern as it i= s with many other protocols. Privacy and reputation require trade-offs. = ;The lisp-nexagon network us= es crowd-sourced street sampling to reflect current geo-state. Even the most= honest client may still be wrong, have faulty vision gear, gps interruption= , or buggy AI. Malicious clients may try to manipulate geo-state to their ad= vantage, clear their path from traffic, or simply try to saw confusion. = ;

For this reason all detections are corr= oborated and trust level of each client is constantly scored by the H3EIDSer= vices and updates the AAA system. This credit score update reflects the beha= vior of  the assigned ephemeral client EID not the client, a car for ec= ample. But the AAA system knows which client ID credentials the EID map to. T= he AAA system does not need to know the geo association of these EID scores.= They can be aggregated from all H3EIDServices before handed to AAA.<= /div>

We can describe this general behavior even thoug= h its part of management and orchestration and not part of the LISP-Nexagon i= nterface specification.   

After we clear these 3 key items to everyone satisfaction we c= an quickly turn around the doc to one more iteration. 

Thank you in adva= nce!


--sz= b
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794
<= div dir=3D"ltr">
On Oct 8, 2020, at 23:21, Tero= Kivinen via Datatracker <noreply@ietf.org> wrote:

=EF=BB=BFReviewer: D= avid Mandelberg
Review result: Not Ready

I have reviewed this document as part of the security director= ate's
ongoing effort to review all IETF documents being proc= essed by the
IESG.  These comments were written primari= ly for the benefit of the
security area directors.  Doc= ument editors and WG chairs should treat
these comments just= like any other last call comments.

The sum= mary of the review is Not ready.

If I under= stand correctly, 64-bit Client EIDs serve as both
identific= ation and authentication for a client. How many clients will an
<= span>EdgeRTR know about at a single time? How many EIDs can an attacker gues= s
per second? If an attacker can guess 1024 EIDs per second= , and there are
2^32 valid EIDs, I think that would mean it= would take about 24 days on
average to guess a (non-specif= ic) EID. Are my numbers off? Is that
acceptable?
=
How does the Client XTR verify the authenticity of th= e data coming from
Server XTRs? Is it relying on infrastruc= ture security in the LISP and
server networks, and the obsc= urity of its own Client EID? E.g., if a
non-participant in t= he LISP network can get the Client EID and RLOC
(e.g., by s= niffing packets), could they spoof an unsolicited multicast
packet to the client?

If the above is poss= ible, I think this part of the Security
Considerations sect= ion should be fleshed out more, and possibly made
mandatory= : "The traffic on the MobilityClient<>EdgeRTR interface is
= tunneled  and its UDP content may be encrypted"
<= /span>
The Security Considerations section says "The H3ServiceEIDs t= hemselves
decrypt and parse actual H3-R15 annotations" but a= s far as I can tell,
that's the first mention of any mandat= ory encryption of H3-R15
information. How does that encrypt= ion work?

I assume it wouldn't be that hard= for an attacker to get legitimate
access to a Mobility Cli= ent (e.g., by buying a car). What would stop
them from send= ing the type of "fake-news" updates the Security
Considerat= ions section talks about?


=

= --Apple-Mail-07DEBE42-3A3B-448C-9805-FD066C8166A9-- From nobody Fri Oct 9 10:32:52 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D893A0D4C for ; Fri, 9 Oct 2020 10:32:50 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=getnexar.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 KFVEzX3xyU4f for ; Fri, 9 Oct 2020 10:32:48 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 B90EA3A0D4A for ; Fri, 9 Oct 2020 10:32:47 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id t9so11110332wrq.11 for ; Fri, 09 Oct 2020 10:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=zQoHOlWpVXrT9ducAUYzvT59xPQJ+u4tcjPORX1FXZY=; b=JKVr+IaXd7J4XMURdFBsbVjzDcN5cLiWbTPQWuLfALB1ZHWgY81MySzMUHt+ME5Uoa VTtsWWw0t4oO+XnP/+Zf1wRti/Pbimqdm9N4fhfq5gCZNpUiqjI5dH9jO4mlXNSPZvU3 CRLy6ewYg9zxeuLudyPCV0B4/xYJZ1i4lw2FA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=zQoHOlWpVXrT9ducAUYzvT59xPQJ+u4tcjPORX1FXZY=; b=oYGFMRgP1pv+wndoVk5inQ9yBLZvXfNHnwq0KfJ84W0h/AlDsiXupwYE/WGDiF25l/ OPiZ+KeOtV2BvuvLiLDYyCrr2PxpzqCRmoDajqiofpivqxhTEu8geAATyhZnhXOUcgr8 yCNUNce5+1CJq7Tls9BNDQkAtpUKAXrN7TgxSEoa5qW6PaRAv+KKjte1nPsdt6m++TDB qIvc2WcUoYegtRQr4ulJ9drdOP0uTonHtdhkwMXeqw706JcOxLO+XD864MjNVqV/YQPc y6CzOJJGodJKBo/CEsyO0OekHiPCcHRiVJi/TrCf04MjI/psgQrT+zAJcfpRGyjyp+Ti mhNQ== X-Gm-Message-State: AOAM532iGQtET2RhsWOhEXHxC3DdODFGtGpfe1BLa+LNWD8lRWJN9rqZ qTIN2vlH2s0Ixu3x4UKOWtfE7g== X-Google-Smtp-Source: ABdhPJz+6kmdgXZOVwfhVg79ZClRidIvKJlvmMjE6DFtnJgrB/csm0ZCFW+E92iDLklOwUorHZujUQ== X-Received: by 2002:adf:9282:: with SMTP id 2mr15578691wrn.43.1602264765825; Fri, 09 Oct 2020 10:32:45 -0700 (PDT) Received: from ?IPv6:2a02:14c:3cf:3500:1d1d:fa3d:2d38:7809? ([2a02:14c:3cf:3500:1d1d:fa3d:2d38:7809]) by smtp.gmail.com with ESMTPSA id h3sm8200167wrw.78.2020.10.09.10.32.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Oct 2020 10:32:45 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-D951ED4D-6682-478F-AB05-8AA66F5D24E2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Sharon Barkai In-Reply-To: <160218848061.12936.5873889616190686198@ietfa.amsl.com> Date: Fri, 9 Oct 2020 20:32:44 +0300 Cc: secdir@ietf.org, lisp@ietf.org, draft-ietf-lisp-nexagon.all@ietf.org Message-Id: <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> To: Tero Kivinen X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:32:50 -0000 --Apple-Mail-D951ED4D-6682-478F-AB05-8AA66F5D24E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry for the confusion, David! really want to thank you for putting in the t= ime, you clearly understood the draft completely and point to areas we inves= ted thought on but can improve the wording. Before adjusting the draft would like to rehash together with the group, Joe= l, and Luigi the themes pointed, which are spot on, so to reach the best pos= sible language.=20 1) End to end encryption - Nexagon uses LISP overlay encapsulations end to end: - between EIDClients and EdgeRTRs - between ingress and egress EdgeRTR - between EdgeRTRs and H3EIDServices Depending on the specific nexagon as service we would like to offer the opt= ion to encrypt all communications on these dynamic encapsulations. We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies RFC2631 ke= y exchange over LISP tunnels, also DTLS was suggested. Should we determine one or just describe the geo privacy and commercial expo= sure if encryption is not used, especially on the tunnels between MobilityEI= DClients and EdgeRTRs? 2) Spoofing and imposters -=20 EdgeRTRs and H3EIDServices are provisioned in the service provider edge netw= ork. EdgeRTRs which are added to the network are provisioned with the mappin= g system, H3EIDServices are whitelist provisioned with their designated Edge= RTRs. We rely on the edge network routers to detect and stop spoofing using indust= ry standard double-lookup source/dest mechanisms. Should we state so? The MobilityEIDClients are behind mobile access networks and go through AAA s= tep before receiving ephemeral EIDs and EdgeRTR RLOCs as anchors.=20 This EID is based on their client ID credentials, and this EID is whitelist p= rovisioned by the AAA to the EdgeRTR given to the client as an anchor.=20 The ipv6 EIDs given to these clients reflect their credibility reputation an= d authorization level to pub-sub into the nexagon network.=20 It is going to be very hard to guess a valid EIDClient which an EdgeRTR expe= cts after AAA to whitelist provision. These EIDs are temporary and expire af= ter 15 minutes. Spoofed EIDClients which are sniffed are going to be detected by the EdgeRTR= s because of mismatched client RLOC. Spoofed client RLOCs are detected by th= e mobile packet core. Should we detail these aspects in security considerations ?=20 3) Fake news and client trust - This is a higher level concern as it is with many other protocols. Privacy a= nd reputation require trade-offs. The lisp-nexagon network uses crowd-source= d street sampling to reflect current geo-state. Even the most honest client m= ay still be wrong, have faulty vision gear, gps interruption, or buggy AI. M= alicious clients may try to manipulate geo-state to their advantage, clear t= heir path from traffic, or simply try to saw confusion.=20 For this reason all detections are corroborated and trust level of each clie= nt is constantly scored by the H3EIDServices and updates the AAA system. Thi= s credit score update reflects the behavior of the assigned ephemeral clien= t EID not the client, a car for ecample. But the AAA system knows which clie= nt ID credentials the EID map to. The AAA system does not need to know the g= eo association of these EID scores. They can be aggregated from all H3EIDSer= vices before handed to AAA. We can describe this general behavior even though its part of management and= orchestration and not part of the LISP-Nexagon interface specification. =20= After we clear these 3 key items to everyone satisfaction we can quickly tur= n around the doc to one more iteration.=20 Thank you in advance! --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker w= rote: >=20 > =EF=BB=BFReviewer: David Mandelberg > Review result: Not Ready >=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 Not ready. >=20 > If I understand correctly, 64-bit Client EIDs serve as both=20 > identification and authentication for a client. How many clients will an=20= > EdgeRTR know about at a single time? How many EIDs can an attacker guess=20= > per second? If an attacker can guess 1024 EIDs per second, and there are=20= > 2^32 valid EIDs, I think that would mean it would take about 24 days on=20= > average to guess a (non-specific) EID. Are my numbers off? Is that=20 > acceptable? >=20 > How does the Client XTR verify the authenticity of the data coming from=20= > Server XTRs? Is it relying on infrastructure security in the LISP and=20 > server networks, and the obscurity of its own Client EID? E.g., if a=20 > non-participant in the LISP network can get the Client EID and RLOC=20 > (e.g., by sniffing packets), could they spoof an unsolicited multicast=20 > packet to the client? >=20 > If the above is possible, I think this part of the Security=20 > Considerations section should be fleshed out more, and possibly made=20 > mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is=20 > tunneled and its UDP content may be encrypted" >=20 > The Security Considerations section says "The H3ServiceEIDs themselves=20 > decrypt and parse actual H3-R15 annotations" but as far as I can tell,=20 > that's the first mention of any mandatory encryption of H3-R15=20 > information. How does that encryption work? >=20 > I assume it wouldn't be that hard for an attacker to get legitimate=20 > access to a Mobility Client (e.g., by buying a car). What would stop=20 > them from sending the type of "fake-news" updates the Security=20 > Considerations section talks about? >=20 >=20 >=20 >=20 --Apple-Mail-D951ED4D-6682-478F-AB05-8AA66F5D24E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sorry for the confusion, David! really want to thank you= for putting in the time, you clearly understood the draft completely and po= int to areas we invested thought on but can improve the wording.

Before adjusting the d= raft would like to rehash together with the group, Joel, and Luigi the theme= s pointed, which are spot on, so to reach the best possible language. <= /div>


<= div style=3D"-webkit-text-size-adjust: auto; direction: ltr;">1) End to end e= ncryption -

Nexagon uses LISP overlay encapsulations end to end:
-= between EIDClients and EdgeRTRs
- between ingress and egress EdgeRTR
= - between EdgeRTRs and H3EIDServices

Depending on the specific  nexagon as service= we would like to offer the option to encrypt all communications on these dy= namic encapsulations.

We could suggest IPSec, draft-ietf-lisp-crypto-10 which spec= ifies RFC2631 key exchange over LISP tunnels, also DTLS was suggested.
=

Should we determ= ine one or just describe the geo privacy and commercial exposure if encrypti= on is not used, especially on the tunnels between MobilityEIDClients and Edg= eRTRs?
<= br>
2) S= poofing and imposters - 

EdgeRTRs and H3EIDServices are provisioned in the s= ervice provider edge network. EdgeRTRs which are added to the network are pr= ovisioned with the mapping system, H3EIDServices are whitelist provisioned w= ith their designated EdgeRTRs.

We rely on the edge network routers to= detect and stop spoofing using industry standard double-lookup source/dest &= nbsp;mechanisms.
Should we state so?

The MobilityEIDClients are behind mobile= access networks and go through AAA step before receiving ephemeral EIDs and= EdgeRTR  RLOCs as anchors. 

This EID is based on their client ID credentials= , and this EID is whitelist provisioned by the AAA to the EdgeRTR given to t= he client as an anchor. 

The ipv6 EIDs given to these clients reflect their credib= ility reputation and authorization level to pub-sub into the nexagon network= . 
=
It i= s going to be very hard to guess a valid EIDClient which an EdgeRTR expects a= fter AAA to whitelist provision. These EIDs are temporary and expire after 1= 5 minutes.

= Spoofed EIDClients which are sniffed are going to be detected by the EdgeRTR= s because of mismatched client RLOC. Spoofed client RLOCs are detected by th= e mobile packet core.

Should we detail these aspects in security considerations ? =

3) Fake news and client trust -

This is a higher level concer= n as it is with many other protocols. Privacy and reputation require trade-o= ffs. The lisp-nexagon network uses crowd-sourced street sampling to ref= lect current geo-state. Even the most honest client may still be wrong, have= faulty vision gear, gps interruption, or buggy AI. Malicious clients may tr= y to manipulate geo-state to their advantage, clear their path from traffic,= or simply try to saw confusion. 

For this reason all detections are corroborated a= nd trust level of each client is constantly scored by the H3EIDServices and u= pdates the AAA system. This credit score update reflects the behavior of &nb= sp;the assigned ephemeral client EID not the client, a car for ecample. But t= he AAA system knows which client ID credentials the EID map to. The AAA syst= em does not need to know the geo association of these EID scores. They can b= e aggregated from all H3EIDServices before handed to AAA.

We can describe this general b= ehavior even though its part of management and orchestration and not part of= the LISP-Nexagon interface specification.   

After we clear these 3 key it= ems to everyone satisfaction we can quickly turn around the doc to one more i= teration. 

Thank you in advance!

--szb
Cell: +972.53= .2470068
WhatsApp: +1.650.492.0794
On Oct 8, 2020, at 23:21, Tero Kivinen via Datatr= acker <noreply@ietf.org> wrote:

=EF=BB=BFReviewer: David Mandelberg
Review result: Not Ready

I have= reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the<= br>IESG.  These comments were written primarily for the benefit o= f 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 i= s Not ready.

If I understand correctly, 64-= bit Client EIDs serve as both
identification and authentica= tion for a client. How many clients will an
EdgeRTR know ab= out at a single time? How many EIDs can an attacker guess
p= er second? If an attacker can guess 1024 EIDs per second, and there are
2^32 valid EIDs, I think that would mean it would take about 24= days on
average to guess a (non-specific) EID. Are my numb= ers off? Is that
acceptable?

How does the Client XTR verify the authenticity of the data coming from <= /span>
Server XTRs? Is it relying on infrastructure security in the= LISP and
server networks, and the obscurity of its own Cli= ent EID? E.g., if a
non-participant in the LISP network can= get the Client EID and RLOC
(e.g., by sniffing packets), c= ould they spoof an unsolicited multicast
packet to the clie= nt?

If the above is possible, I think this p= art of the Security
Considerations section should be fleshe= d out more, and possibly made
mandatory: "The traffic on th= e MobilityClient<>EdgeRTR interface is
tunneled  = ;and its UDP content may be encrypted"

The S= ecurity Considerations section says "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations" but as far as I can tell= ,
that's the first mention of any mandatory encryption of H= 3-R15
information. How does that encryption work?
I assume it wouldn't be that hard for an attacker to= get legitimate
access to a Mobility Client (e.g., by buyin= g a car). What would stop
them from sending the type of "fa= ke-news" updates the Security
Considerations section talks a= bout?




= --Apple-Mail-D951ED4D-6682-478F-AB05-8AA66F5D24E2-- From nobody Fri Oct 9 10:57:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1763A0D7D; Fri, 9 Oct 2020 10:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 Pxz_O7sH7ZE5; Fri, 9 Oct 2020 10:57:35 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 18A393A0D7B; Fri, 9 Oct 2020 10:57:35 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id d20so10929665iop.10; Fri, 09 Oct 2020 10:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qbBxrg4kgkLbm9mbkY1MapL103aA7E+W1yV7R27/caU=; b=Qq5+vfsLZ9TVAlIYAgNSWGNi5Xlwl5ZCRxLQD3MYgTYdp4n4LKsdKkSIDe9edH2DXc zJwGlE5pmXEbBdmvbKM7E+TDUK2YRrHx9XQ0RKiPU9jSexaLQIbnSLwhKLnvtWNMTC6m 2NDB/2ssYZIMzA7knpO+7nygd13ZDjalC0mSonjo7Sjxo6N0v10htBzcnPtsmE+6UDsE Nu1B4KnH4RomYSzLPg3ajEde0SDgxFkKsEIppk8MUuloTiqi580svFvEJiPnVRwCYZOw ZiPr+4oAgnZn3WRl6xs8bky09YZUdH0KnLveY++o2uVDQ7xPBrcamr0gF3Sb+PPSeq62 Ssjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qbBxrg4kgkLbm9mbkY1MapL103aA7E+W1yV7R27/caU=; b=unezoBoBG5trgr9TB6+9/jqp8QeqVS/Six9sMsq6wDIm5yepW6F/6XOimleqAYLh3w Sy4y/hPUY68tqWgI9/Qn2WN59fP0ltuwK3/ehVG75M1Wf15PSdzvIPM6uX1ij/ZpVdE8 1OffP4FxWM5/rvLASJXzCKc9Ure2CYl19GB4bbhF26cqfeFDSqJnCougiBFmE12XeX+R eHxBfwdj1t7pGf+KFSWPx+AUTH1a/ZSw5D3xveAiHt+muULYU9brfWKcbEOA+naWlvt1 XI05tVlNny3774wIxDRLCw/eSClhF+/X0m2usf32zT4cr2j3TIbhjlwly3S22nsfoGyu uy7w== X-Gm-Message-State: AOAM5311a+I3tEVwEk3XPxU+RJoLOV07fk5PWMlvs0+x/Oonx49suJmD peZPIkdMSpE9Jk03IWWPAK0Y+8iU/wE= X-Google-Smtp-Source: ABdhPJwLS577XAZDX9kRbHq/gkaAQPgqc2jC4GAxj36fA8mc5jNYbtNHuA1RxLR0LggF2cTOZpYz+w== X-Received: by 2002:a6b:8ec7:: with SMTP id q190mr853068iod.42.1602266254185; Fri, 09 Oct 2020 10:57:34 -0700 (PDT) Received: from [172.19.0.85] ([75.104.85.69]) by smtp.gmail.com with ESMTPSA id q196sm3781194iod.17.2020.10.09.10.57.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 10:57:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Dino Farinacci In-Reply-To: <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> Date: Fri, 9 Oct 2020 10:57:23 -0700 Cc: Tero Kivinen , secdir@ietf.org, lisp@ietf.org, draft-ietf-lisp-nexagon.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <270712E7-C1EC-4660-88E0-87F4DDDCE0C0@gmail.com> References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> To: Sharon Barkai X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 17:57:37 -0000 > It is going to be very hard to guess a valid EIDClient which an = EdgeRTR expects after AAA to whitelist provision. These EIDs are = temporary and expire after 15 minutes. It can be made even harder using more than 64-bits (since we are using = IPv6 EIDs). But if you do guess it, there isn't much you can do with it = because you don't have context and you can't send packets to it. As an = attacker, you can't get the RLOC information to send packets to the = guessed EID. Registrations and lookups to the mapping system can only done by = provisioned nodes in a centralized secure enclave. Dino From nobody Fri Oct 9 11:28:42 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F203A1000; Fri, 9 Oct 2020 11:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, 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 (2048-bit key) header.d=iki.fi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8XV4I88zR-q; Fri, 9 Oct 2020 11:28:38 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 7D0CB3A0FFA; Fri, 9 Oct 2020 11:28:36 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 53BE31B004DF; Fri, 9 Oct 2020 21:28:32 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602268112; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kbzl6c13OP2iXcQ91WuGpUjrMQdOxpjCA/LdHXdhgbU=; b=XOXrYr+Z+7PbwsLPn9kVRFdFl9D4gCe8Dk80CJPOuagHg4KNzL0UzcHqmICeP49PAF7PiS z8mjD5OBDl54fa1ln+EErxidqO0Ytcl5LkE07xubm5gl04gkTFk19W9Vv/1YEJv8Sn76w/ eaX/F5sPiJvaVQHpd/+HcOkasATupNVNvQi+Bdtq6q5p95saKt88YrqpGBw1leshFwNoHG RKM4N7JiT/LT6s2zizN99X2Y1rJQDs59ABJDgi7x4OwCSB5c/gMbfE1Du8VM9TGFw2RVk9 sDsa4hPyOqVHYYcJqv2VWVjUGrGR3ZH34lPu9Xan73NXEvzrQr20X8/Us8UP/g== Received: by fireball.acr.fi (Postfix, from userid 15204) id 4954F25C0E24; Fri, 9 Oct 2020 21:27:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24448.43948.218771.384183@fireball.acr.fi> Date: Fri, 9 Oct 2020 21:27:56 +0300 From: Tero Kivinen To: Sharon Barkai Cc: secdir@ietf.org, lisp@ietf.org, draft-ietf-lisp-nexagon.all@ietf.org, David Mandelberg In-Reply-To: <90E55F95-C6BB-4D30-814B-ECDF0CDC990A@getnexar.com> References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <90E55F95-C6BB-4D30-814B-ECDF0CDC990A@getnexar.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602268112; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kbzl6c13OP2iXcQ91WuGpUjrMQdOxpjCA/LdHXdhgbU=; b=UkT4Eq7sHlUHJ170eayfHyrBsPHIb2HFUT1IIG4hkw1nkN3ZtRfXaOiPV1hAQTvwmfOI4T /Jfgy5S4zkbiueXWO6vhzWVeuOwjDjCpiSpfNwyYbZHUBy34qQr9+UqI7e16odanEJb1ii Z6rID90fHO6Pn38hWEaHFR1JZVOOwmtMc9sl2EAgMYn0IECqwOb5HsoXEsAQAeJhPPbGPs jzDOQksMpXjZmGLqHSQLqUUl9ai3ZES56/JWX1EugbbQRj6SXfkTiW1Aivmn4U9LpsN0hn yFpX3YuQf85ZvYK0v5ZXRAKolcrV1g40EZhcJGyo1UBwZnu6M2wDHhYS/1tkNw== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602268112; a=rsa-sha256; cv=none; b=eQZsrU2q+QJxyWy+qms1dVQjtYHKiF7F3uWCTfPdUdFjLafcxPKrDkEsELHgDb0vcGVpsr I0L3AK/FGJ9qyHXAq4YS+16sDEj78SU9cN3yCelP4qSxkPZSiE7mUS0B9t59H9i2XxMsTx TY812bO6qLvRoLcx+06TrBwGJVTU5Kkjms4MWROeC5gPo5jhGQkMU1QOyOARUeaP1SqS9Z xxf9EjawMimCNAFmcPEQEVOSGbPiEjGaR7UStxJ3po+CVlT/UW7iJWiVv5uDxmgZttuavm j/D5x4ieYJWTacAjHzNIfeps7Vtp8eJlqy10Z+eTV3bdN6S7x4g14f573TL2wA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 18:28:41 -0000 Sharon Barkai writes: > Tero, really want to thank you for putting in the time, you clearly > understood the draft completely and point to areas we invested > thought on but can improve the wording. I was not the reviewer, the review was done by David Mandelberg, but for some reason his review emails did not get delivered to the secdir list, and I filled them in to the datatracker on his behalf and thats why the datatracker sent the emails out as coming from me to secdir and other lists. For discussion about the draft and review, you better contact him. > Before adjusting the draft would like to rehash together with the > group, Joel, and Luigi the themes pointed, which are spot on, so to > reach the best possible language. > > 1) End to end encryption - > > Nexagon uses LISP tunnels end to end: > - between EIDClients and EdgeRTRs > - between ingress and egress EdgeRTR > - between EdgeRTRs and H3EIDServices > > Depending on the specific nexagon network as service offered we would like to > offer the option to encrypt all communications on these tunnels. > > We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies RFC2631 key > exchange over LISP tunnels, also DTLS was suggested. > > Should we determine one or just describe the geo privacy and commercial > exposure if encryption is not used, especially on the tunnels between > MobilityEIDClients and EdgeRTRs? > > 2) Spoofing and imposters - > > EdgeRTRs and H3EIDServices are provisioned in the service provider edge > network. EdgeRTRs which are added to the network are provisioned with the > mapping system, H3EIDServices are whitelist provisioned with their designated > EdgeRTRs. > > We rely on the edge network routers to detect and stop spoofing using industry > standard double-lookup source/dest mechanisms. > Should we state so? > > The MobilityEIDClients are behind mobile access networks and go through AAA > step before receiving ephemeral EIDs and EdgeRTR RLOCs as anchors. > > This EID is based on their client ID credentials, and this EID is whitelist > provisioned by the AAA to the EdgeRTR given to the client as an anchor. > > The ipv6 EIDs given to these clients reflect their credibility reputation and > authorization level to pub-sub into the nexagon network. It is going to be > very hard to guess a valid EIDClient which an EdgeRTR expects after AAA to > whitelist provision. These EIDs are temporary and expire after 15 minutes. > > Spoofed EIDClients which are sniffed are going to be detected by the EdgeRTRs > because of mismatched client RLOC. Spoofed client RLOCs are detected by the > mobile packet core. > > Should we detail these aspects in security considerations ? > > 3) Fake news and client trust - > > This is a higher level concern as it is with many other protocols. Privacy and > reputation require trade-offs. The lisp-nexagon network uses crowd-sourced > street sampling to reflect current geo-state. Even the most honest client may > still be wrong, have faulty vision gear, gps interruption, or buggy AI. > Malicious clients may try to manipulate geo-state to their advantage, clear > their path from traffic, or simply try to saw confusion. > > For this reason all detections are corroborated and trust level of each client > is constantly scored by the H3EIDServices and updates the AAA system. This > credit score update reflects the behavior of the assigned ephemeral client > EID not the client, a car for ecample. But the AAA system knows which client > ID credentials the EID map to. The AAA system does not need to know the geo > association of these EID scores. They can be aggregated from all H3EIDServices > before handed to AAA. > > We can describe this general behavior even though its part of management and > orchestration and not part of the LISP-Nexagon interface specification. > > After we clear these 3 key items to everyone satisfaction we can quickly turn > around the doc to one more iteration. > > Thank you in advance! > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > > On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker > wrote: > > Reviewer: David Mandelberg > Review result: Not Ready > > 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 Not ready. > > If I understand correctly, 64-bit Client EIDs serve as both > identification and authentication for a client. How many clients will an > EdgeRTR know about at a single time? How many EIDs can an attacker guess > per second? If an attacker can guess 1024 EIDs per second, and there are > 2^32 valid EIDs, I think that would mean it would take about 24 days on > average to guess a (non-specific) EID. Are my numbers off? Is that > acceptable? > > How does the Client XTR verify the authenticity of the data coming from > Server XTRs? Is it relying on infrastructure security in the LISP and > server networks, and the obscurity of its own Client EID? E.g., if a > non-participant in the LISP network can get the Client EID and RLOC > (e.g., by sniffing packets), could they spoof an unsolicited multicast > packet to the client? > > If the above is possible, I think this part of the Security > Considerations section should be fleshed out more, and possibly made > mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is > tunneled and its UDP content may be encrypted" > > The Security Considerations section says "The H3ServiceEIDs themselves > decrypt and parse actual H3-R15 annotations" but as far as I can tell, > that's the first mention of any mandatory encryption of H3-R15 > information. How does that encryption work? > > I assume it wouldn't be that hard for an attacker to get legitimate > access to a Mobility Client (e.g., by buying a car). What would stop > them from sending the type of "fake-news" updates the Security > Considerations section talks about? -- kivinen@iki.fi From nobody Fri Oct 9 14:59:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF4B3A096C; Fri, 9 Oct 2020 08:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602255761; bh=DE/z5Rf+z+VYNG0SKwvYOW82toI+vY1bInlPkKuMj5E=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=yk9j6o1CTz7zHUhHPanu0x+5drMBE2joBkq0PoEIBas+wgXInJtGCAHgw1X/eRIok eNRT0PzPNqcJA49fif19TQPCt+DfiXXcIB/+6xjN59u/Oumb+UKZRszNI7S8I7gmVd j6iuF9M7Xu/Gadmdusg5qKo5mdpNj9v1IOTM67lQ= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 9 08:02:40 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6354F3A08C3; Fri, 9 Oct 2020 08:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602255760; bh=DE/z5Rf+z+VYNG0SKwvYOW82toI+vY1bInlPkKuMj5E=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=Y42JSwUs+w1TEU5cVzjnTc5Ebjh72sG4Zzx+quBbwjPVo2hZOni+SYuWAIasC/e0j jtYlvRuJ8BuTCfql9ZDwDth1jFcwOJc8AeiEqp7F7ZYd8KmNgWkDOn/l23xtMC6YOp 696OVFiGCmOrXFFlgQZx6tW8h7GTNitfJb+D7les= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99ED3A044E for ; Fri, 9 Oct 2020 08:02:38 -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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-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 v46jXj-8-M2G for ; Fri, 9 Oct 2020 08:02:37 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 226903A08B2 for ; Fri, 9 Oct 2020 08:02:36 -0700 (PDT) Received: from [112.102.242.105] (helo=[192.168.0.100]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kQtul-0002iy-6q for new-work@ietf.org; Fri, 09 Oct 2020 15:02:35 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <41199cfc-2cda-f339-30dc-42f2fcd3f0a6@w3.org> Date: Fri, 9 Oct 2020 23:02:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 09 Oct 2020 14:59:14 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web Accessibility Initiative (WAI) Interest Group (until 2020-11-06/07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 15:02:43 -0000 SGVsbG8sCgpUb2RheSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlcyByZWNl aXZlZCBhIHByb3Bvc2FsIHRvIApyZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIEFj Y2Vzc2liaWxpdHkgSW5pdGlhdGl2ZSAoV0FJKSAKSW50ZXJlc3QgR3JvdXA6CiDCoCBodHRwczov L3d3dy53My5vcmcvV0FJL0lHLzIwMjAwODA0Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsgYXQgVzNDLCAKdGhpcyBk cmFmdCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5IENvbW1pdHRlZSByZXZp ZXcgcGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIG9uIHRoZSBwcm9wb3NlZCBj aGFydGVyIHRocm91Z2ggMDQ6NTkgClVUQy9HTVQgb24gMjAyMC0xMS0wNyAoMjM6NTksIEJvc3Rv biB0aW1lIG9uIDIwMjAtMTEtMDYpLiBQbGVhc2Ugc2VuZCAKY29tbWVudHMgdG8gcHVibGljLW5l dy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkgQ29tbWl0dGVl IApSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8gY29t bWVudHMuIElmIHlvdSAKd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5h dGUgeW91ciBjb21tZW50cyB3aXRoIHlvdXIgCkFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRh dGl2ZS4gRm9yIGV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIApwdWJsaWMgY29tbWVudHMg dmlhIHRoaXMgbGlzdCBhbmQgaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSAKUmVwcmVzZW50 YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMgb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMu CgpUaGUgSW50ZXJlc3QgR3JvdXAncyBjdXJyZW50IGNoYXJ0ZXIgWzJdIGlzIGhlcmVieSBleHRl bmRlZCB1bnRpbCAyMCAKTm92ZW1iZXIgMjAyMCwgdG8gYWNjb21tb2RhdGUgdGhlIGNoYXJ0ZXIg cmV2aWV3IHBlcmlvZC4KCklmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQg ZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlIApjb250YWN0IEp1ZHkgQnJld2VyIDxqYnJld2Vy QHczLm9yZz4swqAgV0FJIEludGVyZXN0IEdyb3VwIFN0YWZmIENvbnRhY3QuCgpUaGFuayB5b3Us CgpYdWV5dWFuIEppYSzCoCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRw Oi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0ClsyXSBodHRwczovL3d3dy53My5v cmcvV0FJL0lHL2NoYXJ0ZXI2Lmh0bWwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Oct 9 14:59:19 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A186F3A0DA4; Fri, 9 Oct 2020 09:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602261473; bh=pYcuargehvgNXO+Q/T7MflqY86LYuiwgdWytuHnrrR4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=gzYQp61RNoc0sWBesG1YfUreBkOri/IP7/GiTixpx2ZdaiIgYhaLWoUTTgLzeq9Gm bgi2Xy2kk/HrjVE1JF3u7uN2GCxcO7u6GT2qXYzg0zRXOqRbInj7xQF50CjC+dnw0X dW7Pngj1SXtR61q/Li6He9EE6M8iYhIefW/9XpBo= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Oct 9 09:37:47 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD1E3A0D57; Fri, 9 Oct 2020 09:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602261462; bh=pYcuargehvgNXO+Q/T7MflqY86LYuiwgdWytuHnrrR4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=GesVI81leyW6oP/4UCXQhTCpjeXkIuilGWlaZ2hbv3OWxUXAoYksQdEJmBEfgCVZf MULEY0ugOPJSwWv+K88/U1JqVnGIOsYcRJ1P0cYzGIRVIoesLZtxzjZmbnqUbRSwzo VL/Oyt3w0hB2tw7WFX16OUd/ucYbnSF/LBztFzJ4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 054153A0CEA for ; Fri, 9 Oct 2020 09:37:36 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <160226145600.9767.2143954261959615711@ietfa.amsl.com> Date: Fri, 09 Oct 2020 09:37:36 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 09 Oct 2020 14:59:14 -0700 Subject: [secdir] [new-work] WG Review: JSON Path (jsonpath) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2020 16:38:00 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-10-19. JSON Path (jsonpath) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: jsonpath@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jsonpath Archive: https://mailarchive.ietf.org/arch/browse/jsonpath/ Group page: https://datatracker.ietf.org/group/jsonpath/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jsonpath/ JSONPath is a syntax, originally based on the XML "XPath" design, which selects fields and values from a JSON document. It is used in a variety of applications which rely on JSON message formats. JSONPath was originally described by Stefan Goessner [1] but has never had an official specification of any kind, and the 39+ implementations, while mostly compatible, differ in certain behaviors. Note that while JSON Pointer (RFC 6901) is already standardised, it is designed to provide a reference to a single, specific part of a JSON document, whereas JSONPath provides the ability to query a document and potentially return multiple values. The WG will develop a standards-track JSONPath specification that is technically sound and complete, based on the common semantics and other aspects of existing implementations. Where there are differences, the working group will analyze those differences and make choices that rough consensus considers technically best, with an aim toward minimizing disruption among the different JSONPath implementations. Possible input documents are: * https://datatracker.ietf.org/doc/draft-goessner-dispatch-jsonpath/ * https://jsonpath-standard.github.io/internet-draft/ [1] https://goessner.net/articles/JsonPath/ Milestones: Feb 2021 - Standards Track document defining JSON Path to the IESG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sat Oct 10 21:30:20 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE963A09E4; Sat, 10 Oct 2020 21:30: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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 pP4-IBaBU8Pd; Sat, 10 Oct 2020 21:30:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB83A0E79; Sat, 10 Oct 2020 21:30:05 -0700 (PDT) Received: from [IPv6:2001:470:496b:0:901d:ceeb:51a:4faf] ([IPv6:2001:470:496b:0:901d:ceeb:51a:4faf]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 09B4Tqja2997134 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Oct 2020 21:29:53 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 09B4Tqja2997134 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1602390595; bh=aSkwdudthiN93Ss804ZMIop7b1s7S4vvC5UMLDNhBXU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=CpuTdAVt0BpyFBjOX47Fo/C16ultYu6wLifQ45QV07leBqg18cd2IFACwdrMuxsOS 9yXILCzn5ZjNNdmw4O0OgGywmt4IPhy9VtHd6+pLHG7y4GYm/Fv8cHo2YhAneHpmXM HCpsPT/BD8GYxZ/7fq5fLYQknmuFeHWOf2kq0Hzk= From: Owen DeLong Message-Id: <033A6CDA-63DD-4E3B-9AEB-EAF36B7F8AB7@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 10 Oct 2020 21:29:52 -0700 In-Reply-To: <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu> Cc: Ted Lemon , "v6ops@ietf.org" , "last-call@ietf.org" , "secdir@ietf.org" , Christopher Wood via Datatracker , "draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org" , Christopher Wood To: Uri Blumenthal References: <4FC30E5B-EF9F-4238-A683-CE8235BDD2EF@fugue.com> <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Sat, 10 Oct 2020 21:29:55 -0700 (PDT) Archived-At: Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 04:30:15 -0000 --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Virtually anyone that could possibly be on both interfaces has access to = do far more damage to the network than would be possible from this = particular vulnerability. The northbound interface is between the CPE and the ISP. The southbound = interface is to the site local area networks. Only the site administrator(s) should (theoretically) have access to = both networks. An attacker who has access to both can override virtually = any automated network provisioning at the local site. Owen > On Sep 9, 2020, at 7:17 PM, Uri Blumenthal wrote: >=20 > Capability-wise, what's the likelihood that the attacker would be = present on the southbound interface, but *not* on the northbound one? >=20 > Sent from my test iPhone >=20 >> On Sep 9, 2020, at 19:32, Ted Lemon wrote: >>=20 >> =EF=BB=BF On Sep 9, 2020, at 7:16 PM, Christopher Wood via = Datatracker > wrote: >>> - Section 3: is it possible for an attacker to send DHCPv6 Prefix = Delegations >>> with lifetime=3D0 to CE routers that support LAN-side DHCPv6 and = amplify >>> Reconfigure messages to supporting clients? (I don't know if this is = a concern >>> or part of the threat model, but this did seem to be a case of = possible >>> request/response asymmetry.) - Section 4: rationale for these = default values, >>> if available, might be worth including. (Why not make them shorter? = What are >>> the tradeoffs?) - Section 6: it might be worth noting what happens = if stable >>> storage is unavailable or otherwise compromised when trying to store = prefix >>> information. What happens if the "A" or "L" bits are modified? (I = suspect >>> nothing dangerous, but it's not clear to me whether or not integrity = is >>> important.) >>=20 >> The attacker on the southbound link would have to know the = transaction ID of the DHCP request/confirm/renew message, which is only = sent on the northbound interface, and would have to know the DUID and = IAID used by the client, again never seen on the southbound link, and = would have to know the server=E2=80=99s DUID, again only visible = northbound. I don=E2=80=99t think this is a feasible attack. It=E2=80=99s = hard to see what the benefit of such an attack would be=E2=80=94in order = to effect this attack without knowledge of the exchange on the = northbound interface, the client would have to be continuously spamming = the southbound link with attempts, so that would be a negative = amplication factor of perhaps 2^256, perhaps less if the identifiers can = be predicted and renewal times can be predicted. >>=20 >> And this assumes that the DHCPv6 PD client on the CPE device will = even accept a DHCP Reply on its southbound interface. >>=20 >> :) >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Virtually anyone that could possibly be on both interfaces = has access to do far more damage to the network than would be possible = from this particular vulnerability.

The northbound interface is between the = CPE and the ISP. The southbound interface is to the site local area = networks.

Only = the site administrator(s) should (theoretically) have access to both = networks. An attacker who has access to both can override virtually any = automated network provisioning at the local site.
Owen


On Sep 9, 2020, at 7:17 PM, Uri Blumenthal <uri@mit.edu> = wrote:

Capability-wise, what's the = likelihood that the attacker would be present on the southbound = interface, but *not* on the northbound one?

Sent from my test = iPhone

On Sep 9, 2020, at 19:32, Ted Lemon <mellon@fugue.com> = wrote:

=EF=BB=BF On Sep 9, 2020, at 7:16 PM, Christopher Wood via Datatracker = <noreply@ietf.org> wrote:
- Section 3: is it possible for an attacker to send DHCPv6 = Prefix Delegations
with lifetime=3D0 to CE routers that support LAN-side DHCPv6 = and amplify
Reconfigure = messages to supporting clients? (I don't know if this is a = concern
or part of = the threat model, but this did seem to be a case of possible
request/response asymmetry.) - Section 4: rationale for these = default values,
if available, might be worth including. (Why not make them = shorter? What are
the tradeoffs?) - Section 6: it might be worth noting what = happens if stable
storage is unavailable or otherwise compromised when trying = to store prefix
information. What happens if the "A" or "L" bits are = modified? (I suspect
nothing dangerous, but it's not clear to me whether or not = integrity is
important.)

The attacker on the southbound link would have to know the = transaction ID of the DHCP request/confirm/renew message, which is only = sent on the northbound interface, and would have to know the DUID and = IAID used by the client, again never seen on the southbound link, and = would have to know the server=E2=80=99s DUID, again only visible = northbound. I don=E2=80=99t think this is a feasible attack. It=E2=80=99s = hard to see what the benefit of such an attack would be=E2=80=94in order = to effect this attack without knowledge of the exchange on the = northbound interface, the client would have to be continuously spamming = the southbound link with attempts, so that would be a negative = amplication factor of perhaps 2^256, perhaps less if the identifiers can = be predicted and renewal times can be predicted.

And this assumes that the DHCPv6 PD = client on the CPE device will even accept a DHCP Reply on its southbound = interface.

:)

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
______________________________________= _________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9-- From nobody Tue Oct 13 23:20:59 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 047AF3A0407; Tue, 13 Oct 2020 07:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602599565; bh=jjTD22HVrwAc8oawcinyTaZoo+NnsOx6mARb1pv0BD0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=uXDnSwA09rRKz/npjNxwmHeZ9SLAP2Mi7fLXG6eGsYyi8odQf20hy9cmBv1iQ+YwF LfduBBlGo7m3x0sSRUExvB7nFLa9WHq2h3crG2b/Eusxk1nbf1Ajy3SquMM7Hof6WU LlS6OuheJzooIep8kMdwaaLLIeCMLutmA7Uj1+1o= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Oct 13 07:32:44 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BF3A0822; Tue, 13 Oct 2020 07:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1602599564; bh=jjTD22HVrwAc8oawcinyTaZoo+NnsOx6mARb1pv0BD0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=TMWogHuHmhrwmWDeCe28CVcVhlOBjkLsTuI/X//i5AulQAPeft70gmCOQt5U5EUsP eaoSLuR1V8ilNvnIqaNGq+SYT+10QMvCqXHOW5nHMKi99/tVRjnllE7Wp4pBCW/PAO ERMCZeudQEHhzrgLtYAdikHVm8PO7SM9i78X1nFQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1847D3A0822 for ; Tue, 13 Oct 2020 07:32:41 -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, FREEMAIL_FROM=0.001, 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 (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 SKJ4KDkNMXcQ for ; Tue, 13 Oct 2020 07:32:39 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 523923A07F0 for ; Tue, 13 Oct 2020 07:32:39 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id q25so8689051ioh.4 for ; Tue, 13 Oct 2020 07:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=tOZ8CrVF1dp4w4BiKuDz4noJ9pzL9fZGImOT2YrhjIQ=; b=qSfe7oouumKAvxE69OMzwl+9caA7ApEKVyG249lkSNJBKtcMzDQmWicmpIU0ENDZ3T ggCoOQC5/M09oTF2EV19qLF96Utnj5sLS76hTkYwmysvTteNOS7s6LfN/CkLmPqEBsqz +1xM9/DubKf3qZDYAaExeVrTJiu66NCK+10s2KSCJTxFL0jFA9nLuHOiBKJYe+JkUM8v r9SBPrggfK/4QkgmZgSPoaytaVrrHzFv0H45szMDpaJMWN4or2lnwanGSj8/v8abAlJe 8y9tDAZIaZKkoxp793YMONO6qipHenOHR254urZvgFl0UNhWcDyTUMRsgEVS8vuEASYh cP1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=tOZ8CrVF1dp4w4BiKuDz4noJ9pzL9fZGImOT2YrhjIQ=; b=A8JWl4kKytoxx70f+QPpgqzE8seYFvLS4Yi6TRUmVf2Mj2c4TFGDo9CmlAkuEB6t9V f+Ve22z3IFecrUIxSgug4Cdlf04OW4F44u+N6RqLhTKRCXJWY+9YqCOfjcZpaz+zTKeU 2cfO0GQKa4UXXj9UDRzSKZe/3iCshFZjud+LhD2k6H9Aw6N4gGiunsUM36nk7HahQkFO 1TscMkZrSnAX06JpqEdTf1+p0U/ZxWntFmfiPtz+y1Qff4GxYCyxp3XxcZ3+K5CiE0yP YhLOyahvCg6pDrTlT4w7mZVCga3hM75wAXcHYJFjuAcipM+YoN8ByW4nBgKr9jaPYG+5 ZBWA== X-Gm-Message-State: AOAM533lfF4ps/WGvIpIb8dDQYQp2aoigwvJl0+1J+K3yCHMvDFPT+hT JtgX3sd3RJHgeCzmqJiGlo0= X-Google-Smtp-Source: ABdhPJwGMTq8GsFk0MdmJ+ogYH91csot5oHDmul7jmlL6Q4X6sWHu1DrcxEUUnrI9acxXzUPbHSTLQ== X-Received: by 2002:a5d:9f05:: with SMTP id q5mr13522144iot.11.1602599558566; Tue, 13 Oct 2020 07:32:38 -0700 (PDT) Received: from DESKTOP6VF5FH7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id c63sm2771927ill.24.2020.10.13.07.32.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 07:32:37 -0700 (PDT) From: To: Date: Tue, 13 Oct 2020 10:32:33 -0400 Message-ID: <1baf01d6a16d$b20641b0$1612c510$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdahbZA9oJ2am/leT/asVzh5GgEgxg== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: dorothy.stanley@hpe.com, Paul Nikolich Content-Type: multipart/mixed; boundary="===============1530865683460592219==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 13 Oct 2020 23:20:58 -0700 Subject: [secdir] [new-work] IEEE 802 PARs under Consideration - Nov 2020 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 14:32:47 -0000 This is a multipart message in MIME format. --===============1530865683460592219== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1BB0_01D6A14C.2AF56500" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_1BB0_01D6A14C.2AF56500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) and ICAID will be considered at the IEEE 802 Nov 2020 Plenary, which will be held electronically - * 802.1DP Standard: Time-Sensitive Networking Profile for Aerospace Onboard Ethernet Communications, PAR and CSD * 802.11bh Amendment: Enhanced service with randomized MAC addresses, PAR and CSD * 802.11bi Amendment: Enhanced service with Data Privacy Protection, PAR and CSD * 802.15.4aa Amendment: Japanese Rate Extension, PAR and CSD * 802.16t Amendment - Fixed and Mobile Wireless Access in Narrowband Channels, PAR modification and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 03 Nov 2020, AoE Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_1BB0_01D6A14C.2AF56500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following = Project Authorization Requests (PARs) and ICAID will be considered at = the IEEE 802 Nov 2020 Plenary, which will be held electronically – =  

  • 802.1DP = Standard: Time-Sensitive Networking Profile for Aerospace Onboard = Ethernet Communications, PAR and CSD
  • 802.11bh = Amendment: Enhanced service with randomized MAC addresses, PAR and CSD
  • 802.11bi = Amendment: Enhanced service with Data Privacy Protection,  PAR and CSD
  • 802.15.4aa = Amendment: Japanese Rate Extension, PAR and CSD
  • 802.16t = Amendment - Fixed and Mobile Wireless Access in Narrowband = Channels, PAR modification and CSD

The PARs and ICAID can be = found at http://www.ieee802.org/PARs.sh= tml along with the supporting IEEE 802 Criteria for Standards = Development, or CSD, (which includes the 5 criteria, i.e. the = explanations of how they fit the IEEE 802 criteria for initiating new = work).

 

Any comments on a = proposed PAR / ICAID should be sent to the Working Group chair = identified on the respective document to be received by 03 Nov 2020, = AoE

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

------=_NextPart_000_1BB0_01D6A14C.2AF56500-- --===============1530865683460592219== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1530865683460592219==-- From nobody Fri Oct 16 18:21:51 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B40343A0A96; Fri, 16 Oct 2020 18:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160289769957.27431.527588870284609048@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Fri, 16 Oct 2020 18:21:39 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-calext-jscalendar-32 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 01:21:40 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready The draft describes a calendar/task format that addresses identified issues in iCalendar. These appear to be handled satisfactorily. The Security Considerations section identifies the principle sources of concern. From nobody Sat Oct 17 04:24:24 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8053A0A66 for ; Sat, 17 Oct 2020 04:24:22 -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=getnexar.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 YEEEEUjuzbWx for ; Sat, 17 Oct 2020 04:24:20 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0849D3A0A64 for ; Sat, 17 Oct 2020 04:24:19 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id e23so5894536wme.2 for ; Sat, 17 Oct 2020 04:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=eS/jt/0pm5RLIkbJyLpq75y+7+TISWcl9bKx9dyKKMQ=; b=hOzutXf6CFWtVLVflhoQ0dB1OUK0Ar1JrNZJQCXezro7+t1vp11z5Y3InEHS91euh+ J4107eEcjZQ96qH90NE6PnE3XG00ACuwP3IqPRRsSyVjZtPn3jKmEoxSzKDCoXfBwb9S OVXw4BKpHSbeBA/DZfqZhk2LyP17S3imgz0Yg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eS/jt/0pm5RLIkbJyLpq75y+7+TISWcl9bKx9dyKKMQ=; b=rymYjlZisSCOjXjON7n8pIRY09sRvoFz0jFkR0DbNCnfnkYaqKorBIrAplONSmOXXF CDU1Qus0abmqPiVq5pVehPaW2OE2BDiDRT1VOExPXTAKgQfeTuX/q/I284vyfILnMqlM MvGU9Z96QLcsbA+D0j0sC8Yvjjto0FO4+v0hI05hM1/vnkT5c4vqghoQfYRUzGldU/Uv 6Sx3rjKmUiazVvWrjt3lYCYGo2xBbE1OBjd38bXQ3yUSXpzqDFRRnqMdTZOUF+bleIrZ 10mVVd8723Ho5BcpyXXwpZ1HnZ/wXCtqjRsWtbPIqIUrpZaelaRDMg5JdT8/iqL7JgAm fEuQ== X-Gm-Message-State: AOAM5332b06Wg4x8AP9aB+uRKNxKOLV2I2lt/iPenf8wzO8YsW+5iWfx X+YJTE6ScsF7BNzndWfWtDSz8Q== X-Google-Smtp-Source: ABdhPJwxB3ZPETNiiWc87/W7lsk4dd72Mq+/ZrKhV9fJAvcBOy3zinnIGp9oeu9RvCbQLkhxjMT+jQ== X-Received: by 2002:a1c:b646:: with SMTP id g67mr7886310wmf.87.1602933858247; Sat, 17 Oct 2020 04:24:18 -0700 (PDT) Received: from ?IPv6:2a02:14c:27c:b400:f5b5:cd6:d37a:6dc6? ([2a02:14c:27c:b400:f5b5:cd6:d37a:6dc6]) by smtp.gmail.com with ESMTPSA id l26sm7104303wmi.41.2020.10.17.04.24.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2020 04:24:17 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_29C71931-FADC-4FA9-99C5-EDDF228E357A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sharon Barkai In-Reply-To: <160218848061.12936.5873889616190686198@ietfa.amsl.com> Date: Sat, 17 Oct 2020 14:24:15 +0300 Cc: secdir@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-nexagon.all@ietf.org Message-Id: References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> To: Tero Kivinen , David Mandelberg X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 11:24:22 -0000 --Apple-Mail=_29C71931-FADC-4FA9-99C5-EDDF228E357A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear David, thank you again for putting the effort to review the draft. Published bellow are clarifications to concerns raised. In summary of main risk mitigations for the lisp-nexagon interface we = can say: (1) tapping: all communications are through dynamic tunnels therefor = may be encrypted using IP-Sec or other supported point to point underlay = standards *this are not static, but retunneling routers (RTRs) do all aggregations (2) spoofing: it is very hard to guess a MobilityClientEID valid for a = short period of time. Clients and H3Services EIDs are whitelisted in = EdgeRTRs (3) impersonating: efforts to use MobilityClients and H3Services RLOCs = should be caught by the underlying service provider edge and access networks ** we rely on underlay anti-spoofing for RLOCs and provide anti-spoofing = for EIDs (4) credibility: the interface crowd-sources geo-state and does not = assume to trust single detections. Credit history can be traced and reflect = credentials (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and = geo-location, only AAA is aware of client IDs credentials and credit but not = geo-location ***enterprises can bring their own RTRs and if trusted are provisioned = to the LISP network **** AAA is provisioned administratively including credentials and trust https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-05 = Please let us know as soon as you can if you think the concerns are = addressed. All the best, Sharon > On Oct 8, 2020, at 23:21, Tero Kivinen via Datatracker = wrote: >=20 > Reviewer: David Mandelberg > Review result: Not Ready >=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 Not ready. >=20 > If I understand correctly, 64-bit Client EIDs serve as both=20 > identification and authentication for a client. How many clients will = an=20 > EdgeRTR know about at a single time? How many EIDs can an attacker = guess=20 > per second? If an attacker can guess 1024 EIDs per second, and there = are=20 > 2^32 valid EIDs, I think that would mean it would take about 24 days = on=20 > average to guess a (non-specific) EID. Are my numbers off? Is that=20 > acceptable? >=20 > How does the Client XTR verify the authenticity of the data coming = from=20 > Server XTRs? Is it relying on infrastructure security in the LISP and=20= > server networks, and the obscurity of its own Client EID? E.g., if a=20= > non-participant in the LISP network can get the Client EID and RLOC=20 > (e.g., by sniffing packets), could they spoof an unsolicited multicast=20= > packet to the client? >=20 > If the above is possible, I think this part of the Security=20 > Considerations section should be fleshed out more, and possibly made=20= > mandatory: "The traffic on the MobilityClient<>EdgeRTR interface is=20 > tunneled and its UDP content may be encrypted" >=20 > The Security Considerations section says "The H3ServiceEIDs themselves=20= > decrypt and parse actual H3-R15 annotations" but as far as I can tell,=20= > that's the first mention of any mandatory encryption of H3-R15=20 > information. How does that encryption work? >=20 > I assume it wouldn't be that hard for an attacker to get legitimate=20 > access to a Mobility Client (e.g., by buying a car). What would stop=20= > them from sending the type of "fake-news" updates the Security=20 > Considerations section talks about? >=20 >=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_29C71931-FADC-4FA9-99C5-EDDF228E357A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear David, thank you again for putting the effort to review = the draft.
Published bellow are clarifications to = concerns raised.


In =
summary of main risk mitigations for the lisp-nexagon interface we can =
say:

  (1) tapping: all communications are through dynamic tunnels therefor =
may be
  encrypted using IP-Sec or other supported point to point underlay =
standards
*this are not static, but retunneling routers =
(RTRs) do all aggregations

  (2) spoofing: it is very hard to guess a MobilityClientEID valid for a =
short
  period of time. Clients and H3Services EIDs are whitelisted in =
EdgeRTRs

  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs =
should
  be caught by the underlying service provider edge and access =
networks
** we rely on underlay anti-spoofing for RLOCs =
and provide anti-spoofing for EIDs

  (4) credibility: the interface crowd-sources geo-state and does not =
assume to
  trust single detections. Credit history can be traced and reflect =
credentials

  (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and =
geo-location,
  only AAA is aware of client IDs credentials and credit but not =
geo-location

***enterprises can bring their own RTRs and if =
trusted are provisioned to the LISP network
**** =
AAA is provisioned administratively including credentials and =
trust



https://datatracker.ietf.org/doc/html/draft-ietf-lisp-nexagon-0= 5


Please let us know as soon as you can = if you think the concerns are addressed.
All the = best,
Sharon



On Oct 8, 2020, at 23:21, Tero = Kivinen via Datatracker <noreply@ietf.org> wrote:

Reviewer: David Mandelberg
Review result: Not = Ready

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 Not = ready.

If I understand correctly, 64-bit = Client EIDs serve as both
identification and = authentication for a client. How many clients will an
EdgeRTR know about at a single time? How many EIDs can an = attacker guess
per second? If an attacker can guess 1024 = EIDs per second, and there are
2^32 valid EIDs, I think = that would mean it would take about 24 days on
average to = guess a (non-specific) EID. Are my numbers off? Is that
acceptable?

How does the Client = XTR verify the authenticity of the data coming from
Server = XTRs? Is it relying on infrastructure security in the LISP and
server networks, and the obscurity of its own Client EID? = E.g., if a
non-participant in the LISP network can get = the Client EID and RLOC
(e.g., by sniffing packets), = could they spoof an unsolicited multicast
packet to the = client?

If the above is possible, I think = this part of the Security
Considerations section should = be fleshed out more, and possibly made
mandatory: "The = traffic on the MobilityClient<>EdgeRTR interface is
tunneled  and its UDP content may be encrypted"

The Security Considerations section says "The = H3ServiceEIDs themselves
decrypt and parse actual H3-R15 = annotations" but as far as I can tell,
that's the first = mention of any mandatory encryption of H3-R15
information. = How does that encryption work?

I assume it = wouldn't be that hard for an attacker to get legitimate
access to a Mobility Client (e.g., by buying a car). What = would stop
them from sending the type of "fake-news" = updates the Security
Considerations section talks = about?




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

= --Apple-Mail=_29C71931-FADC-4FA9-99C5-EDDF228E357A-- From nobody Mon Oct 19 16:34:49 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A93A1011 for ; Mon, 19 Oct 2020 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 (2048-bit key) header.d=mandelberg.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 dJ8xLmvmEO-T for ; Mon, 19 Oct 2020 16:34:42 -0700 (PDT) Received: from mail-vs1-xe62.google.com (mail-vs1-xe62.google.com [IPv6:2607:f8b0:4864:20::e62]) (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 4850E3A103F for ; Mon, 19 Oct 2020 16:34:42 -0700 (PDT) Received: by mail-vs1-xe62.google.com with SMTP id u74so30671vsc.2 for ; Mon, 19 Oct 2020 16:34:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:from:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8FAmYK2yuYodu2OswGS2CV1ovbpu8jAz37HpbPVqLUA=; b=AaXSBN7ZuVhMrI9al8QR/jovPr4zadEBtp150/G/BzSvVqrxLkSfpCqvUrNjtZ4rZF FwFyMhuUUmJ2aohS5LTpAROGT2qeXTeUvGsAEgO9459pDdny6sIamGDd3o32tb6dNDIu sgNEG0Yso+UPxcf+RRWYEJOIc/JWyNdRGfBYKSvupCL2MfpdSvwkK+r46fjBDGHMbp9I qhySN7GASwdIx4C2Tm4Y+/8ugap8xtAr5KrQLgUjUYmjDmUjJ86cOTvbW0lgjKe0/KZr /ENnl5YoSk/sCccrpQhMoReC2gVSkrfbNmXisYsoVRmv/1C05M2/s8sTe7mLtwWB3bqT j2Sw== X-Gm-Message-State: AOAM530FX+Mo9tioL9TqMhXkj9niGyXxoBuf0fYbvbj5drwfPBQJWRaN qzWt5abJP5JpbhZrVAjYGSx2ZRAqj+T05R+QnujvCaRvnSbcRg== X-Google-Smtp-Source: ABdhPJy1IhMveUHtj7sdU/8r35GkRyaSkXQS69sGre8R8wJFwcB6sT4Km3EmK0AXO4aS1K7vNunU6RBRznEg X-Received: by 2002:a05:6102:1249:: with SMTP id p9mr31685vsg.51.1603150478756; Mon, 19 Oct 2020 16:34:38 -0700 (PDT) Received: from uriel.mandelberg.org (pool-100-0-196-177.bstnma.fios.verizon.net. [100.0.196.177]) by smtp-relay.gmail.com with ESMTPS id b16sm21483vka.6.2020.10.19.16.34.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2020 16:34:38 -0700 (PDT) X-Relaying-Domain: mandelberg.org Received: from [192.168.1.162] (nevia [192.168.1.2]) by uriel.mandelberg.org (Postfix) with ESMTPSA id B21001C6057; Mon, 19 Oct 2020 19:34:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202009; t=1603150477; bh=pEcYiDvtE5kPU6kO8XtZMMSwYYtA4OXN7vdMxSiTqQE=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=vU3izEnjQJ57ZvQp+/cLsaO4Ej43Cd030WjS51KlmkFPiT//Eds6Nvhn74xNP4dyD d08NWAR/nZJN67NtiN6BO4rqHMrzue/9cPUBOABCLqjzBND769Xg6Fx/qAkAzn6gZ0 L5ivgTRiEi5hZ5QZf3kfwYgLAlza8dpHi2KcyeOds7BZd7oUj1L23YkpbgaooGRfeI oRPtaBdf5Mf/fa6FTxMpdk2VTlCSYDdEg/FLYAPo6oLf8gvjPf+nXbbIU/elwJvYtj ngeoHDgYPbdVIJpyPgJv7F/Hca6+JcO9HvQoeb4MKtbrk4aertk1CwbUKkuNAeU4M3 na/DVNcoDpGag== From: David Mandelberg To: Sharon Barkai , Tero Kivinen Cc: draft-ietf-lisp-nexagon.all@ietf.org, lisp@ietf.org, secdir@ietf.org References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> Message-ID: <5bd465d2-449c-6b1d-f83f-0e3489f1bf22@mandelberg.org> Date: Mon, 19 Oct 2020 19:34:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 23:34:45 -0000 (I previously sent the email below on 2020-10-10, but I don't think it went through due to an email server misconfiguration. Sending again now that my email issues are fixed, I think) On 10/9/20 1:32 PM, Sharon Barkai wrote: > Sorry for the confusion, David! really want to thank you for putting in > the time, you clearly understood the draft completely and point to areas > we invested thought on but can improve the wording. No worries. I'm just glad I noticed that my initial review email didn't go through. Hopefully this one does? > Before adjusting the draft would like to rehash together with the group, > Joel, and Luigi the themes pointed, which are spot on, so to reach the > best possible language. > > > 1) End to end encryption - > > Nexagon uses LISP overlay encapsulations end to end: > - between EIDClients and EdgeRTRs > - between ingress and egress EdgeRTR > - between EdgeRTRs and H3EIDServices That doesn't cover "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 annotations" though, right? Is there any encryption of the H3-R15 information all the way from EIDClient to H3EIDService? > Depending on the specific  nexagon as service we would like to offer the > option to encrypt all communications on these dynamic encapsulations. > > We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies > RFC2631 key exchange over LISP tunnels, also DTLS was suggested. > > Should we determine one or just describe the geo privacy and commercial > exposure if encryption is not used, especially on the tunnels between > MobilityEIDClients and EdgeRTRs? You understand the specifics of where this protocol will be used much better than I do, so I think you're in a better place to choose between picking one option or explaining the issues and letting implementers decide on the encryption mechanism. In general, I'd lean towards picking one good cipher suite and sticking to that (without making it difficult to change things up in the future), but there can be good reasons not to do that. > 2) Spoofing and imposters - > > EdgeRTRs and H3EIDServices are provisioned in the service provider edge > network. EdgeRTRs which are added to the network are provisioned with > the mapping system, H3EIDServices are whitelist provisioned with their > designated EdgeRTRs. > > We rely on the edge network routers to detect and stop spoofing using > industry standard double-lookup source/dest  mechanisms. > Should we state so? I think so, yes. I generally think it's good to be explicit when relying on underlying infrastructure for security, so that if anybody later tries to adapt a protocol to some different infrastructure, they know what to pay attention to. > The MobilityEIDClients are behind mobile access networks and go through > AAA step before receiving ephemeral EIDs and EdgeRTR  RLOCs as anchors. > > This EID is based on their client ID credentials, and this EID is > whitelist provisioned by the AAA to the EdgeRTR given to the client as > an anchor. > > The ipv6 EIDs given to these clients reflect their credibility > reputation and authorization level to pub-sub into the nexagon network. > > It is going to be very hard to guess a valid EIDClient which an EdgeRTR > expects after AAA to whitelist provision. These EIDs are temporary and > expire after 15 minutes. > > Spoofed EIDClients which are sniffed are going to be detected by the > EdgeRTRs because of mismatched client RLOC. Spoofed client RLOCs are > detected by the mobile packet core. Oh, I didn't realize incoming packets on the EdgeRTR were dropped if the source EID doesn't match the RLOC associated with that EID. I thought that was a typical roaming case. If an attacker has to guess both a valid EID and its matching RLOC, I suspect that makes the attack much more difficult. (Though still far from impossible, depending on how many EID-RLOC pairs an EdgeRTR knows about at a time and how many guesses the attacker can get. IP allocation for the RLOC would play a huge factor too. If an ISP allocates RLOCs sequentially, it might be much easier to guess than if RLOCs are random /128s within guessable /64s. Though if an attacker can sniff RLOCs, the math changes again.) > Should we detail these aspects in security considerations ? Yes please. > 3) Fake news and client trust - > > This is a higher level concern as it is with many other protocols. > Privacy and reputation require trade-offs. The lisp-nexagon network uses > crowd-sourced street sampling to reflect current geo-state. Even the > most honest client may still be wrong, have faulty vision gear, gps > interruption, or buggy AI. Malicious clients may try to manipulate > geo-state to their advantage, clear their path from traffic, or simply > try to saw confusion. > > For this reason all detections are corroborated and trust level of each > client is constantly scored by the H3EIDServices and updates the AAA > system. This credit score update reflects the behavior of  the assigned > ephemeral client EID not the client, a car for ecample. But the AAA > system knows which client ID credentials the EID map to. The AAA system > does not need to know the geo association of these EID scores. They can > be aggregated from all H3EIDServices before handed to AAA. > > We can describe this general behavior even though its part of management > and orchestration and not part of the LISP-Nexagon interface specification. Sounds good, even if you mention it only at a high level. I think the fact that H3EIDServices are sharing reputation information back to the AAA service is important to mention. > After we clear these 3 key items to everyone satisfaction we can quickly > turn around the doc to one more iteration. > > Thank you in advance! > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 From nobody Mon Oct 19 22:34:25 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95DA3A0EF4 for ; Mon, 19 Oct 2020 22:34:23 -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=getnexar.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 H_GNrkhuAVOz for ; Mon, 19 Oct 2020 22:34:21 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B693A0EF3 for ; Mon, 19 Oct 2020 22:34:21 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id n18so518067wrs.5 for ; Mon, 19 Oct 2020 22:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=R4Z0BkzB6Uounj+eMLK8tCQu8WOnotk+GjBsEBD9Slc=; b=cv2ffp6rbxw4tC5sm/Y18bVjpS2AeBWJLlPArbOBB1IudKtkLa+xm+AjO0stGie7TT gUJQJ75yA+2e+FTW29iE8reDwtngAOiBQW+u1qTCq1diU6ZGgfOPCp1eR3NOUOo/EZng 8UmrO8MeZJQ/YNZw9GHMKk4CkWHJ99dt8XVww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=R4Z0BkzB6Uounj+eMLK8tCQu8WOnotk+GjBsEBD9Slc=; b=jQ797G1nQzjJ/RNSW0lveb060gaDPJCVTYRe3jYbfuLJ76dSzDszNfGKvFdqg90cp2 +rzp9xxSMGMTUuK17FHlchSs32Dxm7sdvWNnlcMiMJ0jy+QDeJoPF2kiTwNk9F9gKTwe FQjMRvOmGg9WOWUVzQsjn/Z6gzcdMPOiGIzgOizTKEIGApjgBm7gem/p9GlG3RHCNFX+ 9+WMoysOG+ntDEhMeothrBqgIqcgs0xfiE1PFZRfxGSXAq3D4EJKFp5aJ/Uo3sGT4ARq sHa4o63nWpX7qcGZKVzTYR9ceE75XGcuIM7yC1WYQvUmyF552wLYXkISVgtRUhsiRHjM LcPw== X-Gm-Message-State: AOAM533BsJgvgZ91kFGbO7aXRETnZnPdNz9NhkVD6Yp3hdanESajNR9U 3kAfAc86iD2ONrn5bclliU8wbA8AX46mSQ== X-Google-Smtp-Source: ABdhPJyUtkPO1BOSq+anRM7SL0KklGoy+jYFAdM5Y0P+3La+IO1w4sz3EfCvmPNy6K9oQxQXO0NTBw== X-Received: by 2002:a5d:40c3:: with SMTP id b3mr1423089wrq.157.1603172059365; Mon, 19 Oct 2020 22:34:19 -0700 (PDT) Received: from ?IPv6:2a02:14c:27c:b400:f5b5:cd6:d37a:6dc6? ([2a02:14c:27c:b400:f5b5:cd6:d37a:6dc6]) by smtp.gmail.com with ESMTPSA id s2sm943556wmf.45.2020.10.19.22.34.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 22:34:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_514BFEAB-FDA9-45FC-9CC1-0D03209FD1BE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sharon Barkai In-Reply-To: <5bd465d2-449c-6b1d-f83f-0e3489f1bf22@mandelberg.org> Date: Tue, 20 Oct 2020 08:34:16 +0300 Cc: Tero Kivinen , draft-ietf-lisp-nexagon.all@ietf.org, "lisp@ietf.org list" , secdir@ietf.org Message-Id: References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> <5bd465d2-449c-6b1d-f83f-0e3489f1bf22@mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 05:34:24 -0000 --Apple-Mail=_514BFEAB-FDA9-45FC-9CC1-0D03209FD1BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 20, 2020, at 02:34, David Mandelberg = wrote: >=20 > (I previously sent the email below on 2020-10-10, but I don't think it = went through due to an email server misconfiguration. Sending again now = that my email issues are fixed, I think) Made it! >=20 > On 10/9/20 1:32 PM, Sharon Barkai wrote: >> Sorry for the confusion, David! really want to thank you for putting = in the time, you clearly understood the draft completely and point to = areas we invested thought on but can improve the wording. >=20 > No worries. I'm just glad I noticed that my initial review email = didn't go through. Hopefully this one does? >=20 >> Before adjusting the draft would like to rehash together with the = group, Joel, and Luigi the themes pointed, which are spot on, so to = reach the best possible language. >> 1) End to end encryption - >> Nexagon uses LISP overlay encapsulations end to end: >> - between EIDClients and EdgeRTRs >> - between ingress and egress EdgeRTR >> - between EdgeRTRs and H3EIDServices >=20 > That doesn't cover "The H3ServiceEIDs themselves decrypt and parse = actual H3-R15 annotations" though, right? Is there any encryption of the = H3-R15 information all the way from EIDClient to H3EIDService? >=20 >> Depending on the specific nexagon as service we would like to offer = the option to encrypt all communications on these dynamic = encapsulations. >> We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies = RFC2631 key exchange over LISP tunnels, also DTLS was suggested. >> Should we determine one or just describe the geo privacy and = commercial exposure if encryption is not used, especially on the tunnels = between MobilityEIDClients and EdgeRTRs? >=20 > You understand the specifics of where this protocol will be used much = better than I do, so I think you're in a better place to choose between = picking one option or explaining the issues and letting implementers = decide on the encryption mechanism. In general, I'd lean towards picking = one good cipher suite and sticking to that (without making it difficult = to change things up in the future), but there can be good reasons not to = do that. I think we are in sync. Encryption is on a tunnel by tunnel basis (or = dynamic encapsulation to be more accurate) to and from the LISP edge = tunnel routers (EdgeRTRs), IPSec by default, leaving room for work like = lisp-crypto and lisp-wiregaurd being done, but not coupling the clients = and servers in that respect. There is still unclarity about the mismatch = between car-compute and edge-compute hw/sw updates and depreciation, and = car-compute and the car itself for that matter. >=20 >> 2) Spoofing and imposters - >> EdgeRTRs and H3EIDServices are provisioned in the service provider = edge network. EdgeRTRs which are added to the network are provisioned = with the mapping system, H3EIDServices are whitelist provisioned with = their designated EdgeRTRs. >> We rely on the edge network routers to detect and stop spoofing using = industry standard double-lookup source/dest mechanisms. >> Should we state so? >=20 > I think so, yes. I generally think it's good to be explicit when = relying on underlying infrastructure for security, so that if anybody = later tries to adapt a protocol to some different infrastructure, they = know what to pay attention to. Done. >=20 >> The MobilityEIDClients are behind mobile access networks and go = through AAA step before receiving ephemeral EIDs and EdgeRTR RLOCs as = anchors. >> This EID is based on their client ID credentials, and this EID is = whitelist provisioned by the AAA to the EdgeRTR given to the client as = an anchor. >> The ipv6 EIDs given to these clients reflect their credibility = reputation and authorization level to pub-sub into the nexagon network. >> It is going to be very hard to guess a valid EIDClient which an = EdgeRTR expects after AAA to whitelist provision. These EIDs are = temporary and expire after 15 minutes. >> Spoofed EIDClients which are sniffed are going to be detected by the = EdgeRTRs because of mismatched client RLOC. Spoofed client RLOCs are = detected by the mobile packet core. >=20 > Oh, I didn't realize incoming packets on the EdgeRTR were dropped if = the source EID doesn't match the RLOC associated with that EID. I = thought that was a typical roaming case. If an attacker has to guess = both a valid EID and its matching RLOC, I suspect that makes the attack = much more difficult. (Though still far from impossible, depending on how = many EID-RLOC pairs an EdgeRTR knows about at a time and how many = guesses the attacker can get. IP allocation for the RLOC would play a = huge factor too. If an ISP allocates RLOCs sequentially, it might be = much easier to guess than if RLOCs are random /128s within guessable = /64s. Though if an attacker can sniff RLOCs, the math changes again.) Right. LISP Mapped Overlay in this context is used to load-balance = clients as they network-login, and to =E2=80=9Cmap-reduce=E2=80=9D = compute aggregation to EID context. There is no change of EID-RLOC = binding due to random roaming. EID-RLOC pairs are whitelisted in EdgRTRs = by AAA and dev-ops. >=20 >> Should we detail these aspects in security considerations ? >=20 > Yes please. Done. >=20 >> 3) Fake news and client trust - >> This is a higher level concern as it is with many other protocols. = Privacy and reputation require trade-offs. The lisp-nexagon network uses = crowd-sourced street sampling to reflect current geo-state. Even the = most honest client may still be wrong, have faulty vision gear, gps = interruption, or buggy AI. Malicious clients may try to manipulate = geo-state to their advantage, clear their path from traffic, or simply = try to saw confusion. >> For this reason all detections are corroborated and trust level of = each client is constantly scored by the H3EIDServices and updates the = AAA system. This credit score update reflects the behavior of the = assigned ephemeral client EID not the client, a car for ecample. But the = AAA system knows which client ID credentials the EID map to. The AAA = system does not need to know the geo association of these EID scores. = They can be aggregated from all H3EIDServices before handed to AAA. >> We can describe this general behavior even though its part of = management and orchestration and not part of the LISP-Nexagon interface = specification. >=20 > Sounds good, even if you mention it only at a high level. I think the = fact that H3EIDServices are sharing reputation information back to the = AAA service is important to mention. Done. >=20 >> After we clear these 3 key items to everyone satisfaction we can = quickly turn around the doc to one more iteration. >> Thank you in advance! >> --szb >> Cell: +972.53.2470068 >> WhatsApp: +1.650.492.0794 This is the updated related security considerations text in = https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06 = In summary of main risk mitigations for the lisp-nexagon interface we = can say: (1) tapping: all communications are through dynamic tunnels therefore = may be encrypted using IP-Sec or other supported point to point underlay = standards. These are not static tunnels but lisp re-tunneling routers (RTRs) = perform all nexagon Overlay aggregation. (2) spoofing: it is very hard to guess a MobilityClientEID valid for a = short period of time. Clients and H3Services EIDs are whitelisted in = EdgeRTRs, Clients using the AAA procedure, H3Services via dev-ops. (3) impersonating: efforts to use MobilityClients and H3Services RLOCs = should be caught by the underlying service provider edge and access networks. = EID impersonating is caught by EdgeRTR EID RLOC whitelist mismatch. (4) credibility: the interface crowd-sources geo-state and does not = assume to trust single detections. Credit history track to MobilityClientEIDs by = as part of normal H3Services fact checking, aggregate scores affect AAA = credentials. (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and = geo-location, only AAA is aware of client IDs credentials and credit but not = geo-location. aggregate credit score span all H3Services administratively without = source. --Apple-Mail=_514BFEAB-FDA9-45FC-9CC1-0D03209FD1BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 20, 2020, at 02:34, David Mandelberg <david=3D40mandelberg.org@dmarc.ietf.org> = wrote:

(I previously sent the email below on 2020-10-10, but I don't = think it went through due to an email server misconfiguration. Sending = again now that my email issues are fixed, I think)

Made = it!


On 10/9/20 1:32 PM, Sharon = Barkai wrote:
Sorry = for the confusion, David! really want to thank you for putting in the = time, you clearly understood the draft completely and point to areas we = invested thought on but can improve the wording.

No worries. I'm just glad I = noticed that my initial review email didn't go through. Hopefully this = one does?

Before adjusting the draft would like to rehash together with = the group, Joel, and Luigi the themes pointed, which are spot on, so to = reach the best possible language.
1) End to end encryption = -
Nexagon uses LISP overlay encapsulations end to end:
- between EIDClients and EdgeRTRs
- between = ingress and egress EdgeRTR
- between EdgeRTRs and = H3EIDServices

That doesn't = cover "The H3ServiceEIDs themselves decrypt and parse actual H3-R15 = annotations" though, right? Is there any encryption of the H3-R15 = information all the way from EIDClient to H3EIDService?

Depending on the = specific  nexagon as service we would like to offer the option to = encrypt all communications on these dynamic encapsulations.
We could suggest IPSec, draft-ietf-lisp-crypto-10 which = specifies RFC2631 key exchange over LISP tunnels, also DTLS was = suggested.
Should we determine one or just describe the = geo privacy and commercial exposure if encryption is not used, = especially on the tunnels between MobilityEIDClients and EdgeRTRs?

You understand the specifics of = where this protocol will be used much better than I do, so I think = you're in a better place to choose between picking one option or = explaining the issues and letting implementers decide on the encryption = mechanism. In general, I'd lean towards picking one good cipher suite = and sticking to that (without making it difficult to change things up in = the future), but there can be good reasons not to do that.

I = think we are in sync. Encryption is on a tunnel by tunnel basis (or = dynamic encapsulation to be more accurate) to and from the LISP edge = tunnel routers (EdgeRTRs), IPSec by default, leaving room = for work like lisp-crypto and lisp-wiregaurd being done, but not = coupling the clients and servers in that respect. There is still = unclarity about the mismatch between car-compute and edge-compute = hw/sw updates and depreciation, and car-compute and the car itself = for that matter.


2) Spoofing and imposters -
EdgeRTRs and H3EIDServices are provisioned in the service = provider edge network. EdgeRTRs which are added to the network are = provisioned with the mapping system, H3EIDServices are whitelist = provisioned with their designated EdgeRTRs.
We rely on the = edge network routers to detect and stop spoofing using industry standard = double-lookup source/dest  mechanisms.
Should we = state so?

I think so, yes. I = generally think it's good to be explicit when relying on underlying = infrastructure for security, so that if anybody later tries to adapt a = protocol to some different infrastructure, they know what to pay = attention to.

Done.


The MobilityEIDClients are behind mobile access = networks and go through AAA step before receiving ephemeral EIDs and = EdgeRTR  RLOCs as anchors.
This EID is based on their = client ID credentials, and this EID is whitelist provisioned by the AAA = to the EdgeRTR given to the client as an anchor.
The ipv6 = EIDs given to these clients reflect their credibility reputation and = authorization level to pub-sub into the nexagon network.
It = is going to be very hard to guess a valid EIDClient which an EdgeRTR = expects after AAA to whitelist provision. These EIDs are temporary and = expire after 15 minutes.
Spoofed EIDClients which are = sniffed are going to be detected by the EdgeRTRs because of mismatched = client RLOC. Spoofed client RLOCs are detected by the mobile packet = core.

Oh, I didn't realize = incoming packets on the EdgeRTR were dropped if the source EID doesn't = match the RLOC associated with that EID. I thought that was a typical = roaming case. If an attacker has to guess both a valid EID and its = matching RLOC, I suspect that makes the attack much more difficult. = (Though still far from impossible, depending on how many EID-RLOC pairs = an EdgeRTR knows about at a time and how many guesses the attacker can = get. IP allocation for the RLOC would play a huge factor too. If an ISP = allocates RLOCs sequentially, it might be much easier to guess than if = RLOCs are random /128s within guessable /64s. Though if an attacker can = sniff RLOCs, the math changes again.)

Right. = LISP Mapped Overlay in this context is used to load-balance clients as = they network-login, and to =E2=80=9Cmap-reduce=E2=80=9D compute = aggregation to EID context. There is no change of EID-RLOC binding due = to random roaming. EID-RLOC pairs are whitelisted in EdgRTRs by AAA and = dev-ops.



Should we detail these = aspects in security considerations ?

Yes please.

Done.

3) Fake news and client trust -
This is a higher level concern as it is with many other = protocols. Privacy and reputation require trade-offs. The = lisp-nexagon network uses crowd-sourced street sampling to reflect = current geo-state. Even the most honest client may still be wrong, have = faulty vision gear, gps interruption, or buggy AI. Malicious clients may = try to manipulate geo-state to their advantage, clear their path from = traffic, or simply try to saw confusion.
For this reason = all detections are corroborated and trust level of each client is = constantly scored by the H3EIDServices and updates the AAA system. This = credit score update reflects the behavior of  the assigned = ephemeral client EID not the client, a car for ecample. But the AAA = system knows which client ID credentials the EID map to. The AAA system = does not need to know the geo association of these EID scores. They can = be aggregated from all H3EIDServices before handed to AAA.
We can describe this general behavior even though its part of = management and orchestration and not part of the LISP-Nexagon interface = specification.

Sounds good, = even if you mention it only at a high level. I think the fact that = H3EIDServices are sharing reputation information back to the AAA service = is important to mention.

Done.


After we clear these 3 key items to everyone = satisfaction we can quickly turn around the doc to one more = iteration.
Thank you in advance!
--szb
Cell: +972.53.2470068
WhatsApp: = +1.650.492.0794


This is the updated = related security considerations text in https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06

In summary of main risk mitigations =
for the lisp-nexagon interface we can say:

  (1) tapping: all communications are through dynamic tunnels therefore =
may be
  encrypted using IP-Sec or other supported point to point underlay =
standards.
  These are not static tunnels but lisp re-tunneling routers (RTRs) =
perform all
  nexagon Overlay aggregation.

  (2) spoofing: it is very hard to guess a MobilityClientEID valid for a =
short
  period of time. Clients and H3Services EIDs are whitelisted in =
EdgeRTRs,
  Clients using the AAA procedure, H3Services via dev-ops.

  (3) impersonating: efforts to use MobilityClients and H3Services RLOCs =
should
  be caught by the underlying service provider edge and access networks. =
EID
  impersonating is caught by EdgeRTR EID RLOC whitelist mismatch.

  (4) credibility: the interface crowd-sources geo-state and does not =
assume to
  trust single detections. Credit history track to MobilityClientEIDs by =
as part
  of normal H3Services fact checking, aggregate scores affect AAA =
credentials.

  (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and =
geo-location,
  only AAA is aware of client IDs credentials and credit but not =
geo-location.
  aggregate credit score span all H3Services administratively without =
source.



= --Apple-Mail=_514BFEAB-FDA9-45FC-9CC1-0D03209FD1BE-- From nobody Tue Oct 20 19:12:15 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE63A0A0B for ; Tue, 20 Oct 2020 19:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 (2048-bit key) header.d=mandelberg.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 m4HmEMYM38pS for ; Tue, 20 Oct 2020 19:12:11 -0700 (PDT) Received: from mail-pf1-x463.google.com (mail-pf1-x463.google.com [IPv6:2607:f8b0:4864:20::463]) (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 DED733A0A13 for ; Tue, 20 Oct 2020 19:12:11 -0700 (PDT) Received: by mail-pf1-x463.google.com with SMTP id 144so553521pfb.4 for ; Tue, 20 Oct 2020 19:12:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:dkim-signature:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oElIbPxmRpyqh9clPS0BSjRBHVs1/9zsrQdXnf/m6xI=; b=BL32/4EQWP95CvxBJ+pNRQdEmMf4FpWlJYb9sI0C91h8Anlhxv+TyFFUWD2zOo10tE ZN19tc0ebbgOlnsGzL6wtxec8LsNOlRwsEp5vEx/Is8KY9pMD+Tabjh7xeF1HZzfxbDH wtUO8eNIyjeRE/25j27B7HqC0zOwljyQe2Vq76PdmKX44+fN1wFC653DG0vqxo+5Zb0Z IOM50EBbX4eW6g5c9+gblKToshzYTz0W0H3DD9cZ3GgVRvMXFlNV4T5h2RNaYp92jif3 4KZ2oLgrrFIo3LwOiL8qgF1cQbnRa3UZ0JHSIZzr3WuECXPvGi0l4HmWv8RwTDw+jGZr bd6A== X-Gm-Message-State: AOAM531owAbGieGFLa7E6SIgyp2osgaX8v+i5sV7IRzapnVAOfQKSsOm LV85UyEV2jiWQwl8TKEEVKRg978H1jNW3RNodehNjyJgOpMrkw== X-Google-Smtp-Source: ABdhPJyCi5DA4rsJfxiuWxExN9WV3b+cN8iuNdA/nSVtjtIUXAaxUIGnUcZY68K8Lrxr2lDWixv0ii7MR47j X-Received: by 2002:aa7:962f:0:b029:156:51aa:d0a2 with SMTP id r15-20020aa7962f0000b029015651aad0a2mr975503pfg.20.1603246331188; Tue, 20 Oct 2020 19:12:11 -0700 (PDT) Received: from uriel.mandelberg.org (pool-100-0-196-177.bstnma.fios.verizon.net. [100.0.196.177]) by smtp-relay.gmail.com with ESMTPS id m7sm94823pjk.13.2020.10.20.19.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 19:12:11 -0700 (PDT) X-Relaying-Domain: mandelberg.org Received: from [192.168.1.162] (nevia [192.168.1.2]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6F0911C6066; Tue, 20 Oct 2020 22:12:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202009; t=1603246329; bh=z5HtFHbxdp1upFH7jVQwFXnx5LhxzzZKyWkMQ4JA62A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AcivY0c6beHC8LLfZJ6KTL6cFMoy/+fxRzrVpDXKRvnNCqVeVGDT4AclzGvItK279 +KbDHpxD9dpYx2qoHqh4m0uI/mR9w4D0ZzlNYKMUvtt/qNRcORg7qOdtDU6Jcta241 EMhsodAznENiZKzNKEEcq0U9CO8R0P1QTz+oNRAllMsZFIhpmBZh+gKQELk2m/w/WJ tXpWMWRUroBHH67gwpDFR4PfSfSS3dotj07Dox+RsbmjrfEEVy4PprP6Y7BBrwWTrv HdWc9pRZIY2sIxJhAqIvk1m5FoVbA/PuIb+QhINKZsZ5/NacJqiJWBWBYn8s0atWOH Ih7Ft8nCJKZQA== To: Sharon Barkai Cc: secdir@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-nexagon.all@ietf.org References: <160218848061.12936.5873889616190686198@ietfa.amsl.com> <6524FE35-8DE2-4A3B-89ED-7B9933104FB2@getnexar.com> <5bd465d2-449c-6b1d-f83f-0e3489f1bf22@mandelberg.org> From: David Mandelberg Message-ID: <1f0f6ce9-06b1-d92d-200b-29477efe4c38@mandelberg.org> Date: Tue, 20 Oct 2020 22:12:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 02:12:14 -0000 Thanks, draft-ietf-lisp-nexagon-06 addresses all of my concerns. (And sorry about the email issues and associated delays.) On 10/20/20 1:34 AM, Sharon Barkai wrote: > > >> On Oct 20, 2020, at 02:34, David Mandelberg >> > > wrote: >> >> (I previously sent the email below on 2020-10-10, but I don't think it >> went through due to an email server misconfiguration. Sending again >> now that my email issues are fixed, I think) > > Made it! > >> >> On 10/9/20 1:32 PM, Sharon Barkai wrote: >>> Sorry for the confusion, David! really want to thank you for putting >>> in the time, you clearly understood the draft completely and point to >>> areas we invested thought on but can improve the wording. >> >> No worries. I'm just glad I noticed that my initial review email >> didn't go through. Hopefully this one does? >> >>> Before adjusting the draft would like to rehash together with the >>> group, Joel, and Luigi the themes pointed, which are spot on, so to >>> reach the best possible language. >>> 1) End to end encryption - >>> Nexagon uses LISP overlay encapsulations end to end: >>> - between EIDClients and EdgeRTRs >>> - between ingress and egress EdgeRTR >>> - between EdgeRTRs and H3EIDServices >> >> That doesn't cover "The H3ServiceEIDs themselves decrypt and parse >> actual H3-R15 annotations" though, right? Is there any encryption of >> the H3-R15 information all the way from EIDClient to H3EIDService? >> >>> Depending on the specific  nexagon as service we would like to offer >>> the option to encrypt all communications on these dynamic encapsulations. >>> We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies >>> RFC2631 key exchange over LISP tunnels, also DTLS was suggested. >>> Should we determine one or just describe the geo privacy and >>> commercial exposure if encryption is not used, especially on the >>> tunnels between MobilityEIDClients and EdgeRTRs? >> >> You understand the specifics of where this protocol will be used much >> better than I do, so I think you're in a better place to choose >> between picking one option or explaining the issues and letting >> implementers decide on the encryption mechanism. In general, I'd lean >> towards picking one good cipher suite and sticking to that (without >> making it difficult to change things up in the future), but there can >> be good reasons not to do that. > > I think we are in sync. Encryption is on a tunnel by tunnel basis (or > dynamic encapsulation to be more accurate) to and from the LISP edge > tunnel router/s (EdgeRTRs), IPSec by default, leaving room for work like > lisp-crypto and lisp-wiregaurd being done, but not coupling the clients > and servers in that respect. There is still unclarity about the mismatch > between car-compute and edge-compute hw/sw updates and depreciation, and > car-compute and the car itself for that matter./ > >> >>> 2) Spoofing and imposters - >>> EdgeRTRs and H3EIDServices are provisioned in the service provider >>> edge network. EdgeRTRs which are added to the network are provisioned >>> with the mapping system, H3EIDServices are whitelist provisioned with >>> their designated EdgeRTRs. >>> We rely on the edge network routers to detect and stop spoofing using >>> industry standard double-lookup source/dest  mechanisms. >>> Should we state so? >> >> I think so, yes. I generally think it's good to be explicit when >> relying on underlying infrastructure for security, so that if anybody >> later tries to adapt a protocol to some different infrastructure, they >> know what to pay attention to. > > Done. > >> >>> The MobilityEIDClients are behind mobile access networks and go >>> through AAA step before receiving ephemeral EIDs and EdgeRTR  RLOCs >>> as anchors. >>> This EID is based on their client ID credentials, and this EID is >>> whitelist provisioned by the AAA to the EdgeRTR given to the client >>> as an anchor. >>> The ipv6 EIDs given to these clients reflect their credibility >>> reputation and authorization level to pub-sub into the nexagon network. >>> It is going to be very hard to guess a valid EIDClient which an >>> EdgeRTR expects after AAA to whitelist provision. These EIDs are >>> temporary and expire after 15 minutes. >>> Spoofed EIDClients which are sniffed are going to be detected by the >>> EdgeRTRs because of mismatched client RLOC. Spoofed client RLOCs are >>> detected by the mobile packet core. >> >> Oh, I didn't realize incoming packets on the EdgeRTR were dropped if >> the source EID doesn't match the RLOC associated with that EID. I >> thought that was a typical roaming case. If an attacker has to guess >> both a valid EID and its matching RLOC, I suspect that makes the >> attack much more difficult. (Though still far from impossible, >> depending on how many EID-RLOC pairs an EdgeRTR knows about at a time >> and how many guesses the attacker can get. IP allocation for the RLOC >> would play a huge factor too. If an ISP allocates RLOCs sequentially, >> it might be much easier to guess than if RLOCs are random /128s within >> guessable /64s. Though if an attacker can sniff RLOCs, the math >> changes again.) > > Right. LISP Mapped Overlay in this context is used to load-balance > clients as they network-login, and to “map-reduce” compute aggregation > to EID context. There is no change of EID-RLOC binding due to random > roaming. EID-RLOC pairs are whitelisted in EdgRTRs by AAA and dev-ops. > > >> >>> Should we detail these aspects in security considerations ? >> >> Yes please. > > Done. >> >>> 3) Fake news and client trust - >>> This is a higher level concern as it is with many other protocols. >>> Privacy and reputation require trade-offs. The lisp-nexagon network >>> uses crowd-sourced street sampling to reflect current geo-state. Even >>> the most honest client may still be wrong, have faulty vision gear, >>> gps interruption, or buggy AI. Malicious clients may try to >>> manipulate geo-state to their advantage, clear their path from >>> traffic, or simply try to saw confusion. >>> For this reason all detections are corroborated and trust level of >>> each client is constantly scored by the H3EIDServices and updates the >>> AAA system. This credit score update reflects the behavior of  the >>> assigned ephemeral client EID not the client, a car for ecample. But >>> the AAA system knows which client ID credentials the EID map to. The >>> AAA system does not need to know the geo association of these EID >>> scores. They can be aggregated from all H3EIDServices before handed >>> to AAA. >>> We can describe this general behavior even though its part of >>> management and orchestration and not part of the LISP-Nexagon >>> interface specification. >> >> Sounds good, even if you mention it only at a high level. I think the >> fact that H3EIDServices are sharing reputation information back to the >> AAA service is important to mention. > > Done. > >> >>> After we clear these 3 key items to everyone satisfaction we can >>> quickly turn around the doc to one more iteration. >>> Thank you in advance! >>> --szb >>> Cell: +972.53.2470068 >>> WhatsApp: +1.650.492.0794 > > > This is the updated related security considerations text in > https://tools.ietf.org/html/draft-ietf-lisp-nexagon-06 > > In summary of main risk mitigations for the lisp-nexagon interface we can say: > > (1) tapping: all communications are through dynamic tunnels therefore may be > encrypted using IP-Sec or other supported point to point underlay standards. > These are not static tunnels but lisp re-tunneling routers (RTRs) perform all > nexagon Overlay aggregation. > > (2) spoofing: it is very hard to guess a MobilityClientEID valid for a short > period of time. Clients and H3Services EIDs are whitelisted in EdgeRTRs, > Clients using the AAA procedure, H3Services via dev-ops. > > (3) impersonating: efforts to use MobilityClients and H3Services RLOCs should > be caught by the underlying service provider edge and access networks. EID > impersonating is caught by EdgeRTR EID RLOC whitelist mismatch. > > (4) credibility: the interface crowd-sources geo-state and does not assume to > trust single detections. Credit history track to MobilityClientEIDs by as part > of normal H3Services fact checking, aggregate scores affect AAA credentials. > > (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and geo-location, > only AAA is aware of client IDs credentials and credit but not geo-location. > aggregate credit score span all H3Services administratively without source. > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From nobody Wed Oct 21 07:22:27 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467443A10E0 for ; Wed, 21 Oct 2020 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=getnexar.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 NDnGgZyBwRio for ; Wed, 21 Oct 2020 07:22:22 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 39C8D3A11B5 for ; Wed, 21 Oct 2020 07:21:56 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id b8so3416431wrn.0 for ; Wed, 21 Oct 2020 07:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=r0vdFQN0lJgk6dbbAn0woSrTAJt3SxXcolDlaQYQqec=; b=mdlDeooWhrNp9+CrznqHgy63x8pmOVAgfeF1xD81oS77E8iFGt+5V9uJadISptoA3I E4hEdmQlB4h691+U7/4w8jidh6FAlcBzQ4CwxErYSpuXYVJn8C2rek1S7I8BEMbQBas/ 91j4nBL7KQK5w0rnFfwziJ1LOuJHCzqJuU/Nc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=r0vdFQN0lJgk6dbbAn0woSrTAJt3SxXcolDlaQYQqec=; b=XRhjiBhmzcKr2+xWrAsVILrXdvoQ0U6/+c6GyZEhKmTUuD0XMJHhxHq+tj+/Tnne03 aT5vGhFOH+tfMiuGhD5ClTHHJjpNzh0zx/uLK5rFmGjtWd17ygwsbi6BR4dEeR7MIDQy Hr9+wb5YsS+LrQyScyb8UCFAoSspWCGR9qtfmgf+dI3/Hd0gTSUDYoIdsUdrWWJUXJv0 t5GafYZ/64UWA9HFUY2/G00BcEFBYCNRIaLyAv6Zedow3DTm2LC6I6JWNxKPS6CBgmg8 0KxS6ALCmZ4TNdi3Lko0PkZOwq9UG3AY7eSCFMoFbRzafCTsRtgBUHNETUjbWXtlc8nk OfJg== X-Gm-Message-State: AOAM533wmjqtEFzXLtbG/gDhGxM7/KoJ0USRSD0LuPFhk+F5LeHumDZ7 lvsPAVx5gZIvhXPVr8a1csfaMg== X-Google-Smtp-Source: ABdhPJygMYkew45cTfIfPIOQyKthrmfjRzBR0JzucogMbUTr+1VxhR56lGy7itqcmHGLsfpGi7QZIA== X-Received: by 2002:a5d:5604:: with SMTP id l4mr4909501wrv.140.1603290114393; Wed, 21 Oct 2020 07:21:54 -0700 (PDT) Received: from ?IPv6:2a02:14c:27c:b400:34da:b65f:e9d6:62f? ([2a02:14c:27c:b400:34da:b65f:e9d6:62f]) by smtp.gmail.com with ESMTPSA id j7sm3510016wmc.7.2020.10.21.07.21.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Oct 2020 07:21:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Sharon Barkai In-Reply-To: <1f0f6ce9-06b1-d92d-200b-29477efe4c38@mandelberg.org> Date: Wed, 21 Oct 2020 17:21:52 +0300 Cc: secdir@ietf.org, "lisp@ietf.org list" , draft-ietf-lisp-nexagon.all@ietf.org Message-Id: <90D47E71-0310-4A4C-BA42-2655824D774A@getnexar.com> References: <1f0f6ce9-06b1-d92d-200b-29477efe4c38@mandelberg.org> To: David Mandelberg X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [secdir] [lisp] Secdir early review of draft-ietf-lisp-nexagon-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 14:22:24 -0000 Thanks David, everyone, for the time and attention for the review. Its not t= aken for granted.=20 --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Oct 21, 2020, at 05:12, David Mandelberg wrote: >=20 > =EF=BB=BFThanks, draft-ietf-lisp-nexagon-06 addresses all of my concerns. (= And sorry about the email issues and associated delays.) >=20 > On 10/20/20 1:34 AM, Sharon Barkai wrote: >>>> On Oct 20, 2020, at 02:34, David Mandelberg > wrote: >>>=20 >>> (I previously sent the email below on 2020-10-10, but I don't think it w= ent through due to an email server misconfiguration. Sending again now that m= y email issues are fixed, I think) >> Made it! >>>=20 >>> On 10/9/20 1:32 PM, Sharon Barkai wrote: >>>> Sorry for the confusion, David! really want to thank you for putting in= the time, you clearly understood the draft completely and point to areas we= invested thought on but can improve the wording. >>>=20 >>> No worries. I'm just glad I noticed that my initial review email didn't g= o through. Hopefully this one does? >>>=20 >>>> Before adjusting the draft would like to rehash together with the group= , Joel, and Luigi the themes pointed, which are spot on, so to reach the bes= t possible language. >>>> 1) End to end encryption - >>>> Nexagon uses LISP overlay encapsulations end to end: >>>> - between EIDClients and EdgeRTRs >>>> - between ingress and egress EdgeRTR >>>> - between EdgeRTRs and H3EIDServices >>>=20 >>> That doesn't cover "The H3ServiceEIDs themselves decrypt and parse actua= l H3-R15 annotations" though, right? Is there any encryption of the H3-R15 i= nformation all the way from EIDClient to H3EIDService? >>>=20 >>>> Depending on the specific nexagon as service we would like to offer th= e option to encrypt all communications on these dynamic encapsulations. >>>> We could suggest IPSec, draft-ietf-lisp-crypto-10 which specifies RFC26= 31 key exchange over LISP tunnels, also DTLS was suggested. >>>> Should we determine one or just describe the geo privacy and commercial= exposure if encryption is not used, especially on the tunnels between Mobil= ityEIDClients and EdgeRTRs? >>>=20 >>> You understand the specifics of where this protocol will be used much be= tter than I do, so I think you're in a better place to choose between pickin= g one option or explaining the issues and letting implementers decide on the= encryption mechanism. In general, I'd lean towards picking one good cipher s= uite and sticking to that (without making it difficult to change things up i= n the future), but there can be good reasons not to do that. >> I think we are in sync. Encryption is on a tunnel by tunnel basis (or dyn= amic encapsulation to be more accurate) to and from the LISP edge tunnel rou= ter/s (EdgeRTRs), IPSec by default, leaving room for work like lisp-crypto a= nd lisp-wiregaurd being done, but not coupling the clients and servers in th= at respect. There is still unclarity about the mismatch between car-compute a= nd edge-compute hw/sw updates and depreciation, and car-compute and the car i= tself for that matter./ >>>=20 >>>> 2) Spoofing and imposters - >>>> EdgeRTRs and H3EIDServices are provisioned in the service provider edge= network. EdgeRTRs which are added to the network are provisioned with the m= apping system, H3EIDServices are whitelist provisioned with their designated= EdgeRTRs. >>>> We rely on the edge network routers to detect and stop spoofing using i= ndustry standard double-lookup source/dest mechanisms. >>>> Should we state so? >>>=20 >>> I think so, yes. I generally think it's good to be explicit when relying= on underlying infrastructure for security, so that if anybody later tries t= o adapt a protocol to some different infrastructure, they know what to pay a= ttention to. >> Done. >>>=20 >>>> The MobilityEIDClients are behind mobile access networks and go through= AAA step before receiving ephemeral EIDs and EdgeRTR RLOCs as anchors. >>>> This EID is based on their client ID credentials, and this EID is white= list provisioned by the AAA to the EdgeRTR given to the client as an anchor.= >>>> The ipv6 EIDs given to these clients reflect their credibility reputati= on and authorization level to pub-sub into the nexagon network. >>>> It is going to be very hard to guess a valid EIDClient which an EdgeRTR= expects after AAA to whitelist provision. These EIDs are temporary and expi= re after 15 minutes. >>>> Spoofed EIDClients which are sniffed are going to be detected by the Ed= geRTRs because of mismatched client RLOC. Spoofed client RLOCs are detected b= y the mobile packet core. >>>=20 >>> Oh, I didn't realize incoming packets on the EdgeRTR were dropped if the= source EID doesn't match the RLOC associated with that EID. I thought that w= as a typical roaming case. If an attacker has to guess both a valid EID and i= ts matching RLOC, I suspect that makes the attack much more difficult. (Thou= gh still far from impossible, depending on how many EID-RLOC pairs an EdgeRT= R knows about at a time and how many guesses the attacker can get. IP alloca= tion for the RLOC would play a huge factor too. If an ISP allocates RLOCs se= quentially, it might be much easier to guess than if RLOCs are random /128s w= ithin guessable /64s. Though if an attacker can sniff RLOCs, the math change= s again.) >> Right. LISP Mapped Overlay in this context is used to load-balance client= s as they network-login, and to =E2=80=9Cmap-reduce=E2=80=9D compute aggrega= tion to EID context. There is no change of EID-RLOC binding due to random ro= aming. EID-RLOC pairs are whitelisted in EdgRTRs by AAA and dev-ops. >>>=20 >>>> Should we detail these aspects in security considerations ? >>>=20 >>> Yes please. >> Done. >>>=20 >>>> 3) Fake news and client trust - >>>> This is a higher level concern as it is with many other protocols. Priv= acy and reputation require trade-offs. The lisp-nexagon network uses crowd-s= ourced street sampling to reflect current geo-state. Even the most honest cl= ient may still be wrong, have faulty vision gear, gps interruption, or buggy= AI. Malicious clients may try to manipulate geo-state to their advantage, c= lear their path from traffic, or simply try to saw confusion. >>>> For this reason all detections are corroborated and trust level of each= client is constantly scored by the H3EIDServices and updates the AAA system= . This credit score update reflects the behavior of the assigned ephemeral c= lient EID not the client, a car for ecample. But the AAA system knows which c= lient ID credentials the EID map to. The AAA system does not need to know th= e geo association of these EID scores. They can be aggregated from all H3EID= Services before handed to AAA. >>>> We can describe this general behavior even though its part of managemen= t and orchestration and not part of the LISP-Nexagon interface specification= . >>>=20 >>> Sounds good, even if you mention it only at a high level. I think the fa= ct that H3EIDServices are sharing reputation information back to the AAA ser= vice is important to mention. >> Done. >>>=20 >>>> After we clear these 3 key items to everyone satisfaction we can quickl= y turn around the doc to one more iteration. >>>> Thank you in advance! >>>> --szb >>>> Cell: +972.53.2470068 >>>> WhatsApp: +1.650.492.0794 >> This is the updated related security considerations text in https://tools= .ietf.org/html/draft-ietf-lisp-nexagon-06 >> In summary of main risk mitigations for the lisp-nexagon interface we can= say: >> (1) tapping: all communications are through dynamic tunnels therefore m= ay be >> encrypted using IP-Sec or other supported point to point underlay stand= ards. >> These are not static tunnels but lisp re-tunneling routers (RTRs) perfo= rm all >> nexagon Overlay aggregation. >> (2) spoofing: it is very hard to guess a MobilityClientEID valid for a s= hort >> period of time. Clients and H3Services EIDs are whitelisted in EdgeRTRs= , >> Clients using the AAA procedure, H3Services via dev-ops. >> (3) impersonating: efforts to use MobilityClients and H3Services RLOCs s= hould >> be caught by the underlying service provider edge and access networks. E= ID >> impersonating is caught by EdgeRTR EID RLOC whitelist mismatch. >> (4) credibility: the interface crowd-sources geo-state and does not ass= ume to >> trust single detections. Credit history track to MobilityClientEIDs by a= s part >> of normal H3Services fact checking, aggregate scores affect AAA credent= ials. >> (5) privacy: Only EdgeRTRs are aware of both clients' RLOC and geo-loca= tion, >> only AAA is aware of client IDs credentials and credit but not geo-loca= tion. >> aggregate credit score span all H3Services administratively without sou= rce. >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Oct 22 08:34:10 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FC3A0A80 for ; Thu, 22 Oct 2020 08:34:09 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Gtncqg3eE8RH for ; Thu, 22 Oct 2020 08:34:05 -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 C5EFF3A0A73 for ; Thu, 22 Oct 2020 08:34:04 -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 09MFXtli025318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 11:34:00 -0400 Date: Thu, 22 Oct 2020 08:33:55 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com, Christian Huitema Cc: "secdir@ietf.org" Message-ID: <20201022153355.GD39170@kduck.mit.edu> References: <160176719670.27275.17469866976212039001@ietfa.amsl.com> <6471_1601884933_5F7AD305_6471_296_1_787AE7BB302AE849A7480A190F8B93303154CFFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <7daed45f-5bd7-e2bc-8663-8ca2bea7fb82@huitema.net> <27006_1601968923_5F7C1B1A_27006_382_1_787AE7BB302AE849A7480A190F8B93303154DA92@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27006_1601968923_5F7C1B1A_27006_382_1_787AE7BB302AE849A7480A190F8B93303154DA92@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-model-automation-framework-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 15:34:09 -0000 Christian, thanks for the review. Med, thanks for the updates and discussion. These exchanges improved the document a lot, so I had much less to cover in my No Objection ballot. -Ben On Tue, Oct 06, 2020 at 07:22:02AM +0000, mohamed.boucadair@orange.com wrote: > Hi Christian, > > You made good points. Thanks. > > I went with the following modifications to try to address them: > > * Update the title of the layering architecture to insist the view within the same operator: > > OLD: > Figure 3: Layering and Representation > > NEW > Figure 3: Layering and Representation Within a Network Operator > > And added this NEW text to further insist on this aspect: > > "All these elements (i.e., Orchestrator(s), > Controller(s), device(s)) are under the responsibility of the same > operator." > > * Mention how the composite service case is handled: > > NEW: > A composite service offered by a network operator may rely on > services that are offered by other operators. In such case, the > network operator acts as a "Customer" to request services from other > networks. The operators providing these services will then follow > the layering depicted in Figure 3. > > * Cover service violation (including "bad" partners): > > NEW: > A provider may rely on services offered by other providers to build > composite services. Appropriate mechanisms should be enabled by the > provider to monitor and detect a service disruption from these > providers. The characterization of a service disruption (including, > mean time between failures, mean time to repair), the escalation > procedure, and penalties are usually documented in contractual > agreements (e.g., Section 2.1 of [RFC4176]). Misbehaving peer > providers will thus be identified and appropriate countermeasures > will be applied. > > * Internal layer misalignment (corrupted data, manipulated data reporting, ..): > > NEW: > To detect misalignment between layers that might be induced by > misbehaving nodes, upper layers should continuously monitor the > perceived service (Section 4.1.3) and should proceed with checks to > assess that the provided service complies with the expected service > and that the data reported by an underlying layer is matching the > perceived service by the above layer. Typically, such checks are the > responsibility of the service diagnosis (Section 4.1.4). > > * Misbehaving Nodes: > > NEW: > Network operators should monitor and audit their networks to detect > misbehaving nodes and abnormal behaviors. For example, OAM discussed > in Section 4.1.4 can be used for that purpose. > > One pending comment is this one: > > > > [Med] It is up to each individual model to call out those, not > > this document. > > > > I am concerned about that. If that's the approach, then it should be > > stated very forcefully, as in some kind of MUST requirement for the > > development of service descriptions. > > Models must anyway comply with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines. These models must identify sensitive data and so on. I'm afraid that no change is needed for this one. > > Cheers, > Med > > > -----Message d'origine----- > > De: Christian Huitema [mailto:huitema@huitema.net] > > Envoy: lundi 5 octobre 2020 17:20 > > : BOUCADAIR Mohamed TGI/OLN ; > > secdir@ietf.org > > Cc: opsawg@ietf.org; last-call@ietf.org; draft-ietf-opsawg-model- > > automation-framework.all@ietf.org > > Objet: Re: [Last-Call] Secdir last call review of draft-ietf- > > opsawg-model-automation-framework-06 > > > > > > On 10/5/2020 1:02 AM, mohamed.boucadair@orange.com wrote: > > > Hi Christian, > > > > > > Thank you for the review. > > > > > > Please see inline. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De: Christian Huitema via Datatracker [mailto:noreply@ietf.org] > > >> Envoy: dimanche 4 octobre 2020 01:20 : secdir@ietf.org Cc: > > >> opsawg@ietf.org; last-call@ietf.org; draft-ietf-opsawg-model- > > >> automation-framework.all@ietf.org Objet: Secdir last call review > > of > > >> draft-ietf-opsawg-model- > > >> automation-framework-06 > > >> > > >> Reviewer: Christian Huitema > > >> Review result: Has Issues > > >> > > >> The document proposes an architecture for describing and > > provisioning > > >> services such as L3VPN or L2VPN. This is an ambitious > > architecture, > > >> aiming at providing end-to-end services over concatenations of > > >> network services provided by independent providers. > > > [Med] There is no such assumption in the draft but we can > > accommodate that case. > > > > It seems I was led to the wrong conclusion by the exposition of the > > layering between services, networks and devices. If you in fact > > assume that all the "networks" involved in the provision of the > > service are under the same management, by a single operator, then > > you should say that loudly and clearly in the draft. > > > > > I am concerned that the model does not expose trust > > >> boundaries during these providers, and that the security section > > does > > >> not discuss what happens when some providers try to game the > > system > > >> or otherwise fail to cooperate. > > > [Med] The various blocks discussed in the document are within the > > scope of the ** same provider **. > > > > > > That's said, if a provider relies upon other providers to deliver > > a given service, the model will apply in a recursive manner: That > > is, a network can act as a "customer" and request services from > > other networks. The peer network will then follow the various levels > > depicted in the architecture to deliver the service. > > > > > > Any failure of a peer provider to deliver an agreed service is a > > violation of the service level agreement. Such violation is detected > > by means of the service fulfilment/assurance and appropriate > > counter-measures will be followed. These counter-measures may be > > technical (switch to another provider) and/or contractual > > (penalties). > > > > > > We can add the following: > > > > > > A provider may rely upon services offered by other providers. > > > Appropriate mechanisms should be enabled by the provider to > > monitor > > > and detect a service disruption from these providers. The > > > characterization of a service disruption (including, mean time > > > between failures, mean time to repair), the escalation > > procedure, and > > > penalties are usually documented in contractual agreements. > > > Misbehaving peer providers will thus be identified and > > appropriate > > > countermeasures will be applied. > > > > Yes, please. > > > > >> The architecture organizes functions in three levels, service, > > >> network and device. Creation of services will trigger > > requirements on > > >> the networks, and then configuration of devices. Performance > > >> monitoring at the device level will inform service assurance and > > >> service optimizatio at the network level, and service assurance, > > >> optimization and diagnostic at the service level. The > > configurations > > >> and the performance measurements are described using Yang models. > > >> > > >> The Yang modules are designed to be accessed through secrure > > >> protocols, such as NETCONF over SSH or RESTCONF over HTTPS. This > > >> provides authentication of the servers and protection of the > > data, > > >> and allows implementation of access control. That's a good basis, > > but > > >> these processes only secure "point to point" > > >> interfaces between functions in the system. This presupposes > > honest > > >> cooperation between all actors, despite the fact that those > > actors > > >> often are in competition. > > >> > > >> The security considerations consider misconfiguration attacks > > such as > > >> the creation of forwarding loops, leakage of sensitive > > information, > > >> and traffic isolation issues. These are all interesting issues, > > but > > >> they are only mentioned in the architecture document as > > guidelines > > >> for the future development of actual services. I think issues > > such as > > >> the protection of sensitive information should be developed in > > the > > >> model itself, because they are generic. > > > [Med] It is up to each individual model to call out those, not > > this document. > > > > I am concerned about that. If that's the approach, then it should be > > stated very forcefully, as in some kind of MUST requirement for the > > development of service descriptions. > > > > > > > > > > The > > >> document articulates a hierarchy of Yang modules. Why does it not > > >> articulate the trust boundaries between the different actors? > > > [Med] Because the focus is on what happens within ** a single > > provider **. The interaction with other providers is no more than a > > provider acting as a "customer" for a service offered by another > > provider. > > > > > > The customer-facing interface is out of scope. We think this this > > now clarified with the review from Brian. > > > > I already asked that you state the single provider focus more > > clearly in introduction. I would appreciate if it was also called > > out in the security considerations. You assume that the various > > elements are under a single management authority, and thus are > > cooperating in good faith. > > Applying the model without that assumption opens the possibility of > > a range of attacks, in which competing actors might be dissimulating > > or manipulating information. You consider that out of scope, but > > then that also mean that the model should not be applied to > > orchestration of services across multiple operators. > > > > On the other end, there is the particular issue of the untrusted > > device. > > Consider the now classic scenario in which attackers manage to > > obtain the credential of some employees of the operator, maybe > > through a phishing attack. The attackers then use those credentials > > to gain access to a couple of network devices. Have you considered > > how they might leverage that access through the service > > architecture? Or, conversely, have you considered whether the > > architecture provides functions for the operator to detect and > > isolate such attacks? > > > > >> In addition to three classes of issues listed in the security > > >> considerations, I am also concerned with possibilities of > > retaining > > >> or falsifying data. What if an actor hides or fakes performance > > >> monitoring data, either out of malice or due to faulty > > equipement? > > > [Med] All the levels are under the responsibility of the same > > provider. An underlying level can report performance data but the > > above level can also proceed with OAM checks as per Section 4.1.4. > > Anomalies can thus be detected locally. > > > > > >> Will that disrupt the provision of the services? What tools are > > >> available to detect such behavior? What if a network provide > > >> overpromises, in order to attract contracts? I understand that > > the > > >> ultimate remedies lies in contract obligations and contract > > >> enforcement, but that enforcement has to be based on data. How is > > the > > >> architectur organizing the collection of the data? > > > [Med] This is the role of the assurance functions. See also the > > NEW text suggested above. > > Yes, the new text is useful. > > >> On a side note, I find that this architecture cites a large > > number of > > >> other drafts such as evpn, l2vpn, l3vpn, etc. These drafts in > > turn > > >> presumably cite the architecture, thus forcing the RFC production > > to > > >> organize all of them in a large publication cluster. > > >> Is it really required for the architecture document to cite all > > the > > >> documents that will later use it? > > > [Med] None of these drafts is normative. There is not risk to > > create a publication cluster. > > > > I will leave that to you and the RFC Production Center. That was > > just a side remark. > > > > -- Christian Huitema > > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Thu Oct 22 09:30:02 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2F3A0A0B; Thu, 22 Oct 2020 09:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1603383287; bh=XZlCS0YoijU26cf53E8BouYt2MetMRMQFXBaAjv/lYA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=NXzAv5yAaAWvLoHIUcez+7EE+67VgDX4KO6m7jRlejpA/seiZwFM9praX+gTKrTzE 9sOxpeSjZxE/s3hXeOrzLDjDwwOlSaTOMjwEjSPLtt6PtUgmBwZoxnkU5IgEF89zjC 8+vSpYnww1l5QFRbzh8qu8JzbbGSMdxtUrcDY0YU= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Oct 22 09:14:41 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CF23A0905; Thu, 22 Oct 2020 09:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1603383268; bh=XZlCS0YoijU26cf53E8BouYt2MetMRMQFXBaAjv/lYA=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=m3pvzsv+7VubN3CJHwHE5daG98gozrkviBbrtcHB+GBcX1rjzIgaZQfzE9zNSRf9I bJf6t7JFOXX4X1N1xhpHqRjdEFQmSSM/AtJ9STRGH4K3Gt79cjYZaqYPLq0jP0rd5E 15hMK2v2Z5F5fpJGLgPdMdy19ifSxXMhyHieo4Ko= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D703A07DB for ; Thu, 22 Oct 2020 09:14:22 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <160338326232.22717.6626095824085592126@ietfa.amsl.com> Date: Thu, 22 Oct 2020 09:14:22 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Reply-To: iesg@ietf.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 22 Oct 2020 09:30:01 -0700 Subject: [secdir] [new-work] WG Review: Secure Media Frames (sframe) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:14:53 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIGFuZCBS ZWFsLVRpbWUgQXJlYS4gVGhlCklFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHll dC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcwpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92 aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyCmNv bW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAyMC0x MS0wMS4KClNlY3VyZSBNZWRpYSBGcmFtZXMgKHNmcmFtZSkKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ3VycmVu dCBzdGF0dXM6IFByb3Bvc2VkIFdHCgpDaGFpcnM6CiAgVEJECgpBc3NpZ25lZCBBcmVhIERpcmVj dG9yOgogIE11cnJheSBLdWNoZXJhd3kgPHN1cGVydXNlckBnbWFpbC5jb20+CgpBcHBsaWNhdGlv bnMgYW5kIFJlYWwtVGltZSBBcmVhIERpcmVjdG9yczoKICBCYXJyeSBMZWliYSA8YmFycnlsZWli YUBjb21wdXRlci5vcmc+CiAgTXVycmF5IEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4K Ck1haWxpbmcgbGlzdDoKICBBZGRyZXNzOiBzZnJhbWVAaWV0Zi5vcmcKICBUbyBzdWJzY3JpYmU6 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZyYW1lCiAgQXJjaGl2ZTog aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9zZnJhbWUvCgpHcm91cCBw YWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL3NmcmFtZS8KCkNoYXJ0ZXI6 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1zZnJhbWUvCgpS ZWFsLXRpbWUgY29uZmVyZW5jaW5nIHNlc3Npb25zIGluY3JlYXNpbmdseSByZXF1aXJlIGVuZC10 by1lbmQgcHJvdGVjdGlvbnMKdGhhdCBwcmV2ZW50IGludGVybWVkaWFyeSBzZXJ2ZXJzIGZyb20g ZGVjcnlwdGluZyByZWFsLXRpbWUgbWVkaWEuICBUaGUgUEVSQwpXRyBkZXZlbG9wZWQgYSDigJxk b3VibGUgZW5jcnlwdGlvbuKAnSBzY2hlbWUgZm9yIGVuZC10by1lbmQgZW5jcnlwdGlvbiB0aGF0 IHdhcwpkZWVwbHkgdGllZCB0byBTUlRQIGFzIGl0cyB1bmRlcmx5aW5nIHRyYW5zcG9ydC4gIFRo aXMgZW50YW5nbGVtZW50IGhhcwpwcmV2ZW50ZWQgd2lkZXNwcmVhZCBkZXBsb3ltZW50LgoKVGhp cyB3b3JraW5nIGdyb3VwIHdpbGwgZGVmaW5lIHRoZSBTRnJhbWUgc2VjdXJlIGVuY2Fwc3VsYXRp b24gdG8gcHJvdmlkZQphdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gZm9yIHJlYWwtdGltZSBtZWRp YSBjb250ZW50IHRoYXQgaXMgaW5kZXBlbmRlbnQgb2YKdGhlIHVuZGVybHlpbmcgdHJhbnNwb3J0 LiAgVGhlIGVuY2Fwc3VsYXRpb24gd2lsbCBwcm92aWRlIHRoZSBmb2xsb3dpbmcKaW5mb3JtYXRp b24gdG8gY29uZmlndXJlIHRoZSBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24gZm9yIGVhY2ggZW5j cnlwdGlvbgpvcGVyYXRpb246CgoqIFNlbGVjdGlvbiBhbW9uZyBtdWx0aXBsZSBlbmNyeXB0aW9u IGtleXMgaW4gdXNlIGR1cmluZyBhIHJlYWwtdGltZSBzZXNzaW9uCgoqIEFuIGFsZ29yaXRobSBm b3IgZm9ybWluZyBhIHVuaXF1ZSBub25jZSB3aXRoaW4gdGhlIHNjb3BlIG9mIHRoZSBrZXkgYmFz ZWQKb24gaW5mb3JtYXRpb24gaW4gdGhlIGVuY2Fwc3VsYXRpb24gZnJhbWluZwoKVGhlIFNGcmFt ZSBzcGVjaWZpY2F0aW9uIHdpbGwgZGV0YWlsIHRoZSBzcGVjaWZpYyBzZWN1cml0eSBwcm9wZXJ0 aWVzIHRoYXQKdGhlIGVuY2Fwc3VsYXRpb24gcHJvdmlkZXMsIGFuZCBkaXNjdXNzIHRoZWlyIGlt cGxpY2F0aW9ucyB1bmRlciBjb21tb24gdXNhZ2UKc2NlbmFyaW9zIC8gdGhyZWF0IG1vZGVscy4K ClRoZSB0cmFuc3BvcnQtaW5kZXBlbmRlbmNlIG9mIHRoaXMgZW5jYXBzdWxhdGlvbiBtZWFucyB0 aGF0IGl0IGNhbiBiZSBhcHBsaWVkCmF0IGEgaGlnaGVyIGxldmVsIHRoYW4gaW5kaXZpZHVhbCBS VFAgcGF5bG9hZHMuICBGb3IgZXhhbXBsZSwgaXQgbWF5IGJlCmRlc2lyYWJsZSB0byBlbmNyeXB0 IHdob2xlIGZyYW1lcyB0aGF0IHNwYW4gbXVsdGlwbGUgcGFja2V0cyBpbiBvcmRlciB0bwphbW9y dGl6ZSB0aGUgb3ZlcmhlYWQgZnJvbSBmcmFtaW5nIGFuZCBhdXRoZW50aWNhdGlvbiB0YWdzLiAg SXQgbWF5IGFsc28gYmUKZGVzaXJhYmxlIHRvIGVuY3J5cHQgdW5pdHMgb2YgaW50ZXJtZWRpYXRl IHNpemUgKGUuZy4sIEguMjY0IE5BTFVzIG9yIEFWMQpPQlVzKSB0byBhbGxvdyBwYXJ0aWFsIGZy YW1lcyB0byBiZSB1c2FibGUuICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNob29zZQp3aGF0IGxl dmVscyBvZiBncmFudWxhcml0eSBjYW4gYmUgY29uZmlndXJlZCBpbiB0aGUgcHJvdG9jb2wuCgpB biBhcHBsaWNhdGlvbiB1c2luZyBTRnJhbWUgd2lsbCBuZWVkIHRvIGNvbmZpZ3VyZSBzZXZlcmFs IGFzcGVjdHMgb2YgaXRzCm9wZXJhdGlvbiwgZm9yIGV4YW1wbGU6CgoqIFNlbGVjdGluZyB3aGV0 aGVyIFNGcmFtZSBpcyB0byBiZSB1c2VkIGZvciBhIGdpdmVuIG1lZGlhIGZsb3cKCiogU3BlY2lm eWluZyB3aGljaCBlbmNyeXB0aW9uIGFsZ29yaXRobSBzaG91bGQgYmUgdXNlZAoKKiBQcm92aXNp b25pbmcga2V5cyBhbmQga2V5IGlkZW50aWZpZXJzIHRvIGVuZHBvaW50cwoKKiBTZWxlY3Rpbmcg dGhlIGdyYW51bGFyaXR5IGF0IHdoaWNoIFNGcmFtZSBlbmNyeXB0aW9uIGlzIGFwcGxpZWQgKGlm IHRoaXMgaXMKY29uZmlndXJhYmxlKQoKVGhpcyB3b3JraW5nIGdyb3VwLCBob3dldmVyLCB3aWxs IG5vdCBzcGVjaWZ5IHRoZSBzaWduYWxpbmcgcmVxdWlyZWQgdG8KY29uZmlndXJlIFNGcmFtZSBl bmNyeXB0aW9uLiAgSW4gcGFydGljdWxhciwgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBTSVAg b3IKU0RQIGFyZSBvdXQgb2Ygc2NvcGUuICBUaGlzIGlzIGJlY2F1c2UgU0ZyYW1lIGlzIGludGVu ZGVkIHRvIGJlIGFwcGxpZWQgYXMgYW4KYWRkaXRpb25hbCBsYXllciBvbiB0b3Agb2YgdGhlIGJh c2UgbGV2ZWxzIG9mIHByb3RlY3Rpb24gdGhhdCB0aGVzZSBwcm90b2NvbHMKcHJvdmlkZS4gIFRo aXMgd29ya2luZyBncm91cCB3aWxsLCBob3dldmVyLCBkZWZpbmUgdGhlIGd1aWRhbmNlIGZvciBo b3cKU0ZyYW1lIGludGVyYWN0cyB3aXRoIFJUUCAoZS5nLiwgd2l0aCByZWdhcmQgdG8gcGFja2V0 aXphdGlvbiwKZGVwYWNrZXRpemF0aW9uLCBhbmQgcmVjb3ZlcnkgYWxnb3JpdGhtcykgdG8gZW5z dXJlIHRoYXQgaXQgY2FuIGJlIHVzZWQgaW4KZW52aXJvbm1lbnRzIHN1Y2ggYXMgV2ViUlRDLiAg T3RoZXIgV2ViUlRDIGNoYW5nZXMgc3VjaCBhcyB0aGUgcGF5bG9hZCBmb3JtYXQKYW5kIG1ldGFk YXRhIGZvcm1hdCB3aWxsIGJlIGFkZHJlc3NlZCBieSB0aGUgQVZUQ09SRSB3b3JraW5nIGdyb3Vw LgoKSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCBzZXZlcmFsIHVzZSBjYXNlcyBvZiBTRnJhbWUgd2ls bCBpbnZvbHZlIGl0cyB1c2Ugd2l0aAprZXlzIGRlcml2ZWQgZnJvbSB0aGUgTUxTIGdyb3VwIGtl eSBleGNoYW5nZSBwcm90b2NvbC4gIFRoZSB3b3JraW5nIGdyb3VwCndpbGwgZGVmaW5lIGEgbWVj aGFuaXNtIGZvciBkb2luZyBTRnJhbWUgZW5jcnlwdGlvbiB1c2luZyBrZXlzIGZyb20gTUxTLApp bmNsdWRpbmcsIGZvciBleGFtcGxlLCB0aGUgZGVyaXZhdGlvbiBvZiBTRnJhbWUga2V5cyBwZXIg TUxTIGVwb2NoIGFuZCBwZXIKc2VuZGVyLgoKSW5wdXQgdG8gdGhlIFdHCgpQcm9wb3NhbHMgYWxy ZWFkeSBleGlzdGluZyByZWxhdGluZyB0byB0aGlzIGNoYXJ0ZXIgcHJvcG9zYWw6Cmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtb21hcmEtc2ZyYW1lLTAwCgpNaWxl c3RvbmVzOgoKICBKdW4gMjAyMSAtIFN1Ym1pdCBTRnJhbWUgc3BlY2lmaWNhdGlvbiB0byBJRVNH IChTdGFuZGFyZHMgVHJhY2spCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu Oct 22 12:11:58 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 577AF3A0B23 for ; Thu, 22 Oct 2020 12:11:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160339391634.7975.13332438741622250841@ietfa.amsl.com> Date: Thu, 22 Oct 2020 12:11:56 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 19:11:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-10-22 Reviewer LC end Draft Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-11 Christian Huitema R2020-10-08 draft-ietf-opsawg-model-automation-framework-07 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-11 For telechat 2020-11-05 Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-11 Vincent Roca 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Joseph Salowey 2020-10-28 draft-ietf-anima-grasp-api-07 Takeshi Takahashi 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Last calls: Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-11 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Christian Huitema R2020-10-08 draft-ietf-opsawg-model-automation-framework-07 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-11 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-19 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-13 Catherine Meadows 2020-10-21 draft-ietf-6lo-blemesh-08 Daniel Migault 2020-10-19 draft-ietf-bess-mvpn-fast-failover-11 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-12 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-13 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Yoav Nir 2020-11-16 draft-ietf-quic-invariants-11 Magnus Nystrom 2020-11-16 draft-ietf-quic-qpack-19 Hilarie Orman 2020-11-16 draft-ietf-quic-http-32 Radia Perlman 2020-11-16 draft-ietf-quic-tls-32 Derrell Piper 2020-11-16 draft-ietf-quic-recovery-32 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Vincent Roca 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Kyle Rose 2020-10-29 draft-ietf-emu-eap-tls13-11 Joseph Salowey 2020-10-28 draft-ietf-anima-grasp-api-07 Rich Salz 2020-10-28 draft-ietf-tls-md5-sha1-deprecate-04 Stefan Santesson 2020-10-28 draft-ietf-emu-eaptlscert-05 Yaron Sheffer 2020-10-27 draft-ietf-detnet-security-12 Yaron Sheffer R2020-10-16 draft-ietf-tls-exported-authenticator-13 Rifaat Shekh-Yusef 2020-10-27 draft-ietf-babel-source-specific-06 Valery Smyslov 2020-10-27 draft-ietf-babel-information-model-11 Robert Sparks 2020-10-23 draft-ietf-sfc-serviceid-header-10 Takeshi Takahashi 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-11 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-12 Next in the reviewer rotation: Francesca Palombini Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer From nobody Thu Oct 22 12:22:35 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 925473A0B50; Thu, 22 Oct 2020 12:22:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: tls@ietf.org, last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160339454955.8181.12347313700812158110@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 22 Oct 2020 12:22:29 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-md5-sha1-deprecate-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 19:22:30 -0000 Reviewer: Rich Salz Review result: Has Nits I'm the assigned security directorate reviewer for this draft. This is intended for use by the Sec ADs, but anyone else who gleans wisdom from this message is free to use it as they see fit. The document is READY. There are some nits, which can be found at https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-md5-sha1-deprecate-04.txt or by clicking on the "nits" tab on the datatracker page. Don't use MD5 or SHA1 as digests. If you do, bad people in shadows wearing hoodies will be able to steal your information, impersonate or break your TLS or other connections, and so on. This document gives more rationale and updates some RFC's. This NITS should be fixed, but this should be published. From nobody Fri Oct 23 05:36:14 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E6E3A0FCF; Fri, 23 Oct 2020 05:36:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: bess@ietf.org, last-call@ietf.org, draft-ietf-bess-mvpn-fast-failover.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160345656094.22100.7057001737682109381@ietfa.amsl.com> Reply-To: Daniel Migault Date: Fri, 23 Oct 2020 05:36:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 12:36:07 -0000 Reviewer: Daniel Migault Review result: Has Nits Hi, I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Please note also that my expertise in BGP is limited, so feel free to take these comments with a pitch of salt. Review Results: Has Nits Please find my comments below. Yours, Daniel Multicast VPN Fast Upstream Failover draft-ietf-bess-mvpn-fast-failover-11 Abstract This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a Standby Upstream PE. Though it might be just a nit, if MVPN designates multicast VPN, it might be clarifying to specify the acronym in the first sentence. This would later make the correlation with BGP MVPN clearer. 1. Introduction In the context of multicast in BGP/MPLS VPNs, it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers. Well I am not familiar with neither BGP nor MPLS. It seems that BGP/MLPS IP VPNS and MPLS/BGP IP VPNs are both used. I am wondering if there is a distinction between the two and a preferred way to designate these VPNs. My understanding is that the VPN-IPv4 characterizes the VPN while MPLS is used by the backbone for the transport. Since the PE are connected to the backbone the VPN-IPv4 needs to be labeled. Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S, C-G). This method does not provide a "fast failover" solution I understand the limitation is due to BGP convergence. when used alone, but can be used together with the mechanism described in Section 4 for a "fast failover" solution. Section 4 describes protocol extensions that can speed up failover by not requiring any multicast VPN routing message exchange at recovery time. Moreover, section 5 describes a "hot leaf standby" mechanism, that uses a combination of these two mechanisms. This approach has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints. [...] 3.1.1. mVPN Tunnel Root Tracking A condition to consider that the status of a P-tunnel is up is that the root of the tunnel, as determined in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes. That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address, but the root address in the x-PMSI Tunnel attribute. If BGP next-hop tracking is done for VPN routes and the root address of a given tunnel happens to be the same as the next-hop address in the BGP A-D Route advertising the tunnel, then checking, in unicast routing tables, whether the tunnel root is reachable, will be unnecessary duplication and thus will not bring any specific benefit. It seems to me that x-PMSI address designates a different interface than the one used by the Tunnel itself. If that is correct, such mechanisms seems to assume that one equipment up on one interface will be up on the other interfaces. I have the impression that a configuration change in a PE may end up in the P-tunnel being down, while the PE still being reachable though the x-PMSI Tunnel attribute. If that is a possible scenario, the current mechanisms may not provide more efficient mechanism than then those of the standard BGP. Similarly, it is assumed the tunnel is either up or down and the determination of not being up if being down. I am not convinced that the two only states. Typically services under DDoS may be down for a small amount of time. While this affects the network, there is not always a clear cut between the PE being up or down. [...] 3.1.6. BFD Discriminator Attribute P-tunnel status may be derived from the status of a multipoint BFD session [RFC8562] whose discriminator is advertised along with an x-PMSI A-D Route. This document defines the format and ways of using a new BGP attribute called the "BFD Discriminator". It is an optional transitive BGP attribute. In Section 7.2, IANA is requested to allocate the codepoint value (TBA2). The format of this attribute is shown in Figure 1. I feel that the sentence "In Section ... TBA2)." should be removed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Mode | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional TLVs ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Format of the BFD Discriminator Attribute Where: BFD Mode field is the one octet long. This specification defines the P2MP BFD Session as value 1 Section 7.2. Reserved field is three octets long, and the value MUST be zeroed on transmission and ignored on receipt. BFD Discriminator field is four octets long. Morin, et al. Expires April 5, 2021 [Page 7] Internet-Draft mVPN Fast Upstream Failover October 2020 Optional TLVs is the optional variable-length field that MAY be used in the BFD Discriminator attribute for future extensions. TLVs MAY be included in a sequential or nested manner. To allow for TLV nesting, it is advised to define a new TLV as a variable- length object. Figure 2 presents the Optional TLV format TLV that consists of: * one octet-long field of TLV 's Type value (Section 7.3) * one octet-long field of the length of the Value field in octets * variable length Value field. The length of a TLV MUST be multiple of four octets. I am wondering why the constraint on the length is not mentioned in the paragraph associated to the field - as opposed to a separate paragraph. [..] 8. Security Considerations This document describes procedures based on [RFC6513] and [RFC6514] and hence shares the security considerations respectively represented in these specifications. This document uses p2mp BFD, as defined in [RFC8562], which, in turn, is based on [RFC5880]. Security considerations relevant to each protocol are discussed in the respective protocol specifications. An implementation that supports this specification MUST use a mechanism to control the maximum number of p2mp BFD sessions that can be active at the same time. At a high level view - or at least my interpretation of it - the document proposes a mechanism based on BFD to detect fault in the path. Upon a fault detection a fail-over operation is instructed using BGP. This rocedure is expected to perform a faster fail-over than traditional BGP convergence on maintaining routing tables. Once the fail over has been performed, BFD is confirms the new path is "legitimate" and works. It seems correct to me that the current protocol relies on BGP / BFD security. That said, having BFD authentication based on MD5 or SHA1 may suggest that stronger primitives be recommended. While this does not concerns the current document, it seems to me that the information might be relayed to routing ADs. What remains unclear to me - and I assume this might be due to my lake or expertise in routing area - is the impact associated to performing a fail-over both on 1) the data plane and 2) the standard BGP way to establish routing tables. Regarding the data plane, I am wondering if fail-over results in a lost of packets for example - I suppose for example that at least the packets in the process of being forwarded might be lost. I believe that providing details on this may be good. If there are any impacts I would like to understand also in which cases the decision to perform a failover operation may result in more harm than the event that has been over-interpreted. An hypothetical scenario could be that the non reception of a BFD packet is interpreted as a PE being down while it may not be correct and the PE might have been simply under stress. A "too fast" fail-over may over interpreted it and perform a fail-over. If such things could happen, an attacker could leverage a micro event to perform network operation that are not negligible. Another way to see that is that an attacker might not have direct access to the control plan, but could use the data plan to generate a stress and sort of control the fail over. It seems to me that some text might be welcome to prevent such cases to happen. This could be guidance for declaring a tunnel down for example. Similarly, it would be good to add some text regarding the interferences with the non-fast forwarding fail over when performed by the standard BGP. Typically, my impression is that the fast fail-over mechanism is a local decision versus the BGP convergence that is more global. As a result, even with more time this two mechanisms may come with different outcomes. One such example to illustrate my purpose could be the following. Note that this is only illustrative of my purpose, and I let you find and pick on ethat is more appropriated. I am thinking of a case where a standby PE is be shared among multiple PEs - supposing this situation could occur. Typically, if PE_1, PE_2 are shared by PE_a, ..., PE_z. In case PE_a and PE_b are down, we expect PE_a to switch to PE_1 and PE_b to switch to PE_2. It seems to me that BGP would end up in such situation while a local decision may end up in PE_a and PE_a to switch to PE_1. From nobody Fri Oct 23 06:42:14 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC93A0DE1; Fri, 23 Oct 2020 06:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: idr@ietf.org, last-call@ietf.org, draft-ietf-idr-flow-spec-v6.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160346052821.25772.11548718218613853456@ietfa.amsl.com> Reply-To: Vincent Roca Date: Fri, 23 Oct 2020 06:42:08 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-idr-flow-spec-v6-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 13:42:08 -0000 Reviewer: Vincent Roca Review result: Ready Hello, 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. Summary: Ready The security considerations section is kept minimum since it only adds IPv6 format support to the "Dissemination of Flow Specification Rules" (draft-ietf-idr-rfc5575bis-26) document where the full Security Consideration discussion takes place. I also believe there is no added security issue. Typo: - Introduction: typo, add a final "s" to propose in: "and propose a subset..." Cheers, Vincent From nobody Sat Oct 24 15:01:02 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FFA3A0BFE; Sat, 24 Oct 2020 15:00:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: quic@ietf.org, draft-ietf-quic-invariants.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160357685316.11679.4088820464581761732@ietfa.amsl.com> Reply-To: Yoav Nir Date: Sat, 24 Oct 2020 15:00:53 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-quic-invariants-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 22:00:53 -0000 Reviewer: Yoav Nir Review result: Ready The contents of the "security and privacy considerations" section seems to be advice for middlebox authors. I think that it may have been better to name the section something else. However, there is no information that is missing, so I don't really have any recommendations for changing things. From nobody Sun Oct 25 10:35:26 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9783A0B98; Sun, 25 Oct 2020 10:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-ietf-babel-source-specific.all@ietf.org, last-call@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160364731499.17476.11455568556595523172@ietfa.amsl.com> Reply-To: Rifaat Shekh-Yusef Date: Sun, 25 Oct 2020 10:35:15 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-babel-source-specific-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 17:35:15 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Has Nits Section 7, Second Paragraph: “A node MUST NOT send more that one Source Prefix sub-TLV in a TLV, and a node receiving more than one Source Prefix sub-TLV in a single TLV SHOULD ignore this TLV. It MAY ignore the whole packet.” 1. “That” -> “Than” 2. This paragraph implies that a node might accept the TLV with more than one Source Prefix sub-TLV, but it does not state when a node can do that. You might want to elaborate on the conditions that a node is allowed to do that. Otherwise, the security considerations section seems reasonable and addresses the issues that might arise because of the added flexibility of the source prefix. Regards, Rifaat From nobody Mon Oct 26 07:54:40 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA63A0C06; Mon, 26 Oct 2020 07:54:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Valery Smyslov via Datatracker To: Cc: last-call@ietf.org, babel@ietf.org, draft-ietf-babel-information-model.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160372407981.20077.17795340180313190981@ietfa.amsl.com> Reply-To: Valery Smyslov Date: Mon, 26 Oct 2020 07:54:39 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 14:54:40 -0000 Reviewer: Valery Smyslov Review result: Has Issues 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 document defines an informational model for Babel routing protocol. This informational model can be used as a basis for creating various data models (e.g. YANG). The document is properly structured and well written, however I think that it has some issues concerned with security. Issues. 1. Section 3.1: babel-mac-algorithms: List of supported MAC computation algorithms. Possible values include "HMAC-SHA256", "BLAKE2s". BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired size of the MAC is a parameter for it. Where the size of MAC is specified? For HMAC with SHA256 I can at least imagine that full 256 bits output is used as a MAC... 2. Section 3.9: babel-cert-test: An operation that allows a hash of the provided input string to be created using the certificate public key and the SHA-256 hash algorithm. Input to this operation is a binary string. The output of this operation is the resulting hash, as a binary string. I failed to understand what this operation should do. Literally reading it is intended to produce SHA2-256 hash of public key and some arbitrary string (concatenated? in what order?). But then I failed to understand the purpose of this test. I would have understood if this operation provides signing of the arbitrary string using private key and SHA2-256 as a hash function (similarly to babel-mac-key-test), but it in not what is written... 3. Section 5 (Security Considerations): I think that text about keys (their length and properties) needs some expansion. First, there are no any RFC2119 words discouraging using short and weak keys (there is some text, but without RFC2119 words and with no references it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text about the properties of the keys, so I believe at least it must be referenced here. I also suspect that explicitly allowing zero-length and short keys will lead to situations when some network operators will use them (because they are not prohibited), thus subverting security properties of MAC... Nits. 1. Section 1 (Introduction): [I-D.ietf-babel-hmac] defines a security mechanism that allows Babel packets to be cryptographically authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism that allows Babel packets to be encrypted. DTLS provides both confidentiality and authentication of data, so to be formally correct, please add "both authenticated and" before "encrypted". 2. Section 2 (Overview) at the very end: Note that this overview is intended simply to be informative and is not normative. If there is any discrepancy between this overview and the detailed information model definitions in subsequent sections, the error is in this overview. This phrase makes me puzzled. The tree-like description of the information model in the Overview is very useful, however this phrase seems to discourage using it, because authors are not sure it is correct. I think it would be better for readers if authors double check that no discrepancy exists between the overview and the subsequent detailed description and remove this phrase. 3. Section 3.3: babel-mac-verify A Boolean flag indicating whether MAC hashes in incoming Babel packets are required to be present and are verified. If this parameter is "true", incoming packets are required to have a valid MAC hash. An implementation MAY choose to expose this parameter as read-only ("ro"). "MAC hashes" is strange wording, "MAC values" or just "MACs" are better in my opinion. 4. Section 3.8: babel-mac-key-use-sign: Indicates whether this key value is used to sign sent Babel packets. Sent packets are signed using this key if the value is "true". If the value is "false", this key is not used to sign sent Babel packets. An implementation MAY choose to expose this parameter as read-only ("ro"). "Sign" is not a good word when you describe symmetric key operations (which computing MAC belongs to). Although it is often used informally, I think that RFC should be more meticulous in selecting words. I'd rather replace it with "compute MAC" and rename the entry to babel-mac-key-use-compute or babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is OK. 5. Section 3.8: babel-mac-key-value: ... This value is of a length suitable for the associated babel-mac-key- algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. I wonder of the rationale for imposing the above restrictions on HMAC key length. HMAC can use keys of any length, but if the key is greater than block size of underlying hash function, then it's first hashed (small performance penalty). So I imagine that the rationale is to avoid this penalty. However, as RFC2104 states, key sizes greater than output length of the underlying hash function (32 bytes in case of SHA2-256) would not significantly increase the function strength, so it's just a waste of space. See also Issue 3 above. 6. Section 3.8: babel-mac-key-test: An operation that allows the MAC key and hash algorithm to be tested to see if they produce an expected outcome. Input to this operation is a binary string. The implementation is expected to create a hash of this string using the babel-mac-key- value and the babel-mac-key-algorithm. The output of this operation is the resulting hash, as a binary string. The text mixes up words "hash" and "MAC". MAC is not a hash (even if MAC algorithm is often based on hash function). As with my previous grunt, I'd like RFC to be more meticulous in selecting words. Please, avoid using "hash" here. 7. Section 5 (Security Considerations): ... This model requires that private keys never be exposed. The Babel security mechanisms that make use of these credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) identify what credentials can be used with those mechanisms. Please add "and MAC keys" after "private keys" since formally private keys are only defined for public key cryptography. 8. Section 5 (Security Considerations): MAC keys are allowed to be as short as zero-length. This is useful for testing. I wonder what's benefit of allowing zero-length keys for testing purposes. What is intended to be tested in this case? Implementation of MAC? Is it really needed outside test lab? Am I missing something? 9. Section 5 (Security Considerations): Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks. Formally, brute force attack with zero-length keys is not defined, since there is no key to find and all is in clear. Comments. 1. The document contains an entry in the Informational model defining which hash functions can be used with HMAC authentication. However, there is no corresponding entry of which ciphersuites can be used with DTLS. Is it up to DTLS library to select ciphersuites? From nobody Mon Oct 26 08:46:55 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4C3A0C70; Mon, 26 Oct 2020 08:46:50 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjNIhgl_Zp6b; Mon, 26 Oct 2020 08:46:49 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D0CCB3A0D90; Mon, 26 Oct 2020 08:46:32 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 09QFkSAf022467; Mon, 26 Oct 2020 16:46:28 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D716010B82D; Mon, 26 Oct 2020 16:46:28 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id dnfT-Q_CSl3X; Mon, 26 Oct 2020 16:46:22 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 3E7DF10B82A; Mon, 26 Oct 2020 16:46:18 +0100 (CET) Date: Mon, 26 Oct 2020 16:46:18 +0100 Message-ID: <871rhlyoqd.wl-jch@irif.fr> From: Juliusz Chroboczek To: Valery Smyslov Cc: , last-call@ietf.org, draft-ietf-babel-information-model.all@ietf.org, babel@ietf.org In-Reply-To: <160372407981.20077.17795340180313190981@ietfa.amsl.com> References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Mon, 26 Oct 2020 16:46:29 +0100 (CET) X-Miltered: at korolev with ID 5F96EF54.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F96EF54.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F96EF54.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] [babel] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 15:46:51 -0000 > babel-mac-algorithms: List of supported MAC computation algorithms. > Possible values include "HMAC-SHA256", "BLAKE2s". > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the desired > size of the MAC is a parameter for it. Where the size of MAC is specified? For > HMAC with SHA256 I can at least imagine that full 256 bits output is used as a > MAC... Right. The intent is that Blake2s is used with 32-octet keys and 16-octet hashes (collision-resistance is not a concern for Babel-MAC while dictionary attacks are). Barbara, I think that you should explicitly state that Blake2s implies 128-bit hashes. (You may also consider renaming BLAKE2s to BLAKE2s-128.) > babel-mac-key-value: > I wonder of the rationale for imposing the above restrictions on HMAC key > length. HMAC can use keys of any length, but if the key is greater than block > size of underlying hash function, then it's first hashed (small performance > penalty). So I imagine that the rationale is to avoid this penalty. This was discussed at length on the mailing list. It's not about performance, it's about making it more difficult to use an unsafe procedure for generating keys. Since Babel-MAC is vulnerable to dictionary attacks, the key must either be drawn randomly or generated using a procedure that is hardened against such attacks (scrypt, etc.). Applying the procedure described in RFC 2104 to a user-provided passphrase is not safe, and therefore we try to make it difficult for a naive user to do so. I am opposed to putting the RFC 2104 hashing procedure in the information model. Doing so would be a disservice to our users. > Short (and zero-length) keys and keys that make use of only > alphanumeric characters are highly susceptible to brute force > attacks. > Formally, brute force attack with zero-length keys is not defined, since there > is no key to find and all is in clear. The key length is not carried in the clear by the protocol. Guessing the key length requires a brute-force attack, even when it is zero. > 1. The document contains an entry in the Informational model defining which > hash functions can be used with HMAC authentication. However, there is no > corresponding entry of which ciphersuites can be used with DTLS. Is it up to > DTLS library to select ciphersuites? Yes. Babel-DTLS is intended to inherit the security properties of the system's DTLS library. If the DTLS library is unsafe, then Babel-DTLS must not be used until the library is fixed. -- Juliusz From nobody Mon Oct 26 10:39:43 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7F23A0DED; Mon, 26 Oct 2020 10:39:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: last-call@ietf.org, opsawg@ietf.org, draft-ietf-opsawg-model-automation-framework.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160373397407.25576.15002213877677598478@ietfa.amsl.com> Reply-To: Christian Huitema Date: Mon, 26 Oct 2020 10:39:34 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-opsawg-model-automation-framework-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 17:39:34 -0000 Reviewer: Christian Huitema Review result: Ready I have reviewed the differences between the recent draft-10 and draft-06 that I reviewed previously. Draft-10 includes the changes suggested during the discussion of my previous review with authors. The document is ready. From nobody Mon Oct 26 15:25:34 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 817E23A103C; Mon, 26 Oct 2020 15:25:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: sfc@ietf.org, draft-ietf-sfc-serviceid-header.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160375112449.28199.4653147392736464602@ietfa.amsl.com> Reply-To: Robert Sparks Date: Mon, 26 Oct 2020 15:25:24 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sfc-serviceid-header-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 22:25:25 -0000 Reviewer: Robert Sparks 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. This document has nits that should be addressed before publication as Proposed Standard RFC. Document reviewed: draft-ietf-sfc-serviceid-header-10 This document's security considerations rest on the premise that the information it discusses will be added, transported, consumed, and removed within a single administrative domain that is protected from eavesdroppers and malicious on-path attackers through administrative controls. It is quite upfront about that assumption, and the sfc documents it relies on make the same assertions. This document introduces a mechanism that intentionally allows identifiers (addresses) that would normally be hidden/contained behind a nat to be shared beyond that nat, but again, within that single administrative domain. NITS: There are many places where the language in the document needs to be simplified. There are also many places where 2119 language is being used in a way that does not make sense. In document order: Introduction paragraph 2, sentence 1. What does it mean to infer enforcement? Perhaps you mean "policies can be inferred"? Please simplify this sentence. Break the example into a separate sentence and add detail if you can. If possible, provide a reference to what you mean by "SFC-based differentiated traffic policies" means. Introduction paragraph 3. This whole paragraph has complicated, paragraph separated, phrases that should be written more simply. The next to last sentence (at 53 words) is particularly hard to follow. Introduction paragraph 4, last sentence. This sentence does not parse. Please rework it. Introduction paragraph 5. This one sentence paragraph was the most difficult in the document for me to read. Please break it into several simpler sentences. Section 3: at "In order to prevent interoperability issues, the data and their format to be injected in such header SHOULD be configured to nodes authorized to inject such headers." This is not a 2119 SHOULD. It's even not clear what "the data" is here. I suggest something like "The identifiers carried in the Context Headers are opaque. Nodes providing them and consuming them will be configured with the necessary information needed see into them." Section 3, at "Failures to inject such headers SHOULD be logged locally while a notification alarm MAY be sent to a Control Element. The details of sending notification alarms (i.e., the parameters affecting the transmission of the notification alarms depend on the information in the Context Header such as frequency, thresholds, and content of the alarm (full header, timestamp, etc.)) SHOULD be configurable." None of these are correct use of 2119. Consider re-framing the paragraph without using these terms. Section 3 at "That is, to strip such Context Headers." is not a sentence. Section 3 at the paragraph beginning "Depending on local policy". The structure of this paragraph is very odd. Doesn't base SFC say to preserve NSH at intermediaries? I suggest replacing this paragraph with something like "Normal SFC intermediary behavior preserves Network Service Headers. Local policy can require a proxy to strip ..." Section 3 at "NSH-aware SFs MUST be capable to run additional validation checks". This isn't 2119. Perhaps you mean to say "Be aware that local policies may require running additional validation checks at NSH-aware SFs". The whole paragraph can be simplified. Section 3 at "Multiple Subscriber Identifier Context Headers MAY be present in the NSH, each carrying a distinct opaque value but all pointing to the same subscriber." This is a place where a 2119 MUST _would_ make sense. Say "Such multiple headers MUST identify the same subscriber". I wonder, though, if you're closing a door on carrying multiple identities that you'll regret later. Section 4 first paragraph, first sentence: I suggest replacing "identifier is" with "identifiers are" Section 4 fifth paragraph: "defined as optional" -> "defined as an optional" Section 4 sixth paragraph. Similar to the section 3 paragraph I point to above, the structure here is very odd. Again, I suggest something like "Normal SFC intermediaries will preserve Context Headers, but local policy may require a proxy to to strip one after processing it." Section 4 seventh paragraph: "ocnlficting"->"conflicting". I assume the default behavior described here is specified in the base NSH docs? Security Considerations section paragraph 4: Consider "logging the content of ... is not advised" rather than using 2119 here. The paragraph would be better formulated if it explained the risk - SFs that _did_ use the context might be better off not logging them in many cases as well. From nobody Mon Oct 26 15:45:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678343A1056; Mon, 26 Oct 2020 15:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, NICE_REPLY_A=-0.247, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 BkUl04wGmull; Mon, 26 Oct 2020 15:45:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D99173A1050; Mon, 26 Oct 2020 15:45:28 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 09QMjRm1050062 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 26 Oct 2020 17:45:27 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1603752328; bh=3mzNJxJzwkf2XnjSyW3RLAMPfYoR1vgyRtPtX7RpR5k=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=AT4hW8roATTsUoAywxB2vRJgJspdIbyCTxn72sWLDpP9qDh+9wknKDOZVsVAoMXe+ BNOj090RnH0KACurkXXeZOVT5kV/Mq4qEqttrIqIJbaHMiF2IymhrCk4KfjCM0Ruif w6qqELN+gUCzHnRupEG8ucvsEWCAX1QK7chm+JEw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: secdir@ietf.org Cc: draft-ietf-sfc-serviceid-header.all@ietf.org, sfc@ietf.org, last-call@ietf.org References: <160375112449.28199.4653147392736464602@ietfa.amsl.com> From: Robert Sparks Message-ID: Date: Mon, 26 Oct 2020 17:45:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <160375112449.28199.4653147392736464602@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 22:45:36 -0000 Heh - one typo correction below (that might have been obvious, but...) On 10/26/20 5:25 PM, Robert Sparks via Datatracker wrote: > Reviewer: Robert Sparks > 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. > > This document has nits that should be addressed before publication as Proposed > Standard RFC. > > Document reviewed: draft-ietf-sfc-serviceid-header-10 > > This document's security considerations rest on the premise that the > information it discusses will be added, transported, consumed, and removed > within a single administrative domain that is protected from eavesdroppers and > malicious on-path attackers through administrative controls. It is quite > upfront about that assumption, and the sfc documents it relies on make the same > assertions. > > This document introduces a mechanism that intentionally allows identifiers > (addresses) that would normally be hidden/contained behind a nat to be shared > beyond that nat, but again, within that single administrative domain. > > NITS: > > There are many places where the language in the document needs to be > simplified. There are also many places where 2119 language is being used in a > way that does not make sense. > > In document order: > > Introduction paragraph 2, sentence 1. What does it mean to infer enforcement? > Perhaps you mean "policies can be inferred"? Please simplify this sentence. > Break the example into a separate sentence and add detail if you can. If > possible, provide a reference to what you mean by "SFC-based differentiated > traffic policies" means. > > Introduction paragraph 3. This whole paragraph has complicated, paragraph That last word should have been "comma" > separated, phrases that should be written more simply. The next to last > sentence (at 53 words) is particularly hard to follow. > > Introduction paragraph 4, last sentence. This sentence does not parse. Please > rework it. > > Introduction paragraph 5. This one sentence paragraph was the most difficult in > the document for me to read. Please break it into several simpler sentences. > > Section 3: at "In order to prevent interoperability issues, the data and their > format to be injected in such header SHOULD be configured to nodes authorized > to inject such headers." This is not a 2119 SHOULD. It's even not clear what > "the data" is here. I suggest something like "The identifiers carried in the > Context Headers are opaque. Nodes providing them and consuming them will be > configured with the necessary information needed see into them." > > Section 3, at "Failures to inject such headers SHOULD be logged locally while a > notification alarm MAY be sent to a Control Element. The details of sending > notification alarms (i.e., the parameters affecting the transmission of the > notification alarms depend on the information in the Context Header such as > frequency, thresholds, and content of the alarm (full header, timestamp, etc.)) > SHOULD be configurable." None of these are correct use of 2119. Consider > re-framing the paragraph without using these terms. > > Section 3 at "That is, to strip such Context Headers." is not a sentence. > > Section 3 at the paragraph beginning "Depending on local policy". The structure > of this paragraph is very odd. Doesn't base SFC say to preserve NSH at > intermediaries? I suggest replacing this paragraph with something like "Normal > SFC intermediary behavior preserves Network Service Headers. Local policy can > require a proxy to strip ..." > > Section 3 at "NSH-aware SFs MUST be capable to run additional validation > checks". This isn't 2119. Perhaps you mean to say "Be aware that local policies > may require running additional validation checks at NSH-aware SFs". The whole > paragraph can be simplified. > > Section 3 at "Multiple Subscriber Identifier Context Headers MAY be present in > the NSH, each carrying a distinct opaque value but all pointing to the same > subscriber." This is a place where a 2119 MUST _would_ make sense. Say "Such > multiple headers MUST identify the same subscriber". I wonder, though, if > you're closing a door on carrying multiple identities that you'll regret later. > > Section 4 first paragraph, first sentence: I suggest replacing "identifier is" > with "identifiers are" > > Section 4 fifth paragraph: "defined as optional" -> "defined as an optional" > > Section 4 sixth paragraph. Similar to the section 3 paragraph I point to above, > the structure here is very odd. Again, I suggest something like "Normal SFC > intermediaries will preserve Context Headers, but local policy may require a > proxy to to strip one after processing it." > > Section 4 seventh paragraph: "ocnlficting"->"conflicting". I assume the default > behavior described here is specified in the base NSH docs? > > Security Considerations section paragraph 4: Consider "logging the content of > ... is not advised" rather than using 2119 here. The paragraph would be better > formulated if it explained the risk - SFs that _did_ use the context might be > better off not logging them in many cases as well. > > > From nobody Mon Oct 26 15:55:24 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E6C3A106D; Mon, 26 Oct 2020 15:55:18 -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, FREEMAIL_FROM=0.001, 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 (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 JfBlm9lbGko8; Mon, 26 Oct 2020 15:55:15 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 E6B823A1069; Mon, 26 Oct 2020 15:55:14 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id a4so12292794lji.12; Mon, 26 Oct 2020 15:55:14 -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=L0tnCH2ZQw/jVFwvlpX6xu3ZGIJq7REwy8mY2nUHxsQ=; b=S6wEHW3UcHwOTeBjPkg8HPnjQMKYW3K/kOnDYfascwITv2HyOwCug7B+gtB2aQvSoC AbHufct4gIQsn1cAoNlXIYya311zLFjBEFPW6+U37vhmqFw06Rv0OZ0dpWsN1+LLNc/9 84Qv63OCwaqyey3Uw5Msz6WPvii6LHibnt79khH+FajaiareXw8xBceoPNYhRbmRE00Z LMmr72OsYqC24mDmziArnCoHaxg0HAw+2cq2nlaSGuBrdWAHcQ9hoAuyZpHY09fiGs5A 8yy1TS8xGsHi9IHa/K9QXZrjdk/1RLYKIGvXGtYJqhXrH6igxH0GcaWTj/c21ILH8KIu /sFg== 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=L0tnCH2ZQw/jVFwvlpX6xu3ZGIJq7REwy8mY2nUHxsQ=; b=RwYQerLthaMmkwP5avaZNxYNhK7mh/oCKZeYQtML8dwu/EugJmHn9F/ukdLmeuQM7m +MOhzWA9Haa5SGPwnKSPiENPDuVzRWXGOk8M1NdN3eLS99YvhTiG4zhccWyfzUim78AC 9nyKHi3YsmgkZbHHgL5jPwBTjdylOvYcS2zQpwyrbNZlf7lD0+zsi/4XiG74JfMMRkP2 ibOpYoRJ4fHPLQjC/Nz+1y4ceuwt9jejJmRqt0wrmxvqibhl7l9DUvdjaUi1QLQZHuYI Ffl0MnVh5t3fJK4xJw5QN5Vre9dJPmcSN8E4IPzmzDlH+nI69PPttlUWziZQbkAEKKUU ipbw== X-Gm-Message-State: AOAM5332KnsaCkebavnIkQe2YsDslFIMjRWkz097B6KZJRCbfXgfijgt kHeVF46/6+j7BbHcpZxtHd3yotdX3OKcTBioGbg= X-Google-Smtp-Source: ABdhPJwFxGDy8rMpdEnKm6Mx4lL62LCJmqLYhBq0Snzy+gOztjeVYQrKbIfjR9LAlum7u7byilwuL8JwMpe4K/r+Pi0= X-Received: by 2002:a2e:3015:: with SMTP id w21mr6505849ljw.23.1603752912943; Mon, 26 Oct 2020 15:55:12 -0700 (PDT) MIME-Version: 1.0 References: <160345656094.22100.7057001737682109381@ietfa.amsl.com> In-Reply-To: <160345656094.22100.7057001737682109381@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 26 Oct 2020 15:55:02 -0700 Message-ID: To: Daniel Migault Cc: secdir@ietf.org, BESS , last-call@ietf.org, draft-ietf-bess-mvpn-fast-failover.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000aefca805b29ad29d" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-bess-mvpn-fast-failover-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 22:55:19 -0000 --000000000000aefca805b29ad29d Content-Type: text/plain; charset="UTF-8" Hi Daniel, thank you for the review, comments, and helpful suggestions. I'll work on answering questions and addressing comments and respond soon. Regards, Greg On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker < noreply@ietf.org> wrote: > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > > I 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 > authors, document editors, and WG chairs should treat these comments just > like > any other IETF Last Call comments. Please note also that my expertise in > BGP is > limited, so feel free to take these comments with a pitch of salt. > > Review Results: Has Nits > > Please find my comments below. > > Yours, > Daniel > > > Multicast VPN Fast Upstream Failover > draft-ietf-bess-mvpn-fast-failover-11 > > Abstract > > This document defines multicast VPN extensions and procedures that > allow fast failover for upstream failures, by allowing downstream PEs > to take into account the status of Provider-Tunnels (P-tunnels) when > selecting the Upstream PE for a VPN multicast flow, and extending BGP > MVPN routing so that a C-multicast route can be advertised toward a > Standby Upstream PE. > > > Though it might be just a nit, if MVPN > designates multicast VPN, it might be > clarifying to specify the acronym in the > first sentence. This would later make > the correlation with BGP MVPN clearer. > > > > > 1. Introduction > > In the context of multicast in BGP/MPLS VPNs, it is desirable to > provide mechanisms allowing fast recovery of connectivity on > different types of failures. This document addresses failures of > elements in the provider network that are upstream of PEs connected > to VPN sites with receivers. > > > Well I am not familiar with neither BGP > nor MPLS. It seems that BGP/MLPS IP VPNS > and MPLS/BGP IP VPNs are both used. I am > wondering if there is a distinction > between the two and a preferred way to > designate these VPNs. My understanding > is that the VPN-IPv4 characterizes the > VPN while MPLS is used by the backbone > for the transport. Since the PE are > connected to the backbone the VPN-IPv4 > needs to be labeled. > > > > Section 3 describes local procedures allowing an egress PE (a PE > connected to a receiver site) to take into account the status of > P-tunnels to determine the Upstream Multicast Hop (UMH) for a given > (C-S, C-G). This method does not provide a "fast failover" solution > > I understand the limitation is due to > BGP convergence. > > > when used alone, but can be used together with the mechanism > described in Section 4 for a "fast failover" solution. > > Section 4 describes protocol extensions that can speed up failover by > not requiring any multicast VPN routing message exchange at recovery > time. > > Moreover, section 5 describes a "hot leaf standby" mechanism, that > uses a combination of these two mechanisms. This approach has > similarities with the solution described in [RFC7431] to improve > failover times when PIM routing is used in a network given some > topology and metric constraints. > > > [...] > > 3.1.1. mVPN Tunnel Root Tracking > > A condition to consider that the status of a P-tunnel is up is that > the root of the tunnel, as determined in the x-PMSI Tunnel attribute, > is reachable through unicast routing tables. In this case, the > downstream PE can immediately update its UMH when the reachability > condition changes. > > That is similar to BGP next-hop tracking for VPN routes, except that > the address considered is not the BGP next-hop address, but the root > address in the x-PMSI Tunnel attribute. > > If BGP next-hop tracking is done for VPN routes and the root address > of a given tunnel happens to be the same as the next-hop address in > the BGP A-D Route advertising the tunnel, then checking, in unicast > routing tables, whether the tunnel root is reachable, will be > unnecessary duplication and thus will not bring any specific benefit. > > > It seems to me that x-PMSI address > designates a different interface than > the one used by the Tunnel itself. If > that is correct, such mechanisms seems > to assume that one equipment up on one > interface will be up on the other > interfaces. I have the impression that a > configuration change in a PE may end up > in the P-tunnel being down, while the PE > still being reachable though the x-PMSI > Tunnel attribute. If that is a possible > scenario, the current mechanisms may not > provide more efficient mechanism than > then those of the standard BGP. > > Similarly, it is assumed the tunnel is > either up or down and the determination > of not being up if being down. I am not > convinced that the two only states. > Typically services under DDoS may be > down for a small amount of time. While > this affects the network, there is not > always a clear cut between the PE being > up or down. > > > > [...] > > 3.1.6. BFD Discriminator Attribute > > P-tunnel status may be derived from the status of a multipoint BFD > session [RFC8562] whose discriminator is advertised along with an > x-PMSI A-D Route. > > This document defines the format and ways of using a new BGP > attribute called the "BFD Discriminator". It is an optional > transitive BGP attribute. In Section 7.2, IANA is requested to > allocate the codepoint value (TBA2). The format of this attribute is > shown in Figure 1. > > > I feel that the sentence "In Section ... > TBA2)." should be removed. > > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Mode | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | BFD Discriminator | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Optional TLVs ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 1: Format of the BFD Discriminator Attribute > > Where: > > BFD Mode field is the one octet long. This specification defines > the P2MP BFD Session as value 1 Section 7.2. > > Reserved field is three octets long, and the value MUST be zeroed > on transmission and ignored on receipt. > > BFD Discriminator field is four octets long. > > > > > > Morin, et al. Expires April 5, 2021 [Page 7] > > Internet-Draft mVPN Fast Upstream Failover October 2020 > > > Optional TLVs is the optional variable-length field that MAY be > used in the BFD Discriminator attribute for future extensions. > TLVs MAY be included in a sequential or nested manner. To allow > for TLV nesting, it is advised to define a new TLV as a variable- > length object. Figure 2 presents the Optional TLV format TLV that > consists of: > > * one octet-long field of TLV 's Type value (Section 7.3) > > * one octet-long field of the length of the Value field in octets > > * variable length Value field. > > The length of a TLV MUST be multiple of four octets. > > I am wondering why the constraint on the > length is not mentioned in the paragraph > associated to the field - as opposed to > a separate paragraph. > > > > [..] > > 8. Security Considerations > > This document describes procedures based on [RFC6513] and [RFC6514] > and hence shares the security considerations respectively represented > in these specifications. > > This document uses p2mp BFD, as defined in [RFC8562], which, in turn, > is based on [RFC5880]. Security considerations relevant to each > protocol are discussed in the respective protocol specifications. An > implementation that supports this specification MUST use a mechanism > to control the maximum number of p2mp BFD sessions that can be active > at the same time. > > > At a high level view - or at least my > interpretation of it - the document > proposes a mechanism based on BFD to > detect fault in the path. Upon a fault > detection a fail-over operation is > instructed using BGP. This rocedure is > expected to perform a faster fail-over > than traditional BGP convergence on > maintaining routing tables. Once the > fail over has been performed, BFD is > confirms the new path is "legitimate" > and works. > > It seems correct to me that the current > protocol relies on BGP / BFD security. > That said, having BFD authentication > based on MD5 or SHA1 may suggest that > stronger primitives be recommended. > While this does not concerns the current > document, it seems to me that the > information might be relayed to routing > ADs. > > What remains unclear to me - and I > assume this might be due to my lake or > expertise in routing area - is the impact > associated to performing a fail-over > both on 1) the data plane and 2) the > standard BGP way to establish routing > tables. > > Regarding the data plane, I am wondering > if fail-over results in a lost of > packets for example - I suppose for > example that at least the packets in the > process of being forwarded might be > lost. I believe that providing details > on this may be good. > > If there are any impacts I would like to > understand also in which cases the > decision to perform a failover operation > may result in more harm than the event > that has been over-interpreted. An > hypothetical scenario could be that the > non reception of a BFD packet is > interpreted as a PE being down while it > may not be correct and the PE might have > been simply under stress. A "too fast" fail-over > may over interpreted it and perform a > fail-over. If such things could happen, > an attacker could leverage a micro event > to perform network operation that are > not negligible. Another way to see that > is that an attacker might not have > direct access to the control plan, but > could use the data plan to generate a > stress and sort of control the fail > over. It seems to me that some text > might be welcome to prevent such cases > to happen. This could be guidance for > declaring a tunnel down for example. > > Similarly, it would be good to add some > text regarding the interferences with > the non-fast forwarding fail over when > performed by the standard BGP. > Typically, my impression is that the > fast fail-over mechanism is a local > decision versus the BGP convergence that > is more global. As a result, even with > more time this two mechanisms may come > with different outcomes. One such > example to illustrate my purpose could > be the following. Note that this is only > illustrative of my purpose, and I let > you find and pick on ethat is more > appropriated. I am thinking of a case > where a standby PE is be shared among > multiple PEs - supposing this situation > could occur. Typically, if PE_1, PE_2 > are shared by PE_a, ..., PE_z. In case > PE_a and PE_b are down, we expect PE_a > to switch to PE_1 and PE_b to switch to > PE_2. It seems to me that BGP would end > up in such situation while a local > decision may end up in PE_a and PE_a to > switch to PE_1. > > > > > > --000000000000aefca805b29ad29d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
thank you for the review, comments, and hel= pful suggestions. I'll work on answering questions and addressing comme= nts and respond soon.

Regards,
Greg

On Fri, Oct 23, 2020 at 5:36 AM Daniel Migault via Datatracker <noreply@ietf.org> wrote:
Reviewer: Daniel Migault
Review result: Has Nits

Hi,


I reviewed this document as part of the Security Directorate's ongoing = effort to
review all IETF documents being processed by the IESG.=C2=A0 These comments= were
written primarily for the benefit of the Security Area Directors.=C2=A0 Doc= ument
authors, document editors, and WG chairs should treat these comments just l= ike
any other IETF Last Call comments.=C2=A0 Please note also that my expertise= in BGP is
limited, so feel free to take these comments with a pitch of salt.=C2=A0
Review Results: Has Nits

Please find my comments below.

Yours,
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Multicast VP= N Fast Upstream Failover
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-be= ss-mvpn-fast-failover-11

Abstract

=C2=A0 =C2=A0This document defines multicast VPN extensions and procedures = that
=C2=A0 =C2=A0allow fast failover for upstream failures, by allowing downstr= eam PEs
=C2=A0 =C2=A0to take into account the status of Provider-Tunnels (P-tunnels= ) when
=C2=A0 =C2=A0selecting the Upstream PE for a VPN multicast flow, and extend= ing BGP
=C2=A0 =C2=A0MVPN routing so that a C-multicast route can be advertised tow= ard a
=C2=A0 =C2=A0Standby Upstream PE.

<mglt>
Though it might be just a nit, if MVPN
designates multicast VPN, it might be
clarifying to specify the acronym in the
first sentence. This would later make
the correlation with BGP MVPN clearer.

</mglt>


1.=C2=A0 Introduction

=C2=A0 =C2=A0In the context of multicast in BGP/MPLS VPNs, it is desirable = to
=C2=A0 =C2=A0provide mechanisms allowing fast recovery of connectivity on =C2=A0 =C2=A0different types of failures.=C2=A0 This document addresses fai= lures of
=C2=A0 =C2=A0elements in the provider network that are upstream of PEs conn= ected
=C2=A0 =C2=A0to VPN sites with receivers.

<mglt>
Well I am not familiar with neither BGP
nor MPLS. It seems that BGP/MLPS IP VPNS
and MPLS/BGP IP VPNs are both used. I am
wondering if there is a distinction
between the two and a preferred way to
designate these VPNs.=C2=A0 My understanding
is that the VPN-IPv4 characterizes the
VPN while MPLS is used by the backbone
for the transport.=C2=A0 Since the PE are
connected to the backbone the VPN-IPv4
needs to be labeled.

</mglt>

=C2=A0 =C2=A0Section 3 describes local procedures allowing an egress PE (a = PE
=C2=A0 =C2=A0connected to a receiver site) to take into account the status = of
=C2=A0 =C2=A0P-tunnels to determine the Upstream Multicast Hop (UMH) for a = given
=C2=A0 =C2=A0(C-S, C-G).=C2=A0 This method does not provide a "fast fa= ilover" solution
<mglt>
I understand the limitation is due to
BGP convergence.

</mglt>
=C2=A0 =C2=A0when used alone, but can be used together with the mechanism =C2=A0 =C2=A0described in Section 4 for a "fast failover" solutio= n.

=C2=A0 =C2=A0Section 4 describes protocol extensions that can speed up fail= over by
=C2=A0 =C2=A0not requiring any multicast VPN routing message exchange at re= covery
=C2=A0 =C2=A0time.

=C2=A0 =C2=A0Moreover, section 5 describes a "hot leaf standby" m= echanism, that
=C2=A0 =C2=A0uses a combination of these two mechanisms.=C2=A0 This approac= h has
=C2=A0 =C2=A0similarities with the solution described in [RFC7431] to impro= ve
=C2=A0 =C2=A0failover times when PIM routing is used in a network given som= e
=C2=A0 =C2=A0topology and metric constraints.


[...]

3.1.1.=C2=A0 mVPN Tunnel Root Tracking

=C2=A0 =C2=A0A condition to consider that the status of a P-tunnel is up is= that
=C2=A0 =C2=A0the root of the tunnel, as determined in the x-PMSI Tunnel att= ribute,
=C2=A0 =C2=A0is reachable through unicast routing tables.=C2=A0 In this cas= e, the
=C2=A0 =C2=A0downstream PE can immediately update its UMH when the reachabi= lity
=C2=A0 =C2=A0condition changes.

=C2=A0 =C2=A0That is similar to BGP next-hop tracking for VPN routes, excep= t that
=C2=A0 =C2=A0the address considered is not the BGP next-hop address, but th= e root
=C2=A0 =C2=A0address in the x-PMSI Tunnel attribute.

=C2=A0 =C2=A0If BGP next-hop tracking is done for VPN routes and the root a= ddress
=C2=A0 =C2=A0of a given tunnel happens to be the same as the next-hop addre= ss in
=C2=A0 =C2=A0the BGP A-D Route advertising the tunnel, then checking, in un= icast
=C2=A0 =C2=A0routing tables, whether the tunnel root is reachable, will be<= br> =C2=A0 =C2=A0unnecessary duplication and thus will not bring any specific b= enefit.

<mglt>
It seems to me that x-PMSI address
designates a different interface than
the one used by the Tunnel itself. If
that is correct, such mechanisms seems
to assume that one equipment up on one
interface will be up on the other
interfaces. I have the impression that a
configuration change in a PE may end up
in the P-tunnel being down, while the PE
still being reachable though the x-PMSI
Tunnel attribute. If that is a possible
scenario, the current mechanisms may not
provide more efficient mechanism than
then those of the standard BGP.

Similarly, it is assumed the tunnel is
either up or down and the determination
of not being up if being down.=C2=A0 I am not
convinced that the two only states.
Typically services under DDoS may be
down for a small amount of time. While
this affects the network, there is not
always a clear cut between the PE being
up or down.
</mglt>


[...]

3.1.6.=C2=A0 BFD Discriminator Attribute

=C2=A0 =C2=A0P-tunnel status may be derived from the status of a multipoint= BFD
=C2=A0 =C2=A0session [RFC8562] whose discriminator is advertised along with= an
=C2=A0 =C2=A0x-PMSI A-D Route.

=C2=A0 =C2=A0This document defines the format and ways of using a new BGP =C2=A0 =C2=A0attribute called the "BFD Discriminator".=C2=A0 It i= s an optional
=C2=A0 =C2=A0transitive BGP attribute.=C2=A0 In Section 7.2, IANA is reques= ted to
=C2=A0 =C2=A0allocate the codepoint value (TBA2).=C2=A0 The format of this = attribute is
=C2=A0 =C2=A0shown in Figure 1.

<mglt>
I feel that the sentence "In Section ...
TBA2)." should be removed.

</mglt>


=C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 BFD Mode=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFD Discriminator=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
=C2=A0 =C2=A0 =C2=A0 ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Optional TLVs=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0~
=C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 1: Format of the BFD Discr= iminator Attribute

=C2=A0 =C2=A0Where:

=C2=A0 =C2=A0 =C2=A0 BFD Mode field is the one octet long.=C2=A0 This speci= fication defines
=C2=A0 =C2=A0 =C2=A0 the P2MP BFD Session as value 1 Section 7.2.

=C2=A0 =C2=A0 =C2=A0 Reserved field is three octets long, and the value MUS= T be zeroed
=C2=A0 =C2=A0 =C2=A0 on transmission and ignored on receipt.

=C2=A0 =C2=A0 =C2=A0 BFD Discriminator field is four octets long.





Morin, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires April = 5, 2021=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page = 7]

Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mVPN Fast Upstream Failover= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 October 2020


=C2=A0 =C2=A0 =C2=A0 Optional TLVs is the optional variable-length field th= at MAY be
=C2=A0 =C2=A0 =C2=A0 used in the BFD Discriminator attribute for future ext= ensions.
=C2=A0 =C2=A0 =C2=A0 TLVs MAY be included in a sequential or nested manner.= =C2=A0 To allow
=C2=A0 =C2=A0 =C2=A0 for TLV nesting, it is advised to define a new TLV as = a variable-
=C2=A0 =C2=A0 =C2=A0 length object.=C2=A0 Figure 2 presents the Optional TL= V format TLV that
=C2=A0 =C2=A0 =C2=A0 consists of:

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of TLV 's Type value = (Section 7.3)

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 one octet-long field of the length of the Valu= e field in octets

=C2=A0 =C2=A0 =C2=A0 *=C2=A0 variable length Value field.

=C2=A0 =C2=A0 =C2=A0 The length of a TLV MUST be multiple of four octets. <mglt>
I am wondering why the constraint on the
length is not mentioned in the paragraph
associated to the field - as opposed to
a=C2=A0 separate paragraph.

</mglt>

[..]

8.=C2=A0 Security Considerations

=C2=A0 =C2=A0This document describes procedures based on [RFC6513] and [RFC= 6514]
=C2=A0 =C2=A0and hence shares the security considerations respectively repr= esented
=C2=A0 =C2=A0in these specifications.

=C2=A0 =C2=A0This document uses p2mp BFD, as defined in [RFC8562], which, i= n turn,
=C2=A0 =C2=A0is based on [RFC5880].=C2=A0 Security considerations relevant = to each
=C2=A0 =C2=A0protocol are discussed in the respective protocol specificatio= ns.=C2=A0 An
=C2=A0 =C2=A0implementation that supports this specification MUST use a mec= hanism
=C2=A0 =C2=A0to control the maximum number of p2mp BFD sessions that can be= active
=C2=A0 =C2=A0at the same time.

<mglt>
At a high level view - or at least my
interpretation of it - the document
proposes a mechanism based on BFD to
detect fault in the path.=C2=A0 Upon a fault
detection a fail-over operation is
instructed using BGP. This rocedure is
expected to perform a faster fail-over
than traditional BGP convergence on
maintaining routing tables. Once the
fail over has been performed, BFD is
confirms the new path is "legitimate"
and works.

It seems correct to me that the current
protocol relies on BGP / BFD security.
That said, having BFD authentication
based on MD5 or SHA1 may suggest that
stronger primitives be recommended.
While this does not concerns the current
document, it seems to me that the
information might be relayed to routing
ADs.

What remains unclear to me - and I
assume this might be due to my lake or
expertise in routing area - is the impact
associated to performing a fail-over
both on 1) the data plane and 2) the
standard BGP way to establish routing
tables.

Regarding the data plane, I am wondering
if fail-over results in a lost of
packets for example - I suppose for
example that at least the packets in the
process of being forwarded might be
lost. I believe that providing details
on this may be good.

If there are any impacts I would like to
understand also in which cases the
decision to perform a failover operation
may result in more harm than the event
that has been over-interpreted. An
hypothetical scenario could be that the
non reception of a BFD packet is
interpreted as a PE being down while it
may not be correct and the PE might have
been simply under stress. A "too fast" fail-over
may over interpreted it and perform a
fail-over. If such things could happen,
an attacker could leverage a micro event
to perform network operation that are
not negligible. Another way to see that
is that an attacker might not have
direct access to the control plan, but
could use the data plan to generate a
stress and sort of control the fail
over. It seems to me that some text
might be welcome to prevent such cases
to happen. This could be guidance for
declaring a tunnel down for example.

Similarly, it would be good to add some
text regarding the interferences with
the non-fast forwarding fail over when
performed by the standard BGP.
Typically, my impression is that the
fast fail-over mechanism is a local
decision versus the BGP convergence that
is more global. As a result, even with
more time this two mechanisms may come
with different outcomes. One such
example to illustrate my purpose could
be the following. Note that this is only
illustrative of my purpose, and I let
you find and pick on ethat is more
appropriated.=C2=A0 =C2=A0I am thinking of a case
where a standby PE is be shared among
multiple PEs - supposing this situation
could occur.=C2=A0 Typically, if PE_1, PE_2
are shared by PE_a, ..., PE_z. In case
PE_a and PE_b are down, we expect PE_a
to switch to PE_1 and PE_b to switch to
PE_2. It seems to me that BGP would end
up in such situation while a local
decision may end up in PE_a and PE_a to
switch to PE_1.

</mglt>



--000000000000aefca805b29ad29d-- From nobody Mon Oct 26 18:27:27 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913D93A1186 for ; Mon, 26 Oct 2020 18:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=sn3rd.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 c9Gv0EmICQ0k for ; Mon, 26 Oct 2020 18:27:19 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 32B853A117B for ; Mon, 26 Oct 2020 18:27:19 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id a23so10325619qkg.13 for ; Mon, 26 Oct 2020 18:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z7l1ElONdDXVjS6o/+qt8kN8DqLXOWB4lOlGu6P1bns=; b=JAMaJEK5Nk5nk1trKjOcVl1AK02VJoXpe5B9v5ZU9yntUY2nWL8jmRMHG27uABJVL/ e5zRKjeZqiz47+WRXjXIHMO6fFEzrZaDPSSp2Fi8cmRXpcTRpX72eRkZs6kMZW4k7Hf7 T8o/sJPG1SObzcIiGMiZ+Tnr3wCNTbazU0QiA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z7l1ElONdDXVjS6o/+qt8kN8DqLXOWB4lOlGu6P1bns=; b=H9eiSRRPdZXamgUEiDC9sMHS/RJOPe4jIFPnuufKCmA2V/Yqe7Kl5C0N2bQjMwGJp/ Trk7bPXKtx+EwiAKZmrRsvIe4ZqR57aNg7juoJ9IDxvAdtvC058NT1Fuc+oKjmmIXu6n CqYm5YEKzTDvpbpYr6w8+dGj7tH0x2wqJSoIFdD3pgMKBGZ3KuFMWmbyBfa6fU1NyriU b60FlB9qW2sUfZSPqbWkEeQF3RrNsrnBxM9P4cweKcBS+fYMw88M8KJUqdN3ocytwT89 J9hze6LDRASAJEM50zwiiw/esRbLLDJGvblByxMgDPhSEvyEyf1IsYcJKJjRYK1qspRf DHiQ== X-Gm-Message-State: AOAM533fIXAIkYkjhj1bm9wroZQQnNe6XvHxr3daZ2rwgZlDb6anoeu3 aiFHMvO7jNdHhbFQuR5+Dl58hA== X-Google-Smtp-Source: ABdhPJwUJnO/dfwtBAEgD4i+TGu3FPiFkXGwdDMDFd6pdRJJbpSm3TghbOEHoivCtdsGRCDefXfxfw== X-Received: by 2002:a05:620a:12a6:: with SMTP id x6mr4572937qki.189.1603762037898; Mon, 26 Oct 2020 18:27:17 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id g129sm7800791qkb.61.2020.10.26.18.27.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2020 18:27:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Sean Turner In-Reply-To: <160339454955.8181.12347313700812158110@ietfa.amsl.com> Date: Mon, 26 Oct 2020 21:27:16 -0400 Cc: secdir@ietf.org, TLS List , last-call@ietf.org, draft-ietf-tls-md5-sha1-deprecate.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <012C2264-4929-4CA0-9706-1C2903D3017C@sn3rd.com> References: <160339454955.8181.12347313700812158110@ietfa.amsl.com> To: Rich Salz X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-md5-sha1-deprecate-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 01:27:21 -0000 Rich, THanks for the review. Pretty funny that we forgot the 8446 reference. = We will get that added. spt > On Oct 22, 2020, at 15:22, Rich Salz via Datatracker = wrote: >=20 > Reviewer: Rich Salz > Review result: Has Nits >=20 > I'm the assigned security directorate reviewer for this draft. This is = intended > for use by the Sec ADs, but anyone else who gleans wisdom from this = message is > free to use it as they see fit. >=20 > The document is READY. There are some nits, which can be found at > = https://www6.ietf.org/tools/idnits?url=3Dhttps://www.ietf.org/archive/id/d= raft-ietf-tls-md5-sha1-deprecate-04.txt > or by clicking on the "nits" tab on the datatracker page. >=20 > Don't use MD5 or SHA1 as digests. If you do, bad people in shadows = wearing > hoodies will be able to steal your information, impersonate or break = your TLS > or other connections, and so on. This document gives more rationale = and updates > some RFC's. >=20 > This NITS should be fixed, but this should be published. >=20 >=20 >=20 From nobody Tue Oct 27 06:52:00 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7693A0CE1; Tue, 27 Oct 2020 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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=isode.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 LEan1clmItE0; Tue, 27 Oct 2020 06:51:57 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F26C33A0CE0; Tue, 27 Oct 2020 06:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603806713; d=isode.com; s=june2016; i=@isode.com; bh=1KwAKeXtAspg66LUFIyFBIVncsyebTh74KCkLtZrDHU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Yg2W25B6jrodNVl2ooeF0xItq/tOjblalDWYJ90Rpd0rF2sgoSSl7kYNEC14L6Tc3Q3k47 2foSjRYci8gzTZZWGLx8NUqlhTdI2QMhkSaGDBn0kG2k4E9K0c5WnnoX7jxpxykGvG4L/5 k4BLZZ8EPmtcjPLbrMfcKWlECeQ26WQ=; Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 27 Oct 2020 13:51:53 +0000 From: Alexey Melnikov To: Hilarie Orman , iesg@ietf.org, secdir@ietf.org Cc: draft-ietf-acme-email-smime.all@ietf.org References: <202007161804.06GI4xAA000575@rumpleteazer.rhmr.com> Message-ID: Date: Tue, 27 Oct 2020 13:51:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <202007161804.06GI4xAA000575@rumpleteazer.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Security review of draft-ietf-acme-email-smime-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 13:51:59 -0000 Hi Hilarie, Thank you for your thorough review and sorry for the long delay in=20 responding! My comments/questions below: On 16/07/2020 19:04, Hilarie Orman wrote: > Security review of > Extensions to Automatic Certificate Management Environment for end user > S/MIME certificates > draft-ietf-acme-email-smime-08 > > Do not be alarmed. I generated this review of 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 > with the intent of improving security requirements and considerations > in IETF drafts. Comments not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > The abstract states: > "This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for use by email users that want to use S/MIME." > > I would restate this as "a specification of a challenge/response > protocol that is part of issuing ACME certificates to email accounts." > > There doesn't seem to be anything in particular that ties this > document to S/MIME. It would certainly be useful for using S/MIME, > but it is not necessary to have it in the title. My document can be extended/modified to apply to PGP/MIME, but I can't=20 see anything else it would apply to. (Not covering PGP/MIME was a=20 deliberate choice to keep the document simple.) So I would rather leave=20 S/MIME in the title. > The protocol under discussion is a small part of ACME, and it appears > to be what results immediately from a request for a certificate. In > section 3, last paragraph, there is a brief allusion to this context, > in the mention of the email address in a "CSR". This would be > usefully augmented by using the text as in ACME, i.e., "a PKCS#10 > [RFC2986] Certificate Signing Request (CSR)." Thank you for the suggestion. Added. > There's an assumption that the ability to reply to a challenge email from > the certificate server demonstrates "control" of the email account, > and therefore the possession of the private key for the certificate > demonstrates to a third party the "control" of the email account. Yes. This require both ability to read emails, as well as being able to=20 submit responses from the email address (which will imply being able to=20 authenticate as the corresponding account owner to SMTP server). > The security considerations note that the requester's email system > might not be secure, and that email accounts might be shared, but > there is reference to the "account owner". I don't think that there > is a formal notion of an account owner for email, perhaps it shouldn't > be mentioned. You are correct that this is not formally defined. An account owner is a=20 user that authenticates to IMAP/POP & SMTP to read and respond to email.=20 Do you think this should be formally defined in the document or maybe=20 you can suggest a better term here? > The protocol demonstrates that an entity can see email > sent to the email address and can respond from that email address. > That is not necessarily "control", so I would replace that term with > something more neutral, like "access". I admit I struggled a little bit with the verb to use here. "access" for=20 me only implies ability to read, but not=C2=A0 necessary reply. E.g. POP or= =20 IMAP access. Can you think of a better verb here? > The challenge message must be protected with S/MIME signing or DKIM > signing, and pass DMARC validation. The response message must be DKIM > signed. Are there any requirements on the the certificate issuer's No, because certificate issuer doesn't send any email in the proposal.=20 The certificate issuer and the ACME server might be the same entity, but=20 this is already covered in the document. > or requester's policy for DKIM/SPF/DMARC? Good question. I had some commented out text requiring this in the=20 document, but I was wondering whether this is too high of a bar to=20 require. I will restore this text in the draft. > This layering of security mechanisms raises the question of what do > they accomplish? The document recommends that email system > administrators use DNSSEC to protect records that protect email, but > it isn't required. Right. DNSSEC is not required, because requiring it would make this=20 extension undeployable. Many domain owners just accept this risk when=20 using email. > Under what circumstances should the email user > feel confident in the issued certificate? If it is used with S/MIME, > how much confidence should the recipient have in the certificate? The > answer depends on a lot of factors in the details of DNS and email > infrastructure for the certificate issuer and the certificate > requester. I added some text, which hopefully clarifies this. > The ACME specification has a detailed discussion of security. By > introducing email into protocol, this extension seems to raise new > security considerations that should be addressed in similar detail. Best Regards, Alexey From nobody Tue Oct 27 10:25:46 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB593A1264; Tue, 27 Oct 2020 10:25:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160381954432.30121.9559007698502161410@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Tue, 27 Oct 2020 10:25:44 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-grasp-api-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 17:25:44 -0000 Reviewer: Joseph Salowey Review result: Has Issues 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 issues. The document does needs a bit more discussion of the security implications. 1. Authorization In the security considerations section the document says that authorization is left for future work. I would expect that the section should at least describe what the implications of no authorizations are. What risks are not being mitigated? What modes of operations should not be used? In general leaving security items out suggests that the work is not ready for wide deployment. Perhaps this is OK because the work is informational, but the document should probably say this. 2. Authentication Section 2.3.1.4 discusses the ASA_locator. How is is the entity accessed by the locator authenticated? How does the caller of the API know they are talking to the right entity? I don't see any discussion of this in this document and there is very little in draft-ietf-anima-grasp-15 on this. Is there a section in one of these documents I should be looking for? 3. ASA_Nonce The ASA nonce is described as a security mechanism. It is only 4 bytes long. This seems short, making the ASA_Nonce vulnerable to collisions. Why is this not a problem? How long is the ASA nonce supposed to be valid? How often does registration happen? 4. Session Nonce Are there security implications of revealing the session nonce to the caller as suggested in section 2.3.1.7? Could it allow for the ASA to bypass authorization if it knows this value? Perhaps forming the nonce from the underlying session ID is not the best guidance? Also it seems the underlying protocol session ID is only 4 bytes and collisions are likely and may be a problem for the protocol. 5. Error Codes In general, the list of API codes in the appendix is not described in the API. It seems they should be. Some of the error codes seem related to authorization, which is out of scope? It seems that some of the error code could lead to disclosure of information, for example: notYourASA 7 "ASA registered but not by you" might reveal a valid nonce from an invalid nonce 6. Denial of service are there protections in the underlying protocol for denial of service with respect to Flood(), Synchronize() or any other method? From nobody Tue Oct 27 17:11:19 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 852B93A098D; Tue, 27 Oct 2020 17:11:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: emu@ietf.org, last-call@ietf.org, draft-ietf-emu-eap-tls13.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160384386950.10450.5930216784938121668@ietfa.amsl.com> Reply-To: Kyle Rose Date: Tue, 27 Oct 2020 17:11:09 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-emu-eap-tls13-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 00:11:10 -0000 Reviewer: Kyle Rose 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. This document is ready with nits. The purpose of this document is to update the TLS method of EAP to accommodate the changes to TLS in 1.3: in this, it appears to be complete and to have been thoroughly vetted. I have two nits and a high-level suggestion: * The introduction at one point says "Privacy is mandatory". Later in the document it becomes clear what is meant by this, but at this point in the document "privacy" is somewhat of a Rorschach test. It clearly doesn't mean that repeated EAP requests from the same IP will be unlinkable, for instance. What appears to be meant here is that encryption of the client certificate prevents linkability via passive surveillance. Say that instead. * Expand NAI into "Network Access Identifiers", with the appropriate informative reference, at its first use, not halfway through the document. * My high-level suggestion for this document is to be forward-looking in how you specify the relationship of EAP to TLS. Expect there to be a TLS 1.4 (or 2.0) and beyond, and specify this protocol using standardized TLS interfaces only, with the rest of the protocol (including the specific handshake messages) treated as a black box. This may or may not have been possible in the pre-TLS 1.3 era, but it is certainly possible to do so now. At best, no normative changes will be required; at worst, the size of the update to the EAP RFC will be minimized. From nobody Tue Oct 27 18:59:08 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7735D3A09EA; Tue, 27 Oct 2020 18:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 egVs9s2_OCG1; Tue, 27 Oct 2020 18:59:01 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 918173A09EB; Tue, 27 Oct 2020 18:58:58 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id az3so1750153pjb.4; Tue, 27 Oct 2020 18:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TKQPg2jna8LEXY2S9D008aZgL7XQIZFhJpLkfmjYj74=; b=ogfoBXgt9hbC37ORJJA1IXgzQTdNhEiplbcNC3xPPn1SuOU9dd/esqF5kKn5wb2uC6 K6aoYu2cl7cabVaGAfmUo+d841sIAAOkrRZCPAjfO8g9R2a4BBlGoOLJ+ElbkrzUf2wv vBvN6dDXU603ZftmvYsaJa/nVZYFnBbIhc+6xpgDRr5EtcTgHE+BUMzQZO5JODwaMqVI zAnCM0TGbnhQ66ofW79+FZa8WbSQlF3v6CfNs/YHxvBdzlO9bN2i4/cPi1WvJxr75hcw ZKbvaUVD4077vue+icQIlFvLvLDrwe16ROq08hDIGZhG8PK/PR9+FGHOmEnrK+SpiTgb Wo9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TKQPg2jna8LEXY2S9D008aZgL7XQIZFhJpLkfmjYj74=; b=Or089ieiLm9rgDr34bl7MCnrmpYHN5L9jfkhnUD+2xP5tUlWxdmec3RcmhZ1Nz0k+X OLoiHoGfrsIIoKAfbjC2kBXOvvS+2sifVHL1SfHawPsh+QowPhQLex+vWbe4EqxUGsws TXxggzO3tg8jASDwyr7bYKbkmAfJotZ1BdA0CX9h8zXVoxPw4M7SdKXivVyJNAPlFML8 /VfycWZvJc08B/ZPXevmX6mxiLoJNLkX0tFGnY5wFsyz3uxn3S4ULKhEmNOKec+SkNIe zTXAqQ+JRpmh0CLiX0sHwcm5mIN1AALjnzWjsTZD7kHGEYIWkGbRF6MeOc9TqnNPHQcX ePjg== X-Gm-Message-State: AOAM531nr42xb0xew1XPVBbjvrejNfSy/9VLLdhpH1VQu95xsA/yKZiH dk57yiTPm1GnUYgKJa5tshBo44LI7Vc= X-Google-Smtp-Source: ABdhPJzlG3bVOmEP7oa7FQtX5fzNZokDx+rGzUoVK5CBAAisH8A1wm8LyKsP26Hob0Bqdvt76JTxag== X-Received: by 2002:a17:902:9347:b029:d3:7c08:86c6 with SMTP id g7-20020a1709029347b02900d37c0886c6mr5056474plp.84.1603850337222; Tue, 27 Oct 2020 18:58:57 -0700 (PDT) Received: from [192.168.178.20] ([151.210.130.0]) by smtp.gmail.com with ESMTPSA id mn15sm2548429pjb.21.2020.10.27.18.58.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 18:58:55 -0700 (PDT) To: Joseph Salowey , secdir@ietf.org Cc: last-call@ietf.org, anima@ietf.org, draft-ietf-anima-grasp-api.all@ietf.org References: <160381954432.30121.9559007698502161410@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 28 Oct 2020 14:58:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <160381954432.30121.9559007698502161410@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-anima-grasp-api-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 01:59:04 -0000 Hi Joseph, Thanks for the review. Comments in line... On 28-Oct-20 06:25, Joseph Salowey via Datatracker wrote: > Reviewer: Joseph Salowey > Review result: Has Issues > > 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 issues. The document does needs a bit more > discussion of the security implications. > > 1. Authorization > > In the security considerations section the document says that authorization is > left for future work. I would expect that the section should at least describe > what the implications of no authorizations are. This isn't really an issue for the API itself, but for the underlying protocol and for the ANIMA ecosystem. It's an issue that the WG explicitly deferred (and it's now a chartered work item). Let me quote here what the GRASP spec says in its security considerations: >> - Authorization and Roles >> >> The GRASP protocol is agnostic about the roles and capabilities of >> individual ASAs and about which objectives a particular ASA is >> authorized to support. An implementation might support >> precautions such as allowing only one ASA in a given node to >> modify a given objective, but this may not be appropriate in all >> cases. For example, it might be operationally useful to allow an >> old and a new version of the same ASA to run simultaneously during >> an overlap period. These questions are out of scope for the >> present specification. and what draft-carpenter-anima-asa-guidelines says: >> Authorization of ASAs is a subject for future study. At present, ASAs are trusted by virtue of being installed on a node that has successfully joined the ACP. In the general case, a node may have mutltiple roles and a role may use multiple ASAs, each using multiple GRASP objectives. Additional mechanisms for the authorization of nodes and ASAs to manipulate specific GRASP objectives could be designed. That draft is on the verge of WG adoption. The point is that the current trust model is that we trust any node that has successfully joined the ACP, and therefore we trust any ASA in such a node. We should state that clearly in the text. IMHO it would be out of scope for the API to say more but we should add a reference to the GRASP Security Considerations. > What risks are not being > mitigated? What modes of operations should not be used? Those are good questions for the WG to look at. > In general leaving > security items out suggests that the work is not ready for wide deployment. > Perhaps this is OK because the work is informational, but the document should > probably say this. Personally I don't think we have left a hole here, because there's a well-defined trust boundary, but we should indeed state that as well as citing the GRASP spec's security considerations. > > 2. Authentication > > Section 2.3.1.4 discusses the ASA_locator. How is is the entity accessed by > the locator authenticated? How does the caller of the API know they are > talking to the right entity? I don't see any discussion of this in this > document and there is very little in draft-ietf-anima-grasp-15 on this. Is > there a section in one of these documents I should be looking for? No, you're not missing anything. The trust boundary is the ACP, and that takes us back to the previous point. If we do decide that we need a fine-grained trust model inside the ACP, we'll presumably need to extend GRASP itself to add some form of authentication option beyond what GRASP over TLS can provide. > > 3. ASA_Nonce > > The ASA nonce is described as a security mechanism. It is only 4 bytes long. > This seems short, making the ASA_Nonce vulnerable to collisions. Why is this > not a problem? This isn't used on the wire, just locally within the GRASP instance, so collisions can be excluded. > How long is the ASA nonce supposed to be valid? How often does registration > happen? At the moment, there is no sensible answer to those questions. When we develop the authorization model, we'd definitely have to answer those questions and maybe the nonce would have to be replaced by a crypto object. > > 4. Session Nonce > > Are there security implications of revealing the session nonce to the caller as > suggested in section 2.3.1.7? Could it allow for the ASA to bypass > authorization if it knows this value? Perhaps forming the nonce from the > underlying session ID is not the best guidance? Also it seems the underlying > protocol session ID is only 4 bytes and collisions are likely and may be a > problem for the protocol. No, the collision risk is avoided because the session nonce includes the ACP IPv6 address of the session originator. We should explain that more clearly. > > 5. Error Codes > > In general, the list of API codes in the appendix is not described in the API. > It seems they should be. Some of the error codes seem related to > authorization, which is out of scope? Our hope was the the WG could move faster on that topic, but the incredible delays on BRSKI and the ACP made that impossible. Our idea is certainly that register_asa() and register_objective() should include authorization in the longer term. > It seems that some of the error code could lead to disclosure of information, > for example: > > notYourASA 7 "ASA registered but not by you" might reveal a valid nonce > from an invalid nonce Hmm... I don't think so. Let me glance at the code... The only place where I found that error code useful was in deregister_asa() and that doesn't return anything else. It could be used in an exhaustive search attack to deregister an ASA, but in the current trust model that doesn't seem like a significant risk. > > 6. Denial of service > > are there protections in the underlying protocol for denial of service with > respect to Flood(), Synchronize() or any other method? There are recommendations about rate throttling for relaying GRASP Flood and Discover multicasts, which should confine any multicast abuse to a single link-layer segment. That's one good reason for using link-layer multicast only. We also have recommendations for exponential backoff in the GRASP spec, but of course a malicious sender could ignore those. In any case we can put a specific pointer to that subsection of the GRASP Security Considerations. DoS against the Negotiate or Synchronize parts of GRASP seems to be like any other client/server protocol. I'm not sure what we can say in the API spec about that. In my implementation (which is not intended to be production quality) I've simply put finite queues for all the request handlers, with silent discard if the queue overflows. We'll collate updates to all reviews after the LC expires. Thanks again Brian From nobody Wed Oct 28 06:12:18 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC863A0FAE; Wed, 28 Oct 2020 06:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 L0EuAANyOopT; Wed, 28 Oct 2020 06:12:14 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEF83A0FAF; Wed, 28 Oct 2020 06:12:14 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4CLprX6lnpz8tB4; Wed, 28 Oct 2020 14:12:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603890732; bh=6E6t6C8Bpgv4cnwaUI6aJuIxugaZZN2KOsQ4xBaTUks=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=RaMAWPJ1Fam5XyOTNwU8vyZ0nRUqoD4RWs6eZ1OJzTDi0kAT6j8K/GKt48Mmo/RqS +5ynqQHtuyElmbcgXqAG6j7yo23lBCTkxp25qZQ4xhcvpXSuzA5+yD2lbkwVk3APkn KHY2AbhkIitMBY7JK0h4auvNEP8PgEiiejrmaGl+J+nCl0ej2fSP4d4+ERN5ryWoeS vsVJvHukd+5PHTdbXZhuCHfgp1G8dEhrshyfdzO61aPDzU13+td/19yvjIRbfUny6Q zk/RywaBSxlp++Dx1jWCwkoUMPakQRjEDvWr4ZsUs1NW6bwbuDYEmwbu+eZ6iWDB2m TLYccKhQecRVg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CLprX5HqfzCqkS; Wed, 28 Oct 2020 14:12:12 +0100 (CET) From: To: Robert Sparks , "secdir@ietf.org" CC: "draft-ietf-sfc-serviceid-header.all@ietf.org" , "sfc@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 Thread-Index: AQHWq+boyqF2HL3FyUC77ov/yHQCsKmqatMAgAKUpDA= Date: Wed, 28 Oct 2020 13:12:11 +0000 Message-ID: <31178_1603890732_5F996E2C_31178_123_1_787AE7BB302AE849A7480A190F8B9330315684D7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160375112449.28199.4653147392736464602@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 13:12:16 -0000 SGkgUm9iZXJ0cywgDQoNCk1hbnkgdGhhbmtzIGZvciB0aGlzIHVzZWZ1bCByZXZpZXcuIE11Y2gg YXBwcmVjaWF0ZWQhDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNm Yy1zZXJ2aWNlaWQtaGVhZGVyLTExIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5v c3RydW0uY29tXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDI2IG9jdG9icmUgMjAyMCAyMzo0NQ0KPiDD gMKgOiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtc2VydmljZWlkLWhl YWRlci5hbGxAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsNCj4gbGFzdC1jYWxsQGlldGYub3JnDQo+ IE9iamV0wqA6IFJlOiBbTGFzdC1DYWxsXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLXNmYy0NCj4gc2VydmljZWlkLWhlYWRlci0xMA0KPiANCj4gSGVoIC0gb25lIHR5cG8g Y29ycmVjdGlvbiBiZWxvdyAodGhhdCBtaWdodCBoYXZlIGJlZW4gb2J2aW91cywNCj4gYnV0Li4u KQ0KPiANCj4gT24gMTAvMjYvMjAgNToyNSBQTSwgUm9iZXJ0IFNwYXJrcyB2aWEgRGF0YXRyYWNr ZXIgd3JvdGU6DQo+ID4gUmV2aWV3ZXI6IFJvYmVydCBTcGFya3MNCj4gPiBSZXZpZXcgcmVzdWx0 OiBIYXMgTml0cw0KPiA+DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkNCj4gZGlyZWN0b3JhdGUncw0KPiA+IG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KPiA+IElF U0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0 IG9mIHRoZQ0KPiA+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkDQo+IHRyZWF0DQo+ID4gdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4NCj4gPiBUaGlzIGRvY3VtZW50IGhh cyBuaXRzIHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCBiZWZvcmUgcHVibGljYXRpb24NCj4gYXMN Cj4gPiBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuDQo+ID4NCj4gPiBEb2N1bWVudCByZXZpZXdlZDog ZHJhZnQtaWV0Zi1zZmMtc2VydmljZWlkLWhlYWRlci0xMA0KPiA+DQo+ID4gVGhpcyBkb2N1bWVu dCdzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlc3Qgb24gdGhlIHByZW1pc2UgdGhhdA0KPiB0 aGUNCj4gPiBpbmZvcm1hdGlvbiBpdCBkaXNjdXNzZXMgd2lsbCBiZSBhZGRlZCwgdHJhbnNwb3J0 ZWQsIGNvbnN1bWVkLCBhbmQNCj4gPiByZW1vdmVkIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJh dGl2ZSBkb21haW4gdGhhdCBpcyBwcm90ZWN0ZWQNCj4gZnJvbQ0KPiA+IGVhdmVzZHJvcHBlcnMg YW5kIG1hbGljaW91cyBvbi1wYXRoIGF0dGFja2VycyB0aHJvdWdoDQo+IGFkbWluaXN0cmF0aXZl DQo+ID4gY29udHJvbHMuIEl0IGlzIHF1aXRlIHVwZnJvbnQgYWJvdXQgdGhhdCBhc3N1bXB0aW9u LCBhbmQgdGhlIHNmYw0KPiA+IGRvY3VtZW50cyBpdCByZWxpZXMgb24gbWFrZSB0aGUgc2FtZSBh c3NlcnRpb25zLg0KPiA+DQo+ID4gVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbWVjaGFuaXNt IHRoYXQgaW50ZW50aW9uYWxseSBhbGxvd3MNCj4gPiBpZGVudGlmaWVycw0KPiA+IChhZGRyZXNz ZXMpIHRoYXQgd291bGQgbm9ybWFsbHkgYmUgaGlkZGVuL2NvbnRhaW5lZCBiZWhpbmQgYSBuYXQN Cj4gdG8gYmUNCj4gPiBzaGFyZWQgYmV5b25kIHRoYXQgbmF0LCBidXQgYWdhaW4sIHdpdGhpbiB0 aGF0IHNpbmdsZQ0KPiBhZG1pbmlzdHJhdGl2ZSBkb21haW4uDQo+ID4NCj4gPiBOSVRTOg0KPiA+ DQo+ID4gVGhlcmUgYXJlIG1hbnkgcGxhY2VzIHdoZXJlIHRoZSBsYW5ndWFnZSBpbiB0aGUgZG9j dW1lbnQgbmVlZHMgdG8NCj4gYmUNCj4gPiBzaW1wbGlmaWVkLiBUaGVyZSBhcmUgYWxzbyBtYW55 IHBsYWNlcyB3aGVyZSAyMTE5IGxhbmd1YWdlIGlzDQo+IGJlaW5nDQo+ID4gdXNlZCBpbiBhIHdh eSB0aGF0IGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQo+ID4NCj4gPiBJbiBkb2N1bWVudCBvcmRlcjoN Cj4gPg0KPiA+IEludHJvZHVjdGlvbiBwYXJhZ3JhcGggMiwgc2VudGVuY2UgMS4gV2hhdCBkb2Vz IGl0IG1lYW4gdG8gaW5mZXINCj4gZW5mb3JjZW1lbnQ/DQo+ID4gUGVyaGFwcyB5b3UgbWVhbiAi cG9saWNpZXMgY2FuIGJlIGluZmVycmVkIj8gUGxlYXNlIHNpbXBsaWZ5IHRoaXMNCj4gc2VudGVu Y2UuDQo+ID4gQnJlYWsgdGhlIGV4YW1wbGUgaW50byBhIHNlcGFyYXRlIHNlbnRlbmNlIGFuZCBh ZGQgZGV0YWlsIGlmIHlvdQ0KPiBjYW4uDQo+ID4gSWYgcG9zc2libGUsIHByb3ZpZGUgYSByZWZl cmVuY2UgdG8gd2hhdCB5b3UgbWVhbiBieSAiU0ZDLWJhc2VkDQo+ID4gZGlmZmVyZW50aWF0ZWQg dHJhZmZpYyBwb2xpY2llcyIgbWVhbnMuDQo+ID4NCj4gPiBJbnRyb2R1Y3Rpb24gcGFyYWdyYXBo IDMuIFRoaXMgd2hvbGUgcGFyYWdyYXBoIGhhcyBjb21wbGljYXRlZCwNCj4gPiBwYXJhZ3JhcGgN Cj4gVGhhdCBsYXN0IHdvcmQgc2hvdWxkIGhhdmUgYmVlbiAiY29tbWEiDQo+ID4gc2VwYXJhdGVk LCBwaHJhc2VzIHRoYXQgc2hvdWxkIGJlIHdyaXR0ZW4gbW9yZSBzaW1wbHkuIFRoZSBuZXh0IHRv DQo+ID4gbGFzdCBzZW50ZW5jZSAoYXQgNTMgd29yZHMpIGlzIHBhcnRpY3VsYXJseSBoYXJkIHRv IGZvbGxvdy4NCj4gPg0KPiA+IEludHJvZHVjdGlvbiBwYXJhZ3JhcGggNCwgbGFzdCBzZW50ZW5j ZS4gVGhpcyBzZW50ZW5jZSBkb2VzIG5vdA0KPiBwYXJzZS4NCj4gPiBQbGVhc2UgcmV3b3JrIGl0 Lg0KPiA+DQo+ID4gSW50cm9kdWN0aW9uIHBhcmFncmFwaCA1LiBUaGlzIG9uZSBzZW50ZW5jZSBw YXJhZ3JhcGggd2FzIHRoZSBtb3N0DQo+ID4gZGlmZmljdWx0IGluIHRoZSBkb2N1bWVudCBmb3Ig bWUgdG8gcmVhZC4gUGxlYXNlIGJyZWFrIGl0IGludG8NCj4gc2V2ZXJhbCBzaW1wbGVyIHNlbnRl bmNlcy4NCj4gPg0KPiA+IFNlY3Rpb24gMzogYXQgIkluIG9yZGVyIHRvIHByZXZlbnQgaW50ZXJv cGVyYWJpbGl0eSBpc3N1ZXMsIHRoZQ0KPiBkYXRhDQo+ID4gYW5kIHRoZWlyIGZvcm1hdCB0byBi ZSBpbmplY3RlZCBpbiBzdWNoIGhlYWRlciBTSE9VTEQgYmUNCj4gY29uZmlndXJlZCB0bw0KPiA+ IG5vZGVzIGF1dGhvcml6ZWQgdG8gaW5qZWN0IHN1Y2ggaGVhZGVycy4iIFRoaXMgaXMgbm90IGEg MjExOQ0KPiBTSE9VTEQuDQo+ID4gSXQncyBldmVuIG5vdCBjbGVhciB3aGF0ICJ0aGUgZGF0YSIg aXMgaGVyZS4gSSBzdWdnZXN0IHNvbWV0aGluZw0KPiBsaWtlDQo+ID4gIlRoZSBpZGVudGlmaWVy cyBjYXJyaWVkIGluIHRoZSBDb250ZXh0IEhlYWRlcnMgYXJlIG9wYXF1ZS4gTm9kZXMNCj4gPiBw cm92aWRpbmcgdGhlbSBhbmQgY29uc3VtaW5nIHRoZW0gd2lsbCBiZSBjb25maWd1cmVkIHdpdGgg dGhlDQo+IG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBuZWVkZWQgc2VlIGludG8gdGhlbS4iDQo+ID4N Cj4gPiBTZWN0aW9uIDMsIGF0ICJGYWlsdXJlcyB0byBpbmplY3Qgc3VjaCBoZWFkZXJzIFNIT1VM RCBiZSBsb2dnZWQNCj4gPiBsb2NhbGx5IHdoaWxlIGEgbm90aWZpY2F0aW9uIGFsYXJtIE1BWSBi ZSBzZW50IHRvIGEgQ29udHJvbA0KPiBFbGVtZW50Lg0KPiA+IFRoZSBkZXRhaWxzIG9mIHNlbmRp bmcgbm90aWZpY2F0aW9uIGFsYXJtcyAoaS5lLiwgdGhlIHBhcmFtZXRlcnMNCj4gPiBhZmZlY3Rp bmcgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUgbm90aWZpY2F0aW9uIGFsYXJtcyBkZXBlbmQgb24N Cj4gdGhlDQo+ID4gaW5mb3JtYXRpb24gaW4gdGhlIENvbnRleHQgSGVhZGVyIHN1Y2ggYXMgZnJl cXVlbmN5LCB0aHJlc2hvbGRzLA0KPiBhbmQNCj4gPiBjb250ZW50IG9mIHRoZSBhbGFybSAoZnVs bCBoZWFkZXIsIHRpbWVzdGFtcCwgZXRjLikpIFNIT1VMRCBiZQ0KPiA+IGNvbmZpZ3VyYWJsZS4i IE5vbmUgb2YgdGhlc2UgYXJlIGNvcnJlY3QgdXNlIG9mIDIxMTkuIENvbnNpZGVyIHJlLQ0KPiBm cmFtaW5nIHRoZSBwYXJhZ3JhcGggd2l0aG91dCB1c2luZyB0aGVzZSB0ZXJtcy4NCj4gPg0KPiA+ IFNlY3Rpb24gMyBhdCAiVGhhdCBpcywgdG8gc3RyaXAgc3VjaCBDb250ZXh0IEhlYWRlcnMuIiBp cyBub3QgYQ0KPiBzZW50ZW5jZS4NCj4gPg0KPiA+IFNlY3Rpb24gMyBhdCB0aGUgcGFyYWdyYXBo IGJlZ2lubmluZyAiRGVwZW5kaW5nIG9uIGxvY2FsIHBvbGljeSIuDQo+IFRoZQ0KPiA+IHN0cnVj dHVyZSBvZiB0aGlzIHBhcmFncmFwaCBpcyB2ZXJ5IG9kZC4gRG9lc24ndCBiYXNlIFNGQyBzYXkg dG8NCj4gPiBwcmVzZXJ2ZSBOU0ggYXQgaW50ZXJtZWRpYXJpZXM/IEkgc3VnZ2VzdCByZXBsYWNp bmcgdGhpcyBwYXJhZ3JhcGgNCj4gPiB3aXRoIHNvbWV0aGluZyBsaWtlICJOb3JtYWwgU0ZDIGlu dGVybWVkaWFyeSBiZWhhdmlvciBwcmVzZXJ2ZXMNCj4gPiBOZXR3b3JrIFNlcnZpY2UgSGVhZGVy cy4gTG9jYWwgcG9saWN5IGNhbiByZXF1aXJlIGEgcHJveHkgdG8gc3RyaXANCj4gLi4uIg0KPiA+ DQo+ID4gU2VjdGlvbiAzIGF0ICJOU0gtYXdhcmUgU0ZzIE1VU1QgYmUgY2FwYWJsZSB0byBydW4g YWRkaXRpb25hbA0KPiA+IHZhbGlkYXRpb24gY2hlY2tzIi4gVGhpcyBpc24ndCAyMTE5LiBQZXJo YXBzIHlvdSBtZWFuIHRvIHNheSAiQmUNCj4gYXdhcmUNCj4gPiB0aGF0IGxvY2FsIHBvbGljaWVz IG1heSByZXF1aXJlIHJ1bm5pbmcgYWRkaXRpb25hbCB2YWxpZGF0aW9uDQo+IGNoZWNrcw0KPiA+ IGF0IE5TSC1hd2FyZSBTRnMiLiBUaGUgd2hvbGUgcGFyYWdyYXBoIGNhbiBiZSBzaW1wbGlmaWVk Lg0KPiA+DQo+ID4gU2VjdGlvbiAzIGF0ICJNdWx0aXBsZSBTdWJzY3JpYmVyIElkZW50aWZpZXIg Q29udGV4dCBIZWFkZXJzIE1BWQ0KPiBiZQ0KPiA+IHByZXNlbnQgaW4gdGhlIE5TSCwgZWFjaCBj YXJyeWluZyBhIGRpc3RpbmN0IG9wYXF1ZSB2YWx1ZSBidXQgYWxsDQo+ID4gcG9pbnRpbmcgdG8g dGhlIHNhbWUgc3Vic2NyaWJlci4iIFRoaXMgaXMgYSBwbGFjZSB3aGVyZSBhIDIxMTkNCj4gTVVT VA0KPiA+IF93b3VsZF8gbWFrZSBzZW5zZS4gU2F5ICJTdWNoIG11bHRpcGxlIGhlYWRlcnMgTVVT VCBpZGVudGlmeSB0aGUNCj4gc2FtZQ0KPiA+IHN1YnNjcmliZXIiLiBJIHdvbmRlciwgdGhvdWdo LCBpZiB5b3UncmUgY2xvc2luZyBhIGRvb3Igb24NCj4gY2FycnlpbmcgbXVsdGlwbGUgaWRlbnRp dGllcyB0aGF0IHlvdSdsbCByZWdyZXQgbGF0ZXIuDQo+ID4NCj4gPiBTZWN0aW9uIDQgZmlyc3Qg cGFyYWdyYXBoLCBmaXJzdCBzZW50ZW5jZTogSSBzdWdnZXN0IHJlcGxhY2luZw0KPiAiaWRlbnRp ZmllciBpcyINCj4gPiB3aXRoICJpZGVudGlmaWVycyBhcmUiDQo+ID4NCj4gPiBTZWN0aW9uIDQg ZmlmdGggcGFyYWdyYXBoOiAiZGVmaW5lZCBhcyBvcHRpb25hbCIgLT4gImRlZmluZWQgYXMgYW4N Cj4gb3B0aW9uYWwiDQo+ID4NCj4gPiBTZWN0aW9uIDQgc2l4dGggcGFyYWdyYXBoLiBTaW1pbGFy IHRvIHRoZSBzZWN0aW9uIDMgcGFyYWdyYXBoIEkNCj4gcG9pbnQNCj4gPiB0byBhYm92ZSwgdGhl IHN0cnVjdHVyZSBoZXJlIGlzIHZlcnkgb2RkLiBBZ2FpbiwgSSBzdWdnZXN0DQo+IHNvbWV0aGlu Zw0KPiA+IGxpa2UgIk5vcm1hbCBTRkMgaW50ZXJtZWRpYXJpZXMgd2lsbCBwcmVzZXJ2ZSBDb250 ZXh0IEhlYWRlcnMsIGJ1dA0KPiA+IGxvY2FsIHBvbGljeSBtYXkgcmVxdWlyZSBhIHByb3h5IHRv IHRvIHN0cmlwIG9uZSBhZnRlciBwcm9jZXNzaW5nDQo+IGl0LiINCj4gPg0KPiA+IFNlY3Rpb24g NCBzZXZlbnRoIHBhcmFncmFwaDogIm9jbmxmaWN0aW5nIi0+ImNvbmZsaWN0aW5nIi4gSQ0KPiBh c3N1bWUNCj4gPiB0aGUgZGVmYXVsdCBiZWhhdmlvciBkZXNjcmliZWQgaGVyZSBpcyBzcGVjaWZp ZWQgaW4gdGhlIGJhc2UgTlNIDQo+IGRvY3M/DQo+ID4NCj4gPiBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIHBhcmFncmFwaCA0OiBDb25zaWRlciAibG9nZ2luZyB0aGUNCj4gPiBjb250 ZW50IG9mIC4uLiBpcyBub3QgYWR2aXNlZCIgcmF0aGVyIHRoYW4gdXNpbmcgMjExOSBoZXJlLiBU aGUNCj4gPiBwYXJhZ3JhcGggd291bGQgYmUgYmV0dGVyIGZvcm11bGF0ZWQgaWYgaXQgZXhwbGFp bmVkIHRoZSByaXNrIC0NCj4gU0ZzDQo+ID4gdGhhdCBfZGlkXyB1c2UgdGhlIGNvbnRleHQgbWln aHQgYmUgYmV0dGVyIG9mZiBub3QgbG9nZ2luZyB0aGVtIGluDQo+IG1hbnkgY2FzZXMgYXMgd2Vs bC4NCj4gPg0KPiA+DQo+ID4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Oct 28 07:00:22 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AABE3A096B; Wed, 28 Oct 2020 07:00:14 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_xNq2Xu6w3G; Wed, 28 Oct 2020 07:00:13 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 4814D3A1090; Wed, 28 Oct 2020 07:00:04 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 09SE03lo025078; Wed, 28 Oct 2020 15:00:03 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 374ADD17A7; Wed, 28 Oct 2020 15:00:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 2BeFXp7iXc5o; Wed, 28 Oct 2020 15:00:01 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 70809D17A1; Wed, 28 Oct 2020 15:00:01 +0100 (CET) Date: Wed, 28 Oct 2020 15:00:00 +0100 Message-ID: <87o8kmfo2n.wl-jch@irif.fr> From: Juliusz Chroboczek To: Rifaat Shekh-Yusef Cc: , draft-ietf-babel-source-specific.all@ietf.org, last-call@ietf.org, babel@ietf.org In-Reply-To: <160364731499.17476.11455568556595523172@ietfa.amsl.com> References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 28 Oct 2020 15:00:03 +0100 (CET) X-Miltered: at korolev with ID 5F997963.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5F997963.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5F997963.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-source-specific-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:00:15 -0000 > “A node MUST NOT send more that one Source Prefix sub-TLV in a TLV, > and a node receiving more than one Source Prefix sub-TLV in a single > TLV SHOULD ignore this TLV. It MAY ignore the whole packet.” > 2. This paragraph implies that a node might accept the TLV with more than one > Source Prefix sub-TLV, but it does not state when a node can do that. You might > want to elaborate on the conditions that a node is allowed to do that. Right. I've made this a MUST, which reflects implementation practice. Group, please feel free to object if you think this is the wrong choice. -- Juliusz From nobody Wed Oct 28 07:27:45 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16A63A09CF; Wed, 28 Oct 2020 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.275, NICE_REPLY_A=-0.247, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 LtWZ9s30oTpw; Wed, 28 Oct 2020 07:27:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 805513A0AE2; Wed, 28 Oct 2020 07:27:23 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 09SERLP2099905 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 28 Oct 2020 09:27:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1603895243; bh=sdP1yJuhQYQ+wqiVsFUQfiOKQuLj+YvkMj7ji7Q5soY=; h=To:Cc:References:From:Subject:Date:In-Reply-To; b=ndyZbsWAfoFkCseXpb3+TvaduHCl8rQxHNdD09pPEJvlxik43arZVQLPJtzvK3mLo bUyrr2sIryeK4+uWoKMoK8lkUzMNcygn9W9jj7j4KhAgA6Jx1GB/eNUE6e8s+pnQ6O 4+z97EWy+u8n01R3l9zFMNf/VGsOvjjiDNxhzEhQ= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-sfc-serviceid-header.all@ietf.org" , "sfc@ietf.org" , "last-call@ietf.org" References: <160375112449.28199.4653147392736464602@ietfa.amsl.com> <31178_1603890732_5F996E2C_31178_123_1_787AE7BB302AE849A7480A190F8B9330315684D7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Robert Sparks Message-ID: <948de6e7-d035-793b-9698-b28129b52a51@nostrum.com> Date: Wed, 28 Oct 2020 09:27:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <31178_1603890732_5F996E2C_31178_123_1_787AE7BB302AE849A7480A190F8B9330315684D7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:27:42 -0000 Thanks Med - This sufficiently addresses my comments. Thanks for adding clarity with=20 the edits. I do want to ask again, though, whether you're closing off an=20 opportunity with the requirement that all the identifiers belong to a=20 single subscriber, and that the group made that choice explicitly rather = than just falling into it. I could see an alternative that looked like "allow multiple identities,=20 and the use of them in inferred policies is 'is any of' ". Stretching a=20 little into slightly different problem domains, consider, for example,=20 the doctor that could be using his own phone number or the office phone=20 number. I'm not suggesting that allowing such multiple identities is the right=20 thing to do, but I want to verify that simple alternatives like that=20 were considered and rejected, and that you have a way to do them in the=20 future if you want. The text does imply that the group looked at the general problem of=20 trying to capture arbitrary relationships between multiple identities,=20 and decided not to solve that. If that's how it happened, you might=20 consider explicitly saying that so future related work isn't guessing or = making assumptions about the motivation here. RjS On 10/28/20 8:12 AM, mohamed.boucadair@orange.com wrote: > Hi Roberts, > > Many thanks for this useful review. Much appreciated! > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-serviceid-header-11 > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: Robert Sparks [mailto:rjsparks@nostrum.com] >> Envoy=C3=A9=C2=A0: lundi 26 octobre 2020 23:45 >> =C3=80=C2=A0: secdir@ietf.org >> Cc=C2=A0: draft-ietf-sfc-serviceid-header.all@ietf.org; sfc@ietf.org; >> last-call@ietf.org >> Objet=C2=A0: Re: [Last-Call] Secdir last call review of draft-ietf-sfc= - >> serviceid-header-10 >> >> Heh - one typo correction below (that might have been obvious, >> but...) >> >> On 10/26/20 5:25 PM, Robert Sparks via Datatracker wrote: >>> Reviewer: Robert Sparks >>> 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. >>> >>> This document has nits that should be addressed before publication >> as >>> Proposed Standard RFC. >>> >>> Document reviewed: draft-ietf-sfc-serviceid-header-10 >>> >>> This document's security considerations rest on the premise that >> the >>> information it discusses will be added, transported, consumed, and >>> removed within a single administrative domain that is protected >> from >>> eavesdroppers and malicious on-path attackers through >> administrative >>> controls. It is quite upfront about that assumption, and the sfc >>> documents it relies on make the same assertions. >>> >>> This document introduces a mechanism that intentionally allows >>> identifiers >>> (addresses) that would normally be hidden/contained behind a nat >> to be >>> shared beyond that nat, but again, within that single >> administrative domain. >>> NITS: >>> >>> There are many places where the language in the document needs to >> be >>> simplified. There are also many places where 2119 language is >> being >>> used in a way that does not make sense. >>> >>> In document order: >>> >>> Introduction paragraph 2, sentence 1. What does it mean to infer >> enforcement? >>> Perhaps you mean "policies can be inferred"? Please simplify this >> sentence. >>> Break the example into a separate sentence and add detail if you >> can. >>> If possible, provide a reference to what you mean by "SFC-based >>> differentiated traffic policies" means. >>> >>> Introduction paragraph 3. This whole paragraph has complicated, >>> paragraph >> That last word should have been "comma" >>> separated, phrases that should be written more simply. The next to >>> last sentence (at 53 words) is particularly hard to follow. >>> >>> Introduction paragraph 4, last sentence. This sentence does not >> parse. >>> Please rework it. >>> >>> Introduction paragraph 5. This one sentence paragraph was the most >>> difficult in the document for me to read. Please break it into >> several simpler sentences. >>> Section 3: at "In order to prevent interoperability issues, the >> data >>> and their format to be injected in such header SHOULD be >> configured to >>> nodes authorized to inject such headers." This is not a 2119 >> SHOULD. >>> It's even not clear what "the data" is here. I suggest something >> like >>> "The identifiers carried in the Context Headers are opaque. Nodes >>> providing them and consuming them will be configured with the >> necessary information needed see into them." >>> Section 3, at "Failures to inject such headers SHOULD be logged >>> locally while a notification alarm MAY be sent to a Control >> Element. >>> The details of sending notification alarms (i.e., the parameters >>> affecting the transmission of the notification alarms depend on >> the >>> information in the Context Header such as frequency, thresholds, >> and >>> content of the alarm (full header, timestamp, etc.)) SHOULD be >>> configurable." None of these are correct use of 2119. Consider re- >> framing the paragraph without using these terms. >>> Section 3 at "That is, to strip such Context Headers." is not a >> sentence. >>> Section 3 at the paragraph beginning "Depending on local policy". >> The >>> structure of this paragraph is very odd. Doesn't base SFC say to >>> preserve NSH at intermediaries? I suggest replacing this paragraph >>> with something like "Normal SFC intermediary behavior preserves >>> Network Service Headers. Local policy can require a proxy to strip >> ..." >>> Section 3 at "NSH-aware SFs MUST be capable to run additional >>> validation checks". This isn't 2119. Perhaps you mean to say "Be >> aware >>> that local policies may require running additional validation >> checks >>> at NSH-aware SFs". The whole paragraph can be simplified. >>> >>> Section 3 at "Multiple Subscriber Identifier Context Headers MAY >> be >>> present in the NSH, each carrying a distinct opaque value but all >>> pointing to the same subscriber." This is a place where a 2119 >> MUST >>> _would_ make sense. Say "Such multiple headers MUST identify the >> same >>> subscriber". I wonder, though, if you're closing a door on >> carrying multiple identities that you'll regret later. >>> Section 4 first paragraph, first sentence: I suggest replacing >> "identifier is" >>> with "identifiers are" >>> >>> Section 4 fifth paragraph: "defined as optional" -> "defined as an >> optional" >>> Section 4 sixth paragraph. Similar to the section 3 paragraph I >> point >>> to above, the structure here is very odd. Again, I suggest >> something >>> like "Normal SFC intermediaries will preserve Context Headers, but >>> local policy may require a proxy to to strip one after processing >> it." >>> Section 4 seventh paragraph: "ocnlficting"->"conflicting". I >> assume >>> the default behavior described here is specified in the base NSH >> docs? >>> Security Considerations section paragraph 4: Consider "logging the >>> content of ... is not advised" rather than using 2119 here. The >>> paragraph would be better formulated if it explained the risk - >> SFs >>> that _did_ use the context might be better off not logging them in >> many cases as well. >>> >>> > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged= information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified. > Thank you. > From nobody Wed Oct 28 07:47:01 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832C33A0A0B; Wed, 28 Oct 2020 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=eggert.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 OnY89dh3WxX4; Wed, 28 Oct 2020 07:46:52 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 0884A3A0A07; Wed, 28 Oct 2020 07:46:48 -0700 (PDT) Received: from [IPv6:2a00:ac00:4000:400:c1b6:9abf:94c2:7012] (unknown [IPv6:2a00:ac00:4000:400:c1b6:9abf:94c2:7012]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 59E85612910; Wed, 28 Oct 2020 16:46:42 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1603896402; bh=y+fBVOjFaBGjbvedEDc4LrvjJUGTVH15dE+tGqu2mns=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=GTmDd/yzs2QDME/S+m+QGZwMVof/O/3Z89jbaSYZxmreQLqcahoeIIeO3ryRl9KOb 3jtow/XIOxgcMZJk5xeVT9NosarVscIsnYOvxCVUMXqbnGTdwgK/zloFy8lvGrVovR ZJDyu5VJqHi/wQ+iw7SKXGxbJZpd1qAL8DamZ9UY= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7334569E-CB76-46B6-A1AA-DDBD1B1A05AB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 16:46:41 +0200 In-Reply-To: <160357685316.11679.4088820464581761732@ietfa.amsl.com> Cc: secdir@ietf.org, last-call@ietf.org, IETF QUIC WG , draft-ietf-quic-invariants.all@ietf.org To: Yoav Nir References: <160357685316.11679.4088820464581761732@ietfa.amsl.com> X-MailScanner-ID: 59E85612910.AFB48 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-quic-invariants-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:46:54 -0000 --Apple-Mail=_7334569E-CB76-46B6-A1AA-DDBD1B1A05AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoav, thank you for the review. I've opened a GitHub issue in case the editors = would like to discuss editorial changes at = https://github.com/quicwg/base-drafts/issues/4305, please feel free to = track the resolution there. There is also a tracking milestone at = https://github.com/quicwg/base-drafts/milestone/5. Thanks, Lars > On 2020-10-25, at 1:00, Yoav Nir via Datatracker = wrote: >=20 > Reviewer: Yoav Nir > Review result: Ready >=20 > The contents of the "security and privacy considerations" section = seems to be > advice for middlebox authors. I think that it may have been better to = name the > section something else. However, there is no information that is = missing, so I > don't really have any recommendations for changing things. >=20 >=20 --Apple-Mail=_7334569E-CB76-46B6-A1AA-DDBD1B1A05AB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl+ZhFEACgkQVLXDCb9w wVcAEw/9GEP/x+GmwjuwHm6GN3U1D3zpXxZcKWk5YGfK+bYArb6r0sVQwn7O78Ys 2qW5s9uD0k4C9yz4NiWPk/cEC7jTovqZ3VZpaAnpq1zC4dshb4fw5KpSY9ZrVt2Y vjKw0t7+y5EK4GFEzxWxJKSL+lgYvTRxMLbl117j13XW2eX5Ph/nA46Zg+j15A1t gezCHew4TDaoQG765TOI0V2fhNxn561dM5Tf5Fl9+6aGII8NX2mYB5VGl6c2Fq9B be6xZllXTBn+TrWQxjp8JYrNF3hEkZGazfFGGPvSeMQLwKCQ2EGLAEw7PSTVJRw9 OdFXvZNyaB6wqnmKA3ZOUihW+nyWijt4fHFes80yUG2F+JP4+KU9MJv1cwh7bESn bu+8M8cONoCp4ILqh4OFyWEOu86reAgboyia6vpOMbtsrzk+xfoWoF2DCZtPWYpW dmZmUxP8I2tl2ZpycGLgiu7H4za8qpNwEp7it9kURUjwEec3h09Yem3pt9aRxRz6 43JYUqRGuBc1H8Kpgvvz0MmHnwwIR6pEyZTLVgNdO+ZfsxBGVxCjBZwBCgnq84JG HNwV0gjWea8tRJv+H3RJ3WL9a0iLKGtj0LnYB1p7G3hcXjwI5Q6aKSEWsVic88x+ 85tZYprZUCo66O/deYhacJishZlqHpgn0TN/+NQxZqpWSmvmJI0= =oNNz -----END PGP SIGNATURE----- --Apple-Mail=_7334569E-CB76-46B6-A1AA-DDBD1B1A05AB-- From nobody Wed Oct 28 07:52:40 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7C3A0A1F; Wed, 28 Oct 2020 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 CVMJ-GHZpinR; Wed, 28 Oct 2020 07:52:29 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0003A0A13; Wed, 28 Oct 2020 07:52:29 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4CLs4D1gTSz8tGh; Wed, 28 Oct 2020 15:52:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603896748; bh=4ETqh0pOEdODCA1aGyhP/MxFsEoZzjOGO1dyREiVz/I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=aWpQRrtiaj37/B2nEdy79nw5988X5bKeRcZw00iql49SfdNi9TM32IyTj4N3hrEbc dc950WAUgd5fbDXvInpcnOBo0083D7UU5XqDsVF1+zYHDpoKcdUOkSxJYOP6TiQwqe sCCBJfGgXm9Mv4juwk4ittAdfesJAPNzrXLYYFVMoNY1koR+wqOtuTH/XKR8jxFiG+ vt00UJmTOJanytTtXFG1k7vpVRkTydYRRh4xZJdgt0ySOAHmPVAd/bhZGVKQXmJiUi RTwNWWJ9+e2A3jv8D86I1M31V0eVT6U9LtFcjpaj2aGMSwgpbdogQZNQdkV120Fv32 wWseusyz21pvQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4CLs4D0CtTzCqkf; Wed, 28 Oct 2020 15:52:28 +0100 (CET) From: To: Robert Sparks , "secdir@ietf.org" CC: "draft-ietf-sfc-serviceid-header.all@ietf.org" , "sfc@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 Thread-Index: AQHWrTZ2BHiuE7DBfEecTK4bwB4oeamtFvgw Date: Wed, 28 Oct 2020 14:52:27 +0000 Message-ID: <13206_1603896748_5F9985AC_13206_264_1_787AE7BB302AE849A7480A190F8B9330315686FB@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160375112449.28199.4653147392736464602@ietfa.amsl.com> <31178_1603890732_5F996E2C_31178_123_1_787AE7BB302AE849A7480A190F8B9330315684D7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <948de6e7-d035-793b-9698-b28129b52a51@nostrum.com> In-Reply-To: <948de6e7-d035-793b-9698-b28129b52a51@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-sfc-serviceid-header-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:52:32 -0000 UmUtLA0KDQpUaGFuayB5b3UuIA0KDQpPbmUgb2YgdGhlIG1vdGl2YXRpb24gZm9yIGFsbG93aW5n IG11bHRpcGxlIGlkZW50aWZpZXJzLCBidXQgYWxsIGJlbG9uZyB0byB0aGUgc2FtZSBzdWJzY3Jp YmVyLCBpcyB0byBhY2NvbW1vZGF0ZSBjYXNlcyBzdWNoIGFzIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHktMDkjc2Vj dGlvbi0zLjMuMiB3aGVyZSBzb21lIHNlcnZpY2UgZnVuY3Rpb25zIGluIGEgbW9iaWxlIG5ldHdv cmsgY2FuIGVuZm9yY2UgcG9saWNpZXMgYmFzZWQgb24gYW4gaW50ZXJuYWwgSVAgYWRkcmVzcyB3 aGlsZSBvdGhlcnMgbWF5IHJlbHkgb24gdGhlIE1TSVNETiBvciB0aGUgSU1TSS4gDQoNCkFzIGRp c2N1c3NlZCBpbiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NmYy9UdnNo a0FNR3B3eFFyTHJDWkczQk5xcmVVZzAvLCBiZWNhdXNlIHRoZXNlIGlkZW50aWZpZXJzIGJlbG9u ZyB0byB0aGUgc2FtZSBzdWJzY3JpYmVyLCBzdHJpcHBpbmcgdGhlIGlkZW50aWZpZXJzIGlzIHN0 cmFpZ2h0Zm9yd2FyZC4gVGhpbmdzIHdvdWxkIGJlIG11Y2ggY29tcGxleCwgb3RoZXJ3aXNlLiAN Cg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6 IFJvYmVydCBTcGFya3MgW21haWx0bzpyanNwYXJrc0Bub3N0cnVtLmNvbV0NCj4gRW52b3nDqcKg OiBtZXJjcmVkaSAyOCBvY3RvYnJlIDIwMjAgMTU6MjcNCj4gw4DCoDogQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47DQo+IHNlY2RpckBpZXRm Lm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLXNmYy1zZXJ2aWNlaWQtaGVhZGVyLmFsbEBpZXRmLm9y Zzsgc2ZjQGlldGYub3JnOw0KPiBsYXN0LWNhbGxAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtM YXN0LUNhbGxdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2ZjLQ0KPiBz ZXJ2aWNlaWQtaGVhZGVyLTEwDQo+IA0KPiBUaGFua3MgTWVkIC0NCj4gDQo+IFRoaXMgc3VmZmlj aWVudGx5IGFkZHJlc3NlcyBteSBjb21tZW50cy4gVGhhbmtzIGZvciBhZGRpbmcgY2xhcml0eQ0K PiB3aXRoIHRoZSBlZGl0cy4NCj4gDQo+IEkgZG8gd2FudCB0byBhc2sgYWdhaW4sIHRob3VnaCwg d2hldGhlciB5b3UncmUgY2xvc2luZyBvZmYgYW4NCj4gb3Bwb3J0dW5pdHkgd2l0aCB0aGUgcmVx dWlyZW1lbnQgdGhhdCBhbGwgdGhlIGlkZW50aWZpZXJzIGJlbG9uZyB0bw0KPiBhIHNpbmdsZSBz dWJzY3JpYmVyLCBhbmQgdGhhdCB0aGUgZ3JvdXAgbWFkZSB0aGF0IGNob2ljZSBleHBsaWNpdGx5 DQo+IHJhdGhlciB0aGFuIGp1c3QgZmFsbGluZyBpbnRvIGl0Lg0KPiANCj4gSSBjb3VsZCBzZWUg YW4gYWx0ZXJuYXRpdmUgdGhhdCBsb29rZWQgbGlrZSAiYWxsb3cgbXVsdGlwbGUNCj4gaWRlbnRp dGllcywgYW5kIHRoZSB1c2Ugb2YgdGhlbSBpbiBpbmZlcnJlZCBwb2xpY2llcyBpcyAnaXMgYW55 IG9mJw0KPiAiLiBTdHJldGNoaW5nIGEgbGl0dGxlIGludG8gc2xpZ2h0bHkgZGlmZmVyZW50IHBy b2JsZW0gZG9tYWlucywNCj4gY29uc2lkZXIsIGZvciBleGFtcGxlLCB0aGUgZG9jdG9yIHRoYXQg Y291bGQgYmUgdXNpbmcgaGlzIG93biBwaG9uZQ0KPiBudW1iZXIgb3IgdGhlIG9mZmljZSBwaG9u ZSBudW1iZXIuDQo+IA0KPiBJJ20gbm90IHN1Z2dlc3RpbmcgdGhhdCBhbGxvd2luZyBzdWNoIG11 bHRpcGxlIGlkZW50aXRpZXMgaXMgdGhlDQo+IHJpZ2h0IHRoaW5nIHRvIGRvLCBidXQgSSB3YW50 IHRvIHZlcmlmeSB0aGF0IHNpbXBsZSBhbHRlcm5hdGl2ZXMNCj4gbGlrZSB0aGF0IHdlcmUgY29u c2lkZXJlZCBhbmQgcmVqZWN0ZWQsIGFuZCB0aGF0IHlvdSBoYXZlIGEgd2F5IHRvDQo+IGRvIHRo ZW0gaW4gdGhlIGZ1dHVyZSBpZiB5b3Ugd2FudC4NCj4gDQo+IFRoZSB0ZXh0IGRvZXMgaW1wbHkg dGhhdCB0aGUgZ3JvdXAgbG9va2VkIGF0IHRoZSBnZW5lcmFsIHByb2JsZW0gb2YNCj4gdHJ5aW5n IHRvIGNhcHR1cmUgYXJiaXRyYXJ5IHJlbGF0aW9uc2hpcHMgYmV0d2VlbiBtdWx0aXBsZQ0KPiBp ZGVudGl0aWVzLCBhbmQgZGVjaWRlZCBub3QgdG8gc29sdmUgdGhhdC4gSWYgdGhhdCdzIGhvdyBp dA0KPiBoYXBwZW5lZCwgeW91IG1pZ2h0IGNvbnNpZGVyIGV4cGxpY2l0bHkgc2F5aW5nIHRoYXQg c28gZnV0dXJlDQo+IHJlbGF0ZWQgd29yayBpc24ndCBndWVzc2luZyBvciBtYWtpbmcgYXNzdW1w dGlvbnMgYWJvdXQgdGhlDQo+IG1vdGl2YXRpb24gaGVyZS4NCj4gDQo+IFJqUw0KPiANCj4gT24g MTAvMjgvMjAgODoxMiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4g PiBIaSBSb2JlcnRzLA0KPiA+DQo+ID4gTWFueSB0aGFua3MgZm9yIHRoaXMgdXNlZnVsIHJldmll dy4gTXVjaCBhcHByZWNpYXRlZCENCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zZmMtc2VydmljZWlkLWhlYWRlci0NCj4gMTENCj4gPg0KPiA+IENo ZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g Pj4gRGXCoDogUm9iZXJ0IFNwYXJrcyBbbWFpbHRvOnJqc3BhcmtzQG5vc3RydW0uY29tXQ0KPiA+ PiBFbnZvecOpwqA6IGx1bmRpIDI2IG9jdG9icmUgMjAyMCAyMzo0NQ0KPiA+PiDDgMKgOiBzZWNk aXJAaWV0Zi5vcmcNCj4gPj4gQ2PCoDogZHJhZnQtaWV0Zi1zZmMtc2VydmljZWlkLWhlYWRlci5h bGxAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsNCj4gPj4gbGFzdC1jYWxsQGlldGYub3JnDQo+ID4+ IE9iamV0wqA6IFJlOiBbTGFzdC1DYWxsXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFm dC1pZXRmLQ0KPiBzZmMtDQo+ID4+IHNlcnZpY2VpZC1oZWFkZXItMTANCj4gPj4NCj4gPj4gSGVo IC0gb25lIHR5cG8gY29ycmVjdGlvbiBiZWxvdyAodGhhdCBtaWdodCBoYXZlIGJlZW4gb2J2aW91 cywNCj4gPj4gYnV0Li4uKQ0KPiA+Pg0KPiA+PiBPbiAxMC8yNi8yMCA1OjI1IFBNLCBSb2JlcnQg U3BhcmtzIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCj4gPj4+IFJldmlld2VyOiBSb2JlcnQgU3Bh cmtzDQo+ID4+PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPiA+Pj4NCj4gPj4+IEkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5DQo+ID4+IGRpcmVj dG9yYXRlJ3MNCj4gPj4+IG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVu dHMgYmVpbmcgcHJvY2Vzc2VkIGJ5DQo+IHRoZQ0KPiA+Pj4gSUVTRy4gVGhlc2UgY29tbWVudHMg d2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YNCj4gdGhlDQo+ID4+PiBz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNo b3VsZA0KPiA+PiB0cmVhdA0KPiA+Pj4gdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4+Pg0KPiA+Pj4gVGhpcyBkb2N1bWVudCBoYXMgbml0 cyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQgYmVmb3JlDQo+IHB1YmxpY2F0aW9uDQo+ID4+IGFz DQo+ID4+PiBQcm9wb3NlZCBTdGFuZGFyZCBSRkMuDQo+ID4+Pg0KPiA+Pj4gRG9jdW1lbnQgcmV2 aWV3ZWQ6IGRyYWZ0LWlldGYtc2ZjLXNlcnZpY2VpZC1oZWFkZXItMTANCj4gPj4+DQo+ID4+PiBU aGlzIGRvY3VtZW50J3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVzdCBvbiB0aGUgcHJlbWlz ZSB0aGF0DQo+ID4+IHRoZQ0KPiA+Pj4gaW5mb3JtYXRpb24gaXQgZGlzY3Vzc2VzIHdpbGwgYmUg YWRkZWQsIHRyYW5zcG9ydGVkLCBjb25zdW1lZCwNCj4gYW5kDQo+ID4+PiByZW1vdmVkIHdpdGhp biBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gdGhhdCBpcyBwcm90ZWN0ZWQNCj4gPj4g ZnJvbQ0KPiA+Pj4gZWF2ZXNkcm9wcGVycyBhbmQgbWFsaWNpb3VzIG9uLXBhdGggYXR0YWNrZXJz IHRocm91Z2gNCj4gPj4gYWRtaW5pc3RyYXRpdmUNCj4gPj4+IGNvbnRyb2xzLiBJdCBpcyBxdWl0 ZSB1cGZyb250IGFib3V0IHRoYXQgYXNzdW1wdGlvbiwgYW5kIHRoZSBzZmMNCj4gPj4+IGRvY3Vt ZW50cyBpdCByZWxpZXMgb24gbWFrZSB0aGUgc2FtZSBhc3NlcnRpb25zLg0KPiA+Pj4NCj4gPj4+ IFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyBhIG1lY2hhbmlzbSB0aGF0IGludGVudGlvbmFsbHkg YWxsb3dzDQo+ID4+PiBpZGVudGlmaWVycw0KPiA+Pj4gKGFkZHJlc3NlcykgdGhhdCB3b3VsZCBu b3JtYWxseSBiZSBoaWRkZW4vY29udGFpbmVkIGJlaGluZCBhIG5hdA0KPiA+PiB0byBiZQ0KPiA+ Pj4gc2hhcmVkIGJleW9uZCB0aGF0IG5hdCwgYnV0IGFnYWluLCB3aXRoaW4gdGhhdCBzaW5nbGUN Cj4gPj4gYWRtaW5pc3RyYXRpdmUgZG9tYWluLg0KPiA+Pj4gTklUUzoNCj4gPj4+DQo+ID4+PiBU aGVyZSBhcmUgbWFueSBwbGFjZXMgd2hlcmUgdGhlIGxhbmd1YWdlIGluIHRoZSBkb2N1bWVudCBu ZWVkcw0KPiB0bw0KPiA+PiBiZQ0KPiA+Pj4gc2ltcGxpZmllZC4gVGhlcmUgYXJlIGFsc28gbWFu eSBwbGFjZXMgd2hlcmUgMjExOSBsYW5ndWFnZSBpcw0KPiA+PiBiZWluZw0KPiA+Pj4gdXNlZCBp biBhIHdheSB0aGF0IGRvZXMgbm90IG1ha2Ugc2Vuc2UuDQo+ID4+Pg0KPiA+Pj4gSW4gZG9jdW1l bnQgb3JkZXI6DQo+ID4+Pg0KPiA+Pj4gSW50cm9kdWN0aW9uIHBhcmFncmFwaCAyLCBzZW50ZW5j ZSAxLiBXaGF0IGRvZXMgaXQgbWVhbiB0byBpbmZlcg0KPiA+PiBlbmZvcmNlbWVudD8NCj4gPj4+ IFBlcmhhcHMgeW91IG1lYW4gInBvbGljaWVzIGNhbiBiZSBpbmZlcnJlZCI/IFBsZWFzZSBzaW1w bGlmeQ0KPiB0aGlzDQo+ID4+IHNlbnRlbmNlLg0KPiA+Pj4gQnJlYWsgdGhlIGV4YW1wbGUgaW50 byBhIHNlcGFyYXRlIHNlbnRlbmNlIGFuZCBhZGQgZGV0YWlsIGlmIHlvdQ0KPiA+PiBjYW4uDQo+ ID4+PiBJZiBwb3NzaWJsZSwgcHJvdmlkZSBhIHJlZmVyZW5jZSB0byB3aGF0IHlvdSBtZWFuIGJ5 ICJTRkMtYmFzZWQNCj4gPj4+IGRpZmZlcmVudGlhdGVkIHRyYWZmaWMgcG9saWNpZXMiIG1lYW5z Lg0KPiA+Pj4NCj4gPj4+IEludHJvZHVjdGlvbiBwYXJhZ3JhcGggMy4gVGhpcyB3aG9sZSBwYXJh Z3JhcGggaGFzIGNvbXBsaWNhdGVkLA0KPiA+Pj4gcGFyYWdyYXBoDQo+ID4+IFRoYXQgbGFzdCB3 b3JkIHNob3VsZCBoYXZlIGJlZW4gImNvbW1hIg0KPiA+Pj4gc2VwYXJhdGVkLCBwaHJhc2VzIHRo YXQgc2hvdWxkIGJlIHdyaXR0ZW4gbW9yZSBzaW1wbHkuIFRoZSBuZXh0DQo+IHRvDQo+ID4+PiBs YXN0IHNlbnRlbmNlIChhdCA1MyB3b3JkcykgaXMgcGFydGljdWxhcmx5IGhhcmQgdG8gZm9sbG93 Lg0KPiA+Pj4NCj4gPj4+IEludHJvZHVjdGlvbiBwYXJhZ3JhcGggNCwgbGFzdCBzZW50ZW5jZS4g VGhpcyBzZW50ZW5jZSBkb2VzIG5vdA0KPiA+PiBwYXJzZS4NCj4gPj4+IFBsZWFzZSByZXdvcmsg aXQuDQo+ID4+Pg0KPiA+Pj4gSW50cm9kdWN0aW9uIHBhcmFncmFwaCA1LiBUaGlzIG9uZSBzZW50 ZW5jZSBwYXJhZ3JhcGggd2FzIHRoZQ0KPiBtb3N0DQo+ID4+PiBkaWZmaWN1bHQgaW4gdGhlIGRv Y3VtZW50IGZvciBtZSB0byByZWFkLiBQbGVhc2UgYnJlYWsgaXQgaW50bw0KPiA+PiBzZXZlcmFs IHNpbXBsZXIgc2VudGVuY2VzLg0KPiA+Pj4gU2VjdGlvbiAzOiBhdCAiSW4gb3JkZXIgdG8gcHJl dmVudCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcywgdGhlDQo+ID4+IGRhdGENCj4gPj4+IGFuZCB0 aGVpciBmb3JtYXQgdG8gYmUgaW5qZWN0ZWQgaW4gc3VjaCBoZWFkZXIgU0hPVUxEIGJlDQo+ID4+ IGNvbmZpZ3VyZWQgdG8NCj4gPj4+IG5vZGVzIGF1dGhvcml6ZWQgdG8gaW5qZWN0IHN1Y2ggaGVh ZGVycy4iIFRoaXMgaXMgbm90IGEgMjExOQ0KPiA+PiBTSE9VTEQuDQo+ID4+PiBJdCdzIGV2ZW4g bm90IGNsZWFyIHdoYXQgInRoZSBkYXRhIiBpcyBoZXJlLiBJIHN1Z2dlc3Qgc29tZXRoaW5nDQo+ ID4+IGxpa2UNCj4gPj4+ICJUaGUgaWRlbnRpZmllcnMgY2FycmllZCBpbiB0aGUgQ29udGV4dCBI ZWFkZXJzIGFyZSBvcGFxdWUuDQo+IE5vZGVzDQo+ID4+PiBwcm92aWRpbmcgdGhlbSBhbmQgY29u c3VtaW5nIHRoZW0gd2lsbCBiZSBjb25maWd1cmVkIHdpdGggdGhlDQo+ID4+IG5lY2Vzc2FyeSBp bmZvcm1hdGlvbiBuZWVkZWQgc2VlIGludG8gdGhlbS4iDQo+ID4+PiBTZWN0aW9uIDMsIGF0ICJG YWlsdXJlcyB0byBpbmplY3Qgc3VjaCBoZWFkZXJzIFNIT1VMRCBiZSBsb2dnZWQNCj4gPj4+IGxv Y2FsbHkgd2hpbGUgYSBub3RpZmljYXRpb24gYWxhcm0gTUFZIGJlIHNlbnQgdG8gYSBDb250cm9s DQo+ID4+IEVsZW1lbnQuDQo+ID4+PiBUaGUgZGV0YWlscyBvZiBzZW5kaW5nIG5vdGlmaWNhdGlv biBhbGFybXMgKGkuZS4sIHRoZSBwYXJhbWV0ZXJzDQo+ID4+PiBhZmZlY3RpbmcgdGhlIHRyYW5z bWlzc2lvbiBvZiB0aGUgbm90aWZpY2F0aW9uIGFsYXJtcyBkZXBlbmQgb24NCj4gPj4gdGhlDQo+ ID4+PiBpbmZvcm1hdGlvbiBpbiB0aGUgQ29udGV4dCBIZWFkZXIgc3VjaCBhcyBmcmVxdWVuY3ks IHRocmVzaG9sZHMsDQo+ID4+IGFuZA0KPiA+Pj4gY29udGVudCBvZiB0aGUgYWxhcm0gKGZ1bGwg aGVhZGVyLCB0aW1lc3RhbXAsIGV0Yy4pKSBTSE9VTEQgYmUNCj4gPj4+IGNvbmZpZ3VyYWJsZS4i IE5vbmUgb2YgdGhlc2UgYXJlIGNvcnJlY3QgdXNlIG9mIDIxMTkuIENvbnNpZGVyDQo+IHJlLQ0K PiA+PiBmcmFtaW5nIHRoZSBwYXJhZ3JhcGggd2l0aG91dCB1c2luZyB0aGVzZSB0ZXJtcy4NCj4g Pj4+IFNlY3Rpb24gMyBhdCAiVGhhdCBpcywgdG8gc3RyaXAgc3VjaCBDb250ZXh0IEhlYWRlcnMu IiBpcyBub3QgYQ0KPiA+PiBzZW50ZW5jZS4NCj4gPj4+IFNlY3Rpb24gMyBhdCB0aGUgcGFyYWdy YXBoIGJlZ2lubmluZyAiRGVwZW5kaW5nIG9uIGxvY2FsDQo+IHBvbGljeSIuDQo+ID4+IFRoZQ0K PiA+Pj4gc3RydWN0dXJlIG9mIHRoaXMgcGFyYWdyYXBoIGlzIHZlcnkgb2RkLiBEb2Vzbid0IGJh c2UgU0ZDIHNheSB0bw0KPiA+Pj4gcHJlc2VydmUgTlNIIGF0IGludGVybWVkaWFyaWVzPyBJIHN1 Z2dlc3QgcmVwbGFjaW5nIHRoaXMNCj4gcGFyYWdyYXBoDQo+ID4+PiB3aXRoIHNvbWV0aGluZyBs aWtlICJOb3JtYWwgU0ZDIGludGVybWVkaWFyeSBiZWhhdmlvciBwcmVzZXJ2ZXMNCj4gPj4+IE5l dHdvcmsgU2VydmljZSBIZWFkZXJzLiBMb2NhbCBwb2xpY3kgY2FuIHJlcXVpcmUgYSBwcm94eSB0 bw0KPiBzdHJpcA0KPiA+PiAuLi4iDQo+ID4+PiBTZWN0aW9uIDMgYXQgIk5TSC1hd2FyZSBTRnMg TVVTVCBiZSBjYXBhYmxlIHRvIHJ1biBhZGRpdGlvbmFsDQo+ID4+PiB2YWxpZGF0aW9uIGNoZWNr cyIuIFRoaXMgaXNuJ3QgMjExOS4gUGVyaGFwcyB5b3UgbWVhbiB0byBzYXkgIkJlDQo+ID4+IGF3 YXJlDQo+ID4+PiB0aGF0IGxvY2FsIHBvbGljaWVzIG1heSByZXF1aXJlIHJ1bm5pbmcgYWRkaXRp b25hbCB2YWxpZGF0aW9uDQo+ID4+IGNoZWNrcw0KPiA+Pj4gYXQgTlNILWF3YXJlIFNGcyIuIFRo ZSB3aG9sZSBwYXJhZ3JhcGggY2FuIGJlIHNpbXBsaWZpZWQuDQo+ID4+Pg0KPiA+Pj4gU2VjdGlv biAzIGF0ICJNdWx0aXBsZSBTdWJzY3JpYmVyIElkZW50aWZpZXIgQ29udGV4dCBIZWFkZXJzIE1B WQ0KPiA+PiBiZQ0KPiA+Pj4gcHJlc2VudCBpbiB0aGUgTlNILCBlYWNoIGNhcnJ5aW5nIGEgZGlz dGluY3Qgb3BhcXVlIHZhbHVlIGJ1dA0KPiBhbGwNCj4gPj4+IHBvaW50aW5nIHRvIHRoZSBzYW1l IHN1YnNjcmliZXIuIiBUaGlzIGlzIGEgcGxhY2Ugd2hlcmUgYSAyMTE5DQo+ID4+IE1VU1QNCj4g Pj4+IF93b3VsZF8gbWFrZSBzZW5zZS4gU2F5ICJTdWNoIG11bHRpcGxlIGhlYWRlcnMgTVVTVCBp ZGVudGlmeSB0aGUNCj4gPj4gc2FtZQ0KPiA+Pj4gc3Vic2NyaWJlciIuIEkgd29uZGVyLCB0aG91 Z2gsIGlmIHlvdSdyZSBjbG9zaW5nIGEgZG9vciBvbg0KPiA+PiBjYXJyeWluZyBtdWx0aXBsZSBp ZGVudGl0aWVzIHRoYXQgeW91J2xsIHJlZ3JldCBsYXRlci4NCj4gPj4+IFNlY3Rpb24gNCBmaXJz dCBwYXJhZ3JhcGgsIGZpcnN0IHNlbnRlbmNlOiBJIHN1Z2dlc3QgcmVwbGFjaW5nDQo+ID4+ICJp ZGVudGlmaWVyIGlzIg0KPiA+Pj4gd2l0aCAiaWRlbnRpZmllcnMgYXJlIg0KPiA+Pj4NCj4gPj4+ IFNlY3Rpb24gNCBmaWZ0aCBwYXJhZ3JhcGg6ICJkZWZpbmVkIGFzIG9wdGlvbmFsIiAtPiAiZGVm aW5lZCBhcw0KPiBhbg0KPiA+PiBvcHRpb25hbCINCj4gPj4+IFNlY3Rpb24gNCBzaXh0aCBwYXJh Z3JhcGguIFNpbWlsYXIgdG8gdGhlIHNlY3Rpb24gMyBwYXJhZ3JhcGggSQ0KPiA+PiBwb2ludA0K PiA+Pj4gdG8gYWJvdmUsIHRoZSBzdHJ1Y3R1cmUgaGVyZSBpcyB2ZXJ5IG9kZC4gQWdhaW4sIEkg c3VnZ2VzdA0KPiA+PiBzb21ldGhpbmcNCj4gPj4+IGxpa2UgIk5vcm1hbCBTRkMgaW50ZXJtZWRp YXJpZXMgd2lsbCBwcmVzZXJ2ZSBDb250ZXh0IEhlYWRlcnMsDQo+IGJ1dA0KPiA+Pj4gbG9jYWwg cG9saWN5IG1heSByZXF1aXJlIGEgcHJveHkgdG8gdG8gc3RyaXAgb25lIGFmdGVyDQo+IHByb2Nl c3NpbmcNCj4gPj4gaXQuIg0KPiA+Pj4gU2VjdGlvbiA0IHNldmVudGggcGFyYWdyYXBoOiAib2Nu bGZpY3RpbmciLT4iY29uZmxpY3RpbmciLiBJDQo+ID4+IGFzc3VtZQ0KPiA+Pj4gdGhlIGRlZmF1 bHQgYmVoYXZpb3IgZGVzY3JpYmVkIGhlcmUgaXMgc3BlY2lmaWVkIGluIHRoZSBiYXNlIE5TSA0K PiA+PiBkb2NzPw0KPiA+Pj4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBwYXJhZ3Jh cGggNDogQ29uc2lkZXIgImxvZ2dpbmcNCj4gdGhlDQo+ID4+PiBjb250ZW50IG9mIC4uLiBpcyBu b3QgYWR2aXNlZCIgcmF0aGVyIHRoYW4gdXNpbmcgMjExOSBoZXJlLiBUaGUNCj4gPj4+IHBhcmFn cmFwaCB3b3VsZCBiZSBiZXR0ZXIgZm9ybXVsYXRlZCBpZiBpdCBleHBsYWluZWQgdGhlIHJpc2sg LQ0KPiA+PiBTRnMNCj4gPj4+IHRoYXQgX2RpZF8gdXNlIHRoZSBjb250ZXh0IG1pZ2h0IGJlIGJl dHRlciBvZmYgbm90IGxvZ2dpbmcgdGhlbQ0KPiBpbg0KPiA+PiBtYW55IGNhc2VzIGFzIHdlbGwu DQo+ID4+Pg0KPiA+Pj4NCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Oct 28 08:09:53 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28263A0A4F; Wed, 28 Oct 2020 08:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_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=toke.dk 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 Vjb_i1e6gCgY; Wed, 28 Oct 2020 08:09:44 -0700 (PDT) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 892453A0A07; Wed, 28 Oct 2020 08:09:42 -0700 (PDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1603897780; bh=xcM9fMc6mYay+UQq1lWdtKNWEfmwAftQ8TvUh88U6Pg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=qP5arfTFQNHx6VacQnTHNn0hBZ4Mx+iu+vBeZcYSqsV3slXdRgyufuEvUDjlLaQ4i OXeqniZGFxgfHGyWhv871W3iRdgKRoT5Kj1fJXJ4KqDwKYkFnbq08nqELFDfMi5iVK NbldiGbVkIHUSgPM0UX6qmICCxIBl+bRGEvBakuPGNGNQBlxT2CWUlsyK8/AblXv5n T+b/cjLvm4VleNcgJiZ8TphIi4E7DtqExOkb7OYMffZPebw3Y+remoKfby1dp8Axhy 8wYBknTxBg5mliB/QRcCsZ9csMgilFet6/q53kFpHBtNmGqp01hPHfMEsMvv8AEUhX RFl9pDIJU5Omg== To: Juliusz Chroboczek , Rifaat Shekh-Yusef Cc: last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org, secdir@ietf.org In-Reply-To: <87o8kmfo2n.wl-jch@irif.fr> References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> <87o8kmfo2n.wl-jch@irif.fr> Date: Wed, 28 Oct 2020 16:09:39 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87mu06mlos.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [babel] Secdir last call review of draft-ietf-babel-source-specific-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 15:09:46 -0000 Juliusz Chroboczek writes: >> =E2=80=9CA node MUST NOT send more that one Source Prefix sub-TLV in a= TLV, >> and a node receiving more than one Source Prefix sub-TLV in a single >> TLV SHOULD ignore this TLV. It MAY ignore the whole packet.=E2=80=9D > >> 2. This paragraph implies that a node might accept the TLV with more tha= n one >> Source Prefix sub-TLV, but it does not state when a node can do that. Yo= u might >> want to elaborate on the conditions that a node is allowed to do that. > > Right. I've made this a MUST, which reflects implementation practice. > Group, please feel free to object if you think this is the wrong > choice. SGTM. -Toke From nobody Wed Oct 28 16:09:48 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259273A0A8F; Wed, 28 Oct 2020 16:09:42 -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, FREEMAIL_FROM=0.001, 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 (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 2WUbihlmsSsj; Wed, 28 Oct 2020 16:09:40 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 913DE3A0A90; Wed, 28 Oct 2020 16:09:40 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id d24so1018187ljg.10; Wed, 28 Oct 2020 16:09:40 -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=gkHrB5j9y4WAK2GkxzYCi9Bp1Ziv7BqjU+9s7GWr9AA=; b=l1wsOZnusKEa+PKuWqRvi0s6dyvFOOkKNVWl59a/Rw5974bF2kZ8LI7CkuHVe0FaQH L88UWsw00lB7zEvqwqhHqExM/wOHi+t+0ekIvIcPxa7UR4aUCyCSW6tHifn4uTQH67wl WM7J17xc8iHCcVLx8EzPfd59bzu1qk4mzAYN2BtbqF8vVtAoiTHQsZ79upTyRQjwOl+m cYMmQOH8IRClvrwbHDxnLF4/xGoo7FvbpXxqiI9W9H2GRXJlCH3UhV0CnAOnFsX9/z+N YvwSoiHpTM6x2SIWVoNrnkS21Rn1FzKMu3sZXKi1Q/uG3JsEf5mFWZeVAlooe2xvpNCL 7R6Q== 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=gkHrB5j9y4WAK2GkxzYCi9Bp1Ziv7BqjU+9s7GWr9AA=; b=fvNzFyQ6sWABO7lZy+d2tE9lY1/XNiW1ns5LXenReFeMD79FBu4uKbMEXLB5aJjFy1 twLvL+G/wrtgQz5iD6ijvZ/nXhmRK7dYYHpfPIAUguhfg5j1QFJpg2i5WdglBjX9rhB1 vIYYfLI6eXdXgM+UgbYzl04YfjyJBcGg29rt69gF5YBho9qb6p9YNH9qe8ELDY4uPPDT lMZaJYF6YEf1ronYiCZuG+3+OPtZkFSP8kk9WJIx7tHvtYpuPzkHxdX5HOmYgd8WceXD FIsr65kjyJr5qPi/AARtKJk4eXoDTcy6eUdvfH3lDGiisLaw86GHJw/p2LXeUp+zRwLf rYpA== X-Gm-Message-State: AOAM531VPwPVmPXuS89GNXMyrERE0BWo5n1gf2cS/21GqV2z3GLuMnqD eIodL8+zipmeo5lLsBtt7e+/u1bTlOJFMUKHdA3wOOGWx3g= X-Google-Smtp-Source: ABdhPJyuy9VGK05E7k4Ni73IvF96+8VcHtnOe+shv5X4HPafaBOxNvLOaFERv3sOAvQlw6ZDGzRdutmyWRMPZV+ndsM= X-Received: by 2002:a2e:9882:: with SMTP id b2mr542460ljj.247.1603926578814; Wed, 28 Oct 2020 16:09:38 -0700 (PDT) MIME-Version: 1.0 References: <160364731499.17476.11455568556595523172@ietfa.amsl.com> <87o8kmfo2n.wl-jch@irif.fr> <87mu06mlos.fsf@toke.dk> In-Reply-To: <87mu06mlos.fsf@toke.dk> From: David Schinazi Date: Wed, 28 Oct 2020 16:09:26 -0700 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Juliusz Chroboczek , Rifaat Shekh-Yusef , last-call@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, Babel at IETF , secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000f9e32105b2c34130" Archived-At: Subject: Re: [secdir] [Last-Call] [babel] Secdir last call review of draft-ietf-babel-source-specific-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 23:09:42 -0000 --000000000000f9e32105b2c34130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable SGTM2 On Wed, Oct 28, 2020 at 8:10 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Juliusz Chroboczek writes: > > >> =E2=80=9CA node MUST NOT send more that one Source Prefix sub-TLV in= a TLV, > >> and a node receiving more than one Source Prefix sub-TLV in a singl= e > >> TLV SHOULD ignore this TLV. It MAY ignore the whole packet.=E2=80= =9D > > > >> 2. This paragraph implies that a node might accept the TLV with more > than one > >> Source Prefix sub-TLV, but it does not state when a node can do that. > You might > >> want to elaborate on the conditions that a node is allowed to do that. > > > > Right. I've made this a MUST, which reflects implementation practice. > > Group, please feel free to object if you think this is the wrong > > choice. > > SGTM. > > -Toke > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > --000000000000f9e32105b2c34130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SGTM2

On Wed, Oct 28, 2020 at 8:10 AM Toke H=C3=B8iland-J= =C3=B8rgensen <toke=3D40toke= .dk@dmarc.ietf.org> wrote:
Juliusz Chroboczek <jch@irif.fr> writes:

>>=C2=A0 =C2=A0=E2=80=9CA node MUST NOT send more that one Source Pre= fix sub-TLV in a TLV,
>>=C2=A0 =C2=A0 and a node receiving more than one Source Prefix sub-= TLV in a single
>>=C2=A0 =C2=A0 TLV SHOULD ignore this TLV.=C2=A0 It MAY ignore the w= hole packet.=E2=80=9D
>
>> 2. This paragraph implies that a node might accept the TLV with mo= re than one
>> Source Prefix sub-TLV, but it does not state when a node can do th= at. You might
>> want to elaborate on the conditions that a node is allowed to do t= hat.
>
> Right.=C2=A0 I've made this a MUST, which reflects implementation = practice.
> Group, please feel free to object if you think this is the wrong
> choice.

SGTM.

-Toke

--
last-call mailing list
last-call@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/last-call
--000000000000f9e32105b2c34130-- From nobody Thu Oct 29 14:05:14 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E2A3A00E3 for ; Thu, 29 Oct 2020 14:05:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <160400551219.15343.7126865829089748009@ietfa.amsl.com> Date: Thu, 29 Oct 2020 14:05:12 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 21:05:13 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-11-05 Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-12 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-14 Hilarie Orman R2020-07-09 draft-ietf-acme-email-smime-10 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Stefan Santesson 2020-10-28 draft-ietf-emu-eaptlscert-06 Takeshi Takahashi 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Last calls: Reviewer LC end Draft Derek Atkins R2020-09-04 draft-ietf-i2nsf-sdn-ipsec-flow-protection-11 Daniel Franke 2020-09-18 draft-ietf-jmap-mdn-15 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-10 Daniel Gillmor 2020-09-30 draft-ietf-ccamp-layer0-types-08 Phillip Hallam-Baker 2020-09-30 draft-ietf-lwig-tcp-constrained-node-networks-11 Steve Hanna 2020-09-30 draft-ietf-ccamp-wson-yang-27 Dan Harkins None draft-ietf-rtgwg-policy-model-03 Leif Johansson 2020-10-02 draft-ietf-lpwan-schc-over-lorawan-12 Scott Kelly 2020-10-01 draft-ietf-idr-tunnel-encaps-19 Aanchal Malhotra 2020-10-12 draft-ietf-dots-server-discovery-14 Catherine Meadows 2020-10-21 draft-ietf-6lo-blemesh-08 Kathleen Moriarty 2020-07-20 draft-ietf-ace-oscore-profile-13 Russ Mundy 2020-07-20 draft-ietf-ace-dtls-authorize-14 Sandra Murphy 2020-10-15 draft-ietf-tls-external-psk-importer-05 Magnus Nystrom 2020-11-16 draft-ietf-quic-qpack-19 Hilarie Orman 2020-11-16 draft-ietf-quic-http-32 Hilarie Orman R2020-07-09 draft-ietf-acme-email-smime-10 Radia Perlman 2020-11-16 draft-ietf-quic-tls-32 Radia Perlman 2020-11-12 draft-ietf-dots-signal-call-home-11 Derrell Piper 2020-11-16 draft-ietf-quic-recovery-32 Derrell Piper 2020-11-11 draft-ietf-suit-information-model-08 Tirumaleswar Reddy.K 2020-11-16 draft-ietf-quic-transport-32 Rich Salz R2020-08-14 draft-ietf-suit-architecture-14 Stefan Santesson 2020-10-28 draft-ietf-emu-eaptlscert-06 Yaron Sheffer 2020-10-27 draft-ietf-detnet-security-12 Yaron Sheffer R2020-10-16 draft-ietf-tls-exported-authenticator-13 Takeshi Takahashi 2020-10-21 draft-ietf-idr-flow-spec-v6-17 Klaas Wierenga 2020-05-26 draft-ietf-kitten-krb-spake-preauth-09 Christopher Wood 2020-09-23 draft-ietf-6man-rfc4941bis-11 Paul Wouters 2020-09-08 draft-ietf-i2nsf-capability-data-model-12 Next in the reviewer rotation: Francesca Palombini Radia Perlman Derrell Piper Tirumaleswar Reddy.K Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer From nobody Thu Oct 29 16:13:12 2020 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D90363A09D1; Thu, 29 Oct 2020 16:13:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: last-call@ietf.org, draft-ietf-emu-eaptlscert.all@ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160401318284.11167.6795105917637378641@ietfa.amsl.com> Reply-To: Stefan Santesson Date: Thu, 29 Oct 2020 16:13:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 23:13:03 -0000 Reviewer: Stefan Santesson Review result: Has Nits The document in general is good and well written. Some nits needs attention before publication as the general review also points out. Ex in the abstract "This document looks at the this problem" Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum Transmission Unit) On the content itself I have two questions: - Wouldn't it be relevant to also discuss the risks with regard to introduction of quantum safe crypto, if that leads to significantly increased key sizes? It could be troublesome if transition to a safer crypto is made impossible due to size limitations. - Would it be relevant to discuss usage of AIA extension as means of possibly excluding intermediary certs from the path as they could be located using AIA? Finally, I agree with the general review that this document reference quite some work in progress. If this document is to be published before these referenced works are concluded, are there alternatives to make the same point? From nobody Thu Oct 29 20:04:38 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CC33A0D67; Thu, 29 Oct 2020 20:04:28 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 qZ5si9zKwcLc; Thu, 29 Oct 2020 20:04:26 -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 465C33A0D66; Thu, 29 Oct 2020 20:04:25 -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 09U34F8w028039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 29 Oct 2020 23:04:20 -0400 Date: Thu, 29 Oct 2020 20:04:15 -0700 From: Benjamin Kaduk To: Stefan Santesson Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-emu-eaptlscert.all@ietf.org, emu@ietf.org Message-ID: <20201030030415.GE39170@kduck.mit.edu> References: <160401318284.11167.6795105917637378641@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160401318284.11167.6795105917637378641@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 03:04:28 -0000 Hi Stefan, Thanks for the review; it raises some good topics. Replying on a couple points... On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatracker wrote: > Reviewer: Stefan Santesson > Review result: Has Nits > > The document in general is good and well written. > > Some nits needs attention before publication as the general review also points > out. Ex in the abstract "This document looks at the this problem" > > Some abbreviations needs to be spelled out at first usage, such as MTU (Maximum > Transmission Unit) MTU may actually be okay; per https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marked as "well-known" and does not always need to be expanded. > On the content itself I have two questions: > > - Wouldn't it be relevant to also discuss the risks with regard to introduction > of quantum safe crypto, if that leads to significantly increased key sizes? It > could be troublesome if transition to a safer crypto is made impossible due to > size limitations. - Would it be relevant to discuss usage of AIA extension as > means of possibly excluding intermediary certs from the path as they could be > located using AIA? > > Finally, I agree with the general review that this document reference quite > some work in progress. If this document is to be published before these > referenced works are concluded, are there alternatives to make the same point? They seem to mostly be informative references, and so would not require us to hold publication of this document. It is probably still worth considering if there are alternatives anyway, though. -Ben From nobody Fri Oct 30 06:48:51 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D123A0EA9; Fri, 30 Oct 2020 06:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 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, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-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=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 bE88ZMQODUBd; Fri, 30 Oct 2020 06:48:39 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2046.outbound.protection.outlook.com [40.107.22.46]) (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 2555E3A0EAA; Fri, 30 Oct 2020 06:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GEB102smUNi7NZGrUka8cGVKCAnhhMzcAgU09l1M/82b9vv0MbzKHwy/UnTXsYmA4vwX98EAnvZnZsl5vod5Aip/rDqNdxTNNQc+PLXGT3r+N2eiGhSE3Z1DaxC1slCf4JjqIE+jii/BB3wEgRlcwgFPhAqPDrwBdROwzlCBuLlWXoaRac7fiNvRtrn1PmkLyxM4ZLvz1KCiS/m+EGqz+mxE9Y0kNxIVApGijZVgpJukQIMSxh45crB9xzuhwivBlZQwvnbsbKLSW5Ap2s2c9Eporb+8HTqQdMul8l404Ss3PS7v8bXMQ/bzPzZirI8Xw+Jr3R6on68QkLmcoU6tZA== 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=pYCXdhp4G0/RUuWv8YZ95LSVyexi7dxkw4geU02Q2C4=; b=BzWBJsGUaflf/wl8dZ9I0+1q2aInHRxqbH8tGEWnUmzzMxLIOdsibuXqpFFYA0rOB4zC8rWpuPpWtf7OXJSu2s2dTXjmROzxmIJGlRDQOw3dflKXHhD68IXgE7SPdvsJ9bDwLnOBu54mXuRU/Ja/jDEVZ4qaTz4/2ENfCLOIcUv5fch4+VAkKWfd5fwWrU9LUIeuw1rEUD05ShqyMf0+APfpdyjIYkw2NFCPm3wXjkhFnmk+S51nvwUSqNOMPoHUr03dd+awfMiEn/byiyVwlj9XPpLsAG2P+Y0h1W36jJTJQR1sy7hJPo55/txWg9fbP0cH7jVp35RkEFEI7kW8bw== 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=pYCXdhp4G0/RUuWv8YZ95LSVyexi7dxkw4geU02Q2C4=; b=imAWpWgG+3ftncTToSWb4Bpba+8FLf4b7TgW5lrkikYPfgmXE6fXGG6W0wbrh/NLye+/CovreZl6PbvW9MihxnjmUwjoQJmPjCuH2/PQbbNqmMP+WGjmdnQDkb8v/n2oR/0pTP10qfQmCt/Smmbp7Yhy0di4RADOrWcwUSEXCyg= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR07MB4282.eurprd07.prod.outlook.com (2603:10a6:7:a1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.14; Fri, 30 Oct 2020 13:48:36 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca%6]) with mapi id 15.20.3499.028; Fri, 30 Oct 2020 13:48:36 +0000 From: Mohit Sethi M To: Benjamin Kaduk , Stefan Santesson CC: "last-call@ietf.org" , "draft-ietf-emu-eaptlscert.all@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Thread-Topic: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 Thread-Index: AQHWrkkTSwTr5auJQke8Pqw//Tx6KKmvdiCAgAC0B4A= Date: Fri, 30 Oct 2020 13:48:36 +0000 Message-ID: <12167567-9dc5-6161-abef-826b0a8b6602@ericsson.com> References: <160401318284.11167.6795105917637378641@ietfa.amsl.com> <20201030030415.GE39170@kduck.mit.edu> In-Reply-To: <20201030030415.GE39170@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [37.136.189.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba5d73b1-d910-40ef-0ac3-08d87cda8001 x-ms-traffictypediagnostic: HE1PR07MB4282: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: waP+WaeO/N3ilp8m4JZ4dq1EBrvMYt1UMn2ZymoyjK1DogGS57NewyUltnaSGxMbqMy9ybw19gd1vf4yA5hFllrvS8xpj1YyUiOER7yZNX2PJxoSTQWhq/5J7WfTjSy/9DD04la1GIGSgGDnvgWPQjFLdOWvIJXC6vDomBTjlSuzDI7GDx5PWF7634SooBFYJq9ULHXJJtlIZ34LOa5dO0xWgFcNakAUfNU6sw80GVE7AgF3cDKj65gEgcjn/v6S9Y7e1nAUfmDnf0zZP1WSorS4BMEnyadAA1NijLo54RZDRuX6JtB7NAm+TY7REZ9q7NSTZCZ97goa32pRppKI8imYOtL6nmiLxi7eQRX4E5VP0tx+EXUwKVJKCioKcWSnDfCnoeO0OArGFEZ9ZkSjsp0fnizGySf/VihUbummlnD5VaaExbq53LHLDD9rRxZq55sXDJRHFKq9ug4zGzN+Tg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(39860400002)(396003)(346002)(8676002)(86362001)(36756003)(6512007)(8936002)(4326008)(2906002)(71200400001)(6486002)(26005)(478600001)(66946007)(66476007)(66556008)(66446008)(966005)(64756008)(76116006)(316002)(31686004)(186003)(110136005)(54906003)(31696002)(2616005)(53546011)(6506007)(83380400001)(5660300002)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ytX6PwytVD694xiBp7MY2kOIozHeL89H8cw4+4wdYS9CaxLNXiNGtEWvVy+UU/I6jgn4aDaa6wqcK6mveeLZtKB2L+xxHRLNJF+F0YacEefv1mA3rLWuh1lo92yZQmjmikx5G6HQ9ack0w+agWJrNOPfCW61tSXheZzn9VP5TEHUx5EBc+Yqts5fErRwFrBJPWV6FwcfP1BZPcIT2WbJn/XmClHnyanWSRVFvFYreMz8q9qSgt66A8dOeGMdYaJk0PCBoy9fmSSs/lOcd4aBwkfvC6TXXE69aewbgUrXLqfWZsr7Zx1RJpcfjNCh8X9KN8Jff/2pwS3Pj5zjCjrfbl0Eh5W5KDSUv3JSc5M1cZWlDKyFr2x+WR+L1xNrMnjaWtIAaSExpSMikPpUcZAgsx8dfBKfclfSicNtqYGOfnnkTyE0pZa5D5tlydxfkAqlwHX3HWTuAOrQdv4enacZ2ijFvyLuWFWj6H8hs2bHEarDI+6Uq6YS/Sv8NBcrP+FMZPKafN+cvC/PVi7ByZzWS8LI3mIuA04GKYajGcm6G/j6iw605eDJc+AfVo2dmLfrHFggqEme5qRhNr/VvOliaKdRvt5quIqAx/PYeXn7390Jy8c2y/5R7L4a/zNEJM+HvRLluH+x/wRCPq8wjc4T8w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <50D831937F3C6640BB6348DC7A79BC5D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba5d73b1-d910-40ef-0ac3-08d87cda8001 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2020 13:48:36.3522 (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: cDhwQMKaSL26ZeT2OlBLq7rkMijy+RNUV6LGwXc683DH1YUvUatECBKIgahOTOnFOOxtJvNKavKXNagHH/NUMznBwp+P7u89ugYDags7sjI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4282 Archived-At: Subject: Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 13:48:42 -0000 SGkgU3RlZmFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIEkgaGF2ZSB1cGRhdGVkIHRo ZSBkcmFmdCBpbiBnaXRodWIgDQooaHR0cHM6Ly9naXRodWIuY29tL2VtdS13Zy9lYXB0bHMtbG9u Z2NlcnQpLiBIZXJlIGlzIHRoZSBkaWZmIGZvciB5b3VyIA0KY29udmVuaWVuY2U6IA0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9k cmFmdC1pZXRmLWVtdS1lYXB0bHNjZXJ0LnR4dCZ1cmwyPWh0dHBzOi8vZW11LXdnLmdpdGh1Yi5p by9lYXB0bHMtbG9uZ2NlcnQvZHJhZnQtaWV0Zi1lbXUtZWFwdGxzY2VydC50eHQuDQoNClRoZSBm b2xsb3dpbmcgdGV4dCB3YXMgYWRkZWQ6DQoNCj4gwqDCoCBUaGUgc2l6ZSBvZiBjZXJ0aWZpY2F0 ZXMgKGFuZCBjZXJ0aWZpY2F0ZSBjaGFpbnMpIG1heSBhbHNvIGluY3JlYXNlDQo+IMKgwqAgbWFu aWZvbGQgaW4gdGhlIGZ1dHVyZSB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgcXVhbnR1bS1zYWZl DQo+IMKgwqAgY3J5cHRvZ3JhcGh5LsKgIEZvciBleGFtcGxlLCBsYXR0aWNlLWJhc2VkIGNyeXB0 b2dyYXBoeSB3b3VsZCBoYXZlDQo+IMKgwqAgcHVibGljIGtleXMgb2YgYXBwcm94aW1hdGVseSAx MDAwIGJ5dGVzIGFuZCBzaWduYXR1cmVzIG9mDQo+IMKgwqAgYXBwcm94aW1hdGVseSAyMDAwIGJ5 dGVzLg0KYW5kIGluIFNlY3Rpb24gNC4yLjUNCg0KPiDCoMKgIFRoZSBBdXRob3JpdHkgSW5mb3Jt YXRpb24gQWNjZXNzIChBSUEpIGV4dGVuc2lvbiBzcGVjaWZpZWQgaW4NCj4gwqDCoCBbUkZDNTI4 MF0gY2FuIGJlIHVzZWQgd2l0aCBlbmQtZW50aXR5IGFuZCBDQSBjZXJ0aWZpY2F0ZXMgdG8gYWNj ZXNzDQo+IMKgwqAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGlzc3VlciBvZiB0aGUgY2VydGlmaWNh dGUgaW4gd2hpY2ggdGhlDQo+IMKgwqAgZXh0ZW5zaW9uIGFwcGVhcnMuwqAgRm9yIGV4YW1wbGUs IGl0IGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgdGhlDQo+IMKgwqAgYWRkcmVzcyBvZiB0aGUgT0NT UCByZXNwb25kZXIgZnJvbSB3aGVyZSByZXZvY2F0aW9uIHN0YXR1cyBvZiB0aGUNCj4gwqDCoCBj ZXJ0aWZpY2F0ZSAoaW4gd2hpY2ggdGhlIGV4dGVuc2lvbiBhcHBlYXJzKSBjYW4gYmUgY2hlY2tl ZC4gSXQgY2FuDQo+IMKgwqAgYWxzbyBiZSB1c2VkIHRvIG9idGFpbiB0aGUgaXNzdWVyIGNlcnRp ZmljYXRlLsKgIFRodXMsIHRoZSBBSUENCj4gwqDCoCBleHRlbnNpb24gY2FuIHJlZHVjZSB0aGUg c2l6ZSBvZiB0aGUgY2VydGlmaWNhdGUgY2hhaW4gYnkgb25seQ0KPiDCoMKgIGluY2x1ZGluZyBh IHBvaW50ZXIgdG8gdGhlIGlzc3VlciBjZXJ0aWZpY2F0ZSBpbnN0ZWFkIG9mIGluY2x1ZGluZw0K PiDCoMKgIHRoZSBlbnRpcmUgaXNzdWVyIGNlcnRpZmljYXRlLsKgIEhvd2V2ZXIsIGl0IHJlcXVp cmVzIHRoZSBzaWRlDQo+IMKgwqAgcmVjZWl2aW5nIHRoZSBjZXJ0aWZpY2F0ZSBjb250YWluaW5n IHRoZSBleHRlbnNpb24gdG8gaGF2ZSBuZXR3b3JrDQo+IMKgwqAgY29ubmVjdGl2aXR5LsKgIE5h dHVyYWxseSwgc3VjaCBpbmRpcmVjdGlvbiBjYW5ub3QgYmUgdXNlZCBmb3IgdGhlDQo+IMKgwqAg c2VydmVyIGNlcnRpZmljYXRlIChzaW5jZSB0aGUgRUFQIHBlZXIgaW4gbW9zdCBkZXBsb3ltZW50 cyBkb2VzIG5vdA0KPiDCoMKgIGhhdmUgbmV0d29yayBjb25uZWN0aXZpdHkgYmVmb3JlIGF1dGhl bg0KDQpMZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4gSSBhbSBub3QgYW4gZXhwZXJ0IG9uIHF1 YW50dW0gY3J5cHRvZ3JhcGh5IA0Kb3Igb24gdGhlIEFJQSBleHRlbnNpb24uIEkgd2lsbCB3YWl0 IGZvciBhbGwgdGhlIGNvbW1lbnRzIHRvIGNvbWUgaW4gDQpiZWZvcmUgc3VibWl0dGluZyBhIG5l dyB2ZXJzaW9uLg0KDQotLU1vaGl0DQoNCk9uIDEwLzMwLzIwIDU6MDQgQU0sIEJlbmphbWluIEth ZHVrIHdyb3RlOg0KPiBIaSBTdGVmYW4sDQo+DQo+IFRoYW5rcyBmb3IgdGhlIHJldmlldzsgaXQg cmFpc2VzIHNvbWUgZ29vZCB0b3BpY3MuDQo+IFJlcGx5aW5nIG9uIGEgY291cGxlIHBvaW50cy4u Lg0KPg0KPiBPbiBUaHUsIE9jdCAyOSwgMjAyMCBhdCAwNDoxMzowMlBNIC0wNzAwLCBTdGVmYW4g U2FudGVzc29uIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCj4+IFJldmlld2VyOiBTdGVmYW4gU2Fu dGVzc29uDQo+PiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPj4NCj4+IFRoZSBkb2N1bWVudCBp biBnZW5lcmFsIGlzIGdvb2QgYW5kIHdlbGwgd3JpdHRlbi4NCj4+DQo+PiBTb21lIG5pdHMgbmVl ZHMgYXR0ZW50aW9uIGJlZm9yZSBwdWJsaWNhdGlvbiBhcyB0aGUgZ2VuZXJhbCByZXZpZXcgYWxz byBwb2ludHMNCj4+IG91dC4gRXggaW4gdGhlIGFic3RyYWN0ICJUaGlzIGRvY3VtZW50IGxvb2tz IGF0IHRoZSB0aGlzIHByb2JsZW0iDQo+Pg0KPj4gU29tZSBhYmJyZXZpYXRpb25zIG5lZWRzIHRv IGJlIHNwZWxsZWQgb3V0IGF0IGZpcnN0IHVzYWdlLCBzdWNoIGFzIE1UVSAoTWF4aW11bQ0KPj4g VHJhbnNtaXNzaW9uIFVuaXQpDQo+IE1UVSBtYXkgYWN0dWFsbHkgYmUgb2theTsgcGVyDQo+IGh0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dCBp dCBpcyBtYXJrZWQgYXMNCj4gIndlbGwta25vd24iIGFuZCBkb2VzIG5vdCBhbHdheXMgbmVlZCB0 byBiZSBleHBhbmRlZC4NCj4NCj4+IE9uIHRoZSBjb250ZW50IGl0c2VsZiBJIGhhdmUgdHdvIHF1 ZXN0aW9uczoNCj4+DQo+PiAtIFdvdWxkbid0IGl0IGJlIHJlbGV2YW50IHRvIGFsc28gZGlzY3Vz cyB0aGUgcmlza3Mgd2l0aCByZWdhcmQgdG8gaW50cm9kdWN0aW9uDQo+PiBvZiBxdWFudHVtIHNh ZmUgY3J5cHRvLCBpZiB0aGF0IGxlYWRzIHRvIHNpZ25pZmljYW50bHkgaW5jcmVhc2VkIGtleSBz aXplcz8gSXQNCj4+IGNvdWxkIGJlIHRyb3VibGVzb21lIGlmIHRyYW5zaXRpb24gdG8gYSBzYWZl ciBjcnlwdG8gaXMgbWFkZSBpbXBvc3NpYmxlIGR1ZSB0bw0KPj4gc2l6ZSBsaW1pdGF0aW9ucy4g LSBXb3VsZCBpdCBiZSByZWxldmFudCB0byBkaXNjdXNzIHVzYWdlIG9mIEFJQSBleHRlbnNpb24g YXMNCj4+IG1lYW5zIG9mIHBvc3NpYmx5IGV4Y2x1ZGluZyBpbnRlcm1lZGlhcnkgY2VydHMgZnJv bSB0aGUgcGF0aCBhcyB0aGV5IGNvdWxkIGJlDQo+PiBsb2NhdGVkIHVzaW5nIEFJQT8NCj4+DQo+ PiBGaW5hbGx5LCBJIGFncmVlIHdpdGggdGhlIGdlbmVyYWwgcmV2aWV3IHRoYXQgdGhpcyBkb2N1 bWVudCByZWZlcmVuY2UgcXVpdGUNCj4+IHNvbWUgd29yayBpbiBwcm9ncmVzcy4gSWYgdGhpcyBk b2N1bWVudCBpcyB0byBiZSBwdWJsaXNoZWQgYmVmb3JlIHRoZXNlDQo+PiByZWZlcmVuY2VkIHdv cmtzIGFyZSBjb25jbHVkZWQsIGFyZSB0aGVyZSBhbHRlcm5hdGl2ZXMgdG8gbWFrZSB0aGUgc2Ft ZSBwb2ludD8NCj4gVGhleSBzZWVtIHRvIG1vc3RseSBiZSBpbmZvcm1hdGl2ZSByZWZlcmVuY2Vz LCBhbmQgc28gd291bGQgbm90IHJlcXVpcmUgdXMNCj4gdG8gaG9sZCBwdWJsaWNhdGlvbiBvZiB0 aGlzIGRvY3VtZW50LiAgSXQgaXMgcHJvYmFibHkgc3RpbGwgd29ydGgNCj4gY29uc2lkZXJpbmcg aWYgdGhlcmUgYXJlIGFsdGVybmF0aXZlcyBhbnl3YXksIHRob3VnaC4NCj4NCj4gLUJlbg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFbXUg bWFpbGluZyBsaXN0DQo+IEVtdUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2VtdQ0K From nobody Fri Oct 30 07:40:41 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328703A0BE3 for ; Fri, 30 Oct 2020 07:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 eOzc0IGpSpHB for ; Fri, 30 Oct 2020 07:40:35 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 5B2BC3A0EF1 for ; Fri, 30 Oct 2020 07:40:34 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id C7CDE10D0395 for ; Fri, 30 Oct 2020 15:40:29 +0100 (CET) Received: from s499.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id A78AC2EB3BC6; Fri, 30 Oct 2020 15:40:29 +0100 (CET) Received: from s475.loopia.se (unknown [172.22.191.5]) by s499.loopia.se (Postfix) with ESMTP id A1ACD1CE5F2A; Fri, 30 Oct 2020 15:40:29 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s498.loopia.se ([172.22.191.6]) by s475.loopia.se (s475.loopia.se [172.22.190.15]) (amavisd-new, port 10024) with LMTP id wTSvIyf-K5hE; Fri, 30 Oct 2020 15:40:28 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.50] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s498.loopia.se (Postfix) with ESMTPSA id 577B94893BB; Fri, 30 Oct 2020 15:40:28 +0100 (CET) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Fri, 30 Oct 2020 15:40:26 +0100 From: Stefan Santesson To: Mohit Sethi M , Benjamin Kaduk CC: "last-call@ietf.org" , "draft-ietf-emu-eaptlscert.all@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Message-ID: <2F8F716A-C063-4DF4-8384-BBD59C636C8A@aaa-sec.com> Thread-Topic: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 References: <160401318284.11167.6795105917637378641@ietfa.amsl.com> <20201030030415.GE39170@kduck.mit.edu> <12167567-9dc5-6161-abef-826b0a8b6602@ericsson.com> In-Reply-To: <12167567-9dc5-6161-abef-826b0a8b6602@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 14:40:39 -0000 Hi, I think the text is great.=20 However I'm not entirely convinced that AIA requires network connectivity a= t all times. The AIA CA cert url is static and works fine as identifier for a locally ca= ched cert The fact that it is the correct cert is assured by the path validation proc= ess. As such, the AIA works fine with a http cache implementation or similar or = any other solution using locally stored data. If used in a local corporate context, a cache mechanism could be provided w= ith pre-loaded relevant certs. But I don=E2=80=99t know how this may or may not interoperate with deployed base = of EAP implementations. Stefan Santesson=20 =EF=BB=BFOn 2020-10-30, 14:48, "Mohit Sethi M" wrote= : Hi Stefan, Thank you for the review. I have updated the draft in github=20 (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your=20 convenience:=20 https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet= f-emu-eaptlscert.txt&url2=3Dhttps://emu-wg.github.io/eaptls-longcert/draft-iet= f-emu-eaptlscert.txt. The following text was added: > The size of certificates (and certificate chains) may also increas= e > manifold in the future with the introduction of quantum-safe > cryptography. For example, lattice-based cryptography would have > public keys of approximately 1000 bytes and signatures of > approximately 2000 bytes. and in Section 4.2.5 > The Authority Information Access (AIA) extension specified in > [RFC5280] can be used with end-entity and CA certificates to acces= s > information about the issuer of the certificate in which the > extension appears. For example, it can be used to provide the > address of the OCSP responder from where revocation status of the > certificate (in which the extension appears) can be checked. It ca= n > also be used to obtain the issuer certificate. Thus, the AIA > extension can reduce the size of the certificate chain by only > including a pointer to the issuer certificate instead of including > the entire issuer certificate. However, it requires the side > receiving the certificate containing the extension to have network > connectivity. Naturally, such indirection cannot be used for the > server certificate (since the EAP peer in most deployments does no= t > have network connectivity before authen Let me know what you think. I am not an expert on quantum cryptography=20 or on the AIA extension. I will wait for all the comments to come in=20 before submitting a new version. --Mohit On 10/30/20 5:04 AM, Benjamin Kaduk wrote: > Hi Stefan, > > Thanks for the review; it raises some good topics. > Replying on a couple points... > > On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Datatr= acker wrote: >> Reviewer: Stefan Santesson >> Review result: Has Nits >> >> The document in general is good and well written. >> >> Some nits needs attention before publication as the general review a= lso points >> out. Ex in the abstract "This document looks at the this problem" >> >> Some abbreviations needs to be spelled out at first usage, such as M= TU (Maximum >> Transmission Unit) > MTU may actually be okay; per > https://www.rfc-editor.org/materials/abbrev.expansion.txt it is marke= d as > "well-known" and does not always need to be expanded. > >> On the content itself I have two questions: >> >> - Wouldn't it be relevant to also discuss the risks with regard to i= ntroduction >> of quantum safe crypto, if that leads to significantly increased key= sizes? It >> could be troublesome if transition to a safer crypto is made impossi= ble due to >> size limitations. - Would it be relevant to discuss usage of AIA ext= ension as >> means of possibly excluding intermediary certs from the path as they= could be >> located using AIA? >> >> Finally, I agree with the general review that this document referenc= e quite >> some work in progress. If this document is to be published before th= ese >> referenced works are concluded, are there alternatives to make the s= ame point? > They seem to mostly be informative references, and so would not requi= re us > to hold publication of this document. It is probably still worth > considering if there are alternatives anyway, though. > > -Ben > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From nobody Sat Oct 31 07:19:49 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ACE3A0BFD; Sat, 31 Oct 2020 07:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 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, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-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=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 gMb3iBOzErTa; Sat, 31 Oct 2020 07:19:41 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50055.outbound.protection.outlook.com [40.107.5.55]) (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 498343A0BFC; Sat, 31 Oct 2020 07:19:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VJQZz8Q8+4epPSsNnqqNqNVcvzCtg5XGq/FUdr3VSO9meVkHaPDAPcbiOd4ydlJxFl88Tm++46WyxK3wK5z7XDbWLOl5UObrQgfTJyc4SIF6kEW6H/j+wEmeRsbDtUFPFZuEYCLMyHVxaqTNWuj0JPCj2OchrOBdlGyjaX/l3uteKV4WLxhDJyfCXDMClAtFfX+fkPFE4Atn97klep3JFUU2QX0Bouw3R2H+Ydo2NzY5ofaLxhceB9flcwll6iuv/ebchBH0a6ZkKNzb4UkX55F0ZY6gScxyCoyplfkkXqx5JMUoYZk5vfcov1sb/J5q+npthD1uF+5LNlIxsC7rHg== 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=UCKnCqCgjfFTa5jAncrMZipS35URQooARU4I9xpbPRw=; b=BzRexDqZYao3pfjFGPity7ACTQ6Cee/HfjiBOhfzO0O0WowjM7+PQp7XlP5enLR8WueQU3XtFwrcCnJZPMnv4OdV+l+Bykd//UvskRT1mrPfGN/a0CvcGdS3TB3s3sm+2KCRnOpEZq96QbD0BQTDUoBEqfTtkID0zc3uNjVtJ95REpqOoRCFcedgbigrke1I3mw3nArfPk+BOc1iSzN4xajZ3PBlTjnfdUcwqZTGhBCbugOIq87NLGsZgjrUbjPfso8Z1i6gQvZfr65YqbP3NS/WK+hav0oHDzIWStF7FgIo1FRiRr1GAVsGqRTYmMTywYDODxrj0VivOZ/2LNfw1g== 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=UCKnCqCgjfFTa5jAncrMZipS35URQooARU4I9xpbPRw=; b=aZQ++vkigc/ugxucwIoG3GIut2xsKXDDBgEix+kfpyqdH5r6A3C2Y8qEFDWz7hIK2Gh0uY3ZirDH1It2lLYnMZD1WCiEem9xJRk9Y6cQaFr2wtPu7l9ORmycGNthc6GA83Gog/kvxP3MxoyA/xkURODHKWJpKlxiMpQsFGlUFC8= Received: from HE1PR07MB3209.eurprd07.prod.outlook.com (2603:10a6:7:32::14) by HE1PR0702MB3547.eurprd07.prod.outlook.com (2603:10a6:7:85::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.17; Sat, 31 Oct 2020 14:19:31 +0000 Received: from HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca]) by HE1PR07MB3209.eurprd07.prod.outlook.com ([fe80::1550:2d88:a5be:95ca%6]) with mapi id 15.20.3499.028; Sat, 31 Oct 2020 14:19:31 +0000 From: Mohit Sethi M To: Stefan Santesson , Mohit Sethi M , Benjamin Kaduk CC: "last-call@ietf.org" , "draft-ietf-emu-eaptlscert.all@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Thread-Topic: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 Thread-Index: AQHWrkkTSwTr5auJQke8Pqw//Tx6KKmvdiCAgAC0B4CAAA58AIABjHwA Date: Sat, 31 Oct 2020 14:19:31 +0000 Message-ID: <36dd411f-853c-f7fb-957a-c6eb90be130b@ericsson.com> References: <160401318284.11167.6795105917637378641@ietfa.amsl.com> <20201030030415.GE39170@kduck.mit.edu> <12167567-9dc5-6161-abef-826b0a8b6602@ericsson.com> <2F8F716A-C063-4DF4-8384-BBD59C636C8A@aaa-sec.com> In-Reply-To: <2F8F716A-C063-4DF4-8384-BBD59C636C8A@aaa-sec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: aaa-sec.com; dkim=none (message not signed) header.d=none;aaa-sec.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [37.136.189.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fcffd502-68e3-4f11-0ff7-08d87da7fc12 x-ms-traffictypediagnostic: HE1PR0702MB3547: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LUWzNfV0YvrXv0mSbRDHbej5L3XJwo/G8ub7V0+74G8v141W4v3LJAVIeMj3EsBXGmgPnv002bWn62qh5sKRe6gYd87an61LEXZGVkE2s5NxdTQlcVAcqMqGRUet5VwLwsOmEpp7yVw66kpEv784FWewjocKGDGhcR9MdpVjSa1j7aF21aKlofh6jdToev7mgfl/+IsE1eGIGQ20tv+qf8Dne6jp5am4zTDD/5HrQn/4DcTo6IVpnKx3MrUTdfWiKWuV4bOXpLrUiL0LJiJDM2a+tu3tlnX0snL5q+YedrMKUBDN89R+v2y9ebK1+mUp9AHXv/S6sZPpA8PYAW6X7JKsvDKYETmWow468zSDbv6wolYheUm1UThMjYPcHzPM0JO8OjurWFdscqoGbYbTAnBB8JPvw9+qTpjHHbe8EEl10SaJzfxuDhCJJl2uZyGuJhYuUaxtUuZWVyq0lliVbQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3209.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(366004)(136003)(39860400002)(2616005)(166002)(966005)(6506007)(53546011)(6486002)(316002)(186003)(86362001)(4326008)(83380400001)(4001150100001)(71200400001)(5660300002)(2906002)(66476007)(66446008)(64756008)(66556008)(54906003)(110136005)(478600001)(66946007)(6512007)(76116006)(8936002)(31696002)(31686004)(8676002)(26005)(36756003)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qA4tGYis09LVqOduykv0RCJQ+5f5x/ykGTiFNjSm7+WJdyDpPnZHN7hTtBMomUMuLzantGh5QxsfVuzFt+jX7ny3TMlwuY13GBzZoFifVvFtOKZsOl6N6MrpaxBotCCTd5HQjgL1MTkjGjrv50lu8L/bk8jkz7vE9ZZOOrtdBy1AXPrA274ZZyGotqzvXq55YRO3vhgXNK8VDd0u4i6gizNdvD09QuThfXA0/r7uOYtEykOxYzUm5uSIpzJ33X6oQwnuQKqW0T7VRhi7u4xhrvj1O1i02sNfwa6taJBeXnWZtcBOP14W5TFmzIYIqYgc9pdcnGDUedZSAy0hJ5muRGQ9P8LITqsUJesuopCIEwtAAyhbjEQS6XBlPPOeYBCwDkH9ubcXFCR2+E+BrSCkqmEWC5F0X27DELFH6r9+4reh3WvRB6Vlm3oc50Awvey2JsEfbCdNQRvDRRohoh7NMKF5mjrFhqFHbnj2EwXCbCZfvPEWapbfagGTAlFuyoU0HK0kwoyBp0Wk8WSXDzrzr0f+75u3lb7pNyUP+wR5M/EYBIyDca5M6AbiM5Xt5GblUWA22rXn7MSAl2wY6YoMOLyZvyFoTIiM0tXb5IJpbkrkrG+6duNRTcSZILgf25PmCK6RIWmytk1Onndq1VdQzg== Content-Type: multipart/alternative; boundary="_000_36dd411f853cf7fb957ac6eb90be130bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3209.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fcffd502-68e3-4f11-0ff7-08d87da7fc12 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2020 14:19:31.3548 (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: rG5O279KSJncMZU4Pci/JRW2QEoC8P8EFru6HNPnnIokz4aQHmbo4DPfxUhw5PuE1CRp0UMWKDSX8fH5MZd+eHzA3TJvhlcjGrP2Olviokk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3547 Archived-At: Subject: Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 14:19:44 -0000 --_000_36dd411f853cf7fb957ac6eb90be130bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlZmFuLA0KDQpJIG1hZGUgYSBtaW5vciB1cGRhdGUgdG8gcmVmbGVjdCB5b3VyIGZlZWRi YWNrIChodHRwczovL2dpdGh1Yi5jb20vZW11LXdnL2VhcHRscy1sb25nY2VydC9jb21wYXJlLzNh YzBhMTguLjIwOTMwMjYpOg0KDQpUaHVzLCB0aGUgQUlBIGV4dGVuc2lvbiBjYW4gcmVkdWNlIHRo ZSBzaXplIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiBieSBvbmx5IGluY2x1ZGluZyBhIHBvaW50 ZXIgdG8gdGhlIGlzc3VlciBjZXJ0aWZpY2F0ZSBpbnN0ZWFkIG9mIGluY2x1ZGluZyB0aGUgZW50 aXJlIGlzc3VlciBjZXJ0aWZpY2F0ZS4gSG93ZXZlciwgaXQgcmVxdWlyZXMgdGhlIHNpZGUgcmVj ZWl2aW5nIHRoZSBjZXJ0aWZpY2F0ZSBjb250YWluaW5nIHRoZSBleHRlbnNpb24gdG8gaGF2ZSBu ZXR3b3JrIGNvbm5lY3Rpdml0eSAodW5sZXNzIHRoZSBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGNh Y2hlZCBsb2NhbGx5KS4gTmF0dXJhbGx5LCBzdWNoIGluZGlyZWN0aW9uIGNhbm5vdCBiZSB1c2Vk IGZvciB0aGUgc2VydmVyIGNlcnRpZmljYXRlIChzaW5jZSBFQVAgcGVlcnMgaW4gbW9zdCBkZXBs b3ltZW50cyBkbyBub3QgaGF2ZSBuZXR3b3JrIGNvbm5lY3Rpdml0eSBiZWZvcmUgYXV0aGVudGlj YXRpb24gYW5kIHR5cGljYWxseSBkbyBub3QgbWFpbnRhaW4gYW4gdXAtdG8tZGF0ZSBsb2NhbCBj YWNoZSBvZiBpc3N1ZXIgY2VydGlmaWNhdGVzKS4NCg0KSG9wZSB0aGlzIGlzIGNvcnJlY3QgKGFu ZCBzdWZmaWNpZW50KS4NCg0KLS1Nb2hpdA0KDQpPbiAxMC8zMC8yMCA0OjQwIFBNLCBTdGVmYW4g U2FudGVzc29uIHdyb3RlOg0KDQpIaSwNCg0KSSB0aGluayB0aGUgdGV4dCBpcyBncmVhdC4NCkhv d2V2ZXIgSSdtIG5vdCBlbnRpcmVseSBjb252aW5jZWQgdGhhdCBBSUEgcmVxdWlyZXMgbmV0d29y ayBjb25uZWN0aXZpdHkgYXQgYWxsIHRpbWVzLg0KVGhlIEFJQSBDQSBjZXJ0IHVybCBpcyBzdGF0 aWMgYW5kIHdvcmtzIGZpbmUgYXMgaWRlbnRpZmllciBmb3IgYSBsb2NhbGx5IGNhY2hlZCBjZXJ0 DQpUaGUgZmFjdCB0aGF0IGl0IGlzIHRoZSBjb3JyZWN0IGNlcnQgaXMgYXNzdXJlZCBieSB0aGUg cGF0aCB2YWxpZGF0aW9uIHByb2Nlc3MuDQpBcyBzdWNoLCB0aGUgQUlBIHdvcmtzIGZpbmUgd2l0 aCBhIGh0dHAgY2FjaGUgaW1wbGVtZW50YXRpb24gb3Igc2ltaWxhciBvciBhbnkgb3RoZXIgc29s dXRpb24gdXNpbmcgbG9jYWxseSBzdG9yZWQgZGF0YS4NCklmIHVzZWQgaW4gYSBsb2NhbCBjb3Jw b3JhdGUgY29udGV4dCwgYSBjYWNoZSBtZWNoYW5pc20gY291bGQgYmUgcHJvdmlkZWQgd2l0aCBw cmUtbG9hZGVkIHJlbGV2YW50IGNlcnRzLg0KDQpCdXQgSSBkb27igJl0IGtub3cgaG93IHRoaXMg bWF5IG9yIG1heSBub3QgaW50ZXJvcGVyYXRlIHdpdGggZGVwbG95ZWQgYmFzZSBvZiBFQVAgaW1w bGVtZW50YXRpb25zLg0KDQpTdGVmYW4gU2FudGVzc29uDQoNCu+7v09uIDIwMjAtMTAtMzAsIDE0 OjQ4LCAiTW9oaXQgU2V0aGkgTSIgPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPjxtYWlsdG86 bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgSGkgU3RlZmFuLA0KDQog ICAgVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBJIGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgaW4g Z2l0aHViDQogICAgKGh0dHBzOi8vZ2l0aHViLmNvbS9lbXUtd2cvZWFwdGxzLWxvbmdjZXJ0KS4g SGVyZSBpcyB0aGUgZGlmZiBmb3IgeW91cg0KICAgIGNvbnZlbmllbmNlOg0KICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtaWV0Zi1lbXUtZWFwdGxzY2VydC50eHQmdXJsMj1odHRwczovL2VtdS13Zy5naXRodWIuaW8v ZWFwdGxzLWxvbmdjZXJ0L2RyYWZ0LWlldGYtZW11LWVhcHRsc2NlcnQudHh0Lg0KDQogICAgVGhl IGZvbGxvd2luZyB0ZXh0IHdhcyBhZGRlZDoNCg0KICAgID4gICAgVGhlIHNpemUgb2YgY2VydGlm aWNhdGVzIChhbmQgY2VydGlmaWNhdGUgY2hhaW5zKSBtYXkgYWxzbyBpbmNyZWFzZQ0KICAgID4g ICAgbWFuaWZvbGQgaW4gdGhlIGZ1dHVyZSB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgcXVhbnR1 bS1zYWZlDQogICAgPiAgICBjcnlwdG9ncmFwaHkuICBGb3IgZXhhbXBsZSwgbGF0dGljZS1iYXNl ZCBjcnlwdG9ncmFwaHkgd291bGQgaGF2ZQ0KICAgID4gICAgcHVibGljIGtleXMgb2YgYXBwcm94 aW1hdGVseSAxMDAwIGJ5dGVzIGFuZCBzaWduYXR1cmVzIG9mDQogICAgPiAgICBhcHByb3hpbWF0 ZWx5IDIwMDAgYnl0ZXMuDQogICAgYW5kIGluIFNlY3Rpb24gNC4yLjUNCg0KICAgID4gICAgVGhl IEF1dGhvcml0eSBJbmZvcm1hdGlvbiBBY2Nlc3MgKEFJQSkgZXh0ZW5zaW9uIHNwZWNpZmllZCBp bg0KICAgID4gICAgW1JGQzUyODBdIGNhbiBiZSB1c2VkIHdpdGggZW5kLWVudGl0eSBhbmQgQ0Eg Y2VydGlmaWNhdGVzIHRvIGFjY2Vzcw0KICAgID4gICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIGlz c3VlciBvZiB0aGUgY2VydGlmaWNhdGUgaW4gd2hpY2ggdGhlDQogICAgPiAgICBleHRlbnNpb24g YXBwZWFycy4gIEZvciBleGFtcGxlLCBpdCBjYW4gYmUgdXNlZCB0byBwcm92aWRlIHRoZQ0KICAg ID4gICAgYWRkcmVzcyBvZiB0aGUgT0NTUCByZXNwb25kZXIgZnJvbSB3aGVyZSByZXZvY2F0aW9u IHN0YXR1cyBvZiB0aGUNCiAgICA+ICAgIGNlcnRpZmljYXRlIChpbiB3aGljaCB0aGUgZXh0ZW5z aW9uIGFwcGVhcnMpIGNhbiBiZSBjaGVja2VkLiBJdCBjYW4NCiAgICA+ICAgIGFsc28gYmUgdXNl ZCB0byBvYnRhaW4gdGhlIGlzc3VlciBjZXJ0aWZpY2F0ZS4gIFRodXMsIHRoZSBBSUENCiAgICA+ ICAgIGV4dGVuc2lvbiBjYW4gcmVkdWNlIHRoZSBzaXplIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFp biBieSBvbmx5DQogICAgPiAgICBpbmNsdWRpbmcgYSBwb2ludGVyIHRvIHRoZSBpc3N1ZXIgY2Vy dGlmaWNhdGUgaW5zdGVhZCBvZiBpbmNsdWRpbmcNCiAgICA+ICAgIHRoZSBlbnRpcmUgaXNzdWVy IGNlcnRpZmljYXRlLiAgSG93ZXZlciwgaXQgcmVxdWlyZXMgdGhlIHNpZGUNCiAgICA+ICAgIHJl Y2VpdmluZyB0aGUgY2VydGlmaWNhdGUgY29udGFpbmluZyB0aGUgZXh0ZW5zaW9uIHRvIGhhdmUg bmV0d29yaw0KICAgID4gICAgY29ubmVjdGl2aXR5LiAgTmF0dXJhbGx5LCBzdWNoIGluZGlyZWN0 aW9uIGNhbm5vdCBiZSB1c2VkIGZvciB0aGUNCiAgICA+ICAgIHNlcnZlciBjZXJ0aWZpY2F0ZSAo c2luY2UgdGhlIEVBUCBwZWVyIGluIG1vc3QgZGVwbG95bWVudHMgZG9lcyBub3QNCiAgICA+ICAg IGhhdmUgbmV0d29yayBjb25uZWN0aXZpdHkgYmVmb3JlIGF1dGhlbg0KDQogICAgTGV0IG1lIGtu b3cgd2hhdCB5b3UgdGhpbmsuIEkgYW0gbm90IGFuIGV4cGVydCBvbiBxdWFudHVtIGNyeXB0b2dy YXBoeQ0KICAgIG9yIG9uIHRoZSBBSUEgZXh0ZW5zaW9uLiBJIHdpbGwgd2FpdCBmb3IgYWxsIHRo ZSBjb21tZW50cyB0byBjb21lIGluDQogICAgYmVmb3JlIHN1Ym1pdHRpbmcgYSBuZXcgdmVyc2lv bi4NCg0KICAgIC0tTW9oaXQNCg0KICAgIE9uIDEwLzMwLzIwIDU6MDQgQU0sIEJlbmphbWluIEth ZHVrIHdyb3RlOg0KICAgID4gSGkgU3RlZmFuLA0KICAgID4NCiAgICA+IFRoYW5rcyBmb3IgdGhl IHJldmlldzsgaXQgcmFpc2VzIHNvbWUgZ29vZCB0b3BpY3MuDQogICAgPiBSZXBseWluZyBvbiBh IGNvdXBsZSBwb2ludHMuLi4NCiAgICA+DQogICAgPiBPbiBUaHUsIE9jdCAyOSwgMjAyMCBhdCAw NDoxMzowMlBNIC0wNzAwLCBTdGVmYW4gU2FudGVzc29uIHZpYSBEYXRhdHJhY2tlciB3cm90ZToN CiAgICA+PiBSZXZpZXdlcjogU3RlZmFuIFNhbnRlc3Nvbg0KICAgID4+IFJldmlldyByZXN1bHQ6 IEhhcyBOaXRzDQogICAgPj4NCiAgICA+PiBUaGUgZG9jdW1lbnQgaW4gZ2VuZXJhbCBpcyBnb29k IGFuZCB3ZWxsIHdyaXR0ZW4uDQogICAgPj4NCiAgICA+PiBTb21lIG5pdHMgbmVlZHMgYXR0ZW50 aW9uIGJlZm9yZSBwdWJsaWNhdGlvbiBhcyB0aGUgZ2VuZXJhbCByZXZpZXcgYWxzbyBwb2ludHMN CiAgICA+PiBvdXQuIEV4IGluIHRoZSBhYnN0cmFjdCAiVGhpcyBkb2N1bWVudCBsb29rcyBhdCB0 aGUgdGhpcyBwcm9ibGVtIg0KICAgID4+DQogICAgPj4gU29tZSBhYmJyZXZpYXRpb25zIG5lZWRz IHRvIGJlIHNwZWxsZWQgb3V0IGF0IGZpcnN0IHVzYWdlLCBzdWNoIGFzIE1UVSAoTWF4aW11bQ0K ICAgID4+IFRyYW5zbWlzc2lvbiBVbml0KQ0KICAgID4gTVRVIG1heSBhY3R1YWxseSBiZSBva2F5 OyBwZXINCiAgICA+IGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYu ZXhwYW5zaW9uLnR4dCBpdCBpcyBtYXJrZWQgYXMNCiAgICA+ICJ3ZWxsLWtub3duIiBhbmQgZG9l cyBub3QgYWx3YXlzIG5lZWQgdG8gYmUgZXhwYW5kZWQuDQogICAgPg0KICAgID4+IE9uIHRoZSBj b250ZW50IGl0c2VsZiBJIGhhdmUgdHdvIHF1ZXN0aW9uczoNCiAgICA+Pg0KICAgID4+IC0gV291 bGRuJ3QgaXQgYmUgcmVsZXZhbnQgdG8gYWxzbyBkaXNjdXNzIHRoZSByaXNrcyB3aXRoIHJlZ2Fy ZCB0byBpbnRyb2R1Y3Rpb24NCiAgICA+PiBvZiBxdWFudHVtIHNhZmUgY3J5cHRvLCBpZiB0aGF0 IGxlYWRzIHRvIHNpZ25pZmljYW50bHkgaW5jcmVhc2VkIGtleSBzaXplcz8gSXQNCiAgICA+PiBj b3VsZCBiZSB0cm91Ymxlc29tZSBpZiB0cmFuc2l0aW9uIHRvIGEgc2FmZXIgY3J5cHRvIGlzIG1h ZGUgaW1wb3NzaWJsZSBkdWUgdG8NCiAgICA+PiBzaXplIGxpbWl0YXRpb25zLiAtIFdvdWxkIGl0 IGJlIHJlbGV2YW50IHRvIGRpc2N1c3MgdXNhZ2Ugb2YgQUlBIGV4dGVuc2lvbiBhcw0KICAgID4+ IG1lYW5zIG9mIHBvc3NpYmx5IGV4Y2x1ZGluZyBpbnRlcm1lZGlhcnkgY2VydHMgZnJvbSB0aGUg cGF0aCBhcyB0aGV5IGNvdWxkIGJlDQogICAgPj4gbG9jYXRlZCB1c2luZyBBSUE/DQogICAgPj4N CiAgICA+PiBGaW5hbGx5LCBJIGFncmVlIHdpdGggdGhlIGdlbmVyYWwgcmV2aWV3IHRoYXQgdGhp cyBkb2N1bWVudCByZWZlcmVuY2UgcXVpdGUNCiAgICA+PiBzb21lIHdvcmsgaW4gcHJvZ3Jlc3Mu IElmIHRoaXMgZG9jdW1lbnQgaXMgdG8gYmUgcHVibGlzaGVkIGJlZm9yZSB0aGVzZQ0KICAgID4+ IHJlZmVyZW5jZWQgd29ya3MgYXJlIGNvbmNsdWRlZCwgYXJlIHRoZXJlIGFsdGVybmF0aXZlcyB0 byBtYWtlIHRoZSBzYW1lIHBvaW50Pw0KICAgID4gVGhleSBzZWVtIHRvIG1vc3RseSBiZSBpbmZv cm1hdGl2ZSByZWZlcmVuY2VzLCBhbmQgc28gd291bGQgbm90IHJlcXVpcmUgdXMNCiAgICA+IHRv IGhvbGQgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIEl0IGlzIHByb2JhYmx5IHN0aWxs IHdvcnRoDQogICAgPiBjb25zaWRlcmluZyBpZiB0aGVyZSBhcmUgYWx0ZXJuYXRpdmVzIGFueXdh eSwgdGhvdWdoLg0KICAgID4NCiAgICA+IC1CZW4NCiAgICA+DQogICAgPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gRW11IG1haWxpbmcgbGlz dA0KICAgID4gRW11QGlldGYub3JnPG1haWx0bzpFbXVAaWV0Zi5vcmc+DQogICAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VtdQ0KDQoNCg0K --_000_36dd411f853cf7fb957ac6eb90be130bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgU3RlZmFu LDwvcD4NCjxwPkkgbWFkZSBhIG1pbm9yIHVwZGF0ZSB0byByZWZsZWN0IHlvdXIgZmVlZGJhY2sg KDxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2VtdS13 Zy9lYXB0bHMtbG9uZ2NlcnQvY29tcGFyZS8zYWMwYTE4Li4yMDkzMDI2Ij5odHRwczovL2dpdGh1 Yi5jb20vZW11LXdnL2VhcHRscy1sb25nY2VydC9jb21wYXJlLzNhYzBhMTguLjIwOTMwMjY8L2E+ KTo8L3A+DQo8cD48L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3BhbiBjbGFzcz0iYmxv Yi1jb2RlLWlubmVyDQogICAgICAgICAgYmxvYi1jb2RlLW1hcmtlciIgZGF0YS1jb2RlLW1hcmtl cj0iKyI+VGh1cywgdGhlIEFJQSBleHRlbnNpb24gY2FuIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUg Y2VydGlmaWNhdGUgY2hhaW4gYnkgb25seSBpbmNsdWRpbmcgYSBwb2ludGVyIHRvIHRoZSBpc3N1 ZXIgY2VydGlmaWNhdGUgaW5zdGVhZCBvZiBpbmNsdWRpbmcgdGhlIGVudGlyZQ0KIGlzc3VlciBj ZXJ0aWZpY2F0ZS4gSG93ZXZlciwgaXQgcmVxdWlyZXMgdGhlIHNpZGUgcmVjZWl2aW5nIHRoZSBj ZXJ0aWZpY2F0ZSBjb250YWluaW5nIHRoZSBleHRlbnNpb24gdG8gaGF2ZSBuZXR3b3JrIGNvbm5l Y3Rpdml0eSAodW5sZXNzIHRoZSBpbmZvcm1hdGlvbiBpcyBhbHJlYWR5IGNhY2hlZCBsb2NhbGx5 KS4gTmF0dXJhbGx5LCBzdWNoIGluZGlyZWN0aW9uIGNhbm5vdCBiZSB1c2VkIGZvciB0aGUgc2Vy dmVyIGNlcnRpZmljYXRlIChzaW5jZQ0KIEVBUCBwZWVycyBpbiBtb3N0IGRlcGxveW1lbnRzIGRv IG5vdCBoYXZlIG5ldHdvcmsgY29ubmVjdGl2aXR5IGJlZm9yZSBhdXRoZW50aWNhdGlvbiBhbmQg dHlwaWNhbGx5IGRvIG5vdCBtYWludGFpbiBhbiB1cC10by1kYXRlIGxvY2FsIGNhY2hlIG9mIGlz c3VlciBjZXJ0aWZpY2F0ZXMpLjwvc3Bhbj48L2Jsb2NrcXVvdGU+DQo8cD48L3A+DQo8cD5Ib3Bl IHRoaXMgaXMgY29ycmVjdCAoYW5kIHN1ZmZpY2llbnQpLiA8YnI+DQo8L3A+DQo8cD4tLU1vaGl0 PC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMC8zMC8yMCA0OjQwIFBNLCBT dGVmYW4gU2FudGVzc29uIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2l0ZT0ibWlkOjJGOEY3MTZBLUMwNjMtNERGNC04Mzg0LUJCRDU5QzYzNkM4QUBhYWEtc2Vj LmNvbSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPkhpLA0KDQpJIHRoaW5r IHRoZSB0ZXh0IGlzIGdyZWF0LiANCkhvd2V2ZXIgSSdtIG5vdCBlbnRpcmVseSBjb252aW5jZWQg dGhhdCBBSUEgcmVxdWlyZXMgbmV0d29yayBjb25uZWN0aXZpdHkgYXQgYWxsIHRpbWVzLg0KVGhl IEFJQSBDQSBjZXJ0IHVybCBpcyBzdGF0aWMgYW5kIHdvcmtzIGZpbmUgYXMgaWRlbnRpZmllciBm b3IgYSBsb2NhbGx5IGNhY2hlZCBjZXJ0DQpUaGUgZmFjdCB0aGF0IGl0IGlzIHRoZSBjb3JyZWN0 IGNlcnQgaXMgYXNzdXJlZCBieSB0aGUgcGF0aCB2YWxpZGF0aW9uIHByb2Nlc3MuDQpBcyBzdWNo LCB0aGUgQUlBIHdvcmtzIGZpbmUgd2l0aCBhIGh0dHAgY2FjaGUgaW1wbGVtZW50YXRpb24gb3Ig c2ltaWxhciBvciBhbnkgb3RoZXIgc29sdXRpb24gdXNpbmcgbG9jYWxseSBzdG9yZWQgZGF0YS4N CklmIHVzZWQgaW4gYSBsb2NhbCBjb3Jwb3JhdGUgY29udGV4dCwgYSBjYWNoZSBtZWNoYW5pc20g Y291bGQgYmUgcHJvdmlkZWQgd2l0aCBwcmUtbG9hZGVkIHJlbGV2YW50IGNlcnRzLg0KDQpCdXQg SSBkb27igJl0IGtub3cgaG93IHRoaXMgbWF5IG9yIG1heSBub3QgaW50ZXJvcGVyYXRlIHdpdGgg ZGVwbG95ZWQgYmFzZSBvZiBFQVAgaW1wbGVtZW50YXRpb25zLg0KDQpTdGVmYW4gU2FudGVzc29u IA0KDQrvu79PbiAyMDIwLTEwLTMwLCAxNDo0OCwgJnF1b3Q7TW9oaXQgU2V0aGkgTSZxdW90OyA8 YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRo aUBlcmljc3Nvbi5jb20iPiZsdDttb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSZndDs8L2E+IHdy b3RlOg0KDQogICAgSGkgU3RlZmFuLA0KDQogICAgVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiBJ IGhhdmUgdXBkYXRlZCB0aGUgZHJhZnQgaW4gZ2l0aHViIA0KICAgICg8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vZW11LXdnL2VhcHRscy1s b25nY2VydCI+aHR0cHM6Ly9naXRodWIuY29tL2VtdS13Zy9lYXB0bHMtbG9uZ2NlcnQ8L2E+KS4g SGVyZSBpcyB0aGUgZGlmZiBmb3IgeW91ciANCiAgICBjb252ZW5pZW5jZTogDQogICAgPGEgY2xh c3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDE9aHR0cHM6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWVtdS1lYXB0 bHNjZXJ0LnR4dCZhbXA7dXJsMj1odHRwczovL2VtdS13Zy5naXRodWIuaW8vZWFwdGxzLWxvbmdj ZXJ0L2RyYWZ0LWlldGYtZW11LWVhcHRsc2NlcnQudHh0Ij5odHRwczovL3Rvb2xzLmlldGYub3Jn L3JmY2RpZmY/dXJsMT1odHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LWlldGYtZW11LWVh cHRsc2NlcnQudHh0JmFtcDt1cmwyPWh0dHBzOi8vZW11LXdnLmdpdGh1Yi5pby9lYXB0bHMtbG9u Z2NlcnQvZHJhZnQtaWV0Zi1lbXUtZWFwdGxzY2VydC50eHQ8L2E+Lg0KDQogICAgVGhlIGZvbGxv d2luZyB0ZXh0IHdhcyBhZGRlZDoNCg0KICAgICZndDsgICAgVGhlIHNpemUgb2YgY2VydGlmaWNh dGVzIChhbmQgY2VydGlmaWNhdGUgY2hhaW5zKSBtYXkgYWxzbyBpbmNyZWFzZQ0KICAgICZndDsg ICAgbWFuaWZvbGQgaW4gdGhlIGZ1dHVyZSB3aXRoIHRoZSBpbnRyb2R1Y3Rpb24gb2YgcXVhbnR1 bS1zYWZlDQogICAgJmd0OyAgICBjcnlwdG9ncmFwaHkuICBGb3IgZXhhbXBsZSwgbGF0dGljZS1i YXNlZCBjcnlwdG9ncmFwaHkgd291bGQgaGF2ZQ0KICAgICZndDsgICAgcHVibGljIGtleXMgb2Yg YXBwcm94aW1hdGVseSAxMDAwIGJ5dGVzIGFuZCBzaWduYXR1cmVzIG9mDQogICAgJmd0OyAgICBh cHByb3hpbWF0ZWx5IDIwMDAgYnl0ZXMuDQogICAgYW5kIGluIFNlY3Rpb24gNC4yLjUNCg0KICAg ICZndDsgICAgVGhlIEF1dGhvcml0eSBJbmZvcm1hdGlvbiBBY2Nlc3MgKEFJQSkgZXh0ZW5zaW9u IHNwZWNpZmllZCBpbg0KICAgICZndDsgICAgW1JGQzUyODBdIGNhbiBiZSB1c2VkIHdpdGggZW5k LWVudGl0eSBhbmQgQ0EgY2VydGlmaWNhdGVzIHRvIGFjY2Vzcw0KICAgICZndDsgICAgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIGlzc3VlciBvZiB0aGUgY2VydGlmaWNhdGUgaW4gd2hpY2ggdGhlDQog ICAgJmd0OyAgICBleHRlbnNpb24gYXBwZWFycy4gIEZvciBleGFtcGxlLCBpdCBjYW4gYmUgdXNl ZCB0byBwcm92aWRlIHRoZQ0KICAgICZndDsgICAgYWRkcmVzcyBvZiB0aGUgT0NTUCByZXNwb25k ZXIgZnJvbSB3aGVyZSByZXZvY2F0aW9uIHN0YXR1cyBvZiB0aGUNCiAgICAmZ3Q7ICAgIGNlcnRp ZmljYXRlIChpbiB3aGljaCB0aGUgZXh0ZW5zaW9uIGFwcGVhcnMpIGNhbiBiZSBjaGVja2VkLiBJ dCBjYW4NCiAgICAmZ3Q7ICAgIGFsc28gYmUgdXNlZCB0byBvYnRhaW4gdGhlIGlzc3VlciBjZXJ0 aWZpY2F0ZS4gIFRodXMsIHRoZSBBSUENCiAgICAmZ3Q7ICAgIGV4dGVuc2lvbiBjYW4gcmVkdWNl IHRoZSBzaXplIG9mIHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiBieSBvbmx5DQogICAgJmd0OyAgICBp bmNsdWRpbmcgYSBwb2ludGVyIHRvIHRoZSBpc3N1ZXIgY2VydGlmaWNhdGUgaW5zdGVhZCBvZiBp bmNsdWRpbmcNCiAgICAmZ3Q7ICAgIHRoZSBlbnRpcmUgaXNzdWVyIGNlcnRpZmljYXRlLiAgSG93 ZXZlciwgaXQgcmVxdWlyZXMgdGhlIHNpZGUNCiAgICAmZ3Q7ICAgIHJlY2VpdmluZyB0aGUgY2Vy dGlmaWNhdGUgY29udGFpbmluZyB0aGUgZXh0ZW5zaW9uIHRvIGhhdmUgbmV0d29yaw0KICAgICZn dDsgICAgY29ubmVjdGl2aXR5LiAgTmF0dXJhbGx5LCBzdWNoIGluZGlyZWN0aW9uIGNhbm5vdCBi ZSB1c2VkIGZvciB0aGUNCiAgICAmZ3Q7ICAgIHNlcnZlciBjZXJ0aWZpY2F0ZSAoc2luY2UgdGhl IEVBUCBwZWVyIGluIG1vc3QgZGVwbG95bWVudHMgZG9lcyBub3QNCiAgICAmZ3Q7ICAgIGhhdmUg bmV0d29yayBjb25uZWN0aXZpdHkgYmVmb3JlIGF1dGhlbg0KDQogICAgTGV0IG1lIGtub3cgd2hh dCB5b3UgdGhpbmsuIEkgYW0gbm90IGFuIGV4cGVydCBvbiBxdWFudHVtIGNyeXB0b2dyYXBoeSAN CiAgICBvciBvbiB0aGUgQUlBIGV4dGVuc2lvbi4gSSB3aWxsIHdhaXQgZm9yIGFsbCB0aGUgY29t bWVudHMgdG8gY29tZSBpbiANCiAgICBiZWZvcmUgc3VibWl0dGluZyBhIG5ldyB2ZXJzaW9uLg0K DQogICAgLS1Nb2hpdA0KDQogICAgT24gMTAvMzAvMjAgNTowNCBBTSwgQmVuamFtaW4gS2FkdWsg d3JvdGU6DQogICAgJmd0OyBIaSBTdGVmYW4sDQogICAgJmd0Ow0KICAgICZndDsgVGhhbmtzIGZv ciB0aGUgcmV2aWV3OyBpdCByYWlzZXMgc29tZSBnb29kIHRvcGljcy4NCiAgICAmZ3Q7IFJlcGx5 aW5nIG9uIGEgY291cGxlIHBvaW50cy4uLg0KICAgICZndDsNCiAgICAmZ3Q7IE9uIFRodSwgT2N0 IDI5LCAyMDIwIGF0IDA0OjEzOjAyUE0gLTA3MDAsIFN0ZWZhbiBTYW50ZXNzb24gdmlhIERhdGF0 cmFja2VyIHdyb3RlOg0KICAgICZndDsmZ3Q7IFJldmlld2VyOiBTdGVmYW4gU2FudGVzc29uDQog ICAgJmd0OyZndDsgUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCiAgICAmZ3Q7Jmd0Ow0KICAgICZn dDsmZ3Q7IFRoZSBkb2N1bWVudCBpbiBnZW5lcmFsIGlzIGdvb2QgYW5kIHdlbGwgd3JpdHRlbi4N CiAgICAmZ3Q7Jmd0Ow0KICAgICZndDsmZ3Q7IFNvbWUgbml0cyBuZWVkcyBhdHRlbnRpb24gYmVm b3JlIHB1YmxpY2F0aW9uIGFzIHRoZSBnZW5lcmFsIHJldmlldyBhbHNvIHBvaW50cw0KICAgICZn dDsmZ3Q7IG91dC4gRXggaW4gdGhlIGFic3RyYWN0ICZxdW90O1RoaXMgZG9jdW1lbnQgbG9va3Mg YXQgdGhlIHRoaXMgcHJvYmxlbSZxdW90Ow0KICAgICZndDsmZ3Q7DQogICAgJmd0OyZndDsgU29t ZSBhYmJyZXZpYXRpb25zIG5lZWRzIHRvIGJlIHNwZWxsZWQgb3V0IGF0IGZpcnN0IHVzYWdlLCBz dWNoIGFzIE1UVSAoTWF4aW11bQ0KICAgICZndDsmZ3Q7IFRyYW5zbWlzc2lvbiBVbml0KQ0KICAg ICZndDsgTVRVIG1heSBhY3R1YWxseSBiZSBva2F5OyBwZXINCiAgICAmZ3Q7IDxhIGNsYXNzPSJt b3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL21h dGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dCI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv bWF0ZXJpYWxzL2FiYnJldi5leHBhbnNpb24udHh0PC9hPiBpdCBpcyBtYXJrZWQgYXMNCiAgICAm Z3Q7ICZxdW90O3dlbGwta25vd24mcXVvdDsgYW5kIGRvZXMgbm90IGFsd2F5cyBuZWVkIHRvIGJl IGV4cGFuZGVkLg0KICAgICZndDsNCiAgICAmZ3Q7Jmd0OyBPbiB0aGUgY29udGVudCBpdHNlbGYg SSBoYXZlIHR3byBxdWVzdGlvbnM6DQogICAgJmd0OyZndDsNCiAgICAmZ3Q7Jmd0OyAtIFdvdWxk bid0IGl0IGJlIHJlbGV2YW50IHRvIGFsc28gZGlzY3VzcyB0aGUgcmlza3Mgd2l0aCByZWdhcmQg dG8gaW50cm9kdWN0aW9uDQogICAgJmd0OyZndDsgb2YgcXVhbnR1bSBzYWZlIGNyeXB0bywgaWYg dGhhdCBsZWFkcyB0byBzaWduaWZpY2FudGx5IGluY3JlYXNlZCBrZXkgc2l6ZXM/IEl0DQogICAg Jmd0OyZndDsgY291bGQgYmUgdHJvdWJsZXNvbWUgaWYgdHJhbnNpdGlvbiB0byBhIHNhZmVyIGNy eXB0byBpcyBtYWRlIGltcG9zc2libGUgZHVlIHRvDQogICAgJmd0OyZndDsgc2l6ZSBsaW1pdGF0 aW9ucy4gLSBXb3VsZCBpdCBiZSByZWxldmFudCB0byBkaXNjdXNzIHVzYWdlIG9mIEFJQSBleHRl bnNpb24gYXMNCiAgICAmZ3Q7Jmd0OyBtZWFucyBvZiBwb3NzaWJseSBleGNsdWRpbmcgaW50ZXJt ZWRpYXJ5IGNlcnRzIGZyb20gdGhlIHBhdGggYXMgdGhleSBjb3VsZCBiZQ0KICAgICZndDsmZ3Q7 IGxvY2F0ZWQgdXNpbmcgQUlBPw0KICAgICZndDsmZ3Q7DQogICAgJmd0OyZndDsgRmluYWxseSwg SSBhZ3JlZSB3aXRoIHRoZSBnZW5lcmFsIHJldmlldyB0aGF0IHRoaXMgZG9jdW1lbnQgcmVmZXJl bmNlIHF1aXRlDQogICAgJmd0OyZndDsgc29tZSB3b3JrIGluIHByb2dyZXNzLiBJZiB0aGlzIGRv Y3VtZW50IGlzIHRvIGJlIHB1Ymxpc2hlZCBiZWZvcmUgdGhlc2UNCiAgICAmZ3Q7Jmd0OyByZWZl cmVuY2VkIHdvcmtzIGFyZSBjb25jbHVkZWQsIGFyZSB0aGVyZSBhbHRlcm5hdGl2ZXMgdG8gbWFr ZSB0aGUgc2FtZSBwb2ludD8NCiAgICAmZ3Q7IFRoZXkgc2VlbSB0byBtb3N0bHkgYmUgaW5mb3Jt YXRpdmUgcmVmZXJlbmNlcywgYW5kIHNvIHdvdWxkIG5vdCByZXF1aXJlIHVzDQogICAgJmd0OyB0 byBob2xkIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBJdCBpcyBwcm9iYWJseSBzdGls bCB3b3J0aA0KICAgICZndDsgY29uc2lkZXJpbmcgaWYgdGhlcmUgYXJlIGFsdGVybmF0aXZlcyBh bnl3YXksIHRob3VnaC4NCiAgICAmZ3Q7DQogICAgJmd0OyAtQmVuDQogICAgJmd0Ow0KICAgICZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAm Z3Q7IEVtdSBtYWlsaW5nIGxpc3QNCiAgICAmZ3Q7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpFbXVAaWV0Zi5vcmciPkVtdUBpZXRmLm9yZzwvYT4NCiAg ICAmZ3Q7IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW11Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2VtdTwvYT4NCg0KDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_36dd411f853cf7fb957ac6eb90be130bericssoncom_-- From nobody Sat Oct 31 15:03:40 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACE3A0656 for ; Sat, 31 Oct 2020 15:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 ihLuc2vbL3Rl for ; Sat, 31 Oct 2020 15:03:37 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (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 5F6303A0925 for ; Sat, 31 Oct 2020 15:03:36 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 5454210C4708 for ; Sat, 31 Oct 2020 22:56:38 +0100 (CET) Received: from s630.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 33DA62EBADFB; Sat, 31 Oct 2020 22:56:38 +0100 (CET) Received: from s474.loopia.se (unknown [172.22.191.6]) by s630.loopia.se (Postfix) with ESMTP id 1D27C13B92DF; Sat, 31 Oct 2020 22:56:38 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s498.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id Ho9_QOiu1V0C; Sat, 31 Oct 2020 22:56:37 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 90.229.17.25 Received: from [10.0.1.104] (unknown [90.229.17.25]) (Authenticated sender: mailstore2@aaa-sec.com) by s498.loopia.se (Postfix) with ESMTPSA id C6D3A473233; Sat, 31 Oct 2020 22:56:33 +0100 (CET) User-Agent: Microsoft-MacOutlook/16.42.20101102 Date: Sat, 31 Oct 2020 22:56:24 +0100 From: Stefan Santesson To: Mohit Sethi M , Benjamin Kaduk CC: "last-call@ietf.org" , "draft-ietf-emu-eaptlscert.all@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Message-ID: Thread-Topic: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 References: <160401318284.11167.6795105917637378641@ietfa.amsl.com> <20201030030415.GE39170@kduck.mit.edu> <12167567-9dc5-6161-abef-826b0a8b6602@ericsson.com> <2F8F716A-C063-4DF4-8384-BBD59C636C8A@aaa-sec.com> <36dd411f-853c-f7fb-957a-c6eb90be130b@ericsson.com> In-Reply-To: <36dd411f-853c-f7fb-957a-c6eb90be130b@ericsson.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3687029795_1029242773" Archived-At: Subject: Re: [secdir] [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 22:03:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3687029795_1029242773 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I think that is great! =20 Stefan Santesson=20 =20 From: Mohit Sethi M Date: Saturday, 31 October 2020 at 15:19 To: Stefan Santesson , Mohit Sethi M , Benjamin Kaduk Cc: "last-call@ietf.org" , "draft-ietf-emu-eaptlscert.a= ll@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Subject: Re: [Emu] Secdir last call review of draft-ietf-emu-eaptlscert-06 =20 Hi Stefan, I made a minor update to reflect your feedback (https://github.com/emu-wg/e= aptls-longcert/compare/3ac0a18..2093026): Thus, the AIA extension can reduce the size of the certificate chain by onl= y including a pointer to the issuer certificate instead of including the ent= ire issuer certificate. However, it requires the side receiving the certific= ate containing the extension to have network connectivity (unless the inform= ation is already cached locally). Naturally, such indirection cannot be used= for the server certificate (since EAP peers in most deployments do not have= network connectivity before authentication and typically do not maintain an= up-to-date local cache of issuer certificates). Hope this is correct (and sufficient).=20 --Mohit On 10/30/20 4:40 PM, Stefan Santesson wrote: Hi, =20 I think the text is great.=20 However I'm not entirely convinced that AIA requires network connectivity a= t all times. The AIA CA cert url is static and works fine as identifier for a locally ca= ched cert The fact that it is the correct cert is assured by the path validation proc= ess. As such, the AIA works fine with a http cache implementation or similar or = any other solution using locally stored data. If used in a local corporate context, a cache mechanism could be provided w= ith pre-loaded relevant certs. =20 But I don=E2=80=99t know how this may or may not interoperate with deployed base = of EAP implementations. =20 Stefan Santesson=20 =20 =EF=BB=BFOn 2020-10-30, 14:48, "Mohit Sethi M" wrote= : =20 =C2=A0=C2=A0=C2=A0 Hi Stefan, =20 =C2=A0=C2=A0=C2=A0 Thank you for the review. I have updated the draft in github=20 =C2=A0=C2=A0=C2=A0=C2=A0(https://github.com/emu-wg/eaptls-longcert). Here is the diff for y= our=20 =C2=A0=C2=A0=C2=A0=C2=A0convenience:=20 =C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft= -ietf-emu-eaptlscert.txt&url2=3Dhttps://emu-wg.github.io/eaptls-longcert/draft= -ietf-emu-eaptlscert.txt. =20 =C2=A0=C2=A0=C2=A0 The following text was added: =20 =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 The size of certificates (and certificate chains) may also i= ncrease =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 manifold in the future with the introduction of quantum-safe =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 cryptography.=C2=A0 For example, lattice-based cryptography woul= d have =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 public keys of approximately 1000 bytes and signatures of =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 approximately 2000 bytes. =C2=A0=C2=A0=C2=A0 and in Section 4.2.5 =20 =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 The Authority Information Access (AIA) extension specified i= n =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 [RFC5280] can be used with end-entity and CA certificates to= access =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 information about the issuer of the certificate in which the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 extension appears.=C2=A0 For example, it can be used to provide = the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 address of the OCSP responder from where revocation status o= f the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 certificate (in which the extension appears) can be checked.= It can =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 also be used to obtain the issuer certificate.=C2=A0 Thus, the A= IA =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 extension can reduce the size of the certificate chain by on= ly =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 including a pointer to the issuer certificate instead of inc= luding =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 the entire issuer certificate.=C2=A0 However, it requires the si= de =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 receiving the certificate containing the extension to have n= etwork =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 connectivity.=C2=A0 Naturally, such indirection cannot be used f= or the =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 server certificate (since the EAP peer in most deployments d= oes not =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 have network connectivity before authen =20 =C2=A0=C2=A0=C2=A0 Let me know what you think. I am not an expert on quantum cryptograp= hy=20 =C2=A0=C2=A0=C2=A0=C2=A0or on the AIA extension. I will wait for all the comments to come i= n=20 =C2=A0=C2=A0=C2=A0=C2=A0before submitting a new version. =20 =C2=A0=C2=A0=C2=A0 --Mohit =20 =C2=A0=C2=A0=C2=A0 On 10/30/20 5:04 AM, Benjamin Kaduk wrote: =C2=A0=C2=A0=C2=A0 > Hi Stefan, =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > Thanks for the review; it raises some good topics. =C2=A0=C2=A0=C2=A0 > Replying on a couple points... =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > On Thu, Oct 29, 2020 at 04:13:02PM -0700, Stefan Santesson via Dat= atracker wrote: =C2=A0=C2=A0=C2=A0 >> Reviewer: Stefan Santesson =C2=A0=C2=A0=C2=A0 >> Review result: Has Nits =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 >> The document in general is good and well written. =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 >> Some nits needs attention before publication as the general revie= w also points =C2=A0=C2=A0=C2=A0 >> out. Ex in the abstract "This document looks at the this problem" =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 >> Some abbreviations needs to be spelled out at first usage, such a= s MTU (Maximum =C2=A0=C2=A0=C2=A0 >> Transmission Unit) =C2=A0=C2=A0=C2=A0 > MTU may actually be okay; per =C2=A0=C2=A0=C2=A0 > https://www.rfc-editor.org/materials/abbrev.expansion.txt it is ma= rked as =C2=A0=C2=A0=C2=A0 > "well-known" and does not always need to be expanded. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 >> On the content itself I have two questions: =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 >> - Wouldn't it be relevant to also discuss the risks with regard t= o introduction =C2=A0=C2=A0=C2=A0 >> of quantum safe crypto, if that leads to significantly increased = key sizes? It =C2=A0=C2=A0=C2=A0 >> could be troublesome if transition to a safer crypto is made impo= ssible due to =C2=A0=C2=A0=C2=A0 >> size limitations. - Would it be relevant to discuss usage of AIA = extension as =C2=A0=C2=A0=C2=A0 >> means of possibly excluding intermediary certs from the path as t= hey could be =C2=A0=C2=A0=C2=A0 >> located using AIA? =C2=A0=C2=A0=C2=A0 >> =C2=A0=C2=A0=C2=A0 >> Finally, I agree with the general review that this document refer= ence quite =C2=A0=C2=A0=C2=A0 >> some work in progress. If this document is to be published before= these =C2=A0=C2=A0=C2=A0 >> referenced works are concluded, are there alternatives to make th= e same point? =C2=A0=C2=A0=C2=A0 > They seem to mostly be informative references, and so would not re= quire us =C2=A0=C2=A0=C2=A0 > to hold publication of this document.=C2=A0 It is probably still worth =C2=A0=C2=A0=C2=A0 > considering if there are alternatives anyway, though. =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > -Ben =C2=A0=C2=A0=C2=A0 > =C2=A0=C2=A0=C2=A0 > _______________________________________________ =C2=A0=C2=A0=C2=A0 > Emu mailing list =C2=A0=C2=A0=C2=A0 > Emu@ietf.org =C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/listinfo/emu =20 =20 --B_3687029795_1029242773 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I think that is great!

<= p class=3DMsoNormal> =

Stefan Santesson

 

From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
D= ate: Saturday, 31 October 2020 at 15:19
To: Stefan Santesson &= lt;stefan@aaa-sec.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>,= Benjamin Kaduk <kaduk@mit.edu>
Cc: "last-call@ietf.org= " <last-call@ietf.org>, "draft-ietf-emu-eaptlscert.all@ietf.= org" <draft-ietf-emu-eaptlscert.all@ietf.org>, "emu@ietf.org= " <emu@ietf.org>, "secdir@ietf.org" <secdir@ietf.org= >
Subject: Re: [Emu] Secdir last call review of draft-ietf-emu-= eaptlscert-06

 =

Hi Stefan,

I made a minor update to refl= ect your feedback (https://github.com/emu-wg/eaptls-longcert/compare/3ac0a1= 8..2093026):

Thus, the AIA ext= ension can reduce the size of the certificate chain by only including a poin= ter to the issuer certificate instead of including the entire issuer certifi= cate. However, it requires the side receiving the certificate containing the= extension to have network connectivity (unless the information is already c= ached locally). Naturally, such indirection cannot be used for the server ce= rtificate (since EAP peers in most deployments do not have network connectiv= ity before authentication and typically do not maintain an up-to-date local = cache of issuer certificates).

Hope thi= s is correct (and sufficient).

--Mohit

=

On 10/30/20 4:40 PM, Stefan Santesson wrote:

Hi,
 
I think the text is great. 
However I'm not entirely convinced that AIA requires net=
work connectivity at all times.
The AIA CA cert url is =
static and works fine as identifier for a locally cached cert
The fact that it is the correct cert is assured by the path validatio=
n process.
As such, the AIA works fine with a http cach=
e implementation or similar or any other solution using locally stored data.=

If used in a local corporate context, a cache mechanis=
m could be provided with pre-loaded relevant certs.
 
But I don=E2=80=99t know how this may or may not interope=
rate with deployed base of EAP implementations.
&n=
bsp;
Stefan Santesson 
 
=EF=BB=BFOn 2020-10-30, 14:48, "Mohit Sethi M" <mohit.m.sethi@ericsson.com> wrote:=

 
=C2=A0=C2=A0=C2=A0 Hi Stefan,
 
=C2=A0=C2=A0=C2=A0 Thank you for the review. I =
have updated the draft in github 
=C2=A0=C2=A0=C2=A0=C2=A0(https://github.com/emu-wg/eaptls-lon=
gcert). Here is the diff for your 
=C2=A0=C2=A0=C2=A0=C2=A0convenie=
nce: 
=C2=A0=C2=A0=C2=A0=C2=A0https://too=
ls.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-ietf-emu-eaptlscert=
.txt&url2=3Dhttps://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptls=
cert.txt.
 
=C2=A0=C2=A0=C2=A0 The fo=
llowing text was added:
 
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 The size of certificates (and certificate chains) may also in=
crease
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 manifold in the future with th=
e introduction of quantum-safe
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 crypto=
graphy.=C2=A0 For example, lattice-based cryptography would have
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 public keys of approximately 1000 bytes and signatur=
es of
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 approximately 2000 bytes.<=
/o:p>
=C2=A0=C2=A0=C2=A0 and in Section 4.2.5
 =

=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 The Authority Information Access (AIA) ex=
tension specified in
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 [RFC5280] can be=
 used with end-entity and CA certificates to access
=C2=A0=C2=
=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 information about the issuer of the certificate in which the<=
o:p>
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 extension appears.=C2=A0 For example, it =
can be used to provide the
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 address of=
 the OCSP responder from where revocation status of the
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 certificate (in which the extension appears) can be check=
ed. It can
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 also be used to obtain the=
 issuer certificate.=C2=A0 Thus, the AIA
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 =
extension can reduce the size of the certificate chain by only
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 including a pointer to the issuer certificate inst=
ead of including
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 the entire issuer ce=
rtificate.=C2=A0 However, it requires the side
=C2=A0=C2=A0=C2=A0 >=C2=
=A0=C2=A0=C2=A0 receiving the certificate containing the extension to have network
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 connectivity.=C2=A0 Naturally, such indirect=
ion cannot be used for the
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 server cer=
tificate (since the EAP peer in most deployments does not
=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0 have network connectivity before authen
 
=C2=A0=C2=A0=C2=A0 Let me know what you think. I am no=
t an expert on quantum cryptography 
=C2=A0=C2=A0=C2=A0=C2=A0or on the =
AIA extension. I will wait for all the comments to come in 
=

=C2=A0=C2=A0=C2=A0=C2=A0before submitting a new version.
&nbs=
p;
=C2=A0=C2=A0=C2=A0 --Mohit
 
=C2=A0=C2=A0=C2=A0 On 10/30/20 5:04 AM, Benjamin Kaduk wrote:
=C2=A0=C2=A0=C2=A0 > Hi Stefan,
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > Thanks for the review; it raises some good topics.=

=C2=A0=C2=A0=C2=A0 > Replying on a couple points...
=C2=
=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > On Thu, Oct 29, 2020 at 04:13:02=
PM -0700, Stefan Santesson via Datatracker wrote:
=C2=A0=C2=A0=C2=
=A0 >> Reviewer: Stefan Santesson
=C2=A0=C2=A0=C2=A0 >> R=
eview result: Has Nits
=C2=A0=C2=A0=C2=A0 >>
=

=C2=A0=C2=A0=C2=A0 >> The document in general is good and well written.<=
/o:p>
=C2=A0=C2=A0=C2=A0 >>
=C2=A0=C2=A0=C2=A0 >> Some ni=
ts needs attention before publication as the general review also points=

=C2=A0=C2=A0=C2=A0 >> out. Ex in the abstract "This document=
 looks at the this problem"
=C2=A0=C2=A0=C2=A0 >>
=C2=A0=C2=A0=C2=A0 >> Some abbreviations needs to be spelled out at=
 first usage, such as MTU (Maximum
=C2=A0=C2=A0=C2=A0 >> Tran=
smission Unit)
=C2=A0=C2=A0=C2=A0 > MTU may actually be okay; pe=
r
=C2=A0=C2=A0=C2=A0 > https://www.rfc-editor.org/materials/abbrev.expan=
sion.txt it is marked as
=C2=A0=C2=A0=C2=A0 > "well-kno=
wn" and does not always need to be expanded.
=C2=A0=C2=A0=C2=
=A0 >
=C2=A0=C2=A0=C2=A0 >> On the content itself I have two=
 questions:
=C2=A0=C2=A0=C2=A0 >>
=C2=A0=C2=A0=C2=A0=
 >> - Wouldn't it be relevant to also discuss the risks with regard to=
 introduction
=C2=A0=C2=A0=C2=A0 >> of quantum safe crypto, i=
f that leads to significantly increased key sizes? It
=C2=
=A0=C2=A0=C2=A0 >> could be troublesome if transition to a safer crypto is made =
impossible due to
=C2=A0=C2=A0=C2=A0 >> size limitations. - W=
ould it be relevant to discuss usage of AIA extension as
=C2=A0=C2=A0=C2=A0 >> means of possibly excluding intermediary certs from the pa=
th as they could be
=C2=A0=C2=A0=C2=A0 >> located using AIA?<=
o:p>
=C2=A0=C2=A0=C2=A0 >>
=C2=A0=C2=A0=C2=A0 >> Fi=
nally, I agree with the general review that this document reference quite
=C2=A0=C2=A0=C2=A0 >> some work in progress. If this document i=
s to be published before these
=C2=A0=C2=A0=C2=A0 >> referenc=
ed works are concluded, are there alternatives to make the same point?<=
/o:p>
=C2=A0=C2=A0=C2=A0 > They seem to mostly be informative references, a=
nd so would not require us
=C2=A0=C2=A0=C2=A0 > to hold publicat=
ion of this document.=C2=A0 It is probably still worth
=C2=A0=C2=A0=
=C2=A0 > considering if there are alternatives anyway, though.
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > -Ben
=C2=A0=C2=A0=C2=A0 >
=C2=A0=C2=A0=C2=A0 > _____________________________=
__________________
=C2=A0=C2=A0=C2=A0 > Emu mailing list
=C2=A0=C2=A0=C2=A0 > Emu@ietf.org
=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/listinfo/emu
 
 
--B_3687029795_1029242773-- From nobody Sat Oct 31 19:41:13 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009EB3A0E0D; Sat, 31 Oct 2020 19:41:07 -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 tcNhATDXu1MZ; Sat, 31 Oct 2020 19:41:05 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 046343A0E0A; Sat, 31 Oct 2020 19:41:01 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id dg9so10596256edb.12; Sat, 31 Oct 2020 19:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uiaO9GgYwYFDs0xmCcvMenIF7Kkl7w1d0tFze+uxrL8=; b=Lc4LdvBV5C/mvsXA+zjr8M5Su70hyoovF+ApoBu8B6OAx2zvZtiOHM28qDjvx1Ge6K t5vJnDx0trAdLLz0B8Xv4qNJ4OcZU7sEjcxonEQT4GaSZugXJj0xG36peUflAmZBFAi7 KqDFK2LxQ7hIaMR2BvKfe5tJtsb1iMzJXhdvSh3LsiH8xI11RuvU/JVrIGuNChZP+2rk plbUo2aOFzNE9kKApABrprrQAi1FAH2JbLaMWLKGRXOjQr8sDbiNpD/rOtgsWb3jzLOK PKzgEHjM148PqOJXfX5OVb+TLDeRgInCV6B/19dqele1V3k+v4VeTnGGs7rPVRJk9L3k 6VSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uiaO9GgYwYFDs0xmCcvMenIF7Kkl7w1d0tFze+uxrL8=; b=OY0RAz0N4KM8nYnON/C9rl2xltfWOECRsu1E7U5jerNFqMl1J6Er/9kj0Tzq8FV/Ct u60MzmXFq/eo/Y0UYgLH6mAOgO0rUTKF/Y8oEebyRGoS6Ti59Fs8rqgivKBHEzVHe/a8 8sgfAL0H4JeJheOVL7ytPSxrf1imImOvXR7Ojdjd1EUdjSlhms3ZdMKKuYRO6fpN8lwf 2CbiHWz9uCZIm26AXu1EMy7RfG62VNLMl2xHXPmJJddPJhCeOyQVlf5ztcdEA/l9lKFe hogE7axPyjuKe9QwdihptE1xVtV17fppt7jUqb0+QbRxoklT+hX3rsywxtXB1PDjLFMv dUXg== X-Gm-Message-State: AOAM533ihkqnjiWUFZoVhI6mGYdn57Pj1wrq2AkU4MFLbHnwziceqHs/ caDl4i7tvFWPcGrr9KCnksrFfxL1Dz0zMLeCRXnzF4mAX4Y= X-Google-Smtp-Source: ABdhPJzPmEyl1jgG6Uc12bls/wWWCdEdwHBngOSsGv1X/bX9UStqARLTTnR2XyKiKyQ3VG61PGRaJkX5JU/M6b5eFTQ= X-Received: by 2002:a05:6402:b45:: with SMTP id bx5mr9781836edb.193.1604198459907; Sat, 31 Oct 2020 19:40:59 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Sat, 31 Oct 2020 19:40:47 -0700 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-quic-tls.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000005a221705b3028f05" Archived-At: Subject: [secdir] Secdir review of draft-ietf-quic-tls-48 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 02:41:07 -0000 --0000000000005a221705b3028f05 Content-Type: text/plain; charset="UTF-8" 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. This document specifies the cryptographic exchanges and formats associated with the QUIC protocol, which in turn is an ambitious protocol that could over time replace TCP. quic-transport, quic-tls, and quic-recovery represent a triple of I-Ds that are always used together and could be combined into a single spec, though the length of the existing specs is already daunting. In many cases, it is impossible to evaluate them independently. As an interested outsider, I see these protocols as exceptionally well designed and the specs exceptionally well written. I could not find even any nits in a very long spec. It is misleading to regard this as a specification of running QUIC over TLS. It is related to TLS in the same way that DTLS is related to TLS: it imports much of the syntax, but there are many differences and its security must be evaluated largely independently. My initial reaction to this spec was to wonder why it did not simply run QUIC over DTLS . I believe the answer is that careful integration improves the performance and is necessary for some of the address agility/transition design. Given its potential importance, this deserves a thorough review by our best security people. Fortunately, from the acknowledgements list, it appears it has gotten that. There are a few aspects of the design that might raise eyebrows. For example: 1) TLS exchanges start out in cleartext until a key can be negotiated. QUIC data is always encrypted. The initial packets are encrypted with fixed keys whose derivation is specified in the I-D until fresh keys are negotiated. This isn't a security problem...it will just surprise people. 2) Applications using TLS can usually be configured to run over TCP in contexts where cryptographic protection is not needed. (e.g., use HTTP instead of HTTPS). Applications using QUIC cannot. That is likely to mean in practice that it will more frequently be the case that applications using QUIC will need to connect to servers without certificates signed by a CA trusted by the client (because that's the substitute when connecting to a server without a certificate). It's not clear what the spec should say about that, but perhaps the problem should be acknowledged. Radia --0000000000005a221705b3028f05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=C2=A0

This document specifies the cryptographic excha= nges and formats associated with the QUIC protocol, which in turn is an ambitious protocol that could over time replace TCP. quic-transport, quic-tls, and quic-recovery represent a triple of I-Ds that are always used together and could be combined into a single spec, though the length of the existing spe= cs is already daunting. In many cases, it is impossible to evaluate them independently.

=C2=A0

As an interested outsider, I see these protocol= s as exceptionally well designed and the specs exceptionally well written. I cou= ld not find even any nits in a very long spec.

=C2=A0

It is misleading to regard this as a specificat= ion of running QUIC over TLS. It is related to TLS in the same way that DTLS is related to TLS: it imports much of the syntax, but there are many differenc= es and its security must be evaluated largely independently. My initial reacti= on to this spec was to wonder why it did not simply run QUIC over DTLS . I bel= ieve the answer is that careful integration improves the performance and is necessary for some of the address agility/transition design.

=C2=A0

Given its potential importance, this deserves a= thorough review by our best security people. Fortunately, from the acknowledgements list, it appears it has gotten that.

=C2=A0

There are a few aspects of the design that migh= t raise eyebrows. For example:

=C2=A0

1) TLS exchanges start out in cleartext until a= key can be negotiated. QUIC data is always encrypted. The initial packets are encrypte= d with fixed keys whose derivation is specified in the I-D until fresh keys a= re negotiated. This isn't a security problem...it will just surprise peopl= e.

=C2=A0

2) Applications using TLS can usually be config= ured to run over TCP in contexts where cryptographic protection is not needed. (e.g., u= se HTTP instead of HTTPS). Applications using QUIC cannot. That is likely to mean in practice that it will more frequently be the case that applications using QUIC will need to connect to servers without certificates signed by a CA trusted by the client (because = that's the substitute when connecting to a server without a certificate= ). It's not clear what the spec should say about that, but perhaps the problem should b= e acknowledged.


Radia

=C2=A0

--0000000000005a221705b3028f05-- From nobody Sat Oct 31 21:55:30 2020 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCF3A0E63; Sat, 31 Oct 2020 21:55:22 -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 g4T-qIUld1PH; Sat, 31 Oct 2020 21:55:20 -0700 (PDT) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 61DB73A0E62; Sat, 31 Oct 2020 21:55:20 -0700 (PDT) Received: by mail-ej1-x634.google.com with SMTP id o9so11950301ejg.1; Sat, 31 Oct 2020 21:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=D37WCpLpjDlaib4cV0orkhqAZ3C2j41XQS1GucpNf1Y=; b=lC/d8p6vrVB7XTW3SQVKvhQZ8AQ3VMQHPogWVp19xqgTiyTV/4fBgWyE8LYPPsTGq2 w2nMMu6RsVtho7N7ynUD/tQ5ClQ5SoaEQzwUawN5P4OJh+Epp/HfRLMw841Of5TfegOa tcEI5bKBCsPGOk2rDbYmNAbiAXY4ZiSXrXrZTvT1bABS5V+VYUONpDspXzZPi0iKkatN /uroh0aOo7jtjCkXC5J3WOmmSqioFpYv19khRDCQjOivvOddIp+nZ6xIPrD/fBoKfCfF omM6gQfMEivPVPc+X6SWt6tgwQ2bnH/Mc6V/qVNfeWaa7dYUcwJWP1YwKcYGJdknj4rx f1EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=D37WCpLpjDlaib4cV0orkhqAZ3C2j41XQS1GucpNf1Y=; b=Nxw6ZW1je0W8L0NTtljf1w9lG3P2BD8HKIb9bRkPq4setMihNhVdIOct830IN1QmhQ pUrTORbvq2Co6Ql4dWuMHNMdIHxelI4VOXR/Q2+c6H+McR/DPBmYt6ECh6ISnQ1JNW3J mnbX7YYpSCKIvanucURees4+ZxwrVjcgMtrYGr9y8Q8JdexCXphWaixIxGbezGvcsx9p 0Jqo+vUCVIxcPRvZMv0gbbo9Ou/QCZuyHa0yv8Wx8d63Q5gMkIbwGQcfnx4V0U+lKU6K am+ZMj3w9oMKpSeCzWEJ4Larr7GQYPQMaUyTu4jxJq3uHLuLjZXU2wAFg1pvXmGcCpaD qvFA== X-Gm-Message-State: AOAM5329PNB0ucQW0cPoN622Y0aaL8wxPJrygOGhB9FjU7LkW2jvqZ+h 3ob3mFXf/iS7dlt4pprPOTPHFubTDrmLh7h2QXCp5N353vU= X-Google-Smtp-Source: ABdhPJwyD37F7NrFsqy0kEZL5IvmqgwGU8RYBdo16hfsCxjJ4f1MG9mtBMDyEmBbeZApgUOvs8duDQJi07mr+R+n9Ys= X-Received: by 2002:a17:906:f909:: with SMTP id lc9mr1079956ejb.439.1604206518598; Sat, 31 Oct 2020 21:55:18 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Sat, 31 Oct 2020 21:55:07 -0700 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-dots-signal-call-home.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b0021205b3046f6b" Archived-At: Subject: [secdir] secdir review of draft-ietf-dots-signal-call-home-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 04:55:22 -0000 --000000000000b0021205b3046f6b Content-Type: text/plain; charset="UTF-8" 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. I didn't find anything objectionable from a security point-of-view in this I-D. DOTS is a protocol for reporting denial of service attacks to someone closer to the source than you are in hopes they can block such attacks before they have wasted more network bandwidth. The agent reporting the DoS is the DOTS client and the agent receiving the report is the DOTS server. The DOTS protocol is described in other documents. There is a special case where a DOTS server is running in a "home" network where it is capable of initiating connections but not receiving incoming ones because of NAT or firewall. This document defines a variation of the DOTS protocol for such scenarios where the DOTS server initiates the connection to the DOTS client in order to receive notifications of DoS traffic originating inside the firewalled network. Since authentication uses client and server certificates with TLS or DTLS, little needs to be changed to support this role reversal. Found one typo: Section 5.3.2: depictes -> depicts --000000000000b0021205b3046f6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

=C2=A0

I didn't find anything objectionable from a= security point-of-view in this I-D.

=C2=A0

DOTS is a protocol for reporting denial of serv= ice attacks to someone closer to the source than you are in hopes they can block such attacks before they have wasted more network bandwidth. The agent reporting= the DoS is the DOTS client and the agent receiving the report is the DOTS serve= r. The DOTS protocol is described in other documents.

=C2=A0

There is a special case where a DOTS server is = running in a "home" network where it is capable of initiating connections but = not receiving incoming ones because of NAT or firewall. This document defines a variation of the DOTS protocol for such scenarios where the DOTS server initiates the connection to the DOTS client in order to receive notificatio= ns of DoS traffic originating inside the firewalled network. Since authenticat= ion uses client and server certificates with TLS or DTLS, little needs to be changed to support this role reversal.

=C2=A0

Found one typo:

=C2=A0

Section 5.3.2: depictes -> depicts

--000000000000b0021205b3046f6b--