Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and COMMENT)
"Fabio Maino (fmaino)" <fmaino@cisco.com> Fri, 25 October 2019 17:00 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 C1B3A1201E4; Fri, 25 Oct 2019 10:00:30 -0700 (PDT)
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=E7yjrGy1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ik6TKDDm
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 C1KPSTPBgmjS; Fri, 25 Oct 2019 10:00:28 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08A112013A; Fri, 25 Oct 2019 10:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7658; q=dns/txt; s=iport; t=1572022828; x=1573232428; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Djq9hxUmhowhmgbBvz+OT3I6nsv512RW+iprFvpBXmo=; b=E7yjrGy1YzyUgtw5yFCgypjXLtzlCfZO3mM2l/iF70PUzaWH3bWHbEPY 59MPAy2kevVSxpo9gQ4GgK/w3VUfGQ1z6AlEtG2T+7IqFzTeXzAiP3Lkm ovv12trAAtNiypgsatDOHs32vGNKiJ200djUCGy6AuAMojHL9CyfIIf4S g=;
IronPort-PHdr: 9a23:L4TnDh1+OpB5IKvfsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxGOt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQB0jyLfjtRyc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyAABUKbNd/5ldJa1lDgwBAQEBAQEBAQEDAQEBAREBAQECAgEBAQGBe4FLUAVsVyAECyqEKINHA4ptgjmYKoFCgRADVAkBAQEMAQEjCgIBAYRAAheDKCQ4EwIDCQEBBAEBAQIBBQRthTcMhVECAQMSEREMAQE3AQ8CAQgaAiYCAgIwFRACBAENBSKDAAGCRgMuAQIMp08CgTiIYXWBMoJ+AQEFgUhBgwIYghcDBoEOKIlGgkkYgUA/gREnDBOCTD6CYgIBAgGBKgELBwEfgxAygiyNEoJmnXEKgiSHEIFNiEiECBuCPIdUj0OOPIgqkSICBAIEBQIOAQEFgWkiZ1gRCHAVZQGCQVAQFIMGDBcVgzuFFIUEO3QBgSiMXQ8XgjUBAQ
X-IronPort-AV: E=Sophos;i="5.68,229,1569283200"; d="scan'208";a="647097236"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Oct 2019 17:00:24 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x9PH0NZY006502 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Oct 2019 17:00:24 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 12:00:23 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 12:00:22 -0500
Received: from NAM05-DM3-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; Fri, 25 Oct 2019 12:00:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rfhqh6ypbGrOwiLCkIGQ0h9HBUDlN/DXp1tgpU7NNdWyoJjUO5EPEmDn6LwSnkpyM2sUoHgB8Ge+RE5F/sP9+fjxpD1FrYagLXHFg0Dwgz5pAGBWfTwnrhzzREEOk6oDHB0/gF2YF173XFnVqcpZFrLlSfSCKdFnAIBCOPOQMqxz/PuQt5UrJZfD1HCCEuL6wkh3xrdsLKCFVMh/OyfrCfjRKmpqoQgYVzZhpmwrVKqoIPBpGHI7sE8jtaL8YIo1NW0zyMQeGpTO9KAcvt4qDJuOa7kuRG+OgUQgbgEaE/etQwHI90SVCiLL2V4cGAICyLGy/4gVa72L4U3mmxTUSA==
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=Djq9hxUmhowhmgbBvz+OT3I6nsv512RW+iprFvpBXmo=; b=eIUlMd0dJMYxdONqdMiX55iv5b1fdJ61uplMD4koYIrew+mOdHywsdw9kZM55+HBWe69J2ZEXXPSc5tQpx3HhADZagdBTalDp3ZdnsX+VwhvHWTJsQmUtWyfQd5D46dIMT8jAaI1qlNsnpwF6BL5AHoXvHLztnTKv6FEwjxUPZOwZ0Ql3QLeWkMQHjo0IeGEg7uwTNXBWbJrwIOSNhQSow9+o6iN/JGsC3MN0ZvOKqOsRbA8RbkGR3ik/ICP1c8YJxZcfWOVFluAgdwEuKCEYh9nvSi9UbBMeOfnO1zYM9aVS8a5GrOl/aVklELi83vTWm7WEsGlllL1vdhJGMheVw==
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=Djq9hxUmhowhmgbBvz+OT3I6nsv512RW+iprFvpBXmo=; b=ik6TKDDmOZ0wC+mmWHlX8cEFM/ALXyOTevKrFGImKtFufiN9n84G3UkSpRZhSg0ViDl9ibSqF2FP7ik5hhwDQZi0zfEX763lwTIFXkkBw7X6epLo79IsriQx3W5ysuv+kYXCkJfYKLfKqOaFP0mIpyPhMI9hv2eWSZkhvr4U9Kg=
Received: from BY5PR11MB4420.namprd11.prod.outlook.com (52.132.255.20) by BY5PR11MB4038.namprd11.prod.outlook.com (10.255.162.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.25; Fri, 25 Oct 2019 17:00:22 +0000
Received: from BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::b9e3:dd7:b0a6:9780]) by BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::b9e3:dd7:b0a6:9780%3]) with mapi id 15.20.2387.023; Fri, 25 Oct 2019 17:00:22 +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 Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and COMMENT)
Thread-Index: AQHVis2JtsmZFkewG0ibJIbZNfskDKdrIGuA
Date: Fri, 25 Oct 2019 17:00:21 +0000
Message-ID: <3345A897-84EE-4028-A5EC-FFD53EA2EE30@cisco.com>
References: <157196432774.11379.4337977686963900033.idtracker@ietfa.amsl.com>
In-Reply-To: <157196432774.11379.4337977686963900033.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fmaino@cisco.com;
x-originating-ip: [2001:420:301:1258:246b:daf3:4299:3937]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 46596b79-15f2-4748-adc1-08d7596cd291
x-ms-traffictypediagnostic: BY5PR11MB4038:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BY5PR11MB40388F7921EEBCECD9C04429C2650@BY5PR11MB4038.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(136003)(346002)(366004)(199004)(189003)(5660300002)(11346002)(14454004)(46003)(446003)(4326008)(76176011)(102836004)(486006)(14444005)(6116002)(2616005)(476003)(25786009)(99286004)(8676002)(81156014)(81166006)(2906002)(8936002)(305945005)(7736002)(58126008)(66556008)(66574012)(54906003)(36756003)(110136005)(316002)(66476007)(66946007)(64756008)(33656002)(2171002)(6486002)(71190400001)(229853002)(71200400001)(256004)(186003)(6506007)(6512007)(6306002)(86362001)(478600001)(76116006)(6246003)(966005)(6436002)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4038; H:BY5PR11MB4420.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: jkwijwAECDFPTWJfQxDnH5u1tmMvHrYIn7cOdQ67eQIpL/lS3XJsrpjCzd1jAUjQz0m73OQToTAy2+YKU8tdirYKgxq0ewpKsiI9R/rNfjSax+6eaKtspMdDTPAEIHwFbs+HTbB96edtIgfZTCfrWia/GHdUGwh20xsjy8aD8Tjttwbfed7vWK4ZPRxj39L7VAqunHwBdSYy5VrYGYcwZ3ipGfJe8AZNEEbM/Cdy81lX7eT+3UB8CPNy/USVBHJkRTsXpKhPkHS5qEnHdghdkAityNlL9Er8szm9z7eranTeCbL54uiLBH9kCyM3BusdhaUrISYEu3cQvv1G28Pn+SZ7FBJnql2T7Iy+vcxUun2Pcb5AM/I3puPv1q6zHZC7Frud68Nz/Esad1Jl+ABhBFKDxEGHZrFABxK9T+YO4MQSK8hldW1Uk9FrGkX7dz+g0TWWWevGh3/2MSglmd2TOOTaeDPr/dSVjthFz/jk6OY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <B74558DD14A3CD4486CA2BCB30459C63@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 46596b79-15f2-4748-adc1-08d7596cd291
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 17:00:21.8208 (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: kbEXzZV4lXX2TDMIos0xzFWrS2ygPrF5Ev5WZVF2mz9CN4Gkc4d4pn5aYGD67jWu1bgfVg5s223btHiJjvsM/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4038
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/rDVHXrcnJZDKTcZzUQYRbMAiCfI>
Subject: Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf-lisp-gpe-08: (with DISCUSS and 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: Fri, 25 Oct 2019 17:00:31 -0000
Thanks Benjamin, Moving 8060 to normative was my unintentional mistake, sorry. We had actually reduced the dependency from 8060 in rev -08. I've just published -09 that brings 8060 back to informative (and also addresses the 'partial mitigation' comment). Thanks, Fabio On 10/24/19, 5:45 PM, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-lisp-gpe-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the updates in the -08! Can you please say "partially mitigates" instead of "mitigates" in "However, the use of common anti-spoofing mechanisms such as uRPF mitigates this form of attack."? Now that RFC 8060 is a normative reference, it's a downref that I believe will need to be IETF LC'd again. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [original COMMENT section unchanged; contents presumably stale] Section 1 LISP-GPE MAY also be used to extend the LISP Data-Plane header, that has allocated all by defining a Next Protocol "shim" header that nit: allocated all of what? Section 3 This is not exactly the responsibility of LISP-GPE merely because it allocates the last bit in this bitmap, but it seems like it would be quite useful to have a table of which combinations of values are valid vs. nonsensical, given the somewhat complicated interaction between some of these flag bits. Similarly, the encoding of the Source and Dest Map-Version fields, compared with [I-D.ietf-lisp-rfc6830bis], is reduced from 12 to 8 bits. This still allows to associate 256 different versions to each Endpoint Identifier to Routing Locator (EID-to-RLOC) mapping to inform commmunicating ITRs and ETRs about modifications of the mapping. Are we limited to 256 versions total, or is there some sort of larger version space that we truncate to send (a la a wraparound process)? I understand that map-versioning is primarily in a separate document but it seems important for this document to describe to what extent it is limiting functionality. Section 3.1 To ensure that protocols that are encapsulated in LISP-GPE will work well from a transport interaction perspective, the specification of a new encapsulated payload MUST contain an analysis of how LISP-GPE SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit Congestion Notification (ECN) bits whenever they apply to the new encapsulated payload. This MUST is duplicated in the next three paragraphs; I would suggest leaving this introduction as non-normative, with something like "needs to contain an analysis of how LISP-GPE will deal with [...]" Also, nit: "the outer UDP Checksum" Section 4 When encapsulating IP packets to a non LISP-GPE capable router the P-bit MUST be set to 0. [...] A LISP-GPE router MUST NOT encapsulate non-IP packets (that have the P-bit set to 1) to a non-LISP-GPE capable router. I'm failing to see how these two sentences are not redundant. Section 5.1 Just to be clear, the intent is that if there is some non-IETF protocol that we want to encapsulate, we write a two-page Standards-Track RFC that says "this GPE codepoint means to do what this non-IETF document says"? Section 6 However, the use of common anti-spoofing mechanisms such as uRPF prevents this form of attack. I think "mitigates" is probably better than "prevents" in this case. 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 protection mechanisms (such as IPsec) SHOULD be used in combination with LISP-GPE by those protocol extensions that want to protect from on-path attackers. The g-Bit is present in the Map-Reply message, which can in the general case be sent via triangle-routing, in which case the establishment and selection of IPsec security associations is somewhat nontrivial and probably does not quality as "typical", based on my limited experience. I think a more general scheme for providing integrity protection for mapping messages is needed as a mandatory mechanism, but that's a topic for the control-plane document so I will not belabor it here.
- [lisp] Benjamin Kaduk's Discuss on draft-ietf-lis… Benjamin Kaduk via Datatracker
- Re: [lisp] Benjamin Kaduk's Discuss on draft-ietf… Fabio Maino (fmaino)