RFC 6496
Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
RFC 6496 🎀 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
Okay bestie, this is RFC 6496 from the Internet Engineering Task Force (IETF) 🌸. The Request for Comments number is 6496, the Category is Experimental 🧪, the ISSN is 2070-1721, and the date is February 2012 📅.
The authors are S. Krishnan (Ericsson), J. Laganier (Juniper Networks), M. Bonola (Rome Tor Vergata University), and A. Garcia-Martinez (UC3M) 🫶. The title block doesn't list anything this document obsoletes or updates, so it stands on its own ✨.
Abstract 💖
SEcure Neighbor Discovery (SEND) is the thing that locks down Neighbor Discovery (ND) signaling against specific threats 🔐. Right now SEND assumes that the node sending an ND message owns the address it's sending from, and/or has a key that lets it act as a router. So that node has to hold the private key or keys used to sign each message 🔑.
That's a problem for Proxy ND. A node that doesn't know the address owner's private key, and/or doesn't know a router's key, can't secure its signaling with SEND 💀. This document extends the current SEND specification so that Proxy ND operation can be secured 🦋.
Status of This Memo 📜
This is not an Internet Standards Track specification 🙈. It's published for examination, experimental implementation, and evaluation.
This document defines an Experimental Protocol for the Internet community 🧪. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 💅.
For info about the current status of this document, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6496 ✨.
Copyright Notice ©️
Copyright (c) 2012 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), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 🍓.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. Secure Proxy ND Overview ........................................4
5. Secure Proxy ND Specification ...................................5
5.1. Proxy Signature Option .....................................6
5.2. Modified SEND Processing Rules .............................8
5.2.1. Processing Rules for Senders ........................8
5.2.2. Processing Rules for Receivers ......................9
5.3. Proxying Link-Local Addresses .............................11
6. Application Scenarios ..........................................11
6.1. Scenario 1: Mobile IPv6 ...................................11
6.2. Scenario 2: Proxy Mobile IPv6 .............................13
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy .............16
7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes ..17
7.1. Backward Compatibility with RFC 3971 Nodes ................17
7.2. Backward Compatibility with Non-SEND Nodes ................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................22
10. Acknowledgements ..............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................231. Introduction 🌷
SEcure Neighbor Discovery (SEND) [RFC3971] is the method for securing Neighbor Discovery (ND) signaling [RFC4861] against specific threats [RFC3756] 🛡️. As defined today, SEND assumes the node sending an ND message owns the address that message comes from, and/or has a key that authorizes it to act as a router. That means it has to hold the private key or keys used to generate the digital signature on each message 🔑. So Proxy ND signaling, sent by nodes that don't know the address owner's private key and/or a router's key, can't be secured using SEND 😭.
This document extends the current SEND specification with support for Proxy ND ✨. From here on, we call that extension "Secure Proxy ND Support for SEND" 💅.
2. Requirements Notation 📐
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.
3. Terminology 📖
Secure ND Proxy
A node acting on behalf of another node and authorized to secure a Neighbor Discovery Protocol (NDP) message without knowing the private key related to the source address of the other node, or the key related to the router authorization 🧚.
Proxied IPv6 address
An IPv6 address that does not belong to the Secure ND Proxy and for which the Secure ND Proxy is performing advertisements 📣.
Non-SEND node
An IPv6 node that does not implement the SEND [RFC3971] specification, but uses the ND protocol defined in [RFC4861] and [RFC4862], without additional security 🙈.
RFC 3971 node
An IPv6 node that does not implement the specification defined in this document for Secure Proxy ND support, but uses the SEND specification as defined in [RFC3971] 🌈.
Secure Proxy ND (SPND) node
An IPv6 node that receives and validates messages according to the specification defined in this document for Secure Proxy ND support 💜.
Translated NDP message
An NDP message issued by a Secure ND Proxy as a result of a received NDP message. That received message was originated either by the owner of the address, or by another node acting on behalf of the owner of the address 🔁.
Synthetic NDP message
An NDP message issued by a Secure ND Proxy that is not the result of a received NDP message 🪄.
4. Secure Proxy ND Overview 🦋
The original SEND specification [RFC3971] implicitly assumed that only the node sending an ND message is the owner of the address that message comes from 🙃. That assumption doesn't allow ND messages to be proxied, because the advertiser is required to generate a valid RSA Signature option. That in turn requires possession of the public-private key pair that was used to generate a Cryptographically Generated Address (CGA), or that was associated with a router certificate 🔐.
To separate the roles of owner and advertiser, these extensions to the SEND protocol are defined:
- A Secure Proxy ND certificate, which is a certificate authorizing an entity to act as an ND proxy 📜. It's an X.509v3 certificate where the purpose it's issued for has been specified explicitly, as described in a companion document [RFC6494]. Briefly, Secure Proxy ND certificates include one or more
KeyPurposeIdvalues. These can be used to authorize proxies to sign Router Advertisement (RA) and Redirect messages, or to sign Neighbor Advertisement (NA), Neighbor Solicitation (NS), or Router Solicitation (RS) messages on behalf of other nodes 🍰. Including this value lets the certificate owner proxy SEND messages for a range of addresses indicated in the same certificate. This certificate can be exchanged through the Authorization Delegation Discovery process defined in [RFC3971] 🤝. - A new Neighbor Discovery option called the Proxy Signature (PS) option 🌟. This option contains the hash value of the public key of the proxy, and the digital signature of the SEND message computed with the proxy's private key. The hash of the proxy's public key is computed over the public key contained in the Secure Proxy ND certificate. When an ND message contains a PS option, it MUST NOT contain CGA or RSA Signature options 🚫. The PS option MUST be appended to any NDP message (NA, NS, RS, RA, and Redirect) to secure it 🔏.
- A modification of the SEND processing rules for all ND messages: NA, NS, RS, RA, and Redirect 🛠️. When any of these messages containing a PS option is validated, it is considered secure ✅.
These extensions are applied in the following way:
- A Secure ND Proxy that proxies ND messages on behalf of a node can use the PS option to protect the proxied messages. This Secure ND Proxy becomes part of the trusted infrastructure, just like a SEND router 👑.
- The messages to be secured with the PS option are built according to [RFC4861] if they're synthesized by the Secure ND Proxy. Or they result from the processing rules defined in [RFC4389] if they're translated ND messages 🧩.
- For nodes to successfully validate secured proxied messages, the nodes MUST be aware of the Secure Proxy ND certificate (in the format described in [RFC6494]), and MUST apply the modified processing rules specified in this document 🥹. We call these nodes 'SPND nodes'. Note that the rules for generating ND messages in SPND nodes do not change, so these nodes behave as defined in [RFC3971] when they send ND messages 💖.
- To let SPND nodes know the certification path required to validate the public key of the proxy, devices responding to CPS (Certification Path Solicitation) messages with CPA (Certification Path Advertisement) messages are extended. This follows Section 6 of the SEND specification [RFC3971]. These devices support the certificate format specified in [RFC6494] and are configured with the appropriate certification path 🗺️.
5. Secure Proxy ND Specification 💅
A Secure ND Proxy performs all the operations described in the SEND specification [RFC3971]. It also gets new processing rules, so the receiving node can identify an authorized proxy generating a translated or synthetic SEND message for a proxied address 🕵️♀️.
This works by signing the message with a private key of the authorized Secure ND Proxy. That proxy's signature goes into a new option called the PS option 🔏. The signature is performed over all the Neighbor Discovery Protocol (NDP) options present in the message, and the PS option is appended as the last option in the message 🫶.
5.1. Proxy Signature Option
okay bestie, so the Proxy Signature option is how signatures based on public keys get attached to NDP messages 🔐✨ here's the layout, it's giving very organized 🎀
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: PS Option Layout
Type 💖 this is always 32, no notes
Length 📏 the length of the option (counting the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets
Reserved 🫶 a 16-bit field saved for future use. The sender MUST initialize it to zero, and the receiver MUST ignore it.
Key Hash 🔑 a 128-bit field holding the most significant (leftmost) 128 bits of a SHA-1 [SHA1] hash of the public key that was used to build the signature. Its whole job is to link the signature to a particular key the receiver already knows. That key MUST be the same one inside the matching Secure Proxy ND certificate. iconic energy, no notes 👑
Digital Signature ✍️ this one is variable-length and holds a PKCS#1 v1.5 signature. The sender makes it with their private key over the following sequence of octets:
- The 128-bit CGA Message Type tag [RFC3972] value for Secure Proxy ND,
0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. (The tag value has been generated randomly by the editor of this specification.) - The 128-bit Source Address field from the IP header.
- The 128-bit Destination Address field from the IP header.
- The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
- The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to, but not including, NDP options.
- All NDP options preceding the Proxy Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [RSA]. This field starts after the Key Hash field. The length of the Digital Signature field is determined by the ASN.1 BER coding of the PKCS#1 v1.5 signature. 🧠
Padding 🎈 this is variable-length and holds padding. Its length is whatever the Proxy Signature option length is, minus the length of the other fields.
5.2. Modified SEND Processing Rules
this spec tweaks the sender and receiver processing rules from the SEND spec [RFC3971], so we're literally updating the rulebook 📖💅
5.2.1. Processing Rules for Senders
okay, the big rule here: a Secure ND Proxy MUST NOT use a key to sign NDP message types that don't match the authorization given to that key. 🚫 NA, NS, and RS messages MUST be signed with a key that matches a Secure Proxy ND certificate with a KeyPurposeId value [RFC6494] of id-kp-sendProxiedOwner, and the source addresses of those messages MUST be inside the prefix tied to the certificate. RA and Redirect messages MUST be signed with a key matching a Secure Proxy ND certificate with a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix in the RA message used for on-link determination and/or stateless address autoconfiguration, and the Target Address of the Redirect message, MUST be inside the prefix tied to that certificate. main character energy for these certs 🌈
A secured NDP message that a Secure ND Proxy sends for a proxied address MUST contain a PS option and MUST NOT contain either CGA or RSA Signature options. Section 7 talks about which cases need an NDP message to be secured in a scenario that includes non-SEND nodes 👀
The input to this process is a message gotten in either of these ways:
a. If the Secure ND Proxy generates synthetic SEND messages for a proxied address, the message MUST be constructed as described in the Neighbor Discovery for IP version 6 specification [RFC4861].
b. If the Secure ND Proxy translates secured messages, the authenticity of the intercepted message MUST be verified first. If the intercepted message is a SEND message, it MUST be validated as specified in Section 5 of the SEND specification [RFC3971]. If the intercepted message contains a PS option, the authenticity of the message MUST be verified as detailed in Section 5.2.2 of this specification. After validation, the CGA, RSA, or PS options of the original message MUST be removed. Then, the message to be translated MUST be processed according to the ND Proxy specification [RFC4389]. This is how it gets decided whether the message received should be proxied or not, the proxy interface status gets updated if needed, the outgoing interface is determined, the link-layer header and the link-layer address within the payload get modified if required, etc. 🪄
A Secure ND Proxy then modifies the input message like this:
- Timestamp and Nonce options MUST be included according to the rules in SEND [RFC3971]. The value in the Timestamp option MUST be generated by the proxy. If the proxy is translating a message that includes a nonce, the Nonce value in the proxied message MUST be the same as in the intercepted message. If the proxy is synthesizing a solicitation message, the Nonce value MUST be generated by the proxy. If the proxy is synthesizing an advertisement message, the Nonce value MUST correspond to the solicitation message the proxy is responding to.
- The Proxy Signature option MUST be added as the last option in the message.
- The data MUST be signed as explained in Section 5.1.
5.2.2. Processing Rules for Receivers
any SEND message without a Proxy Signature option MUST be treated as specified in the SEND specification [RFC3971], simple as that 🫧
a SEND message that includes a Proxy Signature option MUST be processed as specified below:
- The receiver MUST ignore any RSA and CGA options, as well as any options that might come after the first PS option. These options are ignored for both signature verification and NDP processing purposes.
- The Key Hash field MUST indicate the use of a known public key. A valid certification path (see [RFC6494] Section 9) between the receiver's trust anchor and the sender's public key MUST be known. The Secure Proxy ND X.509v3 certificate MUST contain an extended key usage extension that includes the right KeyPurposeId value and prefix for the message being validated:
- For RA messages, a KeyPurposeId value of
id-kp-sendProxiedRouterMUST exist for the certificate, and the prefix in the RA message used for on-link determination and/or stateless address autoconfiguration MUST be inside the prefix tied to that certificate. - For Redirect messages, a KeyPurposeId value of
id-kp-sendProxiedRouterMUST exist for the certificate, and the prefix in the Target Address of the Redirect message MUST be inside the prefix tied to that certificate. - For NA, NS, and RS messages, a KeyPurposeId value of
id-kp-sendProxiedOwnerMUST exist for the certificate, and the source addresses of the messages MUST be inside the prefix tied to the certificate.
- For RA messages, a KeyPurposeId value of
If any of these tests fail, the verification fails. 🙈
- The Digital Signature field MUST have correct encoding; otherwise, verification of the message including the PS option fails.
- The Digital Signature verification MUST show that the signature was calculated as specified in Section 5.1; otherwise, verification of the message including the PS option fails.
- The Nonce option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' with 'PS option'. If these tests fail, verification of the message including the PS option fails.
- The Timestamp option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' with 'PS option'. If these tests fail, verification of the message including the PS option fails. The receiver SHOULD store the peer-related timing information specified in [RFC3971] Sections 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each different proxy (which could be identified by the different Key Hash values of the proxied message), and separately from the timing information associated with the IP address of a node the message is proxied for. That way, a message received for the first time from a proxy (i.e., one with no information stored in the cache) for which the Timestamp option is checked SHOULD be checked as a message received from a new peer (as in [RFC3971] Section 5.3.4.2). 🕰️
- Messages with the Override bit [RFC4861] set MUST override an existing cache entry, no matter whether that entry was created by an RSA Signature option or a PS option validation. When the Override bit is not set, the advertisement MUST NOT update a cached link-layer address that was created securely by RSA Signature option or PS option validation. 🔒
Messages whose verification fails MUST be silently discarded if the node has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages, but they MUST be treated as unsecured messages. ✨
5.3. Proxying Link-Local Addresses ✨
okay bestie, so SEND [RFC3971] leans on certificates to prove that routers are allowed to announce a certain prefix 🔐. BUT, Neighbor Discovery [RFC4861] says routers don't announce the link-local prefix (fe80::/64) 🙈. So it's not required for a SEND certificate to have an X.509 IP address extension that authorizes fe80::/64 💅. HOWEVER, some Secure Proxy ND scenarios ([RFC4389], [RFC5213]) need the proxying function for a node's link-local address 🦋. So when Secure ND Proxy is needed for a link-local address, either a list of link-local addresses, or the fe80::/64 prefix, MUST be explicitly authorized to be proxied in the corresponding certificate 🫶. no skipping this one, it's a must!! 😭
6. Application Scenarios 🎀
okay so this section is giving "three scenarios, one vibe" 💖. We're looking at three different ways Secure Proxy ND support for SEND can be applied ✨. The exact setup (which ND messages get proxied, which direction, how things work with non-SEND hosts and RFC 3971 hosts, all that jazz) really depends on the scenario 🌸. In the first two scenarios, ND messages are synthesized on behalf of off-link nodes 🧚. In the third one, ND messages get translated from the messages received on the proxy's other interfaces 🔥.
6.1. Scenario 1: Mobile IPv6 🦋
the problems with deploying SEND in this scenario are described in [RFC5909], so go check that out too 💜.
Mobile IPv6 (MIPv6) [RFC6275] lets a Mobile Node (MN) move from one link to another while staying reachable at a stable address, called the MN's Home Address (HoA) 🌈. When an MN is on a foreign network, packets sent to the MN's HoA by a Correspondent Node (CN) on the home link, or by a router, get intercepted by the Home Agent (HA) on that home link, encapsulated, and tunneled to the MN's registered Care-of Address (CoA) 📦.
To deploy Secure Proxy ND here, meaning to secure the HA operation, a Secure Proxy ND certificate with a KeyPurposeId value of id-kp-sendProxiedOwner for the home link's prefix is required 🔐.
The Secure ND Proxy is configured with the private key tied to this certificate 🗝️. When the HA on the home link intercepts an NS, it checks whether the Target Address in the NS matches any of the MN's Home Addresses in the binding cache. If it does, the HA replies with a Neighbor Advertisement (NA) built as described in [RFC4861], containing its own link-layer address (HA_LL) as the Target Link-Layer Address Option (TLLAO) 💌. Then a timestamp (generated by the proxy) and a nonce (if appropriate, according to [RFC3971]) MUST be included 🕰️. Finally, a PS option signing the message MUST be included as the last option of the message 🔏.
Node (N) Home Agent (HA) Mobile Node (MN)
on Home Link on Home Link on Foreign Link
| | |
| SRC = N | |
| DST = solicited_node (MN) | |
| ICMPv6 NS | |
| TARGET = MN | |
| SLLAO = N_LL | |
| [CGA] | |
| RSA signature | |
|-------------------------->| |
| | |
| SRC = HA | |
| DST = N | |
| ICMPv6 NA | |
| TARGET = MN | |
| TLLAO = HA_LL | |
| PS signature | |
|<--------------------------| |
| | |
| traffic | |
| dest = MN HoA | |
|-------------------------->| |
| | |
| | tunneled traffic |
| | dest = MN CoA |
| |------------------------->|
| | |
Figure 2: Proxy ND Role of the Home Agent in MIPv6A node that gets the NA containing the PS option (like the CN on the home link, or a router) MUST apply the rules defined in Section 5.2.2. 🫶 Also, the Override bit of the NA message is what decides which message wins in each case: the one the proxy generated when the MN leaves the home network, or the MN's own message if it comes back to the home link, as defined in the MIPv6 specification [RFC6275] 🦋✨.
6.2. Scenario 2: Proxy Mobile IPv6 🌸
Proxy Mobile IPv6 [RFC5213] is a network-based mobility management protocol that gives IP mobility support to MNs without them having to take part in the mobility signaling 🙌. The whole mobility thing is hidden from the MN inside a Proxy Mobile IPv6 domain, and two functional entities handle it: the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG) 👑.
When the MN connects to a new access link, it sends a multicast Router Solicitation (RS) 📡. The MAG on the new access link notices the MN has attached and signals the LMA, asking it to update the MN's binding state (using a Proxy Binding Update (PBU)) 📨. Once that's done (the MAG gets a Proxy Binding Ack (PBA)), the MAG replies to the MN with a Router Advertisement (RA) containing the home network prefix(es) assigned to that mobility session 🎀. The MN thinks it's still on the same link, so the IPv6 address reconfiguration procedure isn't triggered (Figure 3) 💅.
MN new MAG LMA
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| | |
| SRC = MN | |
| DST = all routers | |
| ICMPv6 RS | |
| [CGA] | |
| RSA signature | |
|--------------------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
| SRC = MAG4MN | |
| DST = MN | |
| ICMPv6 RA | |
| SLL = MAG_LL | |
| PS | |
|<---------------------| |
| | |
| | |
| | |
Figure 3: Mobile Node's Handover in PMIPv6To avoid link-local address collisions between the MAG and the MN after a handoff to a new link, the Proxy Mobile IPv6 specification [RFC5213] requires that the MAG's link-local address on the MN's link be generated by the LMA when the MN first attaches to a PMIPv6 domain, and then handed to the MN's new serving MAG after each handoff 🧩. So from the MN's point of view, the MAG's link-local address stays constant for the whole session 🥰.
The approach above and the current SEND specification are incompatible 💀. Sharing the same link-local address across different MAGs would require all MAGs in a PMIPv6 domain to build the CGA and the RSA Signature option with the same public-private key pair, and that's not an acceptable security policy 🚫.
Using different key pairs on different MAGs would mean each MAG uses a different CGA as its link-local address 😵. Then the serving MAG's link-local address would change after every handoff of the MN, which contradicts how MAG link-local address assignment works in a PMIPv6 domain 😤.
To provide SEND protection, each MAG MUST be configured to act as a proxy by means of a certificate associated with the PMIPv6 domain 🔐. That certificate authorizes each MAG to securely proxy NA and RS messages with a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the certificate MUST also authorize the MAG to advertise prefixes by associating a KeyPurposeId value of id-kp-sendProxiedRouter with that same certificate 📜. Note that multiple KeyPurposeId values are supported by [RFC6494] 🌈.
When a MAG replies to an RS with an RA, the source address MUST be equal to the MAG link-local address associated with the MN in this PMIPv6 domain, and the source link-layer address is the MAG's own link-layer address 🎯. Then a timestamp (generated by the proxy) and a nonce (if appropriate, according to [RFC3971]) MUST be included 🕰️. Finally, a PS option signing the message MUST be included as the last option of the message 🔏. This same procedure is followed for any other ND message the MAG could generate to the MN 💖.
A node that receives a message from the MAG containing the PS option MUST apply the processing rules defined in Section 5.2.2 💅. Also, unsolicited messages sent by the MAG SHOULD be validated by the host according to timestamp values specific to the MAG serving the link, not to any other MAG the host was connected to on other links, following processing step number 6 of Section 5.2.2 🦋✨.
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy ✨
okay so this scenario is the one where the proxy is basically a classic [RFC4389] ND proxy, and the deployment problems for it are written up in [RFC5909] 💅
Link 1 Link 2
Host A ND Proxy (P) Host B
| | |
| SRC = A | |
| DST = solicited_node (B) | |
| ICMPv6 NS | |
| TARGET = B | |
| SLLAO = A_LL | |
|------------------------->| |
| | SRC = A |
| | DST = solicited_node (B) |
| | ICMPv6 NS |
| | TARGET = B |
| | SLLAO = P_LL |
| |------------------------->|
| | |
| | SRC = B |
| | DST = A |
| | ICMPv6 NA |
| | TARGET = B |
| | TLLAO = B_LL |
| |<-------------------------|
| SRC = B | |
| DST = A | |
| ICMPv6 NA | |
| TARGET = B | |
| TLLAO = P_LL | |
|<-------------------------| |
| | |Figure 4: RFC 4389 Neighbor Discovery Proxy Operation 🦋
okay so the ND Proxy spec in [RFC4389] is what lets multiple link-layer segments get bridged into one single segment, and it also spells out the IP-layer bits that make that bridging work 🌸
now here's the big one 👀 a Secure ND Proxy MUST parse every IPv6 packet it gets on a proxy interface to see if it's one of these NDP messages: NS, NA, RS, RA, or Redirect 🔍 and it MUST verify the authenticity of that ND message too, either according to [RFC3971], or according to Section 5.2.2 if the message has a PS option 🔐
then, once the CGA, RSA, or PS options are removed, the message being translated MUST get processed according to the ND Proxy spec [RFC4389] 💖 that means doing the loop prevention checks, figuring out the outgoing interface, swapping the source link-layer address for the outgoing interface's address, changing the source link-layer addresses inside the payload (so the SLLAO or the TLLAO) ✨, keeping the destination link-layer address as whatever the neighbor entry for the destination IPv6 address says, and setting the P bit for proxied RA messages, etc. 🎀
bestie, the tea is that besides the link-layer addresses and the P bit of an RA, nothing else in the received message gets changed when an [RFC4389] proxy handles it 🙈
and for any other IPv6 unicast packet that hits a proxy interface: if it's not locally destined, it gets forwarded unchanged (other than a new link-layer header) to whichever proxy interface has the next-hop address in its neighbor cache 🧚 if there's no neighbor cache entry at all, the Secure ND Proxy SHOULD queue the packet and kick off Neighbor Discovery signaling as if the NS were locally generated 💅
to sign any NS, NA, RS, RA, or Redirect message, the key MUST correspond to a certificate with KeyPurposeId values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter. no exceptions, babe 💀
and last but not least, to deploy this scenario, nodes in the proxied segments MUST know about the certificate-authorizing proxy operation 🫶 so it could be needed that at least one device per proxied segment (maybe the proxy itself) is set up to pass along the required certification path, to authorize proxy operation through a CPS/CPA exchange 👑
7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes 🌈
okay so this section is all about how Secure ND Proxies and SPND nodes get along with RFC 3971 nodes and non-SEND nodes 🤝 as [RFC3971] says, network operators might want to run a mix of nodes that accept secured and unsecured NDP messages at the same time, and so a Secure ND Proxy or SPND node SHOULD support secured and unsecured NDP messages together ✨
7.1. Backward Compatibility with RFC 3971 Nodes 🧚
RFC 3971 nodes (aka SEND nodes that don't have the Section 5 modifications) can't correctly interpret a PS option that shows up in a proxied ND message 😭 they just silently drop the PS option, the way [RFC4861] says to handle any unknown option, so those messages end up being treated as unsecured, as described in Section 8 ("Transitions Issues") of the SEND spec [RFC3971] 🙈
when RFC 3971 nodes and SPND nodes swap ND messages (no proxy involved), in either direction, the messages are generated according to the SEND spec [RFC3971], so they interoperate seamlessly 💜
in the scenarios where the proxy translates ND messages, those messages can come from either an RFC 3971 node or an SPND node, and there aren't any interoperability issues 🦋 (the only real difference between RFC 3971 nodes and SPND nodes is whether they can process received NDP messages that contain a PS option. it doesn't change how they generate SEND-secured messages 💅)
a configuration option MAY exist in a Secure ND Proxy to list the RFC 3971 nodes it's connected to, so the proxied messages going to those nodes aren't run through the Secure Proxy ND spec, for performance reasons 🏎️💨
7.2. Backward Compatibility with Non-SEND Nodes 🌸
non-SEND nodes that receive NDP packets silently discard PS options, same as [RFC4861] says for any unknown option 🫠 so those nodes just read messages proxied by a Secure ND Proxy as any other ND message 🎀
when non-SEND nodes and SPND nodes swap ND messages (no proxy in between), in either direction, the rules in Section 8 of [RFC3971] apply 📜
a Secure ND Proxy SHOULD support secured and unsecured NDP messages at the same time, although it MAY have a configuration that stops proxying for unsecured NDP messages 💖 it also MAY have a config option that turns secure ND proxying off completely 🙅♀️ this config SHOULD be switched off by default, meaning security is on by default ✨
next up we talk about the recommended behavior of the Secure ND Proxy when it comes to how much protection to give proxied messages in a mixed scenario with SPND/RFC 3971 nodes and non-SEND nodes 🧩 there are two different situations, depending on whether the proxied nodes are RFC 3971 or SPND nodes, or non-SEND nodes 👀
as a rule of thumb 📏 if the proxied nodes can come back to the link the proxy operates on, the Secure ND Proxy MUST only generate PS options for nodes with SEND capabilities (aka nodes that could use SEND to defend their messages if they were on the same link as the proxy, so basically RFC 3971 nodes or SPND nodes) 🔐 this matters so nodes can prefer secured info over unsecured info, and so the Duplicate Address Detection (DAD) procedure runs properly, as specified in [RFC3971] 🫶 so in this case the Secure ND Proxy MUST synthesize/translate messages with the PS option for SPND and RFC 3971 hosts, and MUST NOT synthesize/translate messages with the PS option for non-SEND nodes 🚫 also, ND advertisements sent in response to solicitations generated by a Secure ND Proxy must be secured or not secured based on the above (aka the nature of the proxied node), and not based on whether the solicitation was secured or unsecured 💅
to apply this rule, the Secure ND Proxy needs to know the security capabilities of the proxied node 🕵️♀️ how it gets that info depends on the application scenario, and we'll get into that next:
- okay, for scenarios where ND messages get translated for nodes that can arrive on the link the proxy operates on, the rule is pretty easy: only for messages validated in the Secure ND Proxy under the SEND spec [RFC3971], or under Section 5.2.2 of this spec for messages that have a PS option (which means another proxy already checked the original message was secured), the message MUST be proxied securely by including a PS option ✨ unsecured ND messages can be proxied if unsecured operation is enabled on the proxy, but the message the Secure ND Proxy makes for the received message MUST NOT include a PS option 🙈
- for scenarios where ND messages are synthesized on behalf of remote nodes, the considerations are different depending on the particular application scenario 🧚
- for MIPv6, if the MN can return to the home link, the proxy is required to know whether the node could use SEND to defend its address or not 🔍 a HA that includes the PS option when proxying a non-SEND MN would make the proxy's ND messages more preferred than the ND message from the non-SEND MN when it returns to the home link (even if the proxied messages have the Override bit set to 1) 😬 and not using the PS option for an RFC 3971 or SPND MN would make the address on the home link more vulnerable while the MN is away than when it's on the home link, which defeats the whole point of the Secure Proxy ND mechanism 💀 so in this case the HA MUST know the SEND capabilities of the MN, MUST use the PS option if the MN is an SPND or RFC 3971 host, and MUST NOT use the PS option for non-SEND hosts 👑
- for the Proxy Mobile IPv6 scenario, a node moving from a link where the PS option protected a link-layer address to a link where ND messages aren't protected by SEND would stop the MN from getting the new info until the cached info expires 🥲 but in this case it's considered reasonable that all MAGs provide the same protection for ND messages, and that either all MAGs or no MAGs behave as a Secure ND Proxy, so config should be easier 🌷
a configuration option MAY exist in a Secure ND Proxy to list the non-SEND nodes it's connected to, so the proxied messages going to those nodes aren't run through the Secure Proxy ND spec, for performance reasons 🏎️✨
8. Security Considerations 🔐✨
okay bestie, this is the serious part, so get ready 💀 The mechanism here adds a brand new PS option that lets a Secure ND Proxy synthesize or translate a SEND message for a proxied address, redirect traffic for given target addresses, or advertise prefix information through RA messages 🎀 An SPND node only accepts one of these messages if it includes a valid PS option generated by a properly authorized Secure ND Proxy. That proxy needs a certificate with the right KeyPurposeId: id-kp-sendProxiedOwner for protecting NA, NS, and RS messages, or id-kp-sendProxiedRouter for protecting RA and Redirect messages. A message like that is protected against the threats in Section 9 of [RFC3971], which is basically the same level of protection you'd get from a message signed with an RSA Signature option. Literally a whole vibe 🔥
Now the proxied ND messages that don't have a PS option? Those are just as secure as any normal unsecured ND message 🙈 The same goes for a proxied ND message that lands on a non-SEND host or an RFC 3971 host. No extra protection, no extra drama.
When an SPND node gets a message with a PS option, it removes any CGA or RSA options that are also in there and then keeps processing the rest of the message 💅 Properly formed proxied messages MUST NOT include PS and CGA/RSA options at the same time, but if they do show up, tossing them out doesn't hurt security at all. If the PS option checks out, then the info in the message really was generated by a proxy, so it should be honored. (Remember, anti-replay protection comes from the Nonce and Timestamp options 🧚) If the PS option doesn't validate, the message gets treated like an unsecured message. Either way, an attacker gains nothing by tacking false or old CGA/RSA info onto a message that a Secure ND Proxy already secured. No cap 🙅♀️
⚠️ Serious moment: a compromised Secure ND Proxy with an authorization certificate whose KeyPurposeId isid-kp-sendProxiedRoutercan do the same things a compromised router can. That means it can siphon off traffic from the host or pull off a man-in-the-middle attack for hosts talking to off-link hosts. A compromised Secure ND Proxy withid-kp-sendProxiedOwnercan siphon off traffic or run a man-in-the-middle attack on communication between on-link hosts, even when those hosts are using SEND 😭 Different application scenarios might need one kind of authorization, the other kind, or both. So to keep risks low, authorization capabilities MUST NOT exceed what the application scenario you're deploying strictly requires. Keep it tight, babe 💖
The messages a Secure ND Proxy handles, and the link where it does that job, MUST be configured appropriately for each proxy and each scenario 🍓 This config matters even more when Secure Proxy ND is translating ND messages from one link to another.
Section 7 covers the security stuff that comes from choosing whether or not to add the PS option, which depends on whether the proxied nodes are SEND-aware 🦋
Replay protection for unsolicited messages like NA, RA, and Redirects is handled by the Timestamp option ⏰ When you're using Secure ND Proxy, each host and each proxy acting for that host count as different peers when it comes to timestamp verification. The host and a proxy can have different info, including different link-layer addresses, so a replay attack could mess with a third node 😬 Replaying messages from a host that's no longer on the link can block the use of a proxy. Replaying a proxy's messages after the host is back on the link can block communication with that host. This kind of attack can keep going until the timestamp of the peer (the host or a proxy) is no longer valid for the receiver. The window of vulnerability is usually bigger for the first message from a new peer than for later messages from that same peer (see [RFC3971]). For a deeper dive into attacks related to the Timestamp option, check out Section 6.3 of [RFC5909] 🧠✨
9. IANA Considerations 🌸
IANA has given the PS option a new IPv6 Neighbor Discovery Option type, and the number is 32 💜 That value came from the namespace in the IANA "IPv6 Neighbor Discovery Option Formats" registry, which lives at http://www.iana.org/assignments/icmpv6-parameters.
IANA also gave a new 128-bit value to the "Cryptographically Generated Addresses (CGA) Message Type Name Space" registry [RFC3972], and it looks like this:
0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 280410. Acknowledgements 🫶
The text got better thanks to feedback from Jari Arkko, Jean-Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey Melnikov, Sandra Murphy, and Sean Turner. Literal legends 👑
The work of Alberto Garcia-Martinez was supported in part by the T2C2 project (TIN2008-06739-C04-01, granted by the Spanish Science and Innovation Ministry) 🇪🇸💅
11. References 📚
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, August 2008.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
Profile and Certificate Management for SEcure Neighbor
Discovery (SEND)", RFC 6494, February 2012.
[RSA] RSA Laboratories, "PKCS #1 v2.1: RSA Cryptography
Standard", June 2002.
[SHA1] National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1 , April 1995.11.2. Informative References
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, May 2004.
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Neighbor Discovery Proxy: Problem Statement", RFC 5909,
July 2010.Authors' Addresses 🎀
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Julien Laganier
Juniper Networks
1094 North Mathilda Avenue
Sunnyvale, CA 94089
USA
Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com
Marco Bonola
Rome Tor Vergata University
Via del Politecnico, 1
Rome I-00133
Italy
Phone:
EMail: marco.bonola@gmail.com
Alberto Garcia-Martinez
U. Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/📦 where this page comes from
- ietf: rfc6496 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms