Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Mon, 08 March 2021 19:50 UTC
Return-Path: <jorge.rabadan@nokia.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11CE3A1681; Mon, 8 Mar 2021 11:50:17 -0800 (PST)
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 0BqAqtVhqF9a; Mon, 8 Mar 2021 11:50:14 -0800 (PST)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2095.outbound.protection.outlook.com [40.107.223.95]) (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 D48523A167B; Mon, 8 Mar 2021 11:50:12 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TbsIBFtlr81CAs2obWH3ix+0lIB+zWHAhadYpdMU+I7JALWS4jwEe+SocfdY31v30wnzqlAHYl4LSQqI5s8aV69EgRxHfEi0/6BlGpIox59sbPlo+5AmcZy2nKIR4IMD7nQdvfDL4uinBWcQ3y5ckPYyx/5n7tA7GpqREvLVx+0WgrPnKYOzi8enf/pubAGYXSucnR3U5a0qFq/alWcnfDhcVK7nR/YKdQDpe/j91e9EY1WveQWQbqvpOTPEyuMfPVFWnAE7BMD5uSe8XsrNpIqpxndN0J8f4z0vkgnQUIKKXMTwB0jbHkN/OSCiE12IT6wRkm4frNCoWqNllabTsA==
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=dAKbQGjJLzheKZxEtyeop93d8WF3R9TSHbMTh7xyEEg=; b=RIW0H0TvZQlXjJ2GhHbROfGqvBe07x2wDFIfiEhR7Ar6qW2/mrJzjwFyMDbswjpM5OIy1Ir4Q8CmrpWHEnn78oDxIDEBjkr2GM9KK7aV/ojB0mTQsB2OL5uP3LvcCjPoTGs5C5RkqwTiafKoK6eBkJdUa0KU7i1kRoZrN48Iwl2KlANcmFK6veZz/jihWMCIjQATzCeBfBgYnJZmFuLlAnBDhFuLwAFMY4EJfNOCUJinHdCtByGuErsZCiUzJs73ze6XCiD8XjaI/Fu5nGAeRJwVI1LcUU3SwfzTBUo2QStHeHlZzNCbWvPEKiyDuD9ujLG6sy+REQrP3UrBbu0CcA==
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=dAKbQGjJLzheKZxEtyeop93d8WF3R9TSHbMTh7xyEEg=; b=NEbrxnTbvbB7GATwGJYCWjItCPmMXkpHPLPP0uUExstiHZ8l/CmCh1n0fYtYvdeMGhlsGIVJOKc78mADGvvekI0ryp9ccS3FgwG/R+b+VjyzxCxcxOipNZ6v+CT0IOwK5eW9/nOQf5YMWBKZ1NA41p+6jvXDlgnYtGeO3/A6VNU=
Received: from MWHPR08MB3520.namprd08.prod.outlook.com (2603:10b6:301:61::15) by MWHPR08MB2846.namprd08.prod.outlook.com (2603:10b6:300:c6::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.23; Mon, 8 Mar 2021 19:50:09 +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.3912.027; Mon, 8 Mar 2021 19:50:09 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bess-evpn-proxy-arp-nd@ietf.org" <draft-ietf-bess-evpn-proxy-arp-nd@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
Thread-Index: AQHW7viwqstDbgs750yiHvjCrwCKYKp6r5x5
Date: Mon, 08 Mar 2021 19:50:09 +0000
Message-ID: <MWHPR08MB35200D0B92E02A744F1AB683F7939@MWHPR08MB3520.namprd08.prod.outlook.com>
References: <161112548105.6186.14010899890751165417@ietfa.amsl.com>
In-Reply-To: <161112548105.6186.14010899890751165417@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [80.31.183.184]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 6665cf02-9cf2-4b99-1885-08d8e26b612b
x-ms-traffictypediagnostic: MWHPR08MB2846:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MWHPR08MB28468FF638459DD8F309855AF7939@MWHPR08MB2846.namprd08.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sd7/QGpux9fU64ilp89xxJTC3nGEdH+8xjWoWy/mtCs3ofecmLGMw/pZG+o6ayJund4jgmG0STEHkKfO74c97qvoMd+nDHgzRmjaCpVwh6dDmm5WvDuXufsi7ov7mlIF7K1UqAjFXIwWIMBLrnd5jF56iWU9HpyqCsNwEJukF5Qsu9NYdPYojLkx16D5fXNPMKsWshmXOQdIJyTTp6ProF7yZmcv81MB/SpCMkZTk1L5mbhTsc1BA3HiBLlSWlB2e6qLulM10NbWuZMW/lYEfj1gtmB9zt1Vy47En28ojW+3KdHNL/NYODz/HGZjWRsU4WSK3fPiMMHo8nKHd2ThcLn6C25It+27lcRsNsUuLTOoyoTLFkXSoQlOoMVUf1Xcdk4y1/1gz3OUOnYoDMHBsERCA/cbtqf5uh6A1xQEN3xJxu+f2LNSyLh/1bN3HeyAvnNQefsPiGqDW+KTxRstRTiAAog8A8cpnefKU/e1em1rzjzBFIhwH3FRuiX/EEds+Ecv+C4YOX60JVWZcRaW4/6cGRKxzDBuDHPabjt7E5dW6qScZRKaAZIVrNJkd1J/UdqfxUxdnhtVI4Eae9gx8dnoesPxWV6CU56qJvhT4Rs=
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)(346002)(39860400002)(396003)(136003)(376002)(366004)(53546011)(9326002)(6506007)(30864003)(33656002)(86362001)(2906002)(66446008)(66556008)(55016002)(316002)(9686003)(7696005)(66476007)(966005)(83380400001)(64756008)(8676002)(110136005)(186003)(66946007)(107886003)(66574015)(71200400001)(5660300002)(478600001)(52536014)(26005)(8936002)(91956017)(76116006)(54906003)(4326008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 1Bimyh445APD3HxpNJLsDUgBlfdfVfA3++f+B9gIKn5mWImNnvLlIqNGM0F7vG9mgVDxJeIAIMZr7KPntEkPesjikh8ZNByVj3nZurmXkNvDRgdwB3XM4iUyd83hcwOUKmSWTgrPgokQJnfrE5gHxI07I/nNUCXV5bTDWhCVkD9jBHvbFCv2bvxGwUaBnSpplCtAZ7gkX8OU1qLTg6NOUwFZr6xKbOGMWFPUjeFKEzDhSl4gFO9TnDb28z+k27FrNnlBa5d6PhfUMyD7WoNO5s+33wDWvimxJp/YiQaiB6Zn5Bry5TYl0pPWGStRZaflkGzXt0rONDAoDPdpOPU1X8fc4jEH7G5Gb2G2FNTAB1KEccx5aq2v5He6VHr82KfZuACWo6rVs/+4+iG+c/0Zc+HQNMdykWiJPBkab8nwUecniWQlfysZjkfJyA2408h7jorn5Rg0bfQeG990ZrFiRVWsXmNDFlrK79VrUQYPmwGjAkiLuAw6YbsF2JJY3Yf6sUqnFNkppt0pUCaWOWmuB89QACBZt9LiRAwTQHvg0hMYHRRoLdtn5Jsx4nUwiX4H+hTOo+OWXlssmfv9TNX2nhjx3iQiaT0myrdYYLZ8MlFwezJdL1fEjEwVre00EunNlCDtPHd+AIyKI4Zp9w/k8Z/bnNfFeIAqH1rJaTZIhP4vpKaeggSZKiLMQLvbg9aw/VS2wDQ4gXey0cgbJ+Pn6N0oUoRKwvaef/onNW4gWg4g/ZLSbENZZTNlnBMlyPzmKvnA/0k+qkoFhKNYl2CiYpxuv4v1LIuz3d01uwSd70KQMbQulclhLIAnf3pe50eY2cwYn5s4PvA1R4qOzHBfyLGIpXy9aBZ8Szdt2O5IWyR9JPBQKpf+ZUlDk5gemAt3e81D46rv94UVdg/HnhnQDubCLiENXa6AmcnH9pIPXXG6BMJvgMTpvXkK92+dGegTXkR78K+9VBL0wxY1FFIl1U0pRxK2+tIrJGxij72rbLDi9rzm38wX+JtLXiza1UdUe+JARDw6KOSxWdJuf5UCKB3sP4BxnwbNMTmWzTRSPEjojUTg+sapqrNw1v9SsMI0qee901EBlw7FjEE3jS8wBaQzaymbo5prMd5MNhVTaRCRn8iRl+tNmHzgQq2WfHUbVazsDUBcyBH44QACAfHi5ADMgcZCSQT+uLrsf79rlT/UL7Pg7Eq41rEwg2QJRYJ0mygt1V6u65cp0WqV3ni/y4DrcDmAF+37IbAkbNi0iInQBrfkQRIVy6s2p4QUbj65D8c1/kBhJKF09GbbuVmWTri5+6FxKphch4u2QqCUw9n0+Kc7WEtwWqNcX3tAGFjTooxyYl7PsibKUxL3eWXOog==
Content-Type: multipart/alternative; boundary="_000_MWHPR08MB35200D0B92E02A744F1AB683F7939MWHPR08MB3520namp_"
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: 6665cf02-9cf2-4b99-1885-08d8e26b612b
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2021 19:50:09.1358 (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: 6bX/Qfh1QqRY5MhqHyPqqCtnI746PNpyk3t8yUyL8IymUP0YzfvespQVVENIspMssSKM3HbM2J+yJ0dyz2pqMQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2846
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/V97AurKrwF0wg7xGSd7VcL0SkhM>
Subject: Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 19:50:24 -0000
Hi Benjamin, Thanks for the thorough review. Please see my comments in-line with [jorge]. I’ll incorporate the changes in the next version. Thx Jorge ------------------------------------------------------------------------------------- From: Benjamin Kaduk via Datatracker <noreply@ietf.org> Date: Wednesday, January 20, 2021 at 7:51 AM To: The IESG <iesg@ietf.org> Cc: draft-ietf-bess-evpn-proxy-arp-nd@ietf.org <draft-ietf-bess-evpn-proxy-arp-nd@ietf.org>, bess-chairs@ietf.org <bess-chairs@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com>, Bocci, Matthew (Nokia - GB) <matthew.bocci@nokia.com> Subject: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-proxy-arp-nd-11: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-evpn-proxy-arp-nd-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this clear and well-written document; the effort that went into presenting the information really comes through. I basically just have editorial nits as comments, with a few substantive notes on the security considerations section. [jorge] thanks! For most of the document I was convinced that I understood this point, but then Section 5.5 led me to question myself: in the "static provisioning" learning mode, is the IP->MAC mapping configured only at the PE that the CE using those addresses will attach to, or at all PEs in the BD? I can follow up out-of-band with some editorial suggestions either way. [jorge] I added this in section 3.1 to clarify, let me know if you prefer different wording: “Static entries are provisioned from the management plane. A static entry is configured on the PE attached to the host using the IP address in that entry” Abstract (and Introduction) This document describes the EVPN Proxy-ARP/ND function, augmented by the capability of the ARP/ND Extended Community [I-D.ietf-bess-evpn-na-flags]. From that perspective this document updates [RFC7432]. [...] nit: this paragraph doesn't do very much to tell me what the nature of the update is. If it's just to clarify how all the pieces fit together we might add a clause at the end ", to provide more comprehensive documentation of the operation of the system as a whole" or similar. (Some parts of it might also have worked as an RFC 2026 Applicability Statement, but it is probably not worth the trouble of trying to rework things at this stage, especially since what we have is already nicely laid out.) [jorge] ok, I added: “From that perspective this document updates RFC7432 to provide more comprehensive documentation of the operation of the Proxy-ARP/ND function” Section 3 There's a lot of information packed into the Figure, and the surrounding text does a great job describing it. Thank you! The Proxy-ARP/ND function can be structured in six sub-functions or procedures: (editorial) the text from here to the end of the section feels distinct from the explanation of the figure; it might benefit from getting promoted into a (sub)section of its own. [jorge] done! Thanks. Section 3.1 An entry MAY associate a configured static IP to a list of potential MACs, i.e. IP1->(MAC1,MAC2..MACN). When there is more than one MAC in the list of allowed MACs, the PE will not advertise any IP->MAC in EVPN until a local ARP/NA message or any other frame is received from the CE. [...] (nit) would it be better to phrase this as "until a frame (including local ARP/NA message) is received from the CE"? That seems to emphasize that any traffic will do, even if we expect that traffic to be ARP/NA. [jorge] done. Section 3.1.1 o Hosts build a Default Router List based on the received RAs and NAs with R Flag=1. Each cache entry has an IsRouter flag, which must be set based on the R Flag in the received NAs. A host can nit: maybe "must be set for received RAs and is set based on the R flag [...]" [jorge] added: “Each cache entry has an IsRouter flag, which must be set for received RAs and is set based on the R flag in the received NAs” Section 3.6 The distributed nature of EVPN and Proxy-ARP/ND allows the easy detection of duplicated IPs in the network, in a similar way to the MAC duplication function supported by [RFC7432] for MAC addresses. nit: is this "MAC duplication detection function"? [jorge] yes, added “detection” IP1->MAC2 in the Proxy-ARP/ND table. Static IP->MAC entries, that is, locally provisioned or EVPN-learned entries (with I=1 in the ARP/ND Extended Community), are not subject to this procedure. [...] nit: I think the sentence is better without the parentheses, since the presence of I=1 is critical for correct functioning and not intrinsic to the entries being EVPN-learned. [jorge] good point, removed. 1. The entry in duplicate detected state cannot be updated with new dynamic or EVPN-learned entries for the same IP. The operator MAY override the entry though with a static IP->MAC. nit: commas before and after "though". [jorge] added 2. The PE SHOULD alert the operator and stop responding ARP/NS for the duplicate IP until a corrective action is taken. nit: "stop responding to". [jorge] fixed for IP1. Since the AS-MAC is a managed MAC address known by all the PEs in the EVI, all the PEs MAY apply filters to drop nit: this seems to be the first time that we talk about the AS-MAC being a managed address and being known to all PEs in the EVI; it might be worth rewording in light of that or mentioning that in the definition of AS-MAC. [jorge] added this in the definition: “AS-MAC: Anti-spoofing MAC. It is a especial MAC configured on all the PEs attached to the same BD and used for the Duplicate IP Detection procedures.” Section 5.2 This scenario minimizes flooding while enabling dynamic learning of IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of the EVPN PEs, so that the PEs intercept and respond to CE requests. nit: from context it seems like the "dynamic learning" here refers to the EVPN-learned entries, but in §3.1 we reserved the term "dynamic" for entries learned by local snooping. Since the next paragraph talks about snooping as an optional addition, we run into semi-conflicting usage of the term "dynamic". I would suggest (assuming the above is correct) rewording this to "while enabling learning of IP->MAC entries over the EVPN" or similar. [jorge] you are right that 5.2 is confusing. I changed it to: “This scenario minimizes flooding while enabling dynamic learning of IP->MAC entries. The Proxy-ARP/ND function is enabled in the BDs of the EVPN PEs, so that the PEs snoop ARP/ND messages issued by the CEs and respond to CE ARP-requests/NS messages. PEs will flood requests if the entry is not in their Proxy table. Any unknown source MAC->IP entries will be learned and advertised in EVPN, and traffic to unknown entries is discarded at the ingress PE.” Section 5.5 These rules are often called port security. Port security summarizes different operational steps that limit the access to the IXP-LAN, to the customer router and controls the kind of traffic that the routers are allowed to exchange (e.g., Ethernet, nit: this list lacks parallel structure; going with "limit the access to the IXP-LAN and the customer router, and controls the kind of traffic" would be okay. [jorge] done. Section 6 I think it would be useful to reiterate that the security considerations of RFC 7432 and draft-ietf-bess-evpn-na-flags continue to apply (in addition to the useful text that is already present here). I guess ARP and IPv6 ND are arguably also applicable (AFAICT the security properties of the proxied scheme are very similar to those of native usage, in an environment that already has to trust the PEs and provider network that supply the EVPN to the same extent that one would otherwise trust an IP router). [jorge] agreed. Added. It would also be my personal preference (though I do not insist upon it) to note that EVPN does not inherently provide cryptographic protection (including confidentiality protection) despite the word "private" appearing in the name. (This is really a topic that should be addressed via a long-term IETF-wide shift towards just "virtual network" instead of "virtual private network", but I try to mention it when I can so as to socialize the idea.) [jorge] that sounds good to me. Added: “Note that EVPN does not inherently provide cryptographic protection (including confidentiality protection).” I appreciate the discussion (earlier in the document) of the use of dummy MACs to suppress unknown ARP-Request/NS flooding, added in response to the opsdir review. Is it worth calling out the security/availability considerations of that technique from this section? ("No" is a perfectly fine answer.) [jorge] not sure what you mean by the use of “dummy MACs”? Is it too banal to repeat that configuring the unicast-forwarding and/or flooding sub-functions to be disabled risks blocking service for a CE if the static configuration is broken? [jorge] sure, I added: “While the unicast-forward and/or flooding suppression sub-functions provide an added security mechanism for the BD, they can also increase the risk of blocking the service for a CE if the EVPN PEs cannot provide the ARP/ND resolution that the CE needs.” The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. [...] Are these DoS attacks described anywhere that we might reference for further reading? ("No" is a perfectly fine answer.) [jorge] It’s a generic statement, I fail to know what references to provide. If you have suggestions I’d be glad to add them. When EVPN and its associated Proxy-ARP/ND function are used in IXP networks, they provide ARP/ND security and mitigation. IXPs MUST If I understand correctly, this security/mitigation is provided in the face of malicious CE devices, but the system still requires that PEs are trusted and does not provide cryptographic or independently verifiable assurances of correct IP->MAC bindings. I would suggest being explicit about the threat that is being protected against, since by itself the term "security" is so vague so as to become almost meaningless. [jorge] sure, I added: “When EVPN and its associated Proxy-ARP/ND function are used in IXP networks, they provide ARP/ND security and mitigation against attacks from malicious CEs” For example, IXPs should disable all unneeded control protocols, and block unwanted protocols from CEs so that only IPv4, ARP and IPv6 I suggest the parenthetical "so that (for example) only"; we do not really have much reason to preclude other ethertypes if desired by the IXP. [jorge] added.
- [bess] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [bess] Benjamin Kaduk's No Objection on draft… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's No Objection on draft… Rabadan, Jorge (Nokia - US/Mountain View)