Discovery:

A process by which an ASA discovers peers according to a specific discovery objective. The discovery results may be different according to the different discovery objectives. The discovered peers may later be used as negotiation counterparts or as sources of synchronization data.

Negotiation:

A process by which two ASAs interact iteratively to agree on parameter settings that best satisfy the objectives of both ASAs.

State Synchronization:

A process by which ASAs interact to receive the current state of parameter values stored in other ASAs. This is a special case of negotiation in which information is sent, but the ASAs do not request their peers to change parameter settings. All other definitions apply to both negotiation and synchronization.

Technical Objective (usually abbreviated as Objective):

A technical objective is a data structure whose main contents are a name and a value. The value consists of a single configurable parameter or a set of parameters of some kind. The exact format of an objective is defined in Section 2.10.1. An objective occurs in three contexts: discovery, negotiation, and synchronization. Normally, a given objective will not occur in negotiation and synchronization contexts simultaneously.

• One ASA may support multiple independent objectives.
• The parameter(s) in the value of a given objective apply to a specificservice or function or action. They may in principle be anything that can beset to a specific logical, numerical, or string value, or a more complex datastructure, by a network node. Each node is expected to contain one or moreASAs which may each manage subsidiary non-autonomic nodes.

• Discovery Objective:

  an objective in the process of discovery. Its value may be undefined.

  Synchronization Objective:

  an objective whose specific technical content needs to be synchronizedamong two or more ASAs. Thus, each ASA will maintain its own copy of theobjective.

  Negotiation Objective:

  an objective whose specific technical content needs to be decided incoordination with another ASA. Again, each ASA will maintain its own copy ofthe objective.
• A detailed discussion of objectives, including their format, is found in Section 2.10.

Discovery Initiator:

An ASA that starts discovery by sending a Discovery message referring to a specific discovery objective.

Discovery Responder:

A peer that either contains an ASA supporting the discovery objective indicated by the discovery initiator or caches the locator(s) of the ASA(s) supporting the objective. It sends a Discovery Response, as described later.

Synchronization Initiator:

An ASA that starts synchronization by sending a request message referring to a specific synchronization objective.

Synchronization Responder:

A peer ASA that responds with the value of a synchronization objective.

Negotiation Initiator:

An ASA that starts negotiation by sending a request message referring to a specific negotiation objective.

Negotiation Counterpart:

A peer with which the negotiation initiator negotiates a specific negotiation objective.

GRASP Instance:

This refers to an instantiation of a GRASP protocol engine, likely including multiple threads or processes as well as dynamic data structures such as a discovery cache, running in a given security environment on a single device.

GRASP Core:

This refers to the code and shared data structures of a GRASP instance, which will communicate with individual ASAs via a suitable Application Programming Interface (API).

Interface or GRASP Interface:

Unless otherwise stated, this refers to a network interface, which might be physical or virtual, that a specific instance of GRASP is currently using. A device might have other interfaces that are not used by GRASP and which are outside the scope of the Autonomic Network.

A generic platform:

The protocol design is generic and independent of the synchronization or negotiation contents. The technical contents will vary according to the various technical objectives and the different pairs of counterparts.

Multiple instances:

Normally, a single main instance of the GRASP protocol engine will exist in an autonomic node, and each ASA will run as an independent asynchronous process. However, scenarios where multiple instances of GRASP run in a single node, perhaps with different security properties, are possible (Section 2.5.2). In this case, each instance MUST listen independently for GRASP link-local multicasts, and all instances MUST be woken by each such multicast in order for discovery and flooding to work correctly.

Security infrastructure:

As noted above, the protocol itself has no built-in security functionality and relies on a separate secure infrastructure.

Discovery, synchronization, and negotiation are designed together:

The discovery method and the synchronization and negotiation methods are designed in the same way and can be combined when this is useful, allowing a rapid mode of operation described in Section 2.5.4. These processes can also be performed independently when appropriate.

• Thus, for some objectives, especially those concerned with application-layer services, another discovery mechanism such as DNS-based Service Discovery [RFC 7558] MAY be used. The choice is left to the designers of individual ASAs.

A uniform pattern for technical objectives:

The synchronization and negotiation objectives are defined according to a uniform pattern. The values that they contain could be carried either in a simple binary format or in a complex object format. The basic protocol design uses the Concise Binary Object Representation (CBOR) [RFC 8949], which is readily extensible for unknown, future requirements.

