IPv6 Maintenance (6man) Working Group E. Vasilenko Internet Draft X. Xiao Updates: 4861, 4862 (if approved) Huawei Technologies Intended status: Standards Track September 24, 2020 Expires: March 2021 ND improvement to prevent Man-in-the-middle attack draft-vasilenko-6man-nd-mitm-protection-00 Abstract Privacy protection is the bigger and bigger concern of many governments and public in general. ND has a few open man-in-the- middle attack vectors. MITM is considered among the most dangerous attack types because of information leakage. This document proposes minimal modifications for ND to protect IPv6 nodes against still open MITM attacks. It could be implemented gradually on any nodes, with the biggest benefit from support on routers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Vasilenko Expires March 24, 2021 [Page 1] Internet-Draft ND-MITM-protection September 2020 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology and pre-requisite..................................2 2. Introduction...................................................3 3. Security vulnerabilities.......................................4 3.1. Rewrite by unsolicited NA.................................4 3.2. Be the first and suppress DAD.............................5 3.3. Win the race just after DAD...............................6 3.4. Implications for off-link nodes...........................6 3.5. Speed up by [Gratuitous ND]...............................6 4. Solution - Security DAD........................................7 4.1. Standards modifications...................................8 4.1.1. Modifications to [ND]................................8 4.1.2. Modifications to [SLAAC]............................11 4.2. Interoperability analysis................................11 5. Applicability analysis........................................13 5.1. Performance analysis.....................................13 5.2. Usability analysis.......................................15 5.3. DoS level analysis.......................................16 6. Security Considerations.......................................16 7. IANA Considerations...........................................16 8. References....................................................17 8.1. Normative References.....................................17 8.2. Informative References...................................18 9. Acknowledgments...............................................18 1. Terminology and pre-requisite Good knowledge and frequent references to [ND] is assumed. Many terms are inherited from [ND]. Additional terms are introduced: Security DAD: Duplicated Address Detection for security check at the time to write or rewrite for Link Layer Address Intruder: The Node under control of malicious 3rd party Vasilenko Expires March 24, 2021 [Page 2] Internet-Draft ND-MITM-protection September 2020 Intercepted Victim: The node that could lose the privacy of communication Poisoned Victim: The node that could suffer an unauthorized modification of Neighbor Cache entry; depending on the scenario, it could additionally lose the privacy of communication The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 2. Introduction Cyber Security is one of the biggest concern for many governments: CPNI, HIPAA, FCRA, ECPA in US; GDPR in Europe; CSL in China; DPB in India; Data Protection Act 2018 in the UK. Many regulations have been refreshed or fully redeveloped in recent years. [ND Trust Model] clearly states: "it is desirable to limit the amount of potential damage in the case a node becomes compromised. For example, it might still be acceptable that a compromised node is able to launch a denial-of-service attack, but it is undesirable if it is able to hijack existing connections or establish man-in-the- middle attacks on new connections." The most dangerous and easy way to organize a MITM attack is based on rogue Router Advertisements. Fortunately, rogue router is easy to block on link level device by filtering ICMPv6 message type 134 ([RA-Guard]). This document discusses MITM attacks that are more difficult to block, because it is a challenge for link layer to clarify IP address ownership in the plain (distributed) ND architecture. The Internet has open tools to exploit this vulnerability (parasite6, scapy). Attacks are explained in [RIPE-Training] and [IEEE ND Security]. Last reference has very big collection of ND security improvements proposed (50+ solutions), but the problem related to information leakage is still open. This document proposes a simple modification for ND protocol that could be briefly explained as: Vasilenko Expires March 24, 2021 [Page 3] Internet-Draft ND-MITM-protection September 2020 o Link Layer Address rewrite or initial write for any Neighbor Cache entry MUST be the result of only *multicast* Neighbor Solicitation. Multicast would give a chance for Poisoned Victim to understand that many nodes are going to use the same IP address. o "Security DAD" is mandatory: it SHALL be checked that not more than expected number of NA replies have been received in the response to *multicast* NS. It means that for the majority of cases (default DuplicityLevel): no more than 1 reply. o Any node SHOULD override neighbor cache entry on routers by sending unsolicited NA message after respective node addresses would progress to preferred state. 3. Security vulnerabilities 3.1. Rewrite by unsolicited NA Let's consider the case when all nodes support [ND] without any extensions. Additionally, assume that Intruder gains access to one node on the link by exploiting some other vulnerability or Intruder has connected his host physically to the link. 3 nodes involved in the attack: Intruder (typically a host), Intercepted Victim (typically another host) and Poisoned Victim (typically a router). Neighbor Cache poisoning could be organized (by the procedure below) for any node (host or router). Router is typically the more probable target for the Poisoned Victim role because Intercepted Victim has a high probability to communicate with a Router. The algorithm for attack: o Intruder has many ways to get Intercepted Victim IP address - see [IPv6 Reconnaissance]. The IP address could not be considered hidden information. o Intruder starts sending non-legitimate unicast NA to Poisoned Victim with the "target IP address" of Intercepted Victim, but link layer address of the Intruder, with flags "Override" and "Solicited" set. Vasilenko Expires March 24, 2021 [Page 4] Internet-Draft ND-MITM-protection September 2020 o If Neighbor Cache entry on Poisoned Victim for reachability to Intercepted Victim is already created (by NS or return traffic - the second one is highly probable for routers) - then the Neighbor Cache entry would be overwritten, because "Override" flag was set. Neighbor cache entry would be put to STALE state at a minimum. If a particular implementation does not track correspondence between NS and NA (not required for state machine in [ND]) then cache entry would be put directly to REACHABLE, because "Solicited" flag was set (section 7.2.5 of [ND]). o Intercepted Victim would not see unicast NA - it would not have chance to recognize "duplicate address". Upstream traffic would flow normally from Intercepted Victim to Poisoned Victim, but downstream traffic would go from Poisoned Victim to Intruder. An Intruder could build a much bigger set of attacks on this basement, for example: it could edit DNS answers and redirect all Intercepted Victim's traffic to itself (both directions). An intruder could send poisoning NA periodically and intercept traffic as soon as it would become available from Poisoned Victim. Initial traffic missed for Intruder could be very small (tens of milliseconds). 3.2. Be the first and suppress DAD An Intruder could claim an IP address (and establish communication) while Intercepted Victim is disconnected from the link. Intruder just needs to suppress DAD on itself - Poisoned Victim would never understand that address duplication did happen for the basic [ND] environment. It is a more difficult attack vector for an Intruder, because it needs to wait Intercepted Victim reconnection to the link. It would be difficult to push the router to reinitialize the link. It is potentially possible to influence the host to re-initialize the link by DoS, social engineering or other vulnerability. It is definitely possible to wait till host or router would reload after upgrade (predicted event for host). This attack vector does not make sense for the Intruder under the case of availability attack vector #1. But it could become next primary attack vector if Intruder would be prevented from attack vector #1. Hence, solution should block it too. Vasilenko Expires March 24, 2021 [Page 5] Internet-Draft ND-MITM-protection September 2020 3.3. Win the race just after DAD The Intruder could be silent and monitor DAD. As soon as the Intruder would see DAD - it would have RetransTimer (1sec by default) to persuade the Poisoned Victim that it is the only one on the link that claims this IP address. The Intruder could pass any multicast or unicast check, because Intercepted Victim would be silent inside the DAD procedure for the basic [ND] environment. It is a more difficult attack vector for an Intruder, but could become primary if other attack vectors would be blocked. See more detailed explanation in previous section. 3.4. Implications for off-link nodes All 3 attack vectors above have additional strong vulnerability consequence that make sense to discuss separately: Intruder impersonates Intercepted Victim for traffic from off-link (for connections initiated from any node behind the router). It is the strongest form of 2-way Man-in-the-middle attack. It is not very important for ordinary hosts, because not many remote nodes would try to contact Intercepted Victim. There is the possibility for unlucky exception when admin would come to Intercepted Victim for remote monitoring, then Intruder could ask him for password hash. Admin password is extremely valuable for the Intruder. It is really big leakage of information if Intruder impersonates some important corporate server. Many users of this company would connect to the Intruder. The majority of internal Enterprise applications do not have mutual authentication properly activated. The Intruder would be capable to collect many passwords of this company. It is easy for Intruder to emulate the original application because it could proxy user requests to Intercepted Victim (on the same link) and get proper responses that fully satisfy users. Particular application could have additional vulnerabilities that is easy to exploit in the situation when Intruder is on the server side. 3.5. Speed up by [Gratuitous ND] This is not separate attack vector. It is just a little improvement for the Intruder for attack vectors #1. Let's assume that [Gratuitous ND] is implemented at least on Poisoned Victim. Vasilenko Expires March 24, 2021 [Page 6] Internet-Draft ND-MITM-protection September 2020 [Gratuitous ND] has changed 1st paragraph of [ND] section 7.2.5 - it permits creation of new Neighbor Cache entry on Poisoned Victim, including the situation when there was no NS before and no record has been created in any state. Let's assume that garbage collector deleted stale record for seldom speaking node. Then consider situation of attack vector #1. Basic [ND] pushes the Intruder to send unsolicited NA frequently (up to the rate limit on the Poisoned Victim). In contrast, [Gratuitous ND] permits to create the neighbor cache record by one message much in advance of traffic flow. As a result, Intruder could get all traffic from Poisoned Victim to Intercepted Victim, no any packet would be missed. The improvement for the Intruder is very small - just tens of milliseconds of additional traffic would be intercepted. Attack vector is very effective in both cases. Let's look to the attack vector #2. Intruder had plenty of time to establish communication by normal traffic flow. No additional value from [Gratuitous ND]. Let's look to the attack vector #3. Intruder have RetransTimer (1sec by default) to create a record on Poisoned Victim. Normally generated traffic should be fast enough. No additional value from [Gratuitous ND] again. 4. Solution - Security DAD The general idea is very easy to explain: o Link Layer Address rewrite or initial write for any Neighbor Cache entry MUST be the result of only *multicast* Neighbor Solicitation. Multicast would give a chance for Poisoned Victim to understand that many nodes are going to use the same IP address. o "Security DAD" is mandatory: it SHALL be checked that not more than expected number of NA replies have been received in the response to *multicast* NS. It means that for the majority of cases (default DuplicityLevel): no more than 1 reply. o Only fastest NA response to multicast NS SHOULD be used for write or rewrite of LLA. This rule would be useful only for the case of DuplicityLevel more than 1 (not default configuration). It is needed to support many anycast address on the same link. Vasilenko Expires March 24, 2021 [Page 7] Internet-Draft ND-MITM-protection September 2020 o Any node SHOULD override neighbor cache entry on routers by sending unsolicited NA message after respective node addresses would progress to preferred state. The implementation is more complex, because it needs to be put into [ND] context - see next sections. 4.1. Standards modifications 4.1.1. Modifications to [ND] * Section 5.1 and section 7.3.2 of [ND], add new state of Neighbor Cache entry: 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. * Sections 6.2.1 and 6.3.2 of [ND], add to router and host variables: DuplicateTimer - measured in seconds, dampening time for duplicate IP address discovered by SDAD procedure. It SHOULD be copied from "Reachable Time" advertised by router (on the router itself, it is known as AdvReachableTime - section 6.2.1 of [ND]). Future versions of [ND] should be extended to advertise this timer from router in RA messages. * Sections 6.2.1 and 6.3.1 of [ND], add to router and host configurable variables: DuplicityLevel - number of NA responses that is accepted as legitimate for multicast NS solicitation. It permits to proper handling of anycast addresses present on the link if the maximum number of anycast addresses is known in advance. The node MUST have the capability to provision DuplicityLevel on a per-link granularity. 32-bit unsigned integer SHOULD be reserved for this counter. Vasilenko Expires March 24, 2021 [Page 8] Internet-Draft ND-MITM-protection September 2020 * Section 10 of [ND], add to Node constants: DuplicityLevel 1 (no duplicate addresses permitted) * Section 5.3 (Garbage Collection) of [ND], add at the end: Neighbor Cache entries with DuplicateTimer expired SHOULD be deleted. It is possible to delete entries before timer expiration, if there is a need to free space for new entries. * Section 7.2.2 (Sending NS) of [ND], add at the end: Prepare state machine on every transmission of multicast NS: o Initialize DUPLICITY counter by DuplicityLevel o Restart RetransTimer of this Neighbor Cache entry Do not change RetransTimer for unicast NS - reuse expired one. * Section 7.2.5 (Receipt NA) of [ND], replace at the beginning: This modification is equivalent to [Gratuitous ND]. You could have this change already if [Gratuitous ND] is implemented on your router. OLD TEXT: When a valid Neighbor Advertisement is received (either solicited or unsolicited), the Neighbor Cache is searched for the target's entry. If no entry exists, the advertisement SHOULD be silently discarded. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. NEW TEXT: Vasilenko Expires March 24, 2021 [Page 9] Internet-Draft ND-MITM-protection September 2020 When a valid Neighbor Advertisement is received (either solicited or unsolicited), check first for the target's IP address entry in the Neighbor Cache. If no entry exists on the host, it SHOULD silently discard this advertisement. There is no need to create an entry if none exists, since the recipient has apparently not initiated any communication with the target. If no entry exists on the router, it should additionally check for Target link-layer address option. If the received Neighbor Advertisement does not contain the Target link-layer address option, then the router SHOULD silently discard this advertisement. Else router SHOULD create a new entry for the target address with the link-layer address set to the Target link- layer address option. The neighbor cache entry state MUST be set to STALE. * Section 7.2.5 (Receipt NA) of [ND], add at the end: I. If NA received is inside RetransTimer window, then it is considered as a response to NS (solicited): o If DUPLICITY counter does not yet reach 0: Process NA according to all other rules of this section, except write or rewrite of link layer addresses is permitted only if DUPLICITY is equal to DuplicityLevel (only fastest anycast is used for neighbor reachability cache). Additionally, decrement DUPLICITY. o If DUPLICITY counter is 0: Change Neighbor Cache entry to DUPLICATE state. Clear all packets in the queue related to this target address. Log duplicate address event with target address and both Link Layer addresses (from received NA and from cache entry). Start DuplicateTimer for this Neighbor Cache entry. II. If RetransTimer is expired or Neighbor Cache entry does not exist yet for this target address then NA is considered unsolicited disregard of any flags set. Process NA according to all other rules of this section, except additional check: if processing would need to initial write or rewrite Link Level Address (i.e. any change of LLA) then change Neighbor Cache entry state to INCOMPLETE and initiate *multicast* Neighbor Solicitation process against this target IP address. Vasilenko Expires March 24, 2021 [Page 10] Internet-Draft ND-MITM-protection September 2020 * Section 7.2.6 (Sending unsolicited NA) of [ND], add at the end: A node SHOULD send Neighbor Advertisement message with Override flag set to the all-routers multicast address after respective address would change state to preferred. * It MAY be added after 4th paragraph of section 5.2 (Conceptual Sending Algorithm) of [ND]: Traffic resolved to be sent through Neighbor Cache entry in DUPLICATE state MUST be dropped. 4.1.2. Modifications to [SLAAC] * Neighbor Cache maintenance is pretty much restricted to [ND]. Hence, it is not mandatory to change [SLAAC] - the latter is more concerned on initialization and DAD. One optimization is possible specifically for [Gratuitous ND] environment. It is stated in paragraph 4 of section 5.4.2 [SLAAC] that messages sent in response to multicast announcements should be delayed for random time between 0 and MAX_RTR_SOLICITATION_DELAY, but the type of multicast message is mentioned in clear "router advertisement message". It MAY be reasonable to replace it to "any message", because [Gratuitous ND] does send unsolicited NA to all-routers multicast and this document proposes response by NS that could synchronize from all routers. 4.2. Interoperability analysis Proposed solution does not need any additional functionality on link layer technology (no layer 2 features needed). It does not block unsolicited NA - Link Local Addresses write or rewrite is still possible, including compatibility to [Gratuitous ND]. [Optimistic DAD] creates possibility for Intruder to intercept RetransTimer (1sec by default) of traffic in the case of attack vector #2 and #3, because optimistic address could transmit traffic without the possibility to override Poisoned Victim neighbor cache - NA should have override flag cleared. [Gratuitous ND] does not change this rule for the good reason: it would be not a good idea to strongly claim address that has not passed DAD check yet. Vasilenko Expires March 24, 2021 [Page 11] Internet-Draft ND-MITM-protection September 2020 Hence, SDAD would not be activated up to the time the address would progress to preferred, that initiate NA with override flag set. You could disable [Optimistic DAD] if your concern about traffic intercepted for RetransTimer seconds is bigger than your concern of interface initialization delay for the same time. [Gratuitous ND] operates as intended in the combination with [Optimistic DAD]. [Gratuitous ND] is effectively replaced by this document for the case when address is progressed to preferred, because stronger form of unsolicited NA (with override flag set) is proposed. It should be no problem for multi-prefix and multi-homing environment discussed in [Multi-Homing], because Neighbor Cache population does not influence forwarding directions (Destination Cache does). [Gratuitous ND] could create unnecessary states on routers advertising address spaces from different ISP for the case of Provider-aggregatable address space. Mechanism specified in this document would confirm it to REACHABLE state, then it would be probably not used later (freeze in STALE state up to garbage collection). It is very small deficiency originated by [Gratuitous ND] that does not make sense to fix. This document does not create any problem for standard update proposed in [Subnet Model], because determination of "on-link" addresses is on Destination Cache level that Neighbor Cache is not capable to influence. [FCFS SAVI] deep security assistance from L2 switches would not benefit from this document - it is not possible to poison cache in SAVI architecture. It is important to mention that this document would not create any interoperability issue with [FCFS SAVI]. There would be no illegal write or rewrite requests (with duplicate addresses) that SDAD needs to check. The same consequence is under SeND presence: cryptographically protected addresses does not need additional protection, but again current document would not create any interoperability problem by additional Security DAD check. DHCP support is not affected by this document - it is irrelevant how node has got an IP address. Furthermore, it is not important whether it has been done in a legal way - if Intruders would try to hijack traffic of each other - they would be both blocked, because they would create duplicate addresses. Vasilenko Expires March 24, 2021 [Page 12] Internet-Draft ND-MITM-protection September 2020 [NUD improvement] has the natural synergy with current document, because it converts unicast NS to multicast NS (when neighbor cache state would change to UNREACHABLE) that permits to save on additional multicast NS for SDAD check. SDAD (as well as ordinary DAD) is not fully compatible to anycast IP address. DuplicityLevel permits to properly handle anycast addresses present on a link if the maximum number of anycast addresses is known in advance (see DuplicityLevel variable). Active-Standby clustering solutions (including VRRP) should not be affected by this standard extension, because properly functioning cluster should respond to target IP only from one LLA. If any concern on cluster behavior exist - SDAD could be effectively disabled by setting bigger number for DuplicityLevel. The document proposes minimal changes for ND protocol without changing the basic principles. Moreover, changes in nodes behavior are local - it is not needed to wait for formal standard update - new behavior would be fully compliant to [ND] and [SLAAC], as well as all other extensions mentioned above in this section. 5. Applicability analysis 5.1. Performance analysis [Gratuitous ND] cache initialization improvement is not affected by this document, because algorithm above assumes immediate check, no need to wait for return traffic to be buffered. Additional Security DAD (with associated multicast solicitation) should happen only for Link Layer Address write or rewrite that ideally should happen only one time for every address. Control Plane load should not be considerably increased. Moreover, in some cases SDAD check coincide with multicast NS that results in no additional messages. See later more detailed analysis of multicast performance for 3 primary scenarios. It has been analyzed per 1 address space, other Global Unicast Addresses or Unique Local Address would have exactly the same calculations. LLA would generate additional multicast traffic that is omitted in calculations. A reminder: according to section 5.1 of [SLAAC] - ordinary DAD has 1 multicast check by default (DupAddrDetectTransmits is 1). Vasilenko Expires March 24, 2021 [Page 13] Internet-Draft ND-MITM-protection September 2020 We could assume that the host would not wait scheduled RA, it would probably initiate RS that would generate multicast RA. 1. Host to host communication (general scenario). The basic neighbor reachability detection (by [RFC 4861]) should use one multicast for DAD and one multicast solicitation to discover other node. It is not important for performance analysis that only originating node would check 2-way communication (and would promote cache entry to REACHABLE) as a result of initial multicast solicitation, because other node would record proper LLA too - it would use unicast solicitation later to prove 2-way communication. Hence, this document would generate an additional multicast request per every pair of communicating nodes. Depending on the mesh communication richness between nodes - it could increase multicast traffic from 0 up to 100% (depends on the number of communicating pairs): (2*c*(c-1)+h)/(c*(c-1)+h). 2. Router cache population in the basic [ND] scenario. Initial DAD is omitted here, because it was calculated in host- to-host scenario. The host would generate multicast RS and would receive multicast RA. Multicast NS is assumed as a result of one router receiving traffic to a particular host. This document reuses any multicast NS for SDAD, hence performance is not affected: (h*(2*r+1))/(h*(2*r+1))=1. 3. Router cache population in the scenario of [Gratuitous ND]. Initial DAD is omitted here, because it was calculated in host- to-host scenario. The host would generate multicast RS and would receive multicast RA. One multicast unsolicited NA is proposed by [Gratuitous ND], it could not be used for SDAD, because it is going to different multicast group (routers). Hence, this document creates 33% more multicast traffic for 1 router on this link, 40% more multicast for 2 routers on this link, up to 50% more multicast for many routers: (h*(2*r+1+r))/(h*(2*r+1)). It makes sense to remind, that normal neighbor cache entry refreshment should not generate additional multicast, because entry refreshment is assumed in unicast to known MAC address - see PROBE definition in [ND] section 5.1. The Garbage collector may completely delete long stale neighbor cache entry (good example of such host is a printer), then multicast would be needed anyway - this document does not increase multicast for that case. Vasilenko Expires March 24, 2021 [Page 14] Internet-Draft ND-MITM-protection September 2020 5.2. Usability analysis Host's Unsolicited NA (after address would go to preferred state) is proposed only in the direction of all-routers multicast (router to host communication). It would invoke SDAD check and reveal duplicity. Attack vector #2 has been left unprotected by this document for the case of host to host communication. MITM for traffic inside link is still possible, because SDAD check is useless at the time when Intercepted Victim is not connected yet to the link, but later would be no rewrite request that would not initiate SDAD check. Some technologies are prone to multicast loss. The mechanism in this document may not give security protection as intended if multicast NS would be lost only in the direction of Intercepted Victim - SDAD would not detect address duplicity. The Intruder could potentially answer to multicast NS a few milliseconds faster than the Intercepted Victim. Poisoned Victim could update neighbor cache in the favor of Intruder and release the small portion of the traffic before Poisoned Victim would receive excessive number of NA responses and block both (Intruder and Intercepted Victim). Security solution discussed in this document does not need any coordination on introduction in production. It could be done in any order or ad-hoc: it is not restricted which one particular node (router or host) would start additional SDAD check first. There are 2 primary use cases envisioned (with the 3rd mixing both): o Campus environment: the majority of traffic are going to default router on every link. The intruder would have the priority to poison router cache. Hence, router protection is priority o Data Center environment: the big proportion of the East-West traffic. Hosts protection has bigger priority for this use case DuplicityLevel is the common information for the link - it is better to advertise it from router in the future versions of ND. Current design choice (keep this information local) is justified to simplify transition - possibility to introduce SDAD support on any one node or node sets in any order. Vasilenko Expires March 24, 2021 [Page 15] Internet-Draft ND-MITM-protection September 2020 5.3. DoS level analysis MITM attack vector #1 was very effective and easy to organize, hence it was very probable. It has been converted by this document into the same probable DoS (Intercepted Victim and Intruder - both blocked). It could be the temptation to minimize Intercepted Victim disruption by blocking only the second node (first-come/first-serve approach). The Intruder would be the second in the majority of cases that would minimize disruption for Intercepted Victim. Unfortunately, there are less probable cases when Intruder would be capable of catching server with popular application in reload or upgrade state - then legal node would be blocked. The Intruder would be capable of pretending to be the particular application and start collection of valuable information from users that would visit this application. See section 3.4 (Implications for off-link nodes) for details. It is the leakage of information again. The leakage of information is considered much more serious security problem than DoS, hence such conversion of DoS back into leakage is not acceptable. Vulnerability harm is more important than the probability of vulnerability. It is especially true for [ND] where we have other DoS vulnerabilities anyway. Only cryptographically based authentication does permit to really minimize DoS disruption for legal node. 6. Security Considerations This document describes the conversion of most common MITM attack vectors into less dangerous DoS. It does not introduce new vulnerabilities. One corner case is left unprotected by this document: attack vector #2 for the situation when all involved nodes are hosts and at the same time Intercepted Victim has been connected to the link later after Intruder. 7. IANA Considerations This document has no any request to IANA. Vasilenko Expires March 24, 2021 [Page 16] Internet-Draft ND-MITM-protection September 2020 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [Gratuitous ND] Linkova, J., "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers", draft-ietf-6man-grand-01 (work in progress), July 2020. [Optimistic DAD] N. Moore, "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [Multi-Homing] F. Baker, B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, . [ND Trust Model] P. Nikander, J. Kempf, E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, DOI 10.17487/RFC3756, May 2004, . [NUD improvement] E. Nordmark, I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, July 2010, . Vasilenko Expires March 24, 2021 [Page 17] Internet-Draft ND-MITM-protection September 2020 [Subnet Model] H. Singh, W. Beebee, E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, . [FCFS SAVI] E. Nordmark, M. Bagnulo, E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, . 8.2. Informative References [RFC8200] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RIPE-Training] RIPE NCC, "IPv6 Security Training", February 2019, . [RA-Guard] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, . [IPv6 Reconnaissance] F. Gont, T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 0.17487/RFC7707, March 2016, . [IEEE ND Security] Amjed Sid Ahmed Mohamed Sid Ahmed, Rosilah Hassan, Nor Effendy Othman, "IPv6 Neighbor Discovery Protocol Specifications, Threats and Countermeasures: A Survey", DOI 10.1109/ACCESS.2017.2737524, August 2017, . 9. Acknowledgments Thanks to 6man working group for problem discussion Vasilenko Expires March 24, 2021 [Page 18] Internet-Draft ND-MITM-protection September 2020 Authors' Addresses Eduard Vasilenko Huawei Technologies 17/4 Krylatskaya st, Moscow, Russia 121614 Email: vasilenko.eduard@huawei.com Xiao Xipeng Huawei Technologies 205 Hansaallee, 40549 Dusseldorf, Germany Email: xipengxiao@huawei.com Vasilenko Expires March 24, 2021 [Page 19]