# drafts

name: draft-ruas-cfrg-ecdp
rev: 00
title: ECDP: Elliptic Curve Data Protocol
time: 2025-05-19T07:09:03Z
group_uri: /api/v1/group/group/1027/
expires: 2025-05-19T21:24:06Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth"]
tags: []
fetched_at: 2026-03-04T00:00:05.770726+00:00
source: ietf
abstract:
  This document specifies the Elliptic Curve Data Protocol (ECDP), a
     peer-to-peer (P2P) communication protocol tailored for decentralized
     networks.  ECDP utilizes elliptic curve cryptography (ECC) for
     encryption, employs the Elliptic Curve Digital Signature Algorithm
     (ECDSA) for message authentication, and leverages the Diffie-Hellman
     key exchange using elliptic curves for secure session initialization.
     The protocol supports a variety of elliptic curves (e.g., secp256k1,
     secp384r1) with varying key sizes, and is designed to operate over
     both TCP and UDP.  Additionally, it utilizes SHA-256 or SHA-512 for
     cryptographic hash verification to ensure message integrity.

full_text:
  Crypto Forum                                                     I. Ruas
  Internet-Draft                                                   Nrolabs
  Intended status: Standards Track                        15 November 2024
  Expires: 19 May 2025


                     ECDP: Elliptic Curve Data Protocol
                          draft-ruas-cfrg-ecdp-00

  Abstract

     This document specifies the Elliptic Curve Data Protocol (ECDP), a
     peer-to-peer (P2P) communication protocol tailored for decentralized
     networks.  ECDP utilizes elliptic curve cryptography (ECC) for
     encryption, employs the Elliptic Curve Digital Signature Algorithm
     (ECDSA) for message authentication, and leverages the Diffie-Hellman
     key exchange using elliptic curves for secure session initialization.
     The protocol supports a variety of elliptic curves (e.g., secp256k1,
     secp384r1) with varying key sizes, and is designed to operate over
     both TCP and UDP.  Additionally, it utilizes SHA-256 or SHA-512 for
     cryptographic hash verification to ensure message integrity.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://isakruas.github.io/ecdp/draft-ruas-cfrg-ecdp.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ruas-cfrg-ecdp/.

     Discussion of this document takes place on the Crypto Forum Research
     Group mailing list (mailto:cfrg@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/cfrg.  Subscribe at
     https://www.ietf.org/mailman/listinfo/cfrg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/isakruas/ecdp.

  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/.



  Ruas                       Expires 19 May 2025                  [Page 1]


  Internet-Draft                    ECDP                     November 2024


     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 19 May 2025.

  Copyright Notice

     Copyright (c) 2024 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
     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Goals of the Protocol . . . . . . . . . . . . . . . . . . . .   3
     4.  Supported Algorithms  . . . . . . . . . . . . . . . . . . . .   4
       4.1.  4.1 Cryptography  . . . . . . . . . . . . . . . . . . . .   4
         4.1.1.  4.1.1 Supported Elliptic Curves . . . . . . . . . . .   4
         4.1.2.  4.1.2 Supported Cryptographic Hash Algorithms . . . .   4
     5.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Message Types . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Message Structure . . . . . . . . . . . . . . . . . . . . . .   5
       6.1.  5.1 Base Message Structure  . . . . . . . . . . . . . . .   5
       6.2.  5.2 Handshake (0x01)  . . . . . . . . . . . . . . . . . .   6
       6.3.  5.3 Data Transfer (0x02)  . . . . . . . . . . . . . . . .   7
       6.4.  5.4 Acknowledgment (Ack) (0x03) . . . . . . . . . . . . .   8
       6.5.  5.5 Data Request (0x04) . . . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
       7.1.  Additional Recommendations  . . . . . . . . . . . . . . .   9
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11







  Ruas                       Expires 19 May 2025                  [Page 2]


  Internet-Draft                    ECDP                     November 2024


  1.  Introduction

     P2P networks are widely used for data exchange but often face
     challenges related to security and data integrity.  ECDP addresses
     these issues by implementing strong cryptographic measures and robust
     authentication mechanisms.  ECDP is designed for scalability and
     security by enabling nodes to communicate indirectly through a
     network pool.

     To enhance the security and integrity of the messages exchanged, the
     protocol employs elliptic curve cryptography (ECC) with various well-
     established curves, as well as the SHA-256 and SHA-512 algorithms for
     cryptographic hash functions.

     The protocol dynamically supports different ECC key lengths, ensuring
     flexibility and forward compatibility with future developments in
     elliptic curve cryptography.

  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].

  3.  Goals of the Protocol

     *  The protocol *MUST* facilitate secure communication between nodes
        through a pool network.

     *  The protocol *MUST* ensure data integrity and confidentiality of
        the messages transmitted.

     *  The protocol *MUST* authenticate messages using elliptic curve
        signature schemes, ensuring their origin and integrity.

     *  The protocol *MUST* be extensible and support future advances in
        cryptographic techniques.

     *  The protocol *SHOULD* be scalable, able to operate in
        decentralized large-scale P2P networks.

     *  The protocol *MUST* support multiple key sizes for flexible
        elliptic curve operations.







  Ruas                       Expires 19 May 2025                  [Page 3]


  Internet-Draft                    ECDP                     November 2024


  4.  Supported Algorithms

     ECDP relies on a variety of standardized and widely used algorithms
     to ensure secure, authenticated, and efficient communication.

  4.1.  4.1 Cryptography

  4.1.1.  4.1.1 Supported Elliptic Curves

     ECDP supports the following elliptic curves for encryption, Diffie-
     Hellman key exchange, and signing operations (ECDSA):

     *  *secp192k1*

     *  *secp192r1*

     *  *secp224k1*

     *  *secp224r1*

     *  *secp256k1*

     *  *secp256r1*

     *  *secp384r1*

     *  *secp521r1*

     Each curve corresponds to a distinct key size.  To accommodate
     different security levels, the protocol includes a parameter for
     indicating the key size used in message operations.  Implementations
     *MUST* support *secp256k1*, *secp256r1*, and *secp384r1* as a minimum
     requirement.  Support for other curves is *RECOMMENDED* for greater
     flexibility and stronger cryptography when necessary.

  4.1.2.  4.1.2 Supported Cryptographic Hash Algorithms

     ECDP uses cryptographic hash functions for various integrity checks,
     including *checksums* and *digital signatures*.

     Supported hash functions include:

     *  *SHA-256* (RECOMMENDED)

     *  *SHA-512* (OPTIONAL for longer data integrity verification)

     Implementations *MUST* support *SHA-256* as a minimum requirement.




  Ruas                       Expires 19 May 2025                  [Page 4]


  Internet-Draft                    ECDP                     November 2024


  5.  Protocol Operation

  5.1.  Message Types

     *  *0x01:* Handshake

     *  *0x02:* Data Transfer

     *  *0x03:* Acknowledgment (Ack)

     *  *0x04:* Data Request

  6.  Message Structure

  6.1.  5.1 Base Message Structure

     The base structure contains fields that are common across various
     message types, with extensions for specific needs.  Messages are
     routed through a pool network to enhance scalability and security.
































  Ruas                       Expires 19 May 2025                  [Page 5]


  Internet-Draft                    ECDP                     November 2024


       +============+======================================+===========+
       | Field      | Description                          | Size      |
       |            |                                      | (bytes)   |
       +============+======================================+===========+
       | Protocol   | Identifies the version of the ECDP   | 1         |
       | Version    | protocol                             |           |
       +------------+--------------------------------------+-----------+
       | Message    | Indicates the type of message        | 1         |
       | Type       |                                      |           |
       +------------+--------------------------------------+-----------+
       | Key Size   | Indicates the ECC key size used      | 2         |
       |            | (e.g., 192, 224, 256, 384, 521 bits) |           |
       +------------+--------------------------------------+-----------+
       | Sender ECC | Public key of the sending node       | Variable  |
       | Public Key |                                      | (based on |
       |            |                                      | key size) |
       +------------+--------------------------------------+-----------+
       | Receiver   | Public key of the receiving node (if | Variable  |
       | ECC Public | applicable)                          | (based on |
       | Key        |                                      | key size) |
       +------------+--------------------------------------+-----------+
       | Nonce      | Random number to prevent replay      | 8         |
       |            | attacks                              |           |
       +------------+--------------------------------------+-----------+
       | Encrypted  | Content of the message encrypted     | Variable  |
       | Data       | using ECC                            |           |
       +------------+--------------------------------------+-----------+
       | Signature  | Digital signature of the sender      | Variable  |
       |            | (ECDSA)                              | (based on |
       |            |                                      | key size) |
       +------------+--------------------------------------+-----------+

                                    Table 1

     In this structure: - *Key Size* is a 2-byte field that indicates the
     key size in bits (e.g., 192, 224, 256, 384, 521).  This allows both
     endpoints to use flexible key sizes as per their security
     requirements.

  6.2.  5.2 Handshake (0x01)

      +==================+==============================+==============+
      | Field            | Description                  | Size (bytes) |
      +==================+==============================+==============+
      | Protocol Version | Identifies the version of    | 1            |
      |                  | the ECDP protocol            |              |
      +------------------+------------------------------+--------------+
      | Message Type     | Set to Handshake (0x01)      | 1            |



  Ruas                       Expires 19 May 2025                  [Page 6]


  Internet-Draft                    ECDP                     November 2024


      +------------------+------------------------------+--------------+
      | Key Size         | Indicates the ECC key size   | 2            |
      |                  | used                         |              |
      +------------------+------------------------------+--------------+
      | Sender ECC       | Public key of the sending    | Variable     |
      | Public Key       | node                         |              |
      +------------------+------------------------------+--------------+
      | Receiver ECC     | Public key of the receiving  | Variable     |
      | Public Key       | node                         |              |
      +------------------+------------------------------+--------------+
      | Nonce            | Random number to prevent     | 8            |
      |                  | session replay               |              |
      +------------------+------------------------------+--------------+
      | Node Identifier  | Unique ID of the node (e.g., | 32           |
      |                  | hash of the public key)      |              |
      +------------------+------------------------------+--------------+
      | Node Capability  | Information about bandwidth  | 4            |
      |                  | and supported data types     |              |
      +------------------+------------------------------+--------------+
      | Signature        | Digital signature of the     | Variable     |
      |                  | sender (ECDSA)               |              |
      +------------------+------------------------------+--------------+

                                   Table 2

  6.3.  5.3 Data Transfer (0x02)

      +==============+======================================+==========+
      | Field        | Description                          | Size     |
      |              |                                      | (bytes)  |
      +==============+======================================+==========+
      | Protocol     | Identifies the version of the ECDP   | 1        |
      | Version      | protocol                             |          |
      +--------------+--------------------------------------+----------+
      | Message Type | Set to Data Transfer (0x02)          | 1        |
      +--------------+--------------------------------------+----------+
      | Key Size     | Indicates the ECC key size used      | 2        |
      +--------------+--------------------------------------+----------+
      | Sender ECC   | Public key of the sending node       | Variable |
      | Public Key   |                                      |          |
      +--------------+--------------------------------------+----------+
      | Receiver ECC | Public key of the receiving node     | Variable |
      | Public Key   |                                      |          |
      +--------------+--------------------------------------+----------+
      | Nonce        | Exclusive random number for the      | 8        |
      |              | session                              |          |
      +--------------+--------------------------------------+----------+
      | Encrypted    | Message content encrypted using ECC  | Variable |



  Ruas                       Expires 19 May 2025                  [Page 7]


  Internet-Draft                    ECDP                     November 2024


      | Data         |                                      |          |
      +--------------+--------------------------------------+----------+
      | Checksum     | Cryptographic hash (SHA-256 or SHA-  | 32 or 64 |
      |              | 512) for data integrity verification |          |
      +--------------+--------------------------------------+----------+
      | Signature    | Digital signature of the sender      | Variable |
      |              | (ECDSA)                              |          |
      +--------------+--------------------------------------+----------+

                                   Table 3

  6.4.  5.4 Acknowledgment (Ack) (0x03)

      +==================+==============================+==============+
      | Field            | Description                  | Size (bytes) |
      +==================+==============================+==============+
      | Protocol Version | Identifies the version of    | 1            |
      |                  | the ECDP protocol            |              |
      +------------------+------------------------------+--------------+
      | Message Type     | Set to Acknowledgment (0x03) | 1            |
      +------------------+------------------------------+--------------+
      | Nonce            | Random number corresponding  | 8            |
      |                  | to the session               |              |
      +------------------+------------------------------+--------------+
      | Message Hash     | Hash of the received data    | 32 or 64     |
      |                  | message (SHA-256 or SHA-512) |              |
      +------------------+------------------------------+--------------+
      | Status           | Indicates Success (0x00) or  | 1            |
      |                  | Error (0x01)                 |              |
      +------------------+------------------------------+--------------+

                                   Table 4

  6.5.  5.5 Data Request (0x04)

     +==============+====================================+==============+
     | Field        | Description                        | Size (bytes) |
     +==============+====================================+==============+
     | Protocol     | Identifies the version of the ECDP | 1            |
     | Version      | protocol                           |              |
     +--------------+------------------------------------+--------------+
     | Message Type | Set to Data Request (0x04)         | 1            |
     +--------------+------------------------------------+--------------+
     | Key Size     | Indicates the ECC key size used    | 2            |
     +--------------+------------------------------------+--------------+
     | Sender ECC   | Public key of the requesting node  | Variable     |
     | Public Key   |                                    |              |
     +--------------+------------------------------------+--------------+



  Ruas                       Expires 19 May 2025                  [Page 8]


  Internet-Draft                    ECDP                     November 2024


     | Receiver ECC | Public key of the data-holding     | Variable     |
     | Public Key   | node                               |              |
     +--------------+------------------------------------+--------------+
     | Nonce        | Random number for the session      | 8            |
     +--------------+------------------------------------+--------------+
     | Data         | Unique hash or ID of the requested | 32 or 64     |
     | Identifier   | data (using SHA-256, SHA-512)      |              |
     +--------------+------------------------------------+--------------+
     | Signature    | Digital signature of the sender    | Variable     |
     |              | (ECDSA)                            |              |
     +--------------+------------------------------------+--------------+

                                   Table 5

  7.  Security Considerations

     ECDP employs ECC for secure communication between nodes, with
     messages authenticated through ECDSA.  The inclusion of a *Key Size*
     field allows nodes to negotiate and use varying key lengths based on
     the curve chosen, ensuring flexibility in security levels.

     Nonces are used to prevent replay attacks.  The protocol uses the
     Diffie-Hellman key exchange over elliptic curves for secure session
     initialization.  The following elliptic curves are supported, with
     corresponding key sizes:

     *  secp192k1 (192-bit)

     *  secp192r1 (192-bit)

     *  secp224k1 (224-bit)

     *  secp224r1 (224-bit)

     *  secp256k1 (256-bit) (*RECOMMENDED*)

     *  secp256r1 (256-bit) (*RECOMMENDED*)

     *  secp384r1 (384-bit) (*RECOMMENDED*)

     *  secp521r1 (521-bit)

  7.1.  Additional Recommendations

     *  Implementations *SHOULD* regularly update their cryptographic
        libraries to maintain security against evolving threats.





  Ruas                       Expires 19 May 2025                  [Page 9]


  Internet-Draft                    ECDP                     November 2024


     *  Nodes *MUST* verify the signatures of incoming messages to ensure
        authenticity.

     *  Nonce sizes *MUST* be sufficient (8 bytes at minimum) to prevent
        replay attacks.

     *  It is *RECOMMENDED* that nodes securely store their private keys
        using encryption and protected hardware when possible to prevent
        unauthorized access.

  8.  IANA Considerations

     This document has no actions directed at IANA at this time.  However,
     if future protocol updates require additional message types, code
     points, or other attributes, a registration with IANA *MAY* be
     required.

  9.  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,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
                Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
                for Transport Layer Security (TLS)", RFC 4492,
                DOI 10.17487/RFC4492, May 2006,
                <https://www.rfc-editor.org/rfc/rfc4492>.

     [RFC5639]  Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
                (ECC) Brainpool Standard Curves and Curve Generation",
                RFC 5639, DOI 10.17487/RFC5639, March 2010,
                <https://www.rfc-editor.org/rfc/rfc5639>.

     [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
                Algorithm (DSA) and Elliptic Curve Digital Signature
                Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
                2013, <https://www.rfc-editor.org/rfc/rfc6979>.

  Acknowledgments

     The authors acknowledge the valuable contributions of cryptographic
     and P2P networking experts.  Special thanks to those who provided
     feedback on elliptic curve performance and secure key storage
     recommendations.





  Ruas                       Expires 19 May 2025                 [Page 10]


  Internet-Draft                    ECDP                     November 2024


  Author's Address

     Isak Ruas
     Nrolabs
     Brazil
     Email: isakruas@nrolabs.com













































  Ruas                       Expires 19 May 2025                 [Page 11]


name: draft-papon-lake-pq-edhoc
rev: 00
title: Post-Quantum EDHOC - Initiator and Responder using signature and/or KEM
time: 2026-03-02T18:19:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T18:19:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.937014+00:00
source: ietf
abstract:
  This document specifies two extensions to the Ephemeral Diffie-
     Hellman over COSE (EDHOC).  These two protocol versions aim to
     provide quantum-resistance to the original EDHOC protocol, while
     reducing message-complexity with respect to parallel drafts.  The
     document defines: (1) a 3-message quantum-resistant EDHOC proposal
     when the Initiator knows the Responder; in this version, the
     Initiator authenticates using a signature, while the Responder uses a
     KEM; (2) a 3-or-4-message quantum-resistant EDHOC proposal, which
     proposes a tradeoff between message-complexity and computational
     overhead.

full_text:
  LAKE                                                            C. Papon
  Internet-Draft                                                  C. Onete
  Intended status: Informational   XLIM UMR CNRS 7252 - Limoges University
  Expires: 2 September 2026                                   1 March 2026


  Post-Quantum EDHOC - Initiator and Responder using signature and/or KEM
                        draft-papon-lake-pq-edhoc-00

  Abstract

     This document specifies two extensions to the Ephemeral Diffie-
     Hellman over COSE (EDHOC).  These two protocol versions aim to
     provide quantum-resistance to the original EDHOC protocol, while
     reducing message-complexity with respect to parallel drafts.  The
     document defines: (1) a 3-message quantum-resistant EDHOC proposal
     when the Initiator knows the Responder; in this version, the
     Initiator authenticates using a signature, while the Responder uses a
     KEM; (2) a 3-or-4-message quantum-resistant EDHOC proposal, which
     proposes a tradeoff between message-complexity and computational
     overhead.

  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 2 September 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



  Papon & Onete           Expires 2 September 2026                [Page 1]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology and Requirements Language . . . . . . . . . .   3
       1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
         1.2.1.  KEMs (Key Encapsulation Mechanisms) . . . . . . . . .   4
         1.2.2.  Digital Signature . . . . . . . . . . . . . . . . . .   4
     2.  Post-Quantum EDHOC when the Initiator knows the Responder
             (PQ-EDHOC-IKR)  . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  PQ-EDHOC-IKR protocol overview  . . . . . . . . . . . . .   5
         2.2.1.  PQ-EDHOC-IKR protocol description . . . . . . . . . .   5
         2.2.2.  Key Derivation Schedule . . . . . . . . . . . . . . .   9
         2.2.3.  Additional explanations . . . . . . . . . . . . . . .  11
       2.3.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.  KEM & Sign Authentication for Post-Quantum EDHOC  . . . . . .  13
       3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .  13
       3.2.  First case: Initiator signs, Responder KEM and signs  . .  14
         3.2.1.  Protocol overview . . . . . . . . . . . . . . . . . .  14
         3.2.2.  Protocol description  . . . . . . . . . . . . . . . .  15
         3.2.3.  Associated key derivation schedule  . . . . . . . . .  18
         3.2.4.  Additional explanations . . . . . . . . . . . . . . .  20
         3.2.5.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  21
       3.3.  Second case: Initiator KEM and signs, Responder signs . .  21
         3.3.1.  Protocol overview . . . . . . . . . . . . . . . . . .  21
         3.3.2.  Protocol description  . . . . . . . . . . . . . . . .  22
         3.3.3.  Associated key derivation schedule  . . . . . . . . .  25
         3.3.4.  Additional explanations . . . . . . . . . . . . . . .  27
         3.3.5.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  28
       3.4.  Third case: Initiator and Responder KEM and sign - version
             1 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
         3.4.1.  Protocol overview . . . . . . . . . . . . . . . . . .  29
         3.4.2.  Protocol description  . . . . . . . . . . . . . . . .  29
         3.4.3.  Associated key derivation schedule  . . . . . . . . .  32
         3.4.4.  Additional explanations . . . . . . . . . . . . . . .  34
         3.4.5.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  35
       3.5.  Third case: Initiator and Responder KEM and sign - version
             2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  36
         3.5.1.  Protocol overview . . . . . . . . . . . . . . . . . .  36
         3.5.2.  Protocol description  . . . . . . . . . . . . . . . .  36
         3.5.3.  Associated key derivation schedule  . . . . . . . . .  40
         3.5.4.  Additional explanations . . . . . . . . . . . . . . .  41
         3.5.5.  Analysis  . . . . . . . . . . . . . . . . . . . . . .  42



  Papon & Onete           Expires 2 September 2026                [Page 2]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     4.  Security Considerations . . . . . . . . . . . . . . . . . . .  43
       4.1.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  44
       4.2.  Identity protection . . . . . . . . . . . . . . . . . . .  45
       4.3.  Downgrade Protection  . . . . . . . . . . . . . . . . . .  46
       4.4.  Transcript Hash Binding . . . . . . . . . . . . . . . . .  46
       4.5.  External Authorization Data (EAD) . . . . . . . . . . . .  46
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  46
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  46
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  46
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  48
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  48

  1.  Introduction

     This document aims to present new alternatives for rendering the
     Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol quantum-
     resistant.  The main goal is to reduce the number of messages
     exchanged during the handshake, using a combination of KEMs and
     signatures, as well as Post-Quantum Cryptography (PQC) cipher suites,
     for secure key-exchange and authentication.

     In this draft we:

     *  propose, building on [I-D.pocero-authkem-ikr-edhoc], a version of
        quantum-resistant EDHOC where the Initiator knows the Responder,
        but in a scenario where the Initiator authenticates with a
        signature (ML-DSA) and the Responder with a KEM (ML-KEM).

     *  propose, building on [I-D.pocero-authkem-edhoc], a version of the
        protocol that requires, depending on the case, either only 3 or 4
        mandatory messages.  This second version reduces the message
        overhead, but comes at an additional computational overhead for
        (at least) one of the two parties.

     The two proposals in this draft can be viewed to extend (in the case
     of the first bullet-point) and respectively to provide an alternative
     (in the case of the second bullet-point) to the current proposal for
     quantum-resistant EDHOC.

  1.1.  Terminology and Requirements Language

     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.





  Papon & Onete           Expires 2 September 2026                [Page 3]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Readers are expected to be familiar with the terms and concepts
     described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences
     [RFC8742], COSE Structures and Processing [RFC9052] and COSE
     Algorithms [RFC9053].

  1.2.  Definitions

  1.2.1.  KEMs (Key Encapsulation Mechanisms)

     A Key Encapsulation Mechanism (KEM) consists of three algorithms:

     *  KEM.KeyGen: a probabilistic key generation algorithm, which takes
        as input a security parameter k and outputs a key pair (kem.sk,
        kem.pk), where kem.sk is secret and kem.pk is public.

     *  KEM.Encapsulation: a probabilistic encapsulation algorithm, which
        takes as input a KEM public key kem.pk, and generates a pair (ss,
        kem.ct), where ss is the shared-secret and kem.ct is a ciphertext.

     *  KEM.Decapsulation: a deterministic decapsulation algorithm, which
        takes as input a KEM secret key kem.sk and a KEM ciphertext
        kem.ct, and outputs the shared-secret ss (associated to kem.ct).

     In practice, if Alice and Bob use a KEM, Alice generates the public
     and private keys, sends the public key to Bob, who generates the
     shared-secret and ciphertext.  He then returns the latter to Alice,
     who can subsequently recover the same shared-secret using her private
     key and the ciphertext.

  1.2.2.  Digital Signature

     A Digital Signature (DS) scheme consists of three algorithms:

     *  DS.KeyGen: a probabilistic key generation algorithm, which takes
        as input a security parameter k and outputs a key pair (sign.sk,
        sign.pk), where sign.sk is secret and sign.pk is public.

     *  DS.Sign: a probabilistic algorithm, which takes as input a signing
        secret key sign.sk and a message m, and generates a signature s.

     *  DS.Verify: a deterministic algorithm, which takes as input a
        signing public key sign.pk, a message m and a signature s, and
        outputs 1 if the signature is valid for the message, and 0
        otherwise.







  Papon & Onete           Expires 2 September 2026                [Page 4]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     In practice, if Alice and Bob use a DS scheme, Alice generates the
     public and private keys, and sends the public key to Bob. Later,
     Alice sends a message together with a signature to Bob. Bob can then
     verify the validity of the signature on the message under the public
     key.

  2.  Post-Quantum EDHOC when the Initiator knows the Responder (PQ-EDHOC-
      IKR)

  2.1.  Motivation

     In [I-D.pocero-authkem-ikr-edhoc], the authors adopt an EDHOC
     approach for use cases where the Initiator already knows the identity
     of the Responder, in a post-quantum version using ephemeral and
     static KEMs for authentication.  The Initiator, knowing the long-term
     public key of the Responder, can derive the shared-secret ss_R and
     compute a key, then encrypt part of the first message.  It can thus
     send its identity directly and securely authenticate himself, since
     only the Responder with its long-term secret key can decrypt the
     first message.  Knowing the Initiator's identity, the Responder can
     derive the second shared-secret ss_I and continue the key derivation
     schedule.  Sending the encrypted second message allows it to securely
     confirm its identity to the Initiator.

     The key motivation behind our current proposal is a desire to reduce
     the message-complexity of quantum-resistant EDHOC.  We propose an
     extension to draft proposal [I-D.pocero-authkem-ikr-edhoc], which
     allows the Initiator and Responder to authenticate using different
     mechanisms -- much as in the original EDHOC.  In particular, while
     the Responder still authenticates using a KEM, in our proposal the
     Initiator will use a signature.

     This approach comes with the following benefit: there is no need to
     partially encrypt the first message.  Instead, during the third
     message, the Initiator calculates a MAC and signs it.  Upon receiving
     the encrypted third message, the Responder, after decryption,
     authenticates the Initiator in the usual EDHOC manner.

  2.2.  PQ-EDHOC-IKR protocol overview

  2.2.1.  PQ-EDHOC-IKR protocol description

     We present here a high-level description of our PQ-EDHOC-IKR where
     the Initiator authenticates with a signature and the Responder with a
     KEM.






  Papon & Onete           Expires 2 September 2026                [Page 5]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


       I                                                            R
      ---                                                          ---
       |     METHOD, SUITES_I, kem.pk_eph, kem.ct_R, C_I, EAD_1     |
       +------------------------------------------------------------>
       |                          message_1                         |
       |                                                            |
       | kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, MAC_2, EAD_2) |
       <------------------------------------------------------------+
       |                          message_2                         |
       |                                                            |
       |             AEAD(ID_CRED_I, SIGNATURE_3, EAD_3)            |
       +------------------------------------------------------------>
       |                          message_3                         |
       |                                                            |
       |                         AEAD(EAD_4)                        |
       <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
       |                          message_4                         |

     Figure 1: PQ-EDHOC-IKR (I sign, R kem) message flow.

  2.2.1.1.  Formatting and sending message_1

     As in the usual EDHOC protocol, the first message (message_1)
     consists of:

     *  METHOD --> as specified in [RFC9528] it is an integer specifying
        the authentication method the Initiator wants to use;

     *  SUITES_I --> it consists of an ordered set of algorithms supported
        by the Initiator and formatted as specified in [RFC9528];

     *  C_I (and also as C_R, which will appears later) --> the Connection
        Identifiers chosen by the Initiator (C_I) and by the Responder
        (C_R) as specified in [RFC9528];

     *  EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later)
        -> External Authorization Data, respectively included in
        message_1, message_2, message_3 (and optionally) message_4, and
        formatted as specified in [RFC9528];

     *  kem.pk_eph --> the Ephemeral KEM public key generated by the
        Initiator;

     *  kem.ct_R --> based on the Responder long-term KEM public key, the
        Initiator computes ss_R and kem.ct_R with the KEM.Encapsulation
        algorithm.  He keeps secret ss_R to compute, later, PRK_3e2m, and
        sends kem.ct_R to the Responder.




  Papon & Onete           Expires 2 September 2026                [Page 6]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  2.2.1.2.  Processing message_1, formatting and sending message_2

     On the reception of the first message, the Responder first recovers
     ss_R thanks to his long-term KEM secret key kem.sk_R and kem.ct_R,
     using the KEM.Decapsulation algorithm (if the decapsulation process
     fails, he aborts).  He then proceeds as in the original EDHOC
     protocol with elements METHOD, SUITES_I, C_I and EAD_1.  Finally,
     using kem.pk_eph and the KEM.Encapsulation algorithm, he computes the
     ephemeral ciphertext kem.ct_eph and the ephemeral shared-secret
     ss_eph.

     The Responder selects its Connection Identifier C_R as specified in
     [RFC9528].  He then computes:

     *  TH_2 = H(kem.ct_eph, H(message_1));

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph).

     And also, as in [RFC9528]:

     *  KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);

     *  SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length).

     Compared to [RFC9528], the computation of PRK_3e2m is modified as
     follows :

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R).

     The Responder now computes MAC_2 and assembles PLAINTEXT_2:

     *  MAC_2 = EDHOC_KDF(PRK_3e2m, 2, C_R, ID_CRED_R, TH_2, EAD_2,
        mac_length_2);

     *  PLAINTEXT_2 = (C_R, ID_CRED_R, MAC_2, EAD_2).

     So the second message consists of:

     *  kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph;

     *  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2.

  2.2.1.3.  Processing message_2, formatting and sending message_3

     On reception of the second message, the Initiator, using kemp.ct_eph,
     can compute the ephemeral shared-secret ss_eph.  As the Responder
     did, he computes TH_2, PRK_2e and KEYSTREAM_2.  He can now decipher
     and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2.



  Papon & Onete           Expires 2 September 2026                [Page 7]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Thanks to ID_CRED_R, the Initiator verifies the validity of the long-
     term KEM public key of the Responder, kemp.pk_R, and computes
     SALT_3e2m and PRK_3e2m, using the shared-secret ss_R he generates at
     the beginning of the exchange.

     At this point the Initiator is able to authenticate the Responder (at
     least, make sure he is talking to the endpoint he hopes to talk to).
     For that, he computes, as the Responder did, the MAC MAC_2.  If it
     matches with the one he received, then he properly authenticated the
     Responder.  Otherwise he aborts.

     It is now up to the Initiator to authenticate himself.  To do so, the
     Initiator computes the following elements:

     *  TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R);

     *  K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);

     *  IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);

     *  MAC_3 = EDHOC_KDF(PRK_3e2m, 6, ID_CRED_I, TH_3, EAD_3,
        mac_length_3).

     In this version of the protocol, the Initiator authenticates itself
     to the Responder with a signature:

     *  SIGNATURE_3 = DS.Sign(sign.sk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3,
        sign_length))

     where sign.sk_I is the long-term signing private key of the
     Initiator.

     Setting PLAINTEXT_3 = (ID_CRED_I, SIGNATURE_3, EAD_3), the Initiator
     ciphers PLAINTEXT_3 with the AEAD encryption algorithm negociated in
     SUITES_I.

  2.2.1.4.  Processing message_3

     On reception of message_3, the Responder computes TH_3, K_3, and IV_3
     as the Initiator did, and deciphers CIPHERTEXT_3 with the AEAD
     decryption algorithm.  With PLAINTEXT_3, he can compute MAC_3 on his
     side, and verify the signature:

     *  DS.Verify(sign.pk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length),
        SIGNATURE_3)






  Papon & Onete           Expires 2 September 2026                [Page 8]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     where sign.pk_I is the long-term signing public key of the Initiator.
     If the verification algorithm returns 1, the Responder properly
     authenticated the Initiator.  Otherwise he aborts.

  2.2.1.5.  Optionally formatting, sending and receiving message_4

     If the Responder decides of a fourth mandatory message, he then
     computes the following elements:

     *  TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I);

     *  K_4 = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length);

     *  IV_4 = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length).

     Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4
     and sends it to the Initiator.  The latter computes TH_4, K_4, IV_4,
     and deciphers CIPHERTEXT_4 thanks to the AEAD decryption algorithm.

  2.2.1.6.  Computing the session key PRK_out

     It doesn't matter if there is a fourth mandatory message, in any
     case, both the Initiator and the Responder, in order to compute the
     key PRK_out, have to calculate the fourth transcript hash:

     *  TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I).

     With that element, using the EDHOC_KDF algorithm, they both obtain:

     *  PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length)

     which is the desired session key, and the authentication process is
     fully achieved.

  2.2.2.  Key Derivation Schedule

     In this section we summarize the key derivation operations that
     appears throughout the protocol.

               +--------------------------------+
               |TH_2=H(kem.ct_eph, H(message_1))|
               +-------+------------------------+              PLAINTEXT_2
                      |                                               |
       +------+   +---+---+   +------+   +------+   +-----------+   +-+-+
       |ss_eph|-->|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR|
       +------+   +-------+   +---+--+   +---+--+   +-----------+   +-+-+
                                  |          |                        |
                                  |          |                        v



  Papon & Onete           Expires 2 September 2026                [Page 9]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


                                  |        +-+--+           +---------+--+
                                  |        |TH_2|           |CIPHERTEXT_2|
                                  |        +--+-+           +------------+
                              +---+--+        |
                              |Expand|--------+
                              +---+--+
                                 |
                                 |
                           +-----+---+
                    +------|SALT_3e2m|
                    |      +---------+
                    |
       +----+   +---+---+   +--------+   +------+   +-----+
       |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|MAC_2|
       +----+   +-------+   +---+----+   +------+   +-----+
                                |                              PLAINTEXT_3
                                |                                   |
                                |        +------+   +--------+   +--+-+
                                +--------|Expand|-->|K_3/IV_3|-->|AEAD|
                                |        +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_3|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)|
                                |   +------------------------------------+
                                |
                                |       +------+   +-----+   +-----------+
                                +-------|Expand|-->|MAC_3|-->|SIGNATURE_3|
                                |       +------+   +-----+   +-----------+
                                |
                                |                              PLAINTEXT_4
                                |                                   |
                                |        +------+   +--------+   +--+-+
                    message_4?  +--------|Expand|-->|K_4/IV_4|-->|AEAD|
                                |        +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_4|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)|
                                |   +--------+---------------------------+



  Papon & Onete           Expires 2 September 2026               [Page 10]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


                                |            |
                                |            |
                                |        +---+--+   +-------+
                                +--------|Expand|-->|PRK_out|
                                         +------+   +-------+

     Figure 2: PQ-EDHOC-IKR (I sign, R kem) key derivation schedule.

     So we can summarize the different computations as in [RFC9528]:

       PRK_2e      = EDHOC_Extract(TH_2, ss_eph);
       KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);
       SALT_3e2m   = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);
       PRK_3e2m    = EDHOC_Extract(SALT_3e2m, ss_R);
       MAC_2       = EDHOC_KDF(PRK_3e2m, 2, context_2, mac_length_2)
                     (with context_2 = C_R, ID_CRED_R, TH_2, EAD_2);
       K_3         = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);
       IV_3        = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);
       MAC_3       = EDHOC_KDF(PRK_3e2m, 6, context_3, mac_length_3)
                          (with context_3 = ID_CRED_I, TH_3, EAD_3);
       K_4         = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length);
       IV_4        = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length);
       PRK_out     = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length).

  2.2.3.  Additional explanations

     We detail here the main elements that differ from the original EDHOC
     protocol.

  2.2.3.1.  Ephemeral KEM

     As explained in [I-D.pocero-authkem-ikr-edhoc], the usual ephemeral
     Diffie-Hellman elements (x,g^x) and (y,g^y), are here replaced by an
     ephemeral KEM:

     *  At first, the Initiator generates a ephemeral KEM key pair
        (kem.sk_eph, kem.pk_eph) using the KEM.KeyGen(k) algorithm (where
        k is a security parameter);

     *  On reception of the ephemeral KEM public key kemp.pk_eph, the
        Responder generates a pair (ss_eph, kem.ct_eph) with the
        KEM.Encapsulation algorithm (with input kem.pk_eph).  The element
        ss_eph is the ephemeral shared-secret, later used to derive a key,
        and kem.ct_eph is the ephemeral KEM ciphertext, used by the
        Initiator to retrieve the ephemeral shared-secret;






  Papon & Onete           Expires 2 September 2026               [Page 11]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  On reception of the ephemeral KEM ciphertext, the Initiator
        recovers the ephemeral shared-secret ss_eph thanks to the
        KEM.Decapsulation' algorithm (with inputkem.sk_ephandkem.ct_eph`).

  2.2.3.2.  Authentication keys

     For the Initiator, the authentication key MUST be a static signing
     key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k)
     algorithm (where k is a security parameter).

     For the Responder, the authentication key MUST be a static KEM key
     pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm
     (where k is a security parameter).

  2.2.3.3.  Key derivation

     In this version of the protocol, the EDHOC_Extract fonction is used
     to derive two keys, in a way that slightly differ from the original
     EDHOC protocol.

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2
        and the IKM SHALL be the ephemeral shared-secret ss_eph;

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be
        SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the
        'static' shared-secret ss_R.

     Concerning PRK_out, there is no modifications compared to the
     original EDHOC protocol.

  2.3.  Analysis

     In summary, we retain here the use case proposed by
     [I-D.pocero-authkem-ikr-edhoc], where the Initiator already knows the
     Responder identity.  Our protocol proposes a hybridization between
     the protocol proposed by [I-D.pocero-authkem-ikr-edhoc] and EDHOC
     method 1.  In other words, Diffie-Hellman elements are replaced with
     KEMs, and the Initiator authenticates here using a signature (instead
     of a KEM).  An important difference with the proposal of
     [I-D.pocero-authkem-ikr-edhoc] concerns the first message message_1,
     which in our version is simplified and remains closer to the standard
     EDHOC structure.  Indeed, the Initiator authenticates via a signature
     at the third message.  So he no longer needs to derive a key and
     encrypt part of the first message to securely send its identity.  The
     second message also finds itself simplified.  Since the Initiator
     does not use KEM in this situation, the Responder has no need to
     generate a shared-secret ss_I and send the KEM ciphertext kem.ct_I.
     The second message is therefore closer to the usual EDHOC structure.



  Papon & Onete           Expires 2 September 2026               [Page 12]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Finally, the third message is almost 'identical' to the third message
     of the EDHOC method 1 protocol.  It seems important to note that
     complete and secure authentication is ensured here entirely in three
     messages, and the fourth message is optional.  Regarding the Key
     Derivation Schedule, the changes are minor compared to [RFC9528]
     (adaptation of notations, especially for the IKM to take into account
     the post-quantum nature of the cryptographic material) and
     [I-D.pocero-authkem-ikr-edhoc] (simply one less key derivation, since
     the Initiator uses a signature rather than a static KEM).  We will
     discuss security considerations further in this document.  We will
     also soon present a byte comparison for each message.

  3.  KEM & Sign Authentication for Post-Quantum EDHOC

  3.1.  Motivation

     Our second idea is to propose a tradeoff, allowing for a reduced
     number of messages in the quantum-resistant EDHOC handshake, which
     come at a slightly higher computational overhead compared to
     [I-D.pocero-authkem-edhoc].

     Starting from the standard EDHOC protocol, method 0 allows for mutual
     authentication via signature between both users.  As proposed in
     [I-D.pocero-authkem-edhoc], replacing classical signatures with post-
     quantum resistant signatures such as ML-DSA and ephemeral Diffie-
     Hellman elements with a KEM like ML-KEM seems reasonable to make
     EDHOC post-quantum resistant (even if this still needs to be proved).
     These two changes do not affect the number of mandatory messages,
     since the fundamental structure of the protocol is preserved (however
     a post-quantum signature will likely be more computationally
     expensive, just like a KEM).  Things get complicated when trying to
     apply these modifications to the other three methods.  Continuing on
     this track, we replace ephemeral Diffie-Hellman elements with an
     ephemeral KEM.  This does not affect the usual structure of EDHOC.
     However, if we want to take it further and also replace long-term
     Diffie-Hellman elements with a KEM, managing asymmetric keys for the
     latter poses a problem when trying to preserve the authentication
     structure of EDHOC, namely a MAC derived from a long-term secret.  As
     proposed in [I-D.pocero-authkem-edhoc], we go from 3 to 4 or 5
     mandatory messages to achieve complete mutual authentication.  Here,
     we want to explore a different path.  Our solution aims to strike a
     balance between the number of mandatory messages and the computations
     performed by each endpoint.

     The principle is as follows.  Suppose that the Initiator
     authenticates with a signature and the Responder uses a KEM.  In this
     case, we will need an obligatory fourth message (for the Initiator to
     authenticate the Responder via the MAC, as proposed in



  Papon & Onete           Expires 2 September 2026               [Page 13]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     [I-D.pocero-authkem-edhoc]).  To avoid this obligatory fourth message
     and return to three, we propose removing the MAC MAC_2 used to
     authenticate the Responder (eliminating calculations on both sides)
     and replacing it with a signature from the Responder (adding
     calculations on both sides).  To do this, the Responder signs an
     element (which should not be chosen randomly for security reasons and
     which must allow the Initiator to identify the session) and sends it
     directly (encrypted) in the second message.  The Initiator can then
     immediately identify the Responder: it retrieves its identity from
     the encrypted message and verifies the signature.  The rest of the
     protocol remains 'unchanged', and the calculation of PRK_out is
     possible directly after sending/receiving the third message (thus no
     more obligatory fourth message).  The costs of calculations are
     compensated, but the delicate point remains the size of the second
     message (we will provide a bytes analysis for this message later).
     We decline this procedure when the Initiator wants to authenticate
     with a KEM and the Responder with a signature, or when both parties
     want to authenticate with KEMs.  In these two latter cases, the
     number of mandatory messages compared to [I-D.pocero-authkem-edhoc]
     decreases from 5 to 4.

  3.2.  First case: Initiator signs, Responder KEM and signs

     We describe below the equivalent of EDHOC method 1.  The Initiator
     will authenticate with a signature, and the Responder with a KEM and
     a signature.

  3.2.1.  Protocol overview

       I                                                                R
      ---                                                              ---
       |            METHOD, SUITES_I, kem.pk_eph, C_I, EAD_1            |
       +---------------------------------------------------------------->
       |                            message_1                           |
       |                                                                |
       |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)|
       <----------------------------------------------------------------+
       |                            message_2                           |
       |                                                                |
       |          kem.ct_R, AEAD(ID_CRED_I, SIGNATURE_3, EAD_3)         |
       +---------------------------------------------------------------->
       |                            message_3                           |
       |                                                                |
       |                           AEAD(EAD_4)                          |
       <- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
       |                            message_4                           |

     Figure 3: PQ-EDHOC, I Signs - R KEM & Signs message flow.



  Papon & Onete           Expires 2 September 2026               [Page 14]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  3.2.2.  Protocol description

  3.2.2.1.  Formatting and sending message_1

     As in the usual EDHOC protocol, the first message (message_1)
     consists of:

     *  METHOD --> as specified in [RFC9528] it is an integer specifying
        the authentication method the Initiator wants to use;

     *  SUITES_I --> it consists of an ordered set of algorithms supported
        by the Initiator and formatted as specified in [RFC9528];

     *  C_I (and also as C_R, which will appears later) --> the Connection
        Identifiers chosen by the Initiator (C_I) and by the Responder
        (C_R) as specified in [RFC9528];

     *  EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later)
        -> External Authorization Data, respectively included in
        message_1, message_2, message_3 (and optionally) message_4, and
        formatted as specified in [RFC9528];

     *  kem.pk_eph --> the Ephemeral KEM public key generated by the
        Initiator.

  3.2.2.2.  Processing message_1, formatting and sending message_2

     On the reception of the first message, the Responder proceeds as in
     the original EDHOC protocol with elements METHOD, SUITES_I, C_I and
     EAD_1.  In a second step, using kem.pk_eph and the KEM.Encapsulation
     algorithm, he computes the ephemeral ciphertext kem.ct_eph and the
     ephemeral shared-secret ss_eph.

     The Responder selects its Connection Identifier C_R as specified in
     [RFC9528].  He then computes:

     *  TH_2 = H(kem.ct_eph, H(message_1));

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph);

     *  KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length).

     The Responder now assembles PLAINTEXT_2:

     *  PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2)

     then signs this message :




  Papon & Onete           Expires 2 September 2026               [Page 15]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  SIGNATURE_2 = DS.Sign(sign.sk_R, (PLAINTEXT_2, sign_length))

     where sign.sk_R is the long-term signing private key of the
     Responder, and finally ciphers PLAINTEXT_2A = (PLAINTEXT_2,
     SIGNATURE_2):

     *  CIPHERTEXT_2 = PLAINTEXT_2A XOR KEYSTREAM_2.

     So the second message then consists of:

     *  kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph;

     *  CIPHERTEXT_2.

     *Important note:* let us mention that the element signed by the
     Responder, for security considerations during the security analysis,
     could be subject to slight changes.  However, it serves here to
     illustrate the principle proposed here.

  3.2.2.3.  Processing message_2, formatting and sending message_3

     On reception of the second message, the Initiator, using kemp.ct_eph,
     can compute the ephemeral shared-secret ss_eph.  As the Responder
     did, he computes TH_2, PRK_2e and KEYSTREAM_2.  He can now decipher
     and retrieve : PLAINTEXT_2A = CIPHERTEXT_2 XOR KEYSTREAM_2.

     Thanks to ID_CRED_R, the Initiator obtains the long-term public keys
     of the Responder, kemp.pk_R and sign.pk_R.  At first, he checks the
     validity of the signature of the Responder:

     *  DS.Verify(sign.pk_R, (PLAINTEXT_2, sign_length), SIGNATURE_2).

     If the verification algorithm returns 1, the Initiator properly
     authenticated the Responder.  Otherwise he aborts.

     Assuming everything goes well, using the KEM encapsulation algorithm
     KEM.Encapsulation, and the long-term input material kem.pk_R of the
     Responder, the Initiator generated the couple (ss_R, kem.ct_R).

     The shared-secret ss_R will then serve as IKM for the computation of
     PRK_3e2m:

     *  SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R).

     It is now the turn of the Initiator to authenticate himself.  To do
     so, he computes the following elements:



  Papon & Onete           Expires 2 September 2026               [Page 16]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  TH_3 = H(TH_2, PLAINTEXT_2A, ID_CRED_R);

     *  K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);

     *  IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);

     *  MAC_3 = EDHOC_KDF(PRK_3e2m, 6, ID_CRED_I, TH_3, EAD_3,
        mac_length_3)

     as in the original EDHOC protocol.  Then comes the signature:

     *  SIGNATURE_3 = DS.Sign(sign.sk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3,
        sign_length))

     where sign.sk_I is the long-term signing private key of the
     Initiator.

     Setting PLAINTEXT_3 = (ID_CRED_I, SIGNATURE_3, EAD_3), the Initiator
     ciphers PLAINTEXT_3 with the AEAD encryption algorithm negociated in
     SUITES_I.  The third message is then composed of:

     *  CIPHERTEXT_3;

     *  kem.ct_R.

  3.2.2.4.  Processing message_3

     On reception of message_3, the Responder computes TH_3.  He also used
     the KEM.Decapsulation algorithm with its long-term KEM private key
     kem.sk_R and the KEM ciphertext kem.ct_R, to obtain the shared-secret
     ss_R.

     He can now compute SALT_3e2m, PRK_3e2m, K_3, and IV_3 as the
     Initiator did, and deciphers CIPHERTEXT_3 with the AEAD decryption
     algorithm.  With PLAINTEXT_3, he calculates MAC_3 on his side, and
     verifies the signature:

     *  DS.Verify(sign.pk_I, (ID_CRED_I, TH_3, EAD_3, MAC_3, sign_length),
        SIGNATURE_3)

     where sign.pk_I is the long-term signing public key of the Initiator.
     If the verification algorithm returns 1, the Initiator is properly
     authenticated to the Initiator.  Otherwise the Responder aborts.

  3.2.2.5.  Optionally formatting, sending and receiving message_4

     If the Responder decides of a fourth mandatory message, he then
     computes the following elements:



  Papon & Onete           Expires 2 September 2026               [Page 17]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I);

     *  K_4 = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length);

     *  IV_4 = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length).

     Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4
     and sends it to the Initiator.  The latter computes TH_4, K_4, IV_4,
     and deciphers CIPHERTEXT_4 thanks to the AEAD decryption algorithm.

  3.2.2.6.  Computing the session key PRK_out

     Here again, it doesn't matter if there is a fourth mandatory message,
     in any case, both the Initiator and the Responder, in order to
     compute the key PRK_out, have to calculate the fourth transcript hash
     as in the original EDHOC protocol:

     *  TH_4 = H(TH_3, PLAINTEXT_3, ID_CRED_I).

     With this element, using the EDHOC_KDF, they both obtain:

     *  PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length)

     which is the desired session key, and the authentication process is
     fully achieved.

  3.2.3.  Associated key derivation schedule

     In this section we present the key derivation schedule of the
     previously described protocol version.

               +--------------------------------+
               |TH_2=H(kem.ct_eph, H(message_1))|
               +------+----------------------+--+             PLAINTEXT_2A
                      |                      |                        |
       +------+   +---+---+   +------+   +---+--+   +-----------+   +-+-+
       |ss_eph|-->|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR|
       +------+   +-------+   +---+--+   +---+--+   +-----------+   +-+-+
                                  |                                   |
                                  |                                   v
                                  |                         +---------+--+
                                  |                         |CIPHERTEXT_2|
                                  |                         +---------+--+
                                  |
                +---------+   +---+--+
                |SALT_3e2m|<--|Expand|
                +---+-----+   +---+--+                         PLAINTEXT_3
                    |                                               |



  Papon & Onete           Expires 2 September 2026               [Page 18]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


       +----+   +---+---+   +--------+   +------+   +--------+   +--+-+
       |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD|
       +----+   +-------+   +---+----+   +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_3|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)|
                                |   +------------------------------------+
                                |
                                |       +------+   +-----+   +-----------+
                                +-------|Expand|-->|MAC_3|-->|SIGNATURE_3|
                                |       +------+   +-----+   +-----------+
                                |
                                |                              PLAINTEXT_4
                                |                                   |
                                |        +------+   +--------+   +--+-+
                    message_4?  +--------|Expand|-->|K_4/IV_4|-->|AEAD|
                                |        +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_4|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)|
                                |   +--------+---------------------------+
                                |            |
                                |            |
                                |        +---+--+   +-------+
                                +--------|Expand|-->|PRK_out|
                                         +------+   +-------+

     Figure 4: PQ-EDHOC, I Signs - R KEM & Signs key derivation schedule.

     So we can summarize the different computations as previously:











  Papon & Onete           Expires 2 September 2026               [Page 19]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


       PRK_2e      = EDHOC_Extract(TH_2, ss_eph);
       KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);
       SALT_3e2m   = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);
       PRK_3e2m    = EDHOC_Extract(SALT_3e2m, ss_R);
       K_3         = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);
       IV_3        = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);
       MAC_3       = EDHOC_KDF(PRK_3e2m, 6, context_3, mac_length_3)
                          (with context_3 = ID_CRED_I, TH_3, EAD_3);
       K_4         = EDHOC_KDF(PRK_3e2m, 8, TH_4, key_length);
       IV_4        = EDHOC_KDF(PRK_3e2m, 9, TH_4, iv_length);
       PRK_out     = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length).

  3.2.4.  Additional explanations

     We detail here the main elements that differ from the original EDHOC
     protocol.

  3.2.4.1.  Ephemeral KEM

     As previously explain the usual ephemeral Diffie-Hellman elements are
     replaced by an ephemeral KEM.  In this protocol, it works exactly as
     we previously described.

  3.2.4.2.  Authentication keys

     For the Initiator, the authentication key MUST be a static signing
     key pair (sign.sk_I, sign.pk_I) generated using a DS.KeyGen(k)
     algorithm (where k is a security parameter).

     For the Responder, the authentication key MUST be: (1) a static KEM
     key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k)
     algorithm (where k is a security parameter) *and* (2) a static
     signing key pair (sign.sk_R, sign.pk_R) generated using a
     DS.KeyGen(k) algorithm (where k is a security parameter).

  3.2.4.3.  Key derivation

     In this version of the protocol, the keys PRK_2e and PRK_3e2m are
     obtain thanks to EDHOC_Extract fonction:

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2
        and the IKM SHALL be the ephemeral shared-secret ss_eph;

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be
        SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the
        'static' shared-secret ss_R.





  Papon & Onete           Expires 2 September 2026               [Page 20]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Concerning PRK_out, here again, there is no modifications compared to
     the original EDHOC protocol.

  3.2.5.  Analysis

     In this version of the protocol, we assumed that the Initiator has a
     pair of static signature keys (sign.sk_I, sign.pk_I) and that the
     Responder has not only a pair of static signature keys (sign.sk_R,
     sign.pk_R) but also a pair of static KEM keys (kem.sk_R, kem.pk_R).
     This is not an unusual case.  We can suppose that each user, when
     registering in a Public Key Infrastructure (PKI), provides pairs of
     keys of both types (signature and KEM), which they update regularly.
     The difference in our protocol is that the Responder is forced to use
     both types during the same AKE.  From a technical point of view, the
     first message message_1 and the third message message_3 do not differ
     from those proposed in [I-D.pocero-authkem-edhoc].  Two major
     differences are worth noting regarding the messages.  Firstly, here
     we have only an *optional* fourth message message_4.  Secondly, our
     second message message_2 contains an additional signature SIGNATURE_2
     in PLAINTEXT_2A (before ciphering) (we will propose a byte analysis
     of this message later).  Finally, from a computational point of view,
     both the Initiator and the Responder no longer need to calculate the
     MAC MAC_2.  In return, the Responder must sign a message, and the
     Initiator must verify this signature.  Regarding the Key Derivation
     Schedule, aside from the IKM which adapts to post-quantum
     cryptographic material, we remain close to the one of EDHOC's method
     1.  We thus have a tradeoff between the size of messages, calculation
     capabilities, and the number of messages.

  3.3.  Second case: Initiator KEM and signs, Responder signs

     We now invert the roles and describe below the equivalent of EDHOC
     method 2.  The Initiator will authenticate with a KEM and a
     signature, and the Responder only with a signature.

  3.3.1.  Protocol overview















  Papon & Onete           Expires 2 September 2026               [Page 21]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


       I                                                                R
      ---                                                              ---
       |            METHOD, SUITES_I, kem.pk_eph, C_I, EAD_1            |
       +---------------------------------------------------------------->
       |                            message_1                           |
       |                                                                |
       |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)|
       <----------------------------------------------------------------+
       |                            message_2                           |
       |                                                                |
       |               AEAD(ID_CRED_I, EAD_3, SIGNATURE_3)              |
       +---------------------------------------------------------------->
       |                            message_3                           |
       |                                                                |
       |                      kem.ct_I, AEAD(EAD_4)                     |
       <----------------------------------------------------------------+
       |                            message_4                           |

     Figure 5: PQ-EDHOC, I KEM & Signs - R Signs message flow.

  3.3.2.  Protocol description

  3.3.2.1.  Formatting and sending message_1

     As for our previous protocol version, the first message (message_1)
     consists of:

     *  METHOD --> as specified in [RFC9528] it is an integer specifying
        the authentication method the Initiator wants to use;

     *  SUITES_I --> it consists of an ordered set of algorithms supported
        by the Initiator and formatted as specified in [RFC9528];

     *  C_I (and also as C_R, which will appears later) --> the Connection
        Identifiers chosen by the Initiator (C_I) and by the Responder
        (C_R) as specified in [RFC9528];

     *  EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later)
        -> External Authorization Data, respectively included in
        message_1, message_2, message_3 (and optionally) message_4, and
        formatted as specified in [RFC9528];

     *  kem.pk_eph --> the Ephemeral KEM public key generated by the
        Initiator.







  Papon & Onete           Expires 2 September 2026               [Page 22]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  3.3.2.2.  Processing message_1, formatting and sending message_2

     On the reception of the first message, the Responder proceeds as in
     the original EDHOC protocol with elements METHOD, SUITES_I, C_I and
     EAD_1.  In a second step, using kem.pk_eph and the KEM.Encapsulation
     algorithm, he computes the ephemeral ciphertext kem.ct_eph and the
     ephemeral shared-secret ss_eph.

     The Responder selects its Connection Identifier C_R as specified in
     [RFC9528].  He then computes:

     *  TH_2 = H(kem.ct_eph, H(message_1));

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph);

     *  KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length).

     In order to authenticate himself to the Initiator, in this version,
     similarly to the EDHOC method 2, the Responder computes a MAC MAC_2
     and signs it with its long-term signing private key sign.sk_R:

     *  MAC_2 = EDHOC_KDF(PRK_2e, 2, C_R, ID_CRED_R, TH_2, EAD_2,
        mac_length_2);

     *  SIGNATURE_2 = DS.Sign(sign.sk_R, (C_R, ID_CRED_R, TH_2, EAD_2,
        MAC_2, sign_length)).

     The Responder now assembles PLAINTEXT_2:

     *  PLAINTEXT_2 = (C_R, ID_CRED_R, SIGNATURE_2, EAD_2)

     then ciphers this message :

     *  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

     and finally sends message_2 composed of CIPHERTEXT_2 and kem.ct_eph.
     So, so far, except the ephemeral KEM material, everything works like
     in the usual EDHOC method 2 protocol.

  3.3.2.3.  Processing message_2, formatting and sending message_3

     On reception of the second message, the Initiator, using kemp.ct_eph,
     can compute the ephemeral shared-secret ss_eph.  As the Responder
     did, he computes TH_2, PRK_2e and KEYSTREAM_2.  He can now decipher
     and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2.






  Papon & Onete           Expires 2 September 2026               [Page 23]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Thanks to ID_CRED_R, the Initiator obtains the long-term signing
     public key of the Responder, sign.pk_R.  He can then compute MAC_2 on
     its own, and check the validity of the signature of the Responder:

     *  DS.Verify(sign.pk_R, (C_R, ID_CRED_R, TH_2, EAD_2, MAC_2,
        sign_length), SIGNATURE_2).

     If the verification algorithm returns 1, the Initiator properly
     authenticated the Responder.  Otherwise he aborts.

     Assuming everything goes well, the Initiator computes the following
     elements:

     *  TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R);

     *  K_3 = EDHOC_KDF(PRK_2e, 3, TH_3, key_length);

     *  IV_3 = EDHOC_KDF(PRK_2e, 4, TH_3, iv_length).

     Then, in order to authenticate, he forms PLAINTEXT_3 = (ID_CRED_I,
     TH_3, EAD_3) and signs it:

     *  SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length)).

     where sign.sk_I is the long-term signing private key of the
     Initiator.  Finally he ciphers PLAINTEXT_3A = (PLAINTEXT_3,
     SIGNATURE_3) with the AEAD encryption algorithm negociated in
     SUITES_I, as CIPHERTEXT_3.

     The third message is then composed of:

     *  CIPHERTEXT_3.

     *Important note:* let us mention that the element signed by the
     Initiator, here again, for security considerations during the
     security analysis, could be subject to slight changes.

  3.3.2.4.  Processing message_3, formatting and sending message_4

     On reception of message_3, the Responder computes TH_3, K_3 and IV_3,
     and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm.  With
     PLAINTEXT_3A, he obtains the Initiator's long-term signing public
     key, and so he verifies the signature:

     *  DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3).






  Papon & Onete           Expires 2 September 2026               [Page 24]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     If the verification algorithm returns 1, the Initiator is properly
     authenticated to the Initiator.  Otherwise the Responder aborts.
     With PLAINTEXT_3, the Responder also gets the Initiator's long-term
     KEM public key.  He then uses the KEM.Encapsulation algorithm to
     generate ss_I and kem.ct_I.

     Following that, he computes:

     *  TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I);

     *  SALT_4e3m = EDHOC_KDF(PRK_2e, 5, TH_4, hash_length);

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I);

     *  K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);

     *  IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length).

     Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4
     and sends it to the Initiator, along with kem.ct_I.  He then finishes
     the AKE by computing the final key PRK_out:

     *  PRK_out = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

  3.3.2.5.  Processing message_4

     In this situation the fourth message is mandatory.  It is used to
     send the KEM ciphertext kem.ct_I to the Initiator (it cannot be
     shared before, since the Responder only learns the identity of the
     Initiator with the third message).

     When receiving this last message, the Initiator computes the shared-
     secret ss_I thanks to the KEM.Decapsulation algorithm, and elements
     kem.sk_I, kem.ct_I.  After that, he can compute TH_4, K_4, IV_4, and
     decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm.  Once
     he had checked the well formedness of PLAINTEXT_4, he can finally
     compute PRK_out as the Responder did.

  3.3.3.  Associated key derivation schedule

     In this section we present the key derivation schedule of the
     previously described protocol version.









  Papon & Onete           Expires 2 September 2026               [Page 25]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


               +--------------------------------+
               |TH_2=H(kem.ct_eph, H(message_1))|
               +------+----------------------+--+              PLAINTEXT_2
                      |                      |                        |
       +------+   +---+---+   +------+   +---+--+   +-----------+   +-+-+
       |ss_eph|-->|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR|
       +------+   +-------+   +---+--+   +---+--+   +-----------+   +-+-+
                                  |                                   |
                                  |                                   v
                                  |                         +---------+--+
                                  |                         |CIPHERTEXT_2|
                                  |                         +------------+
                                  |
                                  |     +------+   +-----+   +-----------+
                                  +-----|Expand|-->|MAC_2|-->|SIGNATURE_2|
                                  |     +------+   +-----+   +-----------+
                                  |
                                  | +------------------------------------+
                                  | |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)|
                                  | +--------+---------------------------+
                                  |          |
                                  |          |                PLAINTEXT_3A
                                  |          |                      |
                                  |      +---+--+   +--------+   +--+-+
                                  +------|Expand|-->|K_3/IV_3|-->|AEAD|
                                  |      +---+--+   +--------+   +--+-+
                                  |                                 |
                                  |                                 v
                                  |                         +-------+----+
                                  |                         |CIPHERTEXT_3|
                                  |                         +-------+----+
                                  |
                +---------+   +---+--+
                |SALT_4e3m|<--|Expand|
                +---+-----+   +---+--+                         PLAINTEXT_4
                    |                                               |
       +----+   +---+---+   +--------+   +------+   +--------+   +--+-+
       |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|K_4/IV_4|-->|AEAD|
       +----+   +-------+   +---+----+   +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_4|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)|
                                |   +--------+---------------------------+



  Papon & Onete           Expires 2 September 2026               [Page 26]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


                                |            |
                                |        +---+--+   +-------+
                                +--------|Expand|-->|PRK_out|
                                         +------+   +-------+

     Figure 6: PQ-EDHOC, I KEM & Signs - R Signs key derivation schedule.

     So we can summarize the different computations as previously:

       PRK_2e      = EDHOC_Extract(TH_2, ss_eph);
       KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);
       MAC_2       = EDHOC_KDF(PRK_2e, 2, context_2, mac_length_2)
                   (with context_2 = C_R, ID_CRED_R, TH_2, EAD_2);
       K_3         = EDHOC_KDF(PRK_2e, 3, TH_3, key_length);
       IV_3        = EDHOC_KDF(PRK_2e, 4, TH_3, iv_length);
       SALT_4e3m   = EDHOC_KDF(PRK_2e, 5, TH_4, hash_length);
       PRK_4e3m    = EDHOC_Extract(SALT_4e3m, ss_I);
       K_4         = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);
       IV_4        = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length);
       PRK_out     = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

  3.3.4.  Additional explanations

     We detail here the main elements that differ from the original EDHOC
     protocol.

  3.3.4.1.  Ephemeral KEM

     As previously explain the usual ephemeral Diffie-Hellman elements are
     replaced by an ephemeral KEM.  In this protocol, it works exactly as
     we previously described.

  3.3.4.2.  Authentication keys

     For the Initiator, the authentication key MUST be: (1) a static KEM
     key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k)
     algorithm (where k is a security parameter) *and* (2) a static
     signing key pair (sign.sk_I, sign.pk_I) generated using a
     DS.KeyGen(k) algorithm (where k is a security parameter).

     For the Responder, the authentication key MUST be a static signing
     key pair (sign.sk_R, sign.pk_R) generated using a DS.KeyGen(k)
     algorithm (where k is a security parameter).

  3.3.4.3.  Key derivation

     In this version of the protocol, the keys PRK_2e and PRK_4e3m are
     obtain thanks to EDHOC_Extract fonction:



  Papon & Onete           Expires 2 September 2026               [Page 27]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2
        and the IKM SHALL be the ephemeral shared-secret ss_eph;

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be
        SALT_4e3m directly derived from PRK_2e, and the IKM SHALL be the
        'static' shared-secret ss_I.

     Concerning PRK_out, here again, there is no modifications compared to
     the original EDHOC protocol.  We can note that in this two previous
     cases, the Key Derivation Schedule remains close to the standard
     EDHOC Key Derivation Schedule of method 1 and 2.

  3.3.5.  Analysis

     This is actually a mirror version of the previous protocol presented,
     in the sense that this time we assumed that the Responder has a pair
     of static signature keys (sign.sk_R, sign.pk_R) and that the
     Initiator has not only a pair of static signature keys (sign.sk_I,
     sign.pk_I) but also a pair of static KEM keys (kem.sk_I, kem.pk_I).
     For the same reasons, this is not an unusual case.

     From a technical point of view, messages message_1,message_2 and
     message_4 do not differ from those proposed in
     [I-D.pocero-authkem-edhoc].  Here again, two major differences are
     worth noting regarding the messages.  Firstly, here we no more have a
     fifth mandatory message message_5.  Secondly, our third message
     message_3 contains an additional signature SIGNATURE_3 in
     PLAINTEXT_3A (before ciphering) (as this was the case for the
     previous protocol we propose, with SIGNATURE_2) (we will propose a
     byte analysis of this message later).  Finally, from a computational
     point of view, both the Initiator and the Responder no longer need to
     calculate the MAC MAC_3.  In return, in the same vein, the Initiator
     must sign a message, and the Responder must verify this signature, in
     order to authenticate the Initiator, and send him the KEM ciphertext
     kem.ct_I.  Regarding the Key Derivation Schedule, aside from the IKM
     which adapts to post-quantum cryptographic material, we remain close
     to the one of EDHOC's method 2.  So compared to
     [I-D.pocero-authkem-edhoc], we reduce the number of mandatory
     messages, from 5 to 4, and again we obtain a tradeoff between the
     size of messages, calculation capabilities, and the number of
     messages.










  Papon & Onete           Expires 2 September 2026               [Page 28]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  3.4.  Third case: Initiator and Responder KEM and sign - version 1

     We now present the equivalent of EDHOC method 3, which is in our
     case, an hybridation of the previous cases.  We propose two variant
     of this version.  We start here with the first one, where the
     Initiator authenticates with a KEM and a signature, and the Responder
     with only a KEM.  More specifically, this first version is a kind of
     hybrid between a protocol proposed in [I-D.pocero-authkem-edhoc] and
     one of the protocols we have proposed above.

  3.4.1.  Protocol overview

       I                                                              R
      ---                                                            ---
       |           METHOD, SUITES_I, kem.pk_eph, C_I, EAD_1           |
       +-------------------------------------------------------------->
       |                           message_1                          |
       |                                                              |
       |      kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2)     |
       <--------------------------------------------------------------+
       |                           message_2                          |
       |                                                              |
       |         kem.ct_R, AEAD(ID_CRED_I, EAD_3, SIGNATURE_3)        |
       +-------------------------------------------------------------->
       |                           message_3                          |
       |                                                              |
       |                 kem.ct_I, AEAD(EAD_4, MAC_2)                 |
       <--------------------------------------------------------------+
       |                           message_4                          |

     Figure 7: PQ-EDHOC, I KEM & Signs - R KEM message flow.

  3.4.2.  Protocol description

  3.4.2.1.  Formatting and sending message_1

     As for our previous protocol version, the first message (message_1)
     consists of:

     *  METHOD --> as specified in [RFC9528] it is an integer specifying
        the authentication method the Initiator wants to use;

     *  SUITES_I --> it consists of an ordered set of algorithms supported
        by the Initiator and formatted as specified in [RFC9528];

     *  C_I (and also as C_R, which will appears later) --> the Connection
        Identifiers chosen by the Initiator (C_I) and by the Responder
        (C_R) as specified in [RFC9528];



  Papon & Onete           Expires 2 September 2026               [Page 29]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later)
        -> External Authorization Data, respectively included in
        message_1, message_2, message_3 (and optionally) message_4, and
        formatted as specified in [RFC9528];

     *  kem.pk_eph --> the Ephemeral KEM public key generated by the
        Initiator.

  3.4.2.2.  Processing message_1, formatting and sending message_2

     On the reception of the first message, the Responder proceeds as in
     the original EDHOC protocol with elements METHOD, SUITES_I, C_I and
     EAD_1.  In a second step, using kem.pk_eph and the KEM.Encapsulation
     algorithm, he computes the ephemeral ciphertext kem.ct_eph and the
     ephemeral shared-secret ss_eph.

     The Responder selects its Connection Identifier C_R as specified in
     [RFC9528].  He then computes:

     *  TH_2 = H(kem.ct_eph, H(message_1));

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph);

     *  KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length).

     In this version the Responder authenticates with the fourth mandatory
     message.  So he directly assembles PLAINTEXT_2:

     *  PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2)

     then ciphers this message :

     *  CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

     and finally sends message_2 composed of CIPHERTEXT_2 and kem.ct_eph.

  3.4.2.3.  Processing message_2, formatting and sending message_3

     On reception of the second message, the Initiator, using kemp.ct_eph,
     can compute the ephemeral shared-secret ss_eph.  As the Responder
     did, he computes TH_2, PRK_2e and KEYSTREAM_2.  He can now decipher
     and retrieve : PLAINTEXT_2 = CIPHERTEXT_2 XOR KEYSTREAM_2.

     Thanks to ID_CRED_R, the Initiator obtains the long-term KEM public
     key of the Responder, kem.pk_R.  He then uses the KEM.Encapsulation
     algorithm to generate ss_R and kem.ct_R.

     He then computes the following elements:



  Papon & Onete           Expires 2 September 2026               [Page 30]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R);

     *  TH_3 = H(TH_2, PLAINTEXT_2, ID_CRED_R);

     *  K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);

     *  IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length).

     Then, in order to authenticate, he then forms PLAINTEXT_3 =
     (ID_CRED_I, TH_3, EAD_3) and signs it:

     *  SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length))

     where sign.sk_I is the long-term signing private key of the
     Initiator.  Finally he sets PLAINTEXT_3A = (PLAINTEXT_3, SIGNATURE_3)
     and ciphers it with the AEAD encryption algorithm negociated in
     SUITES_I, as CIPHERTEXT_3.

     The third message is then composed of:

     *  kem.ct_R;

     *  CIPHERTEXT_3.

  3.4.2.4.  Processing message_3, formatting and sending message_4

     On reception of message_3, the Responder computes TH_3.  He also used
     the KEM.Decapsulation algorithm with its long-term KEM private key
     kem.sk_R and the KEM ciphertext kem.ct_R, to obtain the shared-secret
     ss_R.

     He can now compute SALT_3e2m, PRK_3e2m, K_3, and IV_3 as the
     Initiator did, and deciphers CIPHERTEXT_3 with the AEAD decryption
     algorithm.  With PLAINTEXT_3A, he obtains kem.pk_I and sign.pk_I, and
     verifies the signature:

     *  DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3).

     If the verification algorithm returns 1, the Initiator is properly
     authenticated to the Initiator.  Otherwise the Responder aborts.

     He then uses the KEM.Encapsulation algorithm to generate ss_I and
     kem.ct_I.

     Following that, he computes:




  Papon & Onete           Expires 2 September 2026               [Page 31]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I);

     *  SALT_4e3m = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length);

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I);

     *  K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);

     *  IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length).

     The Responder now needs to authenticate.  For that, he computes a MAC
     MAC_2:

     *  MAC_2 = EDHOC_KDF(PRK_4e3m, 2, C_R, ID_CRED_R, TH_4, EAD_4,
        mac_length_2).

     Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = (EAD_4,
     MAC_2) and sends it to the Initiator, along with kem.ct_I.  He then
     finishes the AKE by computing the final key PRK_out:

     *  PRK_out = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

  3.4.2.5.  Processing message_4

     In this situation the fourth message is mandatory.  It is used to
     send the KEM ciphertext kem.ct_I to the Initiator (it cannot be
     shared before, since the Responder only learns the identity of the
     Initiator with the third message).

     When receiving this last message, the Initiator computes the shared-
     secret ss_I thanks to the KEM.Decapsulation algorithm, and elements
     kem.sk_I, kem.ct_I.  After that, he can compute TH_4, K_4, IV_4, and
     decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm.  Once
     he had checked the well formedness of PLAINTEXT_4, he can
     authenticate the Responder by computing MAC_2 on its own and
     comparing with the one he finds in PLAINTEXT_4.  If everything goes
     well, he finally computes PRK_out as the Responder did.

  3.4.3.  Associated key derivation schedule

     In this section we present the key derivation schedule of the
     previously described protocol version.









  Papon & Onete           Expires 2 September 2026               [Page 32]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


               +--------------------------------+
               |TH_2=H(kem.ct_eph, H(message_1))|
               +------+----------------------+--+              PLAINTEXT_2
                      |                      |                        |
       +------+   +---+---+   +------+   +---+--+   +-----------+   +-+-+
       |ss_eph|-->|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR|
       +------+   +-------+   +---+--+   +---+--+   +-----------+   +-+-+
                                  |                                   |
                                  |                                   v
                                  |                         +---------+--+
                                  |                         |CIPHERTEXT_2|
                                  |                         +------------+
                +---------+   +---+--+
                |SALT_3e2m|<--|Expand|
                +---+-----+   +---+--+
                    |               +------------------------------------+
                    |               |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)|
                    |               +-------+----------------------------+
                    |                       |
                    |                       |                 PLAINTEXT_3A
                    |                       |                       |
       +----+   +---+---+   +--------+   +--+---+   +--------+   +--+-+
       |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD|
       +----+   +-------+   +---+----+   +---+--+   +--------+   +--+-+
                                  |                                 |
                                  |                                 v
                                  |                         +-------+----+
                                  |                         |CIPHERTEXT_3|
                                  |                         +-------+----+
                                  |
                +---------+   +---+--+
                |SALT_4e3m|<--|Expand|
                +---+-----+   +---+--+
                    |
       +----+   +---+---+   +--------+   +------+   +-----+
       |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|MAC_2|
       +----+   +-------+   +---+----+   +------+   +-----+
                                |
                                |                              PLAINTEXT_4
                                |                                   |
                                |        +------+   +--------+   +--+-+
                                +--------|Expand|-->|K_4/IV_4|-->|AEAD|
                                |        +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_4|
                                |            |              +------------+



  Papon & Onete           Expires 2 September 2026               [Page 33]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


                                |            |
                                |   +--------+---------------------------+
                                |   |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)|
                                |   +--------+---------------------------+
                                |            |
                                |        +---+--+   +-------+
                                +--------|Expand|-->|PRK_out|
                                         +------+   +-------+

     Figure 8: PQ-EDHOC, I KEM & Signs - R KEM key derivation schedule.

     As above, we summarize the different computations:

       PRK_2e      = EDHOC_Extract(TH_2, ss_eph);
       KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);
       SALT_3e2m   = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);
       PRK_3e2m    = EDHOC_Extract(SALT_3e2m, ss_R);
       K_3         = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);
       IV_3        = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);
       SALT_4e3m   = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length);
       PRK_4e3m    = EDHOC_Extract(SALT_4e3m, ss_I);
       K_4         = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);
       IV_4        = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length);
       MAC_2       = EDHOC_KDF(PRK_4e3m, 2, context_2, mac_length_2)
                     (with context_2 = C_R, ID_CRED_R, TH_4, EAD_4);
       PRK_out     = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

  3.4.4.  Additional explanations

     We detail here the main elements that differ from the original EDHOC
     protocol.

  3.4.4.1.  Ephemeral KEM

     As previously explain the usual ephemeral Diffie-Hellman elements are
     replaced by an ephemeral KEM.  In this protocol, it works exactly as
     we previously described.

  3.4.4.2.  Authentication keys

     For the Initiator, the authentication key MUST be: (1) a static KEM
     key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k)
     algorithm (where k is a security parameter) *and* (2) a static
     signing key pair (sign.sk_I, sign.pk_I) generated using a
     DS.KeyGen(k) algorithm (where k is a security parameter).






  Papon & Onete           Expires 2 September 2026               [Page 34]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     For the Responder, the authentication key MUST be a static KEM key
     pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k) algorithm
     (where k is a security parameter).

  3.4.4.3.  Key derivation

     In this version of the protocol, the keys PRK_2e, PRK_3e2m and
     PRK_4e3m are obtain thanks to EDHOC_Extract fonction:

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2
        and the IKM SHALL be the ephemeral shared-secret ss_eph;

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be
        SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the
        'static' shared-secret ss_R.

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be
        SALT_4e3m directly derived from PRK_3e2m, and the IKM SHALL be the
        'static' shared-secret ss_I.

     Concerning PRK_out, here again, there is no modifications compared to
     the original EDHOC protocol.

  3.4.5.  Analysis

     This variant combines our PQ-EDHOC I KEM & Signs - R Signs protocol
     with the version where the Initiator and Responder authenticate using
     a KEM, as presented in [I-D.pocero-authkem-edhoc].  The advantage of
     this alternative is that it preserves Responder authentication via a
     KEM and simply asks the Initiator to sign its identity.
     Additionally, there is no longer need to calculate the MAC MAC_3.  In
     this variant, we assumed that the Initiator has a pair of static
     signature keys (sign.sk_I, sign.pk_I) and also a pair of static KEM
     keys (kem.sk_I, kem.pk_I), and that the Responder has only a pair of
     static KEM keys (kem.sk_R, kem.pk_R).  As already explain, this is
     not an unusual case.  From a technical point of view, messages
     message_1,message_2 and message_4 do not differ from those proposed
     in [I-D.pocero-authkem-edhoc].  Again, two major differences are
     worth noting regarding the messages.  Firstly, here we no more have a
     fifth mandatory message message_5.  Secondly, our third message
     message_3 contains an additional signature SIGNATURE_3 in
     PLAINTEXT_3A(befoire ciphering) (as this was the case for protocols
     that we have proposed above, with SIGNATURE_2 or SIGNATURE_3) (we
     will propose a byte analysis of this message later).  Finally, from a
     computational point of view, both the Initiator and the Responder no
     longer need to calculate the MAC MAC_3.  In return, here again, the
     Initiator must sign a message, and the Responder must verify this
     signature, in order to authenticate the Initiator, and send him the



  Papon & Onete           Expires 2 September 2026               [Page 35]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     KEM ciphertext kem.ct_I.  Regarding the Key Derivation Schedule,
     aside from the IKM which adapts to post-quantum cryptographic
     material, we remain close to the one of EDHOC's method 3.  So
     compared to [I-D.pocero-authkem-edhoc], we reduce the number of
     mandatory messages, from 5 to 4, and again we obtain a tradeoff
     between the size of messages, calculation capabilities, and the
     number of messages.

  3.5.  Third case: Initiator and Responder KEM and sign - version 2

     We now present the second variant of the equivalent of EDHOC method
     3.  In this situation both the Initiator and the Responder
     authenticate with a KEM and a signature, which makes this protocol a
     hybrid of two of the protocols we presented previously.

  3.5.1.  Protocol overview

       I                                                                R
      ---                                                              ---
       |            METHOD, SUITES_I, kem.pk_eph, C_I, EAD_1            |
       +---------------------------------------------------------------->
       |                            message_1                           |
       |                                                                |
       |kem.ct_eph, Enc(KEYSTREAM_2, C_R, ID_CRED_R, EAD_2, SIGNATURE_2)|
       <----------------------------------------------------------------+
       |                            message_2                           |
       |                                                                |
       |          kem.ct_R, AEAD(ID_CRED_I, EAD_3, SIGNATURE_3)         |
       +---------------------------------------------------------------->
       |                            message_3                           |
       |                                                                |
       |                      kem.ct_I, AEAD(EAD_4)                     |
       <----------------------------------------------------------------+
       |                            message_4                           |

     Figure 9: PQ-EDHOC, I KEM & Signs - R KEM & Signs message flow.

  3.5.2.  Protocol description

  3.5.2.1.  Formatting and sending message_1

     As for our previous protocol version, the first message (message_1)
     consists of:

     *  METHOD --> as specified in [RFC9528] it is an integer specifying
        the authentication method the Initiator wants to use;





  Papon & Onete           Expires 2 September 2026               [Page 36]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  SUITES_I --> it consists of an ordered set of algorithms supported
        by the Initiator and formatted as specified in [RFC9528];

     *  C_I (and also as C_R, which will appears later) --> the Connection
        Identifiers chosen by the Initiator (C_I) and by the Responder
        (C_R) as specified in [RFC9528];

     *  EAD_1 (and also EAD_2, EAD_3 and EAD_4, which will appear later)
        -> External Authorization Data, respectively included in
        message_1, message_2, message_3 (and optionally) message_4, and
        formatted as specified in [RFC9528];

     *  kem.pk_eph --> the Ephemeral KEM public key generated by the
        Initiator.

  3.5.2.2.  Processing message_1, formatting and sending message_2

     On the reception of the first message, the Responder proceeds as in
     the original EDHOC protocol with elements METHOD, SUITES_I, C_I and
     EAD_1.  In a second step, using kem.pk_eph and the KEM.Encapsulation
     algorithm, he computes the ephemeral ciphertext kem.ct_eph and the
     ephemeral shared-secret ss_eph.

     The Responder selects its Connection Identifier C_R as specified in
     [RFC9528].  He then computes:

     *  TH_2 = H(kem.ct_eph, H(message_1));

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph);

     *  KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length).

     In this version, the Responder authenticates with message_2 thanks to
     a signature.  So he assembles PLAINTEXT_2:

     *  PLAINTEXT_2 = (C_R, ID_CRED_R, TH_2, EAD_2)

     then signs this message :

     *  SIGNATURE_2 = DS.Sign(sign.sk_R, (PLAINTEXT_2, sign_length))

     where sign.sk_R is the long-term signing private key of the
     Responder.  And finally he ciphers PLAINTEXT_2A = (PLAINTEXT_2,
     SIGNATURE_2):

     *  CIPHERTEXT_2 = PLAINTEXT_2A XOR KEYSTREAM_2

     So the second message then consists of:



  Papon & Onete           Expires 2 September 2026               [Page 37]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     *  kem.ct_eph --> the ephemeral ciphertext obtained with kem.pk_eph;

     *  CIPHERTEXT_2.

  3.5.2.3.  Processing message_2, formatting and sending message_3

     On reception of the second message, the Initiator, using kemp.ct_eph,
     can compute the ephemeral shared-secret ss_eph.  As the Responder
     did, he computes TH_2, PRK_2e and KEYSTREAM_2.  He can now decipher
     and retrieve : PLAINTEXT_2A = CIPHERTEXT_2 XOR KEYSTREAM_2.

     Thanks to ID_CRED_R, the Initiator obtains the long-term public keys
     of the Responder, kemp.pk_R and sign.pk_R.  At first, he checks the
     validity of the signature of the Responder:

     *  DS.Verify(sign.pk_R, (PLAINTEXT_2, sign_length), SIGNATURE_2).

     If the verification algorithm returns 1, the Initiator properly
     authenticated the Responder.  Otherwise he aborts.

     Using the KEM encapsulation algorithm KEM.Encapsulation, and the
     long-term input material kem.pk_R of the Responder, the Initiator
     generated the pair (ss_R, kem.ct_R).

     The shared-secret ss_R will then serve as IKM for the computation of
     PRK_3e2m:

     *  SALT_3e2m = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R).

     It is now the turn of the Initiator to authenticate himself.  To do
     so, he computes the following elements:

     *  TH_3 = H(TH_2, PLAINTEXT_2A, ID_CRED_R);

     *  K_3 = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);

     *  IV_3 = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);

     assembles PLAINTEXT_3 = (ID_CRED_I, TH_3, EAD_3), and signs
     PLAINTEXT_3:

     *  SIGNATURE_3 = DS.Sign(sign.sk_I, (PLAINTEXT_3, sign_length))







  Papon & Onete           Expires 2 September 2026               [Page 38]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     where sign.sk_I is the long-term signing private key of the
     Initiator.  Then, with the AEAD encryption algorithm negociated in
     SUITES_I, he ciphers PLAINTEXT_3A = (PLAINTEXT_3,SIGNATURE_3) as
     CIPHERTEXT_3.

     The third message is then composed of:

     *  kem.ct_R;

     *  CIPHERTEXT_3.

  3.5.2.4.  Processing message_3, formatting and sending message_4

     On reception of message_3, the Responder computes TH_3, K_3 and IV_3,
     and deciphers CIPHERTEXT_3 with the AEAD decryption algorithm.  With
     PLAINTEXT_3A, he obtains the Initiator's long-term public keys
     kem.pk_I and sign.pk_I, and so he verifies the signature:

     *  DS.Verify(sign.pk_I, (PLAINTEXT_3, sign_length), SIGNATURE_3).

     If the verification algorithm returns 1, the Initiator is properly
     authenticated to the Initiator.  Otherwise the Responder aborts.  He
     then uses the KEM.Encapsulation algorithm to generate ss_I and
     kem.ct_I.

     Following that, he computes:

     *  TH_4 = H(TH_3, PLAINTEXT_3A, ID_CRED_I);

     *  SALT_4e3m = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length);

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I);

     *  K_4 = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);

     *  IV_4 = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length).

     Using the AEAD encryption algorithm, he ciphers PLAINTEXT_4 = EAD_4
     and sends it to the Initiator, along with kem.ct_I.  He then finishes
     the AKE by computing the final key PRK_out:

     *  PRK_out = EDHOC_KDF(PRK_3e2m, 7, TH_4, hash_length).









  Papon & Onete           Expires 2 September 2026               [Page 39]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  3.5.2.5.  Processing message_4

     In this situation the fourth message is mandatory.  It is used to
     send the KEM ciphertext kem.ct_I to the Initiator (it cannot be
     shared before, since the Responder only learns the identity of the
     Initiator with the third message).

     When receiving this last message, the Initiator computes the shared-
     secret ss_I thanks to the KEM.Decapsulation algorithm, and elements
     kem.sk_I, kem.ct_I.  After that, he can compute TH_4, K_4, IV_4, and
     decipher CIPHERTEXT_4 thanks to the AEAD decryption algorithm.  Once
     he had checked the well formedness of PLAINTEXT_4, he can finally
     compute PRK_out as the Responder did.

  3.5.3.  Associated key derivation schedule

     In this section we present the key derivation schedule of the
     previously described protocol version.

               +--------------------------------+
               |TH_2=H(kem.ct_eph, H(message_1))|
               +------+----------------------+--+             PLAINTEXT_2A
                      |                      |                        |
       +------+   +---+---+   +------+   +---+--+   +-----------+   +-+-+
       |ss_eph|-->|Extract|-->|PRK_2e|-->|Expand|-->|KEYSTREAM_2|-->|XOR|
       +------+   +-------+   +---+--+   +---+--+   +-----------+   +-+-+
                                  |                                   |
                                  |                                   v
                                  |                         +---------+--+
                                  |                         |CIPHERTEXT_2|
                                  |                         +---------+--+
                                  |
                +---------+   +---+--+
                |SALT_3e2m|<--|Expand|
                +---+-----+   +---+--+
                    |               +------------------------------------+
                    |               |TH_3=H(TH_2, PLAINTEXT_2, ID_CRED_R)|
                    |               +-------+----------------------------+
                    |                       |
                    |                       |                 PLAINTEXT_3A
                    |                       |                       |
       +----+   +---+---+   +--------+   +--+---+   +--------+   +--+-+
       |ss_R|-->|Extract|-->|PRK_3e2m|-->|Expand|-->|K_3/IV_3|-->|AEAD|
       +----+   +-------+   +---+----+   +---+--+   +--------+   +--+-+
                                  |                                 |
                                  |                                 v
                                  |                         +-------+----+
                                  |                         |CIPHERTEXT_3|



  Papon & Onete           Expires 2 September 2026               [Page 40]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


                                  |                         +-------+----+
                                  |
                +---------+   +---+--+
                |SALT_4e3m|<--|Expand|
                +---+-----+   +---+--+                         PLAINTEXT_4
                    |                                               |
       +----+   +---+---+   +--------+   +------+   +--------+   +--+-+
       |ss_I|-->|Extract|-->|PRK_4e3m|-->|Expand|-->|K_4/IV_4|-->|AEAD|
       +----+   +-------+   +---+----+   +---+--+   +--------+   +--+-+
                                |            |                      |
                                |            |                      v
                                |            |              +-------+----+
                                |            |              |CIPHERTEXT_4|
                                |            |              +------------+
                                |            |
                                |   +--------+---------------------------+
                                |   |TH_4=H(TH_3, PLAINTEXT_3, ID_CRED_I)|
                                |   +--------+---------------------------+
                                |            |
                                |        +---+--+   +-------+
                                +--------|Expand|-->|PRK_out|
                                         +------+   +-------+

     Figure 8: PQ-EDHOC, I KEM & Signs - R KEM & Sings key derivation
     schedule.

     Here, we summarize the different computations:

       PRK_2e      = EDHOC_Extract(TH_2, ss_eph);
       KEYSTREAM_2 = EDHOC_KDF(PRK_2e, 0, TH_2, plaintext_length);
       SALT_3e2m   = EDHOC_KDF(PRK_2e, 1, TH_2, hash_length);
       PRK_3e2m    = EDHOC_Extract(SALT_3e2m, ss_R);
       K_3         = EDHOC_KDF(PRK_3e2m, 3, TH_3, key_length);
       IV_3        = EDHOC_KDF(PRK_3e2m, 4, TH_3, iv_length);
       SALT_4e3m   = EDHOC_KDF(PRK_3e2m, 5, TH_4, hash_length);
       PRK_4e3m    = EDHOC_Extract(SALT_4e3m, ss_I);
       K_4         = EDHOC_KDF(PRK_4e3m, 8, TH_4, key_length);
       IV_4        = EDHOC_KDF(PRK_4e3m, 9, TH_4, iv_length);
       PRK_out     = EDHOC_KDF(PRK_4e3m, 7, TH_4, hash_length).

  3.5.4.  Additional explanations

     We detail here the main elements that differ from the original EDHOC
     protocol.







  Papon & Onete           Expires 2 September 2026               [Page 41]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  3.5.4.1.  Ephemeral KEM

     As previously explain the usual ephemeral Diffie-Hellman elements are
     replaced by an ephemeral KEM.  In this protocol, it works exactly as
     we previously described.

  3.5.4.2.  Authentication keys

     For the Initiator, the authentication key MUST be: (1) a static KEM
     key pair (kem.sk_I, kem.pk_I) generated using a KEM.KeyGen(k)
     algorithm (where k is a security parameter) *and* (2) a static
     signing key pair (sign.sk_I, sign.pk_I) generated using a
     DS.KeyGen(k) algorithm (where k is a security parameter).

     For the Responder, the authentication key MUST be: (1) a static KEM
     key pair (kem.sk_R, kem.pk_R) generated using a KEM.KeyGen(k)
     algorithm (where k is a security parameter) *and* (2) a static
     signing key pair (sign.sk_R, sign.pk_R) generated using a
     DS.KeyGen(k) algorithm (where k is a security parameter).

  3.5.4.3.  Key derivation

     In this version of the protocol, the keys PRK_2e, PRK_3e2m and
     PRK_4e3m are obtain thanks to EDHOC_Extract fonction:

     *  PRK_2e = EDHOC_Extract(TH_2, ss_eph) --> the salt SHALL be TH_2
        and the IKM SHALL be the ephemeral shared-secret ss_eph;

     *  PRK_3e2m = EDHOC_Extract(SALT_3e2m, ss_R) --> the salt SHALL be
        SALT_3e2m directly derived from PRK_2e, and the IKM SHALL be the
        'static' shared-secret ss_R.

     *  PRK_4e3m = EDHOC_Extract(SALT_4e3m, ss_I) --> the salt SHALL be
        SALT_4e3m directly derived from PRK_3e2m, and the IKM SHALL be the
        'static' shared-secret ss_I.

     Concerning PRK_out, here again, there is no modifications compared to
     the original EDHOC protocol.

  3.5.5.  Analysis

     We conclude all these descriptions, with a last one variant which
     combines our PQ-EDHOC I KEM & Signs - R Signs protocol with our PQ-
     EDHOC I Signs - R KEM & Signs protocol.  In this situation, both the
     Initiator and the Responder will authenticate using a signature, and
     there will be no longer MACs MAC_2 and MAC_3 to compute.  In this
     variant, we assumed that the Initiator has a pair of static signature
     keys (sign.sk_I, sign.pk_I) and also a pair of static KEM keys



  Papon & Onete           Expires 2 September 2026               [Page 42]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     (kem.sk_I, kem.pk_I), and that the Responder has a pair of static
     signature keys (sign.sk_R, sign.pk_R) and also a pair of static KEM
     keys (kem.sk_R, kem.pk_R).  As already explain, this is not an
     unusual case.  From a technical point of view, only message message_1
     remains unchanged as the one proposed in [I-D.pocero-authkem-edhoc].
     Here, four major differences are worth noting regarding the messages.
     Firstly, here we no more have a fifth mandatory message message_5.
     Secondly, our second and third messages message_2 and message_3
     contain each an additional signature SIGNATURE_2 and SIGNATURE_3
     respectively in PLAINTEXT_2A and in PLAINTEXT_3A.  Moreover, the
     plaintext PLAINTEXT_4 no longer includes MAC_2, which implies that
     the ciphertext CIPHERTEXT_4 is lighter, and so is our fourth message
     message_4 (we will propose a byte analysis of these messages later).
     Finally, from a computational point of view, both the Initiator and
     the Responder no longer need to calculate the MACs MAC_2 and MAC_3.
     In return, both the Initiator and the Responder must sign a message
     and verify signature, in order to authenticate themselves.  This
     allows the Initiator to authenticate the Responder directly when he
     receives the second message, and vice versa for the Responder when he
     receives the third message.  That is why we no longer need MAC_2 and
     MAC_3 in the fourth and fifth messages.  Regarding the Key Derivation
     Schedule, aside from the IKM which adapts to post-quantum
     cryptographic material, we remain close to the one of EDHOC's method
     3.  So compared to [I-D.pocero-authkem-edhoc], we reduce the number
     of mandatory messages, from 5 to 4, and again we obtain a tradeoff
     between the size of messages, calculation capabilities, and the
     number of messages.

  4.  Security Considerations

     We propose here a global security analysis of our five proposals (if
     necessary, we number the protocols from 1 to 5 according to their
     order of appearance in the document).  At the end of each handshake,
     both endpoints:

     *  securely compute the session key PRK_out;

     *  securely authenticate their partner.

     For the first protocol, the Responder authenticates through the MAC
     in message_2, while the Initiator authenticates through the signature
     produced in message_3.  This approach is similar to that of EDHOC
     [RFC9528] in method 1.








  Papon & Onete           Expires 2 September 2026               [Page 43]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     For the second protocol, the Responder's authentication is guaranteed
     by its signature in message_2, while the Initiator authenticates
     through its signature in message_3.  Note that in this protocol
     variant, the Responder's signature is securely ciphered in the second
     message.

     The third protocol is essentially a mirrored version of the second
     protocol, and the authentication methods of the Initiator and the
     Responder are switched.

     For the fourth protocol, this authentication is ensured by the
     Responder's MAC, sent in message_4, and the Initiator's signature,
     sent encrypted in message_3.

     Finally, for the fifth protocol, authentication is guaranteed by the
     Initiator's and Responder's signatures, both sent encrypted in the
     third and second message respectively.

     Our hybrid approaches (combining KEM and signature for
     authentication) follow the structure of the Key Derivation Schedule
     in EDHOC [RFC9528].  The use of a 'static' shared-secret in key
     derivation strengthens the security of the key between two non-
     compromised parties (e.g., if the ephemeral KEM key of the session is
     compromised), and to some extent also strengthens forward-security
     and authentication (e.g., if a long-term signature secret key is
     compromised).

  4.1.  Forward Secrecy

     A forward-secrecy attacker could compromise the long-term signature
     key sign.sk and/or the static KEM secret key kem.sk for one of the
     endpoints, after that particular endpoint has completed a protocol
     session.  The attacker's goal is to compromise the session key
     PRK_out.

     First note that compromising long-term signature keys does not
     compromise the security of past sessions.














  Papon & Onete           Expires 2 September 2026               [Page 44]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     If the static KEM secret key of the Initiator kem.sk_I or of the
     Responder kem.sk_R (depending on the use case and protocol) is
     compromised, the attacker can retrieve the shared secrets ss_I or
     ss_R.  However, this knowledge is insufficient to learn PRK_out.
     This is because, as in the case of EDHOC [RFC9528] (and similarly to
     the recent proposals [I-D.pocero-authkem-edhoc] and
     [I-D.pocero-authkem-ikr-edhoc]), PRK_out is derived from all shared
     secrets of the session, including the ephemeral KEM secret ss_eph.
     As a result, to recompute PRK_out, attackers would also need to
     compromise the ephemeral KEM secret ss_eph used in the session.
     Thus, each of the five protocols achieves Forward Secrecy (FS)
     provided that the ephemeral KEM secret ss_eph remains uncompromised.

  4.2.  Identity protection

     Protocol 1 is relatively close to the one proposed in
     [I-D.pocero-authkem-ikr-edhoc].  Concerning the Identity Protection
     property, in the way it is constructed, protocol 1 guarantees this
     property against passive attackers for the Responder and active
     attackers for the Initiator.  Indeed, the same attacks as in EDHOC
     [RFC9528] by an active attacker allow learning the identity of the
     Responder.  Moreover, since all information about identities is
     encrypted from the second message onwards, this ensures Identity
     Protection against passive/active attackers for Responder/Initiator,
     provided that long-term keys are not compromised.  However, we want
     to point out a disputed aspect regarding this property.  We think it
     might be possible to reuse the security game introduced in
     [CottierPointcheval23], reused in [LIEDHOC] and adapted in [EDHOCPSK]
     to prove Identity Protection.  But this security game seems difficult
     to adapt to the protocol proposed in [I-D.pocero-authkem-ikr-edhoc]
     due to the encryption present in the first message.  We suggest a
     more global approach for this property, possibly based on [PPAKE].

     To return to a more classical definition of Identity Protection
     property, protocols 2 to 5 keep a similar structure as EDHOC, and so
     inherit of this property.  In other words, the identities of the
     Initiator and the Responder are never sent in plaintext, always
     encrypted, and only from the second message onwards.  Moreover, the
     various signatures executed by the endpoints are encrypted in the
     messages and therefore do not appear in clear in the exchange, as
     this is the case in the original EDHOC protocol.

     According to the definition in [CottierPointcheval23], protocols 2 to
     5 verify the Identity Protection property against passive attackers
     for the Responder and against active attackers for the Initiator.
     However, we can still keep our previous proposal in mind and try to
     prove this property in a more general framework for these protocols
     as well.



  Papon & Onete           Expires 2 September 2026               [Page 45]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


  4.3.  Downgrade Protection

     Our protocols protect against downgrade attacks in the same way as
     EDHOC since the choice of methods and cipher suites is included in
     the calculation of certain THs and is linked to Connection
     Identifiers of each session (and then to endpoint identities).  As a
     result, we have the same Downgrade Protection as in EDHOC [RFC9528].

  4.4.  Transcript Hash Binding

     In our protocols, transcript hashes are constructed as in [RFC9528].
     They contain elements from previous messages as well as endpoint
     identities.  They are also involved in the computation of derived and
     intermediaries keys (as explained in the Key Derivation Schedules).
     Thus, like EDHOC, they provide protection against misbinding attacks
     (since identities are linked to keys and messages via THs) and inter-
     session replay attacks (since any changes to a message or injected
     message from another session invalidates subsequent THs).
     Consequently, at each step of the handshake, the integrity of the
     process is verified using THs.

  4.5.  External Authorization Data (EAD)

     The External Authorization Data (EAD) in our protocols behaves
     similarly to what is done in EDHOC [RFC9528] and
     [I-D.pocero-authkem-edhoc].  The first two messages message_1 and
     message_2 carry EAD (partially encrypted), which are not yet
     authenticated.  This makes them potentially vulnerable to replay
     attacks by an active attacker.  The last two messages message_3 and
     message_4 protect the EAD using either MAC or signature, as well as
     AEAD encryption.  Thus, like in EDHOC [RFC9528], our 5 protocols' EAD
     data must be treated as untrusted until the handshake is successfully
     completed.

  5.  IANA Considerations

     This document has no IANA actions.

  6.  References

  6.1.  Normative References

     [I-D.pocero-authkem-edhoc]
                Fraile, L. P., Koulamas, C., Fournaris, A. P., and E.
                Haleplidis, "KEM-based Authentication for EDHOC", Work in
                Progress, Internet-Draft, draft-pocero-authkem-edhoc-02, 2
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                pocero-authkem-edhoc-02>.



  Papon & Onete           Expires 2 September 2026               [Page 46]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     [I-D.pocero-authkem-ikr-edhoc]
                Fraile, L. P., Koulamas, C., Fournaris, A. P., and E.
                Haleplidis, "KEM-based Authentication for EDHOC in
                Initiator-Known Responder (IKR) Scenarios", Work in
                Progress, Internet-Draft, draft-pocero-authkem-ikr-edhoc-
                02, 2 March 2026, <https://datatracker.ietf.org/doc/html/
                draft-pocero-authkem-ikr-edhoc-02>.

     [I-D.spm-lake-pqsuites]
                Selander, G. and J. P. Mattsson, "Quantum-Resistant Cipher
                Suites for EDHOC", Work in Progress, Internet-Draft,
                draft-spm-lake-pqsuites-01, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-spm-lake-
                pqsuites-01>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
                Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5116>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
                Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
                <https://www.rfc-editor.org/rfc/rfc8742>.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.






  Papon & Onete           Expires 2 September 2026               [Page 47]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Header Parameters for Carrying and Referencing X.509
                Certificates", RFC 9360, DOI 10.17487/RFC9360, February
                2023, <https://www.rfc-editor.org/rfc/rfc9360>.

     [RFC9528]  Selander, G., Preuß Mattsson, J., and F. Palombini,
                "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
                DOI 10.17487/RFC9528, March 2024,
                <https://www.rfc-editor.org/rfc/rfc9528>.

  6.2.  Informative References

     [CottierPointcheval23]
                Cottier, B. and D. Pointcheval, "Security Analysis of
                Improved EDHOC Protocol", 2022,
                <https://doi.org/10.1007/978-3-031-30122-3_1>.

     [EDHOCPSK] López-Pérez, E., Watteyne, T., Marin-Lopez, R., Onete, C.,
                Papon, C., and M. Vučinić, "Pre-Shared Key Authentication
                With EDHOC - The Security–Performance Tradeoff", 2025,
                <https://ieeexplore.ieee.org/document/11247913>.

     [LIEDHOC]  Lafourcade, P., López-Pérez, E., Olivier-Anclin, C.,
                Onete, C., Papon, C., and M. Vučinić, "Fine-grained,
                privacy-augmenting LI-compliance in the LAKE standard",
                2025, <https://hal.science/hal-05126079v1>.

     [PPAKE]    Ramacher, S., Slamanig, D., and A. Weninger, "Privacy-
                Preserving Authenticated Key Exchange - Stronger Privacy
                and Generic Constructions", 2022,
                <https://eprint.iacr.org/2022/1338>.

     [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

     [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
                Post-Quantum Traditional Hybrid Schemes", RFC 9794,
                DOI 10.17487/RFC9794, June 2025,
                <https://www.rfc-editor.org/rfc/rfc9794>.

  Authors' Addresses

     Clément Papon
     XLIM UMR CNRS 7252 - Limoges University
     Email: clement.papon@unilim.fr





  Papon & Onete           Expires 2 September 2026               [Page 48]


  Internet-Draft           PQ-EDHOC - Sign and KEM              March 2026


     Cristina Onete
     XLIM UMR CNRS 7252 - Limoges University
     Email: maria-cristina.onete@unilim.fr
















































  Papon & Onete           Expires 2 September 2026               [Page 49]


name: draft-wu-sidr-aspa-validation-signaling
rev: 00
title: BGP AS_PATH Validation State Extended Community
time: 2024-09-01T07:05:10Z
group_uri: /api/v1/group/group/1027/
expires: 2024-09-01T09:24:13Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-04T00:00:05.939826+00:00
source: ietf
abstract:
  This document defines a new BGP opaque extended community to carry
     the AS_PATH validation state based on Autonomous System Provider
     Authorization (ASPA) inside an autonomous system.  Internal BGP
     (IBGP) speakers that receive this validation state can configure
     local policies that allow it to influence their decision process.

full_text:
  Network Working Group                                              T. Wu
  Internet-Draft                                                     J. Ge
  Intended status: Standards Track                                 X. Ding
  Expires: 31 August 2024                                          H. Wang
                                                                    Huawei
                                                          28 February 2024


              BGP AS_PATH Validation State Extended Community
                 draft-wu-sidr-aspa-validation-signaling-00

  Abstract

     This document defines a new BGP opaque extended community to carry
     the AS_PATH validation state based on Autonomous System Provider
     Authorization (ASPA) inside an autonomous system.  Internal BGP
     (IBGP) speakers that receive this validation state can configure
     local policies that allow it to influence their decision process.

  Requirements Language

     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.

  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 31 August 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  Wu, et al.               Expires 31 August 2024                 [Page 1]


  Internet-Draft        RPKI ASPA Extended Community         February 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
     2.  Origin Validation State Extended Community  . . . . . . . . .   2
     3.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   4
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     This document defines a new BGP opaque extended community to carry
     the AS_PATH validation state based on Autonomous System Provider
     Authorization (ASPA) inside an autonomous system.  Internal IBGP
     speakers that receive this validation state can configure local
     policies that allow it to influence their decision process.

  2.  Origin Validation State Extended Community

     The origin validation state extended community is an opaque extended
     community [RFC4360] with the following encoding:


         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
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       0x43    |      0x03     |             Reserved          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Reserved                   |validationstate|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                    Figure 1






  Wu, et al.               Expires 31 August 2024                 [Page 2]


  Internet-Draft        RPKI ASPA Extended Community         February 2024


     The value of the high-order octet of the extended Type field is 0x43,
     which indicates it is non-transitive and opaque [RFC7153].  The value
     of the low-order octet of the extended Type field is 0x03 which is an
     unassigned sub-type of non-transitive opaque extended communities.
     The Reserved field MUST be set to 0 and ignored upon the receipt of
     this community.  The last octet of the extended community is an
     unsigned integer that gives the AS_PATH's validation state
     [I-D.ietf-sidrops-aspa-verification].  It can assume the following
     values:


                     +-------+-----------------------------+
                     | Value | Meaning                     |
                     +-------+-----------------------------+
                     |   0   | Lookup result = "Valid"     |
                     |   1   | Lookup result = "Unknown"   |
                     |   2   | Lookup result = "Invalid"   |
                     +-------+-----------------------------+


                                    Figure 2

     If the router is configured to support the extensions defined in this
     document, it SHOULD attach the AS-PATH validation state extended
     community to BGP UPDATE messages sent to IBGP peers by mapping the
     computed validation state in the last octet of the extended
     community.  Similarly, a receiving BGP speaker, in the absence of
     validation state set based on local data, SHOULD derive a validation
     state from the last octet of the extended community, if present.

     An implementation SHOULD NOT send more than one instance of the AS-
     PATH validation state extended community.  However, if more than one
     instance is received, an implementation MUST disregard all instances
     other than the one with the numerically greatest validation state
     value.  If the value received is greater than the largest specified
     value (2), the implementation MUST apply a strategy similar to
     attribute discard [RFC7606] by discarding the erroneous community and
     logging the error for further analysis.

     By default, implementations MUST drop the AS-PATH validation state
     extended community if received from an External BGP (EBGP) peer,
     without processing it further.  Similarly, by default, an
     implementation SHOULD NOT send the community to EBGP peers.  However,
     it SHOULD be possible to configure an implementation to send or
     accept the community when warranted.  An example of a case where the
     community would reasonably be received from, or sent to, an EBGP peer
     is when two adjacent ASes are under control of the same
     administration.



  Wu, et al.               Expires 31 August 2024                 [Page 3]


  Internet-Draft        RPKI ASPA Extended Community         February 2024


  3.  Deployment Considerations

     In deployment scenarios in which not all the speakers in an
     autonomous system are upgraded to support the extensions defined in
     this document, it is necessary to define policies that match on the
     AS-PATH validation extended community and set another BGP attribute
     that influences selection of the best path in the same way that an
     implementation of this extension would.

  4.  IANA Considerations

     The value 0x03 in the "Non-Transitive Opaque Extended Community Sub-
     Types" registry is unassigned by IANA.  This value can be used as
     "BGP AS-PATH Validation State Extended Community".

  5.  Security Considerations

     Security considerations such as those described in [RFC4272] continue
     to apply.  Since this document introduces an extended community that
     will generally be used to affect route selection, the analysis in
     Section 4.5 ("Falsification") of [RFC4593] is relevant.  These issues
     are neither new, nor unique to the origin validation extended
     community.

     This document describes a scheme where router A outsources validation
     to some router B.  If this scheme is used, the participating routers
     should have the appropriate trust relationship -- B should trust A
     either because they are under the same administrative control.  The
     security properties of the propagation path between the two routers
     should also be considered.  See [RFC7454] Section 5.1 for advice
     regarding protection of the propagation path.

  6.  References

  6.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,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  6.2.  Informative References





  Wu, et al.               Expires 31 August 2024                 [Page 4]


  Internet-Draft        RPKI ASPA Extended Community         February 2024


     [I-D.ietf-sidrops-aspa-verification]
                Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
                J., and K. Sriram, "BGP AS_PATH Verification Based on
                Autonomous System Provider Authorization (ASPA) Objects",
                Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
                verification-16, 29 August 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
                aspa-verification-16>.

     [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
                RFC 4272, DOI 10.17487/RFC4272, January 2006,
                <https://www.rfc-editor.org/info/rfc4272>.

     [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
                Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
                February 2006, <https://www.rfc-editor.org/info/rfc4360>.

     [RFC4593]  Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
                Routing Protocols", RFC 4593, DOI 10.17487/RFC4593,
                October 2006, <https://www.rfc-editor.org/info/rfc4593>.

     [RFC7153]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP
                Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
                March 2014, <https://www.rfc-editor.org/info/rfc7153>.

     [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
                and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
                February 2015, <https://www.rfc-editor.org/info/rfc7454>.

     [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
                Patel, "Revised Error Handling for BGP UPDATE Messages",
                RFC 7606, DOI 10.17487/RFC7606, August 2015,
                <https://www.rfc-editor.org/info/rfc7606>.

  Authors' Addresses

     Tianhao Wu
     Huawei
     Email: wutianhao10@huawei.com


     Jun Ge
     Huawei
     Email: jack.gejun@huawei.com


     Xiangfeng Ding
     Huawei



  Wu, et al.               Expires 31 August 2024                 [Page 5]


  Internet-Draft        RPKI ASPA Extended Community         February 2024


     Email: dingxiangfeng@huawei.com


     Haibo Wang
     Huawei
     Email: rainsword.wang@huawei.com













































  Wu, et al.               Expires 31 August 2024                 [Page 6]


name: draft-amsuess-ace-brski-ace
rev: 00
title: Provisioning ACE credentials through BRSKI
time: 2024-01-08T08:14:05Z
group_uri: /api/v1/group/group/1027/
expires: 2024-01-08T12:29:10Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-03-04T00:00:05.942881+00:00
source: ietf
abstract:
  The autonomous onboarding mechanisms defined in ANIMA's voucher
     artifact and the BRSKI protocol provide a means of onboarding a
     device (the pledge) onto a PKI managed domain.  This document extends
     the voucher with expressions for onboarding it into a domain managed
     through ACE.

full_text:
  ace                                                            C. Amsüss
  Internet-Draft                                               7 July 2023
  Intended status: Standards Track                                        
  Expires: 8 January 2024


                 Provisioning ACE credentials through BRSKI
                       draft-amsuess-ace-brski-ace-00

  Abstract

     The autonomous onboarding mechanisms defined in ANIMA's voucher
     artifact and the BRSKI protocol provide a means of onboarding a
     device (the pledge) onto a PKI managed domain.  This document extends
     the voucher with expressions for onboarding it into a domain managed
     through ACE.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Authentication and
     Authorization for Constrained Environments Working Group mailing list
     (ace@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ace/.

     Source for this draft and an issue tracker can be found at
     https://gitlab.com/chrysn/brski-ace.

  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 8 January 2024.






  Amsüss                   Expires 8 January 2024                 [Page 1]


  Internet-Draft                BRSKI for ACE                    July 2023


  Copyright Notice

     Copyright (c) 2023 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
     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.  Applicability preconditions . . . . . . . . . . . . . . .   2
     2.  Voucher extensions  . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.  Open questions  . . . . . . . . . . . . . . . . . . . . . . .   6
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     [ See abstract. ]

     The main application pattern considered for this kind of enrollment
     is [authz]: After basic networking services (possibly link-local when
     used in combination with CoJP as in Appendix A of [authz]) are
     available, the pledge initiates EDHOC to the lake-authz.arpa anycast
     address, sending an encrypted identifier for its MASA (party W) in
     EAD_1.

  1.1.  Applicability preconditions

     While ACE in general does not constrain the type of tokens used, or
     how the authorization space is split up, using the extensions of this
     document introduces additional conditions:

     *  The key used to authenticate the token is a COSE key, and [CWT]
        are used as tokens.



  Amsüss                   Expires 8 January 2024                 [Page 2]


  Internet-Draft                BRSKI for ACE                    July 2023


        The alternative to this constraint is to declare this a blob of
        some key; what it is depends would be preconfigured in the RS.
        While this is the general approach of ACE, the author considers it
        unsuitable for this particular case where a concrete identifier is
        assigned and thus should have concrete semantics.  Users of any
        other key format may use this document as scaffolding for
        declaring an own YANG leaf instead.

        While this does allow symmetric keys in theory (and they are used
        in ACE, for example in the [ace-oscore]) profile), they should not
        be used in BRSKI deployments, as the secret key would be shared
        with the MASA as it signs the voucher. [ See also the Open
        Questions section. ]

     *  The pledge is identified with a single audience value.  (More
        precisely, there is an "aud" claim conveyed in the CWTs that can
        be checked for equality against a configured value).

        This rules out setups in which multiple security systems coinhabit
        the pledge, are enrolled in a single step to a single AS, but act
        independently at runtime.

        Future iterations of this document may relax this, but will always
        need to express a condition based on which the pledge will know
        whether or not it may act on a token.

     Using these extensions introduces no constraints on the type of scope
     values used with tokens.  The structure of scope values needs to be
     agreed between the AS and the RS out of band.  Typically, the AS will
     have configured knowledge of how to generate scope values that match
     the hard-coded model of the RS's firmware from authorizations of its
     native model.

  2.  Voucher extensions

     This specification adds two leaf nodes to the voucher artifact
     defined in Section 6.1 of [_8366bis] [ this is currently done in a
     monkey-sees-monkey-does fashion, rather than having the yang files
     standalone and using pyang to build the tree as is done in 8366bis ]:

     module: ietf-voucher
       augment voucher:
         +-- ace-as-key?                      binary
         +-- ace-aud?                         string

  2.1.  YANG Module





  Amsüss                   Expires 8 January 2024                 [Page 3]


  Internet-Draft                BRSKI for ACE                    July 2023


     <CODE BEGINS> file "ietf-ace-brski-ace@2023-07-07.yang"
     module ietf-ace-brski-ace {
       yang-version 1.1;

       namespace "urn:ietf:params:xml:ns:yang:ietf-ace-brski-ace";

       prefix vch-ace;

       import ietf-voucher {
         prefix vch;
         reference "I-D.ietf-anima-rfc8366bis-07";
       }

       organization
         "IETF ACE (Authentication and Authorization for Constrained Environments)
         Working Group";

       contact
         "WG Web:   <http://tools.ietf.org/wg/ace/>
          WG List:  <mailto:ace@ietf.org>

          Editor:   Christian Amsüss
                    <mailto:christian@amsuess.com>";

       description
         "This module augments the voucher artifact for bootstrapping
         (onboarding) with mechanisms for onboarding onto ACE (Authentication
         and Authorization for Constrained Environments) Authorization
         Servers.

         Copyright (c) 2019 IETF Trust and the persons identified as
         authors of the code. All rights reserved.

         Redistribution and use in source and binary forms, with or
         without modification, is permitted pursuant to, and subject
         to the license terms contained in, the Simplified BSD License
         set forth in Section 4.c of the IETF Trust's Legal Provisions
         Relating to IETF Documents
         (http://trustee.ietf.org/license-info).

         This version of this YANG module is part of RFC XXXX; see the
         RFC itself for full legal notices.";

       revision 2023-07-07 {
         description
           "Initial revision.";

         reference



  Amsüss                   Expires 8 January 2024                 [Page 4]


  Internet-Draft                BRSKI for ACE                    July 2023


           "I-D.amsuess-ace-brski-ace, Provisioning ACE credentials through
           BRSKI";
       }

       uses "vch:voucher-artifact-grouping" {
         augment "voucher" {
           description
             "Mechanisms for onboarding onto ACE (Authentication and Authorization
             for Constrained Environments) Authorization Servers";

           leaf ace-as-key {
             type binary;
             description
               "Key(s) held by the ACE Authorization Server by which it
               authenticates (and the Resource Server verifies) tokens.
               It is a CBOR encoded COSE_KeySet.";
             reference
               "I-D.amsuess-ace-brski-ace, Provisioning ACE credentials
               through BRSKI";
           }

           leaf ace-aud {
             type string;
             description
               "Audience identifier by which the ACE Authorization Server
               will be the pledge that is enrolled as an ACE Resource
               Server.";
             reference
               "I-D.amsuess-ace-brski-ace, Provisioning ACE credentials
               through BRSKI";
           }
         }
       }
     }
     <CODE ENDS>

     A device accepting this voucher will accept tokens signed with the
     credials expressed as a COSE key in the ace-as-pubk field, provided
     they are issued with an audience value of "jada89".

  3.  Security Considerations

     [ TBD; in particular the open question on symmetric keys. ]

  4.  IANA Considerations

     [ TBD: Request this for the YANG Module Names Registry; the module
     itself is registered differently. ]



  Amsüss                   Expires 8 January 2024                 [Page 5]


  Internet-Draft                BRSKI for ACE                    July 2023


  5.  Open questions

     *  There are probably missing steps in this specification; the
        current draft's intention is primarily to start discussion.

     *  Is there a shorter route to the same result I missed (and should
        take instead)?

        Is there a longer route (doing EST style onboarding into a PKI,
        and then obtain AS data by using those certificates) that I missed
        (and could reference and learn from)?

     *  Is there existing YANG terminology for ACE (or just OAuth) to use?

        There was some OAuth in the YANG of draft-kwatsen-netconf-http-
        client-server-03, but that was just FIXMEs, and later removed.

     *  AIU the voucher artifact data assembled by the registrar travels
        to the MASA to be signed during BRSKI.  That's fine when we're
        shipping a pinned-domain-cert, and also when we're shipping as-
        public-key and an audience identifier (for the ACE EDHOC profile),
        but not when shipping a shared key (for the ACE OSCORE profile).

     *  Is this suitable use of BRSKI and the voucher?

     *  This document currently only describes expressing the ACE details
        in YANG for an ACE voucher.

        For use with more EST-like enrollments, it could define resources
        equivalent to the rt=ace.est.sen resources.

        Alternatively, such setups could use COMI to manipulate the AS.
        (But in the EST direction, would this need "pull mode COMI"?)

  6.  References

  6.1.  Normative References

     [CWT]      Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [_8366bis] Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
                and Q. Ma, "A Voucher Artifact for Bootstrapping
                Protocols", Work in Progress, Internet-Draft, draft-ietf-
                anima-rfc8366bis-07, 7 February 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
                rfc8366bis-07>.



  Amsüss                   Expires 8 January 2024                 [Page 6]


  Internet-Draft                BRSKI for ACE                    July 2023


  6.2.  Informative References

     [ace-oscore]
                Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
                "The Object Security for Constrained RESTful Environments
                (OSCORE) Profile of the Authentication and Authorization
                for Constrained Environments (ACE) Framework", Work in
                Progress, Internet-Draft, draft-ietf-ace-oscore-profile-
                19, 6 May 2021, <https://datatracker.ietf.org/doc/html/
                draft-ietf-ace-oscore-profile-19>.

     [authz]    Selander, G., Mattsson, J. P., Vučinić, M., Richardson,
                M., and A. Schellenbaum, "Lightweight Authorization for
                EDHOC", Work in Progress, Internet-Draft, draft-selander-
                lake-authz-02, 21 April 2023,
                <https://datatracker.ietf.org/doc/html/draft-selander-
                lake-authz-02>.

  Acknowledgments

     TODO acknowledge.

  Author's Address

     Christian Amsüss
     Austria
     Email: christian@amsuess.com
























  Amsüss                   Expires 8 January 2024                 [Page 7]


name: draft-kim-nmrg-2nmai5g
rev: 00
title: Native Network Management using Artificial Intelligence over an Adaptive B5G Network
time: 2024-01-10T08:14:05Z
group_uri: /api/v1/group/group/1027/
expires: 2024-01-11T04:07:16Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "AI safety/alignment", "ML traffic mgmt"]
tags: []
fetched_at: 2026-03-04T00:00:05.946143+00:00
source: ietf
abstract:
  This document is derived from artificial intelligence (AI) network
     and autonomous security, network management intend-based technology
     to ensure constant security quality in B5G.  SOAR (Security
     Orchestration Automation and Response) is needed by autonomous
     security and network management to optimize an adaptive B5G network.
     The purpose of this document is to confirm whether the requirements
     are reflected future users and developed to identify users provided
     by useful decisions on how to develop the system.  This document also
     covers the user requirements for autonomous security and intend-based
     network management to ensure constant security quality on B5G.

full_text:
  Network Management Research Group                               H-K. Kim
  Internet-Draft                                                  M-S. Kim
  Intended status: Informational                      SANGMYUNG UNIVERSITY
  Expires: 10 January 2024                                       July 2023


  Native Network Management using Artificial Intelligence over an Adaptive
                                B5G Network
                         draft-kim-nmrg-2nmai5g-00

  Abstract

     This document is derived from artificial intelligence (AI) network
     and autonomous security, network management intend-based technology
     to ensure constant security quality in B5G.  SOAR (Security
     Orchestration Automation and Response) is needed by autonomous
     security and network management to optimize an adaptive B5G network.
     The purpose of this document is to confirm whether the requirements
     are reflected future users and developed to identify users provided
     by useful decisions on how to develop the system.  This document also
     covers the user requirements for autonomous security and intend-based
     network management to ensure constant security quality on B5G.

  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 2 January 2024.

  Copyright Notice

     Copyright (c) 2023 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.



  Kim & Kim                Expires 10 January 2024                [Page 1]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     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
     2.  Convention and Terminology  . . . . . . . . . . . . . . . . .   3
     3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Terminology and Abbreviations Theorem . . . . . . . . . .   3
       3.2.  Autonomous Network  . . . . . . . . . . . . . . . . . . .   4
     4.  Design of AI-based 6G Autonomous Security Control Model and
             Framework Structure . . . . . . . . . . . . . . . . . . .   5
       4.1.  Model and framework structure for SBA structure
             linkage . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Model and framework structure for SBMA structural
             linkage . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.3.  Model and framework structure for AI-Enabled network
             structural linkage  . . . . . . . . . . . . . . . . . . .   6
       4.4.  NWDAF (Network Data Analytics Function) . . . . . . . . .   6
       4.5.  Management for other Standardization  . . . . . . . . . .   7
     5.  B5G Native Network Management based on SOAR . . . . . . . . .   8
       5.1.  Purpose of B5G Native Network Management Framework  . . .   8
       5.2.  Scope of B5G Native Network Management  . . . . . . . . .   9
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     In order to respond to large-scale attacks on B5G communication
     infrastructure based on hyper-performance, hyperspace, the advanced
     security threats targeting new convergence services and intended
     super-trust-based security technology.  It can ensure constant
     security throughout B5G infrastructure and relate to the foundational
     aim to acquire skills.  For native network management to optimize an
     adaptive B5G network based on SOAR, there are a lot of research
     fields to secure intent-based super-trust security skills and the
     related technology such as vulnerability analysis and security threat
     modeling to provide super-reliable infrastructure for B5G network,
     AI-based autonomous security and control framework to provide safe
     new convergence services in B5G, B5G-based station security to ensure
     availability of 3D mobile communication and quantum security
     technologies (PQC, QKD) of conversion methodology for B5G encryption
     system application.



  Kim & Kim                Expires 10 January 2024                [Page 2]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


  2.  Convention and Terminology

     The keywords "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.  Background

  3.1.  Terminology and Abbreviations Theorem

     SDAF: Security Data Analytics Function

     SBA: Service-Base Architecture

     SBI: Service-Based Interface

     NWDAF: Network Data Analytics Function

     AF: Application Function

     AMF: Access and Mobility Management Function

     AOI: Area of Interest

     ML: Machine Learning

     MTLF: Model Training Logical Function

     PCF: Policy Control Function

     UPF: User Plane Function

     SMF: Session Management Function

     NF: Network Function

     UE: User Equipment

     gNB: gNodeB

     SBMA: Service-Based Management Architecture

     SIEM: Security Information and Event Management

     SOAR: Security Orchestration, Automation, and Response

     AnLF: Analytics Logical Function




  Kim & Kim                Expires 10 January 2024                [Page 3]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     MTLF: Model Training Logical Function

  3.2.  Autonomous Network

     The autonomous network concept is defined differently depending on
     the standardization organization, and these contents are as follows.

     3GPP: SON (Self-Organizing Networks)

     ETS/ITU-T/GSMA: Autonomous Network

     ETSI: ZSM (Zero touch network and Service Management)

     Hauwei: AND (Autonomous Driving Network)

     Juniper: SDN (Self-Driving Network)

     Cisco: DNA (Digital(Data) Network Architecture)

     Ericson: ZTN (Zero Touch Network)

     Autonomous network levels can also be divided into six different
     levels.

     Level 0 - Manual Network: The system is supported by a monitoring
     function to manually execute dynamic tasks (SNMP, CLI)

     Level 1 - Assisted Network: The system executes specific and
     repetitive subtasks that are preconfigured to increase execution
     efficiency (Tack-Centric)

     Level 2 - Partial Autonomous Network: The system enables closed-loop
     O and M for specific devices based on AI models in specific external
     environments (Node-Centric)

     Level 3 - Conditional Autonomous network: L2-based system has
     functions to detect real-time environment change, specific network
     domain, and intention device.  Semi-closed loop management is
     possible to optimize and adjust to the external environment (Service-
     Centric)

     Level 4 - Highly autonomous Network: L3-based system has capabilities
     of service- and customer-experience-centric in a more complex cross-
     domain environment.  It can analyze and make decisions based on
     predictive or active closed-loop management of the network(User-
     Centric)





  Kim & Kim                Expires 10 January 2024                [Page 4]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     Level 5 - Fully autonomous network: The system is a fully autonomous
     network with multi-services, multi-domains, and full lifecycle
     (Value-Centric)

  4.  Design of AI-based 6G Autonomous Security Control Model and
      Framework Structure

     There are three candidates selected by conceptual design, analyzing
     5G System Architecture for AI-based 6G autonomous security control
     model and framework defined by the 3GPP Standardization Organization.

     (1) Model and framework structure for SBA structure linkage

     (2) Model and framework structure for SBMA structural linkage

     (3) Model and framework structure for AI-Enabled network structural
     linkage

  4.1.  Model and framework structure for SBA structure linkage

     In this study, we aim to design at the NF level to internalize an AI-
     based autonomous security control model in the SBA structure of 5G
     System Architecture.  There are 11 major NFs of SBA such as AMF, SMF,
     UPF, NSSF, NEF, NRF, PCF, UDM, UDR, and NWDAF.  Among the NFs
     constituting SBA, NWDAF is used and analyzed NF that utilizes
     intelligent technologies such as AI for network operation.  The NWDAF
     is selected as a reference model to design AI-based security analysis
     functions using network data.

  4.2.  Model and framework structure for SBMA structural linkage

     The SBMA structure defined by 3GPP into account is the Management
     Plane in the SBA structure.  The prior study was designed by setting
     the SBA structure considering the control plane and the user plane.
     We will analyze MDAS or MDAF in the SBMA structure and conduct
     research and conceptual design in consideration of security
     management in the future.

     TBD












  Kim & Kim                Expires 10 January 2024                [Page 5]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


  4.3.  Model and framework structure for AI-Enabled network structural
        linkage

     This structure aims to the conceptual design of element technology
     for an AI-based autonomous security control model over the 6G
     networks.  AI-Enabled Network is designed using SBA's AI-based NWDAF.
     Since NWDAF is an NF that analyzes network data for network
     operations, it seems necessary for Security NF of security analysis.
     SDAF is designed and analyzed using the NWDAF Wrapper method for AI-
     based security of NF.  NWDAF is an analysis of NF using AI and it can
     consist of logical functions (AnLF and/or MTLF).  It is also the
     conceptual design of elemental technology for security intelligence
     with the two functions of security internalization (NWDAF and SDAF).
     It can need an AI Model Training for security intelligence.  The
     following shows the structure according to two candidate designs and
     the proposed model.

     TBD

  4.4.  NWDAF (Network Data Analytics Function)

     NWDAF is one of the network functions located on the control plane in
     the SBA structure of 5GC.  It is based on 5G Core, MEC (Cloud), and
     user equipment (UE) in edge networks.  It is also used with data
     collection and data analysis depending on the application function
     (AF) and Operations and Administration Maintenance(OAM).  The purpose
     of NWDAF is to simplify the complexity of interfacing with 5GC and
     3rd analytic solution providers. 5GC-related data in NWDAF is
     collected with 5G network data and the data can be analyzed by
     machine learning and statistical analysis.  The analyzed result data
     is provided to other 5G core network functions to optimize each
     network function and to improve performance as its main function.



















  Kim & Kim                Expires 10 January 2024                [Page 6]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


       +----+
       +NF-1+----------------+--------------------+             +----+
       +----+                + NWDAF              +-------------+NF-1+
  +-------------+   +-----+  +                    +             +----+
  + Untrusted AF+---+NEF-1+--+                    +
  +-------------+   +-----+  +  +--------------+  +             +-----+
  +----------+               +  +analytic Model+  +-------------+NEF-1+
  +Trusted AF+---------------+  +(Static,      +  +             +-----+
  +----------+               +  + algorithm)-3 +  +
       +-----+               +  +--------------+  +-------------------+
       +UDR-1+---------------+                    +
       +-----+               +                    +             +-----+
       +-----+               +                    +-------------+OAM-2+
       +OAM-2+---------------+                    +             +-----+
       +-----+               +--------------------+
  ----------------------------------------------------------------------------
      .................................................
      .  1: Core NF             2: Network Management .
      .  3: Proprietary Function                      .
      .................................................



                  Figure 1: NWDAF Architecture Overview


                NWDAF
                +--------------------+       +--------------------+
                + AnLF               +       + MTLF               +
                + (Analytics         +       + (Model Training    +
                + Logical Function   +       + Logical Function)  +
                +--------------------+       +--------------------+

        Figure 2: Logical Function (AnLF and/or MTLF) Structure of NWDAF


  4.5.  Management for other Standardization

     NFV (Network Functions Virtualization) Management and NFVO (NFV
     Orchestration): Identify network function (NF) lifecycle management
     procedures in virtualized environments

     OSM (Open Source MANO): E2E Network Service Orchestrator (NFV + Slice
     + Cross Domain)

     MEC (Multi access Edge Computing) Management, F5G (Fifth Generation
     Fixed Network)




  Kim & Kim                Expires 10 January 2024                [Page 7]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     ENI (Experiential Networked Intelligence):

     (a)Cognitive Netwok Management architecture using AI and Context
     aware Polices

     (b)Method to add intelligence to legacy systems

     (c)Method between API Broker layer and Legacy System (OSS/BSS, NF,
     User, etc. and ENI system)

     ZSM (Zero Touch Network and Service Management):

     (a)Fully Autonomous Management and Operations Framework level

     (b)Management Services of Domain, Unified Fabric and Cross Domain

     (c)Closed Loop Control Acquisition, Analysis, Determination and
     Execution Method Actions

     (D)Domain level Management, Cross Domain Level Management, Business
     Service Level Management

     This document present to aim B5G-based autonomous security and intend
     framework based on the constant security quality guarantee to provide
     the super-trusted infrastructure of the new convergent network
     security service without cyber threats

  5.  B5G Native Network Management based on SOAR

  5.1.  Purpose of B5G Native Network Management Framework

     It is necessary to verify native security element skill to analyze
     the detailed functions such as B5G wireless access, D2D and
     infrastructure virtualization.  It is also needed to analyze B5G
     global network security-based intelligence and internalization
     technology, security vulnerability in flying base station and quantum
     security for security application system.  We also propose of design
     of B5G native network management and requirement for B5G wireless
     access/D2D/infrastructure virtualization attack model, AI-based B5G
     autonomous security control of security native intelligence,
     networking security and intrusion detection in flying base station
     and quantum security for application of B5G security system.  In
     addition, security native modeling and verification are also
     necessary in B5G native network management framework.







  Kim & Kim                Expires 10 January 2024                [Page 8]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


  5.2.  Scope of B5G Native Network Management

     Above all, the first scope is to analyze of B5G wireless access/D2D/
     infrastructure virtualization elements and to define security
     requirements such as B5G wireless access, Ultra-high-density of B5G
     D2D and infrastructure virtualization.  In next scope, there are B5G
     wireless access/D2D/infrastructure virtualization attack model
     development and threat analysis, design of AI-based B5G autonomous
     security control and security intelligence internalization concept.
     It is also necessary to design networking security, intrusion
     detection element technology in flying base station and design of
     quantum security technology for B5G security application.
     Verification of the contents in advance is also additionally required
     with the following scope.

  6.  IANA Considerations

     There are no IANA considerations related to this document.

  7.  Security Considerations

     [TBD]

  8.  Informative References

     [TM-Forum] "Aaron Richard Earl Boasman-Patel, Autonomous Networks:
                Empowering Digital Transformation for The Telecoms
                Industry", 2019.

     [ITU-T_Y.3172]
                "Architectural framework for machine learning in future
                networks including IMT-2020", 2020.

     [ITU-T_Y.3173]
                "Framework for evaluating intelligence level of future
                networks including IMT-2020", 2020.

     [ITU-T_Y.3174]
                "Framework for data handling to enable machine learning in
                future networks including IMT-2020", 2020.

     [ITU-T_Y.3176]
                "Machine learning marketplace integration in future
                networks including IMT-2020", 2020.

     [FG-ML5G_spec1]
                "Requirements, architecture and design for machine
                learning function orchestrator", 2020.



  Kim & Kim                Expires 10 January 2024                [Page 9]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     [FG-ML5G_spec2]
                "Machine Learning Sandbox for future networks including
                IMT-2020 requirements and architecture framework", 2020.

     [FG-ML5G_spec3]
                "Machine learning based end to end network slice
                management and orchestration", November 2020.

     [FG-ML5G_spec4]
                "Vertical assisted Network Slicing Based on a Cognitive
                Framework", 2020.

     [Y.ML_IMT2020-RAFR]
                "Architecture framework for AI based network automation of
                resource adaptation and failure recovery for future
                networks including IMT 2020", 2020.

     [TS23.288] "Architecture enhancements for 5G System to support
                network data analytics services", 2021.

     [TR23.791] "Study of Enablers for Network Automation for 5G", 2021.

     [TR28.809] "Study on enhancement of Management Data Analytics (MDA)",
                2021.

     [TR28.810] "Study on concept, requirements and solutions for levels
                of autonomous network", 2021.

     [TR28.100] "Management and orchestration; Levels of autonomous
                network", 2021.

     [TR28.812] "Telecommunication management; Study on scenarios for
                Intent driven management services for mobile networks",
                2021.

     [TR28.312] "Intent driven management services for mobile networks",
                2021.

     [TR28.805] "Telecommunication management; Study on management aspects
                of communication services", 2021.

     [TR28.535] "Management and orchestration; Management services for
                communication service assurance; Requirements", 2021.

     [TR28.536] "Management and orchestration; Management services for
                communication service assurance; Stage 2 and Stage 3",
                2021.




  Kim & Kim                Expires 10 January 2024               [Page 10]


  Internet-Draft          draft-kim-nmrg-2nmai5g-00              July 2023


     [TR28.861] "Study on the Self Organizing Networks (SON) for 5G
                networks", 2021.

     [TR28.313] "Self-Organizing Networks (SON) for 5G networks", 2021.

  Authors' Addresses

     Hwan-kuk Kim
     SANGMYUNG UNIVERSITY
     31, Sangmyeongdae-gil, Dongnam-gu
     Cheonan
     Phone: +82 41 550 5101
     Email: rinyfeel@smu.ac.kr


     Min-Suk Kim
     SANGMYUNG UNIVERSITY
     31, Sangmyeongdae-gil, Dongnam-gu
     Cheonan
     Phone: +82 41 550 5113
     Email: minsuk.kim@smu.ac.kr






























  Kim & Kim                Expires 10 January 2024               [Page 11]


name: draft-yang-alto-multi-domain
rev: 03
title: ALTO Multi-Domain Use Cases and Services
time: 2024-01-11T08:14:05Z
group_uri: /api/v1/group/group/1027/
expires: 2024-01-11T19:19:48Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-03-04T00:00:05.949255+00:00
source: ietf
abstract:
  Application-Layer Traffic Optimization (ALTO) provides means for
     network applications to obtain network information.  Although ALTO is
     inherently multi-domain, in that the ALTO server representing the
     network and the ALTO client requesting the network information belong
     to different trust domains, there are more general cases where the
     path from the source and the destination spans multiple autonomous
     networks, which we call multi-domain settings.  This document first
     gives three multi-domain use cases, and the challenges to address the
     challenges.  It then gives a brief update on the implementation
     solutions that we explored to address the challenges.

full_text:
  ALTO Working Group                                             D. Lachos
  Internet-Draft                                                  I. Poese
  Intended status: Standards Track                                  Benocs
  Expires: 11 January 2024                                      M. Lassnig
                                                                      CERN
                                                                     A. Gu
                                                                   Y. Yang
                                                           Yale University
                                                             J. Ros Giralt
                                                                  Qualcomm
                                                              10 July 2023


                  ALTO Multi-Domain Use Cases and Services
                      draft-yang-alto-multi-domain-03

  Abstract

     Application-Layer Traffic Optimization (ALTO) provides means for
     network applications to obtain network information.  Although ALTO is
     inherently multi-domain, in that the ALTO server representing the
     network and the ALTO client requesting the network information belong
     to different trust domains, there are more general cases where the
     path from the source and the destination spans multiple autonomous
     networks, which we call multi-domain settings.  This document first
     gives three multi-domain use cases, and the challenges to address the
     challenges.  It then gives a brief update on the implementation
     solutions that we explored to address the challenges.

  Requirements Language

     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.

  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/.





  Lachos, et al.           Expires 11 January 2024                [Page 1]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     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 11 January 2024.

  Copyright Notice

     Copyright (c) 2023 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
     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Multi-domain Use Cases  . . . . . . . . . . . . . . . . . . .   3
       2.1.  Multi-domain Path Distance/Ranking for Rucio  . . . . . .   3
       2.2.  Multi-domain Path -> Link Mapping for FTS . . . . . . . .   5
       2.3.  Multi-domain Resource Discovery for NOTED/SENSE . . . . .   6
     3.  Multi-domain Challenges . . . . . . . . . . . . . . . . . . .   6
       3.1.  Challenge: Distributed Information  . . . . . . . . . . .   6
       3.2.  Challenge: Partial Deployment . . . . . . . . . . . . . .   7
     4.  Solution Space Exploration  . . . . . . . . . . . . . . . . .   7
       4.1.  Solution Space to Obtain Forwarding Information Bases
             (FIBs)  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  FIB-Compute Based Design  . . . . . . . . . . . . . . . .   8
       4.3.  FIB-Apply Based Design  . . . . . . . . . . . . . . . . .   8
       4.4.  Multi-Domain Cascading ALTO . . . . . . . . . . . . . . .   8
       4.5.  General-Path Model Supporting Partial Deployment  . . . .   9
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11







  Lachos, et al.           Expires 11 January 2024                [Page 2]


  Internet-Draft              ALTO Multi-Domain                  July 2023


  1.  Introduction

     Application-Layer Traffic Optimization (ALTO) provides means for
     network applications to obtain network information.  For example, the
     Endpoint Cost Service (ECS) and the Cost Map Service (CMS) defined by
     ALTO in [RFC7285] can provide the network-path properties (e.g.,
     routing costs, or relative ranking) of data transmissions from a set
     of source network locations to a set of destination network
     locations.  The Path Vector Service [RFC9275] allows ALTO to provide
     bandwidth availability (bottlenecks) for a given set of flows defined
     by a set of source-destination pairs.

     Although such services can provide values when the network path from
     a given source to a given destination spans only a single network,
     called a single-domain setting, provides these services, there are
     many use cases where the path may span multiple networks, called
     multi-domains settings.  [RFC7971] states that "The ALTO protocol is
     designed for use cases where the ALTO server and client can be
     located in different organizations or trust domains.  ALTO is
     inherently designed for use in multi-domain environments.  Most
     importantly, ALTO is designed to enable deployments in which the ALTO
     server and the ALTO client are not located within the same
     administrative domain.”

     This document first specifies three multi-domain use cases.  It then
     discusses the two challenges when deploying ALTO in multi-domain
     settings.  At the end, this document provides initial designs based
     on current implementation experiences to start the design
     conversation.

  2.  Multi-domain Use Cases

     To be concrete, this document uses three use cases from the context
     of data-intensive sciences for CERN/WLCG.

  2.1.  Multi-domain Path Distance/Ranking for Rucio

     The data orchestration system of CERN/WLCG is Rucio, which selects a
     source for a given downloading client when multiple sources provide
     the dataset.  Rucio also conducts destination selection, when
     multiple destinations can be the target locations for replication.










  Lachos, et al.           Expires 11 January 2024                [Page 3]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     The main mechanism of source/destination selection in Rucio is
     distance, which is a perfect match for ALTO cost services; see
     appendix for a review of the full source/destination mecahnisms of
     Rucio.  Specifically, consider the following ECS query realizing ALTO
     ECS for Rucio to do destination selection.  The source is located at
     CERN and the destination candidates are at multiple locations of the
     LHCONE network (AGLT, BNL, and KIT, for example).


       POST /endpointcost/lookup HTTP/1.1
       Host: alto.example.com
       Content-Length: 248
       Content-Type: application/alto-endpointcostparams+json
       Accept:
          application/alto-endpointcost+json,application/alto-error+json

       {
         "cost-type": {"cost-mode" : "numerical",
                       "cost-metric" : "routingcost"},
         "endpoints" : {
           "srcs": [ "ipv4:188.184.9.234" ],
           "dsts": [
             "ipv4:192.41.231.81",
             "ipv4:104.18.24.74",
             "ipv4:141.3.128.6"
           ]
         }
       }


       HTTP/1.1 200 OK
       Content-Length: 274
       Content-Type: application/alto-endpointcost+json

       {
         "meta" : {
           "cost-type": {"cost-mode" : "numerical",
                         "cost-metric" : "routingcost"
           }
         },
         "endpoint-cost-map" : {
           "ipv4:188.184.9.234": {
             "ipv4:192.41.231.81" : 20,
             "ipv4:104.18.24.74" : 30,
             "ipv4:141.3.128.6"  : 10
           }
         }
       }



  Lachos, et al.           Expires 11 January 2024                [Page 4]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     The use case provides an example of a multi-domain setting, because
     the source and the destinations are located at different networks and
     the network paths span multiple autonomous networks.  For example,
     the path from CERN (188.184.9.234) to AGLT2 (192.41.231.81) spans
     CERN, ESNet and U.  Michigan to reach the destination.

     Figure 1 below illustrates a network path from src to dst spanning
     four networks.


           AS S              AS A        AS B         AS D
     +-------------+se1  +---------+   +-----+   +------------+
     | src       --|-----|ai1   ae1|---|     |---|di1     dst |
     |+--+    --/  |     |         |   |     |   |       +--+ |
     ||  | --/     |     |         |   |     |   |       |  | |
     |+--+    \    |se2  |         |   |     |   |       +--+ |
     |         \__ |_____|ai2   ae2|---|     |---|di2         |
     +-------------+     +---------+   +-----+   +------------+

                   Figure 1. Multi-domain Network.


  2.2.  Multi-domain Path -> Link Mapping for FTS

     The data transport scheduling system of CERN/WLCG is FTS, which
     schedules given transfers, where a transfer is compromised of a fixed
     dataset, a source and a destination (for example, chosen by Rucio).

     One main function of FTS is to satisfy operator resource constraints.
     As an example, FTS may schedule concurrent transfers from CERN to
     CalTech and KIT, under the constraint that the total transmission
     rate for a given link should be within a certain threshold.

     Consider Figure 1.  Assume S is CERN and D is CalTech.  The network
     path from CERN to CalTech uses the top inter-AS link (se1->ai1), and
     the network path from CERN to KIT uses the lower inter-AS link
     (se2->ai2).  For FTS to know how much demand it is placing on each
     one of these two links so that it can stay within the constraint of
     each link, FTS needs to know the network paths, and the paths span
     multiple autonomous networks.











  Lachos, et al.           Expires 11 January 2024                [Page 5]


  Internet-Draft              ALTO Multi-Domain                  July 2023


  2.3.  Multi-domain Resource Discovery for NOTED/SENSE

     An emerging capacity for LHCONE/WLCG is the ability to create new
     paths to obtain additional capacity when there is high demand from a
     given source storage element (SE) to a destination element (SE).  In
     particular, the NOTED project monitors the backlog at Rucio/FTS for
     each source SE, destination SE pair, and may decide to create a path
     if one pair has a large backlog.

     To identify available networking capacity, ALTO Path Vector Service
     (PVS) is an ideal service.  However, as we see from Figure 1, the
     setting can be a multi-domain setting.

  3.  Multi-domain Challenges

     Although implementing ECS/CMS/PVS is relatively straightforward in a
     single domain, there are challenges implementing these services in
     multi-domain settings.

  3.1.  Challenge: Distributed Information

     Consider Figure 1, to compute the total routing cost of the path from
     the src to the dst.  The routing costs will consist of multiple
     segments spanning four autonomous networks: (1) from src to the link
     connecting the egress of AS S (se1) and the ingress of AS A (ia1);
     (2) from the ingress of A to the ingress of B; (3) from the ingress
     of B to the ingress of D; ( 4) from the ingress of D to dst.

     One may think that BGP collects information from multiple autonomous
     networks through back propagation from the destination, and hence
     includes information for all four segments.  But BGP information is
     distributed, coarse-grained, and incomplete.

     Source: The BGP router at AS S knows that the path from src to dst
     consists of the AS-PATH [S A B D].  Combining BGP and intradomain
     routing, AS S will also know which one of the two egress routers
     (se1, se2) that it will use to forward traffic to dst.  However, AS S
     does not know more details downstream: for example, it does not know
     whether the packet will use ae1 or ae2 as the egress router at AS A
     to enter AS B; neither does it know the internal routing inside AS A.
     Hence, an ALTO server provided by AS S cannot provide all of the
     information for the example ECS query.









  Lachos, et al.           Expires 11 January 2024                [Page 6]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     Non-Source AS: A non-source AS knows the AS-PATH starting from itself
     to dst.  But it may not know the ingress point.  For example, AS A
     does not know whether the packet will come in from ai1 or ai2.
     Hence, an ALTO server provided by AS A may consider the example ECS
     query as an ambiguous query (because it gives only source (src) and
     destination (dst), but it does not in general know the ingress
     point).

  3.2.  Challenge: Partial Deployment

     It is possible to design protocol extensions to collect the
     aforementioned distributed information to provide complete
     information (see below), but one challenge is that the deployment may
     be only incremental and hence is partially deployed during the
     process.

  4.  Solution Space Exploration

     During the process of integrating ALTO to support the Rucio and FTS
     use cases, multiple potential solutions are implemented.  Below we
     discuss them briefly to motivate discussions.

  4.1.  Solution Space to Obtain Forwarding Information Bases (FIBs)

     Obtaining FIBs is a basic building block of implementing ALTO route-
     related visibility services.  At a high-level, FIBs have the
     following life cycle:

     FIB-Configure/input:
        Consider a network as a distributed system.  Then the input to the
        distributed system is the input to the components: the routers.
        The input to each router is its configuration, and external input
        such as BGP routes from peers outside the network.

     FIB-Compute:
        The distributed system computes the FIBs using a distributed
        protocol (or configured by a logically centralized control plane).
        During the computing process, the vendor specific configuration
        may be turned into standard format such as IGP information model.

     FIB-Apply:
        The FIBs are computed and then applied.  When FIBs are applied to
        data packets, the application may be observed by NetFlow/sFlow or
        similar capturing capabilities; it may also be applied to control
        mechanisms such as traceoute, which can be observed.






  Lachos, et al.           Expires 11 January 2024                [Page 7]


  Internet-Draft              ALTO Multi-Domain                  July 2023


  4.2.  FIB-Compute Based Design

     This is a type of solution that makes it possible to extends FIB-
     Compute to compute all needed network information at a single
     autonomous network, addressing the distributed information challenge.
     Assume that use an ALTO server at the source network to abstract and
     expose the information.  One natural candidate is to modify the
     routing control plane itself: BGP extensions, which can be extended
     to collect needed information and propagate upstream.  For example,
     when a BGP router at AS A (e.g., ai1) propagates BGP info to its peer
     at AS S (se1), it includes not only the AS-PATH [A, B, D], but also
     additional information so that the upstream can construct the
     complete path cost (distance) metrics.

     The upside of this design is that it integrates with routing systems
     and hence may even extend routing capabilities.  However, routing
     protocol extensions can be complex in deployment.  Further, it
     provides a different trust model: the original ALTO model is a star
     trust model, with the application (e.g., Rucio/FTS) at the hub and
     each AS needs to trust the application.  The BGP extension model
     requires the trust of peers and recursive peers (BGP community may be
     used to impose policies).

  4.3.  FIB-Apply Based Design

     This is a type of solution that allows data path to collect control
     plane information.  For example, a traceroute based system called
     PerfSonar is widely deployed in our setting.  It is also natural to
     use NetFlow/sFlow to identify ingress points.  Such a system can
     collect other network information such as delay and loss naturally as
     measurements.

     However, this solution type can have many issues.  For example,
     traceoute has issues including: anonymous routers, uncertain router
     IP resulting in node aliasing; load balancing routing resulting in
     link aliasing.

  4.4.  Multi-Domain Cascading ALTO

     This is a model that is presented by Ingmar Poese as Cascading ALTO
     at IETF 116.  For Cascading ALTO by Poese, please see his IETF 116
     slides.

     In the ALTO base model, a network is a container, which we call a big
     switch, with endpoints attached to the big switch.  In the multi-
     domain model, each network (represented by an ALTO server) has a set
     of ingress points (in-1 to in-m) and a set of egress points (e-1 to
     e-n).  An endpoint belonging to the network will be attached to an



  Lachos, et al.           Expires 11 January 2024                [Page 8]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     ingress point and an egress point.  Hence, a single-domain ALTO query
     will specify ingress and egress directly attached to an ingress point
     and an egress point.  A source network, to a destination that is not
     in the same network, however, will only return the egress point; a
     destination network, when the source is from a different network,
     will need an ingress point.  A general transit network will need an
     ingress point and return egress point.  For consistency, the egress
     point must be a valid ingress point, represented by a unique address,
     of the peer.


                 in-1   +-------------+  e-1
                    ----|             |----
                        |             |
                    ----|             |----
                        |             |
                    ----|             |----
                        |             |
                    ----|             |----
                 in-m   +-------------+  e-n

     ALTO Server Multi-domain Query Model: Each ECS query, if the src is
     not in the home domain of the ALTO server, should include an ingress
     point, where the ingress point is returned by the ALTO server of the
     previous domain.  If the domain of the ALTO server is not the home
     domain of the destination, the ALTO server should return the egress
     point of the home domain and the ingress of the network domain.

     As an optional feature, the query should allow indication of
     iterative or recursive queries.

     To support incremental deployment, an ALTO server may respond to a
     query without specifying an ingress point and the source is not in
     the domain of the ALTO server.  In this case, the ALTO server will
     return the results from each potential ingress point.  For each
     ingress point indicated, the server indicates information of the
     previous hop (e.g., peer AS number and potential address).

  4.5.  General-Path Model Supporting Partial Deployment

     Complementing the cascading model, we introduced a generic-path model
     at ALTO clients so that they can use the acquired information to
     gradually refine network information.

     In particular, it allows the path from a src to a dst to be a
     directed acyclic graph, with the following components:





  Lachos, et al.           Expires 11 January 2024                [Page 9]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     A set of nodes, where each node has both a type and attributes, where
     the type can be (1) host: such as src/dst, with attributes such as IP
     address; (2) AS: which is a group of nodes, i.e., subgraph, with
     attributes including ASN; (3) router, with subtypes such as BGP-
     router, with attributes such as IP address.

     A set of links, where each link has a head and a tail; hence the
     types of links will be the unique combinations of head-type x tail
     type.  A link can have its attributes as well.

     Now, some examples of this representation in our deployment use case:

     For the geo-distance ALTO cost derived from geo-ip: the src is a host
     and the dst is also a host, and the metric is the geo distance.

     For CERN looking glass ALTO server, from a src host in CERN to a dst
     host in another network, say KIT, the src is a host, with two links,
     one for each of the two looking glass BGP routers from cern; each of
     these BGP routers links to its BGP peer, and each such BGP peer links
     to the next AS, in the AS-PATH exposed by CERN.

  5.  IANA Considerations

     Some of the solutions will need IANA registrations.

  6.  Acknowledgments

     The authors of this document would also like to thank many for the
     reviews and comments.

  7.  References

  7.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,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
                Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
                "Application-Layer Traffic Optimization (ALTO) Protocol",
                RFC 7285, DOI 10.17487/RFC7285, September 2014,
                <https://www.rfc-editor.org/info/rfc7285>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.



  Lachos, et al.           Expires 11 January 2024               [Page 10]


  Internet-Draft              ALTO Multi-Domain                  July 2023


  7.2.  Informative References

     [RFC7971]  Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
                S. Previdi, "Application-Layer Traffic Optimization (ALTO)
                Deployment Considerations", RFC 7971,
                DOI 10.17487/RFC7971, October 2016,
                <https://www.rfc-editor.org/info/rfc7971>.

     [RFC9275]  Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
                "An Extension for Application-Layer Traffic Optimization
                (ALTO): Path Vector", RFC 7971, DOI 10.17487/RFC7971,
                September 2022, <https://www.rfc-editor.org/info/rfc9275>.

  Authors' Addresses

     Danny Lachos
     Benocs
     Berlin
     Germany
     Email: dlachos@benocs.com


     Ingmar Poese
     Benocs
     Berlin
     Germany
     Email: ingmar@benocs.com


     Mario Lassnig
     CERN
     CH-1211 Geneva 23
     Switzerland
     Email: mario.lassnig@cern.ch


     Annie Gu
     Yale University
     51 Prospect St
     New Haven, CT 06520
     United States of America
     Email: annie.gu@yale.edu









  Lachos, et al.           Expires 11 January 2024               [Page 11]


  Internet-Draft              ALTO Multi-Domain                  July 2023


     Y. Richard Yang
     Yale University
     51 Prospect St
     New Haven, CT 06520
     United States of America
     Email: yry@cs.yale.edu


     Jordi Ros Giralt
     Qualcomm
     Madrid
     Spain
     Email: jros@qti.qualcomm.com






































  Lachos, et al.           Expires 11 January 2024               [Page 12]


name: draft-chen-nmrg-ibn-management
rev: 01
title: Network Management Intent -One of IBN Use Cases
time: 2024-09-04T07:05:13Z
group_uri: /api/v1/group/group/1027/
expires: 2024-09-05T06:38:23Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-03-04T00:00:05.957078+00:00
source: ietf
abstract:
  Full life cycle network management will be a key feature of the
     future communication networks.  Meanwhile, the complexity of the
     network management should be reduced and the network expects to be
     managed in a fully automated manner with humans out of the loop.  In
     this document, we propose an use case of intent based network
     management to achieve more flexible , convenient, and efficient
     network management.  In this use case, we propose an architecture and
     attempt to illustrate the five levels of achieving full autonomous
     network management.

full_text:
  Internet Research Task Force                                     D. Chen
  Internet-Draft                                                    K. Yao
  Intended status: Informational                              China Mobile
  Expires: 5 September 2024                                        C. Yang
                                                                     X. Mi
                                                                 Y. Ouyang
                                                         Xidian University
                                                              4 March 2024


              Network Management Intent -One of IBN Use Cases
                     draft-chen-nmrg-ibn-management-01

  Abstract

     Full life cycle network management will be a key feature of the
     future communication networks.  Meanwhile, the complexity of the
     network management should be reduced and the network expects to be
     managed in a fully automated manner with humans out of the loop.  In
     this document, we propose an use case of intent based network
     management to achieve more flexible , convenient, and efficient
     network management.  In this use case, we propose an architecture and
     attempt to illustrate the five levels of achieving full autonomous
     network management.

  Requirements Language

     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 RFC 2119 [RFC2119].

  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 5 September 2024.




  Chen, et al.            Expires 5 September 2024                [Page 1]


  Internet-Draft            Network Working Group               March 2024


  Copyright Notice

     Copyright (c) 2024 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
     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.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  levels of Intent-based Network Management . . . . . . . . . .   7
     5.  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Concrete Example: Intent based Dynamic Service Function
             Chain . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     With the rapid evolution of networks, such as the emergence of the
     sixth generation (6G), we have entered a new digital era that is
     ubiquitously connected by highly heterogeneous and dynamic network
     infrastructure.  And various network applications are predicted to
     appear more in future communication networks.  With these complex
     network scenarios, services, and uncountable degrees of freedom in
     future communication networks, the complexity of network management
     will increase drastically.  Traditional network management methods
     are insufficient to keep up with the growing requirements.  Firstly,
     there exists high complexity and difficulty to manage a large amount
     of infrastructures due to high labor cost, high error probability,
     low management efficiency.  Secondly, traditional network management
     lacks closed-loop control, which can not find and repair faults in
     time.  To overcome these challenges, some novel network models have
     been proposed, such as NFV and SDN.  However, it still faces many
     novel challenges:





  Chen, et al.            Expires 5 September 2024                [Page 2]


  Internet-Draft            Network Working Group               March 2024


        Tight coupling of network and service applications: Traditional
        network management methods cannot solve the diverse cross-domain
        service requirements in future communication networks

        High configuration complexity and scaling cost: Future
        communication networks will have a huge network scale, different
        kinds of network resources, and constantly changing topology.
        This will result in a high network configuration complexity and
        cannot be configured in a timely and efficient manner.  A smart
        and simple network management architecture is required for rapid
        deployment of network service requirements

        Fragile performance provision and policy robustness: In future
        communication networks, it need to continuously improve the
        network system model based on the experienced knowledge of
        administrators.  And real-time verification and feedback
        mechanisms are required for network runtime.

        Lack of full life cycle verification of policy resilience: Manual
        management has several shortcomings, such as high error
        probability, long fault location time, and expensive labor costs.
        Fortunately, full life cycle verification can reduce the failure
        recovery time, monitor network operation, and maintain the whole
        process while enhancing the accuracy of policy configuration and
        the robustness of policy implementation.

     At the same time, with the exponential growth of network devices,
     network administrators need to put in tremendous effort to manage the
     policies that affect the services of these devices.  While in recent
     years the network management methods have been gradually automated,
     there are still many procedures that must be accomplished under the
     strict supervision of administrators, resulting in high error
     probability.  Moreover, current network management is at a level too
     low to entirely eliminate the requirements to customize each solution
     for a specific device or protocol in use.  The emergence of the IBN,
     as defined in RFC 9315 [RFC9315], has the potential to compensate for
     the limitations of the current network management methods.  The
     intent is a high-level abstraction of policy, and the IBN is a way to
     manage the network through intent-driven rather than a low-level
     configuration.  When the user specifies a high-level goal (intent),
     the network automatically converts that goal into policies and
     automatically deploys these policies throughout the network.

  2.  Definitions and Acronyms

     IBN: Intent based network

     IBNM: Intent based network management



  Chen, et al.            Expires 5 September 2024                [Page 3]


  Internet-Draft            Network Working Group               March 2024


     DQN: Deep Q network

  3.  Overview

     Driven by the above requirements and challenges, the intent based
     network management (IBNM) is proposed.  IBNM aims to transition from
     a fully static manual network management to a fully dynamic
     autonomous intent based network management.  In IBNM, users express
     their service requirements or goals in a declarative manner without
     paying attention to how the network achieves them.

     The architecture is shown as Fig 1, which includes the application
     layer, the intent-enabled layer and the infrastructure layer.  The
     application layer collects intents from various users and
     applications, and provides a number of programmable network
     management services.  The intent-enabled layer consists of the intent
     translation module, intelligent policy mapping module, and intent
     guarantee module, whose functions are to build a bridge between the
     application layer and the infrastructure layer.  Heterogeneous
     physical devices are deployed in the infrastructure layer.  This
     layer can execute management instructions from the intent-enabled
     layer and upload underlying network situation information to the
     intent-enabled layer.  Information interaction between different
     layers is done through different interfaces, such as the northbound
     and southbound interfaces.


























  Chen, et al.            Expires 5 September 2024                [Page 4]


  Internet-Draft            Network Working Group               March 2024


       +----------------------------------------+
       |          Application   Layer           |
       +-------------+---------^----------------+
     Intent Ingestion|         | Northbound Interface
       +-------------+---------v----------------+
       |             |      Intent-enabled Layer|
       | +-----------+-------+  +-------------+ |
       | |           |       |  |             | |
       | |  +--------v----+  |  |             | |
       | |  | Translation |  |  |             | |
       | |  +-------------+  |  |             | |
       | |                   |  | Intelligent | |
       | |  +-------------+  |  |             | |
       | |  | Verification|  |  |  Guarantee  | |
       | |  +-------------+  |  |             | |
       | |Intent Translation |  |    Module   | |
       | |      Module       |  |             | |
       | +-------------------+  |             | |
       |                        |             | |
       | +-------------------+  |             | |
       | |Intelligent Policy |  |             | |
       | |  Mapping Module   |  |             | |
       | +-------------------+  +-------------+ |
       |                                        |
       +--------------------^-------------------+
                            |  Southbound Interface
       +--------------------v-------------------+
       |         Infrastructure Layer           |
       +----------------------------------------+

                       Figure 1: The Architecture of IBNM

     Among these layers, the intent-enabled layer is the core of this
     network management architecture.  First, the intent translation
     module translates declarative intent (expressed in the form of
     natural language) into the network intent that can be recognized by
     the system (specific ).  There may be an intent conflict problem when
     multiple intents are input simultaneously.  Thus, the intent
     translation module executes intent verification and intent conflict
     resolution before the intent is issued (measurable).  Second, the
     intelligent policy mapping module provides customized policies
     (achievable) for specific intents according to various requirements
     and evaluates the current policy by rewarding values.  After that, in
     order to complete the policy configuration within the time-bound, the
     intent guarantee module is needed to execute feature extraction and
     location on the collected alarm information.  Then the fault
     information is fed back to the intelligent policy mapping module.




  Chen, et al.            Expires 5 September 2024                [Page 5]


  Internet-Draft            Network Working Group               March 2024


     Based on the above design, on one hand, this architecture can achieve
     full lifecycle automated network management with humans out of the
     loop.  On the other hand, it converts service requirements (intent)
     into network policies and provides self-adapted customized service
     with a full lifecycle verification.  The functions of each module in
     intent-enabled layer are described below.

        Intent Translation Module

        Intent is expressed in the form of natural language, which is
        ambiguous and does not follow specific forms.  Thus, the intent
        translation module translates the intent expressed in a natural
        language through bidirectional long short-term memory (Bi-LSTM)
        and morphological rules, and outputs the network’s understandable
        and regularized intent.  Meanwhile, the intent translation module
        analyzes the accuracy and completeness of the translated intent
        through intent verification and conflict resolution, and
        continuously monitors whether there are conflicts.  The intent
        translation module is the first step to realizing intent.  In
        short, the translation module provides a bridge between the users
        and the network and is responsible for ensuring the integrity and
        realizability of the input intent.  In addition, the result of the
        intent translation module is a critical foundation for the
        intelligent policy mapping module.

        Intelligent Policy Mapping Module

        The intelligent policy mapping module is the process of intent
        realization, in can consist of policy repository, fuzzy decision
        tree, and deep Q network (DQN).  A large number of atomic policies
        can be stored in the policy repository, which can be established
        by the historical policy and administrator operation and
        maintenance experience.  In particular, atomic policy refers to
        the smallest policy unit that can be executed but cannot be split
        again, such as some functional node configuration policies
        (routing selection, service provider node selection, etc.).  The
        function of the fuzzy decision tree is to generate new atomic
        policies for the policy repository or to adjust the existing
        atomic policies.  DQN is a combination of neural network and
        reinforcement learning, which are used to reorganize the atomic
        policies into a new policy that satisfies the current intent
        requirements.  The function of the neural network is to calculate
        the configuration scores for state-action pairs and outputs all
        actions.  Then the action with the highest configuration score is
        selected as the configuration action according to the Q-learning
        principle.

        Intent Guarantee Module



  Chen, et al.            Expires 5 September 2024                [Page 6]


  Internet-Draft            Network Working Group               March 2024


        The function of the intent guarantee module is to monitor the
        network in real time, collect and analyze the data of the faults
        that have occurred, and predict the faults that have not occurred
        in order to ensure the normal operation of the network.  First, a
        fault information table, including fault type, location, quantity,
        and occurrence time, is established based on the collected network
        abnormal information.  Second, a deep neural evolutionary network
        is used to repair faults and feed back the repair results to the
        intent translation module in real time.  A deep neural evolution
        network can not only repair faults, but also ensure the
        implementation of intents when network faults occur.

  4.  levels of Intent-based Network Management

     The complexity of the future communication network dictates that
     achieving IBNM is a long-term goal, which needs to be completed step
     by step.  Based on the autonomous network levels[Autonomous-Networks]
     , we gives the definition of the levels of IBNM as five levels:
     manual network management (Level 0), intent assistance network
     management (Level 1), partial autonomous IBNM (Level 2), high
     autonomous IBNM (Level 3), and full autonomous IBNM (Level 4).  IBNM
     transforms the traditional fully static network into a fully dynamic
     network, and details are as follows:

        Manual network management: This is a fully static phase, and the
        full life cycle of network management is done by the network
        administrator.  The network is unable to provide differentiated
        services for users.

        Intent assistance network management: Intent is first introduced
        in this phase.  Manual network management is still there; however,
        the IBN has been involved to handle partial tasks.  Meanwhile,
        this level always requires administrators to configure parameters
        and correct for errors in implementation results.

        Partial autonomous IBNM: This level achieves a leap from static to
        dynamic.  Most scenarios can achieve automatic configuration and
        timing verification for partial scenarios, which lessens the role
        of the administrator.  In addition, the network can provide
        partial differentiated services for users at this micro-dynamic
        level.

        High autonomous IBNM: This level is semi-dynamic.  The IBN can
        recognize multi- form (graph, text, and voice) intent input and
        realize autonomous intent translation.  In addition, the IBN
        adopts real-time data collection and analysis methods, which
        improve the performance of network management in terms of
        intelligence, real time, and accuracy.



  Chen, et al.            Expires 5 September 2024                [Page 7]


  Internet-Draft            Network Working Group               March 2024


        Full autonomous IBNM: Full dynamicity is the objective of the IBN.
        The unique characteristics of a network management are intelligent
        intent insight, intelligent translation, intelligent configuration
        and error correction as well as real-time verification.  All the
        tasks are done by the network.  The IBN can provide users with
        differentiated services in full scenarios.

  5.  Advantages

     The advantages of the intent based network management include:

        A specific intent based network management architecture is
        proposed for sensing diversified service intents with various
        scenarios, objectives, and preferences.

        The proposed framework can achieve zero touch management within a
        time bound, which can handle the complex services in a fully
        automatic manner.

        The performance benefits are in terms of adaptivity and
        scalability, which rewards various network environments and avoids
        network reconstructions.

  6.  Concrete Example: Intent based Dynamic Service Function Chain

     In order to evaluate the performance of the proposed IBNM
     architecture, we use the intent-based dynamic service function chain
     (SFC) as an example to solve the network management challenges (e.g.,
     cross-domain orchestration and service functions are tightly coupled
     with the underlying equipment).  At the same time, we developed an
     Openstack-based IBNM platform.  The system demonstration implements
     the whole process from intent input to intent translation to intent
     policy generation to intent deployment, and the details are as
     follows.

     The user input cross-domain link-building requests (intent) in
     natural language at the web-page: Transfer a common-level video
     service from user A in Beijing to user B in Nanjing while
     constraining the execution time of the intent.  The intent
     translation module outputs a conflict-free translation result, which
     indicates that the external input and the translation platform have
     been communicated.  The translation results are intent tuples, which
     are displayed on the front-end interface in the form of name-value
     pairs.  After the intent translation module, the translation results
     will be converted to JavaScript Object Notation (JSON) and
     transmitted to the intelligent policy mapping module.  The
     intelligent policy mapping module divides the JSON request into an
     SFC: service function 1 (network address translation) service



  Chen, et al.            Expires 5 September 2024                [Page 8]


  Internet-Draft            Network Working Group               March 2024


     function 2 (firewall), and constructs the SFC request (name,
     tenant_id, description, service requirements, etc.).  Then query
     whether there is an atomic policy combination that satisfies the
     current intent requirements in the policy repository.  Following
     that, SFC is constructed based on the SFC interface, which is
     extended by Neutron.  OpenStack schedules network resources,
     constructs sub-nets and ports, and generates two-dimensional space
     topology.  Meanwhile, during the SFC construction process, the intent
     guarantee module monitors and manages network resource utilization as
     well as network failures in real time.  Overall, IBNM achieves the
     decoupling of service application and network, and cross-domain
     network orchestration, while reducing the complexity of network
     management.

  7.  Security Considerations

     TBD

  8.  IANA Considerations

     This document has no requests to IANA.

  9.  Normative References

     [Autonomous-Networks]
                Richard, A. Richard., "Autonomous Networks: Empowering
                Digital Transformation for Telecoms Industry. TM Forum,
                Parsippany, New Jersey, White Paper, 2019.", April 2019.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/info/rfc9315>.

  Authors' Addresses

     Danyang Chen
     China Mobile
     Beijing
     100053
     China
     Email: chendanyang@chinamobile.com




  Chen, et al.            Expires 5 September 2024                [Page 9]


  Internet-Draft            Network Working Group               March 2024


     Kehan Yao
     China Mobile
     Beijing
     100053
     China
     Email: yaokehan@chinamobile.com


     Chungang Yang
     Xidian University
     Xi'an
     710071
     China
     Email: cgyang@xidian.edu.cn


     Xinru Mi
     Xidian University
     Xi'an
     710071
     China
     Email: xinrum@163.com


     Ying Ouyang
     Xidian University
     Xi'an
     710071
     China
     Email: yingouyang224@163.com





















  Chen, et al.            Expires 5 September 2024               [Page 10]


name: draft-ietf-idr-bgp-dpa
rev: 05
title: Destination Preference Attribute for BGP
time: 2024-08-23T13:35:17Z
group_uri: /api/v1/group/group/1041/
expires: 1996-09-14T07:00:05Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/40/"]
categories: ["A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:05.959916+00:00
source: ietf
abstract:
  The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets.                                    This document describes a new BGP path attribute termed 'Destination Preference Attribute' (DPA) which can be used by a single autonomous system (AS) to specify globally transitive metrics in its routing announcement via BGP.  The metric can then be used by upstream BGP speakers to favor certain path for return traffic.  The application of this attribute includes facilitating the implementation of symmetric routing and load sharing in the multi-provider Internet.

full_text:
  INTERNET-DRAFT                                                 Enke Chen
  <draft-ietf-idr-bgp-dpa-05.txt>                               Tony Bates
  Expires September 1996                                               MCI
                                                                March 1996


                   Destination Preference Attribute for BGP
                        <draft-ietf-idr-bgp-dpa-05.txt>




  Status of this Memo

     This document is an Internet Draft. Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups. Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months. Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time. It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a "working
     draft" or "work in progress".

     Please check the I-D abstract listing contained in each Internet
     Draft directory to learn the current status of this or any other
     Internet Draft.


  Abstract

     The Border Gateway Protocol [1] is an inter-autonomous system routing
     protocol designed for TCP/IP internets.

     This document describes a new BGP path attribute termed "Destination
     Preference Attribute" (DPA) which can be used by a single autonomous
     system (AS) to specify globally transitive metrics in its routing
     announcement via BGP.  The metric can then be used by upstream BGP
     speakers to favor certain path for return traffic.  The application
     of this attribute includes facilitating the implementation of
     symmetric routing and load sharing in the multi-provider Internet.


  Introduction

     In certain cases there is a need for an autonomous system (AS) to
     specify a globally transitive preference in its routing announcement



  Chen & Bates                                                    [Page 1]


  INTERNET-DRAFT            DPA Attribute for BGP               March 1996


     via BGP so that the upstream BGP speakers can use the preference to
     favor certain path for return traffic.  For instance, as discussed in
     [3], currently it is difficult to implement symmetric routing and
     load sharing in the multi-provider Internet due to the lack of this
     preference in BGP.

     In this paper, we propose a new BGP attribute termed "Destination
     Preference Attribute" (DPA) to address such a need.  More
     specifically, the DPA is a globally transitive metric that can be
     used by an AS to specify preference in its routing announcement so
     that the return traffic favors certain path.  As illustrated in [4]
     through several examples, this metric, combined with AS-based
     "LOCAL_PREF" offers much greater flexibility and manageability in
     implementing symmetric inter-domain routing and load sharing in the
     multi-provider Internet.


  Destination Preference Attribute (DPA)

     This document proposes the DPA path attribute, which is an optional
     transitive attribute of fixed length.  The attribute is represented
     by a pair <AS#, DPA value>.  The AS# is a two octet non-negative
     integer, which denotes the AS that specifies the preference.  The DPA
     value is a four octet non-negative integer.

     The DPA attribute has Type Code 11.


  Route Selection Process


     A router may use DPA to influence the degree of preference [1]
     assigned to a route.

     DPA influence on the computation of degree of preference is a local
     matter. In general, a route with a higher DPA indicates a higher
     preference by the originator of the DPA attribute.














  Chen & Bates                                                    [Page 2]


  INTERNET-DRAFT            DPA Attribute for BGP               March 1996


  Operation

     The AS that sets this attribute must include its AS number in the
     attribute.  A BGP speaker may use the "LOCAL_PREF" attribute to
     select a different path other than the one specified by the DPA
     attribute value.  This does not preclude an AS from re-setting this
     attribute.  However, coordination with the upstream and/or downstream
     neighbors is strongly recommended.


  Aggregation

     If aggregation is done, the resultant aggregate shall be treated as a
     new NLRI.  No DPA attribute shall be derived from more specific NLRIs
     which formed the aggregate. The resultant aggregate is free to have
     the DPA attribute set if so desired.


  Remarks

     It is noted that this new BGP attribute is simple and requires little
     change to the current practice and operation of BGP4.  Nevertheless,
     the new attribute would offer the flexibility of shifting more
     influence on route selection to where the route originates, which has
     become increasingly meaningful as the Internet becomes more complex
     and dynamic.  At the same time, the autonomy of an AS is preserved as
     the "LOCAL_PREF" feature remains unchanged.  A typical application of
     this attribute is illustrated in [4] where the DPA attribute is used
     to simplify the implementation of symmetric inter-domain routing and
     load-sharing.


  Applicability

     The DPA path attribute may be used with BGP version 4 and all
     subsequent versions of BGP unless specifically noted otherwise.


  Security Considerations

     Security considerations are not discussed in this memo.


  Acknowledgments

     The authors would like to thank Yakov Rekhter of cisco for his
     insightful comments and suggestions. We also acknowledge Ramesh
     Govindan (ISI), Paul Traina (cisco), and Ravi Chandra (cisco) for



  Chen & Bates                                                    [Page 3]


  INTERNET-DRAFT            DPA Attribute for BGP               March 1996


     their helpful comments.


  References

     [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

     [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway
     Protocol in the Internet", RFC1772, March 1995.

     [3] Chen, E., and Bates, T., "Current Practice of Implementing
     Symmetric Routing and Load Sharing in the Multi-Provider Internet",
     INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-02.txt>, January
     1996.

     [4] Chen, E., and Bates, T., "Application of the BGP Destination
     Preference Attribute in Implementing Symmetric Routing", INTERNET-
     DRAFT, <draft-ietf-idr-dpa-application-02.txt>, January 1996.

     [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf-
     idr-bgp-metrics-00.txt>, March 1995.

     [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
     April 1995.


  Author's Addresses

     Enke Chen
     MCI
     2100 Reston Parkway
     Reston, VA 22091

     phone: +1 703 715 7087
     email: enke@mci.net

     Tony Bates
     MCI
     2100 Reston Parkway
     Reston, VA 22091

     phone: +1 703 715 7521
     email: Tony.Bates@mci.net







  Chen & Bates                                                    [Page 4]



name: draft-ietf-idr-bgp-metrics
rev: 00
title: BGP AS Path Metrics
time: 2024-08-23T13:38:09Z
group_uri: /api/v1/group/group/1041/
expires: 1995-09-23T07:00:00Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/40/"]
categories: ["A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:05.963057+00:00
source: ietf
abstract:
  In this memo, the extended (per-hop) BGP metrics are proposed to allow network operators to implement routing policies which are common cases in the practice but require complicated ad-hoc configurations given the virtual absence of globally significant metrics in BGP-4.          BGP is an inter-autonomous system routing protocol designed for TCP/IP internets.  The current version is BGP-4 documented in RFC 1654, versions 1-3 are documented in RFCs 1105, 1163 and 1267 accordingly.        This document is a supplement to RFC 1654, and describes the new features in terms of differences from BGP-4.


name: draft-ietf-bgp-idrp-usage
rev: 00
title: Application of the Border Gateway Protocol and IDRP for IP in the Internet
time: 2024-08-23T13:40:02Z
group_uri: /api/v1/group/group/1041/
expires: 1994-04-21T07:00:00Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/40/"]
categories: ["A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-03-04T00:00:05.966002+00:00
source: ietf
abstract:
  This document, together with its companion documents, 'A Border Gateway Protocol 4 (BGP-4)' and 'IDRP for IP', define an inter-autonomous system routing protocol for the Internet.  'A Border Gateway Protocol 4 (BGP-4)' defines the BGP protocol specification.  'IDRP for IP' defines the use of IDRP for IP in the Internet. The IDRP specification defines the IDRP protocol. This document describes the usage of the BGP and IDRP for IP in the Internet.                            Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).  Information about the progress of IDRP for IP can be monitored and/or reported on the IDRP for IP mailing list (idrp-for-ip@merit.edu).

full_text:
  Network Working Group                                         Y. Rekhter
  Request for Comments: DRAFT       T.J. Watson Research Center, IBM Corp.
  draft-ietf-bgp-idrp-idrp-usage-00.txt                        S. Hares
                                                               Merit, Inc.
                                                                   Editors
                                                            September 1993



  Application of the Border Gateway Protocol and IDRP for IP in the Internet


  Status of this Memo


     This document, together with its companion documents, "A Border
     Gateway Gateway Protocol 4 (BGP-4)" and "IDRP for IP", defines an
     inter-autonomous system routing protocol for the Internet. This RFC
     specifies an IAB standards track protocol for the Internet community,
     and requests discussion and suggestions for improvements.  Please
     refer to the current edition of the "IAB Official Protocol Standards"
     for the standardization state and status of this protocol.
     Distribution of this document is unlimited.

     This document is an Internet Draft. Internet Drafts are working
     documents of the Internet Engineering Task Force (IETF), its Areas,
     and its Working Groups. Note that other groups may also distribute
     working documents as Internet Drafts.

     Internet Drafts are draft documents valid for a maximum of six
     months. Internet Drafts may be updated, replaced, or obsoleted by
     other documents at any time. It is not appropriate to use Internet
     Drafts as reference material or to cite them other than as a "working
     draft" or "work in progress".


  Abstract


     This document, together with its companion documents, "A Border
     Gateway Protocol 4 (BGP-4)" and "IDRP for IP", define an inter-
     autonomous system routing protocol for the Internet.  "A Border
     Gateway Protocol 4 (BGP-4)" defines the BGP protocol specification.
     "IDRP for IP" defines the use of IDRP for IP in the Internet. The
     IDRP specification [6] defines the IDRP protocol. This document
     describes the usage of the BGP and IDRP for IP in the Internet.

     Information about the progress of BGP can be monitored and/or
     reported on the BGP mailing list (bgp@ans.net).  Information about
     the progress of IDRP for IP can be monitored and/or reported on the
     IDRP for IP mailing list (idrp-for-ip@merit.edu).



  Expiration Date March 1994                              [Page 1]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

  Acknowledgements


     This document was originally published as RFC 1164 in June 1990,
     jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
     (Merit), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
     (Merit).

     The following people also made key contributions to RFC 1164 -- Guy
     Almes (ANS, then at Rice University), Kirk Lougheed (cisco Systems),
     Hans- Werner Braun (SDSC, then at Merit), and Sue Hares (Merit).

     We would like to explicitly thank Bob Braden (ISI) for the review of
     the previous version of this document.

     This updated version of the document was the product of the IETF BGP
     Working Group with Phill Gross (ANS) and Yakov Rekhter (IBM) as
     editors. Finally, the current version of the document covers the
     usage of both BGP and IDRP for IP. The document is the product of
     both the IETF BGP and IDRP for IP Working Groups with Susan Hares
     (Merit, Inc.) and Yakov Rekhter (IBM) as editors.

     John Moy (Proteon) contributed Section 7 "Required set of supported
     routing policies".

     Scott Brim (Cornell University) contributed the basis for Section 8
     "Interaction with other exterior routing protocols".

     Most of the text in Section 9 was contributed by Gerry Meyer
     (Spider).

     John Scudder (Merit) contributed bits of text throughout and did
     proofreading and editing of several drafts of the document.

     Parts of the Introduction were taken almost verbatim from [3].

     We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
     Systems) for their review and comments on the previous version of the
     document.

  1. Introduction

     This memo describes the use of the Border Gateway Protocol (BGP) and
     "IDRP for IP" in the Internet environment.  IDRP and BGP are inter-
     Autonomous System routing protocols.  IDRP and BGP have common roots
     in version 2 of BGP.  However, IDRP has been standardized within ISO
     as a multi-protocol inter-domain routing protocol.  IDRP for IP and
     BGP-4 can be considered, for the most part, interchangeable.  IDRP
     has a few additional features, and some minor differences in
     encoding.  The usage of these additional features will be discussed
     in Section 10.

     Hereafter in this memo, "BGP" will refer to both BGP-4 and IDRP for
     IP.  BGP-4 will refer only to version 4 of BGP, and IDRP will refer


  Expiration Date March 1994                              [Page 2]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 


     to only the IDRP for IP protocol.

     The network reachability information exchanged via BGP provides
     sufficient information to detect routing loops and enforce routing
     decisions based on performance preference and policy constraints as
     outlined in RFC 1104 [2]. In particular, BGP exchanges routing
     information containing full AS paths and enforces routing policies
     based on configuration information.

     As the Internet has evolved and grown, it has become evident that it
     is soon to face several serious scaling problems. These include:

     Exhaustion of the class B network address space. One fundamental
     cause of this problem is the lack of a network class of a size which
     is appropriate for mid-sized organizations; class C, with a maximum
     of 254 host addresses, is too small while class B, which allows up to
     65534 addresses, is too large to be densely populated.  Growth of
     routing tables in Internet routers is beyond the ability of current
     software (and people) to effectively manage.  Eventual exhaustion of
     the 32-bit IP address space.

     It has become clear that the first two of these problems are likely
     to become critical within the next one to three years.  Classless
     inter-domain routing (CIDR) attempts to deal with these problems by
     proposing a mechanism to slow the growth of the routing table and the
     need for allocating new IP network numbers. It does not attempt to
     solve the third problem, which is of a more long-term nature, but
     instead endeavors to ease enough of the short to mid-term
     difficulties to allow the Internet to continue to function
     efficiently while progress is made on a longer-term solution.

     BGP-4 is an extension of BGP-3 that provides support for routing
     information aggregation and reduction based on the Classless inter-
     domain routing architecture (CIDR) [4].  BGP-4 contains many of the
     features initially put into the multi-protocol ISO IDRP protocol.
     This memo describes the usage of both BGP-4 and IDRP for IP in the
     Internet.

     All of the discussions in this paper are based on the assumption that
     the Internet is a collection of arbitrarily connected Autonomous
     Systems. That is, the Internet will be modeled as a general graph
     whose nodes are AS's and whose edges are connections between pairs of
     AS's.

     The classic definition of an Autonomous System is a set of routers
     under a single technical administration, using an interior gateway
     protocol and common metrics to route packets within the AS and using
     an exterior gateway protocol to route packets to other AS's. Since
     this classic definition was developed, it has become common for a
     single AS to use several interior gateway protocols and sometimes
     several sets of metrics within an AS. The use of the term Autonomous
     System here stresses the fact that, even when multiple IGPs and
     metrics are used, the administration of an AS appears to other AS's
     to have a single coherent interior routing plan and presents a

  Expiration Date March 1994                              [Page 3]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     consistent picture of which networks are reachable through it.

     AS's are assumed to be administered by a single administrative
     entity, at least for the purposes of representation of routing
     information to systems outside of the AS.


  2. BGP Topological Model


     When we say that a connection exists between two AS's, we mean two
     things:

        Physical connection:  There is a shared network between the two
        AS's, and on this shared network each AS has at least one border
        gateway belonging to that AS. Thus the border gateway of each AS
        can forward packets to the border gateway of the other AS without
        resorting to Inter-AS or Intra-AS routing.

        BGP connection:  There is a BGP session between BGP speakers in
        each of the AS's, and this session communicates those routes that
        can be used for specific networks via the advertising AS.
        Throughout this document we place an additional restriction on the
        BGP speakers that form the BGP connection: they must themselves
        share the same network that their border gateways share. Thus, a
        BGP session between adjacent AS's requires no support from either
        Inter-AS or Intra-AS routing. Cases that do not conform to this
        restriction fall outside the scope of this document.

     Thus, at each connection, each AS has one or more BGP speakers and
     one or more border gateways, and these BGP speakers and border
     gateways are all located on a shared network. Note that BGP speakers
     do not need to be a border gateway, and vice versa. Paths announced
     by a BGP speaker of one AS on a given connection are taken to be
     feasible for each of the border gateways of the other AS on the same
     shared network, i.e. indirect neighbors are allowed.

     Much of the traffic carried within an AS either originates or
     terminates at that AS (i.e., either the source IP address or the
     destination IP address of the IP packet identifies a host on a
     network internal to that AS).  Traffic that fits this description is
     called "local traffic". Traffic that does not fit this description is
     called "transit traffic". A major goal of BGP usage is to control the
     flow of transit traffic.

     Based on how a particular AS deals with transit traffic, the AS may
     now be placed into one of the following categories:

        Stub AS: an AS that has only a single connection to one other AS.
        Naturally, a stub AS only carries local traffic.

        Multihomed AS: an AS that has connections to more than one other
        AS, but refuses to carry transit traffic.

  Expiration Date March 1994                              [Page 4]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

        Transit AS: an AS that has connections to more than one other AS,
        and is designed (under certain policy restrictions) to carry both
        transit and local traffic.

     Since a full AS path provides an efficient and straightforward way of
     suppressing routing loops and eliminates the "count-to-infinity"
     problem associated with some distance vector algorithms, BGP imposes
     no topological restrictions on the interconnection of AS's.

  3. BGP in the Internet


  3.1 Topology Considerations


     The overall Internet topology may be viewed as an arbitrary
     interconnection of transit, multihomed, and stub AS's.  In order to
     minimize the impact on the current Internet infrastructure, stub and
     multihomed AS's need not use BGP.  These AS's may run other protocols
     (e.g., EGP) to exchange reachability information with transit AS's.
     Transit AS's using BGP will tag this information as having been
     learned by some method other than BGP. The fact that BGP need not run
     on stub or multihomed AS's has no negative impact on the overall
     quality of inter-AS routing for traffic that either destined to or
     originated from the stub or multihomed AS's in question.

     However, it is recommended that BGP be used for stub and multihomed
     AS's as well. In these situations, BGP will provide an advantage in
     bandwidth and performance over some of the currently used protocols
     (such as EGP).  In addition, this would reduce the need for the use
     of default routes and in better choices of Inter-AS routes for
     multihomed AS's.

  3.2 Global Nature of BGP


     At a global level, BGP is used to distribute routing information
     among multiple Autonomous Systems. The information flows can be
     represented as follows:


                      +-------+         +-------+
                BGP   |  BGP  |   BGP   |  BGP  |   BGP
             ---------+       +---------+       +---------
                      |  IGP  |         |  IGP  |
                      +-------+         +-------+

                      <-AS A-->         <--AS B->



     This diagram points out that, while BGP alone carries information
     between AS's, both BGP and an IGP may carry information across an AS.
     Ensuring consistency of routing information between BGP and an IGP


  Expiration Date March 1994                              [Page 5]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     within an AS is a significant issue and is discussed at length later
     in Appendix A.

  3.3 BGP Neighbor Relationships


     The Internet is viewed as a set of arbitrarily connected AS's. BGP
     speakers in each AS communicate with each other to exchange network
     reachability information based on a set of policies established
     within each AS. Routers that communicate directly with each other via
     BGP are known as BGP neighbors. BGP neighbors can be located within
     the same AS or in different AS's. For the sake of discussion, BGP
     communications with neighbors in different AS's will be referred to
     as External BGP, and with neighbors in the same AS as Internal BGP.

     There can be as many BGP speakers as deemed necessary within an AS.
     Usually, if an AS has multiple connections to other AS's, multiple
     BGP speakers are needed. All BGP speakers representing the same AS
     must give a consistent image of the AS to the outside. This requires
     that the BGP speakers have consistent routing information among them.
     These gateways can communicate with each other via BGP or by other
     means. The policy constraints applied to all BGP speakers within an
     AS must be consistent. Techniques such as using a tagged IGP (see
     A.2.2) may be employed to detect possible inconsistencies.

     In the case of External BGP, the BGP neighbors must belong to
     different AS's, but share a common network. This common network
     should be used to carry the BGP messages between them. The use of BGP
     across an intervening AS invalidates the AS path information. An
     Autonomous System number must be used with BGP to specify which
     Autonomous System the BGP speaker belongs to.

  4. Requirements for Route Aggregation


     A conformant BGP implementation is required to have the ability to
     specify when an aggregated route may be generated out of partial
     routing information. For example, a BGP speaker at the border of an
     autonomous system (or group of autonomous systems) must be able to
     generate an aggregated route for a whole set of destination IP
     addresses (in BGP terminology such a set is called the Network Layer
     Reachability Information or NLRI) over which it has administrative
     control, even when not all of them are reachable at the same time.

     A conformant implementation is required to have the ability to
     specify how NLRI may be de-aggregated.

     A conformant implementation is required to support the following
     options when dealing with overlapping routes:

     Install both the less and the more specific routes Install the more
     specific route only Install neither route

     A conformant implementation may also support other options when

  Expiration Date March 1994                              [Page 6]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     dealing with overlapping routes, as specified in Clause 7.16.3.1 of
     [6].

     By default a BGP speaker should aggregate NLRI representing subnets
     to the corresponding network.

     Injecting NLRI representing arbitrary subnets into BGP without
     aggregation to the corresponding network shall be controlled via
     configuration parameters.

     Certain routing policies may depend on the NLRI (e.g. "research"
     versus "commercial"). Therefore, a BGP speaker that performs route
     aggregation should be cognizant, if possible, of potential
     implications on routing policies when aggregating NLRI.

  5. Policy Making with BGP


     BGP provides the capability for enforcing policies based on various
     routing preferences and constraints. Policies are not directly
     encoded in the protocol. Rather, policies are provided to BGP in the
     form of configuration information.

     BGP enforces policies by affecting the selection of paths from
     multiple alternatives and by controlling the redistribution of
     routing information.  Policies are determined by the AS
     administration.

     Routing policies are related to political, security, or economic
     considerations. For example, if an AS is unwilling to carry traffic
     to another AS, it can enforce a policy prohibiting this. The
     following are examples of routing policies that can be enforced with
     the use of BGP:

     A multihomed AS can refuse to act as a transit AS for other AS's.
     (It does so by only advertising routes to networks internal to the
     AS.) A multihomed AS can become a transit AS for a restricted set of
     adjacent AS's, i.e., some, but not all, AS's can use the multihomed
     AS as a transit AS. (It does so by advertising its routing
     information to this set of AS's.) An AS can favor or disfavor the use
     of certain AS's for carrying transit traffic from itself.

     A number of performance-related criteria can be controlled with the
     use of BGP:

     An AS can minimize the number of transit AS's. (Shorter AS paths can
     be preferred over longer ones.) The quality of transit AS's. If an AS
     determines that two or more AS paths can be used to reach a given
     destination, that AS can use a variety of means to decide which of
     the candidate AS paths it will use. The quality of an AS can be
     measured by such things as diameter, link speed, capacity, tendency
     to become congested, and quality of operation. Information about
     these qualities might be determined by means other than BGP.
     Preference of internal routes over external routes.

  Expiration Date March 1994                              [Page 7]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     For consistency within an AS, equal cost paths, resulting from
     combinations of policies and/or normal route selection procedures,
     must be resolved in a consistent fashion.

     Fundamental to BGP is the rule that an AS advertises to its
     neighboring AS's only those routes that it uses. This rule reflects
     the "hop-by-hop" routing paradigm generally used by the current
     Internet.

     IDRP for IP has two features (DIST_LIST_INCL and DIST_LIST_EXCL)
     which allow additional constraints to be placed on the propagation of
     routing information, by restricting the group of AS's which may
     receive certain information.  See Section 10 for further details.

  6. Path Selection with BGP

     One of the major tasks of a BGP speaker is to evaluate different
     paths to a destination network from its border gateways, select the
     best one, apply appropriate policy constraints, and then advertise it
     to all of its BGP neighbors. The key issue is how different paths are
     evaluated and compared.  In traditional distance vector protocols
     (e.g., RIP) there is only one metric (e.g., hop count) associated
     with a path. As such, comparison of different paths is reduced to
     simply comparing two numbers. A complication in Inter-AS routing
     arises from the lack of a universally agreed-upon metric among AS's
     that can be used to evaluate external paths. Rather, each AS may have
     its own set of criteria for path evaluation.

     A BGP speaker builds a routing database consisting of the set of all
     feasible paths and the list of networks reachable through each path.
     For purposes of precise discussion, it's useful to consider the set
     of feasible paths for a given destination network. In many cases, we
     would expect to find only one feasible path. However, when this is
     not the case, all feasible paths should be maintained, as their
     maintenance speeds adaptation to the loss of the primary path. Only
     the primary path at any given time will ever be advertised.

     The path selection process can be formalized by defining a partial
     order over the set of all feasible paths to a given destination
     network. One way to define this partial order is to define a function
     that maps each full AS path to a non-negative integer that denotes
     the path's degree of preference. Path selection is then reduced to
     applying this function to all feasible paths and choosing the one
     with the lowest degree of preference.

     In actual BGP implementations, the criteria for assigning degree of
     preferences to a path are specified as configuration information.

     The process of assigning a degree of preference to a path can be
     based on several sources of information:


     Information explicitly present in the full AS path.  A combination of
     information that can be derived from the full AS path and information

  Expiration Date March 1994                              [Page 8]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     outside the scope of BGP (e.g., policy routing constraints provided
     as configuration information).

     Possible criteria for assigning a degree of preference to a path are:

     AS count. Paths with a smaller AS count are generally better.  Policy
     considerations. BGP supports policy-based routing based on the
     controlled distribution of routing information.  A BGP speaker may be
     aware of some policy constraints (both within and outside of its own
     AS) and do appropriate path selection.  Paths that do not comply with
     policy requirements are not considered further.  Presence or absence
     of a certain AS or set of AS's in the path. By means of information
     outside the scope of BGP, an AS may know some performance
     characteristics (e.g., bandwidth, MTU, intra-AS diameter) of certain
     AS's and may try to avoid or prefer them.  Path origin. A path
     learned entirely from BGP (i.e., whose endpoint is internal to the
     last AS on the path) is generally better than one for which part of
     the path was learned via EGP or some other means.  AS path subsets.
     An AS path that is a subset of a longer AS path to the same
     destination should be preferred over the longer path.  Any problem in
     the shorter path (such as an outage) will also be a problem in the
     longer path.  Link dynamics. Stable paths should be preferred over
     unstable ones. Note that this criterion must be used in a very
     careful way to avoid causing unnecessary route fluctuation.
     Generally, any criteria that depend on dynamic information might
     cause routing instability and should be treated very carefully.

  7. Recommended Set of Supported Routing Policies.


     Policies are provided to BGP in the form of configuration
     information.  This information is not directly encoded in the
     protocol. Therefore, BGP can provide support for very complex routing
     policies. However, it is not required that all BGP implementations
     support such policies.

     While we are not attempting to standardize the routing policies that
     must be supported in every BGP implementation, we strongly encourage
     all implementors to support the following set of routing policies:

     BGP implementations should allow an AS to control announcements of
     BGP-learned routes to adjacent AS's.  Implementations should support
     such control with at least the granularity of a single network.
     Implementations should also support such control with the granularity
     of an autonomous system, where the autonomous system may be either
     the autonomous system that originated the route, or the autonomous
     system that advertised the route to the local system (adjacent
     autonomous system).  Care must be taken when a BGP speaker selects a
     new route that can't be announced to a particular external peer,
     while the previously selected route was announced to that peer.
     Specifically, the local system must explicitly indicate to the peer
     that the previous route is now infeasible.  BGP implementations
     should allow an AS to prefer a particular path to a destination (when
     more than one path is available).  This function may be implemented

  Expiration Date March 1994                              [Page 9]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     by allowing system administrators to assign "weights" to AS's, and by
     having the route selection process select a route with the lowest
     "weight" (where "weight" of a route is defined as a sum of "weights"
     of all AS's in the AS_PATH path attribute associated with that
     route).  BGP implementations should allow an AS to ignore routes with
     certain AS's in the AS_PATH path attribute.  Such function can be
     implemented by using the technique outlined in [2], and by assigning
     "infinity" as "weights" for such AS's. The route selection process
     must ignore routes that have "weight" equal to "infinity".

  8. Interaction With Other Exterior Routing Protocols


     This section presents guidelines for routing information exchange
     between BGP and BGP-3 or EGP-2, as well as between BGP-4 and IDRP.
     The suggested guidelines are consistent with the guidelines presented
     in [3], [4], and [5].

     The routing information exchange has the following aspects: how a
     route received via EGP2/BGP-3 gets injected into BGP how a route
     received via BGP gets injected into EGP2/BGP-3 how a route received
     via BGP-4 gets injected into IDRP how a route received via IDRP gets
     injected into BGP-4

     An AS should advertise a minimal aggregate for its internal networks
     with respect to the amount of address space that it is actually
     using.  This can be used by administrators of non-BGP AS's to
     determine how many routes to explode from a single aggregate.

  8.1 Exchanging Information With EGP2


     The following guidelines are suggested for exchanging routing
     information between BGP and EGP2.

     To provide for graceful migration, a BGP speaker may participate in
     EGP2 as well as in BGP. Thus, a BGP speaker may receive IP
     reachability information by means of EGP2 as well as by means of BGP.
     It is strongly recommended that the exchange of routing information
     via EGP2 between a BGP speaker participating in BGP and a pure EGP2
     speaker occur only at Autonomous System boundaries.

     The information received by EGP2 can be injected into BGP-4 with the
     ORIGIN path attribute set to 1.  It can likewise be injected into
     IDRP with the EXT_INFO path attribute.

     Likewise, the information received via BGP can be injected into EGP2.
     In the latter case, however, one needs to be aware of the potential
     information explosion when a given IP prefix received from BGP
     denotes a set of consecutive A/B/C class networks.  Injection of BGP
     received NLRI that denotes IP subnets requires the BGP speaker to
     inject the corresponding network into EGP2.

     The local system shall provide mechanisms to control the exchange of

  Expiration Date March 1994                             [Page 10]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     reachability information between EGP2 and BGP.  Specifically, a
     conformant implementation is required to support all of the following
     options when injecting BGP received reachability information into
     EGP2:

     inject default only (0.0.0.0); no export of any other NLRI allow
     controlled deaggregation, but only of specific routes; allow export
     of non-aggregated NLRI allow export of only non-aggregated NLRI

     Additional constraints on injecting information received via IDRP
     into EGP2 are listed in Section 8.4.  Additional constraints on
     injecting information received via BGP-4 into EGP2 are listed in
     Section 8.5.

  8.2 Exchanging information with BGP-3


     The following guidelines are suggested for exchanging routing
     information between BGP and BGP-3.

     To provide for graceful migration, a BGP speaker may participate in
     BGP-3 as well as in BGP.  Thus, a BGP speaker may receive IP
     reachability information by means of BGP-3 as well as by means of
     BGP.  It is strongly recommended that the exchange of routing
     information via BGP-3 between a BGP speaker participating in BGP-3
     and a pure BGP-3 speaker occur only at Autonomous System boundaries.

     When injecting BGP-3 routes into BGP-4, the AS_SEQUENCE information
     shall be injected as an AS_SET.  For IDRP, the AS_SEQUENCE
     information shall be injected as an RD_SET within the RD_PATH
     attribute.

     A BGP speaker may inject the information received by BGP-4 into BGP-3
     as follows.

     If an AS_PATH attribute of a BGP-4 route carries AS_SET path
     segments, then the AS_PATH attribute of the BGP-3 route shall be
     constructed by treating the AS_SET segments as AS_SEQUENCE segments,
     with the resulting AS_PATH being a single AS_SEQUENCE. While this
     procedure loses set/sequence information, it doesn't affect
     protection for routing loops suppression.  It may affect policies if
     they are based on the content or ordering of the AS_PATH attribute.

     A BGP speaker may inject the information received by IDRP into BGP-3
     as follows.

     IDRP's equivalent for the AS_PATH attribute is RD_PATH path
     attribute, where RD stands for Routing Domain.  A Routing Domain has
     an identifier which for IDRP for IP is a fixed prefix catenated with
     the AS number.  Given this translation, as defined in the "IDRP for
     IP" document, the IDRP RD_PATH information containing RD_SEQUENCEs
     and RD_SETs is translated into BGP-3 AS_SEQUENCES attribute in the
     same way BGP-4's AS_SEQUENCEs and AS-SETs are.  The resulting BGP-3
     AS_PATH attribute contains all the domains listed in the RD_PATH


  Expiration Date March 1994                             [Page 11]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     attribute.  Again, this does not affect loop suppression, but may
     affect policies.

     While injecting BGP derived NLRI into BGP-3, one needs to be aware of
     the potential information explosion when a given IP prefix denotes a
     set of consecutive A/B/C class networks. Injection of BGP derived
     NLRI that denotes IP subnets requires the BGP speaker to inject the
     corresponding network into BGP-3. The local system shall provide
     mechanisms to control the exchange of routing information between
     BGP-3 and BGP.  Specifically, a conformant implementation is required
     to support all of the following options when injecting BGP received
     routing information into BGP-3:

     inject default only (0.0.0.0), no export of any other NLRI allow
     controlled deaggregation, but only of specific routes; allow export
     of non-aggregated NLRI allow export of only non-aggregated NLRI

     Additional constraints on injecting information received via IDRP
     into BGP-3 are listed in Section 8.4.  Additional constraints on
     injecting information received via BGP-4 into BGP-3 are listed in
     Section 8.5.

  8.3 Exchanging Information Between IDRP and BGP-4


     To provide for graceful migration, an IDRP speaker may participate in
     BGP-4. Thus, an IDRP speaker may receive IP reachability information
     by means of BGP-4, as well as by means of IDRP.  If IDRP for IP and
     BGP-4 routers restrict themselves to the set of functions which is
     common to both protocols, translation between the protocols can be
     done.  Within these restrictions, routers can participate in both
     IDRP and BGP-4 conversations on domain boundaries, and within routing
     domains.

     When passing a BGP-4 route with the ATOMIC_AGGREGATE path attribute
     to IDRP, the IDRP for IP ATOMIC_AGGREGATE shall be included in the
     IDRP route.  The ATOMIC_AGGREGATE attribute is defined in [7].

     Note that any IDRP for IP router receiving a route with the
     ATOMIC_AGGREGATE option shall not deaggregate that route.

     Also note that any IDRP router not recognizing the ATOMIC_AGGREGATE
     option shall set the Partial bit in the Flag field of the attribute
     to 1, as required by clause 7.11.1.a in [6].

     In exporting reachability information from IDRP for IP to BGP-4, if
     the IDRP for IP ATOMIC_AGGREGATE attribute is present and the Partial
     bit is set to 0, the BGP-4 ATOMIC_AGGREGATE attribute shall be
     included in the BGP-4 route.  If the IDRP for IP ATOMIC_AGGREGATE
     attribute is present and the Partial bit is set to 1, the BGP-4
     ORIGIN attribute shall be set to INCOMPLETE.

     The following table specifies mapping between BGP-4 and IDRP for IP
     path attributes.

  Expiration Date March 1994                             [Page 12]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

                           BGP4           IDRP
                          -------------------------------

                          ORIGIN          EXT_INFO

                          AS_PATH         RD_PATH

                          NEXT_HOP        NEXT_HOP

                          MULTI_EXTI_DISC MULTI_EXIT_DISC

                          LOC_PREF        ROUTE_SEPARATOR



     Additional constraints on injecting information received via IDRP
     into BGP-4 are listed in Section 8.4.

  8.4 Additional Constraints on Exchange of IDRP Routes


     The following IDRP attributes cannot be passed into EGP2, BGP-3, or
     BGP-4:

     CAPACITY RD-HOP-COUNT

     However, IDRP routes with these attributes can be passed into EGP2,
     BGP-3, or BGP-4 after stripping the attributes.

     IDRP routes with the following path attributes cannot be passed into
     BGP-3, BGP-4, and EGP2:

     DIST_LIST_INCL DIST_LIST_EXCL HIERARCHICAL_RECORDING TRANSIT DELAY
     RESIDUAL_ERROR EXPENSE LOCALLY DEFINED QoS SECURITY PRIORITY

     When passing a route received via EGP2 or a route received via BGP-3
     or BGP-4, such that the value of the ORIGIN attribute of the route is
     anything but IGP, to IDRP, the corresponding IDRP route shall have
     the EXT_INFO path attribute.  If an IDRP route carries EXT_INFO path
     attribute then the corresponding BGP-3 or BGP-4 route shall have
     value of its ORIGIN attribute set to INCOMPLETE.

     When passing a BGP-3 or BGP-4 route to IDRP, the IDRP RD-HOP-COUNT
     attribute shall be constructed by counting the number of ASs in the
     AS-PATH attribute of the route.

     If an IDRP route carries ENTRY_SEQ or ENTRY_SET path segments, then
     before passing this route to BGP-3 or BGP-4 the BIS shall assume that
     the route exited all the confederations denoted in ENTRY_SET or
     ENTRY_SEQ and update the RD_PATH of the route accordingly.





  Expiration Date March 1994                             [Page 13]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

  8.5 Additional Constrains on Exchange of BGP-4 Routes


     The following BGP-4 attribute can not be passed into EGP2, BGP-3, or
     IDRP:

     AGGREGATOR

     However, BGP-4 routes with this attribute can be passed into IDRP.

     A route that carries the BGP-4 ATOMIC_AGGREGATE path attribute shall
     not be exported into EGP2 or BGP-3, unless such export can be
     accomplished without deaggregating the NLRI of the route.

  9. Operations over Switched Virtual Circuits


     When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
     be desirable to minimize traffic generated by BGP. Specifically, it
     may be desirable to eliminate traffic associated with periodic
     KEEPALIVE messages.  BGP includes a mechanism for operation over
     switched virtual circuit (SVC) services which avoids keeping SVCs
     permanently open and allows it to eliminate periodic sending of
     KEEPALIVE messages.

     This section describes how to operate without periodic KEEPALIVE
     messages to minimize SVC usage when using an intelligent SVC circuit
     manager.  This scheme may also be used on "permanent" circuits, which
     support a feature like link quality monitoring or echo request to
     determine the status of link connectivity.

     The mechanism described in this section is suitable only between BGP
     speakers that are directly connected over a common virtual circuit.

  9.1 Establishing a BGP Connection


     The feature is selected by specifying zero Hold Time in the OPEN
     message.

  9.2 Circuit Manager Properties


     The circuit manager must have sufficient functionality to be able to
     compensate for the lack of periodic KEEPALIVE messages:

     It must be able to determine link layer unreachability within a
     bounded time of the occurance of such a failure.  On determining
     unreachability it should: start a configurable dead timer (comparable
     to a typical Hold timer value).  attempt to re-establish the Link
     Layer connection.

     If the dead timer expires it should: send an internal circuit DEAD
     indication to TCP (if used with BGP-4) or to the IDRP Finite State

  Expiration Date March 1994                             [Page 14]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 


     Machine (if used with IDRP for IP) If the connection is re-
     established before the dead timer expires it should: cancel the dead
     timer.  If the connection is re-established after the dead timer has
     expired (that is, after a DEAD indication has been sent) it should:
     send an internal circuit UP indication to TCP (if used with BGP-4) or
     to the IDRP Finite State Machine (if used with IDRP for IP).


  9.3 TCP Properties


     A small modification must be made to TCP to process internal
     notifications from the circuit manager: DEAD: Flush transmit queue
     and abort TCP connection.  UP: Transmit any queued data or allow an
     outgoing TCP call to proceed.

  9.4 IDRP Finite State Machine Properties


     A small modification must be made to the IDRP Finite State Machine to
     process internal notifications from the circuit manager: DEAD:
     Generate the DEACTIVATE event UP: Generate the ACTIVATE event

  9.5 Combined Properties


     Some implementations may not be able to guarantee that the BGP
     process and the circuit manager will operate as a single entity; i.e.
     they can have a separate existence when the other has been stopped or
     has crashed.

     If this is the case, a periodic two-way poll between the BGP process
     and the circuit manager should be implemented.  If the BGP process
     discovers the circuit manager has gone away it should close all
     relevant TCP connections in the case of BGP-4 or close all relevant
     peer sessions in the case of IDRP.  If the circuit manager discovers
     the BGP process has gone away it should close all its connections
     associated with the BGP process and reject any further incoming
     connections.

  10. IDRP for IP Differences


     The additional attributes and protocol semantics IDRP contains
     besides those in BGP-4 fall into three categories:  QoS related,
     Distribution List related, and Routing Domain Confederations related.

     The QoS related attributes can be thought of as an extension of the
     TOS functions already defined in IP.  These functions have been left
     by IDRP for IP for future study and experimentation.  Anyone
     interested in IDRP's QoS features should contact the BGP/IDRP for IP
     working groups.

     The Distribution List attributes are DIST_LIST_INCL and

  Expiration Date March 1994                             [Page 15]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     DIST_LIST_EXCL.  Their function can be described as follows:  BGP
     speakers receive information from BGP speakers in other AS's, which
     we call the "upstream" AS's.  They then select routes from this
     information and propagate them to other AS's, which we call the
     "downstream" AS's.  The distribution list attributes provide
     mechanisms for the router originating some reachability information
     (or any router downstream of it) to constrain the downstream
     propagation of that information.  If distribution list attributes are
     included, downstream AS's are required to restrict distribution of
     the routing information -- in the case of DIST_LIST_INCL, the routing
     information may only be distributed to the specified set of AS's, and
     in the case of DIST_LIST_EXCL, the routing information my be
     distributed to any AS's but the specified set.  If no distribution
     list attributes are included, the information may be distributed
     without constraint.

     Routing Domain Confederations is a mechanism to group together
     routing domains with compatible policies, in effect providing
     "aggregation" of Routing Domains.  By using RDCs, AS paths can be
     compacted considerably.

     With a Confederation, several AS's can be grouped together.  From the
     point of view of AS's external to the Confederation, the AS path
     information (RD_PATH) can be replaced by a single identifier, the RDC
     identifier.  For example, if 10 associated AS's containing 30 IP
     networks decide to form a Confederation (they might be the members of
     an academic consortium, for example), they could advertise all 30 of
     their networks with a single entry in the RD_PATH, abstracting the
     internal topology of their confederation.

  11. Conclusion


     The BGP protocols, BGP-4 and IDRP, provide a high degree of control
     and flexibility for doing interdomain routing while enforcing policy
     and performance constraints and avoiding routing loops. The
     guidelines presented here will provide a starting point for using BGP
     to provide more sophisticated and manageable routing in the Internet
     as it grows.

  Appendix A. The Interaction of BGP and an IGP


     This section outlines methods by which BGP can exchange routing
     information with an IGP. The methods outlined here are not proposed
     as part of the standard BGP usage at this time.  These methods are
     outlined for information purposes only.  Implementors may want to
     consider these methods when importing IGP information.

     This is general information that applies to any generic IGP.
     Interaction between BGP and any specific IGP is outside the scope of
     this section.  Methods for specific IGP's should be proposed in
     separate documents.  Methods for specific IGP's could be proposed for
     standard usage in the future.

  Expiration Date March 1994                             [Page 16]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

  Overview


     By definition, all transit AS's must be able to carry traffic which
     originates from and/or is destined to locations outside of that AS.
     This requires a certain degree of interaction and coordination
     between BGP and the Interior Gateway Protocol (IGP) used by that
     particular AS. In general, traffic originating outside of a given AS
     will pass through both interior gateways (gateways that support the
     IGP only) and border gateways (gateways that support both the IGP and
     BGP). All interior gateways receive information about external routes
     from one or more of the border gateways of the AS via the IGP, unless
     encapsulation is used (see Section A.2.3).

     Depending on the mechanism used to propagate BGP information within a
     given AS, special care must be taken to ensure consistency between
     BGP and the IGP, since changes in state are likely to propagate at
     different rates across the AS. There may be a time window between the
     moment when some border gateway (A) receives new BGP routing
     information which was originated from another border gateway (B)
     within the same AS, and the moment the IGP within this AS is capable
     of routing transit traffic to that border gateway (B). During that
     time window, either incorrect routing or "black holes" can occur.

     In order to minimize such routing problems, border gateway (A) should
     not advertise a route to some exterior network X via border gateway
     (B) to all of its BGP neighbors in other AS's until all the interior
     gateways within the AS are ready to route traffic destined to X via
     the correct exit border gateway (B). In other words, interior routing
     should converge on the proper exit gateway before/advertising routes
     via that exit gateway to other AS's.

  A.2 Methods for Achieving Stable Interactions


     The following discussion outlines several techniques capable of
     achieving stable interactions between BGP and the IGP within an
     Autonomous System.

  A.2.1 Propagation of BGP Information via the IGP


     While BGP can provide its own mechanism for carrying BGP information
     within an AS, one can also use an IGP to transport this information,
     as long as the IGP supports complete flooding of routing information
     (providing the mechanism to distribute the BGP information) and one
     pass convergence (making the mechanism effectively atomic). If an IGP
     is used to carry BGP information, then the period of
     desynchronization described earlier does not occur at all, since BGP
     information propagates within the AS synchronously with the IGP, and
     the IGP converges more or less simultaneously with the arrival of the
     new routing information. Note that the IGP only carries BGP
     information and should not interpret or process this information.


  Expiration Date March 1994                             [Page 17]



  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

  A.2.2  Tagged Interior Gateway Protocol


     Certain IGPs can tag routes exterior to an AS with the identity of
     their exit points while propagating them within the AS. Each border
     gateway should use identical tags for announcing exterior routing
     information (received via BGP) both into the IGP and into Internal
     BGP when propagating this information to other border gateways within
     the same AS. Tags generated by a border gateway must uniquely
     identify that particular border gateway--different border gateways
     must use different tags.

     All Border Gateways within a single AS must observe the following two
     rules:


     Information received via Internal BGP by a border gateway A declaring
     a network to be unreachable must immediately be propagated to all of
     the External BGP neighbors of A.  Information received via Internal
     BGP by a border gateway A about a reachable network X cannot be
     propagated to any of the External BGP neighbors of A unless/until A
     has an IGP route to X and both the IGP and the BGP routing
     information have identical tags.

     These rules guarantee that no routing information is announced
     externally unless the IGP is capable of correctly supporting it. It
     also avoids some causes of "black holes".

     One possible method for tagging BGP and IGP routes within an AS is to
     use the IP address of the exit border gateway announcing the exterior
     route into the AS. In this case the "gateway" field in the BGP UPDATE
     message is used as the tag.

     An alternate method for tagging BGP and IGP routes is to have BGP and
     the IGP agree on a router ID.  In this case, the router ID is
     available to all BGP (version 3 or higher) speakers.  Since this ID
     is already unique it can be used directly as the tag in the IGP.

  A.2.3 Encapsulation


     Encapsulation provides the simplest (in terms of the interaction
     between the IGP and BGP) mechanism for carrying transit traffic
     across the AS. In this approach, transit traffic is encapsulated
     within an IP datagram addressed to the exit gateway. The only
     requirement imposed on the IGP by this approach is that it should be
     capable of supporting routing between border gateways within the same
     AS.

     The address of the exit gateway A for some exterior network X is
     specified in the BGP identifier field of the BGP OPEN message
     received from gateway A via Internal BGP by all other border gateways
     within the same AS. In order to route traffic to network X, each
     border gateway within the AS encapsulates it in datagrams addressed


  Expiration Date March 1994                             [Page 18]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     to gateway A. Gateway A then performs decapsulation and forwards the
     original packet to the proper gateway in another AS.

     Since encapsulation does not rely on the IGP to carry exterior
     routing information, no synchronization between BGP and the IGP is
     required.

     Some means of identifying datagrams containing encapsulated IP, such
     as an IP protocol type code, must be defined if this method is to be
     used.

     Note that, if a packet to be encapsulated has length that is very
     close to the MTU, that packet would be fragmented at the gateway that
     performs encapsulation.

  A.2.4  Pervasive BGP


     If all routers in an AS are BGP speakers, then there is no need to
     have any interaction between BGP and an IGP.  In such cases, all
     routers in the AS already have full information of all BGP routes.
     The IGP is then only used for routing within the AS, and no BGP
     routes are imported into the IGP.

     For routers to operate in this fashion, they must be able to perform
     a recursive lookup in their routing table.  The first lookup will use
     a BGP route to establish the exit router, while the second lookup
     will determine the IGP path to the exit router.

     Since the IGP carries no external information in this scenario, all
     routers in the AS will have converged as soon as all BGP speakers
     have new information about this route.  Since there is no need to
     delay for the IGP to converge, an implementation may advertise these
     routes without further delay due to the IGP.

  A.2.5  Other Cases


     There may be AS's with IGPs which can neither carry BGP information
     nor tag exterior routes (e.g., RIP). In addition, encapsulation may
     be either infeasible or undesirable. In such situations, the
     following two rules must be observed:

     Information received via Internal BGP by a border gateway A declaring
     a network to be unreachable must immediately be propagated to all of
     the External BGP neighbors of A.  Information received via Internal
     BGP by a border gateway A about a reachable network X cannot be
     propagated to any of the External BGP neighbors of A unless A has an
     IGP route to X and sufficient time has passed for the IGP routes to
     have converged.

     The above rules present necessary (but not sufficient) conditions for
     propagating BGP routing information to other AS's. In contrast to
     tagged IGPs, these rules cannot ensure that interior routes to the

  Expiration Date March 1994                             [Page 19]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

     proper exit gateways are in place before propagating the routes to
     other AS's.

     If the convergence time of an IGP is less than some small value X,
     then the time window during which the IGP and BGP are unsynchronized
     is less than X as well, and the whole issue can be ignored at the
     cost of transient periods (of less than length X) of routing
     instability. A reasonable value for X is a matter for further study,
     but X should probably be less than one second.

     If the convergence time of an IGP cannot be ignored, a different
     approach is needed. Mechanisms and techniques which might be
     appropriate in this situation are subjects for further study.

  References


     [1] Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4),
     Internet Draft, cisco Systems, T.J. Watson Research Center, IBM
     Corp., September 1993.

     [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
     Merit/NSFNET, June 1989.

     [3] Fuller, V., Li, T., Yu, J., Varadhan, K., "Supernetting: an
     Address Assignment and Aggregation Strategy", RFC1519, September
     1993.

     [4] Rekhter, Y., Li, T., "An Architecture for IP address Allocation
     with CIDR", RFC1518, September 1993

     [5] Rekhter, Y., Topolcic, C. "Exchanging Routing Information Across
     Provider/Subscriber Boundaries in the CIDR Environment", RFC1520,
     September 1993

     [6] ISO/IEC IS 10747 - Information Processing Systems -
     Telecommunications and Information Exchange between Systems -
     Protocol for Exchange of Inter-domain Routeing Information among
     Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993.

     [7] Hares, S., Scudder, J., "IDRP for IP", Internet Draft, Merit
     Network Inc., September 1993.

     [8] ISO/IEC JTC 1 "Protocol for Exchanging of Inter-Domain Routeing
     Information among Intermediate Systems to Support Forwarding of ISO
     8473 PDUs", IS10747 1993

  Security Considerations


     Security issues are not discussed in this memo.



  Expiration Date March 1994                             [Page 20]




  INTERNET DRAFT                                            September 1993
  draft-ietf-bgp-idrp-idrp-usage-01.txt 

  Authors' Addresses


     Yakov Rekhter
     T.J. Watson Research Center IBM Corporation
     P.O. Box 218
     Yorktown Heights, NY 10598

     Phone:  (914) 945-3896
     EMail: yakov@watson.ibm.com

     Susan Hares
     Merit, Inc
     1071 Beal Avenue
     Ann Arbor, MI 4810x

     Phone: (313)936-2095
     Email: skh@merit.edu


     IETF BGP WG mailing list: bgp@ans.net
     To be added: bgp-request@ans.net

     IETF IDRP for IP WG mailing list: idrp-for-ip@merit.edu
     To be added: idrp-request@merit.edu






























  Expiration Date March 1994                             [Page 21]


name: draft-ietf-dtn-dtnma
rev: 14
title: DTN Management Architecture
time: 2024-11-07T14:15:17Z
group_uri: /api/v1/group/group/1966/
expires: 2024-10-30T19:38:04Z
ad: /api/v1/person/person/108992/
shepherd: /api/v1/person/email/rick.taylor@ori.co/
categories: ["Autonomous netops", "A2A protocols"]
tags: []
fetched_at: 2026-03-04T00:00:05.968939+00:00
source: ietf
abstract:
  The Delay-Tolerant Networking (DTN) architecture describes a type of
     challenged network in which communications may be significantly
     affected by long signal propagation delays, frequent link
     disruptions, or both.  The unique characteristics of this environment
     require a unique approach to network management that supports
     asynchronous transport, autonomous local control, and a small
     footprint (in both resources and dependencies) so as to deploy on
     constrained devices.

     This document describes a DTN management architecture (DTNMA)
     suitable for managing devices in any challenged environment but, in
     particular, those communicating using the DTN Bundle Protocol (BP).
     Operating over BP requires an architecture that neither presumes
     synchronized transport behavior nor relies on query-response
     mechanisms.  Implementations compliant with this DTNMA should expect
     to successfully operate in extremely challenging conditions, such as
     over uni-directional links and other places where BP is the preferred
     transport.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/110/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  Delay-Tolerant Networking                                   E.J. Birrane
  Internet-Draft                                               S.E. Heiner
  Intended status: Informational                                  E. Annis
  Expires: 30 October 2024        Johns Hopkins Applied Physics Laboratory
                                                             28 April 2024


                        DTN Management Architecture
                          draft-ietf-dtn-dtnma-14

  Abstract

     The Delay-Tolerant Networking (DTN) architecture describes a type of
     challenged network in which communications may be significantly
     affected by long signal propagation delays, frequent link
     disruptions, or both.  The unique characteristics of this environment
     require a unique approach to network management that supports
     asynchronous transport, autonomous local control, and a small
     footprint (in both resources and dependencies) so as to deploy on
     constrained devices.

     This document describes a DTN management architecture (DTNMA)
     suitable for managing devices in any challenged environment but, in
     particular, those communicating using the DTN Bundle Protocol (BP).
     Operating over BP requires an architecture that neither presumes
     synchronized transport behavior nor relies on query-response
     mechanisms.  Implementations compliant with this DTNMA should expect
     to successfully operate in extremely challenging conditions, such as
     over uni-directional links and other places where BP is the preferred
     transport.

  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 30 October 2024.




  Birrane, et al.          Expires 30 October 2024                [Page 1]


  Internet-Draft                    DTNMA                       April 2024


  Copyright Notice

     Copyright (c) 2024 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
     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Organization  . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Challenged Network Overview . . . . . . . . . . . . . . . . .   8
       3.1.  Challenged Network Constraints  . . . . . . . . . . . . .   8
       3.2.  Topology and Service Implications . . . . . . . . . . . .   9
         3.2.1.  Tiered Management . . . . . . . . . . . . . . . . . .  10
         3.2.2.  Remote and Local Manager Associations . . . . . . . .  11
       3.3.  Management Special Cases  . . . . . . . . . . . . . . . .  12
     4.  Desirable Design Properties . . . . . . . . . . . . . . . . .  12
       4.1.  Dynamic Architectures . . . . . . . . . . . . . . . . . .  13
       4.2.  Hierarchically Modeled Information  . . . . . . . . . . .  13
       4.3.  Adaptive Push of Information  . . . . . . . . . . . . . .  14
       4.4.  Efficient Data Encoding . . . . . . . . . . . . . . . . .  15
       4.5.  Universal, Unique Data Identification . . . . . . . . . .  15
       4.6.  Runtime Data Definitions  . . . . . . . . . . . . . . . .  16
       4.7.  Autonomous Operation  . . . . . . . . . . . . . . . . . .  17
     5.  Current Remote Management Approaches  . . . . . . . . . . . .  18
       5.1.  SNMP and SMI Models . . . . . . . . . . . . . . . . . . .  19
         5.1.1.  The SMI Modeling Language . . . . . . . . . . . . . .  19
         5.1.2.  SNMP Protocol and Transport . . . . . . . . . . . . .  20
       5.2.  XML-Infoset-Based Protocols and YANG Models . . . . . . .  20
         5.2.1.  The YANG Modeling Language  . . . . . . . . . . . . .  20
         5.2.2.  NETCONF Protocol and Transport  . . . . . . . . . . .  22
         5.2.3.  RESTCONF Protocol and Transport . . . . . . . . . . .  23
         5.2.4.  CORECONF Protocol and Transport . . . . . . . . . . .  23
       5.3.  gRPC Network Management Interface (gNMI)  . . . . . . . .  23
         5.3.1.  The Protobuf Modeling Language  . . . . . . . . . . .  24
         5.3.2.  gRPC Protocol and Transport . . . . . . . . . . . . .  24
       5.4.  Intelligent Platform Management Interface (IPMI)  . . . .  24



  Birrane, et al.          Expires 30 October 2024                [Page 2]


  Internet-Draft                    DTNMA                       April 2024


       5.5.  Autonomic Networking  . . . . . . . . . . . . . . . . . .  24
       5.6.  Deep Space Autonomy . . . . . . . . . . . . . . . . . . .  25
     6.  Motivation for New Features . . . . . . . . . . . . . . . . .  25
     7.  Reference Model . . . . . . . . . . . . . . . . . . . . . . .  26
       7.1.  Important Concepts  . . . . . . . . . . . . . . . . . . .  26
       7.2.  Model Overview  . . . . . . . . . . . . . . . . . . . . .  27
       7.3.  Functional Elements . . . . . . . . . . . . . . . . . . .  28
         7.3.1.  Managed Applications and Services . . . . . . . . . .  28
         7.3.2.  DTNMA Agent (DA)  . . . . . . . . . . . . . . . . . .  29
         7.3.3.  Managing Applications and Services  . . . . . . . . .  31
         7.3.4.  DTNMA Manager (DM)  . . . . . . . . . . . . . . . . .  32
         7.3.5.  Pre-Shared Definitions  . . . . . . . . . . . . . . .  34
     8.  Desired Services  . . . . . . . . . . . . . . . . . . . . . .  34
       8.1.  Local Monitoring and Control  . . . . . . . . . . . . . .  35
       8.2.  Local Data Fusion . . . . . . . . . . . . . . . . . . . .  35
       8.3.  Remote Configuration  . . . . . . . . . . . . . . . . . .  36
       8.4.  Remote Reporting  . . . . . . . . . . . . . . . . . . . .  36
       8.5.  Authorization . . . . . . . . . . . . . . . . . . . . . .  37
     9.  Logical Autonomy Model  . . . . . . . . . . . . . . . . . . .  37
       9.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  38
       9.2.  Model Characteristics . . . . . . . . . . . . . . . . . .  40
       9.3.  Data Value Representation . . . . . . . . . . . . . . . .  42
       9.4.  Data Reporting  . . . . . . . . . . . . . . . . . . . . .  42
       9.5.  Command Execution . . . . . . . . . . . . . . . . . . . .  43
       9.6.  Predicate Autonomy Rules  . . . . . . . . . . . . . . . .  44
     10. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  44
       10.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . .  44
       10.2.  Serialized Management  . . . . . . . . . . . . . . . . .  45
       10.3.  Intermittent Connectivity  . . . . . . . . . . . . . . .  46
       10.4.  Open-Loop Reporting  . . . . . . . . . . . . . . . . . .  48
       10.5.  Multiple Administrative Domains  . . . . . . . . . . . .  49
       10.6.  Cascading Management . . . . . . . . . . . . . . . . . .  51
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  53
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  53
     13. Informative References  . . . . . . . . . . . . . . . . . . .  53
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  59
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  59

  1.  Introduction

     This document describes a logical, informational DTN management
     architecture (DTNMA) suitable for operating devices in a challenged
     architecture - such as those communicating using the DTN Bundle
     Protocol (BPv7) [RFC9171].

     Challenged networks have certain properties that differentiate them
     from other kinds of networks.  These properties, outlined in
     Section 2.2.1 of [RFC7228], include lacking end-to-end IP



  Birrane, et al.          Expires 30 October 2024                [Page 3]


  Internet-Draft                    DTNMA                       April 2024


     connectivity, having "serious interruptions" to end-to-end
     connectivity, and exhibiting delays longer than can be tolerated by
     end-to-end synchronization mechanisms (such as TCP).

     These challenged properties can be caused by a variety of factors
     such as physical constraints (e.g., long signal propagation delays
     and frequent link disruptions), administrative policies (e.g.,
     quality-of-service prioritization, service-level agreements, and
     traffic management and scheduling), and off-nominal behaviors (e.g.,
     active attackers and misconfigurations).  Since these challenges are
     not solely caused by sparseness, instances of challenged networks
     will persist even in increasingly connected environments.

     The Delay-Tolerant Networking (DTN) architecture, described in
     [RFC4838], has been designed for data exchange in challenged
     networks.  Just as the DTN architecture requires new capabilities for
     transport and transport security, special consideration is needed for
     the operation of devices in a challenged network.

  1.1.  Purpose

     This document describes how challenged network properties affect the
     operation of devices in those networks.  This description is
     presented as a logical architecture formed from a union of best
     practices for operating devices deployed in challenged environments.

     One important practice captured in this document is the concept of
     self-operation.  Self-operation involves operating a device without
     human interactivity, without system-in-the-loop synchronous function,
     and without a synchronous underlying transport layer.  This means
     that devices determine their own schedules for data reporting, their
     own operational configuration, and perform their own error discovery
     and mitigation.

  1.2.  Scope

     This document includes the information necessary to document existing
     practices for operating devices in a challenged network in the
     context of a logical architecture.  A logical architecture describes
     the logical operation of a system by identifying components of the
     system (such as in a reference model), the behaviors they enable, and
     use cases describing how those behaviors result in the desired
     operation of the system.








  Birrane, et al.          Expires 30 October 2024                [Page 4]


  Internet-Draft                    DTNMA                       April 2024


     Logical architectures are not functional architectures.  Therefore,
     any functional design for achieving desired behaviors is out of scope
     for this document.  The set of architectural principles presented
     here is not meant to completely specify interfaces between
     components.

     The selection of any particular transport or network layer is outside
     of the scope of this document.  The DTNMA does not require the use of
     any specific protocol such as IP, BP, TCP, or UDP.  In particular,
     the DTNMA design does not presume the use of BPv7, IPv4 or IPv6.

        |  NOTE: As BPv7 is the preferred transport for networks
        |  conforming to the DTN architecture, the DTNMA should be
        |  considered for any BPv7 network deployment.  However, the DTNMA
        |  may also be used in other networks that have similar needs for
        |  this particular style of self-operation.  For this reason, the
        |  DTNMA does not require the use of BPv7 to transport management
        |  information.

     Network features such as naming, addressing, routing, and
     communications security are out of scope of the DTNMA.  It is
     presumed that any operational network communicating DTNMA messages
     would implement these services for any payloads carried by that
     network.

     The interactions between and amongst the DTNMA and other management
     approaches are outside of the scope of this document.

  1.3.  Organization

     The remainder of this document is organized into the following nine
     sections, described as follows.

     Terminology:  This section identifies terms fundamental to
        understanding DTNMA concepts.  Whenever possible, these terms
        align in both word selection and meaning with their use in other
        management protocols.

     Challenged Network Overview:  This section describes important
        aspects of challenged networks and necessary approaches for their
        management.

     Desirable Design Properties:  This section defines those properties
        of the DTNMA needed to operate within the constraints of a
        challenged network.  These properties are similar to the
        specification of system-level requirements of a DTN management
        solution.




  Birrane, et al.          Expires 30 October 2024                [Page 5]


  Internet-Draft                    DTNMA                       April 2024


     Current Remote Management Approaches:  This section provides a brief
        overview of existing remote management approaches.  Where
        possible, the DTNMA adopts concepts from these approaches.

     Motivation for New Features:  This section provides an overall
        motivation for this work, to include explaining why a management
        architecture for challenged networks is useful and necessary.

     Reference Model:  This section defines a reference model that can be
        used to reason about the DTNMA independent of an implementation or
        implementation architecture.  This model identifies the logical
        components of the system and the high-level relationships and
        behaviors amongst those components.

     Desired Services:  This section identifies and defines the DTNMA
        services provided to network and mission operators.

     Logical Autonomy Model:  This section provides an exemplar data model
        that can be used to reason about DTNMA control and data flows.
        This model is based on the DTNMA reference model.

     Use Cases:  This section presents multiple use cases accommodated by
        the DTNMA architecture.  Each use case is presented as a set of
        control and data flows referencing the DTNMA reference model and
        logical autonomy model.

  2.  Terminology

     This section defines terminology that either is unique to the DTNMA
     or is necessary for understanding the concepts defined in this
     specification.

     Timely Data Exchange:  The ability to communicate information between
        two (or more) entities within a required period of time.  In some
        cases, a 1-second exchange may not be timely and in other cases
        1-hour exchange may be timely.

     Local Operation:  The operation of a device by an application co-
        resident on that device.  Local operators are applications running
        on a device, and there might be one or more of these applications
        working independently or as one to perform the local operations
        function.  Absent error conditions, local operators are always
        expected to be available to the devices they manage.

     Remote Operation:  The operation of a device by an application
        running on a separate device.  Remote operators communicate with
        operated devices over a network.  Remote operators are not always
        expected to be availabe to the devices they operate.



  Birrane, et al.          Expires 30 October 2024                [Page 6]


  Internet-Draft                    DTNMA                       April 2024


     DTN Management:  The management, monitoring, and control of a device
        that does not depend on stateful connections, timely data exchange
        of management messages, or system-in-the-loop synchronous
        functions.  DTN management is accomplished as a fusion of local
        operation and remote operation techniques; remote operators manage
        the configuration of local operators who provide monitoring and
        control of their co-resident devices.

     DTNMA Agent (DA):  A role associated with a managed device,
        responsible for reporting performance data, accepting policy
        directives, performing autonomous local control, error-handling,
        and data validation.  DAs exchange information with DMs operating
        either on the same device and/or on remote devices in the network.
        A DA is a type of local operator.

     DTNMA Manager (DM):  A role associated with a managing device
        responsible for configuring the behavior of, and eventually
        receiving information from, DAs.  DMs interact with one or more
        DAs located on the same device and/or on remote devices in the
        network.  A DM is a type of remote operator.

     Controls:  Procedures run by a DA to change the behavior,
        configuration, or state of an application or protocol managed by
        that DA.  This includes procedures to manage the DA itself, such
        as to have the DA produce performance reports or to apply new
        management policies.

     Externally Defined Data (EDD):  Typed information made available to a
        DA by its hosting device, but not computed directly by the DA
        itself.

     Data Reports:  Typed, ordered collections of data values gathered by
        one or more DAs and provided to one or more DMs.  Reports comply
        to the format of a given Data Report Schema.

     Data Report Schemas:  Named, ordered collection of data elements that
        represent the schema of a Data Report.

     Rules:  Unit of autonomous specification that provides a stimulus-
        response relationship between time or state on a DA and the
        actions or operations to be run as a result of that time or state.










  Birrane, et al.          Expires 30 October 2024                [Page 7]


  Internet-Draft                    DTNMA                       April 2024


  3.  Challenged Network Overview

     The DTNMA provides network management services able to operate in a
     challenged network environment, such as envisioned by the DTN
     architecture.  This section describes what is meant by the term
     "challenged network", the important properties of such a network, and
     observations on impacts to management approaches.

  3.1.  Challenged Network Constraints

     Constrained networks are defined as networks where "some of the
     characteristics pretty much taken for granted with link layers in
     common use in the Internet at the time of writing are not
     attainable."  [RFC7228].  This broad definition captures a variety of
     potential issues relating to physical, technical, and regulatory
     constraints on message transmission.  Constrained networks typically
     include nodes that regularly reboot or are otherwise turned off for
     long periods of time, transmit at low or asynchronous bitrates, and/
     or have very limited computational resources.

     Separately, a challenged network is defined as one that "has serious
     trouble maintaining what an application would today expect of the
     end-to-end IP model" [RFC7228].  Links in such networks may be
     impacted by attenuation, propagation delays, mobility, occultation,
     and other limitations imposed by energy and mass considerations.
     Therefore, systems relying on such links cannot guarantee timely end-
     to-end data exchange.

        |  NOTE: Because challenged networks might not provide services
        |  expected of the end-to-end IP model, devices in such networks
        |  might not implement networking stacks associated with the end-
        |  to-end IP model.  This means that devices might not include
        |  support for certain transport protocols (TCP/QUIC/UDP), web
        |  protocols (HTTP), or internetworking protocols (IPv4/IPv6).

     By these definitions, a "challenged" network is a special type of
     "constrained" network, where constraints prevent timely end-to-end
     data exchange.  As such, "all challenged networks are constrained
     networks ... but not all constrained networks are challenged networks
     ...  Delay-Tolerant Networking (DTN) has been designed to cope with
     challenged networks" [RFC7228].

     Solutions that work in constrained networks might not be solutions
     that work in challenged networks.  In particular, challenged networks
     exhibit the following properties that impact the way in which the
     function of network management is considered.





  Birrane, et al.          Expires 30 October 2024                [Page 8]


  Internet-Draft                    DTNMA                       April 2024


     *  Timely end-to-end data exchange cannot be guaranteed to exist at
        any given time between any two nodes.

     *  Latencies on the order of seconds, hours, or days must be
        tolerated.

     *  Managed devices cannot be guaranteed to always be powered so as to
        receive ad-hoc management requests (even requests with
        artificially extended timeout values).

     *  Individual links may be uni-directional.

     *  Bi-directional links may have asymmetric data rates.

     *  The existence of external infrastructure, services, systems, or
        processes such as a Domain Name Service (DNS) or a Certificate
        Authority (CA) cannot be guaranteed.

  3.2.  Topology and Service Implications

     The set of constraints that might be present in a challenged network
     impact both the topology of the network and the services active
     within that network.

     Operational networks handle cases where nodes join and leave the
     network over time.  These topology changes may or may not be planned,
     they may or may not represent errors, and they may or may not impact
     network services.  Challenged networks differ from other networks not
     in the presence of topological change, but in the likelihood that
     impacts to topology result in impacts to network services.

     The difference between topology impacts and service impacts can be
     expressed in terms of connectivity.  Topological connectivity usually
     refers to the existence of a path between an application message
     source and destination.  Service connectivity, alternatively, refers
     to the existence of a path between a node and one or more services
     needed to process (often just-in-time) application messaging.
     Examples of service connectivity include access to infrastructure
     services such as a Domain Name System (DNS) or a Certificate
     Authority (CA).











  Birrane, et al.          Expires 30 October 2024                [Page 9]


  Internet-Draft                    DTNMA                       April 2024


     In networks that might be partitioned most of the time, it is less
     likely that a node would concurrently access both an application
     endpoint and one or more network service endpoints.  For this reason,
     network services in a challenged network should be designed to allow
     for asynchronous operation.  Accommodating this use case often
     involves the use of local caching, pre-placing information, and not
     hard-coding message information at a source that might change when a
     message reaches its destination.

        |  NOTE: One example of rethinking services in a challenged
        |  network is the securing of BPv7 bundles.  The BPSec [RFC9172]
        |  security extensions to BPv7 do not encode security destinations
        |  when applying security.  Instead, BPSec requires nodes in a
        |  network to identify themselves as security verifiers or
        |  acceptors when receiving and processing secured messages.

  3.2.1.  Tiered Management

     Network operations and management approaches need to adapt to the
     topology and service impacts encountered in challenged networks.  In
     particular, the roles and responsibilities of "managers" and "agents"
     need to be different than what would be expected of unchallenged
     networks.

     When connectivity to a manager cannot be guaranteed, agents will need
     to rely on locally available information and local autonomy to react
     to changes at the node.  When an agent uses local autonomy for self-
     operation, it acts as a local operator serving as a proxy for an
     absent remote operator.

     Therefore, the role of a "manager" must become one of a remote
     operator generating configurations and other essential updates for
     the local operator "agents" that are co-resident on a managed device.

     This approach creates a two-tiered management architecture.  The
     first tier is the management of the local operator configuration
     using any one of a variety of standard mechanisms, models, and
     protocols.  The second tier is the operation of the local device
     through the local operator.

     The DTNMA defines the DTNMA Manager (DM) as a remote operator
     application and the DTNMA Agent (DA) as an agent acting as a local
     operator application.  In this model, which is illustrated in
     Figure 1, the DM and DA can be viewed as applications with the DM
     producing new configurations and the DA receiving those
     configurations from an underlying management mechanism.

     Two-Tiered Management Architecture



  Birrane, et al.          Expires 30 October 2024               [Page 10]


  Internet-Draft                    DTNMA                       April 2024


            _
           /
          / +------------+           +-----------+    Local    +---------+
    TIER /  | DM (Remote |           | DA (Local |  Operation  | Managed |
     2   \  |  Operator) |           | Operator) | <---------> |   Apps  |
    MGMT  \ +------------+           +-----------+             +---------+
           \_      ^                        ^
                   | configs                | configs
            _      |                        |
           /       V                        V
          / +------------+    Remote    +------------+
    TIER /  | Management |  Management  | Management |
     1   \  |   Client   | <----------> |   Server   |
    MGMT  \ +------------+              +------------+
           \_

                                   Figure 1

     In this approach, the configurations produced by the DM are based on
     the DA features and associated data model.  How those configurations
     are transported between the DM and the DA, and how results are
     communicated back from the DA to the DM, can be accomplished using
     whatever mechanism is most appropriate for the network and the device
     platforms.  For example, the use of a NETCONF, RESTCONF, or SNMP
     server on the managed device to provide configurations to a DA.

  3.2.2.  Remote and Local Manager Associations

     In addition to disconnectivity, topological change can alter the
     associations amongst managed and managing devices.  Different
     managing devices might be active in a network at different times or
     in different partitions.  Managed devices might communicate with
     some, all, or none of these managing devices as a function of their
     own local configuration and policy.

        |  NOTE: These concepts relate to practices in conventional
        |  networks.  For example, supporting multiple managing devices is
        |  similar to deploying multiple instances of a network service --
        |  such as a DNS server or CA node.  Selecting from a set of
        |  managing devices is similar to a sensor node practice of
        |  electing cluster heads to act as privileged nodes for data
        |  storage and exfiltration.

     Therefore, a network management architecture for challenged networks
     should:

     1.  Support a many-to-many association amongst managing and managed
         devices, and



  Birrane, et al.          Expires 30 October 2024               [Page 11]


  Internet-Draft                    DTNMA                       April 2024


     2.  Allow "control from" and "reporting to" managing devices to
         function independent of one another.

  3.3.  Management Special Cases

     The following special cases illustrate some of the operational
     situations that can be encountered in the management of devices in a
     challenged network.

     One-Way Management:  A managed device can only be accessed via a uni-
        directional link, or a via a link whose duration is shorter than a
        single round-trip propagation time.  Results of this management
        may come back at a different time, over a different path, and/or
        as observable from out-of-band changes to device behavior.

     Summary Data:  A managing device might only receive summary data of a
        managed device's state because a link or path is constrained by
        capacity or reliability.

     Bulk Historical Reporting:  A managing device receives a large volume
        of historical report data for a managed device.  This can occur
        when a managed device rejoins a network or has temporary access to
        a high capacity link (or path) to the managed device.

     Multiple Managers  A managed device tracks multiple managers in the
        network and communicates with them as a function of time, local
        state, or network topology.  This includes challenged networks
        that interconnect two or more unchallenged networks such that
        managed and managing devices exist in different networks.

     These special cases highlight the need for managed devices to operate
     without presupposing a dedicated connection to a single managing
     device.  Managing devices in a challenged network might never expect
     a reply to a command, and communications from managed devices may be
     delivered much later than the events being reported.

  4.  Desirable Design Properties

     This section describes those design properties that are desirable
     when defining a management architecture operating across challenged
     links in a network.  These properties ensure that network management
     capabilities are retained even as delays and disruptions in the
     network scale.  Ultimately, these properties are the driving design
     principles for the DTNMA.

        |  NOTE: These properties may influence the design, construction,
        |  and adaptation of existing management tools for use in
        |  challenged networks.  For example, the properties of the DTN



  Birrane, et al.          Expires 30 October 2024               [Page 12]


  Internet-Draft                    DTNMA                       April 2024


        |  architecture [RFC4838] resulted in the development of BPv7
        |  [RFC9171] and BPSec [RFC9172].  The DTNMA may result in the
        |  construction of new management data models, policy expressions,
        |  and/or protocols.

  4.1.  Dynamic Architectures

     The DTNMA should be agnostic of the underlying physical topology,
     transport protocols, security solutions, and supporting
     infrastructure of a given network.  Due to the likelihood of
     operating in a frequently partitioned environment, the topology of a
     network may change over time.  Attempts to stabilize an architecture
     around individual nodes can result in a brittle management framework
     and the creation of congestion points during periods of connectivity.

     The DTNMA should not prescribe any association between a DM and a DA
     other than those defined in this document.  There should be no
     logical limitation to the number of DMs that can control a DA, the
     number of DMs that a DA should report to, or any requirement that a
     DM and DA relationship implies a pair.

        |  NOTE: Practical limitations on the relationships between and
        |  amongst DMs and DAs will exist as a function of the
        |  capabilities of networked devices.  These limitations derive
        |  from processing and storage constraints, performance
        |  requirements, and other engineering factors.  While this
        |  information is vital to the proper engineering of a managed and
        |  managing device, they are implementation considerations, and
        |  not otherwise design constraints on the DTNMA.

  4.2.  Hierarchically Modeled Information

     The DTNMA should use data models to define the syntactic and semantic
     contracts for data exchange between a DA and a DM.  A given model
     should have the ability to "inherit" the contents of other models to
     form hierarchical data relationships.

        |  NOTE: The term data model in this context refers to a schema
        |  that defines a contract between a DA and a DM for how
        |  information is represented and validated.

     Many network management solutions use data models to specify the
     semantic and syntactic representation of data exchanged between
     managed and managing devices.  The DTNMA is not different in this
     regard - information exchanged between DAs and DMs should conform to
     one or more pre-defined, normative data models.





  Birrane, et al.          Expires 30 October 2024               [Page 13]


  Internet-Draft                    DTNMA                       April 2024


     A common best practice when defining a data model is to make it
     cohesive.  A cohesive model is one that includes information related
     to a single purpose such as managing a single application or
     protocol.  When applying this practice, it is not uncommon to develop
     a large number of small data models that, together, describe the
     information needed to manage a device.

     Another best practice for data model development is the use of
     inclusion mechanisms to allow one data model to include information
     from another data model.  This ability to include a data model avoids
     repeating information in different data models.  When one data model
     includes information from another data model, there is an implied
     model hierarchy.

     Data models in the DTNMA should allow for the construction of both
     cohesive models and hierarchically related models.  These data models
     should be used to define all sources of information that can be
     retrieved, configured, or executed in the DTNMA.  This includes
     supporting DA autonomy functions such as parameterization, filtering,
     and event driven behaviors.  These models will be used to both
     implement interoperable autonomy engines on DAs and define
     interoperable report parsing mechanisms on DMs.

        |  NOTE: While data model hierarchies can result in a more concise
        |  data model, arbitrarily complex nesting schemes can also result
        |  in very verbose encodings.  Where possible, data identification
        |  schemes should be constructed that allow for both hierarchical
        |  data and highly compressible data identification.

  4.3.  Adaptive Push of Information

     DAs in the DTNMA architecture should determine when to push
     information to DMs as a function of their local state.

     Pull management mechanisms require a managing device to send a query
     to a managed device and then wait for a response to that specific
     query.  This practice implies some knowledge synchronization between
     entities (which may be as simple as knowing when a managed device
     might be powered).  However, challenged networks cannot guarantee
     timely round-trip data exchange.  For this reason, pull mechanisms
     should be avoided in the DTNMA.

     Push mechanisms, in this context, refer to the ability of DAs to
     leverage local autonomy to determine when and what information should
     be sent to which DMs.  The push is considered adaptive because a DA
     determines what information to push (and when) as an adaptation to
     changes to the DA's internal state.  Once pushed, information might
     still be queued pending connectivity of the DA to the network.



  Birrane, et al.          Expires 30 October 2024               [Page 14]


  Internet-Draft                    DTNMA                       April 2024


        |  NOTE: Even in cases where a round-trip exchange can occur, pull
        |  mechanisms increase the overall amount of traffic in the
        |  network and preclude the use of autonomy at managed devices.
        |  So even when pull mechanisms are feasible they should not be
        |  considered a pragmatic alternative to push mechanisms.

  4.4.  Efficient Data Encoding

     Messages exchanged between a DA and a DM in the DTNMA should be
     defined in a way that allows for efficient on-the-wire encoding.
     DTNMA design decisions that result in smaller message sizes should be
     preferred over those that result in larger message sizes.

     There is a relationship between message encoding and message
     processing time at a node.  Messages with little or no encodings may
     simplify node processing whereas more compact encodings may require
     additional activities to generate/parse encoded messages.  Generally,
     compressing a message takes processing time at the sender and
     decompressing a message takes processing time at a receiver.
     Therefore, there is a design tradeoff between minimizing message
     sizes and minimizing node processing.

     There is a significant advantage to smaller DTNMA message sizes in a
     challenged network.  Smaller messages require smaller periods of
     viable transmission for communication, they incur less re-
     transmission cost, and they consume less resources when persistently
     stored en-route in the network.

        |  NOTE: Naive approaches to minimizing message size through
        |  general purpose compression algorithms do not produce minimal
        |  encodings.  Data models can, and should, be designed for
        |  compact encoding from the beginning.  Design strategies for
        |  compact encodings involve using structured data, hierarchical
        |  data models, and common sub-structures within data models.
        |  These strategies allow for compressibility beyond what would
        |  otherwise be achieved by computing large hash values over
        |  generalized data structures.

  4.5.  Universal, Unique Data Identification

     Data elements within the DTNMA should be uniquely identifiable so
     that they can be individually manipulated.  Further, these
     identifiers should be universal - the identifier for a data element
     should be the same regardless of role, implementation, or network
     instance.






  Birrane, et al.          Expires 30 October 2024               [Page 15]


  Internet-Draft                    DTNMA                       April 2024


     Identification schemes that would be relative to a specific DA or
     specific system configuration might change over time and should be
     avoided.  Relying on relative identification schemes would require
     resynchronizing relative state when nodes in a challenge network
     reconnect after periods of partition.  This type of resynchronization
     should be avoided whenever possible.

        |  NOTE: Consider a common management technique for approximating
        |  an associative array lookup.  If a managed device tracks the
        |  number of bytes passed by multiple named interfaces, then the
        |  number of bytes through a specific named interface ("int_foo"),
        |  would be retrieved in the following way:
        |  
        |     1.  Query a list of ordered interface names from an agent.
        |  
        |     2.  Find the name that matches "int_foo" and infer the
        |         agent's index of "int_foo" from the ordered interface
        |         list.  In this instance, assume "int_foo" is the 4th
        |         interface in the list.
        |  
        |     3.  Query the agent (again) to now return the number of
        |         bytes passed through the 4th interface.
        |  
        |  Ignoring the inefficiency of two round-trip exchanges, this
        |  mechanism will fail if an agent implementation changes its
        |  index mapping between the first and second query.
        |  
        |  The desired data being queried, "number of bytes through
        |  int_foo" should be uniquely and universally identifiable and
        |  independent of how that data exists in any agent's custom
        |  implementation.

  4.6.  Runtime Data Definitions

     The DTNMA allows for the addition of new data elements to a data
     model as part of the runtime operation of the management system.
     These definitions may represent custom data definitions that are
     applicable only for a particular device or network.  Custom
     definitions should also be able to be removed from the system during
     runtime.

     The goal of this approach is to dynamically add or remove data
     elements to the local runtime schemas as needed - such as the
     definition of new counters, new reports, or new rules.







  Birrane, et al.          Expires 30 October 2024               [Page 16]


  Internet-Draft                    DTNMA                       April 2024


     The custom definition of new data from existing data (such as through
     data fusion, averaging, sampling, or other mechanisms) provides the
     ability to communicate desired information in as compact a form as
     possible.

        |  NOTE: A DM could, for example, define a custom data report that
        |  includes only summary information around a specific operational
        |  event or as part of specific debugging.  DAs could then produce
        |  this smaller report until it is no longer necessary, at which
        |  point the custom report could be removed from the management
        |  system.

     Custom data elements should be calculated and used both as parameters
     for DA autonomy and for more efficient reporting to DMs.  Defining
     new data elements allows for DAs to perform local data fusion and
     defining new reporting templates allows for DMs to specify desired
     formats and generally save on link capacity, storage, and processing
     time.

  4.7.  Autonomous Operation

     The management of applications by a DA should be achievable using
     only knowledge local to the DA because DAs might need to operate
     during times when they are disconnected from a DM.

     DA autonomy may be used for simple automation of predefined tasks or
     to support semi-autonomous behavior in determining when to run tasks
     and how to configure or parameterize tasks when they are run.

     Important features provided by the DA are listed below.  These
     features work together to accomplish tasks.  As such, there is
     commonality amongst their definitions and nature of their benefits.

     Stand-alone Operation:  Pre-configuration allows DAs to operate
        without regular contact with other nodes in the network.  Updates
        for configurations remain difficult in a challenged network, but
        this approach removes the requirement that a DM be in-the-loop
        during regular operations.  Preconfiguring stimuli-and-responses
        on a DA during periods of connectivity allows DAs to self-manage
        during periods of disconnectivity.

     Deterministic Behavior:  Operational systems might need to act in a
        deterministic way even in the absence of an operator in-the-loop.
        Deterministic behavior allows an out-of-contact DM to predict the
        state of a DA and to determine how a DA got into a particular
        state.

     Engine-Based Behavior:  Operational systems might not be able to



  Birrane, et al.          Expires 30 October 2024               [Page 17]


  Internet-Draft                    DTNMA                       April 2024


        deploy "mobile code" [RFC4949] solutions due to network bandwidth,
        memory or processor loading, or security concerns.  Engine-based
        approaches provide configurable behavior without incurring these
        concerns.

     Authorization and Accounting:  The DTNMA does not require a specific
        underlying transport protocol, network infrastructure, or network
        services.  Therefore, mechanisms for authorization and accounting
        need to be present in a standard way at DAs and DMs to provide
        these functions if the underlying network does not.  This is
        particularly true in cases where multiple DMs may be active
        concurrently in the network.

     To understand the contributions of these features to a common
     behavior, consider the example of a managed device coming online with
     a set of pre-installed configuration.  In this case, the device's
     stand-alone operation comes from the pre-configuration of its local
     autonomy engine.  This engine-based behavior allows the system to
     behave in a deterministic way and any new configurations will need to
     be authorized before being adopted.

     Features such as deterministic processing and engine-based behavior
     are separate from (but do not preclude the use of) other Artificial
     Intelligence (AI) and Machine Learning (ML) approaches for device
     management.

  5.  Current Remote Management Approaches

     Several remote management solutions have been developed for both
     local-area and wide-area networks.  Their capabilities range from
     simple configuration and report generation to complex modeling of
     device settings, state, and behavior.  Each of these approaches are
     successful in the domains for which they have been built, but are not
     all equally functional when deployed in a challenged network.

     This section describes some of the well-known protocols for remote
     management and contrasts their purposes with the desirable properties
     of the DTNMA.  The purpose of this comparison is to identify parts of
     existing approaches that can be adopted or adapted for use in
     challenged networks and where new capabilities should be created
     specifically for this environment.










  Birrane, et al.          Expires 30 October 2024               [Page 18]


  Internet-Draft                    DTNMA                       April 2024


  5.1.  SNMP and SMI Models

     An early and widely used example of a remote management protocol is
     the Simple Network Management Protocol (SNMP) currently at Version 3
     [RFC3410].  The SNMP utilizes a request/response model to get and set
     data values within an arbitrarily deep object hierarchy.  Objects are
     used to identify data such as host identifiers, link utilization
     metrics, error rates, and counters between application software on
     managing and managed devices [RFC3411].  Additionally, SNMP supports
     a model for unidirectional push messages, called event notifications,
     based on agent-defined triggering events.

     SNMP relies on logical sessions with predictable round-trip latency
     to support its "pull" mechanism but a single activity is likely to
     require many round-trip exchanges.  Complex management can be
     achieved, but only through careful orchestration of real-time, end-
     to-end, managing-device-generated query-and-response logic.

     There is existing work that uses the SNMP data model to support some
     low-fidelity Agent-side processing, to include the Distributed
     Management Expression MIB [RFC2982] and Definitions of Managed
     Objects for the Delegation of Management Scripts [RFC3165].  However,
     Agent autonomy is not an SNMP mechanism, so support for a local agent
     response to an initiating event is limited.  In a challenged network
     where the delay between a managing device receiving an alert and
     sending a response can be significant, SNMP is insufficient for
     autonomous event handling.

  5.1.1.  The SMI Modeling Language

     SNMP separates the representations for managed data models from
     Manager--Agent messaging, sequencing and encoding.  Each data model
     is termed a Management Information Base (MIB) [RFC3418] and uses the
     Structure of Management Information (SMI) modeling language
     [RFC2578].  Additionally, the SMI itself is based on the ASN.1 Syntax
     [ASN.1] which is used not just for SMI but for other, unrelated data
     structure specification such as the Cryptographic Message Syntax
     (CMS) [RFC5652].  Separating data models from messaging and encoding
     is a best practice in remote management protocols and is also
     necessary for the DTNMA.

     Each SNMP MIB is composed of managed object definitions each of which
     is associated with a hierarchical Object Identifier (OID).  Because
     of the arbitrarily deep nature of MIB object trees, the size of OIDs
     is not strictly bounded by the protocol (though may be bounded by
     implementations).





  Birrane, et al.          Expires 30 October 2024               [Page 19]


  Internet-Draft                    DTNMA                       April 2024


  5.1.2.  SNMP Protocol and Transport

     The SNMP protocol itself, which is at version 2 [RFC3416], can
     operate over a variety of transports, including plaintext UDP/IP
     [RFC3417], SSH/TCP/IP [RFC5592], and DTLS/UDP/IP or TLS/TCP/IP
     [RFC6353].

     SNMP uses an abstracted security model to provide authentication,
     integrity, and confidentiality.  There are options for user-based
     security model (USM) of [RFC3414], which uses in-message security,
     and transport security model (TSM) [RFC5591], which relies on the
     transport to provide security functions and interfaces.

  5.2.  XML-Infoset-Based Protocols and YANG Models

     Several network management protocols, including NETCONF [RFC6241],
     RESTCONF [RFC8040], and CORECONF [I-D.ietf-core-comi], share the same
     XML information set [xml-infoset] for its hierarchical managed
     information and [XPath] expressions to identify nodes of that
     information model.  Since they share the same information model and
     the same data manipulation operations, together they will be referred
     to as "*CONF" protocols.  Each protocol, however, provides a
     different encoding of that information set and its related operation-
     specific data.

     The YANG modeling language of [RFC7950] is used to define the data
     model for these management protocols.  Currently, YANG represents the
     IETF standard for defining managed information models.

  5.2.1.  The YANG Modeling Language

     The YANG modeling language defines a syntax and modular semantics for
     organizing and accessing a device's configuration or operational
     information.  YANG allows subdividing a full managed configuration
     into separate namespaces defined by separate YANG modules.  Once a
     module is developed, it is used (directly or indirectly) on both the
     client and server to serve as a contract between the two.  A YANG
     module can be complex, describing a deeply nested and inter-related
     set of data nodes, actions, and notifications.

     Unlike the separation in Section 5.1.1 between ASN.1 syntax and
     module semantics from higher-level SMI data model semantics, YANG
     defines both a text syntax and module semantics together with data
     model semantics.

     The YANG language provides flexibility in the organization of model
     objects to the model developer.  The YANG supports a broad range of
     data types noted in [RFC6991].  YANG supports the definition of



  Birrane, et al.          Expires 30 October 2024               [Page 20]


  Internet-Draft                    DTNMA                       April 2024


     parameterized Remote Procedure Calls (RPCs) and actions to be
     executed on managed devices as well as the definition of event
     notifications within the model.

        |  Current *CONF notification logic allows a client to subscribe
        |  to the delivery of specific containers or data nodes defined in
        |  the model, either on a periodic or "on change" basis [RFC8641].
        |  These notification events can be filtered according to XPath
        |  [XPath] or subtree [RFC6241] filtering as described in
        |  Section 2.2 of [RFC8639].

     The use of YANG for data modeling necessarily comes with some side-
     effects, some of which are described here.

     Text Naming:  Data nodes, RPCs, and notifications within a YANG model
        are named by a namespace-qualified, text-based path of the module,
        sub-module, container, and any data nodes such as lists, leaf-
        lists, or leaves, without any explicit hierarchical organization
        based on data or object type.

        Existing efforts to make compressed names for YANG objects, such
        as the YANG Schema Item iDentifiers (SID) from Section 3.2 of
        [RFC9254], allow a node to be named by an globally unique integer
        value but are still relatively verbose (up to 8 bytes per item)
        and still must be translated into text form for things like
        instance identification (see below).  Additionally, when
        representing a tree of named instances the child elements can use
        differential encoding of SID integer values as "delta" integers.
        The mechanisms for assigning SIDs and the lifecycle of those SIDs
        are still in development [I-D.ietf-core-sid].

     Text Values and Built-In Types:  Because the original use of YANG
        with NETCONF was to model XML information sets, the values and
        built-in types are necessarily text based.  The JSON encoding of
        YANG data [RFC7951] allows for optimized representations of many
        built-in types, and similarly the CBOR encoding [RFC9254] allows
        for different optimized representations.

        In particular, the YANG built-in types natively support a fixed
        range of decimal fractions (Section 9.3 of [RFC7950]) but
        purposefully do not support floating point numbers.  There are
        alternatives, such as the type bandwidth-ieee-float32 from
        [RFC8294] or using the "binary" type with one of the IEEE-754
        encodings.

     Deep Hierarchy:  YANG allows for, and current YANG modules take





  Birrane, et al.          Expires 30 October 2024               [Page 21]


  Internet-Draft                    DTNMA                       April 2024


        advantage of, the ability to deeply nest a model hierarchy to
        represent complex combinations and compositions of data nodes.
        When a model uses a deep hierarchy of nodes this necessarily means
        that the qualified paths to name those nodes and instances is
        longer than a flat hierarchy would be.

     Instance Identification:  The node instances in a YANG module
        necessarily use XPath expressions for identification.  Some
        identification is constrained to be strictly within the YANG
        domain, such as "must" "when", "augment", or "deviation"
        statements.  Other identification needs to be processed by a
        managed device, such as in "instance-identifier" built-in type.
        This means any implementation of a managed device must include
        XPath processing and related information model handling of
        Section 6.4 of [RFC7950] and its referenced documents.

     Protocol Coupling:  A significant amount of existing YANG tooling or
        modeling presumes the use of YANG data within a management
        protocol with specific operations available.  For example, the
        access control model of [RFC8341] relies on those operations
        specific to the *CONF protocols for proper behavior.

        The emergence of multiple NETCONF-derived protocols may make these
        presumptions less problematic in the future.  Work to more
        consistently identify different types of YANG modules and their
        use has been undertaken to disambiguate how YANG modules should be
        treated [RFC8199].

     Manager-Side Control:  YANG RPCs and actions execute on a managed
        device and generate an expected, structured response.  RPC
        execution is strictly limited to those issued by the manager.
        Commands are executed immediately and sequentially as they are
        received by the managed device, and there is no method to
        autonomously execute RPCs triggered by specific events or
        conditions.

     The YANG modeling language continues to evolve as new features are
     needed by adopting management protocols.

  5.2.2.  NETCONF Protocol and Transport

     NETCONF is a stateful, XML-encoding-based protocol that provides a
     syntax to retrieve, edit, copy, or delete any data nodes or exposed
     functionality on a server.  It requires that underlying transport
     protocols support long-lived, reliable, low-latency, sequenced data
     delivery sessions.  A bi-directional NETCONF session needs to be
     established before any data transfer (or notification) can occur.




  Birrane, et al.          Expires 30 October 2024               [Page 22]


  Internet-Draft                    DTNMA                       April 2024


     The XML exchanged within NETCONF messages is structured according to
     YANG modules supported by the NETCONF agent, and the data nodes
     reside within one of possibly many datastores in accordance with the
     Network Management Datastore Architecture (NMDA) of [RFC8342].

     NETCONF transports are required to provide authentication, data
     integrity, confidentiality, and replay protection.  Currently,
     NETCONF can operate over SSH/TCP/IP [RFC6242] or TLS/TCP/IP
     [RFC7589].

  5.2.3.  RESTCONF Protocol and Transport

     RESTCONF is a stateless, JSON-encoding-based protocol that provides
     the same operations as NETCONF, using the same YANG modules for
     structure and same NMDA datastores, but using RESTful exchanges over
     HTTP.  It uses HTTP-native methods to express its allowed operations:
     GET, POST, PUT, PATCH, or DELETE data nodes within a datastore.

     Although RESTCONF is a logically stateless protocol, it does rely on
     state within its transport protocol to achieve behaviors such as
     authentication and security sessions.  Because RESTCONF uses the same
     data node semantics of NETCONF, a typical activity can involve the
     use of several sequential round-trips of exchanges to first discover
     managed device state and then act upon it.

  5.2.4.  CORECONF Protocol and Transport

     CORECONF is an emerging stateless protocol built atop the Constrained
     Application Protocol (CoAP) [RFC7252] that defines a messaging
     construct developed to operate specifically on constrained devices
     and networks by limiting message size and fragmentation.  CoAP also
     implements a request/response system and methods for GET, POST, PUT,
     and DELETE.

  5.3.  gRPC Network Management Interface (gNMI)

     Another emerging but not-IETF-affiliated management protocol is the
     gRPC Network Management Interface (gNMI) [gNMI] which is based on
     gRPC messaging and uses Protobuf data modeling.

     The same limitations of RESTCONF listed above apply to gNMI because
     of its reliance on synchronous HTTP exchanges and TLS security for
     normal operations, as well as the likely deep nesting of data
     schemas.  There is a capability for gNMI to transport JSON-encoded
     YANG-modeled data, but this composing is not fully standardized and
     relies on specific tool integrations to operate.





  Birrane, et al.          Expires 30 October 2024               [Page 23]


  Internet-Draft                    DTNMA                       April 2024


  5.3.1.  The Protobuf Modeling Language

     The data managed and exchanged via gNMI is encoded and modeled using
     Google Protobuf, an encoding and modeling syntax not affiliated with
     the IETF (although an attempt has been made and abandoned
     [I-D.rfernando-protocol-buffers]).

     Because the Protobuf modeling syntax is relatively low-level (around
     the same as ASN.1 or CBOR), there are some efforts as part of the
     OpenConfig work [gNMI] to translate YANG modules into Protobuf
     schemas (similar to translation to XML or JSON schemas for NETCONF
     and RESTCONF respectively) but there is no required interoperabilty
     between management via gRPC or any of the *CONF protocols.

  5.3.2.  gRPC Protocol and Transport

     The message encoding and exchange for gNMI, as the name implies, is
     gRPC protocol [gRPC]. gRPC exclusively uses HTTP/2 [RFC9113] for
     transport and relies on some aspects specific to HTTP/2 for its
     operations (such as HTTP trailer fields).  While not mandated by
     gRPC, when used to transport gNMI data TLS is required for transport
     security.

  5.4.  Intelligent Platform Management Interface (IPMI)

     A lower-level remote management protocol, intended to be used to
     manage hardware devices and network appliances below the operating
     system (OS), is the Intelligent Platform Management Interface (IPMI)
     standardized in [IPMI].  The IPMI is focused on health monitoring,
     event logging, firmware management, and serial-over-LAN (SOL) remote
     console access in a "pre-OS or OS-absent" host environment.  The IPMI
     operates over a companion Remote Management Control Protocol (RMCP)
     for messaging, which itself can use UDP for transport.

     Because the IPMI and RCMP are tailored to low-level and well-
     connected devices within a datacenter, with typical workflows
     requiring many messaging round trips or low-latency interactive
     sessions, they are not suitable for operation over a challenged
     network.

  5.5.  Autonomic Networking

     The future of network operations requires more autonomous behavior
     including self-configuration, self-management, self-healing, and
     self-optimization.  One approach to support this is termed Autonomic
     Networking [RFC7575].





  Birrane, et al.          Expires 30 October 2024               [Page 24]


  Internet-Draft                    DTNMA                       April 2024


     There is a large and growing set of work within the IETF focused on
     developing an Autonomic Networking Integrated Model and Approach
     (ANIMA).  The ANIMA work has developed a comprehensive reference
     model for distributing autonomic functions across multiple nodes in
     an autonomic networking infrastructure [RFC8993].

     This work, focused on learning the behavior of distributed systems to
     predict future events, is an emerging network management capability.
     This includes the development of signalling protocols such as GRASP
     [RFC8990] and the autonomic control plane (ACP) [RFC8368].

     Both autonomic and challenged networks require similar degrees of
     autonomy.  However, challenged networks cannot provide the complex
     coordination between nodes and distributed supporting infrastructure
     necessary for the frequent data exchanges for negotiation, learning,
     and bootstrapping associated with the above capabilities.

     There is some emerging work in ANIMA as to how disconnected devices
     might join and leave the autonomic control plane over time.  However,
     this work is addressing a different problem than that encountered by
     challenged networks.

  5.6.  Deep Space Autonomy

     Outside of the terrestrial networking community, there are existing
     and established remote management systems used for deep space mission
     operations.  Examples of two of these are for the New Horizons
     mission to Pluto [NEW-HORIZONS] and the DART mission to the asteroid
     Dimorphos [DART].

     The DTNMA has some heritage in the concepts of deep space autonomy,
     but each of those mission instantiations use mission-specific data
     encoding, messaging, and transport as well as mission-specific (or
     heavily mission-tailored) modeling concepts and languages.  Part of
     the goal of the DTNMA is to take the proven concepts from these
     missions and standardize a messaging syntax as well as a modular data
     modeling method.

  6.  Motivation for New Features

     Management mechanisms that provide the complete set of DTNMA
     desirable properties do not currently exist.  This is not surprising
     since autonomous management in the context of a challenged networking
     environment is a new and emerging use case.

     In particular, a management architecture is needed that integrates
     the following motivating features.




  Birrane, et al.          Expires 30 October 2024               [Page 25]


  Internet-Draft                    DTNMA                       April 2024


     Open Loop Control:  Freedom from a request-response architecture,
        API, or other presumption of timely round-trip communications.
        This is particularly important when managing networks that are not
        built over an HTTP or TCP/TLS infrastructure.

     Standard Autonomy Model:  An autonomy model that allows for standard
        expressions of policy to guarantee deterministic behavior across
        devices and vendor implementations.

     Compressible Model Structure:  A data model that allows for very
        compact encodings by defining and exploiting common structures for
        data schemas.

     Combining these new features with existing mechanisms for message
     data exchange (such as BP), data representations (such as CBOR) and
     data modeling languages (such as YANG) will form a pragmatic approach
     to defining challenged network management.

  7.  Reference Model

     This section describes a reference model for reasoning about network
     management concepts for challenged networks (generally) and those
     conforming to the DTN architecture (in particular).  The goal of this
     section is to describe how DTNMA services provide DTNMA desirable
     properties.

  7.1.  Important Concepts

     Similar to other network management architectures, the DTNMA draws a
     logical distinction between a managed device and a managing device.
     Managed devices use a DA to manage resident applications.  Managing
     devices use a DM to both monitor and control DAs.

        |  NOTE: The terms "managing" and "managed" represent logical
        |  characteristics of a device and are not, themselves, mutually
        |  exclusive.  For example, a managed device might, itself, also
        |  manage some other device in the network.  Therefore, a device
        |  may support either or both of these characteristics.

     The DTNMA differs from some other management architectures in three
     significant ways, all related to the need for a device to self-manage
     when disconnected from a managing device.

     Pre-shared Definitions:  Managing and managed devices should operate
        using pre-shared data definitions and models.  This implies that
        static definitions should be standardized whenever possible and
        that managing and managed devices may need to negotiate
        definitions during periods of connectivity.



  Birrane, et al.          Expires 30 October 2024               [Page 26]


  Internet-Draft                    DTNMA                       April 2024


     Agent Self-Management:  A managed device may find itself disconnected
        from its managing device.  In many challenged networking
        scenarios, a managed device may spend the majority of its time
        without a regular connection to a managing device.  In these
        cases, DAs manage themselves by applying pre-shared policies
        received from managing devices.

     Command-Based Interface:  Managing devices communicate with managed
        devices through a command-based interface.  Instead of exchanging
        variables, objects, or documents, a managing device issues
        commands to be run by a managed device.  These commands may create
        or update variables, change data stores, or impact the managed
        device in ways similar to other network management approaches.
        The use of commands is, in part, driven by the need for DAs to
        receive updates from both remote management devices and local
        autonomy.  The use of controls for the implementation of commands
        is discussed in more detail in Section 9.5.

  7.2.  Model Overview

     A DTNMA reference model is provided in Figure 2 below.  In this
     reference model, applications and services on a managing device
     communicate with a DM which uses pre-shared definitions to create a
     set of policy directives that can be sent to a managed device's DA
     via a command-based interface.  The DA provides local monitoring and
     control (commanding) of the applications and services resident on the
     managed device.  The DA also performs local data fusion as necessary
     to synthesize data products (such as reports) that can be sent back
     to the DM when appropriate.

     DTNMA Reference Model




















  Birrane, et al.          Expires 30 October 2024               [Page 27]


  Internet-Draft                    DTNMA                       April 2024


         Managed Device                            Managing Device
  +----------------------------+           +-----------------------------+
  | +------------------------+ |           | +-------------------------+ |
  | |Applications & Services | |           | | Applications & Services | |
  | +----------^-------------+ |           | +-----------^-------------+ |
  |            |               |           |             |               |
  | +----------v-------------+ |           | +-----------v-------------+ |
  | | DTNMA  +-------------+ | |           | | +-----------+   DTNMA   | |
  | | AGENT  | Monitor and | | |Commanding | | |  Policy   |  MANAGER  | |
  | |        |   Control   | | |<==========| | | Encoding  |           | |
  | | +------+-------------+ | |           | | +-----------+-------+   | |
  | | |Admin | Data Fusion | | |==========>| | | Reporting | Admin |   | |
  | | +------+-------------+ | | Reporting | | +-----------+-------+   | |
  | +------------------------+ |           | +-------------------------+ |
  +----------------------------+           +-----------------------------+
             ^                                             ^
             |            Pre-Shared Definitions           |
             |        +---------------------------+        |
             +--------| - Autonomy Model          |--------+
                      | - Application Data Models |
                      | - Runtime Data Stores     |
                      +---------------------------+

                                 Figure 2

     This model preserves the familiar concept of "managers" resident on
     managing devices and "agents" resident on managed devices.  However,
     the DTNMA model is unique in how the DM and DA operate.  The DM is
     used to pre-configure DAs in the network with management policies.
     it is expected that the DAs, themselves, perform monitoring and
     control functions on their own.  In this way, a properly configured
     DA may operate without a reliable connection back to a DM.

  7.3.  Functional Elements

     The reference model illustrated in Figure 2 implies the existence of
     certain logical components whose roles and responsibilities are
     discussed in this section.

  7.3.1.  Managed Applications and Services

     By definition, managed applications and services reside on a managed
     device.  These software entities can be controlled through some
     interface by the DA and their state can be sampled as part of
     periodic monitoring.  It is presumed that the DA on the managed
     device has the proper data model, control interface, and permissions
     to alter the configuration and behavior of these software
     applications.



  Birrane, et al.          Expires 30 October 2024               [Page 28]


  Internet-Draft                    DTNMA                       April 2024


  7.3.2.  DTNMA Agent (DA)

     A DA resides on a managed device.  As is the case with other network
     management approaches, this agent is responsible for the monitoring
     and control of the applications local to that device.  Unlike other
     network management approaches, the agent accomplishes this task
     without a regular connection to a DTNMA Manager.

     The DA performs three major functions on a managed device: the
     monitoring and control of local applications, production of data
     analytics, and the administrative control of the agent itself.

  7.3.2.1.  Monitoring and Control

     DAs monitor the status of applications running on their managed
     device and selectively control those applications as a function of
     that monitoring.  The following components are used to perform
     monitoring and control on an agent.

     Rules Database:
             Each DA maintains a database of policy expressions that form
             rules of behavior of the managed device.  Within this
             database, each rule of behavior is a tuple of a stimulus and
             a response.  Within the DTNMA, these rules are the embodiment
             of policy expressions received from DMs and evaluated at
             regular intervals by the autonomy engine.  The rules database
             is the collection of active rules known to the DA.

     Autonomy Engine:
             The DA autonomy engine monitors the state of the managed
             device looking for pre-defined stimuli and, when encountered,
             issuing a pre-defined response.  To the extent that this
             function is driven by the rules database, this engine acts as
             a policy execution engine.  This engine may also be directly
             configured by managers during periods of connectivity for
             actions separate from those in the rules database (such as
             enabling or disabling sets of rules).  Once configured, the
             engine may function without other access to any managing
             device.  This engine may also reconfigure itself as a
             function of policy.

     Application Control Interfaces:
             DAs support control interfaces for all managed applications.
             Control interfaces are used to alter the configuration and
             behavior of an application.  These interfaces may be custom
             for each application, or as provided through a common
             framework such as provided by an operating system.




  Birrane, et al.          Expires 30 October 2024               [Page 29]


  Internet-Draft                    DTNMA                       April 2024


  7.3.2.2.  Data Fusion

     DAs generate new data elements as a function of the current state of
     the managed device and its applications.  These new data products may
     take the form of individual data values, or new collections of data
     used for reporting.  The logical components responsible for these
     behaviors are as follows.

     Application Data Interfaces:
             DAs support mechanisms by which important state is retrieved
             from various applications resident on the managed device.
             These data interfaces may be custom for each application, or
             as provided through a common framework such as provided by an
             operating system.

     Data Value Generators:
             DAs may support the generation of new data values as a
             function of other values collected from the managed device.
             These data generators may be configured with descriptions of
             data values and the data values they generate may be included
             in the overall monitoring and reporting associated with the
             managed device.

     Report Generators:
             DAs may, as appropriate, generate collections of data values
             and provide them to whatever local mechanism takes
             responsibility for their eventual transmission (or expiration
             and removal).  Reports can be generated as a matter of policy
             or in response to the handling of critical events (such as
             errors), or other logging needs.  The generation of a report
             is independent of whether there exists any connectivity
             between a DA and a DM.

  7.3.2.3.  Administration

     DAs perform a variety of administrative services in support of their
     configuration, such as the following.

     Manager Mapping:
             The DTNMA allows for a many-to-many relationship amongst
             DTNMA Agents and Managers.  A single DM may configure
             multiple DAs, and a single DA may be configured by multiple
             DMs.  Multiple managers may exist in a network for at least
             two reasons.  First, different managers may exist to control
             different applications on a device.  Second, multiple
             managers increase the likelihood of an agent encountering a
             manager when operating in a sparse or challenged environment.




  Birrane, et al.          Expires 30 October 2024               [Page 30]


  Internet-Draft                    DTNMA                       April 2024


             While the need for multiple managers is required for
             operating in a dynamically partitioned network, this
             situation allows for the possibility of conflicting
             information from different managers.  Implementations of the
             DTNMA should consider conflict resolution mechanisms.  Such
             mechanisms might include analyzing managed content, time,
             agent location, or other relevant information to select one
             manager input over other manager inputs.

     Data Verifiers:
             DAs might handle large amounts of data produced by various
             sources, to include data from local managed applications,
             remote managers, and self-calculated values.  DAs should
             ensure, when possible, that externally generated data values
             have the proper syntax and semantic constraints (e.g., data
             type and ranges) and any required authorization.

     Access Controllers:
             DAs support authorized access to the management of individual
             applications, to include the administrative management of the
             agent itself.  This means that a manager may only set policy
             on the agent pursuant to verifying that the manager is
             authorized to do so.

  7.3.3.  Managing Applications and Services

     Managing applications and services reside on a managing device and
     serve as the both the source of DA policy statements and the target
     of DA reporting.  They may operate with or without an operator in the
     loop.

     Unlike management applications in unchallenged networks, these
     applications cannot exert closed-loop control over any managed device
     application.  Instead, they exercise open-loop control by producing
     policies that can be configured and enforced on managed devices by
     DAs.

        |  NOTE: Closed-loop control in this context refers to the
        |  practice of waiting for a response from a managed device prior
        |  to issuing new commands to that device.  These "loops" may be
        |  closed quickly (in milliseconds) or over much longer periods (
        |  hours, days, years).  The alternative to closed-loop control is
        |  open-loop control, where the issuance of new commands is not
        |  dependent on receiving responses to previous commands.
        |  Additionally, there might not be a 1-1 mapping between commands
        |  and responses.  A DA may, for example, produce a single
        |  response that captures the end state from applying multiple
        |  commands.



  Birrane, et al.          Expires 30 October 2024               [Page 31]


  Internet-Draft                    DTNMA                       April 2024


  7.3.4.  DTNMA Manager (DM)

     A DM resides on a managing device.  This manager provides an
     interface between various managing applications and services and the
     DAs that enforce their policies.  In providing this interface, DMs
     translate between whatever native interface exists to various
     managing applications and the autonomy models used to encode
     management policy.

     The DM performs three major functions on a managing device: policy
     encoding, reporting, and administration.

  7.3.4.1.  Policy Encoding

     DMs translate policy directives from managing applications and
     services into standardized policy expressions that can be recognized
     by DAs.  The following logical components are used to perform this
     policy encoding.

     Application Control Interfaces:
             DMs support control interfaces for managing applications.
             These control interfaces are used to receive desired policy
             statements from applications.  These interfaces may be custom
             for each application, or provided through a common framework,
             protocol, or operating system.

     Policy Encoders:
             DAs implement a standardized autonomy model comprising
             standardized data elements.  This allows the open-loop
             control structures provided by managing applications to be
             represented in a common language.  Policy encoders perform
             this encoding function.

     Policy Aggregators:
             DMs collect multiple encoded policies into messages that can
             be sent to DAs over the network.  This implies the proper
             addressing of agents and the creation of messages that
             support store-and-forward operations.  It is recommended that
             control messages be packaged using BP bundles when there may
             be intermittent connectivity between DMs and DAs.

  7.3.4.2.  Reporting

     DMs receive reports on the status of managed devices during periods
     of connectivity with the DAs on those devices.  The following logical
     components are needed to implement reporting capabilities on a DM.





  Birrane, et al.          Expires 30 October 2024               [Page 32]


  Internet-Draft                    DTNMA                       April 2024


     Report Collectors:
             DMs receive reports from DAs in an asynchronous manner.  This
             means that reports may be received out of chronological order
             and in ways that are difficult or impossible to associate
             with a specific policy from a managing application.  DMs
             collect these reports and extract their data in support of
             subsequent data analytics.

     Data Analyzers:
             DMs review sets of data reports from DAs with the purpose of
             extracting relevant data to communicate with managing
             applications.  This may include simple data extraction or may
             include more complex processing such as data conversion, data
             fusion, and appropriate data analytics.

     Application Data Interfaces:
             DMs support mechanisms by which data retrieved from DAs may
             be provided back to managing devices.  These interfaces may
             be custom for each application, or as provided through a
             common framework, protocol, or operating system.

  7.3.4.3.  Administration

     Managers in the DTNMA perform a variety of administrative services,
     such as the following.

     Agent Mappings:
             The DTNMA allows DMs to communicate with multiple DAs.
             However, not every agent in a network is expected to support
             the same set of Application Data Models or otherwise have the
             same set of managed applications running.  For this reason,
             DMs determine individual DA capabilities to ensure that only
             appropriate Controls are sent to a DA.

     Data Verifiers:
             DMs handle large amounts of data produced by various sources,
             to include data from managing applications and DAs.  DMs
             should ensure, when possible, that data values received from
             DAs over a network have the proper syntax and semantic
             constraints (e.g., data type and ranges) and any required
             authorization.

     Access Controllers:
             DMs should only send Controls to agents when the manager is
             configured with appropriate access to both the agent and the
             applications being managed.





  Birrane, et al.          Expires 30 October 2024               [Page 33]


  Internet-Draft                    DTNMA                       April 2024


  7.3.5.  Pre-Shared Definitions

     A consequence of operating in a challenged environment is the
     potential inability to negotiate information in real-time.  For this
     reason, the DTNMA requires that managed and managing devices operate
     using pre-shared definitions rather than relying on data definition
     negotiation.

     The three types of pre-shared definitions in the DTNMA are the DA
     autonomy model, managed application data models, and any runtime data
     shared by managers and agents.

     Autonomy Model:
             A DTNMA autonomy model represents the data elements and
             associated autonomy structures that define the behavior of
             the agent autonomy engine.  A standardized autonomy model
             allows for individual implementations of DAs, and DMs to
             interoperate.  A standardized model also provides guidance to
             the design and implementation of both managed and managing
             applications.

     Application Data Models:
             As with other network management architectures, the DTNMA
             pre-supposes that managed applications (and services) define
             their own data models.  These data models include the data
             produced by, and Controls implemented by, the application.
             These models are expected to be static for individual
             applications and standardized for applications implementing
             standard protocols.

     Runtime Data Stores:
             Runtime data stores, by definition, include data that is
             defined at runtime.  As such, the data is not pre-shared
             prior to the deployment of DMs and DAs.  Pre-sharing in this
             context means that DMs and DAs are able to define and
             synchronize data elements prior to their operational use in
             the system.  This synchronization happens during periods of
             connectivity between DMs and DAs.

  8.  Desired Services

     This section describes the services provided by DTNMA components on
     both managing and managed devices.  Many of the services discussed in
     this section attempt to provide continuous operation of a managed
     device through periods of no connectivity with a managing device.






  Birrane, et al.          Expires 30 October 2024               [Page 34]


  Internet-Draft                    DTNMA                       April 2024


  8.1.  Local Monitoring and Control

     DTNMA monitoring is associated with some DA autonomy engine.  The
     term monitoring implies regular access to information such that state
     changes may be acted upon within some response time period.

     Predicate autonomy on a managed device should collect state
     associated with the device at regular intervals and evaluate that
     collected state for any changes that require a preventative or
     corrective action.  Similarly, this monitoring may cause the device
     to generate one or more reports destined to a managing device.

     Similar to monitoring, DTNMA control results in actions by the agent
     to change the state or behavior of the managed device.  All control
     in the DTNMA is local control.  In cases where there exists a timely
     connection to a manager, received Controls are still evaluated and
     run locally as part of local autonomy.  In this case, the autonomy
     stimulus is the receipt of the Control and the response is to
     immediately run the Control.  In this way, there is never a
     dependency on a session or other stateful exchange with any remote
     entity.

  8.2.  Local Data Fusion

     DTNMA Fusion services produce new data products from existing state
     on the managed device.  These fusion products can be anything from
     simple summations of sampled counters to complex calculations of
     behavior over time.

     Fusion is an important service in the DTNMA because fusion products
     are part of the overall state of a managed device.  Complete
     knowledge of this overall state is important for the management of
     the device and the predicates of rules on a DA may refer to fused
     data.

     In-situ data fusion is an important function as it allows for the
     construction of intermediate summary data, the reduction of stored
     and transmitted raw data, possibly fewer predicates in rule
     definitions, and otherwise insulates the data source from conclusions
     drawn from that data.

     The DTNMA requires fusion to occur on the managed device itself.  If
     the network is partitioned such that no connection to a managing
     device is available, then fusion needs to happen locally.  Similarly,
     connections to a managing device might not remain active long enough
     for round-trip data exchange or may not have the bandwidth to send
     all sampled data.




  Birrane, et al.          Expires 30 October 2024               [Page 35]


  Internet-Draft                    DTNMA                       April 2024


        |  NOTE: The DTNMA does not restrict the storage and transmission
        |  of raw (pre-fused) data.  Such raw data can be useful for
        |  debugging managed devices, understanding complex interactions
        |  and underlying conditions, and tuning for better performance
        |  and/or better outcomes.

  8.3.  Remote Configuration

     DTNMA configuration services update the local configuration of a
     managed device with the intent to impact the behavior and
     capabilities of that device.

     The DTNMA configuration service is unique in that the selection of
     managed device configurations occurs as a function of the state of
     the device.  This implies that management proxies on the device store
     multiple configuration functions that can be applied as needed
     without consultation from a managing device.

        |  This approach differs from other management concepts of
        |  selecting from multiple datastores.  DTNMA configuration
        |  functions can target individual data elements and can calculate
        |  new values from local device state.

     When detecting stimuli, the agent autonomy engine supports a
     mechanism for evaluating whether application monitoring data or
     runtime data values are recent enough to indicate a change of state.
     In cases where data has not been updated recently, it may be
     considered stale and not used to reliably indicate that some stimulus
     has occurred.

  8.4.  Remote Reporting

     DTNMA reporting services collect information known to the managed
     device and prepare it for eventual transmission to one or more
     managing devices.  The contents of these reports, and the frequency
     at which they are generated, occurs as a function of the state of the
     managed device, independent of the managing device.

     Once generated, it is expected that reports might be queued pending a
     connection back to a managing device.  Therefore, reports need to be
     differentiable as a function of the time they were generated.

        |  NOTE: When reports are queued pending transmission, the overall
        |  storage capacity at the queuing device needs to be considered.
        |  There may be cases where queued reports can be considered
        |  expired either because they have been queued for too long, or
        |  because they have been replaced by a newer report.  When a
        |  report is considered expired, it may be considered for removal



  Birrane, et al.          Expires 30 October 2024               [Page 36]


  Internet-Draft                    DTNMA                       April 2024


        |  and, thus, never transmitted.  This consideration is expected
        |  to be part of the implementation of the queuing device and not
        |  the responsibility of the reporting function within the DTNMA.

     When reports are sent to a managing device over a challenged network,
     they may arrive out of order due to taking different paths through
     the network or being delayed due to retransmissions.  A managing
     device should not infer meaning from the order in which reports are
     received.

     Reports may or may not be associated with a specific Control.  Some
     reports may be annotated with the Control that caused the report to
     be generated.  Sometimes, a single report will represent the end
     state of applying multiple Controls.

  8.5.  Authorization

     Both local and remote services provided by the DTNMA affect the
     behavior of multiple applications on a managed device and may
     interface with multiple managing devices.

     Authorization services enforce the potentially complex mapping of
     other DTNMA services amongst managed and managing devices in the
     network.  For example, fine-grained access control can determine
     which managing devices receive which reports, and what Controls can
     be used to alter which managed applications.

     This is particularly beneficial in networks that either deal with
     multiple administrative entities or overlay networks that cross
     administrative boundaries.  Allowlists, blocklists, key-based
     infrastructures, or other schemes may be used for this purpose.

  9.  Logical Autonomy Model

     An important characteristic of the DTNMA is the shift in the role of
     a managing device.  One way to describe the behavior of the agent
     autonomy engine is to describe the characteristics of the autonomy
     model it implements.

     This section describes a logical autonomy model in terms of the
     abstract data elements that would comprise the model.  Defining
     abstract data elements allows for an unambiguous discussion of the
     behavior of an autonomy model without mandating a particular design,
     encoding, or transport associated with that model.







  Birrane, et al.          Expires 30 October 2024               [Page 37]


  Internet-Draft                    DTNMA                       April 2024


  9.1.  Overview

     A managing autonomy capability on a potentially disconnected device
     needs to behave in both an expressive and deterministic way.
     Expressivity allows for the model to be configured for a wide range
     of future situations.  Determinism allows for the forensic
     reconstruction of device behavior as part of debugging or recovery
     efforts.  It also is necessary to ensure predictable behavior.

        |  NOTE: The use of predicate logic and a stimulus-response system
        |  does not conflict with the use of higher-level autonomous
        |  function or the incorporation of machine learning.
        |  Specifically, the DTNMA deterministic autonomy model can
        |  coexist with other autonomous functions managing applications
        |  and network services.
        |  
        |  An example of such co-existence is the use of the DTNMA model
        |  to ensure a device stays within safe operating parameters while
        |  a less deterministic machine learning model directs smaller
        |  behaviors for the device.

     The DTNMA autonomy model is a rule-based model in which individual
     rules associate a pre-identified stimulus with a pre-configured
     response to that stimulus.

     Stimuli are identified using one or more predicate logic expressions
     that examine aspects of the state of the managed device.  Responses
     are implemented by running one or more procedures on the managed
     device.

     In its simplest form, a stimulus is a single predicate expression of
     a condition that examines some aspect of the state of the managed
     device.  When the condition is met, a predetermined response is
     applied.  This behavior can be captured using the construct:


                 IF <condition 1> THEN <response 1>;

     In more complex forms, a stimulus may include both a common condition
     shared by multiple rules and a specific condition for each individual
     rule.  If the common condition is not met, the evaluation of the
     specific condition of each rule sharing the common condition can be
     skipped.  In this way, the total number of predicate evaluations can
     be reduced.  This behavior can be captured using the construct:







  Birrane, et al.          Expires 30 October 2024               [Page 38]


  Internet-Draft                    DTNMA                       April 2024


                 IF <common condition> THEN
                   IF <specific condition 1> THEN <response 1>
                   IF <specific condition 2> THEN <response 2>
                   IF <specific condition 3> THEN <response 3>

        |  NOTE: The DTNMA model remains a stimulus-response system,
        |  regardless of whether a common condition is part of the
        |  stimulus.  However, it is recommended that implementations
        |  incorporate a common condition because of the efficiency
        |  provided by such a bulk evaluation.
        |  
        |  NOTE: One use of a stimulus "common condition" is to associated
        |  the condition with an on-board event such as the expiring of a
        |  timer or the changing of a monitored value.
        |  
        |  NOTE: The DTNMA does not prescribe when to evaluate rule
        |  stimuli.  Implementations may choose to evaluate rule stimuli
        |  at periodic intervals (such as 1Hz or 100Hz).  When stimuli
        |  include on-board events, implementations may choose to perform
        |  an immediate evaluation at the time of the event rather than
        |  waiting for a periodic evaluation.

     DTNMA Autonomy Model

    Managed Applications |           DTNMA Agent          | DTNMA Manager
   +---------------------+--------------------------------+--------------+
                         |   +---------+                  |
                         |   |  Local  |                  |   Encoded
                         |   | Rule DB |<-------------------- Policy
                         |   +---------+                  |   Expressions
                         |        ^                       |
                         |        |                       |
                         |        v                       |
                         |   +----------+    +---------+  |
       Monitoring Data------>|   Agent  |    | Runtime |  |
                         |   | Autonomy |<-->|  Data   |<---- Definitions
   Application Control<------|  Engine  |    |  Store  |  |
                         |   +----------+    +---------+  |
                         |         |                      |
                         |         +-------------------------> Reports
                         |                                |

                                  Figure 3








  Birrane, et al.          Expires 30 October 2024               [Page 39]


  Internet-Draft                    DTNMA                       April 2024


     The flow of data into and out of the agent autonomy engine is
     illustrated in Figure 3.  In this model, the autonomy engine stores
     the combination of stimulus conditions and associated responses as a
     set of "rules" in a rules database.  This database is updated through
     the execution of the autonomy engine and as configured from policy
     statements received by managers.

     Stimuli are detected by examining the state of applications as
     reported through application monitoring interfaces and through any
     locally-derived data.  Local data is calculated in accordance with
     definitions also provided by managers as part of the runtime data
     store.

     Responses to stimuli may include updates to the rules database,
     updates to the runtime data store, Controls sent to applications, and
     the generation of reports.

  9.2.  Model Characteristics

     There are several practical challenges to the implementation of a
     distributed rule-based system.  Large numbers of rules may be
     difficult to understand, deconflict, and debug.  Rules whose
     conditions are given by fused or other dynamic data may require data
     logging and reporting for deterministic offline analysis.  Rule
     differences across managed devices may lead to oscillating effects.
     This section identifies those characteristics of an autonomy model
     that might help implementations mitigate some of these challenges.

     There are a number of ways to represent data values, and many data
     modeling languages exist for this purpose.  When considering how to
     model data in the context of the DTNMA autonomy model there are some
     modeling features that should be present to enable functionality.
     There are also some modeling features that should be prevented to
     avoid ambiguity.

     Traditional network management approaches favor flexibility in their
     data models.  The DTNMA stresses deterministic behavior that supports
     forensic analysis of agent activities "after the fact".  As such, the
     following statements should be true of all data representations
     relating to DTNMA autonomy.

     Strong Typing:  The predicates and expressions that comprise the
        autonomy services in the DTNMA should require strict data typing.
        This avoids errors associated with implicit data conversions and
        helps detect misconfiguration.

     Acyclic Dependency:  Many dependencies exist in an autonomy model,




  Birrane, et al.          Expires 30 October 2024               [Page 40]


  Internet-Draft                    DTNMA                       April 2024


        particularly when combining individual expressions or results to
        create complex behaviors.  Implementations that conform to the
        DTNMA need to prevent circular dependencies.

     Fresh Data:  Autonomy models operating on data values presume that
        their data inputs represent the actionable state of the managed
        device.  If a data value has failed to be refreshed within a time
        period, autonomy might incorrectly infer an operational state.
        Regardless of whether a data value has changed, DTNMA
        implementations should provide some indicator of whether the data
        value is "fresh" meaning that it still represents the current
        state of the device.

     Pervasive Parameterization:  Where possible, autonomy model objects
        should support parameterization to allow for flexibility in the
        specification.  Parameterization allows for the definition of
        fewer unique model objects and also can support the substitution
        of local device state when exercising device control or data
        reporting.

     Configurable Cardinality:  The number of data values that can be
        supported in a given implementation is finite.  For devices
        operating in challenged environments, the number of supported
        objects may be far fewer than that which can be supported by
        devices in well-resourced environments.  DTNMA implementations
        should define limits to the number of supported objects that can
        be active in a system at one time, as a function of the resources
        available to the implementation.

     Control-Based Updates:  The agent autonomy engine changes the state
        of the managed device by running Controls on the device.  This is
        different from approaches where the behavior of a managed device
        is influenced by updating configuration values, such as in a table
        or datastore.  Altering behavior via one or more Controls allows
        checking all pre-conditions before making changes as well as
        providing more granularity in the way in which the device is
        updated.  Where necessary, Controls can be defined to perform bulk
        updates of configuration data so as not to lose that update
        modality.  One important update pre-condition is that the system
        is not performing an action that would prevent the update (such as
        currently applying a competing update).










  Birrane, et al.          Expires 30 October 2024               [Page 41]


  Internet-Draft                    DTNMA                       April 2024


  9.3.  Data Value Representation

     The expressive representation of simple data values is fundamental to
     the successful construction and evaluation of predicates in the DTNMA
     autonomy model.  When defining such values, there are useful
     distinctions regarding how values are identified and whether values
     are generated internal or external to the autonomy model.

     A DTNMA data value should combine a base type (e.g., integer, real,
     string) representation with relevant semantic information.  Base
     types are used for proper storage and encoding.  Semantic information
     allows for additional typing, constraint definitions, and mnemonic
     naming.  This expanded definition of data value allows for better
     predicate construction and evaluation and early type checking.

     Data values may further be annotated based on whether their value is
     the result of a DA calculation or the result of some external process
     on the managed device.  For example, operators may with to know which
     values can be updated by actions on the DA versus which values (such
     as sensor readings) cannot be reliably changed because they are
     calculated external to the DA.

  9.4.  Data Reporting

     The DTNMA autonomy model should, as required, report on the state of
     its managed device (to include the state of the model itself).  This
     reporting should be done as a function of the changing state of the
     managed device, independent of the connection to any managing device.
     Queuing reports allows for later forensic analysis of device
     behavior, which is a desirable property of DTNMA management.

     DTNMA data reporting consists of the production of some data report
     instance conforming to a data report schema.  The use of schemas
     allows a report instance to identify the schema to which it conforms
     instead of carrying the structure in the report itself.  This
     approach can significantly reduce the size of generated reports.

        |  NOTE: The DTNMA data reporting concept is intentionally
        |  distinct from the concept of exchanging data stores across a
        |  network.  It is envisioned that a DA might generate a data
        |  report instance of a data report schema at regular intervals or
        |  in response to local events.  In this model, many report
        |  schemas may be defined to capture unique, relevant combinations
        |  of known data values rather than sending bulk data stores off-
        |  platform for analysis.
        |  





  Birrane, et al.          Expires 30 October 2024               [Page 42]


  Internet-Draft                    DTNMA                       April 2024


        |  NOTE: It is not required that data report schemas be tabular in
        |  nature.  Individual implementations might define tabular
        |  schemas for table-like data and other report schemas for more
        |  heterogeneous reporting.

  9.5.  Command Execution

     The agent autonomy engine requires that managed devices issue
     commands on themselves as if they were otherwise being controlled by
     a managing device.  The DTNMA implements commanding through the use
     of Controls and macros.

     Controls represent parameterized, predefined procedures run by the DA
     either as directed by the DM or as part of a rule response from the
     DA autonomy engine.  Macros represent ordered sequences of Controls.

     Controls are conceptually similar to RPCs in that they represent
     parameterized functions run on the managed device.  However, they are
     conceptually dissimilar from RPCs in that they do not have a concept
     of a return code because they operate over an asynchronous transport.
     The concept of return code in an RPC implies a synchronous
     relationship between the caller of the procedure and the procedure
     being called, which might not be possible within the DTNMA.

     The success or failure of a Control may be handled locally by the
     agent autonomy engine.  Local error handling is particularly
     important in this architecture given the potential for long periods
     of disconnectivity between a DA and a DM.  The failure of one or more
     Controls is part of the state of the DA and can be used to trigger
     rules within the DA autonomy engine.

     The impact of a Control is externally observable via the generation
     and eventual examination of data reports produced by the managed
     device.

     The failure of certain Controls might leave a managed device in an
     undesired state.  Therefore, it is important that there be
     consideration for Control-specific recovery mechanisms (such as a
     rollback or safing mechanism).  When a Control that is part of a
     macro (such as in an autonomy response) fails, there may be a need to
     implement a safe state for the managed device based on the nature of
     the failure.









  Birrane, et al.          Expires 30 October 2024               [Page 43]


  Internet-Draft                    DTNMA                       April 2024


        |  NOTE: The use of the term Control in the DTNMA is derived in
        |  part from the concept of Command and Control (C2) where control
        |  implies the operational instructions undertaken to implement
        |  (or maintain) a commanded objective.  The DA autonomy engine
        |  implements controls on a managed device to allow it to fulfill
        |  some commanded objective known by a (possibly disconnected)
        |  managing device.
        |  
        |  For example, a device might be commanded to maintain a safe
        |  internal thermal environment.  Actions taken by a DA to manage
        |  heaters, louvers, and other temperature-effecting components
        |  are controls taken in service of that commanded objective.

  9.6.  Predicate Autonomy Rules

     As discussed in Section 9.1, the DTNMA rule-based stimulus-response
     system associates stimulus detection with a predetermined response.
     Rules may be categorized based on whether their stimuli include
     generic statements of managed device state or whether they are
     optimized to only consider the passage of time on the device.

     State-based rules are those whose stimulus is based on the evaluated
     state of the managed device.  Time-based rules are a unique subset of
     state-based rules whose stimulus is given only by a time-based event.
     Implementations might create different structures and evaluation
     mechanisms for these two different types of rules to achieve more
     efficient processing on a platform.

  10.  Use Cases

     Using the autonomy model defined in Section 9, this section describes
     flows through sample configurations conforming to the DTNMA.  These
     use cases illustrate remote configuration, local monitoring and
     control, multiple manager support, and data fusion.

  10.1.  Notation

     The use cases presented in this section are documented with a
     shorthand notation to describe the types of data sent between
     managers and agents.  This notation, outlined in Table 1, leverages
     the definitions of autonomy model components defined in Section 9.










  Birrane, et al.          Expires 30 October 2024               [Page 44]


  Internet-Draft                    DTNMA                       April 2024


     +==================+===================================+===========+
     |       Term       |             Definition            |  Example  |
     +==================+===================================+===========+
     |       EDD#       |  Externally Defined Data - a data |   EDD1,   |
     |                  | value defined external to the DA. |    EDD2   |
     +------------------+-----------------------------------+-----------+
     |        V#        |  Variable - a data value defined  | V1 = EDD1 |
     |                  |        internal to the DA.        |    + 7    |
     +------------------+-----------------------------------+-----------+
     |       EXPR       |   Predicate expression - used to  |   V1 > 5  |
     |                  |      define a rule stimulus.      |           |
     +------------------+-----------------------------------+-----------+
     |        ID        |      DTNMA Object Identifier.     |  V1, EDD2 |
     +------------------+-----------------------------------+-----------+
     |       ACL#       |  Enumerated Access Control List.  |    ACL1   |
     +------------------+-----------------------------------+-----------+
     | DEF(ACL,ID,EXPR) | Define ID from expression.  Allow | DEF(ACL1, |
     |                  |  managers in ACL to see this ID.  |  V1, EDD1 |
     |                  |                                   |  + EDD2)  |
     +------------------+-----------------------------------+-----------+
     |    PROD(P,ID)    | Produce ID according to predicate |  PROD(1s, |
     |                  |  P.  P may be a time period (1s)  |   EDD1)   |
     |                  |   or an expression (EDD1 > 10).   |           |
     +------------------+-----------------------------------+-----------+
     |     RPT(ID)      | A report instance containing data | RPT(EDD1) |
     |                  |             named ID.             |           |
     +------------------+-----------------------------------+-----------+

                             Table 1: Terminology

     These notations do not imply any implementation approach.  They only
     provide a succinct syntax for expressing the data flows in the use
     case diagrams in the remainder of this section.

  10.2.  Serialized Management

     This nominal configuration shows a single DM interacting with
     multiple DAs.  The control flows for this scenario are outlined in
     Figure 4.

     Serialized Management Control Flow










  Birrane, et al.          Expires 30 October 2024               [Page 45]


  Internet-Draft                    DTNMA                       April 2024


           +-----------+           +---------+           +---------+
           |   DTNMA   |           |  DTNMA  |           |  DTNMA  |
           | Manager A |           | Agent A |           | Agent B |
           +----+------+           +----+----+           +----+----+
               |                       |                     |
               |-----PROD(1s, EDD1)--->|                     | (1)
               |----------------------------PROD(1s, EDD1)-->|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     | (2)
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |

                                    Figure 4

     In a serialized management scenario, a single DM interacts with
     multiple DAs.

     In this figure, the DTNMA Manager A sends a policy to DTNMA Agents A
     and B to report the value of an EDD (EDD1) every second in (step 1).
     Each DA receives this policy and configures their respective autonomy
     engines for this production.  Thereafter, (step 2) each DA produces a
     report containing data element EDD1 and sends those reports back to
     the DM.

     This behavior continues without any additional communications from
     the DM.

  10.3.  Intermittent Connectivity

     Building from the nominal configuration in Section 10.2, this
     scenario shows a challenged network in which connectivity between
     DTNMA Agent B and the DM is temporarily lost.  Control flows for this
     case are outlined in Figure 5.

     Challenged Management Control Flow







  Birrane, et al.          Expires 30 October 2024               [Page 46]


  Internet-Draft                    DTNMA                       April 2024


           +-----------+           +---------+           +---------+
           |   DTNMA   |           |  DTNMA  |           |  DTNMA  |
           | Manager A |           | Agent A |           | Agent B |
           +----+------+           +----+----+           +----+----+
               |                       |                     |
               |-----PROD(1s, EDD1)--->|                     | (1)
               |----------------------------PROD(1s, EDD1)-->|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     | (2)
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |                       |            RPT(EDD1)| (3)
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |                       |            RPT(EDD1)| (4)
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<----------------RPT(EDD1), RPT(EDD1)--------| (5)
               |                       |                     |

                                    Figure 5

     In a challenged network, DAs store reports pending a transmit
     opportunity.

     In this figure, DTNMA Manager A sends a policy to DTNMA Agents A and
     B to produce an EDD (EDD1) every second in (step 1).  Each DA
     receives this policy and configures their respective autonomy engines
     for this production.  Produced reports are transmitted when there is
     connectivity between the DA and DM (step 2).












  Birrane, et al.          Expires 30 October 2024               [Page 47]


  Internet-Draft                    DTNMA                       April 2024


     At some point, DTNMA Agent B loses the ability to transmit in the
     network (steps 3 and 4).  During this time period, DA B continues to
     produce reports, but they are queued for transmission.  This queuing
     might be done by the DA itself or by a supporting transport such as
     BP.  Eventually (and before the next scheduled production of EDD1),
     DTNMA Agent B is able to transmit in the network again (step 5) and
     all queued reports are sent at that time.  DTNMA Agent A maintains
     connectivity with the DM during steps 3-5, and continues to send
     reports as they are generated.

  10.4.  Open-Loop Reporting

     This scenario illustrates the DTNMA open-loop control paradigm, where
     DAs manage themselves in accordance with policies provided by DMs,
     and provide reports to DMs based on these policies.

     The control flow shown in Figure 6, includes an example of data
     fusion, where multiple policies configured by a DM result in a single
     report from a DA.

     Consolidated Management Control Flow


           +-----------+           +---------+           +---------+
           |   DTNMA   |           |  DTNMA  |           |  DTNMA  |
           | Manager A |           | Agent A |           | Agent B |
           +----+------+           +----+----+           +----+----+
               |                       |                     |
               |-----PROD(1s, EDD1)--->|                     | (1)
               |----------------------------PROD(1s, EDD1)-->|
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     | (2)
               |<----------------------------RPT(EDD1)-------|
               |                       |                     |
               |                       |                     |
               |----------------------------PROD(1s, EDD2)-->| (3)
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<--------------------------RPT(EDD1,EDD2)----| (4)
               |                       |                     |
               |                       |                     |
               |<-------RPT(EDD1)------|                     |
               |<--------------------------RPT(EDD1,EDD2)----|
               |                       |                     |

                                    Figure 6



  Birrane, et al.          Expires 30 October 2024               [Page 48]


  Internet-Draft                    DTNMA                       April 2024


     A many-to-one mapping between management policy and device state
     reporting is supported by the DTNMA.

     In this figure, DTNMA Manager A sends a policy statement in the form
     of a rule to DTNMA Agents A and B, which instructs the DAs to produce
     a report with EDD1 every second (step 1).  Each DA receives this
     policy, which is stored in its respective Rule Database, and
     configures its Autonomy Engine.  Reports are transmitted by each DA
     when produced (step 2).

     At a later time, DTNMA Manager A sends an additional policy to DTNMA
     Agent B, requesting the production of a report for EDD2 every second
     (step 3).  This policy is added to DTNMA Agent B's Rule Database.

     Following this policy update, DTNMA Agent A will continue to produce
     EDD1 and DTNMA Agent B will produce both EDD1 and EDD2 (step 4).
     However, DTNMA Agent B may provide these values to the DM in a single
     report rather than as 2 independent reports.  In this way, there is
     no direct mapping between the single consolidated report sent by
     DTNMA Agent B (step 4) and the two different policies sent to DTNMA
     Agent B that caused that report to be generated (steps 1 and 3).

  10.5.  Multiple Administrative Domains

     The managed applications on a DA may be controlled by different
     administrative entities in a network.  The DTNMA allows DAs to
     communicate with multiple DMs in the network, such as in cases where
     there is one DM per administrative domain.

     Whenever a DM sends a policy expression to a DA, that policy
     expression may be associated with authorization information.  One
     method of representing this is an ACL.

        |  The use of an ACL in this use case does not imply the DTNMA
        |  requires ACLs to annotate policy expressions.  ACLs and their
        |  representation in this context are for example purposes only.

     The ability of one DM to access the results of policy expressions
     configured by some other DM will be limited to the authorization
     annotations of those policy expressions.

     An example of multi-manager authorization is illustrated in Figure 7.

     Multiplexed Management Control Flow







  Birrane, et al.          Expires 30 October 2024               [Page 49]


  Internet-Draft                    DTNMA                       April 2024


     +-----------+               +---------+                 +-----------+
     |   DTNMA   |               |  DTNMA  |                 |   DTNMA   |
     | Manager A |               | Agent A |                 | Manager B |
     +-----+-----+               +----+----+                 +-----+-----+
          |                          |                            |
          |---DEF(ACL1,V1,EDD1*2)--->|<---DEF(ACL2, V2, EDD2*2)---| (1)
          |                          |                            |
          |---PROD(1s, V1)---------->|<---PROD(1s, V2)------------| (2)
          |                          |                            |
          |<--------RPT(V1)----------|                            | (3)
          |                          |--------RPT(V2)------------>|
          |<--------RPT(V1)----------|                            |
          |                          |--------RPT(V2)------------>|
          |                          |                            |
          |                          |<---PROD(1s, V1)------------| (4)
          |                          |                            |
          |                          |----ERR(V1 no perm.)------->|
          |                          |                            |
          |--DEF(NULL,V3,EDD3*3)---->|                            | (5)
          |                          |                            |
          |---PROD(1s, V3)---------->|                            | (6)
          |                          |                            |
          |                          |<----PROD(1s, V3)-----------|
          |                          |                            |
          |<--------RPT(V3)----------|--------RPT(V3)------------>| (7)
          |<--------RPT(V1)----------|                            |
          |                          |--------RPT(V2)------------>|
          |<-------RPT(V3)-----------|--------RPT(V3)------------>|
          |<-------RPT(V1)-----------|                            |
          |                          |--------RPT(V2)------------>|

                                    Figure 7

     Multiple DMs may interface with a single DA, particularly in complex
     networks.

     In this figure, both DTNMA Managers A and B send policies to DTNMA
     Agent A (step 1).  DM A defines a variable (V1) whose value is given
     by the mathematical expression (EDD1 * 2) and is associated with an
     ACL (ACL1) that restricts access to V1 to DM A only.  Similarly, DM B
     defines a variable (V2) whose value is given by the mathematical
     expression (EDD2 * 2) and associated with an ACL (ACL2) that
     restricts access to V2 to DM B only.








  Birrane, et al.          Expires 30 October 2024               [Page 50]


  Internet-Draft                    DTNMA                       April 2024


     Both DTNMA Managers A and B also send policies to DTNMA Agent A to
     report on the values of their variables at 1 second intervals (step
     2).  Since DM A can access V1 and DM B can access V2, there is no
     authorization issue with these policies and they are both accepted by
     the autonomy engine on Agent A.  Agent A produces reports as
     expected, sending them to their respective managers (step 3).

     Later (step 4) DM B attempts to configure DA A to also report to it
     the value of V1.  Since DM B does not have authorization to view this
     variable, DA A does not include this in the configuration of its
     autonomy engine and, instead, some indication of permission error is
     included in any regular reporting back to DM B.

     DM A also sends a policy to Agent A (step 5) that defines a variable
     (V3) whose value is given by the mathematical expression (EDD3 * 3)
     and is not associated with an ACL, indicating that any DM can access
     V3.  In this instance, both DM A and DM B can then send policies to
     DA A to report the value of V3 (step 6).  Since there is no
     authorization restriction on V3, these policies are accepted by the
     autonomy engine on Agent A and reports are sent to both DM A and B
     over time (step 7).

  10.6.  Cascading Management

     There are times where a single network device may serve as both a DM
     for other DAs in the network and, itself, as a device managed by
     someone else.  This may be the case on nodes serving as gateways or
     proxies.  The DTNMA accommodates this case by allowing a single
     device to run both a DA and DM.

     An example of this configuration is illustrated in Figure 8.

     Cascading Management Control Flow


















  Birrane, et al.          Expires 30 October 2024               [Page 51]


  Internet-Draft                    DTNMA                       April 2024


                    ---------------------------------------
                    |                Node B               |
                    |                                     |
     +-----------+  |   +-----------+       +---------+   |    +---------+
     |   DTNMA   |  |   |   DTNMA   |       |  DTNMA  |   |    |  DTNMA  |
     | Manager A |  |   | Manager B |       | Agent B |   |    | Agent C |
     +---+-------+  |   +-----+-----+       +----+----+   |    +----+----+
         |          |         |                  |        |         |
         |--------------DEF(NULL,V0,EDD1+EDD2)-->|        |         | (1)
         |--------------PROD(1s,V0)------------->|        |         |
         |          |         |                  |        |         |
         |          |         |--PROD(1s,EDD1)-->|        |         | (2)
         |          |         |---------------------PROD(1s,EDD2)-->| (2)
         |          |         |                  |        |         |
         |          |         |                  |        |         |
         |          |         |<----RPT(EDD1)----|        |         | (3)
         |          |         |<--------------------RPT(EDD2)-------| (3)
         |          |         |                  |        |         |
         |<-------------RPT(V0)------------------|        |         | (4)
         |          |         |                  |        |         |
         |          |         |                  |        |         |
                    |                                     |
                    |                                     |
                    ---------------------------------------

                                    Figure 8

     A device can operate as both a DTNMA Manager and an Agent.

     In this example, we presume that DA B is able to sample a given EDD
     (EDD1) and that DA C is able to sample a different EDD (EDD2).  Node
     B houses DM B (which controls DA C) and DA B (which is controlled by
     DM A).  DM A must periodically receive some new value that is
     calculated as a function of both EDD1 and EDD2.

     First, DM A sends a policy to DA B to define a variable (V0) whose
     value is given by the mathematical expression (EDD1 + EDD2) without a
     restricting ACL.  Further, DM A sends a policy to DA B to report on
     the value of V0 every second (step 1).

     DA B needs the ability to monitor both EDD1 and EDD2.  However, the
     only way to receive EDD2 values is to have them reported back to Node
     B by DA C and included in the Node B runtime data stores.  Therefore,
     DM B sends a policy to DA C to report on the value of EDD2 (step 2).

     DA C receives the policy in its autonomy engine and produces reports
     on the value of EDD2 every second (step 3).




  Birrane, et al.          Expires 30 October 2024               [Page 52]


  Internet-Draft                    DTNMA                       April 2024


     DA B may locally sample EDD1 and EDD2 and uses that to compute values
     of V0 and report on those values at regular intervals to DM A (step
     4).

     While a trivial example, the mechanism of associating fusion with the
     Agent function rather than the Manager function scales with fusion
     complexity.  Within the DTNMA, DAs and DMs are not required to be
     separate software implementations.  There may be a single software
     application running on Node B implementing both DM B and DA B roles.

  11.  IANA Considerations

     This document requires no IANA actions.

  12.  Security Considerations

     Security within a DTNMA exists in at least two layers: security in
     the data model and security in the messaging and encoding of the data
     model.

     Data model security refers to the validity and accessibility of data
     elements.  For example, a data element might be available to certain
     DAs or DMs in a system, whereas the same data element may be hidden
     from other DAs or DMs.  Both verification and authorization
     mechanisms at DAs and DMs are important to achieve this type of
     security.

        |  NOTE: One way to provide finer-grained application security is
        |  through the use of Access Control Lists (ACLs) that would be
        |  defined as part of the configuration of DAs and DMs.  It is
        |  expected that many common data model tools provide mechanisms
        |  for the definition of ACLs and best practices for their
        |  operational use.

     The exchange of information between and amongst DAs and DMs in the
     DTNMA is expected to be accomplished through some secured messaging
     transport.

  13.  Informative References

     [ASN.1]    International Organization for Standardization,
                "Information processing systems - Open Systems
                Interconnection - Specification of Abstract Syntax
                Notation One (ASN.1)", International Standard 8824,
                December 1987.






  Birrane, et al.          Expires 30 October 2024               [Page 53]


  Internet-Draft                    DTNMA                       April 2024


     [DART]     Tropf, B. T., Haque, M., Behrooz, N., and C. Krupiarz,
                "The DART Autonomy System", 2023,
                <https://ieeexplore.ieee.org/abstract/document/10207457>.

     [gNMI]     OpenConfig, "gRPC Network Management Interface (gNMI)",
                May 2023, <https://www.openconfig.net/docs/gnmi/gnmi-
                specification/>.

     [gRPC]     gRPC Authors, "gRPC Documentation", 2024,
                <https://grpc.io/docs/>.

     [I-D.ietf-core-comi]
                Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
                and C. Bormann, "CoAP Management Interface (CORECONF)",
                Work in Progress, Internet-Draft, draft-ietf-core-comi-17,
                4 March 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-core-comi-17>.

     [I-D.ietf-core-sid]
                Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M.
                Richardson, "YANG Schema Item iDentifier (YANG SID)", Work
                in Progress, Internet-Draft, draft-ietf-core-sid-24, 22
                December 2023, <https://datatracker.ietf.org/doc/html/
                draft-ietf-core-sid-24>.

     [I-D.rfernando-protocol-buffers]
                Stuart, S. and R. Fernando, "Encoding rules and MIME type
                for Protocol Buffers", Work in Progress, Internet-Draft,
                draft-rfernando-protocol-buffers-00, 11 October 2012,
                <https://datatracker.ietf.org/doc/html/draft-rfernando-
                protocol-buffers-00>.

     [IPMI]     Intel, Hewlett-Packard, NEC, and Dell, "Intelligent
                Platform Management Interface Specification, Second
                Generation", October 2013,
                <https://www.intel.la/content/dam/www/public/us/en/
                documents/specification-updates/ipmi-intelligent-platform-
                mgt-interface-spec-2nd-gen-v2-0-spec-update.pdf>.

     [NEW-HORIZONS]
                Moore, R. C., "Autonomous safeing and fault protection for
                the New Horizons mission to Pluto", March 2007,
                <https://www.sciencedirect.com/science/article/pii/
                S0094576507000604>.







  Birrane, et al.          Expires 30 October 2024               [Page 54]


  Internet-Draft                    DTNMA                       April 2024


     [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
                Schoenwaelder, Ed., "Structure of Management Information
                Version 2 (SMIv2)", STD 58, RFC 2578,
                DOI 10.17487/RFC2578, April 1999,
                <https://www.rfc-editor.org/info/rfc2578>.

     [RFC2982]  Kavasseri, R., Ed., "Distributed Management Expression
                MIB", RFC 2982, DOI 10.17487/RFC2982, October 2000,
                <https://www.rfc-editor.org/info/rfc2982>.

     [RFC3165]  Levi, D. and J. Schoenwaelder, "Definitions of Managed
                Objects for the Delegation of Management Scripts",
                RFC 3165, DOI 10.17487/RFC3165, August 2001,
                <https://www.rfc-editor.org/info/rfc3165>.

     [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
                "Introduction and Applicability Statements for Internet-
                Standard Management Framework", RFC 3410,
                DOI 10.17487/RFC3410, December 2002,
                <https://www.rfc-editor.org/info/rfc3410>.

     [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
                Architecture for Describing Simple Network Management
                Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
                DOI 10.17487/RFC3411, December 2002,
                <https://www.rfc-editor.org/info/rfc3411>.

     [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
                (USM) for version 3 of the Simple Network Management
                Protocol (SNMPv3)", STD 62, RFC 3414,
                DOI 10.17487/RFC3414, December 2002,
                <https://www.rfc-editor.org/info/rfc3414>.

     [RFC3416]  Presuhn, R., Ed., "Version 2 of the Protocol Operations
                for the Simple Network Management Protocol (SNMP)",
                STD 62, RFC 3416, DOI 10.17487/RFC3416, December 2002,
                <https://www.rfc-editor.org/info/rfc3416>.

     [RFC3417]  Presuhn, R., Ed., "Transport Mappings for the Simple
                Network Management Protocol (SNMP)", STD 62, RFC 3417,
                DOI 10.17487/RFC3417, December 2002,
                <https://www.rfc-editor.org/info/rfc3417>.

     [RFC3418]  Presuhn, R., Ed., "Management Information Base (MIB) for
                the Simple Network Management Protocol (SNMP)", STD 62,
                RFC 3418, DOI 10.17487/RFC3418, December 2002,
                <https://www.rfc-editor.org/info/rfc3418>.




  Birrane, et al.          Expires 30 October 2024               [Page 55]


  Internet-Draft                    DTNMA                       April 2024


     [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
                R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
                Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
                April 2007, <https://www.rfc-editor.org/info/rfc4838>.

     [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
                FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
                <https://www.rfc-editor.org/info/rfc4949>.

     [RFC5591]  Harrington, D. and W. Hardaker, "Transport Security Model
                for the Simple Network Management Protocol (SNMP)",
                STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009,
                <https://www.rfc-editor.org/info/rfc5591>.

     [RFC5592]  Harrington, D., Salowey, J., and W. Hardaker, "Secure
                Shell Transport Model for the Simple Network Management
                Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June
                2009, <https://www.rfc-editor.org/info/rfc5592>.

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/info/rfc5652>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/info/rfc6241>.

     [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
                Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
                <https://www.rfc-editor.org/info/rfc6242>.

     [RFC6353]  Hardaker, W., "Transport Layer Security (TLS) Transport
                Model for the Simple Network Management Protocol (SNMP)",
                STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011,
                <https://www.rfc-editor.org/info/rfc6353>.

     [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
                RFC 6991, DOI 10.17487/RFC6991, July 2013,
                <https://www.rfc-editor.org/info/rfc6991>.

     [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
                Constrained-Node Networks", RFC 7228,
                DOI 10.17487/RFC7228, May 2014,
                <https://www.rfc-editor.org/info/rfc7228>.






  Birrane, et al.          Expires 30 October 2024               [Page 56]


  Internet-Draft                    DTNMA                       April 2024


     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/info/rfc7252>.

     [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
                Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
                Networking: Definitions and Design Goals", RFC 7575,
                DOI 10.17487/RFC7575, June 2015,
                <https://www.rfc-editor.org/info/rfc7575>.

     [RFC7589]  Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
                NETCONF Protocol over Transport Layer Security (TLS) with
                Mutual X.509 Authentication", RFC 7589,
                DOI 10.17487/RFC7589, June 2015,
                <https://www.rfc-editor.org/info/rfc7589>.

     [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
                RFC 7950, DOI 10.17487/RFC7950, August 2016,
                <https://www.rfc-editor.org/info/rfc7950>.

     [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
                RFC 7951, DOI 10.17487/RFC7951, August 2016,
                <https://www.rfc-editor.org/info/rfc7951>.

     [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
                Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
                <https://www.rfc-editor.org/info/rfc8040>.

     [RFC8199]  Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
                Classification", RFC 8199, DOI 10.17487/RFC8199, July
                2017, <https://www.rfc-editor.org/info/rfc8199>.

     [RFC8294]  Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
                "Common YANG Data Types for the Routing Area", RFC 8294,
                DOI 10.17487/RFC8294, December 2017,
                <https://www.rfc-editor.org/info/rfc8294>.

     [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
                Access Control Model", STD 91, RFC 8341,
                DOI 10.17487/RFC8341, March 2018,
                <https://www.rfc-editor.org/info/rfc8341>.

     [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
                and R. Wilton, "Network Management Datastore Architecture
                (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
                <https://www.rfc-editor.org/info/rfc8342>.




  Birrane, et al.          Expires 30 October 2024               [Page 57]


  Internet-Draft                    DTNMA                       April 2024


     [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
                Control Plane for Stable Connectivity of Network
                Operations, Administration, and Maintenance (OAM)",
                RFC 8368, DOI 10.17487/RFC8368, May 2018,
                <https://www.rfc-editor.org/info/rfc8368>.

     [RFC8639]  Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
                E., and A. Tripathy, "Subscription to YANG Notifications",
                RFC 8639, DOI 10.17487/RFC8639, September 2019,
                <https://www.rfc-editor.org/info/rfc8639>.

     [RFC8641]  Clemm, A. and E. Voit, "Subscription to YANG Notifications
                for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
                September 2019, <https://www.rfc-editor.org/info/rfc8641>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/info/rfc8990>.

     [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
                L., and J. Nobre, "A Reference Model for Autonomic
                Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
                <https://www.rfc-editor.org/info/rfc8993>.

     [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
                DOI 10.17487/RFC9113, June 2022,
                <https://www.rfc-editor.org/info/rfc9113>.

     [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
                Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
                January 2022, <https://www.rfc-editor.org/info/rfc9171>.

     [RFC9172]  Birrane, III, E. and K. McKeever, "Bundle Protocol
                Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
                2022, <https://www.rfc-editor.org/info/rfc9172>.

     [RFC9254]  Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
                C., and M. Richardson, "Encoding of Data Modeled with YANG
                in the Concise Binary Object Representation (CBOR)",
                RFC 9254, DOI 10.17487/RFC9254, July 2022,
                <https://www.rfc-editor.org/info/rfc9254>.

     [xml-infoset]
                World Wide Web Consortium, "XML Information Set (Second
                Edition)", February 2004,
                <https://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.




  Birrane, et al.          Expires 30 October 2024               [Page 58]


  Internet-Draft                    DTNMA                       April 2024


     [XPath]    World Wide Web Consortium, "XML Path Language (XPath)
                Version 1.0", November 1999,
                <http://www.w3.org/TR/1999/REC-xpath-19991116>.

  Acknowledgements

     Brian Sipos of the Johns Hopkins University Applied Physics
     Laboratory (JHU/APL) provided excellent technical review of the DTNMA
     concepts presented in this document and additional information
     related to existing network management techniques.

  Authors' Addresses

     Edward J. Birrane
     Johns Hopkins Applied Physics Laboratory
     Email: Edward.Birrane@jhuapl.edu


     Sarah E. Heiner
     Johns Hopkins Applied Physics Laboratory
     Email: Sarah.Heiner@jhuapl.edu


     Emery Annis
     Johns Hopkins Applied Physics Laboratory
     Email: Emery.Annis@jhuapl.edu

























  Birrane, et al.          Expires 30 October 2024               [Page 59]