A flexible model for synchronization:

GRASP supports synchronization between two nodes, which could be used repeatedly to perform synchronization among a small number of nodes. It also supports an unsolicited flooding mode when large groups of nodes, possibly including all autonomic nodes, need data for the same technical objective.

• There may be some network parameters for which a more traditional flooding mechanism such as the Distributed Node Consensus Protocol (DNCP) [RFC 7787] is considered more appropriate. GRASP can coexist with DNCP.

A simple initiator/responder model for negotiation:

Multiparty negotiations are very complicated to model and cannot readily be guaranteed to converge. GRASP uses a simple bilateral model and can support multiparty negotiations by indirect steps.

Organizing of synchronization or negotiation content:

The technical content transmitted by GRASP will be organized according to the relevant function or service. The objectives for different functions or services are kept separate because they may be negotiated or synchronized with different counterparts or have different response times. Thus a normal arrangement is a single ASA managing a small set of closely related objectives, with a version of that ASA in each relevant autonomic node. Further discussion of this aspect is out of scope for the current document.

Requests and responses in negotiation procedures:

The initiator can negotiate a specific negotiation objective with relevant counterpart ASAs. It can request relevant information from a counterpart so that it can coordinate its local configuration. It can request the counterpart to make a matching configuration. It can request simulation or forecast results by sending some dry-run conditions.

Beyond the traditional yes/no answer, the responder can reply with a suggested alternative value for the objective concerned. This would start a bidirectional negotiation ending in a compromise between the two ASAs.

Convergence of negotiation procedures:

To enable convergence when a responder suggests a new value or condition in a negotiation step reply, it should be as close as possible to the original request or previous suggestion. The suggested value of later negotiation steps should be chosen between the suggested values from the previous two steps. GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, namely a timeout and a maximum number of iterations.

Extensibility:

GRASP intentionally does not have a version number, and it can be extended by adding new message types and options. The Invalid message (M_INVALID) will be used to signal that an implementation does not recognize a message or option sent by another implementation. In normal use, new semantics will be added by defining new synchronization or negotiation objectives.

• A discovery mechanism (M_DISCOVERY, M_RESPONSE) by which an ASA can discover other ASAs supporting a given objective.
• A negotiation request mechanism (M_REQ_NEG) by which an ASA can start negotiation of an objective with a counterpart ASA. Once a negotiation has started, the process is symmetrical, and there is a negotiation step message (M_NEGOTIATE) for each ASA to use in turn. Two other functions support negotiating steps (M_WAIT, M_END).
• A synchronization mechanism (M_REQ_SYN) by which an ASA can request the current value of an objective from a counterpart ASA. With this, there is a corresponding response function (M_SYNCH) for an ASA that wishes to respond to synchronization requests.
• A flood mechanism (M_FLOOD) by which an ASA can cause the current value of an objective to be flooded throughout the Autonomic Network so that any ASA can receive it. One application of this is to act as an announcement, avoiding the need for discovery of a widely applicable objective.

• An initiator MAY send Discovery or Flood Synchronization link-local multicast messages that MUST have a loop count of 1, to prevent off-link operations. Other unsolicited GRASP message types MUST NOT be sent.
• A responder MUST silently discard any message whose loop count is not 1.
• A responder MUST silently discard any message referring to a GRASP objective that is not directly part of a service that requires this insecure mode.
• A responder MUST NOT relay any multicast messages.
• A Discovery Response MUST indicate a link-local address.
• A Discovery Response MUST NOT include a Divert option.
• A node MUST silently discard any message whose source address is not link-local.

ALL_GRASP_NEIGHBORS

A link-local scope multicast address used by a GRASP-enabled device to discover GRASP-enabled neighbor (i.e., on-link) devices. All devices that support GRASP are members of this multicast group.

• IPv6 multicast address: ff02::13
• IPv4 multicast address: 224.0.0.119

GRASP_LISTEN_PORT (7017)

A well-known UDP user port that every GRASP-enabled network device MUST listen to for link-local multicasts when UDP is used for M_DISCOVERY or M_FLOOD messages in the GRASP instance. This user port MAY also be used to listen for TCP or UDP unicast messages in a simple implementation of GRASP (Section 2.5.3).

