Operational Aspects of Proxy-ARP/ND in EVPN Networks
draft-ietf-bess-evpn-proxy-arp-nd-09
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9161.
|
|
---|---|---|---|
Authors | Jorge Rabadan , Senthil Sathappan , Kiran Nagaraj , Greg Hankins , Thomas King | ||
Last updated | 2020-12-15 (Latest revision 2020-10-12) | ||
Replaces | draft-snr-bess-evpn-proxy-arp-nd | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
by Russ Housley
Almost ready
SECDIR Last Call review
by Russ Housley
Has issues
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Matthew Bocci | ||
Shepherd write-up | Show Last changed 2019-07-09 | ||
IESG | IESG state | Became RFC 9161 (Proposed Standard) | |
Consensus boilerplate | Yes | ||
Telechat date | (None) | ||
Responsible AD | Martin Vigoureux | ||
Send notices to | Matthew Bocci <matthew.bocci@nokia.com> | ||
IANA | IANA review state | IANA OK - No Actions Needed |
draft-ietf-bess-evpn-proxy-arp-nd-09
"All Static Provisioning with Proxy-ARP/ND" is the predominant scenario for IXPs. In addition to the "All Static Provisioning" behavior, in IXP networks it is recommended to configure the Reply Sub-Function to 'discard' ARP-Requests/NS messages with unrecognized options. At IXPs, customers usually follow a certain operational life-cycle. For each step of the operational life-cycle specific operational procedures are executed. The following describes the operational procedures that are needed to guarantee port security throughout the life-cycle of a customer with focus on EVPN features: 1. A new customer is connected the first time to the IXP: Before the connection between the customer router and the IXP-LAN is activated, the MAC of the router is white-listed on the IXP's switch port. All other MAC addresses are blocked. Pre-defined IPv4 and IPv6 addresses of the IXP's peering network space are configured at the customer router. The IP->MAC static entries (IPv4 and IPv6) are configured in the management system of the IXP for the customer's port in order to support Proxy-ARP/ND. In case a customer uses multiple ports aggregated to a single logical port (LAG) some vendors randomly select the MAC address of the LAG from the different MAC addresses assigned to the ports. In this case the static entry will be used associated to a list of allowed MACs. 2. Replacement of customer router: If a customer router is about to be replaced, the new MAC address(es) must be installed in the management system besides the MAC address(es) of the currently connected router. This allows the customer to replace the router without any active involvement of the IXP operator. For this, static entries are also used. After the replacement takes place, the MAC address(es) of the replaced router can be removed. Rabadan, et al. Expires April 12, 2021 [Page 19] Internet-Draft EVPN Proxy-ARP/ND October 2020 3. Decommissioning a customer router If a customer router is decommissioned, the router is disconnected from the IXP PE. Right after that, the MAC address(es) of the router and IP->MAC bindings can be removed from the management system. 6.6. Deployment Scenarios in DCs DCs normally have different requirements than IXPs in terms of Proxy- ARP/ND. Some differences are listed below: a. The required mobility in virtualized DCs makes the "Dynamic Learning" or "Hybrid Dynamic and Static Provisioning" models more appropriate than the "All Static Provisioning" model. b. IPv6 'anycast' may be required in DCs, while it is not a requirement in IXP networks. Therefore if the DC needs IPv6 'anycast' it will be explicitly enabled in the Proxy-ND function, hence the Proxy-ND sub-functions modified accordingly. For instance, if IPv6 'anycast' is enabled in the Proxy-ND function, Duplicate IP Detection must be disabled. c. DCs may require special options on ARP/ND as opposed to the Address Resolution function, which is the only one typically required in IXPs. Based on that, the Reply Sub-function may be modified to forward or discard unknown options. 7. Security Considerations The procedures in this document reduce the amount of ARP/ND message flooding, which in itself provides a protection to "slow path" software processors of routers and Tenant Systems in large BDs. The ARP/ND requests that are replied by the Proxy-ARP/ND function (hence not flooded) are normally targeted to existing hosts in the BD. ARP/ ND requests targeted to absent hosts are still normally flooded, however the suppression of Unknown ARP-Requests and NS messages described in Section 4.5. can provide an additional level of security against ARP-Requests/NS messages issued to non-existing hosts. 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 4.6 will definitely protect the BD against ARP/ND spoofing. When EVPN and its associated Proxy-ARP/ND function are used in IXP networks, they provide ARP/ND security and mitigation. IXPs MUST still employ additional security mechanisms that protect the peering Rabadan, et al. Expires April 12, 2021 [Page 20] Internet-Draft EVPN Proxy-ARP/ND October 2020 network and SHOULD follow established BCPs such as the ones described in [Euro-IX-BCP]. For example, IXPs should disable all unneeded control protocols, and block unwanted protocols from CEs so that only IPv4, ARP and IPv6 Ethertypes are permitted on the peering network. In addition, port security features and ACLs can provide an additional level of security. 8. IANA Considerations No IANA considerations. 9. Acknowledgments The authors want to thank Ranganathan Boovaraghavan, Sriram Venkateswaran, Manish Krishnan, Seshagiri Venugopal, Tony Przygienda, Robert Raszuk and Iftekhar Hussain for their review and contributions. Thank you to Oliver Knapp as well, for his detailed review. 10. Contributors In addition to the authors listed on the front page, the following co-authors have also contributed to this document: Wim Henderickx Nokia Daniel Melzer DE-CIX Management GmbH Erik Nordmark Zededa 11. References 11.1. Normative References [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>. Rabadan, et al. Expires April 12, 2021 [Page 21] Internet-Draft EVPN Proxy-ARP/ND October 2020 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <https://www.rfc-editor.org/info/rfc826>. [RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, DOI 10.17487/RFC6820, January 2013, <https://www.rfc-editor.org/info/rfc6820>. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>. [RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, <https://www.rfc-editor.org/info/rfc5227>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [I-D.ietf-bess-evpn-na-flags] Rabadan, J., Sathappan, S., Nagaraj, K., and W. Lin, "Propagation of ARP/ND Flags in EVPN", draft-ietf-bess- evpn-na-flags-07 (work in progress), October 2020. 11.2. Informative References [ARP-Sponge] N., W. M. A. S., "Effects of IPv4 and IPv6 address resolution on AMS-IX and the ARP Sponge", July 2009. [Euro-IX-BCP] Euro-IX, "European Internet Exchange Association Best Practises". Rabadan, et al. Expires April 12, 2021 [Page 22] Internet-Draft EVPN Proxy-ARP/ND October 2020 Authors' Addresses Jorge Rabadan (editor) Nokia 777 Middlefield Road Mountain View, CA 94043 USA Email: jorge.rabadan@nokia.com Senthil Sathappan Nokia 701 E. Middlefield Road Mountain View, CA 94043 USA Email: senthil.sathappan@nokia.com Kiran Nagaraj Nokia 701 E. Middlefield Road Mountain View, CA 94043 USA Email: kiran.nagaraj@nokia.com Greg Hankins Nokia Email: greg.hankins@nokia.com Thomas King DE-CIX Management GmbH Email: thomas.king@de-cix.net Rabadan, et al. Expires April 12, 2021 [Page 23]