Use of the ILNP Nonce Destination Option Header

1.1. Purpose

The purpose of this document is to clarify for the Nonce Header the following:¶

1. Purpose: what it is intended for in ILNP.¶

2. Design: the nature and use of values in the Nonce Value field.¶

3. Usage: when and how the Nonce Header should be used in ILNP packets.¶

The current RFC documents are not totally clear on points 1. and 2., and this document changes the description with respect to point 3. The key changes are all summarised in Section 4, and the rest of the document provides context and discussion.¶

This document does not change the structure of the Nonce Header, which remains as defined in [RFC6744].¶

1.2. Rationale

The Nonce Header is as defined in [RFC6744], and has been assigned type value 0x8b by IANA: it is essential for the correct operation of ILNP. The current definition and use of the Nonce Header states that it should only be present in some packet exchanges for an ILNP session but not all packets. Clarification is needed to ensure that the design and usage of the Nonce Header is clear and consistent. The clarifications and changes defined in this document will simplify packet processing for ILNP packets.¶

2.1. Definitions from other documents

The following terms are defined in [RFC6740]:¶

• Locator, L64¶

• Node Identifier, NID¶

• Identifier-Locator Vector, I-LV¶

• I-L Communications Cache, ILCC¶

3.1. RFC6740 and RFC6741

The use of the Nonce Header is changed, and the use of the Nonce Value field in the Nonce Header is clarified. So, any reference to either should be read in the light of Section 4. Some key examples of how this document impacts text in RFC6740 and RFC6741 are given in Section 5.1.¶

3.2. RFC6744

The key changes with respect to RFC6744 are listed in Section 4, so, the reading of RFC6744 should now be in the light of Section 4. Some key examples of how this document impacts text in RFC6744 are given in Section 5.2.¶

5.1. Examples from RFC6740 and RFC6741

The core documents for the definition of the ILNP architecture and engineering are [RFC6740] and [RFC6741]. Each makes reference to the Nonce Header or the use of the Nonce Value. Some examples are:¶

1. From Section 8 of [RFC6740], inclusion of the Nonce Header in ILNP packets:
   ... will include the ILNP Nonce value in its initial packet(s) to the responder ...¶

2. From Section 9.1 of [RFC6740], use of the Nonce Header for flow protection:
   To reduce the number of on-path nodes that know the Nonce value for a given session when ILNP is in use, a nonce value is unidirectional, not bidirectional.¶

3. From Section 5.4 of [RFC6741], use of the Nonce Value for ILCC state management:
   For received packets containing an ILNP Nonce Option, lookups in the ILCC MUST use the <remote Identifier, Nonce> tuple as the lookup key. For all other ILNP packets, lookups in the ILNP Correspondent Cache MUST use the <remote Locator, remote Identifier> tuple, i.e., the remote I-LV, as the lookup key.¶

The benefits of NC1:¶

• For example 1 above, similar text appears in a number of places implying that the Nonce Header might not appear in some packets of a flow. However, it is not made explicit that the Nonce Header does not have to appear in every packet of a flow. Having the Nonce header in every ILNP packet avoids the problem where there is an IPv6 flow and an ILNP flow between the same two nodes and the values in the Source Address and Destination Address fields in the IPv6 packets are numerically identical. Without the Nonce Header, it is not possible to determine end-system packet handling at the receiver from inspection of the IPv6 packet header alone.¶

• For example 2 above, coupled with NC3, the presence of the Nonce Header in every packet of a flow provides better protection for the flow overall.¶

• For example 3 above, this is an unnecessary complexity: if the Nonce Header is in every packet, then there is no need for an alternative key tuple definition for identifying flows in the ILCC.¶

The benefits of NC2:¶

• For example 1 above, this is not relevant.¶

• For example 2 above, use of a unique Nonce Value for each ILNP communication session prevents an on-path attacker who learns of a Nonce Value from being able to make use of it for an attack on other ILNP communication sessions, e.g. by forging a new ILNP communication session.¶

• For example 3 above, the management of flow state in the ILCC is simplified by the use of a single key tuple for a flow.¶

The benefits of NC3:¶

• For example 1 above, this is not relevant.¶