GRASP_DEF_TIMEOUT (60000 milliseconds)

The default timeout used to determine that an operation has failed to complete.

GRASP_DEF_LOOPCT (6)

The default loop count used to determine that a negotiation has failed to complete and to avoid looping messages.

GRASP_DEF_MAX_SIZE (2048)

The default maximum message size in bytes.

• Discovery and Discovery Response (M_DISCOVERY, M_RESPONSE).
• Request Negotiation, Negotiation, Confirm Waiting, and Negotiation End (M_REQ_NEG, M_NEGOTIATE, M_WAIT, M_END).
• Request Synchronization, Synchronization, and Flood Synchronization (M_REQ_SYN, M_SYNCH, M_FLOOD).
• No Operation and Invalid (M_NOOP, M_INVALID).

  discovery-message = [M_DISCOVERY, session-id, initiator, objective]

• A Discovery Objective option (Section 2.10.1). Its loop count MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT). If the discovery initiator requires only on-link responses, the loop count MUST be set to 1.
• A Negotiation Objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiator with a Negotiation message for rapid processing, if it could act as the corresponding negotiation counterpart. The sender of such a Discovery message MUST initialize a negotiation timer and loop count in the same way as a Request Negotiation message (Section 2.8.6).
• A Synchronization Objective option (Section 2.10.1). This is used both for the purpose of discovery and to indicate to the discovery target that it MAY directly reply to the discovery initiator with a Synchronization message for rapid processing, if it could act as the corresponding synchronization counterpart. Its loop count MUST be set to a suitable value to prevent discovery loops (default value is GRASP_DEF_LOOPCT).

  response-message = [M_RESPONSE, session-id, initiator, ttl,
                      (+locator-option // divert-option), ?objective]

  ttl = 0..4294967295 ; in milliseconds

• It MUST contain the same Session ID and initiator as the Discovery message.
• It MUST contain a time-to-live (ttl) for the validity of the response, given as a positive integer value in milliseconds. Zero implies a value significantly greater than GRASP_DEF_TIMEOUT milliseconds (Section 2.6). A suggested value is ten times that amount.
• It MAY include a copy of the discovery objective from the Discovery message.

  flood-message = [M_FLOOD, session-id, initiator, ttl,
                   +[objective, (locator-option / [])]]

  ttl = 0..4294967295 ; in milliseconds

• The initiator address is provided, as described for Discovery messages (Section 2.8.4), only to disambiguate the Session ID.
• The message MUST contain a time-to-live (ttl) for the validity of the contents, given as a positive integer value in milliseconds. There is no default; zero indicates an indefinite lifetime.
• The synchronization data are in the form of GRASP option(s) for specific synchronization objective(s). The loop count(s) MUST be set to a suitable value to prevent flood loops (default value is GRASP_DEF_LOOPCT).
• Each objective option MAY be followed by a locator option (Section 2.9.5) associated with the flooded objective. In its absence, an empty option MUST be included to indicate a null locator.

objective = [objective-name, objective-flags,
             loop-count, ?objective-value]

objective-name = text
objective-value = any
loop-count = 0..255

1. The unique string is a decimal number representing a registered 32-bit Private Enterprise Number (PEN) [RFC 5612] that uniquely identifies the enterprise defining the objective.
2. The unique string is a FQDN that uniquely identifies the entity or person defining the objective.
3. The unique string is an email address that uniquely identifies the entity or person defining the objective.

Authentication

A cryptographically authenticated identity for each device is needed in an Autonomic Network. It is not safe to assume that a large network is physically secured against interference or that all personnel are trustworthy. Each autonomic node MUST be capable of proving its identity and authenticating its messages. GRASP relies on a separate, external certificate-based security mechanism to support authentication, data integrity protection, and anti-replay protection.

Since GRASP must be deployed in an existing secure environment, the protocol itself specifies nothing concerning the trust anchor and certification authority. For example, in the ACP [RFC 8994], all nodes can trust each other and the ASAs installed in them.

If GRASP is used temporarily without an external security mechanism, for example, during system bootstrap (Section 2.5.1), the Session ID (Section 2.7) will act as a nonce to provide limited protection against the injecting of responses by third parties. A full analysis of the secure bootstrap process is in [RFC 8995].

Authorization and roles

GRASP is agnostic about the roles and capabilities of individual ASAs and about which objectives a particular ASA is authorized to support. An implementation might support precautions such as allowing only one ASA in a given node to modify a given objective, but this may not be appropriate in all cases. For example, it might be operationally useful to allow an old and a new version of the same ASA to run simultaneously during an overlap period. These questions are out of scope for the present specification.

Privacy and confidentiality

GRASP is intended for network-management purposes involving network elements, not end hosts. Therefore, no personal information is expected to be involved in the signaling protocol, so there should be no direct impact on personal privacy. Nevertheless, applications that do convey personal information cannot be excluded. Also, traffic flow paths, VPNs, etc., could be negotiated, which could be of interest for traffic analysis. Operators generally want to conceal details of their network topology and traffic density from outsiders. Therefore, since insider attacks cannot be excluded in a large network, the security mechanism for the protocol MUST provide message confidentiality. This is why Section 2.5.1 requires either an ACP or an alternative security mechanism.

Link-local multicast security

GRASP has no reasonable alternative to using link-local multicast for Discovery or Flood Synchronization messages, and these messages are sent in the clear and with no authentication. They are only sent on interfaces within the Autonomic Network (see Section 2.1 and Section 2.5.1). They are, however, available to on-link eavesdroppers and could be forged by on-link attackers. In the case of discovery, the Discovery Responses are unicast and will therefore be protected (Section 2.5.1), and an untrusted forger will not be able to receive responses. In the case of flood synchronization, an on-link eavesdropper will be able to receive the flooded objectives, but there is no response message to consider. Some precautions for Flood Synchronization messages are suggested in Section 2.5.6.2.

DoS attack protection

GRASP discovery partly relies on insecure link-local multicast. Since routers participating in GRASP sometimes relay Discovery messages from one link to another, this could be a vector for denial-of-service attacks. Some mitigations are specified in Section 2.5.4. However, malicious code installed inside the ACP could always launch DoS attacks consisting of either spurious Discovery messages or spurious Discovery Responses. It is important that firewalls prevent any GRASP messages from entering the domain from an unknown source.

Security during bootstrap and discovery

A node cannot trust GRASP traffic from other nodes until the security environment (such as the ACP) has identified the trust anchor and can authenticate traffic by validating certificates for other nodes. Also, until it has successfully enrolled [RFC 8995], a node cannot assume that other nodes are able to authenticate its own traffic. Therefore, GRASP discovery during the bootstrap phase for a new device will inevitably be insecure. Secure synchronization and negotiation will be impossible until enrollment is complete. Further details are given in Section 2.5.2.

Security of discovered locators

When GRASP discovery returns an IP address, it MUST be that of a node within the secure environment (Section 2.5.1). If it returns an FQDN or a URI, the ASA that receives it MUST NOT assume that the target of the locator is within the secure environment.

Address(es):

ff02::13

Description:

ALL_GRASP_NEIGHBORS

Reference:

RFC 8990

Address(es):

224.0.0.119

Description:

ALL_GRASP_NEIGHBORS

Reference:

RFC 8990

Service Name:

grasp

Port Number:

7017

Transport Protocol:

udp, tcp

Description

GeneRic Autonomic Signaling Protocol

Assignee:

IESG <iesg@ietf.org>

Contact:

IETF Chair <chair@ietf.org>

Reference:

RFC 8990

[RFC2119]

S. Bradner, "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>.

[RFC3629]

F. Yergeau, "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003,
<https://www.rfc-editor.org/info/rfc3629>.

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC4086]

D. Eastlake 3rd, J. Schiller, and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.

[RFC7217]

F. Gont, "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.

[RFC8085]

L. Eggert, G. Fairhurst, and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017,
<https://www.rfc-editor.org/info/rfc8085>.

[RFC8174]

B. Leiba, "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>.

[RFC8610]

H. Birkholz, C. Vigano, and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019,
<https://www.rfc-editor.org/info/rfc8610>.

[RFC8949]

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

[RFC8994]

T Eckert, M Behringer, and S Bjarnason, "An Autonomic Control Plane (ACP)", RFC 8994, DOI 10.17487/RFC8994, May 2021,
<https://www.rfc-editor.org/info/rfc8994>.

[ADNCP]

, "Autonomic Distributed Node Consensus Protocol", Internet-Draft draft-stenberg-anima-adncp-00, March 2015,
<https://tools.ietf.org/html/draft-stenberg-anima-adncp-00>.

[ASA-GUIDELINES]

Nokia, , , , and , "Guidelines for Autonomic Service Agents", Internet-Draft draft-ietf-anima-asa-guidelines-00, November 2020,
<https://tools.ietf.org/html/draft-ietf-anima-asa-guidelines-00>.

[IGCP]

Fraunhofer Fokus, M. H. Behringer, R. Chaparadza, L. Xin, H. Mahkonen, and R. Petre, "IP based Generic Control Protocol (IGCP)", Internet-Draft draft-chaparadza-intarea-igcp-00, July 2011,
<https://tools.ietf.org/html/draft-chaparadza-intarea-igcp-00>.

[RFC2205]

R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997,
<https://www.rfc-editor.org/info/rfc2205>.

[RFC2334]

J. Luciani, G. Armitage, J. Halpern, and N. Doraswamy, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, DOI 10.17487/RFC2334, April 1998,
<https://www.rfc-editor.org/info/rfc2334>.

[RFC2608]

E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol, Version 2", RFC 2608, DOI 10.17487/RFC2608, June 1999,
<https://www.rfc-editor.org/info/rfc2608>.

[RFC2865]

C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000,
<https://www.rfc-editor.org/info/rfc2865>.

[RFC3416]

R. Presuhn, "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>.

[RFC3493]

R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003,
<https://www.rfc-editor.org/info/rfc3493>.

[RFC4861]

T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC5612]

