< draft-ietf-anima-grasp-09.txt | draft-ietf-anima-grasp-10A.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: June 18, 2017 Univ. of Auckland | Expires: September 3, 2017 Univ. of Auckland | |||
B. Liu, Ed. | B. Liu, Ed. | |||
Huawei Technologies Co., Ltd | Huawei Technologies Co., Ltd | |||
December 15, 2016 | March 2, 2017 | |||
A Generic Autonomic Signaling Protocol (GRASP) | A Generic Autonomic Signaling Protocol (GRASP) | |||
draft-ietf-anima-grasp-09 | draft-ietf-anima-grasp-10 | |||
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 with them. The document then defines a general | |||
general protocol for discovery, synchronization and negotiation, | protocol for discovery, synchronization and negotiation, while the | |||
while the technical objectives for specific scenarios are to be | technical objectives for specific scenarios are to be described in | |||
described in separate documents. An Appendix briefly discusses | separate documents. An Appendix briefly discusses existing protocols | |||
existing protocols with comparable features. | with comparable features. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 June 18, 2017. | This Internet-Draft will expire on September 3, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1. Requirements for Discovery . . . . . . . . . . . . . . . 5 | 2.1. Requirements for Discovery . . . . . . . . . . . . . . . 5 | |||
2.2. Requirements for Synchronization and Negotiation | 2.2. Requirements for Synchronization and Negotiation | |||
Capability . . . . . . . . . . . . . . . . . . . . . . . 6 | Capability . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.3. Specific Technical Requirements . . . . . . . . . . . . . 9 | 2.3. Specific Technical Requirements . . . . . . . . . . . . . 9 | |||
3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 | 3. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 10 | |||
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2. High Level Deployment Model . . . . . . . . . . . . . . . 12 | 3.2. High Level Deployment Model . . . . . . . . . . . . . . . 12 | |||
3.3. High Level Design Choices . . . . . . . . . . . . . . . . 13 | 3.3. High Level Design Choices . . . . . . . . . . . . . . . . 13 | |||
3.4. Quick Operating Overview . . . . . . . . . . . . . . . . 16 | 3.4. Quick Operating Overview . . . . . . . . . . . . . . . . 16 | |||
3.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 16 | 3.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 16 | |||
3.5.1. Required External Security Mechanism . . . . . . . . 16 | 3.5.1. Required External Security Mechanism . . . . . . . . 16 | |||
3.5.2. Constrained Instances . . . . . . . . . . . . . . . . 17 | 3.5.2. Constrained Instances . . . . . . . . . . . . . . . . 17 | |||
3.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 19 | 3.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 19 | |||
3.5.4. Discovery Mechanism and Procedures . . . . . . . . . 20 | 3.5.4. Discovery Mechanism and Procedures . . . . . . . . . 20 | |||
3.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 23 | 3.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 23 | |||
3.5.6. Synchronization and Flooding Procedure . . . . . . . 25 | 3.5.6. Synchronization and Flooding Procedures . . . . . . . 25 | |||
3.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 27 | 3.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 27 | |||
3.7. Session Identifier (Session ID) . . . . . . . . . . . . . 27 | 3.7. Session Identifier (Session ID) . . . . . . . . . . . . . 28 | |||
3.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 28 | 3.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 28 | |||
3.8.1. Message Overview . . . . . . . . . . . . . . . . . . 28 | 3.8.1. Message Overview . . . . . . . . . . . . . . . . . . 28 | |||
3.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 29 | 3.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 29 | |||
3.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 29 | 3.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 30 | |||
3.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 30 | 3.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 30 | |||
3.8.5. Discovery Response Message . . . . . . . . . . . . . 31 | 3.8.5. Discovery Response Message . . . . . . . . . . . . . 31 | |||
3.8.6. Request Messages . . . . . . . . . . . . . . . . . . 32 | 3.8.6. Request Messages . . . . . . . . . . . . . . . . . . 32 | |||
3.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 33 | 3.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 33 | |||
3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 33 | 3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 34 | |||
3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 33 | 3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 34 | |||
3.8.10. Synchronization Message . . . . . . . . . . . . . . . 34 | 3.8.10. Synchronization Message . . . . . . . . . . . . . . . 34 | |||
3.8.11. Flood Synchronization Message . . . . . . . . . . . . 34 | 3.8.11. Flood Synchronization Message . . . . . . . . . . . . 34 | |||
3.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 35 | 3.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 36 | |||
3.8.13. No Operation Message . . . . . . . . . . . . . . . . 35 | 3.8.13. No Operation Message . . . . . . . . . . . . . . . . 36 | |||
3.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 36 | 3.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 36 | |||
3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 36 | 3.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 36 | |||
3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 36 | 3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 37 | |||
3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 36 | 3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 37 | |||
3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37 | 3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37 | |||
3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 37 | 3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 38 | |||
3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 39 | 3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 40 | |||
3.10.1. Format of Objective Options . . . . . . . . . . . . 39 | 3.10.1. Format of Objective Options . . . . . . . . . . . . 40 | |||
3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 40 | 3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 41 | |||
3.10.3. General Considerations for Objective Options . . . . 41 | 3.10.3. General Considerations for Objective Options . . . . 41 | |||
3.10.4. Organizing of Objective Options . . . . . . . . . . 41 | 3.10.4. Organizing of Objective Options . . . . . . . . . . 42 | |||
3.10.5. Experimental and Example Objective Options . . . . . 43 | 3.10.5. Experimental and Example Objective Options . . . . . 43 | |||
4. Implementation Status [RFC Editor: please remove] . . . . . . 43 | 4. Implementation Status [RFC Editor: please remove] . . . . . . 44 | |||
4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 43 | 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 44 | |||
4.2. Python Implementation . . . . . . . . . . . . . . . . . . 44 | 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 44 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | |||
6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 47 | 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 47 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 51 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 52 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 52 | 9.2. Informative References . . . . . . . . . . . . . . . . . 53 | |||
Appendix A. Open Issues [RFC Editor: Please remove if empty] . . 55 | Appendix A. Open Issues [RFC Editor: Please remove if empty] . . 56 | |||
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 55 | Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 56 | |||
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 63 | Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 64 | |||
Appendix D. Example Message Formats . . . . . . . . . . . . . . 69 | Appendix D. Example Message Formats . . . . . . . . . . . . . . 70 | |||
D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 69 | D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 70 | |||
D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 70 | D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 71 | |||
D.3. Synchronization Example . . . . . . . . . . . . . . . . . 70 | D.3. Synchronization Example . . . . . . . . . . . . . . . . . 71 | |||
D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 70 | D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 71 | |||
D.5. Complete Negotiation Example . . . . . . . . . . . . . . 71 | D.5. Complete Negotiation Example . . . . . . . . . . . . . . 72 | |||
Appendix E. Capability Analysis of Current Protocols . . . . . . 72 | Appendix E. Capability Analysis of Current Protocols . . . . . . 73 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76 | |||
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]. | [RFC7576]. | |||
One approach is to largely decentralize the logic of network | One approach is to largely decentralize the logic of network | |||
management by migrating it into network elements. A reference model | management by migrating it into network elements. A reference model | |||
for autonomic networking on this basis is given in | for autonomic networking on this basis is given in | |||
[I-D.ietf-anima-reference-model]. The reader should consult this | [I-D.ietf-anima-reference-model]. The reader should consult this | |||
document to understand how various autonomic components fit together. | document to understand how various autonomic components fit together. | |||
In order to fulfil autonomy, devices that embody Autonomic Service | In order to fulfill autonomy, devices that embody Autonomic Service | |||
Agents (ASAs, [RFC7575]) have specific signaling requirements. In | Agents (ASAs, [RFC7575]) have specific signaling requirements. In | |||
particular they need to discover each other, to synchronize state | particular they need to discover each other, to synchronize state | |||
with each other, and to negotiate parameters and resources directly | with each other, and to negotiate parameters and resources directly | |||
with each other. There is no limitation on the types of parameters | with each other. There is no limitation on the types of parameters | |||
and resources concerned, which can include very basic information | and resources concerned, which can include very basic information | |||
needed for addressing and routing, as well as anything else that | needed for addressing and routing, as well as anything else that | |||
might be configured in a conventional non-autonomic network. The | might be configured in a conventional non-autonomic network. The | |||
atomic unit of discovery, synchronization or negotiation is referred | atomic unit of discovery, synchronization or negotiation is referred | |||
to as a technical objective, i.e, a configurable parameter or set of | to as a technical objective, i.e, a configurable parameter or set of | |||
parameters (defined more precisely in Section 3.1). | parameters (defined more precisely in Section 3.1). | |||
skipping to change at page 4, line 23 | skipping to change at page 4, line 23 | |||
Following this Introduction, Section 2 describes the requirements for | Following this Introduction, Section 2 describes the requirements for | |||
discovery, synchronization and negotiation. Negotiation is an | discovery, synchronization and negotiation. Negotiation is an | |||
iterative process, requiring multiple message exchanges forming a | iterative process, requiring multiple message exchanges forming a | |||
closed loop between the negotiating entities. In fact, these | closed loop between the negotiating entities. In fact, these | |||
entities are ASAs, normally but not necessarily in different network | entities are ASAs, normally but not necessarily in different network | |||
devices. State synchronization, when needed, can be regarded as a | devices. State synchronization, when needed, can be regarded as a | |||
special case of negotiation, without iteration. Section 3.3 | special case of negotiation, without iteration. Section 3.3 | |||
describes a behavior model for a protocol intended to support | describes a behavior model for a protocol intended to support | |||
discovery, synchronization and negotiation. The design of GeneRic | discovery, synchronization and negotiation. The design of GeneRic | |||
Autonomic Signaling Protocol (GRASP) in Section 3 of this document is | Autonomic Signaling Protocol (GRASP) in Section 3 of this document is | |||
mainly based on this behavior model. The relevant capabilities of | based on this behavior model. The relevant capabilities of various | |||
various existing protocols are reviewed in Appendix E. | existing protocols are reviewed in Appendix E. | |||
The proposed discovery mechanism is oriented towards synchronization | The proposed discovery mechanism is oriented towards synchronization | |||
and negotiation objectives. It is based on a neighbor discovery | and negotiation objectives. It is based on a neighbor discovery | |||
process, but also supports diversion to off-link peers. There is no | process on the local link, but also supports diversion to peers on | |||
assumption of any particular form of network topology. When a device | other links. There is no assumption of any particular form of | |||
starts up with no pre-configuration, it has no knowledge of the | network topology. When a device starts up with no pre-configuration, | |||
topology. The protocol itself is capable of being used in a small | it has no knowledge of the topology. The protocol itself is capable | |||
and/or flat network structure such as a small office or home network | of being used in a small and/or flat network structure such as a | |||
as well as a professionally managed network. Therefore, the | small office or home network as well as in a large professionally | |||
discovery mechanism needs to be able to allow a device to bootstrap | managed network. Therefore, the discovery mechanism needs to be able | |||
itself without making any prior assumptions about network structure. | to allow a device to bootstrap itself without making any prior | |||
assumptions about network structure. | ||||
Because GRASP can be used to perform a decision process among | Because GRASP can be used as part of a decision process among | |||
distributed devices or between networks, it must run in a secure and | distributed devices or between networks, it must run in a secure and | |||
strongly authenticated environment. | strongly authenticated environment. | |||
It is understood that in realistic deployments, not all devices will | In realistic deployments, not all devices will support GRASP. | |||
support GRASP. It is expected that some autonomic service agents | Therefore, some autonomic service agents will directly manage a group | |||
will directly manage a group of non-autonomic nodes, and that other | of non-autonomic nodes, and other non-autonomic nodes will be managed | |||
non-autonomic nodes will be managed traditionally. Such mixed | traditionally. Such mixed scenarios are not discussed in this | |||
scenarios are not discussed in this specification. | specification. | |||
2. Requirement Analysis of Discovery, Synchronization and Negotiation | 2. Requirement Analysis of Discovery, Synchronization and Negotiation | |||
This section discusses the requirements for discovery, negotiation | This section discusses the requirements for discovery, negotiation | |||
and synchronization capabilities. The primary user of the protocol | and synchronization capabilities. The primary user of the protocol | |||
is an autonomic service agent (ASA), so the requirements are mainly | is an autonomic service agent (ASA), so the requirements are mainly | |||
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. If a technical objective is managed by several | technical objectives. If a technical objective is managed by several | |||
ASAs, any necessary coordination is outside the scope of the | ASAs, any necessary coordination is outside the scope of the GRASP | |||
signaling protocol itself. | signaling protocol. Furthermore, requirements for ASAs themselves, | |||
such as the processing of Intent [RFC7575], are out of scope for the | ||||
Note that requirements for ASAs themselves, such as the processing of | present document. | |||
Intent [RFC7575] or interfaces for coordination between ASAs are out | ||||
of scope for the present document. | ||||
2.1. Requirements for Discovery | 2.1. Requirements for Discovery | |||
D1. ASAs may be designed to manage anything, as required in | D1. ASAs may be designed to manage any type of configurable device | |||
Section 2.2. A basic requirement is therefore that the protocol can | or software, as required in Section 2.2. A basic requirement is | |||
represent and discover any kind of technical objective among | therefore that the protocol can represent and discover any kind of | |||
arbitrary subsets of participating nodes. | technical objective among 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. For example, it might be necessary | information about relevant peers. For example, it might be necessary | |||
to set up resources on multiple other devices, coordinated and | to set up resources on multiple other devices, coordinated and | |||
matched to each other so that there is no wasted resource. Security | matched to each other so that there is no wasted resource. Security | |||
settings might also need updating to allow for the new device or | settings might also need updating to allow for the new device or | |||
user. The relevant peers may be different for different technical | user. The relevant peers may be different for different technical | |||
objectives. Therefore discovery needs to be repeated as often as | objectives. Therefore discovery needs to be repeated as often as | |||
necessary to find peers capable of acting as counterparts for each | necessary to find peers capable of acting as counterparts for each | |||
objective that a discovery initiator needs to handle. From this | objective that a discovery initiator needs to handle. From this | |||
background we derive the next three requirements: | background we derive the next three requirements: | |||
D2. When an ASA first starts up, it has no knowledge of the specific | D2. When an ASA first starts up, it may have no knowledge of the | |||
network to which it is attached. Therefore the discovery process | specific network to which it is attached. Therefore the discovery | |||
must be able to support any network scenario, assuming only that the | process must be able to support any network scenario, assuming only | |||
device concerned is bootstrapped from factory condition. | that the device concerned is bootstrapped from factory condition. | |||
D3. When an ASA starts up, it must require no configured location | D3. When an ASA starts up, it must require no configured location | |||
information about any peers in order to discover them. | information about any peers in order to discover them. | |||
D4. 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 performed separately to find counterparts for each | needs to be performed separately to find counterparts for each | |||
objective. Thus, there must be a mechanism by which an ASA can | objective. Thus, there must be a mechanism by which an ASA can | |||
separately discover peer ASAs for each of the technical objectives | separately discover peer ASAs for each of the technical objectives | |||
that it needs to manage, whenever necessary. | that it needs to manage, whenever necessary. | |||
D5. 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 conveniently linking discovery to negotiation and | allow for this by conveniently linking discovery to negotiation and | |||
synchronization. It may provide an optional mechanism to combine | synchronization. It may provide an optional mechanism to combine | |||
discovery and negotiation/synchronization in a single call. | discovery and negotiation/synchronization in a single protocol | |||
exchange. | ||||
D6. 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. | |||
D7. 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 During initialisation, a device must be able to establish mutual | o During initialization, a device must be able to establish mutual | |||
trust with the rest of the network and join an authentication | trust with the rest of the network and participate in an | |||
mechanism. Although this will inevitably start with a discovery | authentication mechanism. Although this will inevitably start | |||
action, it is a special case precisely because trust is not yet | with a discovery action, it is a special case precisely because | |||
established. This topic is the subject of | trust is not yet established. This topic is the subject of | |||
[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. | |||
This does not preclude the device having multiple credentials. | ||||
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.ietf-anima-stable-connectivity]. The protocol | Center (NOC) [I-D.ietf-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. | initialization, as well as discovery during ongoing operation. | |||
D8. The discovery process must not generate excessive traffic and | D8. The discovery process must not generate excessive traffic and | |||
must take account of sleeping nodes. | must take account of sleeping nodes. | |||
D9. There must be a mechanism for handling stale discovery results. | 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 and metrics, and an underlying assumption is that nodes | |||
all nodes need a consistent view of the network topology in order for | need a consistent, although partial, view of the network topology in | |||
the routing algorithm to converge. Thus, routing is mainly based on | order for the routing algorithm to converge. Thus, routing is mainly | |||
information synchronization between peers, rather than on bi- | based on simple information synchronization between peers, rather | |||
directional negotiation. Other information, such as latency, | than on bi-directional negotiation. | |||
congestion, capacity, and particularly unused capacity, would be | ||||
helpful to get better path selection and utilization rate, but is not | By contrast, autonomic networks need to be able to manage many more | |||
normally used in distributed routing algorithms. Additionally, | dimensions, such as latency, congestion, unused capacity, security | |||
autonomic networks need to be able to manage many more dimensions, | settings, power saving, load balancing, etc. Status information and | |||
such as security settings, power saving, load balancing, etc. Status | traffic metrics need to be shared between nodes for dynamic | |||
information and traffic metrics need to be shared between nodes for | adjustment of resources and for monitoring purposes. While this | |||
dynamic adjustment of resources and for monitoring purposes. While | might be achieved by existing protocols when they are available, the | |||
this might be achieved by existing protocols when they are available, | 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. | |||
SN1. A basic requirement for the protocol is therefore the ability | SN1. A basic requirement for the protocol is therefore the ability | |||
to represent, discover, synchronize and negotiate almost any kind of | to represent, discover, synchronize and negotiate almost any kind of | |||
network parameter among selected subsets of participating nodes. | network parameter among selected subsets of participating nodes. | |||
SN2. Negotiation is a request/response process that must be | SN2. Negotiation is an iterative request/response process that must | |||
guaranteed to terminate (with success or failure) and if necessary it | be guaranteed to terminate (with success or failure). While tie- | |||
must contain tie-breaking rules for each technical objective that | breaking rules must be defined specifically for each use case, the | |||
requires them. While these must be defined specifically for each use | protocol should have some general mechanisms in support of loop and | |||
case, the protocol should have some general mechanisms in support of | deadlock prevention, such as hop count limits or timeouts. | |||
loop and deadlock prevention, such as hop count limits or timeouts. | ||||
SN3. Synchronization might concern small groups of nodes or very | SN3. Synchronization must be possible for groups of nodes ranging | |||
large groups. Different solutions might be needed at different | from small to very large. | |||
scales. | ||||
SN4. To avoid "reinventing the wheel", the protocol should be able | SN4. To avoid "reinventing the wheel", the protocol should be able | |||
to encapsulate the data formats used by existing configuration | to encapsulate the data formats used by existing configuration | |||
protocols (such as NETCONF/YANG) in cases where that is convenient. | protocols (such as NETCONF/YANG) in cases where that is convenient. | |||
SN5. 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 follows | |||
therefore follows that the protocol, as part of the Autonomic | that the protocol's resource requirements must be appropriate for any | |||
Networking Infrastructure, should be capable of running in any device | device that would otherwise need human intervention. The issue of | |||
that would otherwise need human intervention. The issue of running | running in constrained nodes is discussed in | |||
in constrained nodes is discussed in | ||||
[I-D.ietf-anima-reference-model]. | [I-D.ietf-anima-reference-model]. | |||
SN6. Human intervention in large networks is often replaced by use | SN6. Human intervention in large networks is often replaced by use | |||
of 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, should be capable of running in any device that would | Infrastructure, should 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. | |||
SN7. Some features are expected to be implemented by individual | SN7. Some features are expected to be implemented by individual | |||
skipping to change at page 8, line 22 | skipping to change at page 8, line 22 | |||
from neighbors. This can be established through the negotiation | from neighbors. This can be established through the negotiation | |||
procedure, or through synchronization if that is sufficient. | procedure, or through synchronization if that is sufficient. | |||
However, a given item in a neighbor may depend on other | However, a given item in a neighbor may depend on other | |||
information from its own neighbors, which may need another | information from its own neighbors, which may need another | |||
negotiation or synchronization procedure to obtain or decide. | negotiation or synchronization procedure to obtain or decide. | |||
Therefore, there are potential dependencies and conflicts among | Therefore, there are potential dependencies and conflicts among | |||
negotiation or synchronization procedures. Resolving dependencies | negotiation or synchronization procedures. Resolving dependencies | |||
and conflicts is a matter for the individual ASAs involved. To | and conflicts is a matter for the individual ASAs involved. To | |||
allow this, there need to be clear boundaries and convergence | allow this, there need to be clear boundaries and convergence | |||
mechanisms for negotiations. Also some mechanisms are needed to | mechanisms for negotiations. Also some mechanisms are needed to | |||
avoid loop dependencies. In such a case, the protocol's role is | avoid loop dependencies or uncontrolled growth in a tree of | |||
limited to bilateral signaling between ASAs. | dependencies. It is the ASA designer's responsibility to avoid or | |||
detect looping dependencies or excessive growth of dependency | ||||
trees. The protocol's role is limited to bilateral signaling | ||||
between ASAs, and the avoidance of loops during bilateral | ||||
signaling. | ||||
o Recovery from faults and identification of faulty devices should | o Recovery from faults and identification of faulty devices should | |||
be as automatic as possible. The protocol's role is limited to | be as automatic as possible. The protocol's role is limited to | |||
discovery, synchronization and negotiation. These processes can | discovery, synchronization and negotiation. These processes can | |||
occur at any time, and an ASA may need to repeat any of these | occur at any time, and an ASA may need to repeat any of these | |||
steps when the ASA detects an anomaly such as a negotiation | steps when the ASA detects an event such as a negotiation | |||
counterpart failing. | counterpart failing. | |||
o Since the goal is to minimize human intervention, it is necessary | o Since a major goal is to minimize human intervention, it is | |||
that the network can in effect "think ahead" before changing its | necessary that the network can in effect "think ahead" before | |||
parameters. One aspect of this is an ASA that relies on a | changing its parameters. One aspect of this is an ASA that relies | |||
knowledge base to predict network behavior. This is out of scope | on a knowledge base to predict network behavior. This is out of | |||
for the signaling protocol. However, another aspect is | scope for the signaling protocol. However, another aspect is | |||
forecasting the effect of a change by a "dry run" negotiation | forecasting the effect of a change by a "dry run" negotiation | |||
before actually installing the change. This will be an | before actually installing the change. Signaling a dry run is | |||
application of the protocol rather than a feature of the protocol | therefore a desirable feature of the protocol. | |||
itself. | ||||
o Management logging, monitoring, alerts and tools for intervention | Note that management logging, monitoring, alerts and tools for | |||
are required. However, these can only be features of individual | intervention are required. However, these can only be features of | |||
ASAs. Another document [I-D.ietf-anima-stable-connectivity] | individual ASAs, not of the protocol itself. Another document | |||
discusses how such agents may be linked into conventional OAM | [I-D.ietf-anima-stable-connectivity] discusses how such agents may be | |||
systems via an Autonomic Control Plane | linked into conventional OAM systems via an Autonomic Control Plane | |||
[I-D.ietf-anima-autonomic-control-plane]. | [I-D.ietf-anima-autonomic-control-plane]. | |||
SN8. 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 a flexible and easily extensible | Therefore the protocol will need a flexible and easily extensible | |||
format for describing objectives. At a later stage it may be | format for describing objectives. At a later stage it may be | |||
desirable to adopt an explicit information model. One consideration | desirable to adopt an explicit information model. One consideration | |||
is whether to adopt an existing information model or to design a new | is whether to adopt an existing information model or to design a new | |||
one. | one. | |||
2.3. Specific Technical Requirements | 2.3. Specific Technical Requirements | |||
T1. 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. In | excessive impact on run-time efficiency and footprint. In | |||
particular, it should be possible for ASAs to be implemented | particular, it should be convenient for ASAs to be implemented | |||
independently of each other as user space programs rather than as | independently of each other as user space programs rather than as | |||
kernel code. The classes of device in which the protocol might run | kernel code, where such a programming model is possible. The classes | |||
is discussed in [I-D.ietf-anima-reference-model]. | of device in which the protocol might run is discussed in | |||
[I-D.ietf-anima-reference-model]. | ||||
T2. 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. | |||
T3. 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 on a link, might need to be IP version | such as multicasting on a link, might need to be IP version | |||
dependent. In case of doubt, IPv6 should be preferred. | dependent. By default, IPv6 should be preferred. | |||
T4. 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. | |||
T5. 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. | negotiation or synchronization. | |||
T6. The protocol must be capable of supporting multiple simultaneous | T6. The protocol must be capable of supporting multiple simultaneous | |||
operations, especially when wait states occur. | operations with one or more peers, especially when wait states occur. | |||
T7. Intent: There must be provision for general Intent rules to be | T7. Intent: Although the distribution of Intent is out of scope for | |||
applied by all devices in the network (e.g., security rules, prefix | this document, the protocol must not by design exclude its use for | |||
length, resource sharing rules). However, Intent distribution might | Intent distribution. | |||
not use the signaling protocol itself, but its design should not | ||||
exclude such use. | ||||
T8. 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. | |||
T9. The protocol needs to be fully secured against forged messages | T9. Because this protocol may directly cause changes to device | |||
configurations and have significant impacts on a running network, all | ||||
protocol exchanges need to be fully secured against forged messages | ||||
and man-in-the middle attacks, and secured as much as reasonably | 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. There must also be an | |||
of encryption in order to resist unwanted monitoring. However, it is | encryption mechanism to resist unwanted monitoring. 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 50 | skipping to change at page 11, line 6 | |||
both ASAs. | both ASAs. | |||
o State Synchronization: a process by which ASAs interact to receive | o State Synchronization: a process by which ASAs interact to receive | |||
the current state of parameter values stored in other ASAs. This | the current state of parameter values stored in other ASAs. This | |||
is a special case of negotiation in which information is sent but | is a special case of negotiation in which information is sent but | |||
the ASAs do not request their peers to change parameter settings. | the ASAs do not request their peers to change parameter settings. | |||
All other definitions apply to both negotiation and | All other definitions apply to both negotiation and | |||
synchronization. | 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 data structure, whose main contents are a | |||
parameters of some kind, which occurs in three contexts: | name and a value. The value consists of a single configurable | |||
parameter or a set of parameters of some kind. The exact format | ||||
Discovery, Negotiation and Synchronization. In the protocol, an | of an objective is defined in Section 3.10.1. An objective occurs | |||
objective is represented by an identifier and, if relevant, a | in three contexts: Discovery, Negotiation and Synchronization. | |||
value. Normally, a given objective will not occur in negotiation | Normally, a given objective will not occur in negotiation and | |||
and synchronization contexts simultaneously. | synchronization contexts simultaneously. | |||
* 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(s) in the value of a given objective apply to a | |||
on a specific service or function or action. It may in | specific service or function or action. They may in principle | |||
principle be anything that can be set to a specific logical, | be anything that can be set to a specific logical, numerical or | |||
numerical or string value, or a more complex data structure, by | string value, or a more complex data structure, by a network | |||
a network node. That node is generally expected to contain an | node. Each node is expected to contain one or more ASAs which | |||
ASA which may itself manage subsidiary non-autonomic nodes. | may each manage subsidiary non-autonomic nodes. | |||
* Discovery Objective: an objective in the process of discovery. | * Discovery Objective: an objective in the process of discovery. | |||
Its value may be undefined. | Its value may be undefined. | |||
* Synchronization Objective: an objective whose specific | * Synchronization Objective: an objective whose specific | |||
technical content needs to be synchronized among two or more | technical content needs to be synchronized among two or more | |||
ASAs. | ASAs. Thus, each ASA will maintain its own copy of the | |||
objective. | ||||
* Negotiation Objective: an objective whose specific technical | * Negotiation Objective: an objective whose specific technical | |||
content needs to be decided in coordination with another ASA. | content needs to be decided in coordination with another ASA. | |||
Again, each ASA will maintain its own copy of the objective. | ||||
A detailed discussion of objectives, including their format, is | A detailed discussion of objectives, including their format, is | |||
found in Section 3.10. | found in Section 3.10. | |||
o Discovery Initiator: an ASA that spontaneously starts discovery by | o Discovery Initiator: an ASA that starts discovery by sending a | |||
sending a discovery message referring to a specific discovery | discovery message referring to a specific discovery objective. | |||
objective. | ||||
o Discovery Responder: a peer that either contains an ASA supporting | o Discovery Responder: a peer that either contains an ASA supporting | |||
the discovery objective indicated by the discovery initiator, or | the discovery objective indicated by the discovery initiator, or | |||
caches the locator(s) of the ASA(s) supporting the objective. It | caches the locator(s) of the ASA(s) supporting the objective. It | |||
sends a Discovery Response, as described later. | sends a Discovery Response, as described later. | |||
o Synchronization Initiator: an ASA that spontaneously starts | o Synchronization Initiator: an ASA that starts synchronization by | |||
synchronization by sending a request message referring to a | sending a request message referring to a specific synchronization | |||
specific synchronization objective. | objective. | |||
o Synchronization Responder: a peer ASA which responds with the | o Synchronization Responder: a peer ASA which responds with the | |||
value of a synchronization objective. | value of a synchronization objective. | |||
o Negotiation Initiator: an ASA that spontaneously starts | o Negotiation Initiator: an ASA that starts negotiation by sending a | |||
negotiation by sending a request message referring to a specific | request message referring to a specific negotiation objective. | |||
negotiation objective. | ||||
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. | |||
o GRASP Instance: This refers to an instantiation of a GRASP | ||||
protocol engine, likely including multiple threads or processes as | ||||
well as dynamic data structures such as a discovery cache, running | ||||
in a given security environment on a single device. | ||||
o Network Interface: Unless otherwise stated, this refers to a | ||||
network interface - which might be physical or virtual - that a | ||||
specific instance of GRASP is currently using. A device might | ||||
have other interfaces that are not used by GRASP. | ||||
3.2. High Level Deployment Model | 3.2. High Level Deployment Model | |||
It is expected that a GRASP implementation will reside in an | A GRASP implementation will be part of the Autonomic Networking | |||
autonomic node that also contains both the appropriate security | Infrastructure in an autonomic node, which must also provide an | |||
environment, preferably the Autonomic Control Plane (ACP) | appropriate security environment. In accordance with | |||
[I-D.ietf-anima-autonomic-control-plane], and one or more Autonomic | [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic | |||
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. It is | ||||
expected that GRASP will access the ACP by using a typical socket | ||||
programming interface. There will also be one or more Autonomic | ||||
Service Agents (ASAs). In the minimal case of a single-purpose | Service Agents (ASAs). In the minimal case of a single-purpose | |||
device, these three components might be fully integrated. A more | device, these components might be fully integrated. A more common | |||
common model is expected to be a multi-purpose device capable of | model is expected to be a multi-purpose device capable of containing | |||
containing several ASAs. In this case it is expected that the ACP, | several ASAs. In this case it is expected that the ACP, GRASP and | |||
GRASP and the ASAs will be implemented as separate processes, which | the ASAs will be implemented as separate processes, which are | |||
are probably multi-threaded to support asynchronous and simultaneous | probably multi-threaded to support asynchronous and simultaneous | |||
operations. It is expected that GRASP will access the ACP by using a | operations. | |||
typical socket interface. A well defined Application Programming | ||||
Interface (API) will be needed between GRASP and the ASAs. In some | ||||
implementations, ASAs would run in user space with a GRASP library | ||||
providing the API, and this library would in turn communicate via | ||||
system calls with core GRASP functions. For further details of | ||||
possible deployment models, see [I-D.ietf-anima-reference-model]. | ||||
A GRASP instance must be aware of its network interfaces, and of its | In some scenarios, a limited negotiation model might be deployed | |||
own global-scope and link-local addresses. In the presence of the | based on a limited trust relationship such as that between two | |||
ACP, such information will be available from the adjacency table | administrative domains. ASAs might then exchange limited information | |||
discussed in [I-D.ietf-anima-reference-model]. In other cases, GRASP | and negotiate some particular configurations. | |||
must determine such information for itself. Details depend on the | ||||
operating system. | ||||
Because GRASP needs to work whatever happens, especially during | A suitable Application Programming Interface (API) will be needed | |||
bootstrapping and during fault conditions, it is essential that every | between GRASP and the ASAs. In some implementations, ASAs would run | |||
implementation is as robust as possible. For example, discovery | in user space with a GRASP library providing the API, and this | |||
failures, or any kind of socket error at any time, must not cause | library would in turn communicate via system calls with core GRASP | |||
irrecoverable failures in GRASP itself, and must return suitable | functions. Details of the API are out of scope for the present | |||
error codes through the API so that ASAs can also recover. | document. For further details of possible deployment models, see | |||
[I-D.ietf-anima-reference-model]. | ||||
GRASP must always start up correctly after a system restart. All run | An instance of GRASP must be aware of the network interfaces it will | |||
time error conditions, and events such as address renumbering, | use, and of the appropriate global-scope and link-local addresses. | |||
network interface failures, and CPU sleep/wake cycles, must be | ||||
handled in such a way that GRASP will still operate correctly and | In the presence of the ACP, such information will be available from | |||
securely (Section 3.5.1) afterwards. | the adjacency table discussed in [I-D.ietf-anima-reference-model]. | |||
In other cases, GRASP must determine such information for itself. | ||||
Details depend on the device and operating system. In the rest of | ||||
this document, the term 'interfaces' refers only to the set of | ||||
network interfaces that a specific instance of GRASP is currently | ||||
using. | ||||
Because GRASP needs to work with very high reliability, especially | ||||
during bootstrapping and during fault conditions, it is essential | ||||
that every implementation is as robust as possible. For example, | ||||
discovery failures, or any kind of socket exception at any time, must | ||||
not cause irrecoverable failures in GRASP itself, and must return | ||||
suitable error codes through the API so that ASAs can also recover. | ||||
GRASP must not depend upon non-volatile data storage. All run time | ||||
error conditions, and events such as address renumbering, network | ||||
interface failures, and CPU sleep/wake cycles, must be handled in | ||||
such a way that GRASP will still operate correctly and securely | ||||
(Section 3.5.1) afterwards. | ||||
An autonomic node will normally run a single instance of GRASP, used | An autonomic node will normally run a single instance of GRASP, used | |||
by multiple ASAs. However, scenarios where multiple instances of | by multiple ASAs. Possible exceptions are mentioned below. | |||
GRASP run in a single node, perhaps with different security | ||||
properties, are not excluded. In this case, each instance MUST | ||||
listen independently for GRASP link-local multicasts in order for | ||||
discovery and flooding to work correctly. | ||||
3.3. High Level Design Choices | 3.3. High Level Design Choices | |||
This section describes a behavior model and design choices for GRASP, | This section describes a behavior model and design choices for GRASP, | |||
supporting discovery, synchronization and negotiation, to act as a | supporting discovery, synchronization and negotiation, to act as a | |||
platform for different technical objectives. | platform for different technical objectives. | |||
o A generic platform | o A generic platform: | |||
The protocol is designed as a generic platform, which is | ||||
independent from the synchronization or negotiation contents. It | ||||
takes care of the general intercommunication between counterparts. | ||||
The technical contents will vary according to the various | ||||
technical objectives and the different pairs of counterparts. | ||||
o The protocol is expected to form part of an Autonomic Networking | ||||
Infrastructure [I-D.ietf-anima-reference-model]. It will provide | ||||
services to ASAs via a suitable application programming interface | ||||
(API), which will reflect the protocol elements but will not | ||||
necessarily be in one-to-one correspondence to them. This API is | ||||
out of scope for the present document. | ||||
o It is normally expected that a single main instance of GRASP will | The protocol design is generic and independent of the | |||
exist in an autonomic node, and that the protocol engine and each | synchronization or negotiation contents. The technical contents | |||
ASA will run as independent asynchronous processes. However, | will vary according to the various technical objectives and the | |||
separate GRASP instances may exist for security-related reasons | different pairs of counterparts. | |||
(Section 3.5.2). | ||||
o Security infrastructure and trust relationship | o Normally, a single main instance of the GRASP protocol engine will | |||
exist in an autonomic node, and each ASA will run as an | ||||
independent asynchronous process. However, scenarios where | ||||
multiple instances of GRASP run in a single node, perhaps with | ||||
different security properties, are possible (Section 3.5.2). In | ||||
this case, each instance MUST listen independently for GRASP link- | ||||
local multicasts, and all instances MUST be woken by each such | ||||
multicast, in order for discovery and flooding to work correctly. | ||||
Because this negotiation protocol may directly cause changes to | o Security infrastructure: | |||
device configurations and bring significant impacts to a running | ||||
network, this protocol is required to run within an existing | ||||
secure environment with strong authentication. As a design | ||||
choice, the protocol itself is not provided with built-in security | ||||
functionality. | ||||
On the other hand, a limited negotiation model might be deployed | As noted above, the protocol itself has no built-in security | |||
based on a limited trust relationship such as that between two | functionality, and relies on a separate secure infrastructure. | |||
administrative domains. ASAs might then exchange limited | ||||
information and negotiate some particular configurations. | ||||
o Discovery, synchronization and negotiation are designed together. | o Discovery, synchronization and negotiation are designed together: | |||
The discovery method and the synchronization and negotiation | The discovery method and the synchronization and negotiation | |||
methods are designed in the same way and can be combined when this | methods are designed in the same way and can be combined when this | |||
is useful, allowing a rapid mode of operation described in | is useful, allowing a rapid mode of operation described in | |||
Section 3.5.4. These processes can also be performed | Section 3.5.4. These processes can also be performed | |||
independently when appropriate. | independently when appropriate. | |||
* Thus, for some objectives, especially those concerned with | * Thus, for some objectives, especially those concerned with | |||
application layer services, another discovery mechanism such as | application layer services, another discovery mechanism such as | |||
the future DNS Service Discovery [RFC7558] MAY be used. The | the future DNS Service Discovery [RFC7558] MAY be used. The | |||
choice is left to the designers of individual ASAs. | choice is left to the designers of individual ASAs. | |||
o A uniform pattern for technical objectives | o A uniform pattern for technical objectives: | |||
The synchronization and negotiation objectives are defined | The synchronization and negotiation objectives are defined | |||
according to a uniform pattern. The values that they contain | according to a uniform pattern. The values that they contain | |||
could be carried either in a simple binary format or in a complex | could be carried either in a simple binary format or in a complex | |||
object format. The basic protocol design uses the Concise Binary | object format. The basic protocol design uses the Concise Binary | |||
Object Representation (CBOR) [RFC7049], which is readily | Object Representation (CBOR) [RFC7049], which is readily | |||
extensible for unknown future requirements. | extensible for unknown future requirements. | |||
o A flexible model for synchronization | o A flexible model for synchronization: | |||
GRASP supports bilateral synchronization, which could be used to | GRASP supports synchronization between two nodes, which could be | |||
perform synchronization among a small number of nodes. It also | used repeatedly to perform synchronization among a small number of | |||
supports an unsolicited flooding mode when large groups of nodes, | nodes. It also supports an unsolicited flooding mode when large | |||
possibly including all autonomic nodes, need data for the same | groups of nodes, possibly including all autonomic nodes, need data | |||
technical objective. | for the same technical objective. | |||
* There may be some network parameters for which a more | * There may be some network parameters for which a more | |||
traditional flooding mechanism such as DNCP [RFC7787] is | traditional flooding mechanism such as DNCP [RFC7787] is | |||
considered more appropriate. GRASP can coexist with DNCP. | considered more appropriate. GRASP can coexist with DNCP. | |||
o A simple initiator/responder model for negotiation | o A simple initiator/responder model for negotiation: | |||
Multi-party negotiations are very complicated to model and cannot | Multi-party negotiations are very complicated to model and cannot | |||
readily be guaranteed to converge. GRASP uses a simple bilateral | readily be guaranteed to converge. GRASP uses a simple bilateral | |||
model and can support multi-party negotiations by indirect steps. | model and can support multi-party negotiations by indirect steps. | |||
o Organizing of synchronization or negotiation content | o Organizing of synchronization or negotiation content: | |||
The technical content transmitted by GRASP will be organized | The technical content transmitted by GRASP will be organized | |||
according to the relevant function or service. The objectives for | according to the relevant function or service. The objectives for | |||
different functions or services are kept separate, because they | different functions or services are kept separate, because they | |||
may be negotiated or synchronized with different counterparts or | may be negotiated or synchronized with different counterparts or | |||
have different response times. Thus a normal arrangement would be | have different response times. Thus a normal arrangement would be | |||
a single ASA managing a small set of closely related objectives, | a single ASA managing a small set of closely related objectives, | |||
with a version of that ASA in each relevant autonomic node. | with a version of that ASA in each relevant autonomic node. | |||
Further discussion of this aspect is out of scope for the current | Further discussion of this aspect is out of scope for the current | |||
document. | document. | |||
o Requests and responses in negotiation procedures | o Requests and responses in negotiation procedures: | |||
The initiator can negotiate a specific negotiation objective with | The initiator can negotiate a specific negotiation objective with | |||
relevant counterpart ASAs. It can request relevant information | relevant counterpart ASAs. It can request relevant information | |||
from a counterpart so that it can coordinate its local | from a counterpart so that it can coordinate its local | |||
configuration. It can request the counterpart to make a matching | configuration. It can request the counterpart to make a matching | |||
configuration. It can request simulation or forecast results by | configuration. It can request simulation or forecast results by | |||
sending some dry run conditions. | sending some dry run conditions. | |||
Beyond the traditional yes/no answer, the responder can reply with | Beyond the traditional yes/no answer, the responder can reply with | |||
a suggested alternative value for the objective concerned. This | a suggested alternative value for the objective concerned. This | |||
would start a bi-directional negotiation ending in a compromise | would start a bi-directional negotiation ending in a compromise | |||
between the two ASAs. | between the two ASAs. | |||
o Convergence of negotiation procedures | o Convergence of negotiation procedures: | |||
To enable convergence, when a responder suggests a new value or | To enable convergence, when a responder suggests a new value or | |||
condition in a negotiation step reply, it should be as close as | condition in a negotiation step reply, it should be as close as | |||
possible to the original request or previous suggestion. The | possible to the original request or previous suggestion. The | |||
suggested value of later negotiation steps should be chosen | suggested value of later negotiation steps should be chosen | |||
between the suggested values from the previous two steps. GRASP | between the suggested values from the previous two steps. GRASP | |||
provides mechanisms to guarantee convergence (or failure) in a | provides mechanisms to guarantee convergence (or failure) in a | |||
small number of steps, i.e. a timeout and a maximum number of | small number of steps, i.e. a timeout and a maximum number of | |||
iterations. | iterations. | |||
o Extensibility | o Extensibility: | |||
GRASP does not have a version number. In most cases new semantics | GRASP does not have a version number, and could be extended by | |||
will be added by defining new synchronization or negotiation | adding new message types and options. In normal use, new | |||
objectives. However, the protocol could be extended by adding new | semantics will be added by defining new synchronization or | |||
message types and options in future. | negotiation objectives. | |||
3.4. Quick Operating Overview | 3.4. Quick Operating Overview | |||
GRASP is expected to run as an operating system core module, | An instance of GRASP is expected to run as a separate core module, | |||
providing an API (such as [I-D.liu-anima-grasp-api]) to interface to | providing an API (such as [I-D.liu-anima-grasp-api]) to interface to | |||
less privileged ASAs. Thus ASAs may operate without special | various ASAs. These ASAs may operate without special privilege, | |||
privilege, unless they need it for other reasons (such as configuring | unless they need it for other reasons (such as configuring IP | |||
IP addresses or manipulating routing tables). | addresses or manipulating routing tables). | |||
The GRASP mechanisms used by the ASA are built around GRASP | The GRASP mechanisms used by the ASA are built around GRASP | |||
objectives defined as data structures containing administrative | objectives defined as data structures containing administrative | |||
information such as the objective's unique name, and its current | information such as the objective's unique name, and its current | |||
value. The format and size of the value is not restricted by the | value. The format and size of the value is not restricted by the | |||
protocol, except that it must be possible to serialise it for | protocol, except that it must be possible to serialise it for | |||
transmission in CBOR, which is no restriction at all in practice. | transmission in CBOR, which is no restriction at all in practice. | |||
The GRASP provides the following mechanisms: | GRASP provides the following mechanisms: | |||
o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA | o A discovery mechanism (M_DISCOVERY, M_RESPONSE), by which an ASA | |||
can discover other ASAs supporting a given objective. | can discover other ASAs supporting a given objective. | |||
o A negotiation request mechanism (M_REQ_NEG), by which an ASA can | o A negotiation request mechanism (M_REQ_NEG), by which an ASA can | |||
start negotiation of an objective with a counterpart ASA. Once a | start negotiation of an objective with a counterpart ASA. Once a | |||
negotiation has started, the process is symmetrical, and there is | negotiation has started, the process is symmetrical, and there is | |||
a negotiation step message (M_NEGOTIATE) for each ASA to use in | a negotiation step message (M_NEGOTIATE) for each ASA to use in | |||
turn. Two other functions support negotiating steps (M_WAIT, | turn. Two other functions support negotiating steps (M_WAIT, | |||
M_END). | M_END). | |||
o A synchronization mechanism (M_REQ_SYN), by which an ASA can | o A synchronization mechanism (M_REQ_SYN), by which an ASA can | |||
request the current value of an objective from a counterpart ASA. | request the current value of an objective from a counterpart ASA. | |||
With this, there is a corresponding response function (M_SYNCH) | With this, there is a corresponding response function (M_SYNCH) | |||
for an ASA that wishes to respond to synchronization requests. | for an ASA that wishes to respond to synchronization requests. | |||
o A flood mechanism (M_FLOOD), by which an ASA can cause the current | o A flood mechanism (M_FLOOD), by which an ASA can cause the current | |||
value of an objective to be flooded throughout the AN so that any | value of an objective to be flooded throughout the autonomic | |||
ASA can receive it. One application of this is to act as an | network so that any ASA can receive it. One application of this | |||
announcement, avoiding the need for discovery of a widely | is to act as an announcement, avoiding the need for discovery of a | |||
applicable objective. | widely applicable objective. | |||
Some example messages and simple message flows are provided in | Some example messages and simple message flows are provided in | |||
Appendix D. | Appendix D. | |||
3.5. GRASP Protocol Basic Properties and Mechanisms | 3.5. GRASP Protocol Basic Properties and Mechanisms | |||
3.5.1. Required External Security Mechanism | 3.5.1. Required External Security Mechanism | |||
The protocol SHOULD always run within a secure Autonomic Control | The protocol SHOULD always run within a secure Autonomic Control | |||
Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is | Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is | |||
assumed to carry all messages securely, including link-local | assumed to carry all messages securely, including link-local | |||
multicast if possible. A GRASP implementation MUST verify whether | multicast when it is virtualized over the ACP. A GRASP instance MUST | |||
the ACP is operational. | verify whether the ACP is operational. | |||
If there is no ACP, the protocol MUST use another form of strong | If there is no ACP, one of the following alternatives applies: | |||
authentication and SHOULD use a form of strong encryption. See | ||||
Section 3.5.2.1 for further discussion. | 1. The protocol instance MUST use another form of strong | |||
authentication and SHOULD use a form of strong encryption. See | ||||
Section 3.5.2.1 for further discussion. | ||||
2. The protocol instance MUST operate as described in | ||||
Section 3.5.2.2 or Section 3.5.2.3. | ||||
Network interfaces could be at different security levels, for example | ||||
being part of the ACP or not. All the interfaces supported by a | ||||
given GRASP instance MUST be at the same security level. | ||||
The ACP, or in its absence another security mechanism, sets the | The ACP, or in its absence another security mechanism, sets the | |||
boundary within which nodes are trusted as GRASP peers. A GRASP | boundary within which nodes are trusted as GRASP peers. A GRASP | |||
implementation MUST refuse to execute GRASP synchronization and | implementation MUST refuse to execute GRASP synchronization and | |||
negotiation functions if there is neither an operational ACP nor | negotiation functions if there is neither an operational ACP nor | |||
another secure environment. | another secure environment. | |||
Link-local multicast is used for discovery messages. Responses to | Link-local multicast is used for discovery messages. Responses to | |||
discovery messages MUST be secured, with one exception mentioned in | discovery messages MUST be secured, with one exception mentioned in | |||
the next section. | the next section. | |||
3.5.2. Constrained Instances | 3.5.2. Constrained Instances | |||
This section describes some examples of cases where additional | This section describes some cases where additional instances of GRASP | |||
instances of GRASP subject to certain constraints are appropriate. | subject to certain constraints are appropriate. | |||
3.5.2.1. No ACP | 3.5.2.1. No ACP | |||
As mentioned in Section 3.3, some GRASP operations might be performed | As mentioned in Section 3.3, some GRASP operations might be performed | |||
across an administrative domain boundary by mutual agreement, without | across an administrative domain boundary by mutual agreement, without | |||
the benefit of an ACP. Such operations MUST be confined to a | the benefit of an ACP. Such operations MUST be confined to a | |||
separate instance of GRASP with its own copy of all GRASP data | separate instance of GRASP with its own copy of all GRASP data | |||
structures. Messages MUST be authenticated and SHOULD be encrypted. | structures. Messages MUST be authenticated and SHOULD be encrypted. | |||
TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure | TLS [RFC5246] and DTLS [RFC6347] based on a Public Key Infrastructure | |||
(PKI) [RFC5280] are RECOMMENDED for this purpose. Further details | (PKI) [RFC5280] are RECOMMENDED for this purpose. Further details | |||
are out of scope for this document. | are out of scope for this document. | |||
3.5.2.2. Discovery Unsolicited Link-Local | 3.5.2.2. Discovery Unsolicited Link-Local | |||
Some services may need to use insecure GRASP discovery, response and | Some services may need to use insecure GRASP discovery, response and | |||
flood messages without being able to use pre-existing security | flood messages without being able to use pre-existing security | |||
associations. Such operations being intrinsically insecure, they | associations. Such operations being intrinsically insecure, they | |||
need to be confined to link-local use to minimise the risk of | need to be confined to link-local use to minimize the risk of | |||
malicious actions. Possible examples include discovery of candidate | malicious actions. Possible examples include discovery of candidate | |||
ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of | ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of | |||
bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps | bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps | |||
initialisation services in networks using GRASP without being fully | initialization services in networks using GRASP without being fully | |||
autonomic (e.g., no ACP). Such usage MUST be limited to link-local | autonomic (e.g., no ACP). Such usage MUST be limited to link-local | |||
operations and MUST be confined to a separate insecure instance of | operations and MUST be confined to a separate insecure instance of | |||
GRASP with its own copy of all GRASP data structures. This instance | GRASP with its own copy of all GRASP data structures. This instance | |||
is nicknamed DULL - Discovery Unsolicited Link-Local. | is nicknamed DULL - Discovery Unsolicited Link-Local. | |||
The detailed rules for the DULL instance of GRASP are as follows: | The detailed rules for the DULL instance of GRASP are as follows: | |||
o An initiator MUST only send Discovery or Flood Synchronization | o An initiator MUST only send Discovery or Flood Synchronization | |||
link-local multicast messages with a loop count of 1. A responder | link-local multicast messages with a loop count of 1. A responder | |||
SHOULD NOT send a Discovery Response message unless it cannot be | SHOULD NOT send a Discovery Response message unless it cannot be | |||
skipping to change at page 18, line 28 | skipping to change at page 18, line 36 | |||
o A responder MUST NOT relay any multicast messages. | o A responder MUST NOT relay any multicast messages. | |||
o A Discovery Response MUST indicate a link-local address. | o A Discovery Response MUST indicate a link-local address. | |||
o A Discovery Response MUST NOT include a Divert option. | o A Discovery Response MUST NOT include a Divert option. | |||
o A node MUST silently discard any message whose source address is | o A node MUST silently discard any message whose source address is | |||
not link-local. | not link-local. | |||
GRASP traffic SHOULD be minimized by using only Flood Synchronization | To minimize traffic possibly observed by third parties, GRASP traffic | |||
to announce objectives and their associated locators, rather than by | SHOULD be minimized by using only Flood Synchronization to announce | |||
using Discovery and Response. Further details are out of scope for | objectives and their associated locators, rather than by using | |||
this document | Discovery and Response. Further details are out of scope for this | |||
document | ||||
3.5.2.3. Secure Only Neighbor Negotiation | 3.5.2.3. Secure Only Neighbor Negotiation | |||
Some services might use insecure on-link operations as in DULL, but | Some services might use insecure on-link operations as in DULL, but | |||
also use unicast synchronization or negotiation operations protected | also use unicast synchronization or negotiation operations protected | |||
by TLS. A separate instance of GRASP is used, with its own copy of | by TLS. A separate instance of GRASP is used, with its own copy of | |||
all GRASP data structures. This instance is nicknamed SONN - Secure | all GRASP data structures. This instance is nicknamed SONN - Secure | |||
Only Neighbor Negotiation. | Only Neighbor Negotiation. | |||
The detailed rules for the SONN instance of GRASP are as follows: | The detailed rules for the SONN instance of GRASP are as follows: | |||
skipping to change at page 19, line 14 | skipping to change at page 19, line 25 | |||
o A responder MUST NOT relay any multicast messages. | o A responder MUST NOT relay any multicast messages. | |||
o A Discovery Response MUST indicate a link-local address. | o A Discovery Response MUST indicate a link-local address. | |||
o A Discovery Response MUST NOT include a Divert option. | o A Discovery Response MUST NOT include a Divert option. | |||
o A node MUST silently discard any message whose source address is | o A node MUST silently discard any message whose source address is | |||
not link-local. | not link-local. | |||
Further details, including TLS and PKI usage, are out of scope for | Further details are out of scope for this document. | |||
this document. | ||||
3.5.3. Transport Layer Usage | 3.5.3. Transport Layer Usage | |||
GRASP discovery and flooding messages are designed for use over link- | GRASP discovery and flooding messages are designed for use over link- | |||
local multicast UDP. They MUST NOT be fragmented, and therefore MUST | local multicast UDP. They MUST NOT be fragmented, and therefore MUST | |||
NOT exceed the link MTU size. Nothing in principle prevents them | NOT exceed the link MTU size. | |||
from working over some other method of sending packets to all on-link | ||||
neighbors, but this is out of scope for the present specification. | ||||
All other GRASP messages are unicast and could in principle run over | All other GRASP messages are unicast and could in principle run over | |||
any transport protocol. An implementation MUST support use of TCP. | any transport protocol. An implementation MUST support use of TCP. | |||
It MAY support use of another transport protocol. However, GRASP | It MAY support use of another transport protocol. However, GRASP | |||
itself does not provide for error detection or retransmission. Use | itself does not provide for error detection or retransmission. Use | |||
of an unreliable transport protocol is therefore NOT RECOMMENDED. | of an unreliable transport protocol is therefore NOT RECOMMENDED. | |||
Nevertheless, when running within a secure ACP on reliable | Nevertheless, when running within a secure ACP on reliable | |||
infrastructure, UDP MAY be used for unicast messages not exceeding | infrastructure, UDP MAY be used for unicast messages not exceeding | |||
the minimum IPv6 path MTU; however, TCP MUST be used for longer | the minimum IPv6 path MTU; however, TCP MUST be used for longer | |||
skipping to change at page 20, line 15 | skipping to change at page 20, line 23 | |||
3.5.4. Discovery Mechanism and Procedures | 3.5.4. Discovery Mechanism and Procedures | |||
3.5.4.1. Separated discovery and negotiation mechanisms | 3.5.4.1. Separated discovery and negotiation mechanisms | |||
Although discovery and negotiation or synchronization are defined | Although discovery and negotiation or synchronization are defined | |||
together in GRASP, they are separate mechanisms. The discovery | together in GRASP, they are separate mechanisms. The discovery | |||
process could run independently from the negotiation or | process could run independently from the negotiation or | |||
synchronization process. Upon receiving a Discovery (Section 3.8.4) | synchronization process. Upon receiving a Discovery (Section 3.8.4) | |||
message, the recipient node should return a response message in which | message, the recipient node should return a response message in which | |||
it either indicates itself as a discovery responder or diverts the | it either indicates itself as a discovery responder or diverts the | |||
initiator towards another more suitable ASA. | initiator towards another more suitable ASA. However, this response | |||
may be delayed if the recipient needs to relay the discovery onwards, | ||||
as described below. | ||||
The discovery action (M_DISCOVERY) will normally be followed by a | The discovery action (M_DISCOVERY) will normally be followed by a | |||
negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The | negotiation (M_REQ_NEG) or synchronization (M_REQ_SYN) action. The | |||
discovery results could be utilized by the negotiation protocol to | discovery results could be utilized by the negotiation protocol to | |||
decide which ASA the initiator will negotiate with. | decide which ASA the initiator will negotiate with. | |||
The initiator of a discovery action for a given objective need not be | The initiator of a discovery action for a given objective need not be | |||
capable of responding to that objective as a Negotiation Counterpart, | capable of responding to that objective as a Negotiation Counterpart, | |||
as a Synchronization Responder or as source for flooding. For | as a Synchronization Responder or as source for flooding. For | |||
example, an ASA might perform discovery even if it only wishes to act | example, an ASA might perform discovery even if it only wishes to act | |||
skipping to change at page 20, line 43 | skipping to change at page 21, line 4 | |||
the scope of GRASP. | the scope of GRASP. | |||
3.5.4.2. Discovery Overview | 3.5.4.2. Discovery Overview | |||
A complete discovery process will start with a multicast (of | A complete discovery process will start with a multicast (of | |||
M_DISCOVERY) on the local link. On-link neighbors supporting the | M_DISCOVERY) on the local link. On-link neighbors supporting the | |||
discovery objective will respond directly (with M_RESPONSE). A | discovery objective will respond directly (with M_RESPONSE). A | |||
neighbor with multiple interfaces will respond with a cached | neighbor with multiple interfaces will respond with a cached | |||
discovery response if any. However, it SHOULD NOT respond with a | discovery response if any. However, it SHOULD NOT respond with a | |||
cached response on an interface if it learnt that information from | cached response on an interface if it learnt that information from | |||
the same interface. If it has no cached response, it will relay the | the same interface, because the peer in question will answer directly | |||
discovery on its other interfaces, for example reaching a higher- | if still operational. If it has no cached response, it will relay | |||
the discovery on its other interfaces, for example reaching a higher- | ||||
level gateway in a hierarchical network. If a node receiving the | level gateway in a hierarchical network. If a node receiving the | |||
relayed discovery supports the discovery objective, it will respond | relayed discovery supports the discovery objective, it will respond | |||
to the relayed discovery. If it has a cached response, it will | to the relayed discovery. If it has a cached response, it will | |||
respond with that. If not, it will repeat the discovery process, | respond with that. If not, it will repeat the discovery process, | |||
which thereby becomes recursive. The loop count and timeout will | which thereby becomes iterative. The loop count and timeout will | |||
ensure that the process ends. | ensure that the process ends. | |||
Exceptionally, a Discovery message MAY be sent unicast (via UDP or | A Discovery message MAY be sent unicast (via UDP or TCP) to a peer | |||
TCP) to a peer node, which will then proceed exactly as if the | node, which SHOULD then proceed exactly as if the message had been | |||
message had been multicast, except that when TCP is used, the | multicast, except that when TCP is used, the response will be on the | |||
response will be on the same socket as the query. However, this mode | same socket as the query. However, this mode does not guarantee | |||
does not guarantee successful discovery in the general case. | successful discovery in the general case. | |||
3.5.4.3. Discovery Procedures | 3.5.4.3. Discovery Procedures | |||
Discovery starts as an on-link operation. The Divert option can tell | Discovery starts as an on-link operation. The Divert option can tell | |||
the discovery initiator to contact an off-link ASA for that discovery | the discovery initiator to contact an off-link ASA for that discovery | |||
objective. Every Discovery message is sent by a discovery initiator | objective. A Discovery message is sent by a discovery initiator via | |||
via UDP to the ALL_GRASP_NEIGHBOR link-local multicast address | UDP to the ALL_GRASP_NEIGHBORS link-local multicast address | |||
(Section 3.6). Every network device that supports GRASP always | (Section 3.6). Every network device that supports GRASP always | |||
listens to a well-known UDP port to capture the discovery messages. | listens to a well-known UDP port to capture the discovery messages. | |||
Because this port is unique in a device, this is a function of the | Because this port is unique in a device, this is a function of the | |||
GRASP core and not of an individual ASA. As a result, each ASA will | GRASP instance and not of an individual ASA. As a result, each ASA | |||
need to register the objectives that it supports with the GRASP core. | will need to register the objectives that it supports with the local | |||
GRASP instance. | ||||
If an ASA in a neighbor device supports the requested discovery | If an ASA in a neighbor device supports the requested discovery | |||
objective, the device SHOULD respond to the link-local multicast with | objective, the device SHOULD respond to the link-local multicast with | |||
a unicast Discovery Response message (Section 3.8.5) with locator | a unicast Discovery Response message (Section 3.8.5) with locator | |||
option(s), unless it is temporarily unavailable. Otherwise, if the | option(s), unless it is temporarily unavailable. Otherwise, if the | |||
neighbor has cached information about an ASA that supports the | neighbor has cached information about an ASA that supports the | |||
requested discovery objective (usually because it discovered the same | requested discovery objective (usually because it discovered the same | |||
objective before), it SHOULD respond with a Discovery Response | objective before), it SHOULD respond with a Discovery Response | |||
message with a Divert option pointing to the appropriate Discovery | message with a Divert option pointing to the appropriate Discovery | |||
Responder. | Responder. | |||
skipping to change at page 21, line 46 | skipping to change at page 22, line 9 | |||
If no discovery response is received within a reasonable timeout | If no discovery response is received within a reasonable timeout | |||
(default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery | (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the Discovery | |||
message MAY be repeated, with a newly generated Session ID | message MAY be repeated, with a newly generated Session ID | |||
(Section 3.7). An exponential backoff SHOULD be used for subsequent | (Section 3.7). An exponential backoff SHOULD be used for subsequent | |||
repetitions, to limit the load during busy periods. Frequent | repetitions, to limit the load during busy periods. Frequent | |||
repetition might be symptomatic of a denial of service attack. | repetition might be symptomatic of a denial of service attack. | |||
After a GRASP device successfully discovers a locator for a Discovery | After a GRASP device successfully discovers a locator for a Discovery | |||
Responder supporting a specific objective, it MUST cache this | Responder supporting a specific objective, it MUST cache this | |||
information, including the interface identifier via which it was | information, including the interface index via which it was | |||
discovered. This cache record MAY be used for future negotiation or | discovered. This cache record MAY be used for future negotiation or | |||
synchronization, and the locator SHOULD be passed on when appropriate | synchronization, and the locator SHOULD be passed on when appropriate | |||
as a Divert option to another Discovery Initiator. | as a Divert option to another Discovery Initiator. | |||
The cache mechanism MUST include a lifetime for each entry. The | The cache mechanism MUST include a lifetime for each entry. The | |||
lifetime is derived from a time-to-live (ttl) parameter in each | lifetime is derived from a time-to-live (ttl) parameter in each | |||
Discovery Response message. Cached entries MUST be ignored or | Discovery Response message. Cached entries MUST be ignored or | |||
deleted after their lifetime expires. In some environments, | deleted after their lifetime expires. In some environments, | |||
unplanned address renumbering might occur. In such cases, the | unplanned address renumbering might occur. In such cases, the | |||
lifetime SHOULD be short compared to the typical address lifetime and | lifetime SHOULD be short compared to the typical address lifetime and | |||
a mechanism to flush the discovery cache SHOULD be implemented. The | a mechanism to flush the discovery cache MUST be implemented. The | |||
discovery mechanism needs to track the node's current address to | discovery mechanism needs to track the node's current address to | |||
ensure that Discovery Responses always indicate the correct address. | ensure that Discovery Responses always indicate the correct address. | |||
If multiple Discovery Responders are found for the same objective, | If multiple Discovery Responders are found for the same objective, | |||
they SHOULD all be cached, unless this creates a resource shortage. | they SHOULD all be cached, unless this creates a resource shortage. | |||
The method of choosing between multiple responders is an | The method of choosing between multiple responders is an | |||
implementation choice. This choice MUST be available to each ASA but | implementation choice. This choice MUST be available to each ASA but | |||
the GRASP implementation SHOULD provide a default choice. | the GRASP implementation SHOULD provide a default choice. | |||
Because Discovery Responders will be cached in a finite cache, they | Because Discovery Responders will be cached in a finite cache, they | |||
skipping to change at page 22, line 30 | skipping to change at page 22, line 42 | |||
be repeated. If an ASA exits for any reason, its locator might still | 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. | be cached for some time, and attempts to connect to it will fail. | |||
ASAs need to be robust in these circumstances. | ASAs need to be robust in these circumstances. | |||
3.5.4.4. Discovery Relaying | 3.5.4.4. Discovery Relaying | |||
A GRASP instance with multiple link-layer interfaces (typically | A GRASP instance with multiple link-layer interfaces (typically | |||
running in a router) MUST support discovery on all interfaces. We | running in a router) MUST support discovery on all interfaces. We | |||
refer to this as a 'relaying instance'. | refer to this as a 'relaying instance'. | |||
However, different interfaces can be at different security levels: | Constrained Instances (Section 3.5.2) are always single-interface | |||
each group of interfaces with the same security level SHOULD be | instances and therefore MUST NOT perform discovery relaying. | |||
serviced by the same GRASP process, except for Limited Security | ||||
Instances Section 3.5.2 which are always single-interface instances | ||||
and MUST NOT perform discovery relaying. | ||||
If a relaying instance receives a Discovery message on a given | If a relaying instance receives a Discovery message on a given | |||
interface for a specific objective that it does not support and for | interface for a specific objective that it does not support and for | |||
which it has not previously cached a Discovery Responder, it MUST | which it has not previously cached a Discovery Responder, it MUST | |||
relay the query by re-issuing a Discovery message as a link-local | relay the query by re-issuing a new Discovery message as a link-local | |||
multicast on its other interfaces. | multicast on its other interfaces. | |||
The relayed discovery message MUST have the same Session ID as the | The relayed discovery message MUST have the same Session ID as the | |||
incoming discovery message and MUST be tagged with the IP address of | incoming discovery message and MUST be tagged with the IP address of | |||
its original initiator (see Section 3.8.4). Note that this initiator | its original initiator (see Section 3.8.4). Note that this initiator | |||
address is only used to allow for disambiguation of the Session ID | address is only used to allow for disambiguation of the Session ID | |||
and is never used to address Response packets. | and is never used to address Response packets, which are sent to the | |||
relaying instance, not the original initiator. | ||||
Since the relay device is unaware of the timeout set by the original | Since the relay device is unaware of the timeout set by the original | |||
initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT | initiator it SHOULD set a timeout at least equal to GRASP_DEF_TIMEOUT | |||
milliseconds. | milliseconds. | |||
The relaying instance MUST decrement the loop count within the | The relaying instance MUST decrement the loop count within the | |||
objective, and MUST NOT relay the Discovery message if the result is | objective, and MUST NOT relay the Discovery message if the result is | |||
zero. Also, it MUST limit the total rate at which it relays | zero. Also, it MUST limit the total rate at which it relays | |||
discovery messages to a reasonable value, in order to mitigate | discovery messages to a reasonable value, in order to mitigate | |||
possible denial of service attacks. It MUST cache the Session ID | possible denial of service attacks. It MUST cache the Session ID | |||
skipping to change at page 23, line 21 | skipping to change at page 23, line 32 | |||
any Discovery Responses have arrived or the discovery process has | any Discovery Responses have arrived or the discovery process has | |||
timed out. To prevent loops, it MUST NOT relay a Discovery message | timed out. To prevent loops, it MUST NOT relay a Discovery message | |||
which carries a given cached Session ID and initiator address more | which carries a given cached Session ID and initiator address more | |||
than once. These precautions avoid discovery loops and mitigate | than once. These precautions avoid discovery loops and mitigate | |||
potential overload. | potential overload. | |||
The discovery results received by the relaying instance MUST in turn | The discovery results received by the relaying instance MUST in turn | |||
be sent as a Discovery Response message to the Discovery message that | be sent as a Discovery Response message to the Discovery message that | |||
caused the relay action. | caused the relay action. | |||
This relayed discovery mechanism, with caching of the results, should | ||||
be sufficient to support most network bootstrapping scenarios. | ||||
3.5.4.5. Rapid Mode (Discovery/Negotiation binding) | 3.5.4.5. Rapid Mode (Discovery/Negotiation binding) | |||
A Discovery message MAY include a Negotiation Objective option. This | A Discovery message MAY include a Negotiation Objective option. This | |||
allows a rapid mode of negotiation described in Section 3.5.5. A | allows a rapid mode of negotiation described in Section 3.5.5. A | |||
similar mechanism is defined for synchronization in Section 3.5.6. | similar mechanism is defined for synchronization in Section 3.5.6. | |||
Note that rapid mode is currently limited to a single objective for | Note that rapid mode is currently limited to a single objective for | |||
simplicity of design and implementation. A possible future extension | simplicity of design and implementation. A possible future extension | |||
is to allow multiple objectives in rapid mode for greater efficiency. | is to allow multiple objectives in rapid mode for greater efficiency. | |||
3.5.5. Negotiation Procedures | 3.5.5. Negotiation Procedures | |||
A negotiation initiator sends a negotiation request to a counterpart | A negotiation initiator sends a negotiation request (using M_REQ_NEG) | |||
ASA, including a specific negotiation objective. It may request the | to a counterpart ASA, including a specific negotiation objective. It | |||
negotiation counterpart to make a specific configuration. | may request the negotiation counterpart to make a specific | |||
Alternatively, it may request a certain simulation or forecast result | configuration. Alternatively, it may request a certain simulation or | |||
by sending a dry run configuration. The details, including the | forecast result by sending a dry run configuration. The details, | |||
distinction between dry run and an actual configuration change, will | including the distinction between dry run and an actual configuration | |||
be defined separately for each type of negotiation objective. | change, will be defined separately for each type of negotiation | |||
objective. | ||||
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.6), the | timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the | |||
negotiation request MAY be repeated, with a newly generated Session | negotiation request MAY be repeated, with a newly generated Session | |||
ID (Section 3.7). An exponential backoff SHOULD be used for | ID (Section 3.7). An exponential backoff SHOULD be used for | |||
subsequent repetitions. | subsequent repetitions. | |||
If the counterpart can immediately apply the requested configuration, | If the counterpart can immediately apply the requested configuration, | |||
it will give an immediate positive (O_ACCEPT) answer (using M_END). | it will give an immediate positive (O_ACCEPT) answer (using M_END). | |||
This will end the negotiation phase immediately. Otherwise, it will | This will end the negotiation phase immediately. Otherwise, it will | |||
skipping to change at page 25, line 4 | skipping to change at page 25, line 13 | |||
node does not support rapid mode, discovery will continue normally. | node does not support rapid mode, discovery will continue normally. | |||
It is possible that a Discovery Response will arrive from a responder | It is possible that a Discovery Response will arrive from a responder | |||
that does not support rapid mode, before such a Negotiation message | that does not support rapid mode, before such a Negotiation message | |||
arrives. In this case, rapid mode will not occur. | arrives. In this case, rapid mode will not occur. | |||
This rapid mode could reduce the interactions between nodes so that a | This rapid mode could reduce the interactions between nodes so that a | |||
higher efficiency could be achieved. However, a network in which | higher efficiency could be achieved. However, a network in which | |||
some nodes support rapid mode and others do not will have complex | some nodes support rapid mode and others do not will have complex | |||
timing-dependent behaviors. Therefore, the rapid negotiation | timing-dependent behaviors. Therefore, the rapid negotiation | |||
function SHOULD be configured off by default and MAY be configured on | function SHOULD be disabled by default. | |||
or off by Intent. | ||||
3.5.6. Synchronization and Flooding Procedure | 3.5.6. Synchronization and Flooding Procedures | |||
3.5.6.1. Unicast Synchronization | ||||
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 Synchronization message (Section 3.8.10) | counterpart responds with a Synchronization message (Section 3.8.10) | |||
containing the current value of the requested synchronization | containing the current value of the requested synchronization | |||
objective. No further 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.6), the | timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the | |||
synchronization request MAY be repeated, with a newly generated | synchronization request MAY be repeated, with a newly generated | |||
Session ID (Section 3.7). An exponential backoff SHOULD be used for | Session ID (Section 3.7). An exponential backoff SHOULD be used for | |||
subsequent repetitions. | subsequent repetitions. | |||
3.5.6.1. Flooding | 3.5.6.2. 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 flooding initiator MAY send an unsolicited Flood | For this, a flooding initiator MAY send an unsolicited Flood | |||
Synchronization message containing one or more Synchronization | Synchronization message containing one or more Synchronization | |||
Objective option(s), if and only if the specification of those | Objective option(s), if and only if the specification of those | |||
objectives permits it. This is sent as a multicast message to the | objectives permits it. This is sent as a multicast message to the | |||
ALL_GRASP_NEIGHBOR multicast address (Section 3.6). | ALL_GRASP_NEIGHBORS multicast address (Section 3.6). | |||
Every network device that supports GRASP always listens to a well- | Receiving flood multicasts is a function of the GRASP core, as in the | |||
known UDP port to capture flooding messages. Because this port is | case of discovery multicasts (Section 3.5.4.3). | |||
unique in a device, this is a function of the GRASP core. | ||||
To ensure that flooding does not result in a loop, the originator of | To ensure that flooding does not result in a loop, the originator of | |||
the Flood Synchronization message MUST set the loop count in the | the Flood Synchronization message MUST set the loop count in the | |||
objectives to a suitable value (the default is GRASP_DEF_LOOPCT). | objectives to a suitable value (the default is GRASP_DEF_LOOPCT). | |||
Also, a suitable mechanism is needed to avoid excessive multicast | Also, a suitable mechanism is needed to avoid excessive multicast | |||
traffic. This mechanism MUST be defined as part of the specification | traffic. This mechanism MUST be defined as part of the specification | |||
of the synchronization objective(s) concerned. It might be a simple | of the synchronization objective(s) concerned. It might be a simple | |||
rate limit or a more complex mechanism such as the Trickle algorithm | rate limit or a more complex mechanism such as the Trickle algorithm | |||
[RFC6206]. | [RFC6206]. | |||
skipping to change at page 26, line 16 | skipping to change at page 26, line 24 | |||
to 1, and sending with a link-local source address. Floods with | to 1, and sending with a link-local source address. Floods with | |||
link-local source addresses and a loop count other than 1 are | link-local source addresses and a loop count other than 1 are | |||
invalid, and such messages MUST be discarded. | invalid, and such messages MUST be discarded. | |||
The relaying device MUST decrement the loop count within the first | The relaying device MUST decrement the loop count within the first | |||
objective, and MUST NOT relay the Flood Synchronization message if | objective, and MUST NOT relay the Flood Synchronization message if | |||
the result is zero. Also, it MUST limit the total rate at which it | the result is zero. Also, it MUST limit the total rate at which it | |||
relays Flood Synchronization messages to a reasonable value, in order | relays Flood Synchronization messages to a reasonable value, in order | |||
to mitigate possible denial of service attacks. It MUST cache the | to mitigate possible denial of service attacks. It MUST cache the | |||
Session ID value and initiator address of each relayed Flood | Session ID value and initiator address of each relayed Flood | |||
Synchronization message for a finite time not less than twice | Synchronization message for a time not less than twice | |||
GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay | GRASP_DEF_TIMEOUT milliseconds. To prevent loops, it MUST NOT relay | |||
a Flood Synchronization message which carries a given cached Session | a Flood Synchronization message which carries a given cached Session | |||
ID and initiator address more than once. These precautions avoid | ID and initiator address more than once. These precautions avoid | |||
synchronization loops and mitigate potential overload. | synchronization loops and 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, | |||
or new nodes that join the network, or nodes that rejoin the network | or new nodes that join the network, or nodes that rejoin the network | |||
after a fault. An ASA that initiates a flood SHOULD repeat the flood | after a fault. An ASA that initiates a flood SHOULD repeat the flood | |||
at a suitable frequency and SHOULD also act as a synchronization | at a suitable frequency and SHOULD also act as a synchronization | |||
responder for the objective(s) concerned. Thus nodes that require an | responder for the objective(s) concerned. Thus nodes that require an | |||
skipping to change at page 26, line 39 | skipping to change at page 26, line 47 | |||
The multicast messages for synchronization flooding are subject to | The multicast messages for synchronization flooding are subject to | |||
the security rules in Section 3.5.1. In practice this means that | the security rules in Section 3.5.1. In practice this means that | |||
they MUST NOT be transmitted and MUST be ignored on receipt unless | they MUST NOT be transmitted and MUST be ignored on receipt unless | |||
there is an operational ACP or equivalent strong security in place. | there is an operational ACP or equivalent strong security in place. | |||
However, because of the security weakness of link-local multicast | However, because of the security weakness of link-local multicast | |||
(Section 5), synchronization objectives that are flooded SHOULD NOT | (Section 5), synchronization objectives that are flooded SHOULD NOT | |||
contain unencrypted private information and SHOULD be validated by | contain unencrypted private information and SHOULD be validated by | |||
the recipient ASA. | the recipient ASA. | |||
3.5.6.2. Rapid Mode (Discovery/Synchronization Linkage) | 3.5.6.3. Rapid Mode (Discovery/Synchronization Linkage) | |||
A Discovery message MAY include a Synchronization Objective option. | A Discovery message MAY include a Synchronization Objective option. | |||
In this case the Discovery message also acts as a Request | In this case the Discovery message also acts as a Request | |||
Synchronization message to indicate to the Discovery Responder that | Synchronization message to indicate to the Discovery Responder that | |||
it could directly reply to the Discovery Initiator with a | it could directly reply to the Discovery Initiator with a | |||
Synchronization message Section 3.8.10 with synchronization data for | Synchronization message Section 3.8.10 with synchronization data for | |||
rapid processing, if the discovery target supports the corresponding | rapid processing, if the discovery target supports the corresponding | |||
synchronization objective. The design implications are similar to | synchronization objective. The design implications are similar to | |||
those discussed in Section 3.5.5.1. | those discussed in Section 3.5.5.1. | |||
skipping to change at page 27, line 14 | skipping to change at page 27, line 22 | |||
This rapid mode could reduce the interactions between nodes so that a | This rapid mode could reduce the interactions between nodes so that a | |||
higher efficiency could be achieved. However, a network in which | higher efficiency could be achieved. However, a network in which | |||
some nodes support rapid mode and others do not will have complex | some nodes support rapid mode and others do not will have complex | |||
timing-dependent behaviors. Therefore, the rapid synchronization | timing-dependent behaviors. Therefore, the rapid synchronization | |||
function SHOULD be configured off by default and MAY be configured on | function SHOULD be configured off by default and MAY be configured on | |||
or off by Intent. | or off by Intent. | |||
3.6. GRASP Constants | 3.6. GRASP Constants | |||
o ALL_GRASP_NEIGHBOR | o ALL_GRASP_NEIGHBORS | |||
A link-local scope multicast address used by a GRASP-enabled | A link-local scope multicast address used by a GRASP-enabled | |||
device to discover GRASP-enabled neighbor (i.e., on-link) devices | device to discover GRASP-enabled neighbor (i.e., on-link) devices. | |||
. All devices that support GRASP are members of this multicast | All devices that support GRASP are members of this multicast | |||
group. | group. | |||
* IPv6 multicast address: TBD1 | * IPv6 multicast address: TBD1 | |||
* IPv4 multicast address: TBD2 | * IPv4 multicast address: TBD2 | |||
o GRASP_LISTEN_PORT (TBD3) | o GRASP_LISTEN_PORT (TBD3) | |||
A well-known UDP user port that every GRASP-enabled network device | A well-known UDP user port that every GRASP-enabled network device | |||
MUST always listen to for link-local multicasts. Additionally, | MUST always listen to for link-local multicasts. This user port | |||
this user port MAY be used to listen for TCP or UDP unicast | MAY also be used to listen for TCP or UDP unicast messages in a | |||
messages in a simple implementation of GRASP (Section 3.5.3). | simple implementation of GRASP (Section 3.5.3). | |||
o GRASP_DEF_TIMEOUT (60000 milliseconds) | o GRASP_DEF_TIMEOUT (60000 milliseconds) | |||
The default timeout used to determine that a discovery etc. has | The default timeout used to determine that a discovery etc. has | |||
failed to complete. | failed to complete. | |||
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. | |||
skipping to change at page 28, line 41 | skipping to change at page 28, line 49 | |||
3.8. GRASP Messages | 3.8. GRASP Messages | |||
3.8.1. Message Overview | 3.8.1. Message Overview | |||
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. | |||
The messages currently defined are: | The messages currently defined are: | |||
Discovery and Discovery Response. | Discovery and Discovery Response (M_DISCOVERY, M_RESPONSE). | |||
Request Negotiation, Negotiation, Confirm Waiting and Negotiation | Request Negotiation, Negotiation, Confirm Waiting and Negotiation | |||
End. | End (M_REQ_NEG, M_NEGOTIATE, M_WAIT, M_END). | |||
Request Synchronization, Synchronization, and Flood | Request Synchronization, Synchronization, and Flood | |||
Synchronization. | Synchronization (M_REQ_SYN, M_SYNCH, M_FLOOD. | |||
No Operation. | No Operation and Invalid (M_NOOP, M_INVALID). | |||
3.8.2. GRASP Message Format | 3.8.2. 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, including | CDDL specification of GRASP is given in Section 6, including | |||
skipping to change at page 29, line 42 | skipping to change at page 29, line 50 | |||
the expected options. Any options received that are not consistent | the expected options. Any options received that are not consistent | |||
with the MESSAGE_TYPE SHOULD be silently discarded. | with the MESSAGE_TYPE SHOULD be silently discarded. | |||
The No Operation (noop) message is described in Section 3.8.13. | The No Operation (noop) message is described in Section 3.8.13. | |||
The various MESSAGE_TYPE values are defined in Section 6. | The various MESSAGE_TYPE values are defined in Section 6. | |||
All other message elements are described below and formally defined | All other message elements are described below and formally defined | |||
in Section 6. | in Section 6. | |||
If an unrecognized MESSAGE_TYPE is received in a unicast message, an | ||||
Invalid message (Section 3.8.12) MAY be returned. Otherwise the | ||||
message MAY be logged and MUST be discarded. If an unrecognized | ||||
MESSAGE_TYPE is received in a multicast message, it MAY be logged and | ||||
MUST be silently discarded. | ||||
3.8.3. Message Size | 3.8.3. Message Size | |||
GRASP nodes MUST be able to receive messages of at least | GRASP nodes MUST be able to receive unicast messages of at least | |||
GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send messages longer | GRASP_DEF_MAX_SIZE bytes. GRASP nodes MUST NOT send unicast messages | |||
than GRASP_DEF_MAX_SIZE bytes unless a longer size is explicitly | longer than GRASP_DEF_MAX_SIZE bytes unless a longer size is | |||
allowed for the objective concerned. For example, GRASP negotiation | explicitly allowed for the objective concerned. For example, GRASP | |||
itself could be used to agree on a longer message size. | negotiation itself could be used to agree on a longer message size. | |||
The message parser used by GRASP should be configured to know about | The message parser used by GRASP should be configured to know about | |||
the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so | the GRASP_DEF_MAX_SIZE, or any larger negotiated message size, so | |||
that it may defend against overly long messages. | that it may defend against overly long messages. | |||
The maximum size of multicast messages (M_DISCOVERY and M_FLOOD) | ||||
depends on the link layer technology or link adaptation layer in use. | ||||
3.8.4. Discovery Message | 3.8.4. 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, initiator, objective] | discovery-message = [M_DISCOVERY, session-id, initiator, objective] | |||
A discovery initiator sends a Discovery message to initiate a | A discovery initiator sends a Discovery message to initiate a | |||
discovery process for a particular objective option. | discovery process for a particular objective option. | |||
The discovery initiator sends all Discovery messages via UDP to port | The discovery initiator sends all Discovery messages via UDP to port | |||
GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBOR multicast | GRASP_LISTEN_PORT at the link-local ALL_GRASP_NEIGHBORS multicast | |||
address on each link-layer interface in use by GRASP. It then | address on each link-layer interface in use by GRASP. It then | |||
listens for unicast TCP responses on a given port, and stores the | listens for unicast TCP responses on a given port, and stores the | |||
discovery results (including responding discovery objectives and | discovery results (including responding discovery objectives and | |||
corresponding unicast locators). | corresponding unicast locators). | |||
The listening port used for TCP MUST be the same port as used for | The listening port used for TCP MUST be the same port as used for | |||
sending the Discovery UDP multicast, on a given interface. In a low- | sending the Discovery UDP multicast, on a given interface. In a low- | |||
end implementation this MAY be GRASP_LISTEN_PORT. In a more complex | end implementation this MAY be GRASP_LISTEN_PORT. In a more complex | |||
implementation, the GRASP discovery mechanism will find, for each | implementation, the GRASP discovery mechanism will find, for each | |||
interface, a dynamic port that it can bind to for both UDP and TCP | interface, a dynamic port that it can bind to for both UDP and TCP | |||
skipping to change at page 31, line 10 | skipping to change at page 31, line 29 | |||
(Section 3.8.6). | (Section 3.8.6). | |||
o a synchronization objective option (Section 3.10.1). This is used | o a synchronization objective option (Section 3.10.1). This is used | |||
both for the purpose of discovery and to indicate to the discovery | both for the purpose of discovery and to indicate to the discovery | |||
target that it MAY directly reply to the discovery initiator with | target that it MAY directly reply to the discovery initiator with | |||
a Synchronization message for rapid processing, if it could act as | a Synchronization message for rapid processing, if it could act as | |||
the corresponding synchronization counterpart. Its loop count | the corresponding synchronization counterpart. Its loop count | |||
MUST be set to a suitable value to prevent discovery loops | MUST be set to a suitable value to prevent discovery loops | |||
(default value is GRASP_DEF_LOOPCT). | (default value is GRASP_DEF_LOOPCT). | |||
Exceptionally, a Discovery message MAY be sent unicast to a peer | As mentioned in Section 3.5.4.2, a Discovery message MAY be sent | |||
node, which will then proceed exactly as if the message had been | unicast to a peer node, which SHOULD then proceed exactly as if the | |||
multicast. | message had been multicast. | |||
3.8.5. Discovery Response Message | 3.8.5. Discovery Response Message | |||
In fragmentary CDDL, a Discovery Response message follows the | In fragmentary CDDL, a Discovery Response message follows the | |||
pattern: | pattern: | |||
response-message = [M_RESPONSE, session-id, initiator, ttl, | response-message = [M_RESPONSE, session-id, initiator, ttl, | |||
(+locator-option // divert-option), ?objective)] | (+locator-option // divert-option), ?objective)] | |||
ttl = 0..4294967295 ; in milliseconds | ttl = 0..4294967295 ; in milliseconds | |||
skipping to change at page 31, line 39 | skipping to change at page 32, line 10 | |||
It MUST contain a time-to-live (ttl) for the validity of the | It MUST contain a time-to-live (ttl) for the validity of the | |||
response, given as a positive integer value in milliseconds. Zero | response, given as a positive integer value in milliseconds. Zero | |||
is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). | is treated as the default value GRASP_DEF_TIMEOUT (Section 3.6). | |||
It MAY include a copy of the discovery objective from the | It MAY include a copy of the discovery objective from the | |||
Discovery message. | Discovery message. | |||
It is sent to the sender of the Discovery message via TCP at the port | It is sent to the sender of the Discovery message via TCP at the port | |||
used to send the Discovery message (as explained in Section 3.8.4). | used to send the Discovery message (as explained in Section 3.8.4). | |||
In the case of a relayed Discovery message, the Discovery Response is | ||||
thus sent to the relay, not the original initiator. | ||||
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.9.5) to indicate its own location. A sequence of multiple | (Section 3.9.5) to indicate its own location. A sequence of multiple | |||
kinds of locator options (e.g. IP address option and FQDN option) is | kinds of locator options (e.g. IP address option and FQDN 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 | |||
skipping to change at page 33, line 45 | skipping to change at page 34, line 21 | |||
A negotiation counterpart sends an Negotiation End message to close | A negotiation counterpart sends an Negotiation End message to close | |||
the negotiation. It MUST contain either an accept or a decline | the negotiation. It MUST contain either an accept or a decline | |||
option, defined in Section 3.9.3 and Section 3.9.4. It could be sent | option, defined in Section 3.9.3 and Section 3.9.4. It could be sent | |||
either by the requesting node or the responding node. | either by the requesting node or the responding node. | |||
3.8.9. Confirm Waiting Message | 3.8.9. 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] | wait-message = [M_WAIT, session-id, waiting-time] | |||
waiting-time = 0..4294967295 ; in milliseconds | waiting-time = 0..4294967295 ; in milliseconds | |||
A responding node sends a Confirm Waiting message to ask 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. When received, the waiting time value | include any other options. When received, the waiting time value | |||
overwrites and restarts the current negotiation timer | overwrites and restarts the current negotiation timer | |||
(Section 3.8.6). | (Section 3.8.6). | |||
The responding node SHOULD send a Negotiation, Negotiation End or | The responding node SHOULD send a Negotiation, Negotiation End or | |||
skipping to change at page 34, line 36 | skipping to change at page 35, line 12 | |||
In fragmentary CDDL, a Flood Synchronization message follows the | In fragmentary CDDL, a Flood Synchronization message follows the | |||
pattern: | pattern: | |||
flood-message = [M_FLOOD, session-id, initiator, ttl, | flood-message = [M_FLOOD, session-id, initiator, ttl, | |||
+[objective, (locator-option / [])]] | +[objective, (locator-option / [])]] | |||
ttl = 0..4294967295 ; in milliseconds | ttl = 0..4294967295 ; in milliseconds | |||
A node MAY initiate flooding by sending an unsolicited Flood | A node MAY initiate flooding by sending an unsolicited Flood | |||
Synchronization Message with synchronization data. This MAY be sent | Synchronization Message with synchronization data. This MAY be sent | |||
to the link-local ALL_GRASP_NEIGHBOR multicast address, in accordance | to the link-local ALL_GRASP_NEIGHBORS multicast address, in | |||
with the rules in Section 3.5.6. | accordance with the rules in Section 3.5.6. | |||
The initiator address is provided, as described for Discovery | The initiator address is provided, as described for Discovery | |||
messages (Section 3.8.4), only to disambiguate the Session ID. | messages (Section 3.8.4), only to disambiguate the Session ID. | |||
The message MUST contain a time-to-live (ttl) for the validity of | The message MUST contain a time-to-live (ttl) for the validity of | |||
the contents, given as a positive integer value in milliseconds. | the contents, given as a positive integer value in milliseconds. | |||
There is no default; zero indicates an indefinite lifetime. | There is no default; zero indicates an indefinite lifetime. | |||
The synchronization data are in the form of GRASP Option(s) for | The synchronization data are in the form of GRASP Option(s) for | |||
specific synchronization objective(s). The loop count(s) MUST be | specific synchronization objective(s). The loop count(s) MUST be | |||
skipping to change at page 35, line 36 | skipping to change at page 36, line 12 | |||
Cached entries MUST be ignored or deleted after their lifetime | Cached entries MUST be ignored or deleted after their lifetime | |||
expires. | expires. | |||
3.8.12. Invalid Message | 3.8.12. Invalid Message | |||
In fragmentary CDDL, an Invalid message follows the pattern: | In fragmentary CDDL, an Invalid message follows the pattern: | |||
invalid-message = [M_INVALID, session-id, ?any] | invalid-message = [M_INVALID, session-id, ?any] | |||
This message MAY be sent by an implementation in response to an | This message MAY be sent by an implementation in response to an | |||
incoming message that it considers invalid. The session-id MUST be | incoming unicast message that it considers invalid. The session-id | |||
copied from the incoming message. The content SHOULD be diagnostic | MUST be copied from the incoming message. The content SHOULD be | |||
information such as a partial copy of the invalid message. An | diagnostic information such as a partial copy of the invalid message. | |||
M_INVALID message MAY be silently ignored by a recipient. However, | An M_INVALID message MAY be silently ignored by a recipient. | |||
it could be used in support of extensibility, since it indicates that | However, it could be used in support of extensibility, since it | |||
the remote node does not support a new or obsolete message or option | indicates that the remote node does not support a new or obsolete | |||
message or option. | ||||
An M_INVALID message MUST NOT be sent in response to an M_INVALID | An M_INVALID message MUST NOT be sent in response to an M_INVALID | |||
message. | message. | |||
3.8.13. No Operation Message | 3.8.13. No Operation Message | |||
In fragmentary CDDL, a No Operation message follows the pattern: | In fragmentary CDDL, a No Operation message follows the pattern: | |||
noop-message = [M_NOOP] | noop-message = [M_NOOP] | |||
This message MAY be sent by an implementation that for practical | This message MAY be sent by an implementation that for practical | |||
reasons needs to activate a socket. It MUST be silently ignored by a | reasons needs to initialize a socket. It MUST be silently ignored by | |||
recipient. | a recipient. | |||
3.9. GRASP Options | 3.9. GRASP Options | |||
This section defines the GRASP options for the negotiation and | This section defines the GRASP options for the negotiation and | |||
synchronization protocol signaling. Additional options may be | synchronization protocol signaling. Additional options may be | |||
defined in the future. | defined in the future. | |||
3.9.1. Format of GRASP Options | 3.9.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. | |||
These option types are formally defined in Section 6. Apart from | These option types are formally defined in Section 6. Apart from | |||
that the only format requirement is that each option MUST be a well- | that the only format requirement is that each option MUST be a well- | |||
formed CBOR object. In general a CBOR array format is RECOMMENDED to | formed CBOR object. In general a CBOR array format is RECOMMENDED to | |||
limit overhead. | limit overhead. | |||
GRASP options are usually scoped by using encapsulation. However, | GRASP options may be defined to include encapsulated GRASP options. | |||
this is not a requirement | ||||
3.9.2. Divert Option | 3.9.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 Discovery Response messages. If found elsewhere, it | encapsulated in Discovery Response messages. If found elsewhere, it | |||
SHOULD be silently ignored. | SHOULD be silently ignored. | |||
skipping to change at page 37, line 26 | skipping to change at page 37, line 51 | |||
process. | process. | |||
The decline option MUST only be encapsulated in Negotiation End | The decline option MUST only be encapsulated in Negotiation End | |||
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, ?reason] | decline-option = [O_DECLINE, ?reason] | |||
reason = text ;optional error message | reason = text ;optional error message | |||
Note: there are scenarios where a negotiation counterpart wants to | Note: there might be scenarios where an ASA wants to decline the | |||
decline the proposed negotiation content and continue the negotiation | proposed value and restart the negotiation process. In this case it | |||
process. For these scenarios, the negotiation counterpart SHOULD use | is an implementation choice whether to send a Decline option or to | |||
a Negotiate message, with either an objective option that contains a | continue with a Negotiate message, with an objective option that | |||
data field set to indicate a meaningless initial value, or a specific | contains a null value, or one that contains a new value that might | |||
objective option that provides further conditions for convergence. | achieve convergence. | |||
3.9.5. Locator Options | 3.9.5. 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 IPv6 Address | for an ASA, a device or an interface. They are Locator IPv6 Address | |||
Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified | Option, Locator IPv4 Address Option, Locator FQDN (Fully Qualified | |||
Domain Name) Option and URI (Uniform Resource Identifier) Option. | Domain Name) Option and URI (Uniform Resource Identifier) Option. | |||
Since ASAs will normally run as independent user programs, locator | Since ASAs will normally run as independent user programs, locator | |||
options need to indicate the network layer locator plus the transport | options need to indicate the network layer locator plus the transport | |||
skipping to change at page 38, line 21 | skipping to change at page 38, line 43 | |||
ipv6-address = bytes .size 16 | ipv6-address = bytes .size 16 | |||
transport-proto = IPPROTO_TCP / IPPROTO_UDP | transport-proto = IPPROTO_TCP / IPPROTO_UDP | |||
IPPROTO_TCP = 6 | IPPROTO_TCP = 6 | |||
IPPROTO_UDP = 17 | IPPROTO_UDP = 17 | |||
port-number = 0..65535 | port-number = 0..65535 | |||
The content of this option is a binary IPv6 address followed by the | The content of this option is a binary IPv6 address followed by the | |||
protocol number and port number to be used. | protocol number and port number to be used. | |||
Note 1: The IPv6 address MUST normally have global scope. | Note 1: The IPv6 address MUST normally have global scope. However, | |||
Exceptionally, during initialisation, a link-local address MAY be | during initialization, a link-local address MAY be used for specific | |||
used for specific objectives only (Section 3.5.2). In this case the | objectives only (Section 3.5.2). In this case the corresponding | |||
corresponding Discovery Response message MUST be sent via the | Discovery Response message MUST be sent via the interface to which | |||
interface to which the link-local address applies. | the link-local address applies. | |||
Note 2: A link-local IPv6 address MUST NOT be used when this option | Note 2: A link-local IPv6 address MUST NOT be used when this option | |||
is included in a Divert option. | is included in a Divert option. | |||
3.9.5.2. Locator IPv4 address option | 3.9.5.2. 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 = [O_IPv4_LOCATOR, ipv4-address, | ipv4-locator-option = [O_IPv4_LOCATOR, ipv4-address, | |||
transport-proto, port-number] | transport-proto, port-number] | |||
skipping to change at page 40, line 26 | skipping to change at page 40, line 49 | |||
The GRASP protocol treats the objective name as an opaque string. | The GRASP protocol treats the objective name as an opaque string. | |||
For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 | For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 | |||
and "user@example.org:EX1" would be five different objectives. | and "user@example.org:EX1" would be five different objectives. | |||
The 'objective-flags' field is described below. | 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.8.7. It is also used for terminating | described in Section 3.8.7. It is also used for terminating | |||
discovery as described in Section 3.5.4, and for terminating flooding | discovery as described in Section 3.5.4, and for terminating flooding | |||
as described in Section 3.5.6.1. | as described in Section 3.5.6.2. It is placed in the objective | |||
rather than in the GRASP message format because, as far as the ASA is | ||||
concerned, it is a property of the objective itself. | ||||
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 simple 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 Discovery Response message. | Discovery or Discovery Response message. | |||
3.10.2. Objective flags | 3.10.2. Objective flags | |||
An objective may be relevant for discovery only, for discovery and | An objective may be relevant for discovery only, for discovery and | |||
negotiation, or for discovery and synchronization. This is expressed | negotiation, or for discovery and synchronization. This is expressed | |||
in the objective by logical flag bits: | in the objective by logical flag bits: | |||
objective-flags = uint .bits objective-flag | objective-flags = uint .bits objective-flag | |||
skipping to change at page 41, line 35 | skipping to change at page 42, line 11 | |||
which vary according to different functions/services. They MUST be | which vary according to different functions/services. They MUST be | |||
carried by Discovery, Request Negotiation or Negotiation messages | carried by Discovery, Request Negotiation or Negotiation messages | |||
only. The negotiation initiator MUST set the initial "loop-count" to | only. The negotiation initiator MUST set the initial "loop-count" to | |||
a value specified in the specification of the objective or, if no | a value specified in the specification of the objective or, if no | |||
such value is specified, to GRASP_DEF_LOOPCT. | such value is specified, to GRASP_DEF_LOOPCT. | |||
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 Negotiation message, or | always be completely presented in a Request Negotiation message, or | |||
in a Discovery message in rapid mode. If there is no initial value, | in a Discovery message in rapid mode. If there is no initial value, | |||
the bits in the value field SHOULD all be set to indicate a | the value field SHOULD be set to the 'null' value defined by CBOR. | |||
meaningless value, unless this is inappropriate for the specific | ||||
negotiation objective. | ||||
Synchronization Objective Options are similar, but MUST be carried by | Synchronization Objective Options are similar, but MUST be carried by | |||
Discovery, Discovery Response, Request Synchronization, or Flood | Discovery, Discovery Response, Request Synchronization, or Flood | |||
Synchronization messages only. They include value fields only in | Synchronization messages only. They include value fields only in | |||
Synchronization or Flood Synchronization messages. | Synchronization or Flood Synchronization messages. | |||
3.10.4. Organizing of Objective Options | 3.10.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 SHOULD be designed to use either the negotiation or | the public and SHOULD be designed to use either the negotiation or | |||
skipping to change at page 42, line 26 | skipping to change at page 42, line 49 | |||
A synchronization objective SHOULD be organized as a single GRASP | A synchronization objective SHOULD be organized as a single GRASP | |||
option. | option. | |||
Some objectives will support more than one operational mode. An | Some objectives will support more than one operational mode. An | |||
example is a negotiation objective with both a "dry run" mode (where | example is a negotiation objective with both a "dry run" mode (where | |||
the negotiation is to find out whether the other end can in fact make | the negotiation is to find out whether the other end can in fact make | |||
the requested change without problems) and a "live" mode. Such modes | the requested change without problems) and a "live" mode. Such modes | |||
will be defined in the specification of such an objective. These | will be defined in the specification of such an objective. These | |||
objectives SHOULD include flags indicating the applicable mode(s). | objectives SHOULD include flags indicating the applicable mode(s). | |||
An objective may have multiple parameters. Parameters can be | An issue requiring particular attention is that GRASP itself is a | |||
categorized into two classes: the obligatory ones presented as fixed | stateless protocol. Any state associated with a dry run operation, | |||
fields; and the optional ones presented in CBOR sub-options or some | such as temporarily reserving a resource for subsequent use in a live | |||
other form of data structure embedded in CBOR. The format might be | run, is entirely a matter for the designer of the ASA concerned. | |||
inherited from an existing management or configuration protocol, the | ||||
objective option acting as a carrier for that format. The data | ||||
structure might be defined in a formal language, but that is a matter | ||||
for the specifications of individual objectives. There are many | ||||
candidates, according to the context, such as ABNF, RBNF, XML Schema, | ||||
possibly YANG, etc. The GRASP protocol itself is agnostic on these | ||||
questions. | ||||
It is NOT RECOMMENDED to split parameters in a single objective into | As indicated in Section 3.1, an objective's value may include | |||
multiple options, unless they have different response periods. An | multiple parameters. Parameters might be categorized into two | |||
exception scenario may also be described by split objectives. | classes: the obligatory ones presented as fixed fields; and the | |||
optional ones presented in some other form of data structure embedded | ||||
in CBOR. The format might be inherited from an existing management | ||||
or configuration protocol, with the objective option acting as a | ||||
carrier for that format. The data structure might be defined in a | ||||
formal language, but that is a matter for the specifications of | ||||
individual objectives. There are many candidates, according to the | ||||
context, such as ABNF, RBNF, XML Schema, YANG, etc. The GRASP | ||||
protocol itself is agnostic on these questions. The only restriction | ||||
is that the format can be mapped into CBOR. | ||||
It is NOT RECOMMENDED to mix parameters that have significantly | ||||
different response time characteristics in a single objective. | ||||
Separate objectives are more suitable for such a scenario. | ||||
All objectives MUST support GRASP discovery. However, as mentioned | All objectives MUST support GRASP discovery. However, as mentioned | |||
in Section 3.3, it is acceptable for an ASA to use an alternative | in Section 3.3, it is acceptable for an ASA to use an alternative | |||
method of discovery. | method of discovery. | |||
Normally, a GRASP objective will refer to specific technical | Normally, a GRASP objective will refer to specific technical | |||
parameters as explained in Section 3.1. However, it is acceptable to | parameters as explained in Section 3.1. However, it is acceptable to | |||
define an abstract objective for the purpose of managing or | define an abstract objective for the purpose of managing or | |||
coordinating ASAs. It is also acceptable to define a special-purpose | coordinating ASAs. It is also acceptable to define a special-purpose | |||
objective for purposes such as trust bootstrapping or formation of | objective for purposes such as trust bootstrapping or formation of | |||
skipping to change at page 44, line 22 | skipping to change at page 45, line 5 | |||
4.2. Python Implementation | 4.2. Python Implementation | |||
o Name: graspy | o Name: graspy | |||
o Description: Python 3 implementation of GRASP core and API. | o Description: Python 3 implementation of GRASP core and API. | |||
o Maturity: Prototype code, interoperable between Windows 7 and | o Maturity: Prototype code, interoperable between Windows 7 and | |||
Linux. | Linux. | |||
o Coverage: Corresponds to draft-ietf-anima-grasp-08. Limitations | o Coverage: Corresponds to draft-ietf-anima-grasp-10. Limitations | |||
include: | include: | |||
* insecure: uses a dummy ACP module and does not implement TLS | * insecure: uses a dummy ACP module and does not implement TLS | |||
* only coded for IPv6, any IPv4 is accidental | * only coded for IPv6, any IPv4 is accidental | |||
* FQDN and URI locators incompletely supported | * FQDN and URI locators incompletely supported | |||
* no code for rapid mode | * no code for rapid mode | |||
skipping to change at page 45, line 7 | skipping to change at page 45, line 35 | |||
socket peculiarities | socket peculiarities | |||
o Licensing: Simplified BSD | o Licensing: Simplified BSD | |||
o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf | o Experience: https://www.cs.auckland.ac.nz/~brian/graspy/graspy.pdf | |||
o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ | o Contact: https://www.cs.auckland.ac.nz/~brian/graspy/ | |||
5. Security Considerations | 5. Security Considerations | |||
It is obvious that a successful attack on negotiation-enabled nodes | A successful attack on negotiation-enabled nodes would be extremely | |||
would be extremely harmful, as such nodes might end up with a | harmful, as such nodes might end up with a completely undesirable | |||
completely undesirable configuration that would also adversely affect | configuration that would also adversely affect their peers. GRASP | |||
their peers. GRASP nodes and messages therefore require full | nodes and messages therefore require full protection. As explained | |||
protection. | in Section 3.5.1, GRASP MUST run within a secure environment such as | |||
the Autonomic Control Plane [I-D.ietf-anima-autonomic-control-plane], | ||||
except for the constrained instances described in Section 3.5.2. | ||||
- Authentication | - Authentication | |||
A cryptographically authenticated identity for each device is | A cryptographically authenticated identity for each device is | |||
needed in an autonomic network. It is not safe to assume that a | needed in an autonomic network. It is not safe to assume that a | |||
large network is physically secured against interference or that | large network is physically secured against interference or that | |||
all personnel are trustworthy. Each autonomic node MUST be | all personnel are trustworthy. Each autonomic node MUST be | |||
capable of proving its identity and authenticating its messages. | capable of proving its identity and authenticating its messages. | |||
GRASP relies on a separate external certificate-based security | GRASP relies on a separate external certificate-based security | |||
mechanism to support authentication, data integrity protection, | mechanism to support authentication, data integrity protection, | |||
and anti-replay protection. | and anti-replay protection. | |||
Since GRASP is intended to be deployed in a single administrative | Since GRASP must be deployed in an existing secure environment, | |||
domain operating its own trust anchor and CA, there is no need for | the protocol itself specifies nothing concerning the trust anchor | |||
a trusted public third party. In a network requiring "air gap" | and certification authority. | |||
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.5.1), | mechanism, for example during system bootstrap (Section 3.5.1), | |||
the Session ID (Section 3.7) will act as a nonce to provide | the Session ID (Section 3.7) 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 in | |||
the present document. | [I-D.ietf-anima-bootstrapping-keyinfra]. | |||
- Authorization and Roles | - Authorization and Roles | |||
The GRASP protocol is agnostic about the role of individual ASAs | The GRASP protocol is agnostic about the roles and capabilities of | |||
and about which objectives a particular ASA is authorized to | individual ASAs and about which objectives a particular ASA is | |||
support. An implementation might support precautions such as | authorized to support. An implementation might support | |||
allowing only one ASA in a given node to modify a given objective, | precautions such as allowing only one ASA in a given node to | |||
but this may not be appropriate in all cases. For example, it | modify a given objective, but this may not be appropriate in all | |||
might be operationally useful to allow an old and a new version of | cases. For example, it might be operationally useful to allow an | |||
the same ASA to run simultaneously during an overlap period. | old and a new version of the same ASA to run simultaneously during | |||
These questions are out of scope for the present specification. | an overlap period. These questions are out of scope for the | |||
present specification. | ||||
- 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 | |||
skipping to change at page 46, line 23 | skipping to change at page 47, line 5 | |||
GRASP has no reasonable alternative to using link-local multicast | GRASP has no reasonable alternative to using link-local multicast | |||
for Discovery or Flood Synchronization messages and these messages | for Discovery or Flood Synchronization messages and these messages | |||
are sent in clear and with no authentication. They are therefore | are sent in clear and with no authentication. They are therefore | |||
available to on-link eavesdroppers, and could be forged by on-link | available to on-link eavesdroppers, and could be forged by on-link | |||
attackers. In the case of Discovery, the Discovery Responses are | attackers. In the case of Discovery, the Discovery Responses are | |||
unicast and will therefore be protected (Section 3.5.1), and an | unicast and will therefore be protected (Section 3.5.1), and an | |||
untrusted forger will not be able to receive responses. In the | untrusted forger will not be able to receive responses. In the | |||
case of Flood Synchronization, an on-link eavesdropper will be | case of Flood Synchronization, an on-link eavesdropper will be | |||
able to receive the flooded objectives but there is no response | able to receive the flooded objectives but there is no response | |||
message to consider. Some precautions for Flood Synchronization | message to consider. Some precautions for Flood Synchronization | |||
messages are suggested in Section 3.5.6.1. | messages are suggested in Section 3.5.6.2. | |||
- DoS Attack Protection | - DoS Attack Protection | |||
GRASP discovery partly relies on insecure link-local multicast. | GRASP discovery partly relies on insecure link-local multicast. | |||
Since routers participating in GRASP sometimes relay discovery | Since routers participating in GRASP sometimes relay discovery | |||
messages from one link to another, this could be a vector for | messages from one link to another, this could be a vector for | |||
denial of service attacks. Some mitigations are specified in | denial of service attacks. Some mitigations are specified in | |||
Section 3.5.4. However, malicious code installed inside the | Section 3.5.4. However, malicious code installed inside the | |||
Autonomic Control Plane could always launch DoS attacks consisting | Autonomic Control Plane could always launch DoS attacks consisting | |||
of spurious discovery messages, or of spurious discovery | of spurious discovery messages, or of spurious discovery | |||
responses. Additionally, it is of great importance that firewalls | responses. It is important that firewalls prevent any GRASP | |||
prevent any GRASP messages from entering the domain from an | messages from entering the domain from an unknown source. | |||
untrusted source. | ||||
- Security during bootstrap and discovery | - Security during bootstrap and discovery | |||
A node cannot authenticate GRASP traffic from other nodes until it | A node cannot trust GRASP traffic from other nodes until the | |||
has identified the trust anchor and can validate certificates for | security environment (such as the ACP) has identified the trust | |||
anchor and can authenticate traffic by validating certificates for | ||||
other nodes. Also, until it has succesfully enrolled | other nodes. Also, until it has succesfully enrolled | |||
[I-D.ietf-anima-bootstrapping-keyinfra] it cannot assume that | [I-D.ietf-anima-bootstrapping-keyinfra] a node 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. Secure synchronization and negotiation | |||
will be impossible until enrollment is complete. Further details | will be impossible until enrollment is complete. Further details | |||
are given in Section 3.5.2. | are given in Section 3.5.2. | |||
- Security of discovered locators | - Security of discovered locators | |||
When GRASP discovery returns an IP address, it MUST be that of a | When GRASP discovery returns an IP address, it MUST be that of a | |||
node within the secure environment (Section 3.5.1). If it returns | node within the secure environment (Section 3.5.1). If it returns | |||
an FQDN or a URI, the ASA that receives it MUST NOT assume that | an FQDN or a URI, the ASA that receives it MUST NOT assume that | |||
the target of the locator is within the secure environment. | the target of the locator is within the secure environment. | |||
6. CDDL Specification of GRASP | 6. CDDL Specification of GRASP | |||
<CODE BEGINS> | <CODE BEGINS> | |||
grasp-message = (message .within message-structure) / noop-message | grasp-message = (message .within message-structure) / noop-message | |||
skipping to change at page 49, line 27 | skipping to change at page 50, line 10 | |||
O_ACCEPT = 101 | O_ACCEPT = 101 | |||
O_DECLINE = 102 | O_DECLINE = 102 | |||
O_IPv6_LOCATOR = 103 | O_IPv6_LOCATOR = 103 | |||
O_IPv4_LOCATOR = 104 | O_IPv4_LOCATOR = 104 | |||
O_FQDN_LOCATOR = 105 | O_FQDN_LOCATOR = 105 | |||
O_URI_LOCATOR = 106 | O_URI_LOCATOR = 106 | |||
<CODE ENDS> | <CODE ENDS> | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document defines the Generic Autonomic Signaling Protocol | This document defines the GeneRic Autonomic Signaling Protocol | |||
(GRASP). | (GRASP). | |||
Section 3.6 explains the following link-local multicast addresses, | Section 3.6 explains the following link-local multicast addresses, | |||
which IANA is requested to assign for use by GRASP: | which IANA is requested to assign for use by GRASP: | |||
ALL_GRASP_NEIGHBOR multicast address (IPv6): (TBD1). Assigned in | ALL_GRASP_NEIGHBORS 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_NEIGHBORS multicast address (IPv4): (TBD2). Assigned in | |||
the IPv4 Multicast Local Network Control Block. | the IPv4 Multicast Local Network Control Block. | |||
Section 3.6 explains the following User Port, which IANA is requested | Section 3.6 explains the following User Port, which IANA is requested | |||
to assign for use by GRASP for both UDP and TCP: | to assign for use by GRASP for both UDP and TCP: | |||
GRASP_LISTEN_PORT: (TBD3) | GRASP_LISTEN_PORT: (TBD3) | |||
Service Name: Generic Autonomic Signaling Protocol (GRASP) | Service Name: Generic Autonomic Signaling Protocol (GRASP) | |||
Transport Protocols: UDP, TCP | Transport Protocols: UDP, TCP | |||
Assignee: iesg@ietf.org | Assignee: iesg@ietf.org | |||
Contact: chair@ietf.org | Contact: chair@ietf.org | |||
skipping to change at page 51, line 9 | skipping to change at page 51, line 45 | |||
EX5 | EX5 | |||
EX6 | EX6 | |||
EX7 | EX7 | |||
EX8 | EX8 | |||
EX9 | EX9 | |||
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. Significant review inputs were received from | made by Sheng Jiang. Significant review inputs were received from | |||
Joel Halpern, Toerless Eckert and Michael Richardson. | Joel Halpern, Toerless Eckert, Charles E. Perkins, and Michael | |||
Richardson. | ||||
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, Zhenbin Li, | |||
Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, | Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, | |||
Rene Struik, Dacheng Zhang, and other participants in the NMRG | Rene Struik, Dacheng Zhang, and other participants in the NMRG | |||
research group and the ANIMA working group. | research group and the ANIMA working group. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
skipping to change at page 52, line 30 | skipping to change at page 53, line 22 | |||
[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.ietf-anima-autonomic-control-plane] | [I-D.ietf-anima-autonomic-control-plane] | |||
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic | Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic | |||
Control Plane", draft-ietf-anima-autonomic-control- | Control Plane", draft-ietf-anima-autonomic-control- | |||
plane-04 (work in progress), October 2016. | plane-05 (work in progress), January 2017. | |||
[I-D.ietf-anima-bootstrapping-keyinfra] | [I-D.ietf-anima-bootstrapping-keyinfra] | |||
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, | Pritikin, M., Richardson, M., Behringer, M., Bjarnason, | |||
S., and K. Watsen, "Bootstrapping Remote Secure Key | S., and K. Watsen, "Bootstrapping Remote Secure Key | |||
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- | Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- | |||
keyinfra-04 (work in progress), October 2016. | keyinfra-04 (work in progress), October 2016. | |||
[I-D.ietf-anima-reference-model] | [I-D.ietf-anima-reference-model] | |||
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., | Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., | |||
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A | Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A | |||
Reference Model for Autonomic Networking", draft-ietf- | Reference Model for Autonomic Networking", draft-ietf- | |||
anima-reference-model-02 (work in progress), July 2016. | anima-reference-model-02 (work in progress), July 2016. | |||
[I-D.ietf-anima-stable-connectivity] | [I-D.ietf-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-ietf- | Plane for Stable Connectivity of Network OAM", draft-ietf- | |||
anima-stable-connectivity-01 (work in progress), July | anima-stable-connectivity-02 (work in progress), February | |||
2016. | 2017. | |||
[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-18 (work in | Protocol", draft-ietf-netconf-restconf-18 (work in | |||
progress), October 2016. | progress), October 2016. | |||
[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.liu-anima-grasp-api] | [I-D.liu-anima-grasp-api] | |||
Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic | Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic | |||
Autonomic Signaling Protocol Application Program Interface | Autonomic Signaling Protocol Application Program Interface | |||
(GRASP API)", draft-liu-anima-grasp-api-02 (work in | (GRASP API)", draft-liu-anima-grasp-api-03 (work in | |||
progress), September 2016. | progress), February 2017. | |||
[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 | |||
progress), March 2015. | progress), March 2015. | |||
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. | |||
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 | |||
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | Functional Specification", RFC 2205, DOI 10.17487/RFC2205, | |||
September 1997, <http://www.rfc-editor.org/info/rfc2205>. | September 1997, <http://www.rfc-editor.org/info/rfc2205>. | |||
skipping to change at page 59, line 43 | skipping to change at page 60, line 30 | |||
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? | |||
RESOLVED: Decided not to consider this further as a GRASP protocol | RESOLVED: Decided not to consider this further as a GRASP protocol | |||
issue. GRASP objectives could embed DNS-SD formats if needed. | issue. GRASP objectives could embed DNS-SD formats if needed. | |||
o 26. Add a URL type to the locator options (for security bootstrap | o 26. Add a URL type to the locator options (for security bootstrap | |||
etc.) | etc.) | |||
RESOLVED: Done, later renamed as URI. | RESOLVED: Done, later renamed as URI. | |||
o 27. Security of Flood multicasts (Section 3.5.6.1). | o 27. Security of Flood multicasts (Section 3.5.6.2). | |||
RESOLVED: added text. | RESOLVED: added text. | |||
o 28. Does ACP support secure link-local multicast? | o 28. Does ACP support secure link-local multicast? | |||
RESOLVED by new text in the Security Considerations. | RESOLVED by new text in the Security Considerations. | |||
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. | |||
skipping to change at page 63, line 43 | skipping to change at page 64, line 30 | |||
RESOLVED: Retained but only as an option. | RESOLVED: Retained but only as an option. | |||
o 62. Is it helpful to tag descriptive text with message names | o 62. Is it helpful to tag descriptive text with message names | |||
(M_DISCOVER etc.)? | (M_DISCOVER etc.)? | |||
RESOLVED: Yes, done in various parts of the text. | RESOLVED: Yes, done in various parts of the text. | |||
Appendix C. Change log [RFC Editor: Please remove] | Appendix C. Change log [RFC Editor: Please remove] | |||
draft-ietf-anima-grasp-10, 2017-03-XX: | ||||
Updates following IETF Last call: | ||||
Protocol change: Specify that an objective with no initial value | ||||
should have its value field set to CBOR 'null'. | ||||
Protocol change: Specify behavior on receiving unrecognized message | ||||
type. | ||||
Editorial improvements and clarifications. | ||||
draft-ietf-anima-grasp-09, 2016-12-15: | draft-ietf-anima-grasp-09, 2016-12-15: | |||
Protocol change: Add F_NEG_DRY flag to specify a "dry run" objective. | Protocol change: Add F_NEG_DRY flag to specify a "dry run" objective. | |||
Protocol change: Change M_FLOOD syntax to associate a locator with | Protocol change: Change M_FLOOD syntax to associate a locator with | |||
each objective. | each objective. | |||
Concentrated mentions of TLS in one section, with all details out of | Concentrated mentions of TLS in one section, with all details out of | |||
scope. | scope. | |||
End of changes. 152 change blocks. | ||||
415 lines changed or deleted | 462 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |