idnits 2.17.1 draft-vasilenko-6man-nd-mitm-protection-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 draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4862, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: DUPLICATE - Target address has been put into dampening state for the time defined by DuplicateTimer, because SDAD (additional security check) has found duplicate address. The Neighbor Cache entry MUST not be used for traffic forwarding. All NS and NA for this target address SHALL be ignored. DUPLICATE entry SHOULD be deleted when DuplicateTimer expire. (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) (Using the creation date from RFC4862, updated by this document, for RFC5378 checks: 2004-02-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 24, 2020) is 1309 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: 'RFC 4861' is mentioned on line 571, but not defined == Unused Reference: 'RFC8200' is defined on line 753, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-6man-grand-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Maintenance (6man) Working Group E. Vasilenko 2 Internet Draft X. Xiao 3 Updates: 4861, 4862 (if approved) Huawei Technologies 4 Intended status: Standards Track September 24, 2020 5 Expires: March 2021 7 ND improvement to prevent Man-in-the-middle attack 8 draft-vasilenko-6man-nd-mitm-protection-00 10 Abstract 12 Privacy protection is the bigger and bigger concern of many 13 governments and public in general. ND has a few open man-in-the- 14 middle attack vectors. MITM is considered among the most dangerous 15 attack types because of information leakage. This document proposes 16 minimal modifications for ND to protect IPv6 nodes against still 17 open MITM attacks. It could be implemented gradually on any nodes, 18 with the biggest benefit from support on routers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with 47 respect to this document. Code Components extracted from this 48 document must include Simplified BSD License text as described in 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Terminology and pre-requisite..................................2 55 2. Introduction...................................................3 56 3. Security vulnerabilities.......................................4 57 3.1. Rewrite by unsolicited NA.................................4 58 3.2. Be the first and suppress DAD.............................5 59 3.3. Win the race just after DAD...............................6 60 3.4. Implications for off-link nodes...........................6 61 3.5. Speed up by [Gratuitous ND]...............................6 62 4. Solution - Security DAD........................................7 63 4.1. Standards modifications...................................8 64 4.1.1. Modifications to [ND]................................8 65 4.1.2. Modifications to [SLAAC]............................11 66 4.2. Interoperability analysis................................11 67 5. Applicability analysis........................................13 68 5.1. Performance analysis.....................................13 69 5.2. Usability analysis.......................................15 70 5.3. DoS level analysis.......................................16 71 6. Security Considerations.......................................16 72 7. IANA Considerations...........................................16 73 8. References....................................................17 74 8.1. Normative References.....................................17 75 8.2. Informative References...................................18 76 9. Acknowledgments...............................................18 78 1. Terminology and pre-requisite 80 Good knowledge and frequent references to [ND] is assumed. Many 81 terms are inherited from [ND]. Additional terms are introduced: 83 Security DAD: Duplicated Address Detection for security check 84 at the time to write or rewrite for Link Layer Address 86 Intruder: The Node under control of malicious 3rd party 87 Intercepted Victim: The node that could lose the privacy of 88 communication 90 Poisoned Victim: The node that could suffer an unauthorized 91 modification of Neighbor Cache entry; depending on the 92 scenario, it could additionally lose the privacy of 93 communication 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here 101 2. Introduction 103 Cyber Security is one of the biggest concern for many governments: 104 CPNI, HIPAA, FCRA, ECPA in US; GDPR in Europe; CSL in China; DPB in 105 India; Data Protection Act 2018 in the UK. Many regulations have 106 been refreshed or fully redeveloped in recent years. 108 [ND Trust Model] clearly states: "it is desirable to limit the 109 amount of potential damage in the case a node becomes compromised. 110 For example, it might still be acceptable that a compromised node is 111 able to launch a denial-of-service attack, but it is undesirable if 112 it is able to hijack existing connections or establish man-in-the- 113 middle attacks on new connections." 115 The most dangerous and easy way to organize a MITM attack is based 116 on rogue Router Advertisements. Fortunately, rogue router is easy to 117 block on link level device by filtering ICMPv6 message type 134 118 ([RA-Guard]). 120 This document discusses MITM attacks that are more difficult to 121 block, because it is a challenge for link layer to clarify IP 122 address ownership in the plain (distributed) ND architecture. The 123 Internet has open tools to exploit this vulnerability (parasite6, 124 scapy). Attacks are explained in [RIPE-Training] and [IEEE ND 125 Security]. Last reference has very big collection of ND security 126 improvements proposed (50+ solutions), but the problem related to 127 information leakage is still open. 129 This document proposes a simple modification for ND protocol that 130 could be briefly explained as: 132 o Link Layer Address rewrite or initial write for any Neighbor 133 Cache entry MUST be the result of only *multicast* Neighbor 134 Solicitation. Multicast would give a chance for Poisoned Victim 135 to understand that many nodes are going to use the same IP 136 address. 138 o "Security DAD" is mandatory: it SHALL be checked that not more 139 than expected number of NA replies have been received in the 140 response to *multicast* NS. It means that for the majority of 141 cases (default DuplicityLevel): no more than 1 reply. 143 o Any node SHOULD override neighbor cache entry on routers by 144 sending unsolicited NA message after respective node addresses 145 would progress to preferred state. 147 3. Security vulnerabilities 149 3.1. Rewrite by unsolicited NA 151 Let's consider the case when all nodes support [ND] without any 152 extensions. Additionally, assume that Intruder gains access to one 153 node on the link by exploiting some other vulnerability or Intruder 154 has connected his host physically to the link. 156 3 nodes involved in the attack: Intruder (typically a host), 157 Intercepted Victim (typically another host) and Poisoned Victim 158 (typically a router). 160 Neighbor Cache poisoning could be organized (by the procedure below) 161 for any node (host or router). Router is typically the more probable 162 target for the Poisoned Victim role because Intercepted Victim has a 163 high probability to communicate with a Router. 165 The algorithm for attack: 167 o Intruder has many ways to get Intercepted Victim IP address - see 168 [IPv6 Reconnaissance]. The IP address could not be considered 169 hidden information. 171 o Intruder starts sending non-legitimate unicast NA to Poisoned 172 Victim with the "target IP address" of Intercepted Victim, but 173 link layer address of the Intruder, with flags "Override" and 174 "Solicited" set. 176 o If Neighbor Cache entry on Poisoned Victim for reachability to 177 Intercepted Victim is already created (by NS or return traffic - 178 the second one is highly probable for routers) - then the 179 Neighbor Cache entry would be overwritten, because "Override" 180 flag was set. Neighbor cache entry would be put to STALE state at 181 a minimum. If a particular implementation does not track 182 correspondence between NS and NA (not required for state machine 183 in [ND]) then cache entry would be put directly to REACHABLE, 184 because "Solicited" flag was set (section 7.2.5 of [ND]). 186 o Intercepted Victim would not see unicast NA - it would not have 187 chance to recognize "duplicate address". Upstream traffic would 188 flow normally from Intercepted Victim to Poisoned Victim, but 189 downstream traffic would go from Poisoned Victim to Intruder. An 190 Intruder could build a much bigger set of attacks on this 191 basement, for example: it could edit DNS answers and redirect all 192 Intercepted Victim's traffic to itself (both directions). 194 An intruder could send poisoning NA periodically and intercept 195 traffic as soon as it would become available from Poisoned Victim. 196 Initial traffic missed for Intruder could be very small (tens of 197 milliseconds). 199 3.2. Be the first and suppress DAD 201 An Intruder could claim an IP address (and establish communication) 202 while Intercepted Victim is disconnected from the link. Intruder 203 just needs to suppress DAD on itself - Poisoned Victim would never 204 understand that address duplication did happen for the basic [ND] 205 environment. 207 It is a more difficult attack vector for an Intruder, because it 208 needs to wait Intercepted Victim reconnection to the link. 209 It would be difficult to push the router to reinitialize the link. 210 It is potentially possible to influence the host to re-initialize 211 the link by DoS, social engineering or other vulnerability. It is 212 definitely possible to wait till host or router would reload after 213 upgrade (predicted event for host). 214 This attack vector does not make sense for the Intruder under the 215 case of availability attack vector #1. But it could become next 216 primary attack vector if Intruder would be prevented from attack 217 vector #1. Hence, solution should block it too. 219 3.3. Win the race just after DAD 221 The Intruder could be silent and monitor DAD. As soon as the 222 Intruder would see DAD - it would have RetransTimer (1sec by 223 default) to persuade the Poisoned Victim that it is the only one on 224 the link that claims this IP address. The Intruder could pass any 225 multicast or unicast check, because Intercepted Victim would be 226 silent inside the DAD procedure for the basic [ND] environment. 228 It is a more difficult attack vector for an Intruder, but could 229 become primary if other attack vectors would be blocked. See more 230 detailed explanation in previous section. 232 3.4. Implications for off-link nodes 234 All 3 attack vectors above have additional strong vulnerability 235 consequence that make sense to discuss separately: Intruder 236 impersonates Intercepted Victim for traffic from off-link (for 237 connections initiated from any node behind the router). It is the 238 strongest form of 2-way Man-in-the-middle attack. 239 It is not very important for ordinary hosts, because not many remote 240 nodes would try to contact Intercepted Victim. There is the 241 possibility for unlucky exception when admin would come to 242 Intercepted Victim for remote monitoring, then Intruder could ask 243 him for password hash. Admin password is extremely valuable for the 244 Intruder. 245 It is really big leakage of information if Intruder impersonates 246 some important corporate server. Many users of this company would 247 connect to the Intruder. The majority of internal Enterprise 248 applications do not have mutual authentication properly activated. 249 The Intruder would be capable to collect many passwords of this 250 company. It is easy for Intruder to emulate the original application 251 because it could proxy user requests to Intercepted Victim (on the 252 same link) and get proper responses that fully satisfy users. 253 Particular application could have additional vulnerabilities that is 254 easy to exploit in the situation when Intruder is on the server 255 side. 257 3.5. Speed up by [Gratuitous ND] 259 This is not separate attack vector. It is just a little improvement 260 for the Intruder for attack vectors #1. 262 Let's assume that [Gratuitous ND] is implemented at least on 263 Poisoned Victim. 265 [Gratuitous ND] has changed 1st paragraph of [ND] section 7.2.5 - it 266 permits creation of new Neighbor Cache entry on Poisoned Victim, 267 including the situation when there was no NS before and no record 268 has been created in any state. 270 Let's assume that garbage collector deleted stale record for seldom 271 speaking node. Then consider situation of attack vector #1. Basic 272 [ND] pushes the Intruder to send unsolicited NA frequently (up to 273 the rate limit on the Poisoned Victim). In contrast, [Gratuitous ND] 274 permits to create the neighbor cache record by one message much in 275 advance of traffic flow. As a result, Intruder could get all traffic 276 from Poisoned Victim to Intercepted Victim, no any packet would be 277 missed. The improvement for the Intruder is very small - just tens 278 of milliseconds of additional traffic would be intercepted. Attack 279 vector is very effective in both cases. 281 Let's look to the attack vector #2. Intruder had plenty of time to 282 establish communication by normal traffic flow. No additional value 283 from [Gratuitous ND]. 285 Let's look to the attack vector #3. Intruder have RetransTimer (1sec 286 by default) to create a record on Poisoned Victim. Normally 287 generated traffic should be fast enough. No additional value from 288 [Gratuitous ND] again. 290 4. Solution - Security DAD 292 The general idea is very easy to explain: 294 o Link Layer Address rewrite or initial write for any Neighbor 295 Cache entry MUST be the result of only *multicast* Neighbor 296 Solicitation. Multicast would give a chance for Poisoned Victim 297 to understand that many nodes are going to use the same IP 298 address. 300 o "Security DAD" is mandatory: it SHALL be checked that not more 301 than expected number of NA replies have been received in the 302 response to *multicast* NS. It means that for the majority of 303 cases (default DuplicityLevel): no more than 1 reply. 305 o Only fastest NA response to multicast NS SHOULD be used for write 306 or rewrite of LLA. This rule would be useful only for the case of 307 DuplicityLevel more than 1 (not default configuration). It is 308 needed to support many anycast address on the same link. 310 o Any node SHOULD override neighbor cache entry on routers by 311 sending unsolicited NA message after respective node addresses 312 would progress to preferred state. 314 The implementation is more complex, because it needs to be put into 315 [ND] context - see next sections. 317 4.1. Standards modifications 319 4.1.1. Modifications to [ND] 321 * Section 5.1 and section 7.3.2 of [ND], 322 add new state of Neighbor Cache entry: 324 DUPLICATE - Target address has been put into dampening state for the 325 time defined by DuplicateTimer, because SDAD (additional 326 security check) has found duplicate address. The Neighbor 327 Cache entry MUST not be used for traffic forwarding. All NS 328 and NA for this target address SHALL be ignored. DUPLICATE 329 entry SHOULD be deleted when DuplicateTimer expire. 331 * Sections 6.2.1 and 6.3.2 of [ND], 332 add to router and host variables: 334 DuplicateTimer - measured in seconds, dampening time for duplicate 335 IP address discovered by SDAD procedure. It SHOULD be 336 copied from "Reachable Time" advertised by router (on the 337 router itself, it is known as AdvReachableTime - section 338 6.2.1 of [ND]). Future versions of [ND] should be extended 339 to advertise this timer from router in RA messages. 341 * Sections 6.2.1 and 6.3.1 of [ND], 342 add to router and host configurable variables: 344 DuplicityLevel - number of NA responses that is accepted as 345 legitimate for multicast NS solicitation. It permits to 346 proper handling of anycast addresses present on the link if 347 the maximum number of anycast addresses is known in 348 advance. The node MUST have the capability to provision 349 DuplicityLevel on a per-link granularity. 32-bit unsigned 350 integer SHOULD be reserved for this counter. 352 * Section 10 of [ND], add to Node constants: 354 DuplicityLevel 1 (no duplicate addresses permitted) 356 * Section 5.3 (Garbage Collection) of [ND], add at the end: 358 Neighbor Cache entries with DuplicateTimer expired SHOULD be 359 deleted. It is possible to delete entries before timer expiration, 360 if there is a need to free space for new entries. 362 * Section 7.2.2 (Sending NS) of [ND], add at the end: 364 Prepare state machine on every transmission of multicast NS: 366 o Initialize DUPLICITY counter by DuplicityLevel 368 o Restart RetransTimer of this Neighbor Cache entry 370 Do not change RetransTimer for unicast NS - reuse expired one. 372 * Section 7.2.5 (Receipt NA) of [ND], replace at the beginning: 374 This modification is equivalent to [Gratuitous ND]. You could have 375 this change already if [Gratuitous ND] is implemented on your 376 router. 378 OLD TEXT: 380 When a valid Neighbor Advertisement is received (either solicited or 381 unsolicited), the Neighbor Cache is searched for the target's entry. 382 If no entry exists, the advertisement SHOULD be silently discarded. 383 There is no need to create an entry if none exists, since the 384 recipient has apparently not initiated any communication with the 385 target. 387 NEW TEXT: 389 When a valid Neighbor Advertisement is received (either solicited or 390 unsolicited), check first for the target's IP address entry in the 391 Neighbor Cache. 393 If no entry exists on the host, it SHOULD silently discard this 394 advertisement. There is no need to create an entry if none exists, 395 since the recipient has apparently not initiated any communication 396 with the target. 398 If no entry exists on the router, it should additionally check for 399 Target link-layer address option. 400 If the received Neighbor Advertisement does not contain the Target 401 link-layer address option, then the router SHOULD silently discard 402 this advertisement. Else router SHOULD create a new entry for the 403 target address with the link-layer address set to the Target link- 404 layer address option. The neighbor cache entry state MUST be set to 405 STALE. 407 * Section 7.2.5 (Receipt NA) of [ND], add at the end: 409 I. If NA received is inside RetransTimer window, then it is 410 considered as a response to NS (solicited): 412 o If DUPLICITY counter does not yet reach 0: Process NA according 413 to all other rules of this section, except write or rewrite of 414 link layer addresses is permitted only if DUPLICITY is equal to 415 DuplicityLevel (only fastest anycast is used for neighbor 416 reachability cache). Additionally, decrement DUPLICITY. 418 o If DUPLICITY counter is 0: Change Neighbor Cache entry to 419 DUPLICATE state. Clear all packets in the queue related to this 420 target address. Log duplicate address event with target address 421 and both Link Layer addresses (from received NA and from cache 422 entry). Start DuplicateTimer for this Neighbor Cache entry. 424 II. If RetransTimer is expired or Neighbor Cache entry does not 425 exist yet for this target address then NA is considered unsolicited 426 disregard of any flags set. Process NA according to all other rules 427 of this section, except additional check: if processing would need 428 to initial write or rewrite Link Level Address (i.e. any change of 429 LLA) then change Neighbor Cache entry state to INCOMPLETE and 430 initiate *multicast* Neighbor Solicitation process against this 431 target IP address. 433 * Section 7.2.6 (Sending unsolicited NA) of [ND], add at the end: 435 A node SHOULD send Neighbor Advertisement message with Override flag 436 set to the all-routers multicast address after respective address 437 would change state to preferred. 439 * It MAY be added after 4th paragraph of section 5.2 (Conceptual 440 Sending Algorithm) of [ND]: 442 Traffic resolved to be sent through Neighbor Cache entry in 443 DUPLICATE state MUST be dropped. 445 4.1.2. Modifications to [SLAAC] 447 * Neighbor Cache maintenance is pretty much restricted to [ND]. 448 Hence, it is not mandatory to change [SLAAC] - the latter is more 449 concerned on initialization and DAD. One optimization is possible 450 specifically for [Gratuitous ND] environment. It is stated in 451 paragraph 4 of section 5.4.2 [SLAAC] that messages sent in response 452 to multicast announcements should be delayed for random time between 453 0 and MAX_RTR_SOLICITATION_DELAY, but the type of multicast message 454 is mentioned in clear "router advertisement message". It MAY be 455 reasonable to replace it to "any message", because [Gratuitous ND] 456 does send unsolicited NA to all-routers multicast and this document 457 proposes response by NS that could synchronize from all routers. 459 4.2. Interoperability analysis 461 Proposed solution does not need any additional functionality on link 462 layer technology (no layer 2 features needed). 464 It does not block unsolicited NA - Link Local Addresses write or 465 rewrite is still possible, including compatibility to [Gratuitous 466 ND]. 468 [Optimistic DAD] creates possibility for Intruder to intercept 469 RetransTimer (1sec by default) of traffic in the case of attack 470 vector #2 and #3, because optimistic address could transmit traffic 471 without the possibility to override Poisoned Victim neighbor cache - 472 NA should have override flag cleared. [Gratuitous ND] does not 473 change this rule for the good reason: it would be not a good idea to 474 strongly claim address that has not passed DAD check yet. 476 Hence, SDAD would not be activated up to the time the address would 477 progress to preferred, that initiate NA with override flag set. 478 You could disable [Optimistic DAD] if your concern about traffic 479 intercepted for RetransTimer seconds is bigger than your concern of 480 interface initialization delay for the same time. 482 [Gratuitous ND] operates as intended in the combination with 483 [Optimistic DAD]. [Gratuitous ND] is effectively replaced by this 484 document for the case when address is progressed to preferred, 485 because stronger form of unsolicited NA (with override flag set) is 486 proposed. 488 It should be no problem for multi-prefix and multi-homing 489 environment discussed in [Multi-Homing], because Neighbor Cache 490 population does not influence forwarding directions (Destination 491 Cache does). [Gratuitous ND] could create unnecessary states on 492 routers advertising address spaces from different ISP for the case 493 of Provider-aggregatable address space. Mechanism specified in this 494 document would confirm it to REACHABLE state, then it would be 495 probably not used later (freeze in STALE state up to garbage 496 collection). It is very small deficiency originated by [Gratuitous 497 ND] that does not make sense to fix. 499 This document does not create any problem for standard update 500 proposed in [Subnet Model], because determination of "on-link" 501 addresses is on Destination Cache level that Neighbor Cache is not 502 capable to influence. 504 [FCFS SAVI] deep security assistance from L2 switches would not 505 benefit from this document - it is not possible to poison cache in 506 SAVI architecture. It is important to mention that this document 507 would not create any interoperability issue with [FCFS SAVI]. There 508 would be no illegal write or rewrite requests (with duplicate 509 addresses) that SDAD needs to check. 511 The same consequence is under SeND presence: cryptographically 512 protected addresses does not need additional protection, but again 513 current document would not create any interoperability problem by 514 additional Security DAD check. 516 DHCP support is not affected by this document - it is irrelevant how 517 node has got an IP address. Furthermore, it is not important whether 518 it has been done in a legal way - if Intruders would try to hijack 519 traffic of each other - they would be both blocked, because they 520 would create duplicate addresses. 522 [NUD improvement] has the natural synergy with current document, 523 because it converts unicast NS to multicast NS (when neighbor cache 524 state would change to UNREACHABLE) that permits to save on 525 additional multicast NS for SDAD check. 527 SDAD (as well as ordinary DAD) is not fully compatible to anycast IP 528 address. DuplicityLevel permits to properly handle anycast addresses 529 present on a link if the maximum number of anycast addresses is 530 known in advance (see DuplicityLevel variable). 532 Active-Standby clustering solutions (including VRRP) should not be 533 affected by this standard extension, because properly functioning 534 cluster should respond to target IP only from one LLA. If any 535 concern on cluster behavior exist - SDAD could be effectively 536 disabled by setting bigger number for DuplicityLevel. 538 The document proposes minimal changes for ND protocol without 539 changing the basic principles. Moreover, changes in nodes behavior 540 are local - it is not needed to wait for formal standard update - 541 new behavior would be fully compliant to [ND] and [SLAAC], as well 542 as all other extensions mentioned above in this section. 544 5. Applicability analysis 546 5.1. Performance analysis 548 [Gratuitous ND] cache initialization improvement is not affected by 549 this document, because algorithm above assumes immediate check, no 550 need to wait for return traffic to be buffered. 552 Additional Security DAD (with associated multicast solicitation) 553 should happen only for Link Layer Address write or rewrite that 554 ideally should happen only one time for every address. Control Plane 555 load should not be considerably increased. Moreover, in some cases 556 SDAD check coincide with multicast NS that results in no additional 557 messages. See later more detailed analysis of multicast performance 558 for 3 primary scenarios. It has been analyzed per 1 address space, 559 other Global Unicast Addresses or Unique Local Address would have 560 exactly the same calculations. 561 LLA would generate additional multicast traffic that is omitted in 562 calculations. 564 A reminder: according to section 5.1 of [SLAAC] - ordinary DAD has 1 565 multicast check by default (DupAddrDetectTransmits is 1). 567 We could assume that the host would not wait scheduled RA, it would 568 probably initiate RS that would generate multicast RA. 570 1. Host to host communication (general scenario). 571 The basic neighbor reachability detection (by [RFC 4861]) should 572 use one multicast for DAD and one multicast solicitation to 573 discover other node. It is not important for performance analysis 574 that only originating node would check 2-way communication (and 575 would promote cache entry to REACHABLE) as a result of initial 576 multicast solicitation, because other node would record proper 577 LLA too - it would use unicast solicitation later to prove 2-way 578 communication. Hence, this document would generate an additional 579 multicast request per every pair of communicating nodes. 580 Depending on the mesh communication richness between nodes - it 581 could increase multicast traffic from 0 up to 100% (depends on 582 the number of communicating pairs): (2*c*(c-1)+h)/(c*(c-1)+h). 584 2. Router cache population in the basic [ND] scenario. 585 Initial DAD is omitted here, because it was calculated in host- 586 to-host scenario. The host would generate multicast RS and would 587 receive multicast RA. Multicast NS is assumed as a result of one 588 router receiving traffic to a particular host. This document 589 reuses any multicast NS for SDAD, hence performance is not 590 affected: (h*(2*r+1))/(h*(2*r+1))=1. 592 3. Router cache population in the scenario of [Gratuitous ND]. 593 Initial DAD is omitted here, because it was calculated in host- 594 to-host scenario. The host would generate multicast RS and would 595 receive multicast RA. One multicast unsolicited NA is proposed by 596 [Gratuitous ND], it could not be used for SDAD, because it is 597 going to different multicast group (routers). Hence, this 598 document creates 33% more multicast traffic for 1 router on this 599 link, 40% more multicast for 2 routers on this link, up to 50% 600 more multicast for many routers: (h*(2*r+1+r))/(h*(2*r+1)). 602 It makes sense to remind, that normal neighbor cache entry 603 refreshment should not generate additional multicast, because entry 604 refreshment is assumed in unicast to known MAC address - see PROBE 605 definition in [ND] section 5.1. The Garbage collector may completely 606 delete long stale neighbor cache entry (good example of such host is 607 a printer), then multicast would be needed anyway - this document 608 does not increase multicast for that case. 610 5.2. Usability analysis 612 Host's Unsolicited NA (after address would go to preferred state) is 613 proposed only in the direction of all-routers multicast (router to 614 host communication). It would invoke SDAD check and reveal 615 duplicity. 616 Attack vector #2 has been left unprotected by this document for the 617 case of host to host communication. MITM for traffic inside link is 618 still possible, because SDAD check is useless at the time when 619 Intercepted Victim is not connected yet to the link, but later would 620 be no rewrite request that would not initiate SDAD check. 622 Some technologies are prone to multicast loss. The mechanism in this 623 document may not give security protection as intended if multicast 624 NS would be lost only in the direction of Intercepted Victim - SDAD 625 would not detect address duplicity. 627 The Intruder could potentially answer to multicast NS a few 628 milliseconds faster than the Intercepted Victim. Poisoned Victim 629 could update neighbor cache in the favor of Intruder and release the 630 small portion of the traffic before Poisoned Victim would receive 631 excessive number of NA responses and block both (Intruder and 632 Intercepted Victim). 634 Security solution discussed in this document does not need any 635 coordination on introduction in production. It could be done in any 636 order or ad-hoc: it is not restricted which one particular node 637 (router or host) would start additional SDAD check first. 639 There are 2 primary use cases envisioned (with the 3rd mixing both): 641 o Campus environment: the majority of traffic are going to default 642 router on every link. The intruder would have the priority to 643 poison router cache. Hence, router protection is priority 645 o Data Center environment: the big proportion of the East-West 646 traffic. Hosts protection has bigger priority for this use case 648 DuplicityLevel is the common information for the link - it is better 649 to advertise it from router in the future versions of ND. Current 650 design choice (keep this information local) is justified to simplify 651 transition - possibility to introduce SDAD support on any one node 652 or node sets in any order. 654 5.3. DoS level analysis 656 MITM attack vector #1 was very effective and easy to organize, hence 657 it was very probable. It has been converted by this document into 658 the same probable DoS (Intercepted Victim and Intruder - both 659 blocked). It could be the temptation to minimize Intercepted Victim 660 disruption by blocking only the second node (first-come/first-serve 661 approach). The Intruder would be the second in the majority of cases 662 that would minimize disruption for Intercepted Victim. 663 Unfortunately, there are less probable cases when Intruder would be 664 capable of catching server with popular application in reload or 665 upgrade state - then legal node would be blocked. The Intruder would 666 be capable of pretending to be the particular application and start 667 collection of valuable information from users that would visit this 668 application. See section 3.4 (Implications for off-link nodes) for 669 details. It is the leakage of information again. The leakage of 670 information is considered much more serious security problem than 671 DoS, hence such conversion of DoS back into leakage is not 672 acceptable. Vulnerability harm is more important than the 673 probability of vulnerability. It is especially true for [ND] where 674 we have other DoS vulnerabilities anyway. 676 Only cryptographically based authentication does permit to really 677 minimize DoS disruption for legal node. 679 6. Security Considerations 681 This document describes the conversion of most common MITM attack 682 vectors into less dangerous DoS. It does not introduce new 683 vulnerabilities. 685 One corner case is left unprotected by this document: 686 attack vector #2 for the situation when all involved nodes are hosts 687 and at the same time Intercepted Victim has been connected to the 688 link later after Intruder. 690 7. IANA Considerations 692 This document has no any request to IANA. 694 8. References 696 8.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, DOI 700 10.17487/RFC2119, March 1997, . 703 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 704 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 705 May 2017, . 707 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 708 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 709 DOI 10.17487/RFC4861, September 2007, . 712 [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 713 Address Autoconfiguration", RFC 4862, DOI 714 10.17487/RFC4862, September 2007, . 717 [Gratuitous ND] Linkova, J., "Gratuitous Neighbor Discovery: 718 Creating Neighbor Cache Entries on First-Hop Routers", 719 draft-ietf-6man-grand-01 (work in progress), July 2020. 721 [Optimistic DAD] N. Moore, "Optimistic Duplicate Address Detection 722 (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 723 2006, . 725 [Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection 726 by Hosts in a Multi-Prefix Network", RFC 8028, DOI 727 10.17487/RFC8028, November 2016, . 730 [ND Trust Model] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor 731 Discovery (ND) Trust Models and Threats", RFC 3756, DOI 732 10.17487/RFC3756, May 2004, . 735 [NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor 736 Unreachability Detection Is Too Impatient", RFC 7048, DOI 737 10.17487/RFC7048, July 2010, . 740 [Subnet Model] H. Singh, W. Beebee, E. Nordmark, "IPv6 Subnet Model: 741 The Relationship between Links and Subnet Prefixes", RFC 742 5942, DOI 10.17487/RFC5942, July 2010, . 745 [FCFS SAVI] E. Nordmark, M. Bagnulo, E. Levy-Abegnoli, "FCFS SAVI: 746 First-Come, First-Served Source Address Validation 747 Improvement for Locally Assigned IPv6 Addresses", RFC 748 6620, DOI 10.17487/RFC6620, May 2012, . 751 8.2. Informative References 753 [RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6 754 (IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200, 755 July 2017, . 757 [RIPE-Training] RIPE NCC, "IPv6 Security Training", February 2019, 758 . 761 [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. 762 Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 763 10.17487/RFC6105, February 2011, . 766 [IPv6 Reconnaissance] F. Gont, T. Chown, "Network Reconnaissance in 767 IPv6 Networks", RFC 7707, DOI 0.17487/RFC7707, March 2016, 768 . 770 [IEEE ND Security] Amjed Sid Ahmed Mohamed Sid Ahmed, Rosilah 771 Hassan, Nor Effendy Othman, "IPv6 Neighbor Discovery 772 Protocol Specifications, Threats and Countermeasures: A 773 Survey", DOI 10.1109/ACCESS.2017.2737524, August 2017, 774 . 777 9. Acknowledgments 779 Thanks to 6man working group for problem discussion 781 Authors' Addresses 783 Eduard Vasilenko 784 Huawei Technologies 785 17/4 Krylatskaya st, Moscow, Russia 121614 787 Email: vasilenko.eduard@huawei.com 789 Xiao Xipeng 790 Huawei Technologies 791 205 Hansaallee, 40549 Dusseldorf, Germany 793 Email: xipengxiao@huawei.com