P. Eronen, and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009,
<https://www.rfc-editor.org/info/rfc5612>.

[RFC5971]

H. Schulzrinne, and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010,
<https://www.rfc-editor.org/info/rfc5971>.

[RFC6206]

P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011,
<https://www.rfc-editor.org/info/rfc6206>.

[RFC6241]

R. Enns, M. Bjorklund, J. Schoenwaelder, and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.

[RFC6733]

V. Fajardo, J. Arkko, J. Loughney, and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>.

[RFC6762]

S. Cheshire, and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.

[RFC6763]

S. Cheshire, and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.

[RFC6887]

D. Wing, S. Cheshire, M. Boucadair, R. Penno, and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.

[RFC7558]

K. Lynn, S. Cheshire, M. Blanchet, and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015,
<https://www.rfc-editor.org/info/rfc7558>.

[RFC7575]

M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015,
<https://www.rfc-editor.org/info/rfc7575>.

[RFC7576]

S. Jiang, B. Carpenter, and M. Behringer, "General Gap Analysis for Autonomic Networking", RFC 7576, DOI 10.17487/RFC7576, June 2015,
<https://www.rfc-editor.org/info/rfc7576>.

[RFC7787]

M. Stenberg, and S. Barth, "Distributed Node Consensus Protocol", RFC 7787, DOI 10.17487/RFC7787, April 2016,
<https://www.rfc-editor.org/info/rfc7787>.

[RFC7788]

M. Stenberg, S. Barth, and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016,
<https://www.rfc-editor.org/info/rfc7788>.

[RFC8040]

A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[RFC8264]

P. Saint-Andre, and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.

[RFC8368]

T. Eckert, 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>.

[RFC8415]

T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.

[RFC8991]

B Carpenter, B Liu, W Wang, and X Gong, "GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API)", RFC 8991, DOI 10.17487/RFC8991, May 2021,
<https://www.rfc-editor.org/info/rfc8991>.

[RFC8993]

M Behringer, B Carpenter, T Eckert, L Ciavaglia, and J Nobre, "A Reference Model for Autonomic Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
<https://www.rfc-editor.org/info/rfc8993>.

[RFC8995]

M Pritikin, M Richardson, T Eckert, M Behringer, and K Watsen, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, May 2021,
<https://www.rfc-editor.org/info/rfc8995>.

1. CBOR diagnostic notation.
2. Similar, but showing the names of the constants. (Details of the flag bit encoding are omitted.)
3. Hexadecimal version of the CBOR wire format.

D1.

ASAs may be designed to manage any type of configurable device or software, as required in Appendix B.2. A basic requirement is therefore that the protocol can represent and discover any kind of technical objective (as defined in Section 2.1) among arbitrary subsets of participating nodes. In an Autonomic Network, we must assume that when a device starts up, it has no information about any peer devices, the network structure, or the specific role it must play. The ASA(s) inside the device are in the same situation. In some cases, when a new application session starts within a device, the device or ASA may again lack information about relevant peers. For example, it might be necessary to set up resources on multiple other devices, coordinated and matched to each other so that there is no wasted resource. Security settings might also need updating to allow for the new device or user. The relevant peers may be different for different technical objectives. Therefore discovery needs to be repeated as often as necessary to find peers capable of acting as counterparts for each objective that a discovery initiator needs to handle. From this background we derive the next three requirements:

D2.

When an ASA first starts up, it may have no knowledge of the specific network to which it is attached. Therefore the discovery process must be able to support any network scenario, assuming only that the device concerned is bootstrapped from factory condition.

D3.

When an ASA starts up, it must require no configured location information about any peers in order to discover them.

D4.

If an ASA supports multiple technical objectives, relevant peers may be different for different discovery objectives, so discovery needs to be performed separately to find counterparts for each objective. Thus, there must be a mechanism by which an ASA can separately discover peer ASAs for each of the technical objectives that it needs to manage, whenever necessary.

D5.

Following discovery, an ASA will normally perform negotiation or synchronization for the corresponding objectives. The design should allow for this by conveniently linking discovery to negotiation and synchronization. It may provide an optional mechanism to combine discovery and negotiation/synchronization in a single protocol exchange.

D6.

Some objectives may only be significant on the local link, but others may be significant across the routed network and require off-link operations. Thus, the relevant peers might be immediate neighbors on the same layer 2 link, or they might be more distant and only accessible via layer 3. The mechanism must therefore provide both on-link and off-link discovery of ASAs supporting specific technical objectives.

D7.

The discovery process should be flexible enough to allow for special cases, such as the following:

• During initialization, a device must be able to establish mutual trust with autonomic nodes elsewhere in the network and participate in an authentication mechanism. Although this will inevitably start with a discovery action, it is a special case precisely because trust is not yet established. This topic is the subject of [RFC 8995]. We require that once trust has been established for a device, all ASAs within the device inherit the device's credentials and are also trusted. This does not preclude the device having multiple credentials.
• Depending on the type of network involved, discovery of other central functions might be needed, such as the Network Operations Center (NOC) [RFC 8368]. The protocol must be capable of supporting such discovery during initialization, as well as discovery during ongoing operation.

D8.

The discovery process must not generate excessive traffic and must take account of sleeping nodes.

D9.

There must be a mechanism for handling stale discovery results.

SN1.

A basic requirement for the protocol is therefore the ability to represent, discover, synchronize, and negotiate almost any kind of network parameter among selected subsets of participating nodes.

SN2.

Negotiation is an iterative request/response process that must be guaranteed to terminate (with success or failure). While tie-breaking rules must be defined specifically for each use case, the protocol should have some general mechanisms in support of loop and deadlock prevention, such as hop-count limits or timeouts.

SN3.

Synchronization must be possible for groups of nodes ranging from small to very large.

SN4.

To avoid "reinventing the wheel", the protocol should be able to encapsulate the data formats used by existing configuration protocols (such as Network Configuration Protocol (NETCONF) and YANG) in cases where that is convenient.

SN5.

Human intervention in complex situations is costly and error prone. Therefore, synchronization or negotiation of parameters without human intervention is desirable whenever the coordination of multiple devices can improve overall network performance. It follows that the protocol's resource requirements must be small enough to fit in any device that would otherwise need human intervention. The issue of running in constrained nodes is discussed in [RFC 8993].

SN6.

Human intervention in large networks is often replaced by use of a top-down network management system (NMS). It therefore follows that the protocol, as part of the Autonomic Networking Infrastructure, should be capable of running in any device that would otherwise be managed by an NMS, and that it can coexist with an NMS and with protocols such as SNMP and NETCONF.

SN7.

Specific autonomic features are expected to be implemented by individual ASAs, but the protocol must be general enough to allow them. Some examples follow:

