draft-ietf-anima-grasp-01.txt   draft-ietf-anima-grasp-02.txt 
Network Working Group C. Bormann Network Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track B. Carpenter, Ed. Intended status: Standards Track B. Carpenter, Ed.
Expires: April 11, 2016 Univ. of Auckland Expires: July 16, 2016 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
October 9, 2015 January 13, 2016
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-01 draft-ietf-anima-grasp-02
Abstract Abstract
This document establishes requirements for a signaling protocol that This document establishes requirements for a signaling protocol that
enables autonomic devices and autonomic service agents to dynamically enables autonomic devices and autonomic service agents to dynamically
discover peers, to synchronize state with them, and to negotiate discover peers, to synchronize state with them, and to negotiate
parameter settings mutually with them. The document then defines a parameter settings mutually with them. The document then defines a
general protocol for discovery, synchronization and negotiation, general protocol for discovery, synchronization and negotiation,
while the technical objectives for specific scenarios are to be while the technical objectives for specific scenarios are to be
described in separate documents. An Appendix briefly discusses described in separate documents. An Appendix briefly discusses
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 11, 2016. This Internet-Draft will expire on July 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirement Analysis of Discovery, Synchronization and 2. Requirement Analysis of Discovery, Synchronization and
Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 4
2.2. Requirements for Synchronization and Negotiation 2.2. Requirements for Synchronization and Negotiation
Capability . . . . . . . . . . . . . . . . . . . . . . . 6 Capability . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Specific Technical Requirements . . . . . . . . . . . . . 8 2.3. Specific Technical Requirements . . . . . . . . . . . . . 8
3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 9 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11 3.2. High-Level Design Choices . . . . . . . . . . . . . . . . 11
3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15 3.3. GRASP Protocol Basic Properties and Mechanisms . . . . . 15
3.3.1. Required External Security Mechanism . . . . . . . . 15 3.3.1. Required External Security Mechanism . . . . . . . . 15
3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 15 3.3.2. Transport Layer Usage . . . . . . . . . . . . . . . . 16
3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16 3.3.3. Discovery Mechanism and Procedures . . . . . . . . . 16
3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 18 3.3.4. Negotiation Procedures . . . . . . . . . . . . . . . 18
3.3.5. Synchronization Procedure . . . . . . . . . . . . . . 19 3.3.5. Synchronization and Flooding Procedure . . . . . . . 20
3.4. High Level Deployment Model . . . . . . . . . . . . . . . 20 3.4. High Level Deployment Model . . . . . . . . . . . . . . . 21
3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 20 3.5. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 21
3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 21 3.6. Session Identifier (Session ID) . . . . . . . . . . . . . 22
3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 21 3.7. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 22
3.7.1. GRASP Message Format . . . . . . . . . . . . . . . . 21 3.7.1. GRASP Message Format . . . . . . . . . . . . . . . . 23
3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 22 3.7.2. Discovery Message . . . . . . . . . . . . . . . . . . 23
3.7.3. Response Message . . . . . . . . . . . . . . . . . . 23 3.7.3. Response Message . . . . . . . . . . . . . . . . . . 24
3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 23 3.7.4. Request Message . . . . . . . . . . . . . . . . . . . 25
3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 24 3.7.5. Negotiation Message . . . . . . . . . . . . . . . . . 25
3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 24 3.7.6. Negotiation-ending Message . . . . . . . . . . . . . 26
3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 25 3.7.7. Confirm-waiting Message . . . . . . . . . . . . . . . 26
3.8. GRASP General Options . . . . . . . . . . . . . . . . . . 25 3.7.8. Synchronization Message . . . . . . . . . . . . . . . 26
3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 25 3.7.9. Flood Message . . . . . . . . . . . . . . . . . . . . 27
3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 25 3.7.10. No Operation Message . . . . . . . . . . . . . . . . 27
3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 26 3.8. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 27
3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 26 3.8.1. Format of GRASP Options . . . . . . . . . . . . . . . 27
3.8.5. Waiting Time Option . . . . . . . . . . . . . . . . . 27 3.8.2. Divert Option . . . . . . . . . . . . . . . . . . . . 28
3.8.6. Device Identity Option . . . . . . . . . . . . . . . 27 3.8.3. Accept Option . . . . . . . . . . . . . . . . . . . . 28
3.8.7. Locator Options . . . . . . . . . . . . . . . . . . . 27 3.8.4. Decline Option . . . . . . . . . . . . . . . . . . . 28
3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 29 3.8.5. Device Identity Option . . . . . . . . . . . . . . . 29
3.9.1. Format of Objective Options . . . . . . . . . . . . . 29 3.8.6. Locator Options . . . . . . . . . . . . . . . . . . . 29
3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 30 3.9. Objective Options . . . . . . . . . . . . . . . . . . . . 30
3.9.3. General Considerations for Objective Options . . . . 30 3.9.1. Format of Objective Options . . . . . . . . . . . . . 30
3.9.4. Organizing of Objective Options . . . . . . . . . . . 31 3.9.2. Objective flags . . . . . . . . . . . . . . . . . . . 32
3.9.5. Experimental and Example Objective Options . . . . . 32 3.9.3. General Considerations for Objective Options . . . . 32
4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.9.4. Organizing of Objective Options . . . . . . . . . . . 33
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 3.9.5. Experimental and Example Objective Options . . . . . 34
6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 38 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 42
9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 42 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix A. Capability Analysis of Current Protocols . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 10.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Capability Analysis of Current Protocols . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The success of the Internet has made IP-based networks bigger and The success of the Internet has made IP-based networks bigger and
more complicated. Large-scale ISP and enterprise networks have more complicated. Large-scale ISP and enterprise networks have
become more and more problematic for human based management. Also, become more and more problematic for human based management. Also,
operational costs are growing quickly. Consequently, there are operational costs are growing quickly. Consequently, there are
increased requirements for autonomic behavior in the networks. increased requirements for autonomic behavior in the networks.
General aspects of autonomic networks are discussed in [RFC7575] and General aspects of autonomic networks are discussed in [RFC7575] and
[RFC7576]. A reference model for autonomic networking is given in [RFC7576].
One approach is to largely decentralize the logic of network
management by migrating it into network elements. A reference model
for autonomic networking on this basis is given in
[I-D.behringer-anima-reference-model]. In order to fulfil autonomy, [I-D.behringer-anima-reference-model]. In order to fulfil autonomy,
devices that embody autonomic service agents have specific signaling devices that embody autonomic service agents have specific signaling
requirements. In particular they need to discover each other, to requirements. In particular they need to discover each other, to
synchronize state with each other, and to negotiate parameters and synchronize state with each other, and to negotiate parameters and
resources directly with each other. There is no restriction on the resources directly with each other. There is no restriction on the
type of parameters and resources concerned, which include very basic type of parameters and resources concerned, which include very basic
information needed for addressing and routing, as well as anything information needed for addressing and routing, as well as anything
else that might be configured in a conventional non-autonomic else that might be configured in a conventional non-autonomic
network. The atomic unit of synchronization or negotiation is network. The atomic unit of synchronization or negotiation is
referred to as a technical objective, i.e, a configurable parameter referred to as a technical objective, i.e, a configurable parameter
skipping to change at page 4, line 44 skipping to change at page 4, line 48
expressed as the features needed by an ASA. A single physical device expressed as the features needed by an ASA. A single physical device
might contain several ASAs, and a single ASA might manage several might contain several ASAs, and a single ASA might manage several
technical objectives. technical objectives.
Note that requirements for ASAs themselves, such as the processing of Note that requirements for ASAs themselves, such as the processing of
Intent [RFC7575] or interfaces for coordination between ASAs are out Intent [RFC7575] or interfaces for coordination between ASAs are out
of scope for the present document. of scope for the present document.
2.1. Requirements for Discovery 2.1. Requirements for Discovery
1. ASAs may be designed to manage anything, as required in D1. ASAs may be designed to manage anything, as required in
Section 2.2. A basic requirement is therefore that the protocol can Section 2.2. A basic requirement is therefore that the protocol can
represent and discover any kind of technical objective among represent and discover any kind of technical objective among
arbitrary subsets of participating nodes. arbitrary subsets of participating nodes.
In an autonomic network we must assume that when a device starts up In an autonomic network we must assume that when a device starts up
it has no information about any peer devices, the network structure, it has no information about any peer devices, the network structure,
or what specific role it must play. The ASA(s) inside the device are or what specific role it must play. The ASA(s) inside the device are
in the same situation. In some cases, when a new application session in the same situation. In some cases, when a new application session
starts up within a device, the device or ASA may again lack starts up within a device, the device or ASA may again lack
information about relevant peers. It might be necessary to set up information about relevant peers. It might be necessary to set up
resources on multiple other devices, coordinated and matched to each resources on multiple other devices, coordinated and matched to each
other so that there is no wasted resource. Security settings might other so that there is no wasted resource. Security settings might
also need updating to allow for the new device or user. The relevant also need updating to allow for the new device or user. The relevant
peers may be different for different technical objectives. Therefore peers may be different for different technical objectives. Therefore
discovery needs to be repeated as often as necessary to find peers discovery needs to be repeated as often as necessary to find peers
capable of acting as counterparts for each objective that a discovery capable of acting as counterparts for each objective that a discovery
initiator needs to handle. From this background we derive the next initiator needs to handle. From this background we derive the next
three requirements: three requirements:
2. When an ASA first starts up, it has no knowledge of the specific D2. When an ASA first starts up, it has no knowledge of the specific
network to which it is attached. Therefore the discovery process network to which it is attached. Therefore the discovery process
must be able to support any network scenario, assuming only that the must be able to support any network scenario, assuming only that the
device concerned is bootstrapped from factory condition. device concerned is bootstrapped from factory condition.
3. When an ASA starts up, it must require no information about any D3. When an ASA starts up, it must require no information about any
peers in order to discover them. peers in order to discover them.
4. If an ASA supports multiple technical objectives, relevant peers D4. If an ASA supports multiple technical objectives, relevant peers
may be different for different discovery objectives, so discovery may be different for different discovery objectives, so discovery
needs to be repeated to find counterparts for each objective. Thus, needs to be repeated to find counterparts for each objective. Thus,
there must be a mechanism by which an ASA can separately discover there must be a mechanism by which an ASA can separately discover
peer ASAs for each of the technical objectives that it needs to peer ASAs for each of the technical objectives that it needs to
manage, whenever necessary. manage, whenever necessary.
5. Following discovery, an ASA will normally perform negotiation or D5. Following discovery, an ASA will normally perform negotiation or
synchronization for the corresponding objectives. The design should synchronization for the corresponding objectives. The design should
allow for this by associating discovery, negotiation and allow for this by associating discovery, negotiation and
synchronization objectives. It may provide an optional mechanism to synchronization objectives. It may provide an optional mechanism to
combine discovery and negotiation/synchronization in a single call. combine discovery and negotiation/synchronization in a single call.
6. Some objectives may only be significant on the local link, but D6. Some objectives may only be significant on the local link, but
others may be significant across the routed network and require off- others may be significant across the routed network and require off-
link operations. Thus, the relevant peers might be immediate link operations. Thus, the relevant peers might be immediate
neighbors on the same layer 2 link, or they might be more distant and neighbors on the same layer 2 link, or they might be more distant and
only accessible via layer 3. The mechanism must therefore provide only accessible via layer 3. The mechanism must therefore provide
both on-link and off-link discovery of ASAs supporting specific both on-link and off-link discovery of ASAs supporting specific
technical objectives. technical objectives.
7. The discovery process should be flexible enough to allow for D7. The discovery process should be flexible enough to allow for
special cases, such as the following: special cases, such as the following:
o In some networks, as mentioned above, there will be some o In some networks, as mentioned above, there will be some
hierarchical structure, at least for certain synchronization or hierarchical structure, at least for certain synchronization or
negotiation objectives, but this is unknown in advance. The negotiation objectives, but this is unknown in advance. The
discovery protocol must therefore operate regardless of discovery protocol must therefore operate regardless of
hierarchical structure, which is an attribute of individual hierarchical structure, which is an attribute of individual
technical objectives and not of the autonomic network as a whole. technical objectives and not of the autonomic network as a whole.
This is part of the more general requirement to discover off-link This is part of the more general requirement to discover off-link
peers. peers.
skipping to change at page 6, line 23 skipping to change at page 6, line 29
[I-D.ietf-anima-bootstrapping-keyinfra]. We require that once [I-D.ietf-anima-bootstrapping-keyinfra]. We require that once
trust has been established for a device, all ASAs within the trust has been established for a device, all ASAs within the
device inherit the device's credentials and are also trusted. device inherit the device's credentials and are also trusted.
o Depending on the type of network involved, discovery of other o Depending on the type of network involved, discovery of other
central functions might be needed, such as the Network Operations central functions might be needed, such as the Network Operations
Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol Center (NOC) [I-D.eckert-anima-stable-connectivity]. The protocol
must be capable of supporting such discovery during must be capable of supporting such discovery during
initialisation, as well as discovery during ongoing operation. initialisation, as well as discovery during ongoing operation.
8. The discovery process must not generate excessive (multicast) D8. The discovery process must not generate excessive traffic and
traffic and must take account of sleeping nodes in the case of a must take account of sleeping nodes in the case of a constrained-node
resource-constrained network [RFC7228]. network [RFC7228].
D9. There must be a mechanism for handling stale discovery results.
2.2. Requirements for Synchronization and Negotiation Capability 2.2. Requirements for Synchronization and Negotiation Capability
As background, consider the example of routing protocols, the closest As background, consider the example of routing protocols, the closest
approximation to autonomic networking already in widespread use. approximation to autonomic networking already in widespread use.
Routing protocols use a largely autonomic model based on distributed Routing protocols use a largely autonomic model based on distributed
devices that communicate repeatedly with each other. The focus is devices that communicate repeatedly with each other. The focus is
reachability, so current routing protocols mainly consider simple reachability, so current routing protocols mainly consider simple
link status, i.e., up or down, and an underlying assumption is that link status, i.e., up or down, and an underlying assumption is that
all nodes need a consistent view of the network topology in order for all nodes need a consistent view of the network topology in order for
skipping to change at page 7, line 5 skipping to change at page 7, line 11
autonomic networks need to be able to manage many more dimensions, autonomic networks need to be able to manage many more dimensions,
such as security settings, power saving, load balancing, etc. Status such as security settings, power saving, load balancing, etc. Status
information and traffic metrics need to be shared between nodes for information and traffic metrics need to be shared between nodes for
dynamic adjustment of resources and for monitoring purposes. While dynamic adjustment of resources and for monitoring purposes. While
this might be achieved by existing protocols when they are available, this might be achieved by existing protocols when they are available,
the new protocol needs to be able to support parameter exchange, the new protocol needs to be able to support parameter exchange,
including mutual synchronization, even when no negotiation as such is including mutual synchronization, even when no negotiation as such is
required. In general, these parameters do not apply to all required. In general, these parameters do not apply to all
participating nodes, but only to a subset. participating nodes, but only to a subset.
9. A basic requirement for the protocol is therefore the ability to SN1. A basic requirement for the protocol is therefore the ability
represent, discover, synchronize and negotiate almost any kind of to represent, discover, synchronize and negotiate almost any kind of
network parameter among arbitrary subsets of participating nodes. network parameter among arbitrary subsets of participating nodes.
10. Negotiation is a request/response process that must be SN2. Negotiation is a request/response process that must be
guaranteed to terminate (with success or failure) and if necessary it guaranteed to terminate (with success or failure) and if necessary it
must contain tie-breaking rules for each technical objective that must contain tie-breaking rules for each technical objective that
requires them. While these must be defined specifically for each use requires them. While these must be defined specifically for each use
case, the protocol should have some general mechanisms in support of case, the protocol should have some general mechanisms in support of
loop and deadlock prevention, such as hop count limits or timeouts. loop and deadlock prevention, such as hop count limits or timeouts.
11. Synchronization might concern small groups of nodes or very SN3. Synchronization might concern small groups of nodes or very
large groups. Different solutions might be needed at different large groups. Different solutions might be needed at different
scales. scales.
12. To avoid "reinventing the wheel", the protocol should be able to SN4. To avoid "reinventing the wheel", the protocol should be able
carry the message formats used by existing configuration protocols to carry the message formats used by existing configuration protocols
(such as NETCONF/YANG) in cases where that is convenient. (such as NETCONF/YANG) in cases where that is convenient.
13. Human intervention in complex situations is costly and error- SN5. Human intervention in complex situations is costly and error-
prone. Therefore, synchronization or negotiation of parameters prone. Therefore, synchronization or negotiation of parameters
without human intervention is desirable whenever the coordination of without human intervention is desirable whenever the coordination of
multiple devices can improve overall network performance. It multiple devices can improve overall network performance. It
therefore follows that the protocol, as part of the Autonomic therefore follows that the protocol, as part of the Autonomic
Networking Infrastructure, must be capable of running in any device Networking Infrastructure, must be capable of running in any device
that would otherwise need human intervention. that would otherwise need human intervention.
14. Human intervention in large networks is often replaced by use of SN6. Human intervention in large networks is often replaced by use
a top-down network management system (NMS). It therefore follows of a top-down network management system (NMS). It therefore follows
that the protocol, as part of the Autonomic Networking that the protocol, as part of the Autonomic Networking
Infrastructure, must be capable of running in any device that would Infrastructure, must be capable of running in any device that would
otherwise be managed by an NMS, and that it can co-exist with an NMS, otherwise be managed by an NMS, and that it can co-exist with an NMS,
and with protocols such as SNMP and NETCONF. and with protocols such as SNMP and NETCONF.
15. Some features are expected to be implemented by individual ASAs, SN7. Some features are expected to be implemented by individual
but the protocol must be general enough to allow them: ASAs, but the protocol must be general enough to allow them:
o Dependencies and conflicts: In order to decide a configuration on o Dependencies and conflicts: In order to decide a configuration on
a given device, the device may need information from neighbors. a given device, the device may need information from neighbors.
This can be established through the negotiation procedure, or This can be established through the negotiation procedure, or
through synchronization if that is sufficient. However, a given through synchronization if that is sufficient. However, a given
item in a neighbor may depend on other information from its own item in a neighbor may depend on other information from its own
neighbors, which may need another negotiation or synchronization neighbors, which may need another negotiation or synchronization
procedure to obtain or decide. Therefore, there are potential procedure to obtain or decide. Therefore, there are potential
dependencies and conflicts among negotiation or synchronization dependencies and conflicts among negotiation or synchronization
procedures. Resolving dependencies and conflicts is a matter for procedures. Resolving dependencies and conflicts is a matter for
skipping to change at page 8, line 29 skipping to change at page 8, line 35
actually installing the change. This will be an application of actually installing the change. This will be an application of
the protocol rather than a feature of the protocol itself. the protocol rather than a feature of the protocol itself.
o Management logging, monitoring, alerts and tools for intervention o Management logging, monitoring, alerts and tools for intervention
are required. However, these can only be features of individual are required. However, these can only be features of individual
ASAs. Another document [I-D.eckert-anima-stable-connectivity] ASAs. Another document [I-D.eckert-anima-stable-connectivity]
discusses how such agents may be linked into conventional OAM discusses how such agents may be linked into conventional OAM
systems via an Autonomic Control Plane systems via an Autonomic Control Plane
[I-D.ietf-anima-autonomic-control-plane]. [I-D.ietf-anima-autonomic-control-plane].
16. The protocol will be able to deal with a wide variety of SN8. The protocol will be able to deal with a wide variety of
technical objectives, covering any type of network parameter. technical objectives, covering any type of network parameter.
Therefore the protocol will need either an explicit information model Therefore the protocol will need either an explicit information model
describing its messages, or at least a flexible and easily extensible describing its messages, or at least a flexible and easily extensible
message format. One design consideration is whether to adopt an message format. One design consideration is whether to adopt an
existing information model or to design a new one. existing information model or to design a new one.
2.3. Specific Technical Requirements 2.3. Specific Technical Requirements
17. It should be convenient for ASA designers to define new T1. It should be convenient for ASA designers to define new
technical objectives and for programmers to express them, without technical objectives and for programmers to express them, without
excessive impact on run-time efficiency and footprint. The classes excessive impact on run-time efficiency and footprint. The classes
of device in which the protocol might run is discussed in of device in which the protocol might run is discussed in
[I-D.behringer-anima-reference-model]. [I-D.behringer-anima-reference-model].
18. The protocol should be easily extensible in case the initially T2. The protocol should be easily extensible in case the initially
defined discovery, synchronization and negotiation mechanisms prove defined discovery, synchronization and negotiation mechanisms prove
to be insufficient. to be insufficient.
19. To be a generic platform, the protocol payload format should be T3. To be a generic platform, the protocol payload format should be
independent of the transport protocol or IP version. In particular, independent of the transport protocol or IP version. In particular,
it should be able to run over IPv6 or IPv4. However, some functions, it should be able to run over IPv6 or IPv4. However, some functions,
such as multicasting or broadcasting on a link, might need to be IP such as multicasting on a link, might need to be IP version
version dependent. In case of doubt, IPv6 should be preferred. dependent. In case of doubt, IPv6 should be preferred.
20. The protocol must be able to access off-link counterparts via T4. The protocol must be able to access off-link counterparts via
routable addresses, i.e., must not be restricted to link-local routable addresses, i.e., must not be restricted to link-local
operation. operation.
21. It must also be possible for an external discovery mechanism to T5. It must also be possible for an external discovery mechanism to
be used, if appropriate for a given technical objective. In other be used, if appropriate for a given technical objective. In other
words, GRASP discovery must not be a prerequisite for GRASP words, GRASP discovery must not be a prerequisite for GRASP
negotiation or synchronization; the prerequisite is discovering a negotiation or synchronization; the prerequisite is discovering a
peer's locator by any method. peer's locator by any method.
22. ASAs and the signaling protocol engine need to run T6. ASAs and the signaling protocol need to run asynchronously when
asynchronously when wait states occur. wait states occur.
23. Intent: There must be provision for general Intent rules to be T7. Intent: There must be provision for general Intent rules to be
applied by all devices in the network (e.g., security rules, prefix applied by all devices in the network (e.g., security rules, prefix
length, resource sharing rules). However, Intent distribution might length, resource sharing rules). However, Intent distribution might
not use the signaling protocol itself, but its design should not not use the signaling protocol itself, but its design should not
exclude such use. exclude such use.
24. Management monitoring, alerts and intervention: Devices should T8. Management monitoring, alerts and intervention: Devices should
be able to report to a monitoring system. Some events must be able be able to report to a monitoring system. Some events must be able
to generate operator alerts and some provision for emergency to generate operator alerts and some provision for emergency
intervention must be possible (e.g. to freeze synchronization or intervention must be possible (e.g. to freeze synchronization or
negotiation in a mis-behaving device). These features might not use negotiation in a mis-behaving device). These features might not use
the signaling protocol itself, but its design should not exclude such the signaling protocol itself, but its design should not exclude such
use. use.
25. The protocol needs to be fully secured against forged messages T9. The protocol needs to be fully secured against forged messages
and man-in-the middle attacks, and secured as much as reasonably and man-in-the middle attacks, and secured as much as reasonably
possible against denial of service attacks. It needs to be capable possible against denial of service attacks. It needs to be capable
of encryption in order to resist unwanted monitoring, although this of encryption in order to resist unwanted monitoring. However, it is
capability may not be required in all deployments. However, it is
not required that the protocol itself provides these security not required that the protocol itself provides these security
features; it may depend on an existing secure environment. features; it may depend on an existing secure environment.
3. GRASP Protocol Overview 3. GRASP Protocol Overview
3.1. Terminology 3.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
skipping to change at page 10, line 30 skipping to change at page 10, line 44
interact to agree on the current state of parameter values stored interact to agree on the current state of parameter values stored
in each ASA. This is a special case of negotiation in which in each ASA. This is a special case of negotiation in which
information is sent but the ASAs do not request their peers to information is sent but the ASAs do not request their peers to
change parameter settings. All other definitions apply to both change parameter settings. All other definitions apply to both
negotiation and synchronization. negotiation and synchronization.
o Technical Objective (usually abbreviated as Objective): A o Technical Objective (usually abbreviated as Objective): A
technical objective is a configurable parameter or set of technical objective is a configurable parameter or set of
parameters of some kind, which occurs in three contexts: parameters of some kind, which occurs in three contexts:
Discovery, Negotiation and Synchronization. In the protocol, an Discovery, Negotiation and Synchronization. In the protocol, an
objective is represented by an identifier (actually a GRASP option objective is represented by an identifier and if relevant a value.
number) and if relevant a value. Normally, a given objective will Normally, a given objective will occur during discovery and
occur during discovery and negotiation, or during discovery and negotiation, or during discovery and synchronization, but not in
synchronization, but not in all three contexts. all three contexts.
* One ASA may support multiple independent objectives. * One ASA may support multiple independent objectives.
* The parameter described by a given objective is naturally based * The parameter described by a given objective is naturally based
on a specific service or function or action. It may in on a specific service or function or action. It may in
principle be anything that can be set to a specific logical, principle be anything that can be set to a specific logical,
numerical or string value, or a more complex data structure, by numerical or string value, or a more complex data structure, by
a network node. That node is generally expected to contain an a network node. That node is generally expected to contain an
ASA which may itself manage other nodes. ASA which may itself manage other nodes.
skipping to change at page 11, line 36 skipping to change at page 11, line 49
o Negotiation Counterpart: a peer with which the Negotiation o Negotiation Counterpart: a peer with which the Negotiation
Initiator negotiates a specific negotiation objective. Initiator negotiates a specific negotiation objective.
3.2. High-Level Design Choices 3.2. High-Level Design Choices
This section describes a behavior model and some considerations for This section describes a behavior model and some considerations for
designing a generic signaling protocol initially supporting designing a generic signaling protocol initially supporting
discovery, synchronization and negotiation, which can act as a discovery, synchronization and negotiation, which can act as a
platform for different technical objectives. platform for different technical objectives.
NOTE: An earlier version of this protocol used type-length-value
formats and was prototyped by Huawei and the Beijing University of
Posts and Telecommunications.
o A generic platform o A generic platform
The protocol is designed as a generic platform, which is The protocol is designed as a generic platform, which is
independent from the synchronization or negotiation contents. It independent from the synchronization or negotiation contents. It
takes care of the general intercommunication between counterparts. takes care of the general intercommunication between counterparts.
The technical contents will vary according to the various The technical contents will vary according to the various
technical objectives and the different pairs of counterparts. technical objectives and the different pairs of counterparts.
o The protocol is expected to form part of an Autonomic Networking o The protocol is expected to form part of an Autonomic Networking
Infrastructure [I-D.behringer-anima-reference-model]. It will Infrastructure [I-D.behringer-anima-reference-model]. It will
provide services to ASAs via a suitable application programming provide services to ASAs via a suitable application programming
interface, which will reflect the protocol elements but will not interface, which will reflect the protocol elements but will not
skipping to change at page 12, line 5 skipping to change at page 12, line 15
independent from the synchronization or negotiation contents. It independent from the synchronization or negotiation contents. It
takes care of the general intercommunication between counterparts. takes care of the general intercommunication between counterparts.
The technical contents will vary according to the various The technical contents will vary according to the various
technical objectives and the different pairs of counterparts. technical objectives and the different pairs of counterparts.
o The protocol is expected to form part of an Autonomic Networking o The protocol is expected to form part of an Autonomic Networking
Infrastructure [I-D.behringer-anima-reference-model]. It will Infrastructure [I-D.behringer-anima-reference-model]. It will
provide services to ASAs via a suitable application programming provide services to ASAs via a suitable application programming
interface, which will reflect the protocol elements but will not interface, which will reflect the protocol elements but will not
necessarily be in one-to-one correspondence to them. It is necessarily be in one-to-one correspondence to them. It is
expected that the protocol engine and each ASA will run as expected that a single instance of GRASP will exist in an
independent asynchronous processes. autonomic node, and that the protocol engine and each ASA will run
as independent asynchronous processes.
o Security infrastructure and trust relationship o Security infrastructure and trust relationship
Because this negotiation protocol may directly cause changes to Because this negotiation protocol may directly cause changes to
device configurations and bring significant impacts to a running device configurations and bring significant impacts to a running
network, this protocol is assumed to run within an existing secure network, this protocol is assumed to run within an existing secure
environment with strong authentication. environment with strong authentication.
On the other hand, a limited negotiation model might be deployed On the other hand, a limited negotiation model might be deployed
based on a limited trust relationship. For example, between two based on a limited trust relationship. For example, between two
skipping to change at page 15, line 10 skipping to change at page 15, line 19
next (deadlock resolution, tie-breaking, or revert to best- next (deadlock resolution, tie-breaking, or revert to best-
effort service). Again, this MUST be specified for individual effort service). Again, this MUST be specified for individual
negotiation objectives, as an implementation choice, a pre- negotiation objectives, as an implementation choice, a pre-
configurable parameter, or network Intent. configurable parameter, or network Intent.
3.3. GRASP Protocol Basic Properties and Mechanisms 3.3. GRASP Protocol Basic Properties and Mechanisms
3.3.1. Required External Security Mechanism 3.3.1. Required External Security Mechanism
The protocol SHOULD run within a secure Autonomic Control Plane (ACP) The protocol SHOULD run within a secure Autonomic Control Plane (ACP)
[I-D.ietf-anima-autonomic-control-plane]. The ACP MUST provide a [I-D.ietf-anima-autonomic-control-plane]. The ACP is assumed to
status indicator to inform GRASP that the ACP is operational. carry all messages securely, including link-local multicast if
possible. A GRASP implementation MUST verify whether the ACP is
operational.
If there is no ACP, the protocol MUST use another form of strong If there is no ACP, the protocol MUST use another form of strong
authentication and SHOULD use a form of strong encryption. TLS authentication and SHOULD use a form of strong encryption. TLS
[RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based [RFC5246] is RECOMMENDED for this purpose, based on a local Public
on a local Public Key Infrastructure (PKI) [RFC5280] managed within Key Infrastructure (PKI) [RFC5280] managed within the autonomic
the autonomic network itself. network itself. The details of such a PKI and how its boundary is
established are out of scope for this document. DTLS [RFC6347] MAY
be used but since GRASP operations usually involve several messages
this is not expected to be advantageous.
Link-local multicast is used for discovery messages. It is expected The ACP, or in its absence the local PKI, sets the boundary within
that the ACP will handle these and distribute them securely to all which nodes are trusted as GRASP peers. A GRASP implementation MUST
on-link ACP nodes only. However, in the absence of an ACP they refuse to execute any GRASP functions except discovery if there is
cannot be secured. Responses to discovery messages MUST be secured. neither an operational ACP nor an operational (D)TLS environment.
During initialisation, before a node has joined the applicable trust As mentioned in Section 3.2, limited GRASP operations might be
infrastructure, e.g., [I-D.ietf-anima-bootstrapping-keyinfra], it performed across an administrative domain boundary by mutual
might be impossible to secure certain messages. Such messages MUST agreement. Such operations MUST be authenticated and SHOULD be
be limited to the strictly necessary minimum. A full analysis of the encrypted. TLS is RECOMMENDED for this purpose.
secure bootstrap process is out of scope for the present document.
Link-local multicast is used for discovery messages. Responses to
discovery messages MUST be secured, with one exception.
The exception is that during initialisation, before a node has joined
the applicable trust infrastructure, e.g.,
[I-D.ietf-anima-bootstrapping-keyinfra], or before the ACP is fully
established, it might be impossible to secure messages. Indeed, both
the security bootstrap process and the ACP creation process might use
insecure GRASP discovery and response messages. Such usage MUST be
limited to the strictly necessary minimum. A full analysis of the
initialisation process is out of scope for the present document.
3.3.2. Transport Layer Usage 3.3.2. Transport Layer Usage
The protocol is capable of running over UDP or TCP, except for link- The protocol is capable of running over UDP or TCP, except for link-
local multicast discovery messages, which can only run over UDP and local multicast discovery messages, which can only run over UDP and
MUST NOT be fragmented, and therefore cannot exceed the link MTU MUST NOT be fragmented, and therefore cannot exceed the link MTU
size. size.
When running within a secure ACP, UDP SHOULD be used for messages not When running within a secure ACP, UDP SHOULD be used for messages not
exceeding the minimum IPv6 path MTU, and TCP MUST be used for longer exceeding the minimum IPv6 path MTU, and TCP MUST be used for longer
messages. In other words, IPv6 fragmentation is avoided. If a node messages. In other words, IPv6 fragmentation is avoided. If a node
receives a UDP message but the reply is too long, it MUST open a TCP receives a UDP message but the reply is too long, it MUST open a TCP
connection to the peer for the reply. connection to the peer for the reply.
When running without an ACP, TLS MUST be supported and used by When running without an ACP, TLS SHOULD be supported and used by
default, except for multicast discovery messages. DTLS MAY be default, except for multicast discovery messages. DTLS MAY be
supported as an alternative but the details are out of scope for this supported as an alternative but the details are out of scope for this
document. document.
For all transport protocols, the GRASP protocol listens to the GRASP For all transport protocols, the GRASP protocol listens to the GRASP
Listen Port (Section 3.5). Listen Port (Section 3.5).
3.3.3. Discovery Mechanism and Procedures 3.3.3. Discovery Mechanism and Procedures
o Separated discovery and negotiation mechanisms o Separated discovery and negotiation mechanisms
Although discovery and negotiation or synchronization are Although discovery and negotiation or synchronization are
defined together in the GRASP, they are separated mechanisms. defined together in the GRASP, they are separated mechanisms.
The discovery process could run independently from the The discovery process could run independently from the
negotiation or synchronization process. Upon receiving a negotiation or synchronization process. Upon receiving a
discovery (Section 3.7.2) or request (Section 3.7.4) message, discovery (Section 3.7.2) message, the recipient ASA should
the recipient ASA should return a message in which it either return a message in which it either indicates itself as a
indicates itself as a discovery responder or diverts the discovery responder or diverts the initiator towards another
initiator towards another more suitable ASA. more suitable ASA.
The discovery action will normally be followed by a negotiation The discovery action will normally be followed by a negotiation
or synchronization action. The discovery results could be or synchronization action. The discovery results could be
utilized by the negotiation protocol to decide which ASA the utilized by the negotiation protocol to decide which ASA the
initiator will negotiate with. initiator will negotiate with.
It is entirely possible to use GRASP discovery without a
subsequent negotiation or synchronization action. In this
case, the discovered objective is simply used as a name during
the discovery process and any subsequent operations between the
peers are outside the scope of GRASP.
o Discovery Procedures o Discovery Procedures
Discovery starts as an on-link operation. The Divert option Discovery starts as an on-link operation. The Divert option
can tell the discovery initiator to contact an off-link ASA for can tell the discovery initiator to contact an off-link ASA for
that discovery objective. Every Discovery message is sent by a that discovery objective. Every Discovery message is sent by a
discovery initiator via UDP to the ALL_GRASP_NEIGHBOR multicast discovery initiator via UDP to the ALL_GRASP_NEIGHBOR multicast
address (Section 3.5). Every network device that supports the address (Section 3.5). Every network device that supports the
GRASP always listens to a well-known UDP port to capture the GRASP always listens to a well-known UDP port to capture the
discovery messages. discovery messages.
skipping to change at page 17, line 11 skipping to change at page 17, line 42
Responder supporting a specific objective, it MUST cache this Responder supporting a specific objective, it MUST cache this
information. This cache record MAY be used for future information. This cache record MAY be used for future
negotiation or synchronization, and SHOULD be passed on when negotiation or synchronization, and SHOULD be passed on when
appropriate as a Divert option to another Discovery Initiator. appropriate as a Divert option to another Discovery Initiator.
The cache lifetime is an implementation choice that MAY be The cache lifetime is an implementation choice that MAY be
modified by network Intent. modified by network Intent.
If multiple Discovery Responders are found for the same If multiple Discovery Responders are found for the same
objective, they SHOULD all be cached, unless this creates a objective, they SHOULD all be cached, unless this creates a
resource shortage. The method of choosing between multiple resource shortage. The method of choosing between multiple
responders is an implementation choice. responders is an implementation choice. This choice MUST be
available to each ASA but the GRASP implementation SHOULD
provide a default choice.
Because Discovery Responders will be cached in a finite cache,
they might be deleted at any time. In this case, discovery
will need to be repeated. If an ASA exits for any reason, its
locator might still be cached for some time, and attempts to
connect to it will fail. ASAs need to be robust in these
circumstances.
A GRASP device with multiple link-layer interfaces (typically a A GRASP device with multiple link-layer interfaces (typically a
router) MUST support discovery on all interfaces. If it router) MUST support discovery on all interfaces. If it
receives a Discovery message on a given interface for a receives a Discovery message on a given interface for a
specific objective that it does not support and for which it specific objective that it does not support and for which it
has not previously discovered a Discovery Responder, it MUST has not previously discovered a Discovery Responder, it MUST
relay the query by re-issuing the same Discovery message on its relay the query by re-issuing a Discovery message on its other
other interfaces. Before this, it MUST decrement the loop interfaces. The relayed message MAY have a different Session
count within the objective, and discard the Discovery message ID. Before this, it MUST decrement the loop count within the
if the result is zero. Also, it MUST limit the total rate at objective, and MUST NOT relay the Discovery message if the
which it relays discovery messages to a reasonable value, in result is zero. Also, it MUST limit the total rate at which it
order to mitigate possible denial of service attacks. It MUST relays discovery messages to a reasonable value, in order to
cache the Session ID value of each relayed discovery message mitigate possible denial of service attacks. It MUST cache the
and, to prevent loops, MUST NOT relay a Discovery message which Session ID value of each relayed discovery message and, to
carries such a cached Session ID. These precautions avoid prevent loops, MUST NOT relay a Discovery message which carries
discovery loops and mitigate potential overload. such a cached Session ID. These precautions avoid discovery
loops and mitigate potential overload.
This relayed discovery mechanism, with caching of the results, This relayed discovery mechanism, with caching of the results,
should be sufficient to support most network bootstrapping should be sufficient to support most network bootstrapping
scenarios. scenarios.
o A complete discovery process will start with multicast on the o A complete discovery process will start with multicast on the
local link; a neighbor might divert it to an off-link destination, local link; a neighbor might divert it to an off-link destination,
which could be a default higher-level gateway in a hierarchical which could be a default higher-level gateway in a hierarchical
network. Then discovery would continue with a unicast to that network. Then discovery would continue with a unicast to that
gateway; if that gateway is still not the right counterpart, it gateway; if that gateway is still not the right counterpart, it
should divert to another gateway, which is in principle closer to should divert to another gateway, which is in principle closer to
the right counterpart. Finally the right counterpart responds to the right counterpart. Finally the right counterpart responds to
start the negotiation or synchronization process. start the negotiation or synchronization process.
o Rapid Mode (Discovery/Negotiation binding) o Rapid Mode (Discovery/Negotiation binding)
A Discovery message MAY include one or more Negotiation A Discovery message MAY include a Negotiation Objective option.
Objective option(s). This allows a rapid mode of negotiation This allows a rapid mode of negotiation described in
described in Section 3.3.4. A similar mechanism is defined for Section 3.3.4. A similar mechanism is defined for
synchronization in Section 3.3.5. synchronization in Section 3.3.5.
3.3.4. Negotiation Procedures 3.3.4. Negotiation Procedures
A negotiation initiator sends a negotiation request to a counterpart A negotiation initiator sends a negotiation request to a counterpart
ASA, including a specific negotiation objective. It may request the ASA, including a specific negotiation objective. It may request the
negotiation counterpart to make a specific configuration. negotiation counterpart to make a specific configuration.
Alternatively, it may request a certain simulation or forecast result Alternatively, it may request a certain simulation or forecast result
by sending a dry run configuration. The details, including the by sending a dry run configuration. The details, including the
distinction between dry run and an actual configuration change, will distinction between dry run and an actual configuration change, will
skipping to change at page 18, line 43 skipping to change at page 19, line 33
if a timeout is exceeded or a loop count is exceeded. if a timeout is exceeded or a loop count is exceeded.
A negotiation procedure concerns one objective and one counterpart. A negotiation procedure concerns one objective and one counterpart.
Both the initiator and the counterpart may take part in simultaneous Both the initiator and the counterpart may take part in simultaneous
negotiations with various other ASAs, or in simultaneous negotiations negotiations with various other ASAs, or in simultaneous negotiations
about different objectives. Thus, GRASP is expected to be used in a about different objectives. Thus, GRASP is expected to be used in a
multi-threaded mode. Certain negotiation objectives may have multi-threaded mode. Certain negotiation objectives may have
restrictions on multi-threading, for example to avoid over-allocating restrictions on multi-threading, for example to avoid over-allocating
resources. resources.
Rapid Mode (Discovery/Negotiation linkage) Some configuration actions, for example wavelength switching in
optical networks, might take considerable time to execute. The ASA
concerned needs to allow for this by design, but GRASP does allow for
a peer to insert latency in a negotiation process if necessary
(Section 3.7.7).
A Discovery message MAY include a Negotiation Objective option. 3.3.4.1. Rapid Mode (Discovery/Negotiation Linkage)
In this case the Discovery message also acts as a Request message
to indicate to the Discovery Responder that it could directly
reply to the Discovery Initiator with a Negotiation message for
rapid processing, if it could act as the corresponding negotiation
counterpart. However, the indication is only advisory not
prescriptive.
This rapid mode could reduce the interactions between nodes so A Discovery message MAY include a Negotiation Objective option. In
that a higher efficiency could be achieved. This rapid this case the Discovery message also acts as a Request message to
negotiation function SHOULD be configured off by default and MAY indicate to the Discovery Responder that it could directly reply to
be configured on or off by Intent. the Discovery Initiator with a Negotiation message for rapid
processing, if it could act as the corresponding negotiation
counterpart. However, the indication is only advisory not
prescriptive.
3.3.5. Synchronization Procedure This rapid mode could reduce the interactions between nodes so that a
higher efficiency could be achieved. This rapid negotiation function
SHOULD be configured off by default and MAY be configured on or off
by Intent.
3.3.5. Synchronization and Flooding Procedure
A synchronization initiator sends a synchronization request to a A synchronization initiator sends a synchronization request to a
counterpart, including a specific synchronization objective. The counterpart, including a specific synchronization objective. The
counterpart responds with a Response message containing the current counterpart responds with a Synchronization message (Section 3.7.8)
value of the requested synchronization objective. No further containing the current value of the requested synchronization
messages are needed. objective. No further messages are needed.
If no reply message of any kind is received within a reasonable If no reply message of any kind is received within a reasonable
timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.5), the
synchronization request MAY be repeated, with a newly generated synchronization request MAY be repeated, with a newly generated
Session ID (Section 3.6). An exponential backoff SHOULD be used for Session ID (Section 3.6). An exponential backoff SHOULD be used for
subsequent repetitions. subsequent repetitions.
3.3.5.1. Flooding
In the case just described, the message exchange is unicast and In the case just described, the message exchange is unicast and
concerns only one synchronization objective. For large groups of concerns only one synchronization objective. For large groups of
nodes requiring the same data, synchronization flooding is available. nodes requiring the same data, synchronization flooding is available.
For this, a synchronization responder MAY send an unsolicited For this, a flooding initiator MAY send an unsolicited Flood message
Response message containing one or more Synchronization Objective containing one or more Synchronization Objective option(s), if and
option(s), if and only if the specification of those objectives only if the specification of those objectives permits it. This is
permits it. This is sent as a multicast message to the sent as a multicast message to the ALL_GRASP_NEIGHBOR multicast
ALL_GRASP_NEIGHBOR multicast address (Section 3.5). To ensure that address (Section 3.5). To ensure that flooding does not result in a
flooding does not result in a loop, the originator of the Response loop, the originator of the Flood message MUST set the loop count in
message MUST set the loop count in the objective to a suitable value the objectives to a suitable value (the default is GRASP_DEF_LOOPCT).
(the default is GRASP_DEF_LOOPCT). In this case a suitable mechanism In this case a suitable mechanism is needed to avoid excessive
is needed to avoid excessive multicast traffic. This mechanism MUST multicast traffic. This mechanism MUST be defined as part of the
be defined as part of the specification of the synchronization specification of the synchronization objective(s) concerned. It
objective(s) concerned. It might be a simple rate limit or a more might be a simple rate limit or a more complex mechanism such as the
complex mechanism such as the Trickle algorithm [RFC6206]. Trickle algorithm [RFC6206].
A GRASP device with multiple link-layer interfaces (typically a A GRASP device with multiple link-layer interfaces (typically a
router) MUST support synchronization flooding on all interfaces. If router) MUST support synchronization flooding on all interfaces. If
it receives a multicast unsolicited Response message on a given it receives a multicast Flood message on a given interface, it MUST
interface, it MUST relay it by re-issuing the same Response message relay it by re-issuing a Flood message on its other interfaces. The
on its other interfaces. Before this, it MUST decrement the loop relayed message MAY have a different Session ID. Before this, it
count within the objective, and discard the Response message if the MUST decrement the loop count within the objective, and MUST NOT
result is zero. Also, it MUST limit the total rate at which it relay the Flood message if the result is zero. Also, it MUST limit
relays Response messages to a reasonable value, in order to mitigate the total rate at which it relays Flood messages to a reasonable
possible denial of service attacks. It MUST cache the Session ID value, in order to mitigate possible denial of service attacks. It
value of each relayed Response message and, to prevent loops, MUST MUST cache the Session ID value of each relayed Flood message and, to
NOT relay a Response message which carries such a cached Session ID. prevent loops, MUST NOT relay a Flood message which carries such a
These precautions avoid synchronization loops and mitigate potential cached Session ID. These precautions avoid synchronization loops and
overload. mitigate potential overload.
Note that this mechanism is unreliable in the case of sleeping nodes. Note that this mechanism is unreliable in the case of sleeping nodes.
Sleeping nodes that require an objective subject to synchronization Sleeping nodes that require an objective subject to flooding SHOULD
flooding SHOULD periodically initiate normal synchronization for that periodically request unicast synchronization for that objective.
objective.
Rapid Mode (Discovery/Synchronization linkage) The multicast messages for synchronization flooding are subject to
the security rules in Section 3.3.1. In practice this means that
they MUST NOT be transmitted and MUST be ignored on receipt unless
there is an operational ACP.
A Discovery message MAY include one or more Synchronization 3.3.5.2. Rapid Mode (Discovery/Synchronization Linkage)
Objective option(s). In this case the Discovery message also acts
as a Request message to indicate to the Discovery Responder that
it could directly reply to the Discovery Initiator with a Response
message with synchronization data for rapid processing, if the
discovery target supports the corresponding synchronization
objective(s). However, the indication is only advisory not
prescriptive.
This rapid mode could reduce the interactions between nodes so A Discovery message MAY include a Synchronization Objective option.
that a higher efficiency could be achieved. This rapid In this case the Discovery message also acts as a Request message to
synchronization function SHOULD be configured off by default and indicate to the Discovery Responder that it could directly reply to
MAY be configured on or off by Intent. the Discovery Initiator with a Synchronization message Section 3.7.8
with synchronization data for rapid processing, if the discovery
target supports the corresponding synchronization objective.
However, the indication is only advisory not prescriptive.
This rapid mode could reduce the interactions between nodes so that a
higher efficiency could be achieved. This rapid synchronization
function SHOULD be configured off by default and MAY be configured on
or off by Intent.
3.4. High Level Deployment Model 3.4. High Level Deployment Model
It is expected that a GRASP implementation will reside in an It is expected that a GRASP implementation will reside in an
autonomic node that also contains both the appropriate security autonomic node that also contains both the appropriate security
environment (preferably the ACP) and one or more Autonomic Service environment (preferably the ACP) and one or more Autonomic Service
Agents (ASAs). In the minimal case of a single-purpose device, these Agents (ASAs). In the minimal case of a single-purpose device, these
three components might be fully integrated. A more common model is three components might be fully integrated. A more common model is
expected to be a multi-purpose device capable of containing several expected to be a multi-purpose device capable of containing several
ASAs. In this case it is expected that the ACP, GRASP and the ASAs ASAs. In this case it is expected that the ACP, GRASP and the ASAs
skipping to change at page 21, line 25 skipping to change at page 22, line 28
o GRASP_DEF_LOOPCT (6) o GRASP_DEF_LOOPCT (6)
The default loop count used to determine that a negotiation has The default loop count used to determine that a negotiation has
failed to complete, and to avoid looping messages. failed to complete, and to avoid looping messages.
3.6. Session Identifier (Session ID) 3.6. Session Identifier (Session ID)
This is an up to 24-bit opaque value used to distinguish multiple This is an up to 24-bit opaque value used to distinguish multiple
sessions between the same two devices. A new Session ID MUST be sessions between the same two devices. A new Session ID MUST be
generated for every new Discovery or Request message, and for every generated by the initiator for every new Discovery, Flood or Request
unsolicited Response message. All follow-up messages in the same message. All responses and follow-up messages in the same discovery,
discovery, synchronization or negotiation procedure, which is synchronization or negotiation procedure MUST carry the same Session
initiated by the request message, MUST carry the same Session ID. ID.
The Session ID SHOULD have a very low collision rate locally. It The Session ID SHOULD have a very low collision rate locally. It
MUST be generated by a pseudo-random algorithm using a locally MUST be generated by a pseudo-random algorithm using a locally
generated seed which is unlikely to be used by any other device in generated seed which is unlikely to be used by any other device in
the same network [RFC4086]. the same network [RFC4086].
However, there is a finite probability that two nodes might generate
the same Session ID value. For that reason, when a Session ID is
communicated via GRASP, the receiving node MUST tag it with the
initiator's IP address to allow disambiguation. Multicast GRASP
messages and their responses, which may be relayed between links,
therefore include a field that carries the initiator's global IP
address.
3.7. GRASP Messages 3.7. GRASP Messages
This section defines the GRASP message format and message types. This section defines the GRASP message format and message types.
Message types not listed here are reserved for future use. Message types not listed here are reserved for future use.
3.7.1. GRASP Message Format 3.7.1. GRASP Message Format
GRASP messages share an identical header format and a variable format GRASP messages share an identical header format and a variable format
area for options. GRASP message headers and options are transmitted area for options. GRASP message headers and options are transmitted
in Concise Binary Object Representation (CBOR) [RFC7049]. In this in Concise Binary Object Representation (CBOR) [RFC7049]. In this
specification, they are described using CBOR data definition language specification, they are described using CBOR data definition language
(CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is (CDDL) [I-D.greevenbosch-appsawg-cbor-cddl]. Fragmentary CDDL is
used to describe each item in this section. A complete and normative used to describe each item in this section. A complete and normative
CDDL specification of GRASP is given in Section 6. CDDL specification of GRASP is given in Section 6, including
constants such as message types.
Every GRASP message carries a Session ID (Section 3.6). Options are Every GRASP message, except the No Operation message, carries a
then presented serially in the options field. Session ID (Section 3.6). Options are then presented serially in the
options field.
In fragmentary CDDL, every GRASP message follows the pattern: In fragmentary CDDL, every GRASP message follows the pattern:
message /= [MESSAGE_TYPE, session-id, *option] grasp-message = (message .within message-structure) / noop-message
MESSAGE_TYPE = ; a defined constant message-structure = [MESSAGE_TYPE, session-id, +grasp-option]
session-id = 0..16777215
option /= ; one of the options defined below MESSAGE_TYPE = 1..255
session-id = 0..16777215 ;up to 24 bits
grasp-option = any
The MESSAGE_TYPE indicates the type of the message and thus defines
the expected options. Any options received that are not consistent
with the MESSAGE_TYPE SHOULD be silently discarded.
The No Operation (noop) message is described in Section 3.7.10.
The various MESSAGE_TYPE values are defined in Section 6.
All other message elements are described below and formally defined
in Section 6.
3.7.2. Discovery Message 3.7.2. Discovery Message
In fragmentary CDDL, a Discovery message follows the pattern: In fragmentary CDDL, a Discovery message follows the pattern:
discovery-message = [M_DISCOVERY, session-id, objective] discovery-message = [M_DISCOVERY, session-id, initiator, objective]
M_DISCOVERY = ; a defined constant
session-id = 0..16777215
objective /= ; defined below
A discovery initiator sends a Discovery message to initiate a A discovery initiator sends a Discovery message to initiate a
discovery process. discovery process for a particular objective option.
The discovery initiator sends the Discovery messages to the link- The discovery initiator sends the Discovery messages to the link-
local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores local ALL_GRASP_NEIGHBOR multicast address for discovery, and stores
the discovery results (including responding discovery objectives and the discovery results (including responding discovery objectives and
corresponding unicast addresses or FQDNs). corresponding unicast addresses, FQDNs or URIs).
The 'initiator' field in the message is a globally unique IP address
of the initiator, for the sole purpose of disambiguating the Session
ID in other nodes. If for some reason the initiator does not have a
globally unique IP address, it MUST use a link-local address for this
purpose that is highly likely to be unique, for example using
[RFC7217].
A Discovery message MUST include exactly one of the following: A Discovery message MUST include exactly one of the following:
o a discovery objective option (Section 3.9.1). Its loop count must o a discovery objective option (Section 3.9.1). Its loop count MUST
be set to a suitable value to prevent discovery loops (default be set to a suitable value to prevent discovery loops (default
value is GRASP_DEF_LOOPCT). value is GRASP_DEF_LOOPCT).
o a negotiation objective option (Section 3.9.1) to indicate to the o a negotiation objective option (Section 3.9.1). This is used both
discovery target that it MAY directly reply to the discovery for the purpose of discovery and to indicate to the discovery
initiatior with a Negotiation message for rapid processing, if it target that it MAY directly reply to the discovery initiatior with
could act as the corresponding negotiation counterpart. The a Negotiation message for rapid processing, if it could act as the
sender of such a Discovery message MUST initialize a negotiation corresponding negotiation counterpart. The sender of such a
timer and loop count in the same way as a Request message Discovery message MUST initialize a negotiation timer and loop
(Section 3.7.4). count in the same way as a Request message (Section 3.7.4).
o one or more synchronization objective options (Section 3.9.1) to o a synchronization objective option (Section 3.9.1). This is used
indicate to the discovery target that it MAY directly reply to the both for the purpose of discovery and to indicate to the discovery
discovery initiator with a Response message for rapid processing, target that it MAY directly reply to the discovery initiator with
if it could act as the corresponding synchronization counterpart. 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).
3.7.3. Response Message 3.7.3. Response Message
In fragmentary CDDL, a Response message follows the pattern: In fragmentary CDDL, a Response message follows the pattern:
response-message = [M_RESPONSE, session-id, response-message = [M_RESPONSE, session-id, initiator,
(+locator-option // divert-option // objective)] (+locator-option // divert-option), ?objective)]
M_RESPONSE = ; a defined constant
session-id = 0..16777215
locator-option /= ; defined below
divert-option = ; defined below
objective /= ; defined below
A node which receives a Discovery message sends a Response message to A node which receives a Discovery message SHOULD send a Response
respond to a discovery. It MUST contain the same Session ID as the message if and only if it can respond to the discovery. It MUST
Discovery message. It MAY include a copy of the discovery objective contain the same Session ID and initiator as the Discovery message.
from the Discovery message. It MAY include a copy of the discovery objective from the Discovery
message.
If the responding node supports the discovery objective of the If the responding node supports the discovery objective of the
discovery, it MUST include at least one kind of locator option discovery, it MUST include at least one kind of locator option
(Section 3.8.7) to indicate its own location. A combination of (Section 3.8.6) to indicate its own location. A sequence of multiple
multiple kinds of locator options (e.g. IP address option + FQDN kinds of locator options (e.g. IP address option + FQDN option) is
option) is also valid. also valid.
If the responding node itself does not support the discovery If the responding node itself does not support the discovery
objective, but it knows the locator of the discovery objective, then objective, but it knows the locator of the discovery objective, then
it SHOULD respond to the discovery message with a divert option it SHOULD respond to the discovery message with a divert option
(Section 3.8.2) embedding a locator option or a combination of (Section 3.8.2) embedding a locator option or a combination of
multiple kinds of locator options which indicate the locator(s) of multiple kinds of locator options which indicate the locator(s) of
the discovery objective. the discovery objective.
A node which receives a synchronization request sends a Response
message with the synchronization data, in the form of GRASP Option(s)
for the specific synchronization objective(s).
3.7.4. Request Message 3.7.4. Request Message
In fragmentary CDDL, a Request message follows the pattern: In fragmentary CDDL, a Request message follows the pattern:
discovery-message = [M_REQUEST, session-id, objective] request-message = [M_REQUEST, session-id, objective]
M_REQUEST = ; a defined constant
session-id = 0..16777215
objective /= ; defined below
A negotiation or synchronization requesting node sends the Request A negotiation or synchronization requesting node sends the Request
message to the unicast address (directly stored or resolved from the message to the unicast address (directly stored or resolved from an
FQDN) of the negotiation or synchronization counterpart (selected FQDN) of the negotiation or synchronization counterpart (selected
from the discovery results). from the discovery results).
A request message MUST include the relevant objective option, with A request message MUST include the relevant objective option, with
the requested value in the case of negotiation. the requested value in the case of negotiation.
When an initiator sends a Request message, it MUST initialize a When an initiator sends a Request message, it MUST initialize a
negotiation timer for the new negotiation thread with the value negotiation timer for the new negotiation thread with the value
GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is modified by a
Confirm-waiting message (Section 3.7.7), the initiator will consider Confirm-waiting message (Section 3.7.7), the initiator will consider
that the negotiation has failed when the timer expires. that the negotiation has failed when the timer expires.
When an initiator sends a Request message, it MUST initialize the When an initiator sends a Request message, it MUST initialize the
loop count of the objective option with a value defined in the loop count of the objective option with a value defined in the
specification of the option or, if no such value is specified, with specification of the option or, if no such value is specified, with
GRASP_DEF_LOOPCT. GRASP_DEF_LOOPCT.
If a node receives a Request message for an objective for which no
ASA is currently listening, it MUST immediately close the relevant
socket to indicate this to the initiator.
3.7.5. Negotiation Message 3.7.5. Negotiation Message
In fragmentary CDDL, a Negotiation message follows the pattern: In fragmentary CDDL, a Negotiation message follows the pattern:
discovery-message = [M_NEGOTIATE, session-id, objective] discovery-message = [M_NEGOTIATE, session-id, objective]
M_NEGOTIATE = ; a defined constant
session-id = 0..16777215
objective /= ; defined below
A negotiation counterpart sends a Negotiation message in response to A negotiation counterpart sends a Negotiation message in response to
a Request message, a Negotiation message, or a Discovery message in a Request message, a Negotiation message, or a Discovery message in
Rapid Mode. A negotiation process MAY include multiple steps. Rapid Mode. A negotiation process MAY include multiple steps.
The Negotiation message MUST include the relevant Negotiation The Negotiation message MUST include the relevant Negotiation
Objective option, with its value updated according to progress in the Objective option, with its value updated according to progress in the
negotiation. The sender MUST decrement the loop count by 1. If the negotiation. The sender MUST decrement the loop count by 1. If the
loop count becomes zero both parties will consider that the loop count becomes zero the message MUST NOT be sent. In this case
negotiation has failed. the negotiation session has failed and will time out.
3.7.6. Negotiation-ending Message 3.7.6. Negotiation-ending Message
In fragmentary CDDL, a Negotiation-ending message follows the In fragmentary CDDL, a Negotiation-ending message follows the
pattern: pattern:
end-message = [M_END, session-id, accept-option / decline-option] end-message = [M_END, session-id, accept-option / decline-option]
M_END = ; a defined constant
session-id = 0..16777215
accept-option = ; defined below
decline-option ; defined below
A negotiation counterpart sends an Negotiation-ending message to A negotiation counterpart sends an Negotiation-ending message to
close the negotiation. It MUST contain one, but only one of accept/ close the negotiation. It MUST contain either an accept or a decline
decline option, defined in Section 3.8.3 and Section 3.8.4. It could option, defined in Section 3.8.3 and Section 3.8.4. It could be sent
be sent either by the requesting node or the responding node. either by the requesting node or the responding node.
3.7.7. Confirm-waiting Message 3.7.7. Confirm-waiting Message
In fragmentary CDDL, a Confirm-waiting message follows the pattern: In fragmentary CDDL, a Confirm-waiting message follows the pattern:
wait-message = [M_WAIT, session-id, waiting-time-option] wait-message = [M_WAIT, session-id, waiting-time]
waiting-time = 0..4294967295 ; in milliseconds
M_WAIT = ; a defined constant
session-id = 0..16777215
waiting-time-option = ; defined below
A responding node sends a Confirm-waiting message to indicate the A responding node sends a Confirm-waiting message to ask the
requesting node to wait for a further negotiation response. It might requesting node to wait for a further negotiation response. It might
be that the local process needs more time or that the negotiation be that the local process needs more time or that the negotiation
depends on another triggered negotiation. This message MUST NOT depends on another triggered negotiation. This message MUST NOT
include any other options than the Waiting Time Option include any other options. When received, the waiting time value
(Section 3.8.5). overwrites and restarts the current negotiation timer
(Section 3.7.4).
3.8. GRASP General Options The responding node SHOULD send a Negotiation, Negotiation-Ending or
another Confirm-waiting message before the negotiation timer expires.
If not, the initiator MUST abandon or restart the negotiation
procedure, to avoid an indefinite wait.
This section defines the GRASP general options for the negotiation 3.7.8. Synchronization Message
and synchronization protocol signaling. Additional option types are
reserved for GRASP general options defined in the future. In fragmentary CDDL, a Synchronization message follows the pattern:
synch-message = [M_SYNCH, session-id, objective]
A node which receives a synchronization Request, or a Discovery
message in Rapid Mode, sends back a unicast Synchronization message
with the synchronization data, in the form of a GRASP Option for the
specific synchronization objective present in the Request.
3.7.9. Flood Message
In fragmentary CDDL, a Flood message follows the pattern:
flood-message = [M_FLOOD, session-id, initiator, +objective]
A node MAY initiate flooding by sending an unsolicited Flood Message
with synchronization data. This MAY be sent to the link-local
ALL_GRASP_NEIGHBOR multicast address, in accordance with the rules in
Section 3.3.5. The initiator address is provided as described for
Discovery messages. The synchronization data will be 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).
A node that receives a Flood message SHOULD cache the received
objectives for use by local ASAs.
3.7.10. No Operation Message
In fragmentary CDDL, a No Operation message follows the pattern:
noop-message = [M_NOOP]
This message MAY be sent by an implementation that for practical
reasons needs to activate a socket. It MUST be silently ignored by a
recipient.
3.8. GRASP Options
This section defines the GRASP options for the negotiation and
synchronization protocol signaling. Additional options may be
defined in the future.
3.8.1. Format of GRASP Options 3.8.1. Format of GRASP Options
GRASP options are CBOR objects that MUST start with an unsigned GRASP options are CBOR objects that MUST start with an unsigned
integer identifying the specific option type carried in this option. integer identifying the specific option type carried in this option.
Apart from that the only format requirement is each option MUST be a These option types are formally defined in Section 6. Apart from
well-formed CBOR object. In general a CBOR array format is that the only format requirement is that each option MUST be a well-
RECOMMENDED to limit overhead. formed CBOR object. In general a CBOR array format is RECOMMENDED to
limit overhead.
GRASP options are usually scoped by using encapsulation. However, GRASP options are usually scoped by using encapsulation. However,
this is not a requirement this is not a requirement
3.8.2. Divert Option 3.8.2. Divert Option
The Divert option is used to redirect a GRASP request to another The Divert option is used to redirect a GRASP request to another
node, which may be more appropriate for the intended negotiation or node, which may be more appropriate for the intended negotiation or
synchronization. It may redirect to an entity that is known as a synchronization. It may redirect to an entity that is known as a
specific negotiation or synchronization counterpart (on-link or off- specific negotiation or synchronization counterpart (on-link or off-
link) or a default gateway. The divert option MUST only be link) or a default gateway. The divert option MUST only be
encapsulated in Response messages. If found elsewhere, it SHOULD be encapsulated in Response messages. If found elsewhere, it SHOULD be
silently ignored. silently ignored.
In fragmentary CDDL, the Divert option follows the pattern: In fragmentary CDDL, the Divert option follows the pattern:
divert-option = [O_DIVERT, +locator-option] divert-option = [O_DIVERT, +locator-option]
O_DIVERT = ; a defined constant The embedded Locator Option(s) (Section 3.8.6) point to diverted
locator-option = ; defined below
The embedded Locator Option(s) (Section 3.8.7) point to diverted
destination target(s) in response to a Discovery message. destination target(s) in response to a Discovery message.
Note: Currently the need for this option is disputed. It might be
removed or modified.
3.8.3. Accept Option 3.8.3. Accept Option
The accept option is used to indicate to the negotiation counterpart The accept option is used to indicate to the negotiation counterpart
that the proposed negotiation content is accepted. that the proposed negotiation content is accepted.
The accept option MUST only be encapsulated in Negotiation-ending The accept option MUST only be encapsulated in Negotiation-ending
messages. If found elsewhere, it SHOULD be silently ignored. messages. If found elsewhere, it SHOULD be silently ignored.
In fragmentary CDDL, the Accept option follows the pattern: In fragmentary CDDL, the Accept option follows the pattern:
accept-option = [O_ACCEPT] accept-option = [O_ACCEPT]
O_ACCEPT = ; a defined constant
3.8.4. Decline Option 3.8.4. Decline Option
The decline option is used to indicate to the negotiation counterpart The decline option is used to indicate to the negotiation counterpart
the proposed negotiation content is declined and end the negotiation the proposed negotiation content is declined and end the negotiation
process. process.
The decline option MUST only be encapsulated in Negotiation-ending The decline option MUST only be encapsulated in Negotiation-ending
messages. If found elsewhere, it SHOULD be silently ignored. messages. If found elsewhere, it SHOULD be silently ignored.
In fragmentary CDDL, the Decline option follows the pattern: In fragmentary CDDL, the Decline option follows the pattern:
decline-option = [O_DECLINE] decline-option = [O_DECLINE, ?reason]
reason = text ;optional error message
O_DECLINE = ; a defined constant
Notes: there are scenarios where a negotiation counterpart wants to Note: there are scenarios where a negotiation counterpart wants to
decline the proposed negotiation content and continue the negotiation decline the proposed negotiation content and continue the negotiation
process. For these scenarios, the negotiation counterpart SHOULD use process. For these scenarios, the negotiation counterpart SHOULD use
a Negotiate message, with either an objective option that contains a a Negotiate message, with either an objective option that contains a
data field set to indicate a meaningless initial value, or a specific data field set to indicate a meaningless initial value, or a specific
objective option that provides further conditions for convergence. objective option that provides further conditions for convergence.
3.8.5. Waiting Time Option 3.8.5. Device Identity Option
The waiting time option is used to indicate that the negotiation
counterpart needs to wait for a further negotiation response, since
the processing might need more time than usual or it might depend on
another triggered negotiation.
The waiting time option MUST only be encapsulated in Confirm-waiting
messages. If found elsewhere, it SHOULD be silently ignored. When
received, its value overwrites the negotiation timer (Section 3.7.4).
The counterpart SHOULD send a Negotiation, Negotiation-Ending or
another Confirm-waiting message before the negotiation timer expires.
If not, the initiator MUST abandon or restart the negotiation
procedure, to avoid an indefinite wait.
In fragmentary CDDL, the Waiting-time option follows the pattern:
waiting-time-option = [O_WAITING, option-waiting-time]
O_WAITING = ; a defined constant
option-waiting-time = 0..4294967295 ; in milliseconds
3.8.6. Device Identity Option
The Device Identity option carries the identities of the sender and The Device Identity option carries the identities of the sender and
of the domain(s) that it belongs to. of the domain(s) that it belongs to.
In fragmentary CDDL, the Device Identity option follows the pattern: In fragmentary CDDL, the Device Identity option follows the pattern:
option-device-id = [O_DEVICE_ID, bytes] option-device-id = [O_DEVICE_ID, bytes]
O_DEVICE_ID = ; a defined constant
The option contains a variable-length field containing the device The option contains a variable-length field containing the device
identity and one or more domain identities. The format is not yet identity and one or more domain identities. The format is not yet
defined. defined.
Note: Currently this option is a placeholder. It might be removed or Note: Currently this option is an unused placeholder. It might be
modified. removed or modified.
3.8.7. Locator Options 3.8.6. Locator Options
These locator options are used to present reachability information These locator options are used to present reachability information
for an ASA, a device or an interface. They are Locator IPv4 Address for an ASA, a device or an interface. They are Locator IPv4 Address
Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified Option, Locator IPv6 Address Option, Locator FQDN (Fully Qualified
Domain Name) Option and Uniform Resource Locator Option. Domain Name) Option and Uniform Resource Identifier Option.
Note: It is assumed that all locators are in scope throughout the Note: It is assumed that all locators are in scope throughout the
GRASP domain. GRASP is not intended to work across disjoint GRASP domain. GRASP is not intended to work across disjoint
addressing or naming realms. addressing or naming realms.
3.8.7.1. Locator IPv4 address option 3.8.6.1. Locator IPv4 address option
In fragmentary CDDL, the IPv4 address option follows the pattern: In fragmentary CDDL, the IPv4 address option follows the pattern:
ipv4-locator-option = bytes .size 4 ipv4-locator-option = bytes .size 4
The content of this option is a binary IPv4 address. The content of this option is a binary IPv4 address.
Note: If an operator has internal network address translation for Note: If an operator has internal network address translation for
IPv4, this option MUST NOT be used within the Divert option. IPv4, this option MUST NOT be used within the Divert option.
3.8.7.2. Locator IPv6 address option 3.8.6.2. Locator IPv6 address option
In fragmentary CDDL, the IPv6 address option follows the pattern: In fragmentary CDDL, the IPv6 address option follows the pattern:
ipv6-locator-option = bytes .size 16 ipv6-locator-option = bytes .size 16
The content of this option is a binary IPv6 address. The content of this option is a binary IPv6 address.
Note: A link-local IPv6 address MUST NOT be used when this option is Note 1: The IPv6 address MUST normally have global scope.
used within the Divert option. Exceptionally, during node bootstrap, a link-local address MAY be
used for specific objectives only.
3.8.7.3. Locator FQDN option Note 2: A link-local IPv6 address MUST NOT be used when this option
is included in a Divert option.
3.8.6.3. Locator FQDN option
In fragmentary CDDL, the FQDN option follows the pattern: In fragmentary CDDL, the FQDN option follows the pattern:
fqdn-locator-option = [O_FQDN_LOCATOR, text] fqdn-locator-option = [O_FQDN_LOCATOR, text]
O_FQDN_LOCATOR = ; a defined constant
The content of this option is the Fully Qualified Domain Name of the The content of this option is the Fully Qualified Domain Name of the
target. target.
Note: Any FQDN which might not be valid throughout the network in Note 1: Any FQDN which might not be valid throughout the network in
question, such as a Multicast DNS name [RFC6762], MUST NOT be used question, such as a Multicast DNS name [RFC6762], MUST NOT be used
when this option is used within the Divert option. when this option is used within the Divert option.
3.8.7.4. Locator URL option Note 2: Normal GRASP operations are not expected to use this option.
It is intended for special purposes such as discovering external
services.
In fragmentary CDDL, the URL option follows the pattern: 3.8.6.4. Locator URI option
url-locator-option = [O_URL_LOCATOR, text] In fragmentary CDDL, the URI option follows the pattern:
O_URL_LOCATOR = ; a defined constant uri-locator-option = [O_URI_LOCATOR, text]
The content of this option is the Uniform Resource Locator of the The content of this option is the Uniform Resource Identifier of the
target [RFC3986]. target [RFC3986].
Note: Any URL which might not be valid throughout the network in Note 1: Any URI which might not be valid throughout the network in
question, such as one based on a Multicast DNS name [RFC6762], MUST question, such as one based on a Multicast DNS name [RFC6762], MUST
NOT be used when this option is used within the Divert option. NOT be used when this option is used within the Divert option.
Note 2: Normal GRASP operations are not expected to use this option.
It is intended for special purposes such as discovering external
services.
3.9. Objective Options 3.9. Objective Options
3.9.1. Format of Objective Options 3.9.1. Format of Objective Options
An objective option is used to identify objectives for the purposes An objective option is used to identify objectives for the purposes
of discovery, negotiation or synchronization. All objectives must of discovery, negotiation or synchronization. All objectives MUST be
follow one of two common formats as follows, described in fragmentary in the following format, described in fragmentary CDDL:
CDDL:
generic-obj = [objective-name, objective-flags, loop-count, ?any] objective = [objective-name, objective-flags, loop-count, ?any]
vendor-obj = [{"PEN":pen}, objective-name, objective-flags,
loop-count, ?any]
objective-name = tstr objective-name = text
pen = 0..4294967295
loop-count = 0..255 loop-count = 0..255
objective-flags \= ; defined below
All objectives are identified by a unique name which is a UTF-8 All objectives are identified by a unique name which is a case-
string. The names of generic objectives MUST be registered with sensitive UTF-8 string.
IANA.
The name "PEN" and the value following it MUST be prepended to The names of generic objectives MUST NOT include a colon (":") and
indicate vendor-defined objectives. The associated value uniquely MUST be registered with IANA (Section 7).
identifies the enterprise that defines the option, in the form of a
registered 32 bit Private Enterprise Number (PEN) The names of privately defined objectives MUST include at least one
[I-D.liang-iana-pen]. There is no default value for this field. colon (":"). The string preceding the last colon in the name MUST be
Note that it is not used during discovery. It MUST be verified globally unique and in some way identify the entity or person
during negotiation or synchronization. defining the objective. The following three methods MAY be used to
create such a globally unique string:
1. The unique string is a decimal number representing a registered
32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that
uniquely identifies the enterprise defining the objective.
2. The unique string is a fully qualified domain name 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.
The GRASP protocol treats the objective name as an opaque string.
For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1
and "user@example.org:EX1" would be five different objectives.
The 'objective-flags' field is described below.
The 'loop-count' field is used for terminating negotiation as The 'loop-count' field is used for terminating negotiation as
described in Section 3.7.5. It is also used for terminating described in Section 3.7.5. It is also used for terminating
discovery as described in Section 3.3.3, and for terminating flooding discovery as described in Section 3.3.3, and for terminating flooding
as described in FLOODING. as described in Section 3.3.5.1.
The 'any' field is to express the actual value of a negotiation or The 'any' field is to express the actual value of a negotiation or
synchronization objective. Its format is defined in the synchronization objective. Its format is defined in the
specification of the objective and may be a single value or a data specification of the objective and may be a single value or a data
structure of any kind. It is optional because it is optional in a structure of any kind. It is optional because it is optional in a
Discovery or Response message. Discovery or Response message.
3.9.2. Objective flags 3.9.2. Objective flags
An objective may be relevant for discovery, negotiation or An objective may be relevant for discovery only, for discovery and
synchronization. This is expressed in the objective by logical negotiation, or for discovery and synchronization. This is expressed
flags: in the objective by logical flags:
objective-flags = uint .bits objective-flag objective-flags = uint .bits objective-flag
objective-flag = &( objective-flag = &(
D: 0 ; valid for discovery only F_DISC: 0 ; valid for discovery only
N: 1 ; valid for discovery and negotiation F_NEG: 1 ; valid for discovery and negotiation
S: 2 ; valid for discovery and synchronization F_SYNCH: 2 ; valid for discovery and synchronization
) )
3.9.3. General Considerations for Objective Options 3.9.3. General Considerations for Objective Options
As mentioned above, generic Objective Options MUST be assigned a As mentioned above, Objective Options MUST be assigned a unique name.
unique name. As long as vendor-defined Objective Options start with As long as privately defined Objective Options obey the rules above,
a valid PEN, this document does not restrict their choice of name, this document does not restrict their choice of name, but the entity
but the vendor SHOULD publish the names in use. or person concerned SHOULD publish the names in use.
All Objective Options MUST respect the CBOR patterns defined above as All Objective Options MUST respect the CBOR patterns defined above as
"generic-obj" or "vendor-obj" and MUST replace the "any" field with a "objective" and MUST replace the "any" field with a valid CBOR data
valid CBOR data definition for the relevant use case and application. definition for the relevant use case and application.
An Objective Option that contains no additional fields beyond its An Objective Option that contains no additional fields beyond its
"loop-count" can only be a discovery objective and MUST only be used "loop-count" can only be a discovery objective and MUST only be used
in Discovery and Response messages. in Discovery and Response messages.
The Negotiation Objective Options contain negotiation objectives, The Negotiation Objective Options contain negotiation objectives,
which vary according to different functions/services. They MUST be which vary according to different functions/services. They MUST be
carried by Discovery, Request or Negotiation Messages only. The carried by Discovery, Request or Negotiation Messages only. The
negotiation initiator MUST set the initial "loop-count" to a value negotiation initiator MUST set the initial "loop-count" to a value
specified in the specification of the objective or, if no such value specified in the specification of the objective or, if no such value
skipping to change at page 30, line 49 skipping to change at page 32, line 49
For most scenarios, there should be initial values in the negotiation For most scenarios, there should be initial values in the negotiation
requests. Consequently, the Negotiation Objective options MUST requests. Consequently, the Negotiation Objective options MUST
always be completely presented in a Request message, or in a always be completely presented in a Request message, or in a
Discovery message in rapid mode. If there is no initial value, the Discovery message in rapid mode. If there is no initial value, the
bits in the value field SHOULD all be set to indicate a meaningless bits in the value field SHOULD all be set to indicate a meaningless
value, unless this is inappropriate for the specific negotiation value, unless this is inappropriate for the specific negotiation
objective. objective.
Synchronization Objective Options are similar, but MUST be carried by Synchronization Objective Options are similar, but MUST be carried by
Discovery, Request or Response messages only. They include value Discovery, Request, Response or Flood messages only. They include
fields only in Response messages. value fields only in Response or Flood messages.
3.9.4. Organizing of Objective Options 3.9.4. Organizing of Objective Options
Generic objective options MUST be specified in documents available to Generic objective options MUST be specified in documents available to
the public and MUST be designed to use either the negotiation or the the public and SHOULD be designed to use either the negotiation or
synchronization mechanism described above. the synchronization mechanism described above.
As noted earlier, one negotiation objective is handled by each GRASP As noted earlier, one negotiation objective is handled by each GRASP
negotiation thread. Therefore, a negotiation objective, which is negotiation thread. Therefore, a negotiation objective, which is
based on a specific function or action, SHOULD be organized as a based on a specific function or action, SHOULD be organized as a
single GRASP option. It is NOT RECOMMENDED to organize multiple single GRASP option. It is NOT RECOMMENDED to organize multiple
negotiation objectives into a single option, nor to split a single negotiation objectives into a single option, nor to split a single
function or action into multiple negotiation objectives. function or action into multiple negotiation objectives.
It is important to understand that GRASP negotiation does not support It is important to understand that GRASP negotiation does not support
transactional integrity. If transactional integrity is needed for a transactional integrity. If transactional integrity is needed for a
skipping to change at page 32, line 30 skipping to change at page 34, line 30
experiment may use multiple options simultaneously. These experiment may use multiple options simultaneously. These
experimental options are highly likely to have different meanings experimental options are highly likely to have different meanings
when used for different experiments. Therefore, they SHOULD NOT be when used for different experiments. Therefore, they SHOULD NOT be
used without an explicit human decision and SHOULD NOT be used in used without an explicit human decision and SHOULD NOT be used in
unmanaged networks such as home networks. unmanaged networks such as home networks.
These names are also RECOMMENDED for use in documentation examples. These names are also RECOMMENDED for use in documentation examples.
4. Open Issues 4. Open Issues
RFC Editor: This section should be deleted except for any items not
marked as resolved, which should be retained and renumbered.
There are various unresolved design questions that are worthy of more There are various unresolved design questions that are worthy of more
work in the near future, as listed below (statically numbered in work in the near future, as listed below (statically numbered in
historical order for reference purposes, with the resolved issues historical order for reference purposes, with the resolved issues
retained for reference): retained for reference):
o 1. UDP vs TCP: For now, this specification suggests UDP and TCP o 1. UDP vs TCP: For now, this specification suggests UDP and TCP
as message transport mechanisms. This is not clarified yet. UDP as message transport mechanisms. This is not clarified yet. UDP
is good for short conversations, is necessary for multicast is good for short conversations, is necessary for multicast
discovery, and generally fits the discovery and divert scenarios discovery, and generally fits the discovery and divert scenarios
well. However, it will cause problems with large messages. TCP well. However, it will cause problems with large messages. TCP
skipping to change at page 33, line 13 skipping to change at page 35, line 15
as security solution to avoid duplication of effort. It also as security solution to avoid duplication of effort. It also
allows essentially similar security for short messages over UDP allows essentially similar security for short messages over UDP
and longer ones over TCP. The implementation trade-offs are and longer ones over TCP. The implementation trade-offs are
different. The current approach requires expensive asymmetric different. The current approach requires expensive asymmetric
cryptographic calculations for every message. (D)TLS has startup cryptographic calculations for every message. (D)TLS has startup
overheads but cheaper crypto per message. DTLS is less mature overheads but cheaper crypto per message. DTLS is less mature
than TLS. than TLS.
RESOLVED by specifying external security (ACP or (D)TLS). RESOLVED by specifying external security (ACP or (D)TLS).
o The following open issues apply only if the current security model o The following open issues applied only if the original security
is retained: model was retained:
* 2.1. For replay protection, GRASP currently requires every * 2.1. For replay protection, GRASP currently requires every
participant to have an NTP-synchronized clock. Is this OK for participant to have an NTP-synchronized clock. Is this OK for
low-end devices, and how does it work during device low-end devices, and how does it work during device
bootstrapping? We could take the Timestamp out of signature bootstrapping? We could take the Timestamp out of signature
option, to become an independent and OPTIONAL (or RECOMMENDED) option, to become an independent and OPTIONAL (or RECOMMENDED)
option. option.
* 2.2. The Signature Option states that this option could be any * 2.2. The Signature Option states that this option could be any
place in a message. Wouldn't it be better to specify a place in a message. Wouldn't it be better to specify a
skipping to change at page 34, line 4 skipping to change at page 35, line 49
discovery, especially for a very large autonomic network. discovery, especially for a very large autonomic network.
Centralized registration could be automatically deployed Centralized registration could be automatically deployed
incrementally. At the very first stage, the repository could be incrementally. At the very first stage, the repository could be
empty; then it could be filled in by the objectives discovered by empty; then it could be filled in by the objectives discovered by
different devices (for example using Dynamic DNS Update). The different devices (for example using Dynamic DNS Update). The
more records are stored in the repository, the less the multicast- more records are stored in the repository, the less the multicast-
based discovery is needed. However, if we adopt such a mechanism, based discovery is needed. However, if we adopt such a mechanism,
there would be challenges: stateful solution, and security. there would be challenges: stateful solution, and security.
RESOLVED for now by adding optional use of DNS-SD by ASAs. RESOLVED for now by adding optional use of DNS-SD by ASAs.
Subsequently removed by editors as irrelevant to GRASP istelf.
o 5. Need to expand description of the minimum requirements for the o 5. Need to expand description of the minimum requirements for the
specification of an individual discovery, synchronization or specification of an individual discovery, synchronization or
negotiation objective. negotiation objective.
RESOLVED for now by extra wording. RESOLVED for now by extra wording.
o 6. Use case and protocol walkthrough. A description of how a o 6. Use case and protocol walkthrough. A description of how a
node starts up, performs discovery, and conducts negotiation and node starts up, performs discovery, and conducts negotiation and
synchronisation for a sample use case would help readers to synchronisation for a sample use case would help readers to
skipping to change at page 35, line 43 skipping to change at page 37, line 41
RESOLVED: Yes, see #14. RESOLVED: Yes, see #14.
o 17. Ensure that the discovery mechanism is completely proof o 17. Ensure that the discovery mechanism is completely proof
against loops and protected against duplicate responses. against loops and protected against duplicate responses.
RESOLVED: Added loop count mechanism. RESOLVED: Added loop count mechanism.
o 18. Discuss the handling of multiple valid discovery responses. o 18. Discuss the handling of multiple valid discovery responses.
RESOLVED: Stated that the choice must be available to the ASA but
GRASP implementation should pick a default.
o 19. Should we use a text-oriented format such as JSON/CBOR o 19. Should we use a text-oriented format such as JSON/CBOR
instead of native binary TLV format? instead of native binary TLV format?
RESOLVED: Yes, changed to CBOR RESOLVED: Yes, changed to CBOR.
o 20. Is the Divert option needed? If a discovery response o 20. Is the Divert option needed? If a discovery response
provides a valid IP address or FQDN, the recipient doesn't gain provides a valid IP address or FQDN, the recipient doesn't gain
any extra knowledge from the Divert. On the other hand, the any extra knowledge from the Divert. On the other hand, the
presence of Divert informs the receiver that the target is off- presence of Divert informs the receiver that the target is off-
link, which might be useful sometimes. link, which might be useful sometimes.
RESOLVED: Decided to keep Divert option.
o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling o 21. Rename the protocol as GRASP (GeneRic Autonomic Signaling
Protocol)? Protocol)?
RESOLVED: Yes, name changed. RESOLVED: Yes, name changed.
o 22. Does discovery mechanism scale robustly as needed? Need hop o 22. Does discovery mechanism scale robustly as needed? Need hop
limit on relaying? limit on relaying?
RESOLVED: Added hop limit. RESOLVED: Added hop limit.
o 23. Need more details on TTL for caching discovery responses. o 23. Need more details on TTL for caching discovery responses.
RESOLVED: Done. RESOLVED: Done.
o 24. Do we need "fast withdrawal" of discovery responses? o 24. Do we need "fast withdrawal" of discovery responses?
RESOLVED: This doesn't seem necessary. If an ASA exits or stops
supporting a given objective, peers will fail to start future
sessions and will simply repeat discovery.
o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD? o 25. Does GDNP discovery meet the needs of multi-hop DNS-SD?
o 26. Add a URL type to the locator options (for security RESOLVED: Decided not to consider this further as a GRASP protocol
bootstrap) issue. GRASP objectives could embed DNS-SD formats if needed.
RESOLVED: Done. o 26. Add a URL type to the locator options (for security bootstrap
etc.)
o 27. Security of unsolicited Response multicasts (Section 3.3.5). RESOLVED: Done, later renamed as URI.
o 28. Does ACP support multicast? o 27. Security of Flood multicasts (Section 3.3.5.1).
RESOLVED: added text.
o 28. Does ACP support secure link-local multicast?
o 29. PEN is used to distinguish vendor options. Would it be o 29. PEN is used to distinguish vendor options. Would it be
better to use a domain name? Anything unique will do. better to use a domain name? Anything unique will do.
RESOLVED: Simplified this by removing PEN field and changing
naming rules for objectives.
o 30. Does response to discovery require randomized delays to o 30. Does response to discovery require randomized delays to
mitigate amplification attacks? mitigate amplification attacks?
RESOLVED: WG feedback is that it's unnecessary.
o 31. We have specified repeats for failed discovery etc. Is that o 31. We have specified repeats for failed discovery etc. Is that
sufficient to deal with sleeping nodes? sufficient to deal with sleeping nodes?
RESOLVED: WG feedback is that it's unnecessary to say more.
o 32. We have one-to-one synchronization and flooding o 32. We have one-to-one synchronization and flooding
synchronization. Do we also need selective flooding to a subset synchronization. Do we also need selective flooding to a subset
of nodes? of nodes?
RESOLVED: This will be discussed as a protocol extension in a
separate draft (draft-liu-anima-grasp-distribution).
o 33. Clarify if/when discovery needs to be repeated.
RESOLVED: Done.
o 34. Clarify what is mandatory for running in ACP, expand
discussion of security boundary when running with no ACP - might
rely on the local PKI infrastructure.
RESOLVED: Done.
o 35. State that role-based authorization of ASAs is out of scope
for GRASP. GRASP doesn't recognize/handle any "roles".
RESOLVED: Done.
o 36. Reconsider CBOR definition for PEN syntax. ( objective-name
= text / [pen, text] ; pen = uint )
RESOLVED: See issue 29.
o 37. Are URI locators really needed?
RESOLVED: Yes, e.g. for security bootstrap discovery, but added
note that addresses are the normal case (same for FQDN locators).
o 38. Is Session ID sufficient to identify relayed responses?
Isn't the originator's address needed too?
RESOLVED: Yes, this is needed for multicast messages and their
responses.
o 39. Clarify that a node will contain one GRASP instance
supporting multiple ASAs.
RESOLVED: Done.
o 40. Add a "reason" code to the DECLINE option?
RESOLVED: Done.
o 41. What happens if an ASA cannot conveniently use one of the
GRASP mechanisms? Do we (a) add a message type to GRASP, or (b)
simply pass the discovery results to the ASA so that it can open
its own socket?
RESOLVED: Both would be possible, but (b) is preferred.
o 42. Do we need a feature whereby an ASA can bypass the ACP and
use the data plane for efficiency/throughput? This would require
discovery to return non-ACP addresses and would evade ACP
security.
o 43. Rapid mode synchronization and negotiation is currently
limited to a single objective for simplicity of design and
implementation. A future consideration is to allow multiple
objectives in rapid mode for greater efficiency.
o 44. In requirement T9, the words that encryption "may not be
required in all deployments" were removed. Is that OK?.
o 45. Device Identity Option is unused. Can we remove it
completely?.
o 46. The 'initiator' field in DISCOVER, RESPONSE and FLOOD
messages is intended to assist in loop prevention. However, we
also have the loop count for that. It would be simpler to remove
the initiator, making message parsing more uniform. Is that OK?
o 47. REQUEST is a dual purpose message (request negotiation or
request synchronization). Would it be better to split this into
two different messages (and adjust various message names
accordingly)?
5. Security Considerations 5. Security Considerations
It is obvious that a successful attack on negotiation-enabled nodes It is obvious that a successful attack on negotiation-enabled nodes
would be extremely harmful, as such nodes might end up with a would be extremely harmful, as such nodes might end up with a
completely undesirable configuration that would also adversely affect completely undesirable configuration that would also adversely affect
their peers. GRASP nodes and messages therefore require full their peers. GRASP nodes and messages therefore require full
protection. protection.
- Authentication - Authentication
skipping to change at page 37, line 36 skipping to change at page 41, line 30
a trusted public third party. In a network requiring "air gap" a trusted public third party. In a network requiring "air gap"
security, such a dependency would be unacceptable. security, such a dependency would be unacceptable.
If GRASP is used temporarily without an external security If GRASP is used temporarily without an external security
mechanism, for example during system bootstrap (Section 3.3.1), mechanism, for example during system bootstrap (Section 3.3.1),
the Session ID (Section 3.6) will act as a nonce to provide the Session ID (Section 3.6) will act as a nonce to provide
limited protection against third parties injecting responses. A limited protection against third parties injecting responses. A
full analysis of the secure bootstrap process is out of scope for full analysis of the secure bootstrap process is out of scope for
the present document. the present document.
- Authorization and Roles
The GRASP protocol is agnostic about the role of individual ASAs
and about which objectives a particular ASA is authorized to
support. It SHOULD apply obvious precautions such as allowing
only one ASA in a given node to modify a given objective, but
otherwise authorization is out of scope.
- Privacy and confidentiality - Privacy and confidentiality
Generally speaking, no personal information is expected to be Generally speaking, no personal information is expected to be
involved in the signaling protocol, so there should be no direct involved in the signaling protocol, so there should be no direct
impact on personal privacy. Nevertheless, traffic flow paths, impact on personal privacy. Nevertheless, traffic flow paths,
VPNs, etc. could be negotiated, which could be of interest for VPNs, etc. could be negotiated, which could be of interest for
traffic analysis. Also, operators generally want to conceal traffic analysis. Also, operators generally want to conceal
details of their network topology and traffic density from details of their network topology and traffic density from
outsiders. Therefore, since insider attacks cannot be excluded in outsiders. Therefore, since insider attacks cannot be excluded in
a large network, the security mechanism for the protocol MUST a large network, the security mechanism for the protocol MUST
skipping to change at page 38, line 24 skipping to change at page 42, line 27
[I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that [I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that
other nodes are able to authenticate its own traffic. Therefore, other nodes are able to authenticate its own traffic. Therefore,
GRASP discovery during the bootstrap phase for a new device will GRASP discovery during the bootstrap phase for a new device will
inevitably be insecure and GRASP synchronization and negotiation inevitably be insecure and GRASP synchronization and negotiation
will be impossible until enrollment is complete. will be impossible until enrollment is complete.
6. CDDL Specification of GRASP 6. CDDL Specification of GRASP
<CODE BEGINS> <CODE BEGINS>
grasp-message = message grasp-message = (message .within message-structure) / noop-message
session-id = 0..16777215 message-structure = [MESSAGE_TYPE, session-id, +grasp-option]
; that is up to 24 bits
MESSAGE_TYPE = 0..255
session-id = 0..16777215 ;up to 24 bits
grasp-option = any
message /= discovery-message message /= discovery-message
discovery-message = [M_DISCOVERY, session-id, objective] discovery-message = [M_DISCOVERY, session-id, initiator, objective]
message /= response-message message /= response-message ;response to Discovery
response-message = [M_RESPONSE, session-id, response-message = [M_RESPONSE, session-id, initiator,
(+locator-option // divert-option // objective)] (+locator-option // divert-option), ?objective]
message /= synch-message ;response to Synchronization request
synch-message = [M_SYNCH, session-id, objective]
message /= flood-message
flood-message = [M_FLOOD, session-id, initiator, +objective]
message /= request-message message /= request-message
request-message = [M_REQUEST, session-id, objective] request-message = [M_REQUEST, session-id, objective]
message /= negotiation-message message /= negotiation-message
negotiation-message = [M_NEGOTIATE, session-id, objective] negotiation-message = [M_NEGOTIATE, session-id, objective]
message /= end-message message /= end-message
end-message = [M_END, session-id, (accept-option / decline-option)] end-message = [M_END, session-id, accept-option / decline-option ]
message /= wait-message message /= wait-message
wait-message = [M_WAIT, session-id, waiting-time-option] wait-message = [M_WAIT, session-id, waiting-time]
noop-message = [M_NOOP]
divert-option = [O_DIVERT, +locator-option] divert-option = [O_DIVERT, +locator-option]
accept-option = [O_ACCEPT] accept-option = [O_ACCEPT]
decline-option = [O_DECLINE]
waiting-time-option = [O_WAITING, option-waiting-time] decline-option = [O_DECLINE, ?reason]
option-waiting-time = 0..4294967295 ; in milliseconds reason = text ;optional error message
waiting-time = 0..4294967295 ; in milliseconds
option-device-id = [O_DEVICE_ID, bytes] option-device-id = [O_DEVICE_ID, bytes]
locator-option /= ipv4-locator-option locator-option /= ipv4-locator-option
ipv4-locator-option = bytes .size 4 ipv4-locator-option = bytes .size 4
; this is simpler than [O_IPv4_LOCATOR, bytes .size 4] ; this is simpler than [O_IPv4_LOCATOR, bytes .size 4]
locator-option /= ipv6-locator-option locator-option /= ipv6-locator-option
ipv6-locator-option = bytes .size 16 ipv6-locator-option = bytes .size 16
locator-option /= fqdn-locator-option locator-option /= fqdn-locator-option
fqdn-locator-option = [O_FQDN_LOCATOR, text] fqdn-locator-option = [O_FQDN_LOCATOR, text]
locator-option /= url-locator-option locator-option /= uri-locator-option
url-locator-option = [O_URL_LOCATOR, text] uri-locator-option = [O_URI_LOCATOR, text]
initiator = ipv4-locator-option / ipv6-locator-option
objective-flags = uint .bits objective-flag objective-flags = uint .bits objective-flag
objective-flag = &( objective-flag = &(
D: 0 F_DISC: 0 ; valid for discovery only
N: 1 F_NEG: 1 ; valid for discovery and negotiation
S: 2 F_SYNCH: 2 ; valid for discovery and synchronization
) )
; D means valid for discovery only
; N means valid for discovery and negotiation
; S means valid for discovery and synchronization
objective /= generic-obj
generic-obj = [objective-name, objective-flags, loop-count, ?any]
objective /= vendor-obj
vendor-obj = [{"PEN":pen}, objective-name, objective-flags,
loop-count, ?any]
; A PEN is used to distinguish vendor-specific options. objective = [objective-name, objective-flags, loop-count, ?any]
pen = 0..4294967295 objective-name = text ;see specification for uniqueness rules
objective-name = tstr
loop-count = 0..255 loop-count = 0..255
; Constants ; Constants for message types and option types
M_NOOP = 0
M_DISCOVERY = 1 M_DISCOVERY = 1
M_RESPONSE = 2 M_RESPONSE = 2
M_REQUEST = 3 M_REQUEST = 3
M_NEGOTIATE = 4 M_NEGOTIATE = 4
M_END = 5 M_END = 5
M_WAIT = 6 M_WAIT = 6
M_SYNCH = 7
M_FLOOD = 8
O_DIVERT = 100 O_DIVERT = 100
O_ACCEPT = 101 O_ACCEPT = 101
O_DECLINE = 102 O_DECLINE = 102
O_WAITING = 103 O_FQDN_LOCATOR = 103
O_DEVICE_ID = 104 O_URI_LOCATOR = 104
O_FQDN_LOCATOR = 105 O_DEVICE_ID = 105
O_URL_LOCATOR = 106
<CODE ENDS> <CODE ENDS>
7. IANA Considerations 7. IANA Considerations
Section 3.5 defines the following link-local multicast addresses, This document defines the General Discovery and Negotiation Protocol
which have been assigned by IANA for use by GRASP: (GRASP).
Section 3.5 explains the following link-local multicast addresses,
which IANA is requested to assign for use by GRASP:
ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in
the IPv6 Link-Local Scope Multicast Addresses registry. the IPv6 Link-Local Scope Multicast Addresses registry.
ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in ALL_GRASP_NEIGHBOR multicast address (IPv4): (TBD2). Assigned in
the IPv4 Multicast Local Network Control Block. the IPv4 Multicast Local Network Control Block.
(Note in draft: alternatively, we could use 224.0.0.1, currently Section 3.5 explains the following UDP and TCP port, which IANA is
defined as All Systems on this Subnet.) requested to assign for use by GRASP:
Section 3.5 defines the following UDP and TCP port, which has been
assigned by IANA for use by GRASP:
GRASP_LISTEN_PORT: (TBD3) GRASP_LISTEN_PORT: (TBD3)
This document defines the General Discovery and Negotiation Protocol The IANA is requested to create a GRASP Parameter Registry including
(GRASP). The IANA is requested to create a GRASP Parameter Registry. two registry tables. These are the GRASP Messages and Options
The IANA is also requested to add two new registry tables to the Table and the GRASP Objective Names Table.
newly-created GRASP Parameter Registry. The two tables are the GRASP
Messages and Options Table and the GRASP Objective Names Table.
GRASP Messages and Options Table. The values in this table are names GRASP Messages and Options Table. The values in this table are names
paired with decimal integers. Future values MUST be assigned using paired with decimal integers. Future values MUST be assigned using
the Standards Action policy defined by [RFC5226]. The following the Standards Action policy defined by [RFC5226]. The following
initial values are assigned by this document: initial values are assigned by this document:
M_NOOP = 0
M_DISCOVERY = 1 M_DISCOVERY = 1
M_RESPONSE = 2 M_RESPONSE = 2
M_REQUEST = 3 M_REQUEST = 3
M_NEGOTIATE = 4 M_NEGOTIATE = 4
M_END = 5 M_END = 5
M_WAIT = 6 M_WAIT = 6
O_DIVERT = 100 O_DIVERT = 100
O_ACCEPT = 101 O_ACCEPT = 101
O_DECLINE = 102 O_DECLINE = 102
O_WAITING = 103 O_FQDN_LOCATOR = 103
O_DEVICE_ID = 104 O_URI_LOCATOR = 104
O_FQDN_LOCATOR = 105 O_DEVICE_ID = 105
O_URL_LOCATOR = 106
GRASP Objective Names Table. The values in this table are UTF-8 GRASP Objective Names Table. The values in this table are UTF-8
strings. Future values MUST be assigned using the Specification strings. Future values MUST be assigned using the Specification
Required policy defined by [RFC5226]. The following initial values Required policy defined by [RFC5226]. The following initial values
are assigned by this document: are assigned by this document:
EX0 EX0
EX1 EX1
EX2 EX2
EX3 EX3
EX4 EX4
EX5 EX5
EX6 EX6
EX7 EX7
EX8 EX8
EX9 EX9
PEN
8. Acknowledgements 8. Acknowledgements
A major contribution to the original version of this document was A major contribution to the original version of this document was
made by Sheng Jiang. made by Sheng Jiang.
Valuable comments were received from Michael Behringer, Jeferson Valuable comments were received from Michael Behringer, Jeferson
Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Zhenbin Li, Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Halpern,
Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Michael Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman,
Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and other Michael Richardson, Markus Stenberg, Rene Struik, Dacheng Zhang, and
participants in the NMRG research group and the ANIMA working group. other participants in the NMRG research group and the ANIMA working
group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
9. Change log [RFC Editor: Please remove] 9. Change log [RFC Editor: Please remove]
draft-ietf-anima-grasp-02, 2016-01-13:
Resolved numerous issues according to WG discussions.
Renumbered requirements, added D9.
Protocol change: only allow one objective in rapid mode.
Protocol change: added optional error string to DECLINE option.
Protocol change: removed statement that seemed to say that a Request
not preceded by a Discovery should cause a Discovery response. That
made no sense, because there is no way the initiator would know where
to send the Request.
Protocol change: Removed PEN option from vendor objectives, changed
naming rule accordingly.
Protocol change: Added FLOOD message to simplify coding.
Protocol change: Added SYNCH message to simplify coding.
Protocol change: Added initiator id to DISCOVER, RESPONSE and FLOOD
messages. But also allowed the relay process for DISCOVER and FLOOD
to regenerate a Session ID.
Protocol change: Require that discovered addresses must be global
(except during bootstrap).
Protocol change: Receiver of REQUEST message must close socket if no
ASA is listening for the objective.
Protocol change: Simplified Waiting message.
Protocol change: Added No Operation message.
Renamed URL locator type as URI locator type.
Updated CDDL definition.
Various other clarifications and editorial fixes.
draft-ietf-anima-grasp-01, 2015-10-09: draft-ietf-anima-grasp-01, 2015-10-09:
Updated requirements after list discussion. Updated requirements after list discussion.
Changed from TLV to CBOR format - many detailed changes, added co- Changed from TLV to CBOR format - many detailed changes, added co-
author. author.
Tightened up loop count and timeouts for various cases. Tightened up loop count and timeouts for various cases.
Noted that GRASP does not provide transactional integrity. Noted that GRASP does not provide transactional integrity.
skipping to change at page 44, line 4 skipping to change at page 48, line 44
draft-carpenter-anima-gdn-protocol-01, restructured the logical flow draft-carpenter-anima-gdn-protocol-01, restructured the logical flow
of the document, updated to describe synchronization completely, add of the document, updated to describe synchronization completely, add
unsolicited responses, numerous corrections and clarifications, unsolicited responses, numerous corrections and clarifications,
expanded future work list, 2015-01-06. expanded future work list, 2015-01-06.
draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang- draft-carpenter-anima-gdn-protocol-00, combination of draft-jiang-
config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol- config-negotiation-ps-03 and draft-jiang-config-negotiation-protocol-
02, 2014-10-08. 02, 2014-10-08.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition Vigano, C. and H. Birkholz, "CBOR data definition language
language: a notational convention to express CBOR data (CDDL): a notational convention to express CBOR data
structures.", draft-greevenbosch-appsawg-cbor-cddl-06 structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work
(work in progress), July 2015. in progress), October 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 44, line 46 skipping to change at page 49, line 39
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <http://www.rfc-editor.org/info/rfc7049>. October 2013, <http://www.rfc-editor.org/info/rfc7049>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
10.2. Informative References 10.2. Informative References
[I-D.behringer-anima-reference-model] [I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-behringer-anima- for Autonomic Networking", draft-behringer-anima-
reference-model-03 (work in progress), June 2015. reference-model-04 (work in progress), October 2015.
[I-D.chaparadza-intarea-igcp] [I-D.chaparadza-intarea-igcp]
Behringer, M., Chaparadza, R., Petre, R., Li, X., and H. Behringer, M., Chaparadza, R., Petre, R., Li, X., and H.
Mahkonen, "IP based Generic Control Protocol (IGCP)", Mahkonen, "IP based Generic Control Protocol (IGCP)",
draft-chaparadza-intarea-igcp-00 (work in progress), July draft-chaparadza-intarea-igcp-00 (work in progress), July
2011. 2011.
[I-D.eckert-anima-stable-connectivity] [I-D.eckert-anima-stable-connectivity]
Eckert, T. and M. Behringer, "Using Autonomic Control Eckert, T. and M. Behringer, "Using Autonomic Control
Plane for Stable Connectivity of Network OAM", draft- Plane for Stable Connectivity of Network OAM", draft-
eckert-anima-stable-connectivity-01 (work in progress), eckert-anima-stable-connectivity-02 (work in progress),
March 2015. October 2015.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", draft-ietf-anima-autonomic- Autonomic Control Plane", draft-ietf-anima-autonomic-
control-plane-01 (work in progress), October 2015. control-plane-01 (work in progress), October 2015.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S. Pritikin, M., Richardson, M., Behringer, M., and S.
Bjarnason, "Bootstrapping Key Infrastructures", draft- Bjarnason, "Bootstrapping Key Infrastructures", draft-
ietf-anima-bootstrapping-keyinfra-00 (work in progress), ietf-anima-bootstrapping-keyinfra-01 (work in progress),
August 2015. October 2015.
[I-D.ietf-homenet-dncp] [I-D.ietf-homenet-dncp]
Stenberg, M. and S. Barth, "Distributed Node Consensus Stenberg, M. and S. Barth, "Distributed Node Consensus
Protocol", draft-ietf-homenet-dncp-10 (work in progress), Protocol", draft-ietf-homenet-dncp-12 (work in progress),
September 2015. November 2015.
[I-D.ietf-homenet-hncp] [I-D.ietf-homenet-hncp]
Stenberg, M., Barth, S., and P. Pfister, "Home Networking Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", draft-ietf-homenet-hncp-09 (work in Control Protocol", draft-ietf-homenet-hncp-10 (work in
progress), August 2015. progress), November 2015.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-07 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
progress), July 2015. progress), December 2015.
[I-D.liang-iana-pen] [I-D.liang-iana-pen]
Liang, P., Melnikov, A., and D. Conrad, "Private Liang, P., Melnikov, A., and D. Conrad, "Private
Enterprise Number (PEN) practices and Internet Assigned Enterprise Number (PEN) practices and Internet Assigned
Numbers Authority (IANA) registration considerations", Numbers Authority (IANA) registration considerations",
draft-liang-iana-pen-06 (work in progress), July 2015. draft-liang-iana-pen-06 (work in progress), July 2015.
[I-D.stenberg-anima-adncp] [I-D.stenberg-anima-adncp]
Stenberg, M., "Autonomic Distributed Node Consensus Stenberg, M., "Autonomic Distributed Node Consensus
Protocol", draft-stenberg-anima-adncp-00 (work in Protocol", draft-stenberg-anima-adncp-00 (work in
 End of changes. 176 change blocks. 
439 lines changed or deleted 684 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/