Re: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)
"Fabio Maino (fmaino)" <fmaino@cisco.com> Mon, 06 January 2020 23:34 UTC
Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ECD12007C; Mon, 6 Jan 2020 15:34:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=EdVeZM/e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FPm2Bmc+
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 oRqdKOmAYg59; Mon, 6 Jan 2020 15:34:57 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E67120041; Mon, 6 Jan 2020 15:34:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=145538; q=dns/txt; s=iport; t=1578353697; x=1579563297; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T9g6WBCUZ7KOdHynZE/tWmv8oG+3faMiyMfRIPp1FQQ=; b=EdVeZM/eMo+LsfoVIbj+q4mCSNHgLOzMTEJ/8KD0xw4HXgHojL6wnD8T UlsIacnZouYKiyOApQfktD1pKr8sReZgLMLDmPnIA7hCAvNb55g4T7cnz exBUdpC5SLMFkieaP2y08bw8pg7Q3Cc3/rzZK3uuxxptkAR+GJXQSJ4cJ 8=;
X-Files: Diff_ draft-ietf-lisp-gpe-12.txt - draft-ietf-lisp-gpe-13.txt.pdf : 100859
IronPort-PHdr: 9a23:wSEMfx0EuhuX69ZKsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQB0jyLfjtRyc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CuBQC1wxNe/40NJK1mDg4BAQEBAQcBAREBBAQBAYF8gVRQBWwrLSAECyqECYNGA4sCgjqBJpcMgUKBEANUAgcBAQEJAQIBASMKAgEBhEACF4FSJDgTAgMNAQEEAQEBAgEFBG2FNwyFXwIBAxIRHQEBAzQBDwIBCEICAgIYGCUCBAENBQ4UgwABgkYDHw8BAgyiVAKBOIhhdYEygn4BAQWBSUGCeBiCBQcDBoE2gVOKRhqBQT+BEScMFIIXNT6CZAIBAgGBLAEMBgE2gnkygiyNJieCcYVXgRKMZIESh32CAwqCNoNhg1OKRIMBgSEbgkaHfYEDiisohEKOU4hTkgYCBAIEBQIOAQEFgWkiZ1gRCHAVZQE5AQGCBlAYDY0Sg3OFFIUEO3QBgSeKfRAXghsBAQ
X-IronPort-AV: E=Sophos;i="5.69,404,1571702400"; d="pdf'?scan'208";a="398265482"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 23:34:55 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 006NYtgx019446 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jan 2020 23:34:55 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 17:34:55 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 18:34:53 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 17:34:53 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jy5zVypmnzzav4O02L70G3Ar9nkteKXEfsDJhZnbSAsm78NHOTvFtklkkOXmP4f1y26auJLOoLaeaK7NHd/fUPy6+Uj+2m9WO26xz++Vk4o7S/IW1D3XhB/f3Bx/8Rq8ig0s7uE/Oo5TgTnZBJS6Ps0rj9BvMA+Ibj5MaBzO4Fvnu+ANgLdUUq04J05UR2iAJsOYiuW8qy4eiTrr0E577usHT8z/wmiHW4To/zUJ3YOUMYgGFRjY4blA5A3FDn8dFHf+uR/ky8lhEXgNcd5/SZbNbeNjppNNiTTJd68ZpZtbOLE+YQn1196ttiQuMyE36tXaJiUCKTGgG8cwFV3Ezw==
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=DcaZ09iqKte4qyYrH1VBlcUQDThVqLTC8yHobd6Xx2U=; b=Kuy7tf/h/Or8rxNTMZa0yxvaeWq04zsl+03EWyA92t1jhq233cni+/l+qJkpbmvlxoCCQcTV7ocOZL80ZZRkM+XitOiO0bHKJ/+gNG1uQC8baQO4v/H/M2j9uXBOKHP16qo/DtQK7lOIe7Mi+Z2p5rMvMrEf0asGaIub4sLBljIJzCC+BplspsYmpLpoB+xBU3hTbI+0NTVhpyDfaJK4B/E4w4CyOb6/V/0wnHfGMeZ5KFOFM/J6PD0y93bNI55ppKTbx6n0dTiVFKHIVU2Bw++evCz7dAtnOKyIgyGHXHRf3Wm+jg/2a5okeM7TjgVPgILBkdiu9pBedLewFuZnWw==
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=DcaZ09iqKte4qyYrH1VBlcUQDThVqLTC8yHobd6Xx2U=; b=FPm2Bmc+NHxvh/WF+prJIi6LNdeCsneUwmhchXBii01I2jYiMdh29OLFz16VZCvoJyz5svFIAm9gK35FOsBFUIGQWkz3NjBYeNU/sqcTjx0VS6RtVP0qSydTIe3+Rs8LL+5593jOoxNJuKLWY5njXybxJT/tgGNpSfrY/naDVyU=
Received: from BY5PR11MB4420.namprd11.prod.outlook.com (52.132.255.20) by BY5PR11MB4210.namprd11.prod.outlook.com (52.132.253.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Mon, 6 Jan 2020 23:34:50 +0000
Received: from BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::cc2a:491c:a377:bc18]) by BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::cc2a:491c:a377:bc18%7]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 23:34:50 +0000
From: "Fabio Maino (fmaino)" <fmaino@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, Luigi Iannone <ggx@gigix.net>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)
Thread-Index: AQHVv0o0j3nf/Rd/60G2DD5hlTWPSqfdvv+AgAAQFoA=
Date: Mon, 06 Jan 2020 23:34:49 +0000
Message-ID: <B0781502-7752-42ED-B9C0-2F8B31976DB2@cisco.com>
References: <157773531769.4591.17385552684076890219.idtracker@ietfa.amsl.com> <4BD723EE-CCEE-44C6-AF97-A88FB33EDCF5@cisco.com>
In-Reply-To: <4BD723EE-CCEE-44C6-AF97-A88FB33EDCF5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.20.0.191208
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fmaino@cisco.com;
x-originating-ip: [2001:420:30a:4e05:15c:a22d:632b:c69f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bd53ff94-efea-4e6a-3dd2-08d7930105ff
x-ms-traffictypediagnostic: BY5PR11MB4210:
x-microsoft-antispam-prvs: <BY5PR11MB4210FD419F22BA727BAC844DC23C0@BY5PR11MB4210.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0274272F87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(396003)(346002)(136003)(51914003)(189003)(199004)(66556008)(86362001)(8676002)(33656002)(36756003)(6486002)(71200400001)(110136005)(54906003)(81156014)(2906002)(81166006)(316002)(8936002)(76116006)(5660300002)(6506007)(53546011)(66446008)(64756008)(4326008)(186003)(2616005)(966005)(6512007)(66616009)(66946007)(66476007)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4210; H:BY5PR11MB4420.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YTZ6YyQM8K++CCrXcmUXL8EAdqiFpgcjhi9BO/ZIPCgQQ4iKtPmRKJ+a+RQ1aAog0uJlvkk/UIy3Nu1mKairhzs8kg7opCEwBb+N0lXV33HeGElImO4g0HFy3jUpJQzdMF9UJXaNLDCaS3hTqhbBmAb+M0DDmY1xN48jHVIgp7wz56BVbBKCBmB1s2kswKPHNBODkbjjXCQuC9uXazuncoKS26K+iFNMoT7WXttfmfbPZD7UoAV4GeEjlwDTGYIm33HorP29LeJ1LCoC842s33xxMSqw5ohVo/kyCFYcmcQD0Ei3ybaNQo9+Md+lVwmHvje1uwok5tf8b/sMQiF+sfSaQA5VZ4ArKp0CPmkx72rBXiIk+XrXxZ/LVPK0ohEzsNG3MVoSCSCI2uI5QawLajalktYRsk1W6VU4iwFXUSWbteALpIGzUdFfPUfxMMuBUVaQ7ZcfTPHO2i1pfCF7RSqz6/X+YRPccVO1u4gwvJt0PHXTl1VL0xHSIzpftwl6hfKFH4t5lDLZ59jY2t7dTlH1Q3NSTpZaYD0IDdglh4A=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_002_B0781502775242EDB9C02F8B31976DB2ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bd53ff94-efea-4e6a-3dd2-08d7930105ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 23:34:49.9369 (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: OSiCCHI9E38aYGqnci1zsOAtnJ0l9PbX9hQjwAaX9OrZmFPeWk10Uy7MYZwn6tUJckEryDB1Ri0GQjxFqitCVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4210
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/BrJH5O0_11B-2OBPpqD6mzpUsYo>
Subject: Re: [lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-gpe-12: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2020 23:35:00 -0000
Hi Ben, I have just posted -rev 13 (https://www.ietf.org/id/draft-ietf-lisp-gpe-13.txt) that should address your comments as described in my previous email. Please, find attached the diff with -rev 12. Thanks again, Fabio On 1/6/20, 2:37 PM, "Fabio Maino (fmaino)" <fmaino@cisco.com> wrote: Hi Ben, Thanks for your comments, and happy new year! Please see below. On 12/30/19, 11:49 AM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-gpe-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in -10 through -12 to leave nonce/versioning to additional shim headers/extensions; that does alleviate the concerns that left me balloting Abstain on the -09. I do have some (new) comments on the -12. Section 3 Conceptually, I'm thinking about this document as allocating the 'P' bit in the header and specifying its format when the P bit is set to 1; I don't expect it to be making changes to generic non-GPE LISP behavior. So it's a little surprising to see that bits 0-3 are now marked as Reserved (though that could probably be wordsmithed away, and the existing Section 2 probably sets the reader up to do the right thing already), and fairly surprising to see the following in the P-Bit description: If the P-bit is clear (0) the LISP header is bit-by-bit equivalent to the definition in [I-D.ietf-lisp-rfc6830bis] with bits N, L, E and V set to 0. Is the claim that once an implementation supports GPE, it will never use the non-shim-header versions of echo-nonce, map-versioning, etc? If not, then I don't think it's appropriate to say "with bits N, L, E, and V set to 0" here. [FM] I think you make a good point, especially that we don't want to alter the behavior of the protocol when P=0. We can re-word the document accordingly: we leave NLEV bits in the header definition, and we limit the document to specify the behavior for the case when P=1. I'm also not sure I fully understand the motivation for pulling out the Locator-Status-Bits, as that field's width is unchanged from stock 6830bis. Leaving them to a TBD shim-header does prevent the conflict with the Instance ID field, and perhaps the current usage patterns justify such a shift, so this may be more of a side note than an indication of a flaw in the document. [FM] Indeed, there isn't a strong rationale to prevent the use of LSBs with GPE. Following your suggestion of specifying GPE as "allocating the P bit in LISP" we can leave that feature available even when P=1. Section 7 LISP-GPE, as many encapsulations that use optional extensions, is subject to on-path adversaries that by manipulating the g-Bit and the packet itself can remove part of the payload. Typical integrity Is "g-Bit" supposed to be "P-Bit"? I am failing to remember what the g-Bit is, at least... [FM] yes, typo. Will fix in next rev. With LISP-GPE, issues such as data-plane spoofing, flooding, and traffic redirection may depend on the particular protocol payload encapsulated. I'd consider adding another clause, "noting that an attacker that is spoofing LISP-GPE traffic can claim to encapsulate any protocol payload type" -- the risk here is based on what types the receiver's implementation supports, not just what the legitimate sender is encapsulating. [FM] Ok, we will address this in the next rev. I'll post an updated version to reflect the comments above asap. Thanks, Fabio
- Re: [lisp] Benjamin Kaduk's No Objection on draft… Fabio Maino (fmaino)
- Re: [lisp] Benjamin Kaduk's No Objection on draft… Fabio Maino (fmaino)
- [lisp] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker