Network Working Group A. Pelov Internet-Draft IMT Atlantique Intended status: Standards Track 23 June 2026 Expires: 25 December 2026 ICMPv6 Secure Segment Treatment Notifications draft-pelov-icmpv6-sec-01 Abstract A packet can cross an IPv6 segment whose properties - long delay, scheduled contacts, a strict size budget - defeat the feedback an endpoint normally relies on. This document defines ICMPv6-SEC (SECure Segment Treatment), an ICMPv6 message that a segment boundary sends to a packet's source when the packet is not prepared for such a segment. The message carries a COSE-signed Segment Descriptor: a compact CBOR object stating which segment is meant, how long the statement is valid, and what treatment future packets require. A receiver applies a descriptor only after verifying the signature, the validity window, and that the signer is authorized for the segment. 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 25 December 2026. Copyright Notice Copyright (c) 2026 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 (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 Pelov Expires 25 December 2026 [Page 1] Internet-Draft ICMPv6-SEC June 2026 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 3 4. Segment Descriptor . . . . . . . . . . . . . . . . . . . . . 5 5. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction A source sends a packet toward a destination, and the packet crosses a constrained segment the source did not know about - a deep-space relay, a scheduled link, an LPWAN (such as LoRaWAN) reached through a SCHC [RFC8724] gateway, a policy-controlled region. The constraint may be delay - at a one-way delay of minutes, end-to-end feedback (Path MTU Discovery [RFC8201], congestion signals) arrives far too late - or a strict size or duty-cycle budget that a packet must already respect on entry. In either case the source needed the segment's properties before it sent the first packet. ICMPv6-SEC turns that silent failure into a signed, actionable notification. When a Segment Boundary sees a packet that is not prepared for the segment ahead, it returns one ICMPv6-SEC message to the source carrying a Code, a quote of the packet for correlation, and a Segment Descriptor: a COSE-signed CBOR object stating what the segment is and what treatment future packets require (for example a Traffic Class value, a SCHC [RFC8724] Header Format [SCHC-HDR-FMT], or an admission token). The descriptor is signed by an operator authority, not by the forwarding device, so the source can verify and cache it independently of the path it took. The exchange is fast because it does not cross the segment it describes: the boundary is at the near edge, so the notification is a local round trip. The pattern is not specific to interplanetary links; it applies to any segment whose far side is a special network - a delay- or disruption-tolerant (DTN) relay, or an LPWAN such as LoRaWAN reached Pelov Expires 25 December 2026 [Page 2] Internet-Draft ICMPv6-SEC June 2026 through a SCHC gateway, which filters entering traffic just as a deep-space boundary does. In each case the boundary tells the source the same thing: be aware that a special network lies ahead, adjust your behaviour, and mark your traffic as prepared for it (for example with a SCHC Header Format [SCHC-HDR-FMT] or an admission token). ICMPv6-SEC is an exception mechanism for use in limited domains [RFC8799] or trust federations, where operators can pre-provision trust anchors. A source MUST operate safely when no ICMPv6-SEC message is received; ordinary IPv6 operation remains in effect regardless. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Segment: A portion of an IPv6 path with operational treatment requirements. Segment Boundary: A node that observes packets entering a Segment and generates ICMPv6-SEC messages for packets that do not satisfy the Segment treatment policy. Invoking Packet: The packet that caused a Segment Boundary to generate an ICMPv6-SEC message. Segment Treatment Indicator: A marking, profile, or credential indicating that traffic is prepared for a Segment - for example a Traffic Class value, a SCHC Header Format, or an admission token. Segment Descriptor: A COSE-signed CBOR object that identifies a Segment and the treatment required to cross it. Authorized Signer: An entity whose signature validates and that local policy accepts as speaking for the described Segment or prefix. 3. Message Format ICMPv6-SEC is an ICMPv6 informational message (Type assigned by IANA). It consists of the four-octet ICMPv6 header, a four-octet fixed header (Data Length and Reserved), a Quoted Invoking Packet, and an ICMP Extension Structure [RFC4884] containing exactly one Segment Descriptor Object. Pelov Expires 25 December 2026 [Page 3] Internet-Draft ICMPv6-SEC June 2026 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Quoted Invoking Packet (Data Length octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ICMP Extension Structure (RFC 4884) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ICMPv6-SEC Message Format Data Length gives the length in octets of the Quoted Invoking Packet, which MUST be zero-padded to an 8-octet boundary before the Extension Structure and MUST include at least the IPv6 header (40 octets). The Quoted Invoking Packet is used only for correlation and is not authenticated. The Extension Structure MUST contain exactly one Segment Descriptor Object (Section 4); a message with none, or more than one, MUST be discarded. An ICMPv6-SEC message SHOULD NOT exceed 1280 octets. +======+===========+========================================+ | Code | Name | Meaning | +======+===========+========================================+ | 0 | Segment | The Invoking Packet lacked a required | | | Treatment | indicator; it MAY have been forwarded. | | | Required | Future packets without the indicated | | | | treatment may be dropped. | +------+-----------+----------------------------------------+ | 1 | Segment | The Invoking Packet was dropped; | | | Treatment | future packets without the indicated | | | Rejected | treatment will not be admitted. | +------+-----------+----------------------------------------+ Table 1: ICMPv6-SEC Code Values The Code is outside the COSE signature and is therefore not authenticated. A receiver MUST NOT infer that a specific packet was lost or delivered from the Code; loss detection remains the transport layer's responsibility. Pelov Expires 25 December 2026 [Page 4] Internet-Draft ICMPv6-SEC June 2026 A Segment Boundary MAY generate ICMPv6-SEC when a packet entering a Segment lacks a required indicator. It MUST rate-limit generation per source address and per Segment, and MUST NOT generate ICMPv6-SEC in response to an ICMPv6 error or another ICMPv6-SEC message, nor to a packet with a multicast or otherwise invalid source or a multicast destination. 4. Segment Descriptor The Segment Descriptor is a COSE_Sign1 object [RFC9052] whose payload is a CBOR-encoded [RFC8949] map, defined with CDDL [RFC8610] in Figure 2 and carried as a single ICMP extension object [RFC4884] (Class-Num TBD1, C-Type 1). An Authorized Signer creates and signs it; the Segment Boundary carries it unmodified and SHOULD use pre- signed descriptors. The COSE_Sign1 MUST set alg in the protected header; signers SHOULD use ES256 [RFC9053]. The Sig_structure external_aad MUST be the 13-octet ASCII string "ICMPv6-SEC-v1" (domain separation; not carried on the wire). The protected header SHOULD include a key identifier. ICMPv6SecDescriptor = { 0: uint, ; version (1) 1: bstr .size 16, ; descriptor-id 2: SegmentId, ; segment 3: Validity, ; [not-before, not-after] 4: [1* Treatment], ; required treatment * uint => any ; future keys (IANA-registered) } SegmentId = {0: IPv6Prefix, ?1: tstr} IPv6Prefix = [bstr .size 16, uint .le 128] Validity = [#6.1(uint), #6.1(uint)] ; not-before, not-after (UTC) Treatment = { 0: IndicatorType, ? 1: bstr } IndicatorType = uint .le 255 Figure 2: Segment Descriptor CDDL Receivers MUST ignore unrecognized map keys and discard descriptors whose version is not 1. The segment MUST contain an IPv6 prefix (key 0), which is the signed anchor that binds the descriptor to traffic. A segment name (key 1), when present, is operator metadata and MUST NOT be used by itself to select affected traffic. Each Treatment carries an IndicatorType (Segment Treatment Indicator Types, Section 7) and, for the initial types defined by this document, a required value: Pelov Expires 25 December 2026 [Page 5] Internet-Draft ICMPv6-SEC June 2026 * Type 0 (IPv6 Traffic Class or DSCP): the value is one octet. It carries the IPv6 Traffic Class value; when a deployment uses only DSCP, the DSCP is carried in the six most significant bits. * Type 1 (SCHC Header Format): the value is an opaque identifier for a SCHC Header Format binding or profile. The exact identifier syntax is defined by the SCHC Header Format binding or deployment profile. * Type 2 (Admission Token or Credential Reference): the value is an opaque token or credential reference whose syntax and lifecycle are defined by the using deployment profile. A receiver MUST ignore an indicator it does not recognize. A receiver MUST discard a descriptor if a recognized indicator is missing a required value or if the value length is invalid for that indicator. Optional descriptor fields (for example expected delay, contact windows, or a maximum packet size) are carried under keys registered in the Segment Descriptor Keys registry (Section 7). 5. Receiver Processing On receiving an ICMPv6-SEC message a host MUST, in order: 1. Apply base ICMPv6 checks [RFC4443]: checksum, and a valid unicast source. 2. Discard the message if Data Length is less than 40 octets, or if Data Length and its required padding do not leave a complete ICMP Extension Structure. 3. Validate the ICMP Extension Structure according to [RFC4884], including the Extension Header Version and Checksum fields; discard the message if the structure is malformed or fails validation. 4. Locate the single Segment Descriptor Object; discard the message if it is absent or if more than one Segment Descriptor Object is present. 5. Verify the COSE_Sign1 signature with external_aad = "ICMPv6-SEC- v1". Implementations MUST support ES256. Discard if verification fails. 6. Check the Validity window; discard if the current time is outside it (a local clock-skew margin SHOULD be applied). Pelov Expires 25 December 2026 [Page 6] Internet-Draft ICMPv6-SEC June 2026 7. Verify, by local policy, that the signer is authorized for the segment prefix. A valid signature from an unauthorized signer MUST NOT cause any treatment change. If all checks pass the receiver MAY apply the descriptor, anchored to the signed prefix: it applies the treatment to traffic it sends toward destinations the prefix covers. The Quoted Invoking Packet MUST NOT be used to decide which traffic is affected. Performance- affecting prior information SHOULD be treated as superseded by end- to-end observations when those are available; for a maximum packet size, a receiver SHOULD use the smaller of the descriptor value and a Path MTU Discovery result [RFC8201]. Receivers SHOULD cache a valid descriptor until the earliest of its not-after time and a locally configured maximum lifetime. 6. Security Considerations A valid signature is necessary but not sufficient: the receiver MUST also verify that the signer is authorized for the segment (step 5). The Quoted Invoking Packet and the Code are not authenticated and are advisory only. The Validity window bounds replay; there is no revocation, which argues for short windows, and receivers SHOULD cap the cache lifetime below the signed window where the context permits. A genuine descriptor can still be replayed off-path to a host it does not apply to; anchoring to the signed prefix and subordinating prior information to end-to-end observations limit the damage. ICMPv6-SEC can be a reflection/amplification vector: a Segment Boundary MUST rate-limit generation, SHOULD keep messages within the 1280-octet minimum MTU, SHOULD NOT embed certificate chains (use pre- provisioned trust anchors), and SHOULD restrict generation to sources within the limited domain. Rate limits SHOULD also key on a property the attacker cannot spoof, such as the ingress interface. Segment Descriptors reveal operational metadata (accepted treatments, SCHC Header Formats, schedules). Deployments SHOULD disclose only what a receiver needs and SHOULD avoid exposing detailed policy to unauthorized sources. 7. IANA Considerations IANA is requested to assign a new ICMPv6 informational Type "ICMPv6-SEC" from the "ICMPv6 Type Numbers" registry, and to create the registries below. Pelov Expires 25 December 2026 [Page 7] Internet-Draft ICMPv6-SEC June 2026 ICMPv6-SEC Code Values (under the assigned Type): 0 = Segment Treatment Required, 1 = Segment Treatment Rejected (both, This document); 2-255 by Standards Action [RFC8126]. ICMP Extension Object: Class-Num TBD1, C-Type 1, "Segment Descriptor Object", This document. Segment Descriptor Keys: a registry for the integer map keys of the descriptor (Figure 2): 0 version, 1 descriptor-id, 2 segment, 3 validity, 4 treatment (all This document). Keys 5-255 by Specification Required [RFC8126]. A registration MUST NOT define a key whose omission would change the meaning of the keys defined here. Segment Treatment Indicator Types: 0 = IPv6 Traffic Class or DSCP [RFC2474]; 1 = SCHC Header Format [SCHC-HDR-FMT]; 2 = Admission Token or Credential Reference (all This document). Values 3-255 by Specification Required [RFC8126]; a registration MUST state whether the value field is required and what it carries. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Pelov Expires 25 December 2026 [Page 8] Internet-Draft ICMPv6-SEC June 2026 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . 8.2. Informative References [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [SCHC-HDR-FMT] Pelov, A., "SCHC Header Format", Work in Progress, Internet-Draft, draft-pelov-schc-header-format-00, 2026, . Pelov Expires 25 December 2026 [Page 9] Internet-Draft ICMPv6-SEC June 2026 Acknowledgements The author thanks contributors discussing ICMPv6, SCHC, COSE, and the SCHC Header Format for the observations that shaped this revision. Author's Address Alexander Pelov IMT Atlantique 2bis rue de la Chataigneraie 35536 Cesson-Sevigne France Email: alexander.pelov@imt-atlantique.fr Pelov Expires 25 December 2026 [Page 10]