idnits 2.17.00 (12 Aug 2021) /tmp/idnits30280/draft-surajk-evpn-access-security-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 476: '... The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 12, 2017) is 1955 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4364' is mentioned on line 476, but not defined == Unused Reference: 'RFC2131' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'EVPN-IGMP' is defined on line 529, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 7209 -- Possible downref: Non-RFC (?) normative reference: ref. 'EVPN-IGMP' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group S. Kumar 3 Internet-Draft D. Kakrania 4 Intended status: Standards Track V. Duna 5 Expires: July 16, 2017 Juniper Networks 6 January 12, 2017 8 EVPN ACCESS SECURITY 9 draft-surajk-evpn-access-security-00 11 Abstract 13 The draft defines a new BGP EVPN route message for syncing DHCP 14 packet contents as well as snoop entry among PEs in an Ethernet 15 Segment (ES). The snoop entry is required to implement Dynamic ARP 16 inspection (DAI), IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor 17 Discovery Inspection (NDI) access security features. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 16, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Access Security Features . . . . . . . . . . . . . . . . . . 3 56 3.1. DHCP snooping . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Dynamic ARP inspection (DAI) . . . . . . . . . . . . . . 3 58 3.3. IP Source Guard (IPSGv4/IPSGv6) . . . . . . . . . . . . . 4 59 3.4. IPv6 Neighbor Discovery Inspection (NDI) . . . . . . . . 4 60 4. DHCP Snooping Database . . . . . . . . . . . . . . . . . . . 4 61 4.1. CE Connected to Single PE . . . . . . . . . . . . . . . . 5 62 4.2. CE Connected to Multiple PEs . . . . . . . . . . . . . . 5 63 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Centralized Mode . . . . . . . . . . . . . . . . . . . . 7 65 5.2. Distributed Mode . . . . . . . . . . . . . . . . . . . . 7 66 6. DHCP Snoop Advertisement route . . . . . . . . . . . . . . . 8 67 6.1. Constructing DHCP Snoop Advertisement route . . . . . . . 9 68 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 In EVPN solution where a CE is connected to multiple PEs in All- 76 Active redundancy mode then to support Dynamic ARP inspection (DAI), 77 IP Source Guard (IPSG/IPSGv6) and IPv6 Neighbor Discovery Inspection 78 (NDI) access security features, each PE in the ES needs to build an 79 identical snoop database. This requires exchanging DHCP packet 80 relevant contents as well as complete snoop entry among PEs in the 81 ES. The draft defines a new BGP EVPN route for this. 83 2. Terminology 85 CE: Customer Edge device, e.g., a host, router, or switch. 87 PE: Provider Edge device e.g switch or router. 89 EVI: An EVPN instance spanning the Provider Edge (PE) devices 90 participating in that EVPN. 92 Ethernet Segment (ES): When a customer site (device or network) is 93 connected to one or more PEs via a set of Ethernet links, then that 94 set of links is referred to as an 'Ethernet segment'. 96 Ethernet Segment Identifier (ESI): A unique non-zero identifier that 97 identifies an Ethernet segment is called an 'Ethernet Segment 98 Identifier' 100 Ethernet Tag ID (ETAG ID): An Ethernet tag identifies a particular 101 broadcast domain, e.g., a VLAN. An EVPN instance consists of one or 102 more broadcast domains. 104 All-Active Redundancy Mode: When all PEs attached to an Ethernet 105 segment are allowed to forward known unicast traffic to/from that 106 Ethernet segment for a given VLAN, then the Ethernet segment is 107 defined to be operating in All-Active redundancy mode. 109 3. Access Security Features 111 3.1. DHCP snooping 113 DHCP snooping enables the switch (PE), to intercept DHCP messages 114 exchanged between untrusted host (DHCP client) and trusted DHCP 115 server and build an entry for untrusted host in snooping database. A 116 switch builds a DHCP snooping entry by extracting relevant 117 information from snooped DHCP packets. Similarly, a switch builds a 118 DHCPv6 snooping entry by extracting relevant information from snooped 119 DHCPv6 packets. The snoop entry holds the following information 121 1- Untrusted host MAC address (mac) 123 2- Untrusted host IP address (ip/ip6) 125 3- The interface(port) on which untrusted host is connected (intf) 127 4- Vlan in which untrusted host resides (vlan) 129 The entry [mac, ip, intf, vlan] is used for DAI, IPSGv4 features 130 Similarly, [mac, ip6, intf, vlan] is used for IPSGv6 and NDI 131 features. 133 3.2. Dynamic ARP inspection (DAI) 135 Dynamic ARP inspection (DAI) protects switching devices against ARP 136 spoofing. 138 DAI inspects Address Resolution Protocol (ARP) packets on the LAN and 139 uses the information in the DHCP snooping database on the switch to 140 validate ARP packets and to protect against ARP spoofing (also known 141 as ARP poisoning or ARP cache poisoning). ARP requests and replies 142 are compared against entries in the DHCP snooping database, and 143 filtering decisions are made based on the results of those 144 comparisons. When an attacker tries to use a forged ARP packet to 145 spoof an address, the switch checks the sender IP and MAC source 146 addresses in a ARP packet sent from a host attached to an untrusted 147 access interface on the switch. The switch searches an entry [mac, 148 ipv4, intf, vlan] in the snooping database. If the entry is not 149 found in DHCP snooping database, the packet is dropped. 151 3.3. IP Source Guard (IPSGv4/IPSGv6) 153 Ethernet LAN switches are vulnerable to attacks that involve spoofing 154 (forging) of source IP addresses or source MAC addresses. These 155 spoofed packets are sent from hosts connected to untrusted access 156 interfaces on the switch. 158 IP source guard checks the IP source address and MAC source address 159 in a packet sent from a host attached to an untrusted access 160 interface on the switch. The switch searches for the entry [mac, ip/ 161 ipv6, intf, vlan] in the snooping database. If the entry is not 162 found in DHCP snooping database, the packet is dropped. 164 3.4. IPv6 Neighbor Discovery Inspection (NDI) 166 IPv6 Neighbor Discovery Inspection protects switching devices against 167 ND spoofing. 169 NDI inspects Neighbor Discovery packets on the LAN and uses the 170 information in the DHCPv6 snooping database on the switch to validate 171 ND packets and to protect against ND spoofing. ND packets are 172 compared against entries in the DHCPv6 snooping database, and 173 filtering decisions are made based on the results of those 174 comparisons. When an attacker tries to use a forged ND packet to 175 spoof an IPv6 address, the switch checks the IPv6 source address and 176 MAC source address in a ND packet sent from a host attached to an 177 untrusted access interface on the switch. The switch searches the 178 entry [mac, ip6, intf, vlan] in the DHCPv6 snooping database. If the 179 entry is not found in database, the packet is dropped. 181 4. DHCP Snooping Database 183 A snoop database is a place holder of snoop entries. A DHCPv4 snoop 184 database contains DHCPv4 snoop entries. Similarly, a DHCPv6 snoop 185 database contains DHCPv6 entries. 187 A Switch (PE) does not need the complete DHCP packet to build 188 snooping entry. The PE needs some relevant DHCP packet contents as 189 mentioned in section Section 6.1 to build a snoop entry. 191 4.1. CE Connected to Single PE 193 +----+ +----+ +-----+ 194 | CE1|---------------| PE |----------------| CE2 | 195 +----+ +----+ +-----+ 197 Figure 1 199 The basic process of DHCP snooping database building consists of the 200 following steps. These steps are mentioned here for better 201 understanding of the document. The scope of document is not to 202 explain complete snooping mechanism. 204 1. The host (CE1) sends a DHCPDISCOVER packet to request an IP 205 address. 207 2. The PE forwards the packet to the DHCP server (CE2). 209 3. The CE2 sends a DHCPOFFER packet to offer an address. If the 210 DHCPOFFER packet is from a trusted interface, the switching device 211 forwards the packet to the DHCP client. 213 4. The CE1 sends a DHCPREQUEST packet to accept the IP address. The 214 PE adds an [mac, ip, intf, vlan] entry to the database. The entry is 215 considered a placeholder until a DHCPACK packet is received from the 216 server. Until then, the IP address could still be assigned to some 217 other host. 219 5. The CE2 sends a DHCPACK packet to assign the IP address or a 220 DHCPNAK packet to deny the address request. 222 6. The PE updates the DHCP snooping database according to the type 223 of packet received. 225 7. If the switching device receives a DHCPACK packet, it updates 226 lease information for the [mac, ip, intf, vlan] in its database. The 227 entry is deleted upon expiration of lease time. 229 8. If the PE receives a DHCPNACK packet, it deletes the placeholder. 231 4.2. CE Connected to Multiple PEs 232 +--------------+ 233 | | 234 +----+ | | +----+ +----+ 235 | | | | | |---| CE2| Server 236 /| PE1| | IP/MPLS | | PE5| +----+ 237 / +----+ | Network | +----+ 238 / | | 239 / +----+ | | 240 +----+/ | | | | 241 Client | CE1|-----| PE2| | | 242 +----+\ +----+ | | 243 \ \ | | 244 \ \ +----+ | | 245 \ \| PE3| | | 246 \ | | | | 247 \ +----+ | | 248 \ +----+ | | 249 \ | PE4| | | 250 \| | | | 251 +----+ | | 252 | | 253 +--------------+ 255 Figure 2 257 In Figure 2, PE1, PE2, PE3 and PE4 are in All-Active Redundancy Mode 258 in an Ethernet Segment. Each PE advertises BGP Ethernet Segment (ES) 259 route for Redundancy group discovery and also for Designated 260 Forwarder (DF) election. Each PE router connected to an Ethernet 261 Segment, advertises a BGP Ethernet Segment (ES) route that consists 262 of an ESI and ES-Import extended community. 264 In the above Figure 2, PE1, PE2, PE3 and PE4 have the same ESI value 265 (say ES1). PE1 advertises its ESI value in the Ethernet Segment 266 Route with ES-Import community set to ES1. PE2, PE3, PE4 and PE5 267 will receive that route but PE2, PE3, PE4 will import this route, 268 since they have a matching ESI value. PE5 will not import this route 269 since it does not have matching ESI. This ensures PE2, PE3, PE4 270 knows that PE1 is connected to the same CE1 host. The process is 271 repeated for each PE in the ES. Each PEs in the ES comes to know 272 about all other PEs connected to same CE1 in the same ES. The DF 273 election in an ES is done as specified in [RFC7432] section 8.5. 275 In Figure 2, to build an identical snoop database on each PEs in the 276 ES, each PE needs to extract relevant information from DHCP packets 277 exchanged between Client (CE1) and Server (CE2). But here problem is 278 that all DHCP packets do not go through the same PE. For an example 279 DHCP REQUEST can go through one of the PE say (PE1) and DHCP ACK from 280 server can go through some other PE say (PE2). Since neither PE1 nor 281 PE2 gets all relevant information of DHCP REQUEST and ACK packets, 282 PE1/PE2 cannot build snooping database. 284 5. Solution 286 The draft proposes the two possible solutions for snoop entry [mac, 287 ip, ESI, ETAG ID] creation and synchronization among PEs in an ES in 288 the All-Active Redundancy Mode. Specific realizations and 289 implementation details (state machines or algorithms, etc.) of below 290 solutions are out of the scope of this document. 292 5.1. Centralized Mode 294 The PE acting as DF must be responsible for building the snoop entry 295 and transporting it to all non-DF PE in the ES. The DF PE must also 296 be responsible for withdrawing the entry locally and as well as from 297 all other non-DF remote PEs in the ES. The non-DF PE must neither 298 create nor release the snooping entry by itself. The creation and 299 release of entry is controlled by DF PE in the ES. The PE must use 300 the proposed EVPN DHCP Snoop Advertisement route for exchanging DHCP 301 packet contents as well as complete bindings with other PE in the ES. 303 When a DF PE receives a DHCP packet from CE, it consumes it locally. 304 When a non-DF PE receives a DHCP packet it extracts relevant 305 information from the packet and transport this information to DF PE 306 using newly proposed EVPN DHCP Snoop Advertisement route. The non-DF 307 PE must not consume the DHCP packet locally. 309 The DF PE eventually receives all the information that are required 310 to build snooping entry for the untrusted host. The DF PE builds 311 [mac, ip, ESI, ETAG ID] entry and advertise this to all the non-DF 312 PEs in the ES. When the DF PE releases the entry locally then it 313 advertises the withdrawal of the entry to all the non-DF PEs is the 314 ES. 316 5.2. Distributed Mode 318 In this mode, PE (DF or non-DF) must be responsible for building and 319 releasing entry independently. The DF PE must be responsible for 320 syncing snoop entry when a new non-DF PE joins the same redundancy 321 group. Unlike Centralized mode, in this mode each PE must release 322 the snoop entry upon expiration of lease time. 324 When a PE receives a DHCP packet it extracts relevant information 325 from the packet and transport this information to all other PEs in 326 the ES using newly proposed EVPN DHCP Snoop Advertisement route 327 message. Each PE in the ES eventually receives all the information 328 that are required to build snooping entry for the host. Each PE in 329 the ES builds [mac, ip, ESI, ETAG ID] snoop entry. Each PE in the ES 330 also receives the relevant DHCP release packet content to release the 331 entry independently. 333 6. DHCP Snoop Advertisement route 335 The [RFC7432] defines a new BGP Network Layer Reachability 336 Information (NLRI) called the EVPN NLRI. The format of the EVPN NLRI 337 is as follows: 339 +-----------------------------------+ 340 | Route Type (1 octet) | 341 +-----------------------------------+ 342 | Length (1 octet) | 343 +-----------------------------------+ 344 | Route Type specific (variable) | 345 +-----------------------------------+ 347 Figure 3 349 The EVPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 350 Extensions [RFC4760] with an Address Family Identifier (AFI) of 25 351 (L2VPN) and a Subsequent Address Family Identifier (SAFI) of 70 352 (EVPN). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI 353 attribute contains the EVPN NLRI (encoded as specified above). 355 This [RFC7432] defines the following Route Types: 357 + 1 - Ethernet Auto-Discovery (A-D) route 359 + 2 - MAC/IP Advertisement route 361 + 3 - Inclusive Multicast Ethernet Tag rout 363 + 4 - Ethernet Segment route 365 This draft defines a new route (DHCP Snoop Advertisement route) The 366 PE uses this route message for exchanging DHCP packet contents as 367 well as complete bindings with other PE. 369 + 5 - DHCP Snoop Advertisement route 371 An DHCP Snoop Advertisement route type specific EVPN NLRI consists of 372 the following: 374 +---------------------------------------+ 375 |RD (8 octets) | 376 +---------------------------------------+ 377 |Ethernet Segment Identifier (10 octets)| 378 +---------------------------------------+ 379 | Ethernet Tag ID (4 octets) | 380 +---------------------------------------+ 381 | Packet Flags (1 octet) | 382 +---------------------------------------+ 383 | Packet Type (1 octet) | 384 | XID (4 octets) | 385 +---------------------------------------+ 386 | Lease (4 octets) | 387 +---------------------------------------+ 388 | MAC Address (6 octets) | 389 +---------------------------------------+ 390 | Client IP Address (4, or 16 octets) | 391 +---------------------------------------+ 392 | Client Link local Address (16 octets)| 393 +---------------------------------------+ 394 | Client ID Length (2 octets) | 395 +---------------------------------------+ 396 | Client ID (variable length) | 397 +---------------------------------------+ 399 Figure 4 401 6.1. Constructing DHCP Snoop Advertisement route 403 Packet Flags: 405 Packet Flags is one-byte value in the message. The flags bit is as 406 defined below: 408 0 1 2 3 4 5 6 7 409 +--+--+--+--+--+--+--+--+ 410 | reserved | | | | | 411 +--+--+--+--+--+--+--+--+ 413 Figure 5 415 The least significant bit, bit 7 indicates DHCPv6 contents or DHCPv6 416 snoop entry. This bit is not set for DHCPv4 contents or DHCPv4 snoop 417 entry. 419 The second least significant bit, bit 6 indicates DHCPv6 Rapid commit 420 option is enabled. 422 The third least significant bit, bit 5 indicates DHCPv6 Reply is a 423 NAK. DHCPv6 NAK is extracted from Status Code option of reply 424 packet. 426 The fourth least significant bit, bit 4 indicates DHCP Snoop 427 Advertisement route contains the snoop entry. If this bit is not set 428 this indicate the DHCP Snoop Advertisement route contains DHCP packet 429 contents. 431 The lease significant bits 3, 2,1 and 0 are reserved. 433 Packet Type: 435 Type of packet, e.g DHCPDISCOVER, DHCPOFFER. This is valid only when 436 bit 4 is not set in Packet Flags. 438 XID: 440 Transaction ID, a random number chosen by the client, used by the 441 client and server to associate messages and responses between a 442 client and a server. This is used by the client to match incoming 443 DHCP messages with pending requests. This is valid only when bit 4 444 is not set in Packet Flags. 446 Lease: 448 The period of time IP address is allocated to a client by server. 450 Mac Address: 452 Untrusted Client's source mac address 454 Client IP Address: 456 Untrusted Client's source IP address. This can be IPv4 or IPv6 based 457 on the Packet Type. 459 Client Link Local Address: 461 Untrusted Client's Link Local IPv6 address. This is valid only when 462 bit 7 in Packet Flags is set. 464 Client ID Length: 466 Length of client ID in octets. This is valid only when bit 7 in 467 Packet Flags is set. 469 Client ID: 471 The Client Identifier option is used to carry a DUID. Each DHCP 472 client and server has a DUID. The DUID is DHCP Unique Identifier. 473 This may be used as key to identify the snoop entry. This filed is 474 valid only when bit 7 in Packet Flags is set. 476 The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The 477 value field comprises an IP address of the PE (typically, the 478 loopback address) followed by a number unique to the PE 480 The Ethernet Tag ID: 482 CE's Ethernet tag value (e.g., CE VLAN ID) 484 7. Error Handling 486 The snoop database among PEs in a ES may go out of sync due to some 487 PE going unreachable in the ES. The solution of this problem is out 488 of scope of this draft. 490 In Centralized mode, If DF PE goes down during the process of 491 building snoop entry, it is possible that the untrusted host gets IP 492 address but no snoop entry gets created on any of the PEs in the ES 494 8. Security Considerations 496 Same security considerations as [RFC7432]. 498 9. References 500 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 501 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 502 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 503 2015, . 505 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 506 RFC 2131, DOI 10.17487/RFC2131, March 1997, 507 . 509 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 510 C., and M. Carney, "Dynamic Host Configuration Protocol 511 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 512 2003, . 514 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 515 Henderickx, W., and A. Isaac, "Requirements for Ethernet 516 VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 517 . 519 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 520 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 521 DOI 10.17487/RFC4271, January 2006, 522 . 524 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 525 "Multiprotocol Extensions for BGP-4", RFC 4760, 526 DOI 10.17487/RFC4760, January 2007, 527 . 529 [EVPN-IGMP] 530 Sajassi, A., "https://tools.ietf.org/html/draft-sajassi- 531 bess-evpn-igmp-mld-proxy-01", October 2016. 533 Authors' Addresses 535 Suraj Kumar 536 Juniper Networks 537 Elnath, Juniper Networks 538 Bangalore, Karnataka 560036 539 India 541 EMail: surajk@juniper.net 543 Deepak Kakrania 544 Juniper Networks 545 Elnath, Juniper Networks 546 Bangalore, Karnataka 560036 547 India 549 EMail: dkakrania@juniper.net 551 Vijay Kumar Duna 552 Juniper Networks 553 Elnath, Juniper Networks 554 Bangalore, Karnataka 560036 555 India 557 EMail: dvijay@juniper.net