IPv6 Maintenance (6man) Working Group E. Vasilenko Internet Draft Huawei Technologies Updates: None Intended status: Standards Track September 22, 2022 Expires: March 2023 Cryptographically Generated Addresses (CGA) Light draft-ev-6man-cga-light-01 Abstract This document specifies a method for securely associating link-layer addresses (MAC) to the IPv6 address by a cryptography method similar to blockchain mining. It permits guarantee security at the IPv6 layer to the same degree as at the link layer (that node is dependent on anyway). 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) 2022 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 publication of this document. Please review these documents Expires March 22, 2023 [Page 1] Internet-Draft ND-prefix-robustness September 2022 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. Strength Evaluation............................................5 4. IID generation technical details...............................6 5. IID validation technical details..............................10 6. ND extensions to exchange relevant information................11 7. Compatibility with other ND functionality.....................12 8. Security Considerations.......................................13 9. IANA Considerations...........................................14 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................15 11. Acknowledgments..............................................16 1. Terminology and pre-requisite Many terms are inherited from [CGA] and [SEND]. Information for IID - the collection of information needed to distinguish IIDs generated for different purposes in compliance with other standards; local information to the node. Digest of IID information - hash from "Information for IID"; public information distributed by ND. Chg parameter - a number between 0 and 15 (4 bits) that participates in the calculation (A+B*Chg) of leading zero bits that should be in a validated hash; "A" and "B" are constants fixed in this specification 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 Expires March 22, 2023 [Page 2] Internet-Draft ND-prefix-robustness September 2022 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Introduction There are many attack vectors to ND. [ND Trust Model] section 4.1 has the name "Non-router related threats" and could be summarized: . A malicious node could answer DAD for any request of a legitimate node (denial of service attack) . A malicious node could poison the cache of another node (especially the router) to intercept traffic directed to another node (man in the middle attack); it is possible for neighbor solicitation and neighbor advertisement in many different cases. The potential bunch of attacks based on the above is discussed in detail in [ND MITM] section 3: . Rewrite cache by unsolicited NA . Be the first and suppress DAD . Win the race just after DAD The [SEND] plus [CGA] have proposed cryptographic solutions to the problem. The [CGA] was positioned as dependent on [SEND] not a separate solution, it was used primarily to avoid unnecessary signature verifications (pre-check) for denial of service requests. Unfortunately, [SEND] has a pre-request to organize PKI (public key infrastructure) which is a well-known problem for enterprises. It is assumed that trusted anchor management in the [SEND] solution was the primary reason for low adoption. The same problem is relevant to the [HBA] solution that needs distribution and management for symmetric keys. Effectively, it could be said that previous solutions have low adoption for the same reason as IPSec: a challenge to organize key management. Blockchain's general success has shown that cryptography could be valuable even in a situation when the trusted anchor is not considered. This document is based on the [CGA] with minor modifications needed to satisfy the requirements of many other standards developed since then. This document fulfills the [CGA] promise: "The protection works without a certification authority or any security infrastructure". Expires March 22, 2023 [Page 3] Internet-Draft ND-prefix-robustness September 2022 The [CGA] was associating the "public key" to "IID" as a backup to public key management in the certification authority. In contrast, this document proposes a "Link-layer" to "IPv6" addresses associated with cryptography assurance. Link-layer address to IP layer address mapping is the primary function of [ND] protocol that is protected by this specification. The link-layer address is cryptographically protected in the case of wireless and very often protected in the case of wireline (802.1x). It is possible to have the link with nodes supporting this specification and legacy nodes that could not check the address ownership. ND cache could be poisoned on unprotected nodes in a mixed environment. The router is the key target for ND cache poisoning. Hence, router support for this specification is especially valuable. A reminder that hash function is by design has no correlation between output and input. Hence, only brute input trials are needed to find output with any desired property (like some number of leading zeroes). The protection principles here are the same as for blockchain mining or [CGA]: the legal node needs 2^(A+B*Chg+1-1) calculations on average for IID mining but the malicious node would need 2^(A+B*Chg+60-1) calculations on average because in addition to the same amount of leading zeroes it needs additionally the particular combination of 60 trailing bits at the same time. "+1" in the above calculations is because the hash is double for mining. "-1" in the above calculation is because of the average (50% probability). Hence, the intruder needs 2^59 times more hash calculations to find a proper "Digest of IID information" that would match his link-layer address (MAC). [Hash in Sec] has a discussion that if many hash algorithms are available on the link then intruder can attack the weakest. [Hash in Sec] has proposed to encode hash type in the IID (borrowing security level space), IANA "CGA SEC" registry has been created. Hence, [CGA] security level ("Sec" parameter) has a different meaning from the "Chg" parameter used in this specification. Attack vector on hash type downgrade has been dealt with in this specification by rewrite rules of ND cache where hash type is considered. Let's overview IID mining: Expires March 22, 2023 [Page 4] Internet-Draft ND-prefix-robustness September 2022 0. Choose the Chg parameter that points to how many leading zeroes should be in the hash on step 3. 1. Initially, all relevant information for IID creation is concatenated in the clear text block that would be named "Information for IID". It is primarily the information needed for: a. Guaranty IID uniqueness (Time, Nonce, Collision count) b. Guaranty stable but different IID for different link attachments (interface name, network name) 2. Then "Information for IID" is hashed. The result is the "Digest of IID information" that would be made public by [ND] protocol. 3. "Digest of IID information" is concatenated with Prefix and link- layer (MAC) and then hashed again. 4. If the hash result of step 3 already has the needed number of leading zeroes then 60 lowest bits are used for IID and "Information for IID" should be saved in non-volatile memory. Else (not enough leading zeroes) any bits (Nonce, Time) or fields order in the "Information for IID" should be changed and this algorithm loops to step 2. The algorithm convergence may need 2^(A+B*Chg) calculations in an average of the selected hash function, it has a good probability to converge for 2^(A+B*Chg+1) hash calculations. Any other node may do a simple check of validity for the Prefix/IID/Link-Layer combination before rewriting ND cache: 0. Extract Chg from 4 high order IID bits. 1. Hash the "Digest of IID information" concatenated with Prefix and link-layer address (MAC). 2. Check that the leading A+B*Chg bits of the hash are zeroes. Discard ND update otherwise. 3. Check that the trailing 60 bits of the hash are equal to the IID claimed by the node. Discard ND update otherwise. 4. Accept ND update. 3. Strength Evaluation Bitcoin is a good reference for such a type of evaluation. It uses a double hash like this specification, the type is SHA-256. The different hash algorithms (SHA-512 is recommended below for this specification) may improve security that would be ignored for this estimation. Bitcoin has started from the requirement for 32 bits leading zeroes (for the genesis block) and has moved to 80 bits now. It has surpassed 200EH/s (2*10^20 hashes per second) to crack 80 Expires March 22, 2023 [Page 5] Internet-Draft ND-prefix-robustness September 2022 bits for 10 minutes on average. The principal difference is that the Bitcoin block (to hash) is much bigger (around 1MB+-50%) compare needed to CGA (around 280B). Hence, Bitcoin's difficulty is around 2^12 bigger just because of the bigger input. Let's justify the "A" and "B" parameters for "A+B*Chg" leading zeroes. "A" leading zeroes should be easy to calculate even for the smallest system. The smallest IoT system may spend as high as 200us for one SHA-256 in software (hardware acceleration is available very often then the performance is better). 1 minute is the assumption for the time permitted to spend for mining then A=8 leading zeroes that are needed for mining at a minimum. The challenge for the intruder would be 2^67 hashes. The whole Bitcoin infrastructure would crack it for 18us. It would be just a problem to persuade mining owners to proceed. Let "B" would be big enough for the whole Bitcoin infrastructure would not crack IID in 1000 years. 1000 years is different from 10 min in 2^26. Additionally, our hashed block is 2^12 smaller. Hence, it should be an 80+26+12=118 bits challenge. Then B=4. The challenge for mining IID would be 2^68. Some GPUs are capable of 3GH/s then IID mining would be around 3000 years on one GPU which is probably a good room for growth. It means that the Chg parameter at the highest values (>12) would be seen as very rare for some time. Summary: for respective A+B*Chg, A=8, B=4. Chg is transmitted in every ND update as the high-order bits of IID. It is the compromise between the possibility of mining on the smallest node and maximum protection that is desired to achieve in the future for a very important server. In general, knowing the node capability for the number of hashes per second (for chosen hash type) - it is easy to predict the average time of mining for the specific level of protection (Chg parameter). 4. IID generation technical details IID generation should be done separately per every link/network according to [Different IIDs]. It would be needed to perform this procedure after any new prefix (PIO) announcement or link-layer address change. The implementation MAY have the capability to get initial parameters from the configuration when it is possible to do mining on a Expires March 22, 2023 [Page 6] Internet-Draft ND-prefix-robustness September 2022 different system. In that case, the target system SHOULD go through the algorithm below anyway to check the consistency. It would cost 2 hash calculations to check that all data are consistent. Decide about the needed level of protection for the address. Chg parameter has 4 bits that permit 16 levels of protection, every next level of protection would request "B" additional zero leading bits in the second hash mining. All nodes SHOULD have a possibility of administrator configuration for the level of IID protection (Chg parameter) on every sub-interface. The default protection level for the particular system is up to the implementer. Like all other cases in cryptography, even well-protected IID (high levels of Chg) MUST be refreshed after some time. Pay attention that Chg increase by one would increase the strength of IID by 2^B. It does not permit giving default configuration recommendations because different hash algorithms by themselves may have different strengths and different target systems may have a few orders of magnitude different attractiveness for an intruder that may bring principally different resources for mining. Hence, the table of lifetimes for every level of Chg is implementation-specific. It may be different for different hash algorithms. Reminder, that [IID significance] has deprecated special meaning for "u" and "g" bits in IID. Hence, all 64 bits are available for our specification. 4 bits were used for the protection level. Hence, 60 bits are left for random ID. Step 1: As discussed in [Temporary addresses] that "Information for IID" should have a prefix, link-layer address, network name, time, DAD counter, and some nonce to make it possible for temporary address generation. Prefix and link-layer addresses would be added to the second hash calculation. Hence, initially, the "Information for IID" text should have: . Nonce to easy change the "Information for IID" hash . Time in any format, better to follow [Temporary addresses] assumptions . Network name (like SSID) for links that have such parameter . DAD collision count that is regulated by other specifications . Any other parameters are permitted because all parameters of "Information for IID" have local meaning - they would be not advertised by [ND] Expires March 22, 2023 [Page 7] Internet-Draft ND-prefix-robustness September 2022 The size of the parameters is up to the implementer. An especially big block of "Information for IID" may affect the performance of IID mining. The order of information concatenation is not important. Moreover, as it would be shown later the order may be changed during the mining process. Special warning about Nonce size. It is RECOMMENDED to choose it longer than chosen A+B*Chg bits. Or else would be the same problem as for Bitcoin: Nonce could be looped around, but mining is not successful yet. In this case, like for Bitcoin, it is possible to change parameters (for example, read new time) or reorder the above- mentioned fields or introduce extraNonce as an additional field to the "Information for IID". To avoid this additional algorithm complexity, it is better to define Nonce as A+B*15 bits which should be enough for the most secure IID mining. Anyway, it is a local implementation matter. It does not make sense to spend resources on additional mathematical functions upon "Information for IID" because later it would be hashed anyway for good randomization. The hash function is good enough to satisfy [Temporary addresses] requirements. Step 2: Then "Information for IID" is hashed. The result is the "Digest of IID information" that would be made public by [ND] protocol together with the corresponding link-layer address and prefix intended for IID. The hash at this stage has local significance. Hence, the hash type may be different from the hash type in Step 3 which should be synchronized between nodes on the link. Simplicity should have both hashes of the same type. Step 3: "Digest of IID information" is concatenated with Prefix and link- layer address into one block that is hashed again. It is MANDATORY to keep the order and size mentioned in this Step parameters to have consistent hash results on all nodes of the link (to check validity). "Digest of IID information" on the input MUST have the same size as the output of the chosen hash type for this step. If there is any Expires March 22, 2023 [Page 8] Internet-Draft ND-prefix-robustness September 2022 difference then Digest should be truncated or fitted with leading zeroes. Most probably, both steps (step 2 and step 3) would use the same hash type then the hash size would be equal automatically. The prefix MUST be populated with trailing zeroes up to 128 bits to support any prefix boundary in the future. Link Layer address MUST be fitted leading zeroes to 64 bits to be capable to accommodate any L2 technology. Step 4: Check for how many leading zeroes the second hash has (from the previous step). Mining SHOULD be processed till A+B*Chg leading bits are zeroed. If successful then the resulted "Information for IID" and "Digest of IID information" SHOULD be memorized in non-volatile memory. Else "Information for IID" should be modified and the mining algorithm should be looped to step 2. "Information for IID" has many ways to be modified: . Increment Nonce . Reorder fields in the "Information for IID" . Change fields (update time) . Add field (like extraNonce) It is potentially possible in Step 4 to memorize the "Information for IID" for the best result seen. Then it is possible to break from the mining with the correction of the Chg to the achieved number. Hence, it is possible to loop in the mining cycle for a limited time. It is NOT RECOMMENDED because it does not permit achieving the desired level of security. But it may be needed for the high protection levels (high Chg) or on systems with low hash processing rates to avoid the system hanging in the mining for an unaccepted period. Step 5: According to the [SLAAC] procedure, the new IID should be checked for uniqueness by DAD. If DAD is positive then Collision Counter in the "Information for IID" is incremented and the mining is looped to step 2. It is up to other specifications to regulate how many collisions are tolerable and what to do after it would be reached (for example, ask a manual intervention). Expires March 22, 2023 [Page 9] Internet-Draft ND-prefix-robustness September 2022 5. IID validation technical details The validation node SHOULD check the IP/Link-layer pair association before any modification in the ND cache. And even after the validity is checked, there is an additional procedure to check overwrite rights (see at the end of this section). Every record in the ND cache should have a flag "validated" and additional fields used for validation (at least "Digest of IID information" and hash type). Let's call legacy ND records and updates as Not-Protected. The validating node should receive an ND message with all needed information (hash algorithm type, "Digest of IID information", Prefix, link-layer address) by mechanisms specified in section 6. Partial presence of needed parameters (for example "Digest of IID information" is present but the hash type is absent) is treated as an update request from a node not supporting this specification (Not-Protected node). The mining challenge parameter (Chg) should be extracted from 4 high-order bits of IID. See details in section 4. Step 3 for the importance of the order and size of all concatenated fields to get consistent results. Then hash the "Digest of IID information" concatenated with Prefix and link- layer address. Resulted hash should be checked for: . leading A+B*Chg bits of the hash are zero . trailing 60 bits of the hash are equal to the IID claimed by the node If any check is negative then the ND update MUST be dropped. The update that claims to be protected but failed validation should not be considered in principle. If both checks are positive then proceed to the final check that is especially needed in the mixed environment: . The Not-Protected record SHOULD be overwritten by a Validated ND update. . The Validated record SHOULD be overwritten by a Validated ND update that satisfies two checks: 1) equal or high permitted hash type number (see section 6. about the possibility to exclude some hash types from consideration) and 2) high Chg parameter (more leading zeroes for protection). Expires March 22, 2023 [Page 10] Internet-Draft ND-prefix-robustness September 2022 . The Validated record MUST NOT be overwritten by 1) a Not- Protected ND update or 2) by a Validated update with an equal or lower protection level (the smaller or equal Chg parameter) or 3) by a Validated update with lower permitted (see section 6. about the possibility to exclude some has types from consideration) hash type number. Effectively, the last rule may be presented in a simpler form: The Validated record MUST NOT be overwritten in all other cases. 6. ND extensions to exchange relevant information For the other node to check address ownership, it needs "Digest of IID information" concatenated with Prefix and link-layer address. Three parameters and the type of the hash function should be advertised. ND option 39 (Crypto-ID Parameters) would be reused for the hash type signaling. All other parameters delivered by this option except hash function type would be ignored for this specification. Crypto- Type number 1 is pointing to SHA-512 which is RECOMMENDED as the default. Crypto-type section of the [ICMPv6] registry currently has types 0 or 2 that choose SHA-256. Crypto-type registry may be extended as needed. Different nodes can have different crypto-types on the link, hence, nodes (especially routers) may need to support all active hash types on the link. Nodes MUST have the capability to restrict the list of hash types accepted on the link. It is needed to block failed or weak hash algorithms in the future. The implementation MAY just treat such updates as Not-Protected without checking the validity and following rewrite rules for Not-Protected updates. It is RECOMMENDED that by default node should accept in ND updates only the hash type that the node itself is using for mining, all other hash types are better to provision consciously. It is the primary purpose of ND to deliver a link-layer address. [ND] protocol is already asking to include link-layer address options for all relevant cases: . It should be included for Router Solicitation (except the IP address is still unspecified) . It may be omitted for Router Advertisement . It must be included for multicast and should be included for unicast of Neighbor Solicitation . It must be included for multicast and should be included for unicast of Neighbor Advertisement (except IP address is still unspecified) Expires March 22, 2023 [Page 11] Internet-Draft ND-prefix-robustness September 2022 Hence, it may be assumed that the link-layer address would be available at the time needed. ND protocol is based on IP. Hence, the prefix could be extracted from the source IP address. The only parameter left is the "Digest of IID information". It is defined in this specification: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Digest | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ of IID information (hash) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type number is TBD by IANA. "Digest of IID information" and "Crypto-type" options SHOULD be sent in all cases when link-layer information is sent, i.e. on all occasions when [ND] uses option 1 (source link-layer address) or option 2 (target link-layer address). If the node does not support this specification or requested hash type then it could not protect other node address ownership. Hence, it is mandatory to support this specification and all needed hash types at least on routers. 7. Compatibility with other ND functionality This specification applies to all types of IPv6 addresses: LLA, ULA, and GUA. IID generation should be done separately per every link/network according to [Different IIDs]. It is important for privacy. There is a discussion in the industry that link-layer addresses should be changed too to get better privacy. It is not a problem for the proposed algorithm to have a separate MAC for the separate link. Expires March 22, 2023 [Page 12] Internet-Draft ND-prefix-robustness September 2022 [Temporary addresses] recommendations have been reused in the proposed algorithm for compliance. It is not a problem to change the link-layer address together with IID at the time of mining (to have the link-layer address temporary too). ND Proxy claims the ownership of link-layer addresses on different media. Hence, it would be operational for its primary purpose - to interconnect separate media. ND Proxy fully impersonalizes the IP/Link-layer relationship for the different media. ND Proxy does not need to do mining - it should reuse all parameters received from the original node owning the IP/Link-layer association. This specification does not influence the protocol exchange. Hence, it is compatible with [ND] and its many modifications (Optimistic DAD, NUD improvements, Gratuitous ND, Multihoming, etc). The proposal may replace deep snooping and automatic filtering by SAVI. Many node redundancy schemes share link-layer addresses (MAC) then it is not a problem to share "Information for IID" between such nodes and keep IP to link-layer association protected. The load balancer should have no problem distributing traffic between unique IP/Link-layer pairs. There is a special situation with Anycast if it is localized on one link because the same IP could not have a different link-layer address. Hence, this specification should be disabled on the routers for this link. Anycast distributed between links (a more typical situation) is not a problem because the IP to the link-layer association has a local significance for the link. A duplicate link-layer address initiates flapping which is a typical problem for switching infrastructure. It should be investigated anyway. Switches typically have the functionality to automatically suppress flapping link-layer addresses or ports. 8. Security Considerations This document closes some ND vulnerabilities by cryptographic methods popular in the blockchain. IP Address ownership is securely associated with the link-layer address. Expires March 22, 2023 [Page 13] Internet-Draft ND-prefix-robustness September 2022 This specification does not prevent replay attacks. If the victim node is absent on the link then the malicious node could change his link-layer address (MAC) to the victims' then claim IP/Link-layer association replaying previously saved ND messages. It may not happen for link layers that are protected by themselves (typically encryption implemented on any wireless). If successful, then the intruder may impersonate the absent victim and ask for credentials as a minimum. It has a low probability because the server is typically always available but the client is not receiving incoming connections. As it was stated in the abstract the level of protection is equal to the level of link layer protection. If it is possible to impersonate the address at the link-layer then IP layer protection would not help, certification authority and end-to-end traffic encryption are needed. Replay protection needs different Nonce included into every message then encrypt and decrepit every message that is a very expensive proposition for [ND]. Canceling a trusted anchor would make all nodes equal that does not permit the restriction of the router's functionality to particular nodes. Hence, this specification could not deprecate [RA-Guard] and [RA-Guard+]. This specification does not prevent denial of service attacks in general. It is possible to generate many legal IP/Link-layer associations (presumably with a low level of mining by Chg parameter) and try to overwhelm other nodes on the link with additional states. 9. IANA Considerations The new option "Digest of IID information Option" is specified with the type number TBD. It is registered in the section "IPv6 Neighbor Discovery Option Formats" of the [ICMPv6] registry. 10. References 10.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, . Expires March 22, 2023 [Page 14] Internet-Draft ND-prefix-robustness September 2022 [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, . [IID significance] B. Carpenter, S. Jiang, D. Thaler, W. Liu, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . [Different IIDs] F. Gont, A. Cooper, D. Thaler, W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . [Temporary addresses] F. Gont, S. Krishnan, T. Narten, R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, . [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, . 10.2. Informative References [SEND] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, June 2004, . [HBA] M. Bagnulo, "Hash-Based Addresses (HBA)", RFC 5535, DOI 10.17487/RFC5535, June 2009, . Expires March 22, 2023 [Page 15] Internet-Draft ND-prefix-robustness September 2022 [CGA] T. Aura, "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . [Hash in Sec] M. Bagnulo, J. Arkko, "Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)", RFC 4982, DOI 10.17487/RFC4982, July 2007, . [ICMPv6] IANA, "Internet Control Message Protocol version 6 (ICMPv6) Parameters", . [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, . [RA-Guard+] F. Gont, "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", RFC 7113, DOI 10.17487/RFC7113, February 2014, . [ND MITM] E. Vasilenko, X. Xiao, " ND improvement to prevent Man-in- the-middle attack", draft-vasilenko-6man-nd-mitm- protection-00 (work in progress), September 2020. 11. Acknowledgments Thanks to the 6man working group for problem discussion. Authors' Addresses Eduard Vasilenko Huawei Technologies 17/4 Krylatskaya st, Moscow, Russia 121614 Email: vasilenko.eduard@huawei.com Expires March 22, 2023 [Page 16]