• Dependencies and conflicts: In order to decide upon a configuration for a given device, the device may need information from neighbors. This can be established through the negotiation procedure, or through synchronization if that is sufficient. However, a given item in a neighbor may depend on other information from its own neighbors, which may need another negotiation or synchronization procedure to obtain or decide. Therefore, there are potential dependencies and conflicts among negotiation or synchronization procedures. Resolving dependencies and conflicts is a matter for the individual ASAs involved. To allow this, there need to be clear boundaries and convergence mechanisms for negotiations. Also some mechanisms are needed to avoid loop dependencies or uncontrolled growth in a tree of dependencies. It is the ASA designer's responsibility to avoid or detect looping dependencies or excessive growth of dependency trees. The protocol's role is limited to bilateral signaling between ASAs and the avoidance of loops during bilateral signaling.
• Recovery from faults and identification of faulty devices should be as automatic as possible. The protocol's role is limited to discovery, synchronization, and negotiation. These processes can occur at any time, and an ASA may need to repeat any of these steps when the ASA detects an event such as a negotiation counterpart failing.
• Since a major goal is to minimize human intervention, it is necessary that the network can in effect "think ahead" before changing its parameters. One aspect of this is an ASA that relies on a knowledge base to predict network behavior. This is out of scope for the signaling protocol. However, another aspect is forecasting the effect of a change by a "dry run" negotiation before actually installing the change. Signaling a dry run is therefore a desirable feature of the protocol.

Note that management logging, monitoring, alerts, and tools for intervention are required. However, these can only be features of individual ASAs, not of the protocol itself. Another document [RFC 8368] discusses how such agents may be linked into conventional Operations, Administration, and Maintenance (OAM) systems via an Autonomic Control Plane [RFC 8994].

SN8.

The protocol will be able to deal with a wide variety of technical objectives, covering any type of network parameter. Therefore the protocol will need a flexible and easily extensible format for describing objectives. At a later stage, it may be desirable to adopt an explicit information model. One consideration is whether to adopt an existing information model or to design a new one.

T1.

It should be convenient for ASA designers to define new technical objectives and for programmers to express them, without excessive impact on runtime efficiency and footprint. In particular, it should be convenient for ASAs to be implemented independently of each other as user-space programs rather than as kernel code, where such a programming model is possible. The classes of device in which the protocol might run is discussed in [RFC 8993].

T2.

The protocol should be easily extensible in case the initially defined discovery, synchronization, and negotiation mechanisms prove to be insufficient.

T3.

To be a generic platform, the protocol payload format should be independent of the transport protocol or IP version. In particular, it should be able to run over IPv6 or IPv4. However, some functions, such as multicasting on a link, might need to be IP version dependent. By default, IPv6 should be preferred.

T4.

The protocol must be able to access off-link counterparts via routable addresses, i.e., must not be restricted to link-local operation.

T5.

It must also be possible for an external discovery mechanism to be used, if appropriate for a given technical objective. In other words, GRASP discovery must not be a prerequisite for GRASP negotiation or synchronization.

T6.

The protocol must be capable of distinguishing multiple simultaneous operations with one or more peers, especially when wait states occur.

T7.

Intent: Although the distribution of Intent is out of scope for this document, the protocol must not by design exclude its use for Intent distribution.

T8.

Management monitoring, alerts, and intervention: Devices should be able to report to a monitoring system. Some events must be able to generate operator alerts, and some provision for emergency intervention must be possible (e.g., to freeze synchronization or negotiation in a misbehaving device). These features might not use the signaling protocol itself, but its design should not exclude such use.

T9.

Because this protocol may directly cause changes to device configurations and have significant impacts on a running network, all protocol exchanges need to be fully secured against forged messages and man-in-the-middle attacks, and secured as much as reasonably possible against denial-of-service attacks. There must also be an encryption mechanism to resist unwanted monitoring. However, it is not required that the protocol itself provides these security features; it may depend on an existing secure environment.

• Every participating node has a unique node identifier.
• DNCP messages are encoded as a sequence of TLV objects and sent over unicast UDP or TCP, with or without (D)TLS security.
• Multicast is used only for discovery of DNCP neighbors when lower security is acceptable.
• Synchronization of state is maintained by a flooding process using the Trickle algorithm. There is no bilateral synchronization or negotiation capability.
• The HNCP profile of DNCP is designed to operate between directly connected neighbors on a shared link using UDP and link-local IPv6 addresses.

Carsten Bormann

Brian Carpenter

Bing Liu