Re: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Wed, 17 March 2021 10:56 UTC
Return-Path: <jorge.rabadan@nokia.com>
X-Original-To: int-dir@ietfa.amsl.com
Delivered-To: int-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CA63A1245; Wed, 17 Mar 2021 03:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Level:
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=nokia.onmicrosoft.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 DG176oc0EHct; Wed, 17 Mar 2021 03:56:37 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2099.outbound.protection.outlook.com [40.107.93.99]) (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 EEED93A1233; Wed, 17 Mar 2021 03:56:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cotQnU3udrstQY0cUyAyMH8mO0KpLUU3dV8lwCcvM16Zm7tZoZo+ODAAVsAO1YVt52J4M6fwCkcFTu1sj8e/NeiIf2yxBzNPX921vOgEvfHYi/X+qI8as1B/Mpn+iBqi2Z+38bkKmKoi4uGqd4koAA3zC4x9w/F4q/YPxFCsnQdCXGGgLOdhNCBnA0GrOsx0Hhdql9RK7OGVkxwwmkE5qe+ZeAe83/K5zdaIUo++D+nbTuWU3F2rhKVZczmPlDRl/Rd4gfMYzfiWTRdjtRS2/SiMxh1CwfUoZ7JizsobuJlDwNEBPjCIdzXRWDAUT6xyL+OkXGodlwpHJl87p55w0w==
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=fge+KXxyoItXCpUS36WpzbVxdOQ1ICyJpwngfq6MfqA=; b=cvQQc5PxdH1meCRoaZaswo9ZEWTFZhGgQ4utF+BesVqVjRx4hca6jpl0XO6GyHZNRmVjk3AjT+Da3rFjb2ZfDQXiZHCHaY731iT5NxJndbv8H5qHTvjFcJBGwWsz5SoSM77t6nUup8EYvZ1FXif9O7ZfnHJT/uybSt806gTzzR97TJh/4gn8omhzlqn9xi0jmPNyNquIg6IzN6eYmyzPqfEVEQXqIbSEWJ8DAMkwRWdJdlAsfnduuV7svCNMJ07aUWOt4bUMRuAyPzUeuN3Uhh8/gmbCiL4v5L1A7AkWDvHp38NHpATpILbacY8EXbZrZFuWV3+dH8NxW9x3uYj7sw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fge+KXxyoItXCpUS36WpzbVxdOQ1ICyJpwngfq6MfqA=; b=w+f8LZl0HbIC/g7TpOivl76YjhJ2UV12n9wvwrWoTyFVF/jSjAhdvFsF4x6A6jMPjd0pesbsw72MsXmRT7x4J+/WBsWtAopIpgty1Ne2Xrak9CJKhKjQQP6YkhYKyQhXEh53y10GEJqJCDauVJBdWsDMumy8h3mf1IU7QUdj8rY=
Received: from MWHPR08MB3520.namprd08.prod.outlook.com (2603:10b6:301:61::15) by MWHPR08MB2798.namprd08.prod.outlook.com (2603:10b6:300:cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Wed, 17 Mar 2021 10:56:04 +0000
Received: from MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::3df6:7840:7369:73a6]) by MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::3df6:7840:7369:73a6%6]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 10:56:04 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>, "int-dir@ietf.org" <int-dir@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11
Thread-Index: AQHW724azrWDKaoe40WMynsH9VAKhaqGvSFX
Date: Wed, 17 Mar 2021 10:56:03 +0000
Message-ID: <MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9@MWHPR08MB3520.namprd08.prod.outlook.com>
References: <161117591453.11763.14808972528115094239@ietfa.amsl.com>
In-Reply-To: <161117591453.11763.14808972528115094239@ietfa.amsl.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=nokia.com;
x-originating-ip: [79.156.144.227]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 63592539-e136-425a-68ed-08d8e9334283
x-ms-traffictypediagnostic: MWHPR08MB2798:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR08MB2798ED5768D58ACF5D05F35CF76A9@MWHPR08MB2798.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Fe8rinlzgtVP9M7wj7E9+jXMUAvr2fOjO/LdrFruTb6HhSL9lcr4a0L74MiNya0AqSpg71552Q9LbEDzoTfCU4oZqurnCgVBPN4XCHv5jreXolifkWifWh6kzjK9PsdRjJEp42HlYo2fyIsQhHf2O2iCZkkQNdiwXlE2i8ulWssy37yD9V75+/eMNJUPVCvd+yJbTBLm9WEVTvO/S6CFQp9/lO/MPNvhgp5RIwNxWyWAhfp0bDLjaU0LD808u5ZjMu1/2VrdM2ngGYi2ifWim2Ysr7/NrXV+mCWyJ4OBFSDlW73HM6w8le+kf9Sx9eOVgEGuQ+sZZEbWUhTBobr+ZsBQPME2aZ+HNqhONu/F2QkgomXsN37rmCndOU0+z0a3V9iF3lZLhf5+9HrkNxSWKr5pEp1yN7R/vJa8MK3iRarFMcUUaEMOHJEydeIR4RKwjCItgb4Gk1bGVa4m6Kh6i/qFHgGYe7Ux3M0oywDgMhBI+ebSpJwMJtPonXhPgVUX5sQz7Vxl/8P9VZ1J7cb+W7k4xNo/hCuUeIizKxVdUF/i2Kr5Yk1XEOgSLDxOtf2v2mfrVo1Lku2bnO/O0AR92x8LxDFDaoMozMby/jWvn2ilgMsa0FdOlYszYrS8tFvyotu51j7fO+4NCCJjMyWzBQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR08MB3520.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(186003)(64756008)(966005)(4326008)(66476007)(2906002)(166002)(478600001)(53546011)(66946007)(66556008)(6506007)(8676002)(33656002)(7696005)(71200400001)(76116006)(8936002)(91956017)(83380400001)(66446008)(110136005)(86362001)(55016002)(54906003)(9686003)(5660300002)(316002)(30864003)(66574015)(52536014)(26005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: FJ8/JZIWYmwYmDhFqo77fX9pRvoY+pzv4WupigP15c1vWcsjuy9xIiuuW0HiTqRJOlMtQIold+PxoSgJIQ4c0KuXxBIQz0jko5a/nv8cF6Ffguh2Hn/HRv3dxNKZ1Rm1JqG8xM2q1uXVONsjO0FHLixkpdUvH0hps0yJcrkjtuixmSIaT6UyKluO7IlgW5MOw4Vm9wwmMcU6Jsm8RMXYahbeeTo6bp78hM6WUtQe3JS7eC4T4omS+ykwZZ/cKAQ4tHrKGYhzLuBF0cpqAZGqKO5HmruVlNaisGm8FdMOd+aCOeHWFZImFNBoIRwYpXtxKDQdHeqUay1TEfY3S36di/p0Me3uM8gX4gdQ2DQtjPpWE7Q+eUg5eE2uJcZr9omc6ZREPzzi1V0grvemQuIbVif25sFhlkNaHhVxQPsHROW0Rr4uRubdgit5n8Gj52Jw0cDqdTeWd6SLDroNFPPlutH74QR3zoOMXoKHkXexvrpCQuNOsNXueE80dLtTtppr+chabmgviVVpjchjCY5Z6KVSTfn65hSJQbiWhcXxLeGfYIASG4XS8e43PM+5/lrJyWTuo6uRCgDC5MMWHuzzm8ZqkYjk+/6pclv5pxbu8+RxUGCS292k2+w6CwEWEoZVmuTDWSryU8BgydKCmy26lXFRIF5jIQX9HFdEUSuO6jQKbHrmIu5peGAK1cTlaTlXwY/mW2erda6C6vd1jxihW0q8PzEG8zHZqhstgKSqrELxhQN8OBwscpOLghWZCIvmKk1toOclcWvQRHhsI14462jPcrPcmtoUubX3usNxPne/m3eHyf0U+W6XdMfD23wbfAoekv2uc5vbk4yRJKaM54hlLRrXzniZd17sum4NdyJJP6W4cUzYAR31sQO/aOODnhcJo+dRf9u2Ar661aHn2uk8znMt1HorR+jJnA5drgQnrcl/BxT1MftIIc9BQ0tUK7XRSRF55/jdW5OJu0rXD6YgC1BpqUUxhJXXS5ax3AqI8mr5UOmDFFhe0BIvsT0BmbQusFdOQZsdLA6Vg2txIUZavbMBt2ao33oZCY71+Bn4as5y5A4VJ0tC/gCx5Hyu2UBHGp7oDGtOLS61HNe1DPSU6AYsPRqk6Dcx23O8FmlUfSrXQ158EbVffaspBRvpn/dQTGU4+zU5h11jjfiRdW0//xFB3tik7MriJJE/e4tRfuUMLCAQRT8N76F/kGruNhV3yeEbg9ZNaMEmlXvUQwEnBntsZsIOPsCbf9mecCkPy/IJOpufkwVBxd/lD/IPInBo4XtJuF0Q3rjsLgls3eNycHu8L6ZaCWtHHd5moufE1UjN2a0SRlxrg2GJD8krFbVpsp3t2g23mq82LGAMmg==
Content-Type: multipart/alternative; boundary="_000_MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9MWHPR08MB3520namp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR08MB3520.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 63592539-e136-425a-68ed-08d8e9334283
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 10:56:03.8848 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aTEqk534PbXtDhIjQvM5CVSioJ3+bhBQafso+/OBVu5zDYw5HoJkJ38wjhjKzJ4fItILtzgGdyb4ERjcnnygXA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2798
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-dir/NVRTUWQGQC0PP8iinNolbJDu-FY>
Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11
X-BeenThere: int-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This list is for discussion between the members of the Internet Area directorate." <int-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-dir>, <mailto:int-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-dir/>
List-Post: <mailto:int-dir@ietf.org>
List-Help: <mailto:int-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-dir>, <mailto:int-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Mar 2021 10:56:41 -0000
Hi Jean-Michel, Thank you very much for the thorough review and my apologies for the delay in my reply. Please see my comments in-line with [jorge]. Thank you. Jorge From: Jean-Michel Combes via Datatracker <noreply@ietf.org> Date: Wednesday, January 20, 2021 at 9:52 PM To: int-dir@ietf.org <int-dir@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>, last-call@ietf.org <last-call@ietf.org> Subject: Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 Reviewer: Jean-Michel Combes Review result: Almost Ready Hi, Please find my review, as member of the INT Area Directorate, of the following document: *** GENERAL COMMENT(S)/QUESTION(S) *** o Forwarding a packet I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN allows a PE to forward a packet when the CE owning the MAC destination address and the CE owning the MAC source address are not on the same L2 link. If my assumption is wrong, that should change deeply my review. */ [jorge] let me try to clarify since I agree this is important. In your example, both CEs are on the same L2 link. Suppose you have two CEs connected to an EVPN BD (as in the document) CE1----PE1---evpn---PE2---CE2 In EVPN terminology we say CE1 and CE2 are in the same Broadcast Domain (BD, a broadcast from one CE will reach the other CE without any modification on the frame) and they belong to the same subnet. What that means is that CE1 needs to resolve CE2’s IP address (via ARP/ND) and once it does, CE1 sends a unicast frame to CE2 and neither PE1 nor PE2 change the MAC SA or MAC DA of that frame. Frames between CE1 and CE2 will have the same behavior as if they were connected to the same L2 switch or L2 link. Does this help? */ o State of the art There are no reference to RFC 4349 and RFC 6957, at least. Previous works have been done on “Proxy-ND” and potential issues already analyzed/solved. Please my comments/questions inside: - Section 3.6 - Section 6 */ [jorge] RFC4349 seems to be “High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)” – not sure what the link is with proxy-ND, is this the RFC you intended to refer to? Sorry if I am missing something. About RFC6957, thanks for pointing that out. However, the scenario is different IMHO – RFC6957 refers to a point-to-multipoint topologies with a split-horizon forwarding, where the ‘CEs’ have no direct communication within the same L2 link. That is not the same as in an EVPN BD, where the CEs have direct communication at L2. Please let me know if that makes sense. */ *** DEEP REVIEW *** BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Updates: 7432 (if approved) K. Nagaraj Intended status: Standards Track G. Hankins Expires: July 11, 2021 Nokia T. King DE-CIX January 7, 2021 Operational Aspects of Proxy-ARP/ND in EVPN Networks draft-ietf-bess-evpn-proxy-arp-nd-11 <snip> 1. Terminology <snip> BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. BD: Broadcast Domain. ARP: Address Resolution Protocol. GARP: Gratuitous ARP message. ND: Neighbor Discovery Protocol. NS: Neighbor Solicitation message. NA: Neighbor Advertisement. IXP: Internet eXchange Point. IXP-LAN: the IXP's large Broadcast Domain to where Internet routers are connected. DC: Data Center. IP->MAC: an IP address associated to a MAC address. IP->MAC entries are programmed in Proxy-ARP/ND tables and may be of three different types: dynamic, static or EVPN-learned. SN-multicast address: Solicited-Node IPv6 multicast address used by NS messages. NUD: Neighbor Unreachability Detection, as per [RFC4861]. DAD: Duplicate Address Detection, as per [RFC4861]. SLLA: Source Link Layer Address, as per [RFC4861]. TLLA: Target Link Layer Address, as per [RFC4861]. R Flag: Router Flag in NA messages, as per [RFC4861]. O Flag: Override Flag in NA messages, as per [RFC4861]. S Flag: Solicited Flag in NA messages, as per [RFC4861]. RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC7432]. MAC or IP DA: MAC or IP Destination Address. MAC or IP SA: MAC or IP Source Address. AS-MAC: Anti-spoofing MAC. LAG: Link Aggregation Group. BD: Broadcast Domain. <JMC> BD is already defined at the beginning of the list. </JMC> /* [jorge] good catch! Removed. Thanks! */ <snip> 3. Solution Description <snip> As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding as well as the unknown unicast flooding can practically be suppressed. In an EVPN- based IXP network, where all the entries are Static, the ARP/ND flooding is in fact totally suppressed. <JMC> IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address Detection (DAD) is remaining, even when the entries are all Static: cf. RFC 4862, Section 5.4. </JMC> /* [jorge] I should probably clarify that the PEs doing proxy-ARP/ND do not have any assigned IPv6 address of their own in the BD. I agree with you that CEs connected to the PEs must do DAD, and PEs doing proxy-ND will reply to the DAD messages. If all the CEs attached to the same BD have static entries on the PEs, ND flooding *among* PEs should be practically suppressed. I included the phrase “among PEs” to avoid confusion, let me know if that helps please: “As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages among PEs is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding among PEs, as well as the unknown unicast flooding, can practically be suppressed. In an EVPN-based IXP network, where all the entries are Static, the ARP/ND flooding among PEs is in fact totally suppressed.“ */ The Proxy-ARP/ND function can be structured in six sub-functions or procedures: 1. Learning sub-function 2. Reply sub-function 3. Unicast-forward sub-function 4. Maintenance sub-function 5. Flooding reduction/suppression sub-function 6. Duplicate IP detection sub-function A Proxy-ARP/ND implementation MAY support all those sub-functions or only a subset of them. The following sections describe each individual sub-function. <JMC> No sub-function is mandatory to have “Proxy-ARP/ND” working correctly? If not, please, add text saying which ones MUST be implemented. </JMC> /* [jorge] I agree, I changed it to: “A Proxy-ARP/ND implementation MUST at least support the Learning, Reply and Maintenance sub-functions. The following sections describe each individual sub-function.” */ <snip> 3.2. Reply Sub-Function This sub-function will reply to Address Resolution requests/ solicitations upon successful lookup in the Proxy-ARP/ND table for a given IP address. The following considerations should be taken into account: a. When replying to ARP Request or NS messages, the PE SHOULD use the Proxy-ARP/ND entry MAC address as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. <JMC> What is the IP source address in the NA message? What is the Target link-layer address in the NA message? </JMC> /* [jorge] I added the following, let me know if it addresses your questions please: The following considerations should be taken into account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND entry IP1->MAC1: a. When replying to ARP Request or NS messages: - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and MAC1 addresses in the Sender Protocol Address and Hardware Address fields, respectively. - for an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as the IP SA and Target Address. M1 MUST be used as the Target Link Local Address. */ <snip> 3.3. Unicast-forward Sub-Function As discussed in Section 3.2, in some cases the operator may want to 'unicast-forward' certain ARP-Request and NS messages as opposed to reply to them. The operator SHOULD be able to activate this option with one of the following parameters: a. unicast-forward always b. unicast-forward unknown-options If 'unicast-forward always' is enabled, the PE will perform a Proxy- ARP/ND table lookup and in case of a hit, the PE will forward the packet to the owner of the MAC found in the Proxy-ARP/ND table. This is irrespective of the options carried in the ARP/ND packet. This option provides total transparency in the BD and yet reduces the amount of flooding significantly. If 'unicast-forward unknown-options' is enabled, upon a successful Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action only if the ARP-Request or NS messages carry unknown options, as explained in Section 3.2. The 'unicast-forward unknown-options' configuration allows the support of new applications using ARP/ND in the BD while still reducing the flooding. <JMC> What happens, for these two options, when there is no hit inside “Proxy-ARP/ND Table”? </JMC> /* [jorge] good point, thanks, I added this: “Irrespective of the enabled option, if there is no successful Proxy- ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the context of the BD, as per Section 3.6.” */ <snip> 3.5. Flooding (to Remote PEs) Reduction/Suppression The Proxy-ARP/ND function implicitly helps reducing the flooding of ARP Request and NS messages to remote PEs in an EVPN network. However, in certain use-cases, the flooding of ARP/NS/NA messages (and even the unknown unicast flooding) to remote PEs can be suppressed completely in an EVPN network. For instance, in an IXP network, since all the participant CEs are well known and will not move to a different PE, the IP->MAC entries may be all provisioned by a management system. Assuming the entries for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND table will only contain static and EVPN-learned entries. In this case, the operator may choose to suppress the flooding of ARP/NS/NA to remote PEs completely. <JMC> Cf. my comment about DAD in section 3. </JMC> /* [jorge] following up on my response to your comment, the DAD messages from the CE will be replied by the proxy-ND function on the connected PE if there is a hit. Otherwise it should be flooded. The above case for IXPs with all static entries is an exception that assumes there is always a successful lookup on the proxy-ND table, hence flooding could be avoided. I also added a sentence for the next paragraph: The flooding may also be suppressed completely in IXP networks with dynamic Proxy-ARP/ND entries assuming that all the CEs are directly connected to the PEs and they all advertise their presence with a GARP/unsolicited-NA when they connect to the network. If any of those two assumptions is not true and any of the PEs may not learn all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA messages from the local PE to the remote PEs SHOULD NOT be suppressed, or the address resolution process for some CEs will not be completed. */ <snip> 3.6. Duplicate IP Detection The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. <JMC> Duplicate Address Detection is mandatory: s/SHOULD/MUST IMHO, it would be useful to add text explaining why RFC 6957 doesn’t solve your issues and so you need to specify a solution “from scratch”. </JMC> */ [jorge] Since DAD is still performed by the CEs, we wanted to make this duplicate IP detection on the PEs as a recommendation rather than a MUST. Also there are many proxy-ND implementations for EVPN BDs out there that do not do this and we didn’t want to make them non-compliant unless it is absolutely necessary. Let me know if it is ok to keep it as SHOULD. Also, I added this to address your comment about RFC6957, let me know if it is ok: The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. For IPv6 addresses, CEs will continue to carry out the DAD procedures as per [RFC4862]. The solution described in this section is an additional security mechanism carried out by the PEs that guarantees IPv6 address moves between PEs are legit and not the result of an attack. [RFC6957] describes a solution for IPv6 Duplicate Address Detection Proxy, however, it is defined for point- to-multipoint topologies with a split-horizon forwarding, where the 'CEs' have no direct communication within the same L2 link and therefore it is not suitable for EVPN Broadcast Domains. In addition, the solution described in this section includes the use of the AS-MAC for additional security. */ <snip> 5.1. All Dynamic Learning In this scenario for minimum security and mitigation, EVPN is deployed in the peering network with the Proxy-ARP/ND function shutdown. PEs do not intercept ARP/ND requests and flood all requests, as in a conventional layer-2 network. <JMC> ND messages are IP based: s/layer-2/layer-3 </JMC> /* [jorge] the “layer-2” refers to the network between the CEs and not the nature of the CEs or the messages they sent. I modified the sentence to clarify, let me know if it helps please: PEs do not intercept ARP/ND requests and flood all requests issued by the CEs, as a conventional layer-2 network among those CEs would do. */ <snip> 6. Security Considerations <snip> The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. The Duplicate IP Detection and the use of an AS-MAC as explained in Section 3.6 protects the BD against ARP/ND spoofing. <JMC> You are assuming that the attacker and the victim are not on the same L2-Link. Is it always the case in your scenarios (i.e., only P2P links between PE and CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. </JMC> /* [jorge] the attacker and the victim are in the same L2 broadcast domain, as discussed at the beginning of the email. Does that change your comment? Let me know if it doesn’t please. */ <JMC> I would some text about the fact that your proposal cannot/will not work if there is a (current or future) security mechanism securing ARP/ND exchanges (e.g., SEND) because the PE is not able to secure "proxied" ND messages (i.e., with SEND, the PE is not aware of the security credentials linked to an IP address). </JMC> /* [jorge] Based on Russ’ review https://mailarchive.ietf.org/arch/msg/bess/wi_uxXT1HGfxCGphJL6fDmeqPa4/ - I removed any references to SEND in the text. Other than that, I added this: Finally, it is worth noting that the Proxy-ARP/ND solution in this document will not work if there is a mechanism securing ARP/ND exchanges among CEs, because the PE is not able to secure the "proxied" ND messages. Taking your words as a model… Let me know if this addresses your concern, please. */ <snip> Thanks in advance for your replies. /* [jorge] thank YOU for such thorough review of the ND aspects! */ Best regards, JMC.
- [Int-dir] Intdir telechat review of draft-ietf-be… Jean-Michel Combes via Datatracker
- Re: [Int-dir] Intdir telechat review of draft-iet… Eric Vyncke (evyncke)
- Re: [Int-dir] Intdir telechat review of draft-iet… Rabadan, Jorge (Nokia - US/Mountain View)