• For example 2 above, it can be argued that the use of a bidirectional Nonce Value introduces no degradation of protection compared to use of two unidirectional Nonce Values. A suitably-placed on-path attacker could observe the Nonce Value in the packet exchange regardless of whether it is a unidirectional or bidirectional value. Meanwhile, coupled with NC1, the use of a bidirectional Nonce Value can be used as part of a handshake / synchronisation token for the two communicating parties, e.g. to help prevent off-path forged packets entering a flow at the start of a session when the initiating node is waiting to learn the value of the Nonce Value field in the reverse direction. Additionally, the Nonce Header is designed only to provide some lightweight protection for off-path attackers (please see Section 9 of [RFC6740] and Section 11 of [RFC6741]).¶

• For example 3 above, the management of flow state in the ILCC is simplified by ensuring that the key tuple is unique.¶

5.2. Examples from RFC6744

The Nonce Header is defined in [RFC6744] and includes the following text:¶

1. From Section 3.1 of [RFC6744], inclusion of the Nonce Header in ILNP packets:
   ... initial packet(s) of an IPv6 session ....¶

2. From Section 5.2 of [RFC6744], use of the Nonce Value in distinguishing between transport flows in case of clashes of NID values (ILCC state management):
   Multiple transport-layer sessions between a given pair of nodes normally share a single entry in the ILNP Communication Cache, provided their network-layer details (e.g., Identifiers, Nonces) are identical. Because two different ILNP nodes at two different locations might share the same Identifier value, it is important for an ILNP implementation to use the ILNP Nonce values to distinguish between different ILNP nodes that happen to be using the same (or some of the same) Identifier value(s).¶

3. From Section 6 of [RFC6744], the implication of the selective inclusion of the Nonce Header in ILNP packets:
   ILNPv6 nodes MUST include this option in the first few packets of each ILNPv6 session, MUST include this option in all ICMP messages generated by endpoints participating in an ILNPv6 session, and MAY include this option in any and all packets of an ILNPv6 session. It is recommended that this option be included in all packets of the ILNPv6 session if the packet loss for that session is known to be much higher than normal.¶

4. From Section 7 of [RFC6744], the Nonce Header is used for off-path protection:
   The ILNPv6 Nonce Destination Option only seeks to provide protection against off-path attacks on an IP session.¶

The benefits of NC1:¶

• For example 1 above, as described in Section 5.1, the inclusion of the Nonce Header in every ILNP packet is beneficial for packet processing.¶

• For example 2, coupled with NC3, the presence of the Nonce Header in every packet will allow better state management in the ILCC.¶

• For example 3, the text is now redundant, simplifying the overall description.¶

• For example 4, this document makes the issue of lightweight off-path protection an explicit objective for the Nonce Header in Section 4, and makes clear that it is a lightweight protection only against off-path attackers.¶

The benefits of NC2:¶

• For example 1 above, this is not relevant.¶

• For example 2 above, the text is now redundant, simplifying the overall description.¶

• For example 3 above, coupled with NC1, the text is now redundant, simplifying the overall description.¶

• For example 4 above, coupled with NC1, protection against off-path attacks is improved.¶

The benefits of NC3:¶

• For example 1 above, this is not relevant.¶

• For example 2 above, coupled with NC1, this will help to avoid state clashes in the ILCC.¶

• For example 3 above, the text is now redundant, simplifying the description.¶

• For example 4 above, there is a discussion in Section 5.1.¶

5.3. Example from RFC6748

[RFC6748] describes use cases and scenarios for ILNP. Many of the use cases employ an ILNP-aware Site Border Routers (SBR). RFC6748 is not modified by the contents of this document, but there is an improvement to be noted.¶

• From Section 3.2 of [RFC6748], the operation of a SBR or firewall would be improved if the Nonce Header is used consistently:
  Since ILNP requires that all Locator Update messages be authenticated by the ILNP Nonce, the SBR will need to include the appropriate Nonce values as part of its cache of information about ILNP sessions traversing the SBR. (NOTE: Since commercial security gateways available as of this writing reportedly can handle full stateful packet inspection for millions of flows at multi-gigabit speeds, it should be practical for such devices to cache the ILNP flow information, including Nonce values.)¶

The combination of NC1, NC2, and NC3 would make the operation of SBR or firewall functions for ILNP easier to implement and more consistent.¶