Network Working Group T. Herbert Internet-Draft SiPanda Intended status: Standards Track 20 March 2024 Expires: 21 September 2024 Common Option Format for Host-Network Signaling draft-herbert-hnsigopt-00 Abstract This specification describes an option format for Hop-by-Hop and Destination Options for host-net signaling (host to network and network to host signaling). The format supports a uniform mechanism for sending signals and reflecting received signals back to an originating sender. While this document describes a format for IPv6 Hop-by-Hop options or Destination options, the base format for carrying signals is generic and could be the payload of other options mechanisms such as UDP Options or Geneve options. 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 21 September 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Herbert Expires 21 September 2024 [Page 1] Internet-Draft HNSIGOPT March 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol format . . . . . . . . . . . . . . . . . . . . . . . 4 3. Reflection properties . . . . . . . . . . . . . . . . . . . . 5 3.1. Don't reflect . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Actionable in the forward path and return path . . . . . 6 3.3. Forward path actionable, return path not actionable . . . 6 3.4. Forward path not actionable, return path actionable . . . 7 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Sender operation . . . . . . . . . . . . . . . . . . . . 7 4.2. Intermediate node operation . . . . . . . . . . . . . . . 7 4.3. Receiver operation . . . . . . . . . . . . . . . . . . . 8 4.3.1. Receiving a don't reflect option . . . . . . . . . . 8 4.3.2. Receiving an option to be reflected . . . . . . . . . 8 4.3.3. Reflecting signals . . . . . . . . . . . . . . . . . 8 4.3.4. Receiving a reflected signal . . . . . . . . . . . . 9 5. Implementation Considerations for Reflection . . . . . . . . 9 5.1. Reflection with TCP . . . . . . . . . . . . . . . . . . . 9 5.2. Reflection with UDP . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This specification describes a simple and extensible option format for in-situ signaling between hosts and the network. The format is applicable to host to network as well as network to host signaling, and we refer to the union of both use cases as "host-net signaling". Herbert Expires 21 September 2024 [Page 2] Internet-Draft HNSIGOPT March 2024 Signaling has two facets: "signal carrier" and "signal content". This specification focuses on creating a common carrier format for host-net signaling. The format must be extensible to support use cases for different types of host-net signal content. Host-net signals are expressed in IPv6 Hop-by-Hop or Destination Options before the Routing Header [RFC8200]. A sender may "piggyback" host-net signals on application packets using these options. Host to network signals are not modified by intermediate nodes and so use an "unmodifiable" option type (the third high order bit in the type is zero). Network to host signals are modified by intermediate nodes and therefore use a "modifiable" option type (the third high order bit in the type is one). A common technique of signaling is for a receiver to "reflect" the signal back to the host. We refer to path from a sender to a receiver as the "forward path" of a signal, and the reverse path from the receiver to the sender as the "return path". A non-reflected signal is sent on the forward path, and a reflected signal is sent on the return path. When signal reflection is used, the signal sent on the forward path or return path may be "actionable" or "not actionable". An actionable signal is one that is processed by on-path elements, a non-actionable signal is ignored by on-path elements. The purpose of non-actionable signals is to transport a signal without interpretation by intermediate nodes. For instance, in the case of IOAM a non-actionable signal is reflected to report the telemetry gathered in the forward path. Actionable signals are carried in Hop-by-Hop Options or Destination Options before the Routing Header. Hop-by-Hop Options are used to signal all on-path elements, and Destination Options before the Routing Header are used to signal intermediate destinations in a Routing Header. Non-actionable signals are carried in Destination Options after the Routing Header (or just Destination Options if there is no Routing Header in the packet). 1.1. Related work There have been a number of proposals for Hop-by-Hop and Destination Options formats for both host to network and network to host signaling. [I-D.eckert-6man-qos-exthdr-discuss] proposes a common option format for QoS as a form of host to network signaling. [I-D.shi-ippm-congestion-measurement-ipv6-options] proposes a common format for congestion measurement as a form of network to host signaling. [I-D.herbert-fast] proposes a format for a Hop-by-Hop option to carry Firewall and Service Tickets as a form of host to Herbert Expires 21 September 2024 [Page 3] Internet-Draft HNSIGOPT March 2024 network signaling. In this draft, we consolidate the ideas of previous work into one general proposal for conveying host to network and network to host signaling. The format should be compatible with all proposed use cases of host-net signaling, and includes procedures and protocol for reflecting signals. 1.2. Terminology 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]. 2. Protocol format Host-net signals may be carried in Hop-by-Hop or Destination options. We refer to an option for carrying a signal as a "signal option". The base format of a signal option is a single byte composed of a Pr field and a Type field. The Pr fields indicates the reflection properties of the signal as discussed in Section 3. The Type field indicates the type and format of the payload following the first byte The format of this byte is shown below: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Pr | Type | +-+-+-+-+-+-+-+-+ The format of a signal option in a Hop-by-Hop or Destination option is illustrated below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len |Pr| Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: * Option Type=0xf [TBD]: Type of Hop-by-Hop or the Destination Herbert Expires 21 September 2024 [Page 4] Internet-Draft HNSIGOPT March 2024 option. Two option types are requested, one with third high order bit set to indicate that the option is modifiable en route (i.e. it is a network to host signal), and one type where the third high order bit is not set to indicate that the option is not modifiable en route (i.e. it is a host to network signal). The high order two bits of the option type are 00 to indicate that an unknown option should be skipped and no ICMP error is sent. * Opt Data Len: Length of the option data field. The option data is comprised the Pr-Type byte, and the Data. * Pr: Indicates properties of the signal option for reflection and path processing. Handling of the reflection property is described in Section 3. Possible values are: 0: Don't reflect 1: Reflect as actionable 2: Reflect as non-actionable 3: Reflected * Type: Type of the host-net signal. This field determines the format of the following payload in the option * Data: The signal content. The format is indicated by the Type field 3. Reflection properties There are four basic reflection properties of signal options: * Don't reflect * Actionable in the forward path and return path * Forward path actionable, return path not actionable * Forward path not actionable, return path actionable 3.1. Don't reflect A signal option with this property is sent in Hop-by-Hop Options or Destination Options before a Routing Header with Pr set to 0 (Don't reflect). Intermediate nodes may process the option. At a receiver, the signal option is not reflected. Herbert Expires 21 September 2024 [Page 5] Internet-Draft HNSIGOPT March 2024 Signal options with this property are uni-directional signals that are always actionable in the forward path. This property is useful in host to network signaling to affect the forward path of communications, for instance to request QoS or other services in the forward path of a flow. 3.2. Actionable in the forward path and return path A signal option with this property is sent in Hop-by-Hop Options or Destination Options before a Routing Header with Pr set to 1 (Reflect as actionable). Intermediate nodes may process the option in the forward path. At a receiver, the option is reflected in Hop-by-Hop Options or Destination Options before a Routing Header and intermediate nodes may process the reflected option in the return path. When an option with this property is reflected by a receivers, it is sent in a Hop-by-Hop Options or Destination Options before the Routing Header. If the original signal option was received in a Hop- by-Hop option, then it is reflected in a Hop-by-Hop option. If the original signal was received in Destination Options before the Routing Header then the signal is reflected in Destination Options before the Routing Header, except if packets sent on the return path don't contain a Routing Header in which case the signal option is not reflected. Signal options with this property are useful in host to network signaling to affect both directions of communications, for instance to request that the same QoS be applied bidirectionally. They may also be useful in network to host signaling to gather telemetry for both directions of a communication in the same option. 3.3. Forward path actionable, return path not actionable A signal option with this property is sent in Hop-by-Hop Options or Destination Options before a Routing Header with Pr set to 2 (Reflect as non-actionable). Intermediate nodes may process the option in the forward path. At a receiver, the option is reflected in Destination Options after the Routing Header and intermediate nodes do not process the reflected option in the return path. When the option is reflected by a receivers, it is sent in Destination Options after the Routing Header or just Destination Options if there is no Routing Header being sent in the packet. Herbert Expires 21 September 2024 [Page 6] Internet-Draft HNSIGOPT March 2024 Signal options with this property are useful in network to host signaling to return information gathered in the forward path, for instance an IOAM option might be reflected to report telemetry collected from routers in the forward path. 3.4. Forward path not actionable, return path actionable A signal option with this property is sent in Destination Options after the Routing Header with Pr set to 1 (Reflect as actionable). Intermediate nodes do not process the option in the forward path. At a receiver, the option is reflected in Hop-by-Hop Options and intermediate nodes may process the reflected option in the return path. When the option is reflected by a receivers, it is sent in Hop-by-Hop Options. Note that there is no means to request that a signal option is not actionable in the forward path and should be reflected in Destination Options before the Routing Header (this mode does not seem particularly useful). Signal options with this property are useful in network to host signaling to gather information in the return path, for instance an IOAM option might be reflected to gather telemetry in the forward path. The property may also be used in host to network signaling to affect only the return path of communications, for instance to request QoS or other services only for the return path of a flow. 4. Operation 4.1. Sender operation A sender MAY include one or more signal options in a packet. A sender SHOULD apply extension header limits in [I-D.ietf-6man-eh-limits]. If a sender includes more than one actionable signal option in a packet, it SHOULD order them in decreasing order of importance [I-D.ietf-6man-hbh-processing]. A sender SHOULD send at most one signal option for each type and reflection property. 4.2. Intermediate node operation An intermediate node MAY process actionable signal options it receives. These are signal options in Hop-by-Hop Options or signal options in Destination Options before the Routing Header at an intermediate destination in the Routing Header. An intermediate node may apply applicable processing limits in [I-D.ietf-6man-eh-limits]. Herbert Expires 21 September 2024 [Page 7] Internet-Draft HNSIGOPT March 2024 If an intermediate node recognizes the Type in the signal option then it MAY process the option and take appropriate action. If an intermediate node does not recognize the Type then it should skip the rest of the option and continue processing the header. 4.3. Receiver operation 4.3.1. Receiving a don't reflect option If a receiver receives a signal option with Pr field set to 0 (Don't reflect) then the receiver MAY process the option as part of receive option processing but otherwise SHOULD ignore the signal option. 4.3.2. Receiving an option to be reflected If a receiver receives a signal option with Pr field set to 1 (Reflect as actionable) or 2 (Reflect as non-actionable) then the receiver SHOULD save the option in the state context of the corresponding flow to subsequently reflect it in packets sent on the return path. A receiver SHOULD also note if the option was received in Destination Options before the Routing Header or not. If the option is actionable, that is the option was in Hop-by-Hop Options or Destination Options before the routing header, then the receiver MAY process the option as part of receive processing. 4.3.3. Reflecting signals If a signal option was saved in the context for a flow to be reflected then the reflected option is included when packets are sent in the return path of the option. A host does this by creating a signal option per properties of the original received signal. If the reflection property of the original signal option is "Forward path not actionable, return path actionable" then the signal option is reflected in Destination Options after the Routing header or just Destination Options if there is no Routing Header in the packet being sent. If the reflection property of the original signal is "Actionable in the forward path and return path" or "Forward path not actionable, return path actionable" then the signal is reflected depending on how it was received: * If the original signal was not received in Destination Options before the Routing Header then it is reflected in Hop-by-Hop Options. * If the original signal was received in Destination Options before Herbert Expires 21 September 2024 [Page 8] Internet-Draft HNSIGOPT March 2024 the Routing Header then it is reflected in Destination Options before the Routing Header only if the packet would otherwise contain a Routing Header. If the packet being sent does not contain a Routing Header then the signal option is not reflected. When a host sends a reflected signal option it MUST set the Pr to 3 (Reflected signal). A host SHOULD continue to reflect the saved signal until a different signal to be reflected with the same type is received from the peer for the flow, or a packet is received that doesn't contain a signal of the same type to be reflected. Note that reflection is optional at a receiver, and a receiver MAY reflect one or more signal options for the same flow. A receiver MAY choose to only save one signal option to reflect per flow, and in the case that more than one option is received to be reflected a receiver SHOULD save only the first found signal option to be reflected in the flow's context. Note that a receiver can reflect a signal option even if it doesn't recognize its Type. 4.3.4. Receiving a reflected signal When a host receives a reflected signal it MAY process it. In the case of a network to host signal the contents MAY be consumed by the application. For instance, if the signal indicates a report of router congestion in forward path, the host may adjust congestion avoidance algorithms for the flow. 5. Implementation Considerations for Reflection 5.1. Reflection with TCP When a TCP packet is received with a signal option to be reflected, the option is saved in the TCP Protocol Control Block (or PCB) for the connection. When a TCP packet is sent, the saved signal option in the PCB is checked. If there is a saved option then it is included in the packet per the requirements of Section 3. If a TCP packet is received that is different from the currently saved option, then the new option overwrites the saved option. Note that this is done without respect to the transport layer ordering. For instance a signal option may reflected that does not reflect the the signal option received with the greatest TCP sequence number (this can happen when a sender retransmits a packet that has a different signal option that a packet that was sent with a larger sequence number). Herbert Expires 21 September 2024 [Page 9] Internet-Draft HNSIGOPT March 2024 5.2. Reflection with UDP When a UDP packet is received with a signal option to be reflected, the option would normally be passed the application. In the sockets API this could be done via ancillary data in the recvmsg function. The application could save the signal option in its context for the flow, and when sending on the flow it includes a signal option if one has been saved. 6. Security Considerations Signal reflection introduces a potential security risk for amplification or spoofing attacks. In its nature, signal reflection is best effort, so it can be suppressed to mitigate the risks. Also, since signal reflection is stateful, the state itself could be used to mitigate the risk. For instance, for a TCP connection signal reflection might only be allowed in Established state. Furthermore the peer that sent a signal option could be considered, for instance if the peer address is in the same limited domain as the receiver then that is a good indicator that it is safe to reflect a signal option. 7. IANA Considerations IANA is requested to assign the following Hop-By-Hop and Destination options for signal options: +-----------+---------------+-------------+---------------+ | Hex Value | Binary value | Description | Reference | | | act chg rest | | | +-----------+---------------+-------------+---------------+ | 0x0F [TBD]| 00 0 01111 | Unmodifiable| This document | | | | signal | | | | | option | | +-----------+---------------+-------------+---------------+ | 0x0F [TBD]| 00 1 01111 | Modifiable | This document | | | | signal | | | | | option | | +-----------+---------------+-------------+---------------+ IANA is requested to set up a registry for the reflection property (Pr) of signal options. This is a 2 bit value: Herbert Expires 21 September 2024 [Page 10] Internet-Draft HNSIGOPT March 2024 +----------------+----------------------+---------------+ | Ticket property| Description | Reference | +----------------+----------------------+---------------+ | 0x0 | Don't reflect | This document | +----------------+----------------------+---------------+ | 0x1 | Reflect as | This document | | | actionable | | +----------------+----------------------+---------------+ | 0x2 | Reflect as | This document | | | not actionable | | +----------------+----------------------+---------------+ | 0x3 | Reflected | This document | +----------------+----------------------+---------------+ IANA is requested to set up a registry for the Signal Option Type. These are 6 bit values. Values 0 to 0x3b are reserved for assignment via Standards Action [RFC8126]. Values 0x3c to 0x3f are for experimentation or private use. +----------------+--------------------+---------------+ | Ticket type | Description | Reference | +----------------+--------------------+---------------+ | 0x0-0x3b | Assignable | This document | +----------------+--------------------+---------------+ | 0x3c-0x3f | Private use | This document | +----------------+--------------------+---------------+ 8. References 8.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 8.2. Informative References [I-D.eckert-6man-qos-exthdr-discuss] Eckert, T. T., Joung, J., Peng, S., and X. Geng, "Considerations for common QoS IPv6 extension header(s)", Work in Progress, Internet-Draft, draft-eckert-6man-qos- exthdr-discuss-00, 4 March 2024, . Herbert Expires 21 September 2024 [Page 11] Internet-Draft HNSIGOPT March 2024 [I-D.herbert-fast] Herbert, T., "Firewall and Service Tickets", Work in Progress, Internet-Draft, draft-herbert-fast-07, 7 October 2023, . [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-12, 18 December 2023, . [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-14, 25 February 2024, . [I-D.shi-ippm-congestion-measurement-ipv6-options] Shi, H., Zhou, T., Ying, and M. Han, "IPv6 Options for Congestion Measurement", Work in Progress, Internet-Draft, draft-shi-ippm-congestion-measurement-ipv6-options-00, 3 March 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 21 September 2024 [Page 12]