draft-ietf-anima-grasp-11.txt   draft-ietf-anima-grasp-12.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: October 1, 2017 Univ. of Auckland Expires: November 20, 2017 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
March 30, 2017 May 19, 2017
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-11 draft-ietf-anima-grasp-12
Abstract Abstract
This document establishes requirements for a signaling protocol that This document establishes requirements for a signaling protocol that
enables autonomic nodes and autonomic service agents to dynamically enables autonomic nodes 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 with them. The document then defines a general parameter settings with them. The document then defines a general
protocol for discovery, synchronization and negotiation, while the protocol for discovery, synchronization and negotiation, while the
technical objectives for specific scenarios are to be described in technical objectives for specific scenarios are to be described in
separate documents. An Appendix briefly discusses existing protocols separate documents. An Appendix briefly discusses existing protocols
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 1, 2017. This Internet-Draft will expire on November 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . 17
3.5.1. Required External Security Mechanism . . . . . . . . 16 3.5.1. Required External Security Mechanism . . . . . . . . 17
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 Procedures . . . . . . . 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) . . . . . . . . . . . . . 28 3.7. Session Identifier (Session ID) . . . . . . . . . . . . . 28
3.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 29 3.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 29
3.8.1. Message Overview . . . . . . . . . . . . . . . . . . 29 3.8.1. Message Overview . . . . . . . . . . . . . . . . . . 29
3.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 29 3.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 29
3.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . . . . . . . . 34
3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 34 3.8.8. Negotiation End Message . . . . . . . . . . . . . . . 34
3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 34 3.8.9. Confirm Waiting Message . . . . . . . . . . . . . 34
3.8.10. Synchronization Message . . . . . . . . . . . . . . . 34 3.8.10. Synchronization Message . . . . . . . . . . . . . . . 35
3.8.11. Flood Synchronization Message . . . . . . . . . . . . 35 3.8.11. Flood Synchronization Message . . . . . . . . . . . . 35
3.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 36 3.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 36
3.8.13. No Operation Message . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . 37
3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 37 3.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 37
3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 37 3.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 37
3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37 3.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 37
3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 38 3.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 38
3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 40 3.10. Objective Options . . . . . . . . . . . . . . . . . . . . 40
3.10.1. Format of Objective Options . . . . . . . . . . . . 40 3.10.1. Format of Objective Options . . . . . . . . . . . . 40
3.10.2. Objective flags . . . . . . . . . . . . . . . . . . 41 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 . . . . . . . . . . 42 3.10.4. Organizing of Objective Options . . . . . . . . . . 42
3.10.5. Experimental and Example Objective Options . . . . . 44 3.10.5. Experimental and Example Objective Options . . . . . 44
4. Implementation Status [RFC Editor: please remove] . . . . . . 44 4. Implementation Status [RFC Editor: please remove] . . . . . . 44
4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 44 4.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 44
4.2. Python Implementation . . . . . . . . . . . . . . . . . . 45 4.2. Python Implementation . . . . . . . . . . . . . . . . . . 45
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . 46
6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 48 6. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.1. Normative References . . . . . . . . . . . . . . . . . . 52 9.1. Normative References . . . . . . . . . . . . . . . . . . 52
9.2. Informative References . . . . . . . . . . . . . . . . . 53 9.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Open Issues [RFC Editor: This section should be Appendix A. Open Issues [RFC Editor: This section should be
empty. Please remove] . . . . . . . . . . . . . . . 56 empty. Please remove] . . . . . . . . . . . . . . . 57
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 56 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 57
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 65 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 65
Appendix D. Example Message Formats . . . . . . . . . . . . . . 71 Appendix D. Example Message Formats . . . . . . . . . . . . . . 72
D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 72 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 72
D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 72 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 73
D.3. Synchronization Example . . . . . . . . . . . . . . . . . 72 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 73
D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 73 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 73
D.5. Complete Negotiation Example . . . . . . . . . . . . . . 73 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 74
Appendix E. Capability Analysis of Current Protocols . . . . . . 74 Appendix E. Capability Analysis of Current Protocols . . . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77
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
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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 distinguishing multiple
operations with one or more peers, especially when wait states occur. simultaneous operations with one or more peers, especially when wait
states occur.
T7. Intent: Although the distribution of Intent is out of scope for T7. Intent: Although the distribution of Intent is out of scope for
this document, the protocol must not by design exclude its use for this document, the protocol must not by design exclude its use for
Intent distribution. Intent distribution.
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
skipping to change at page 12, line 16 skipping to change at page 12, line 16
request message referring to a specific negotiation objective. request message referring to a specific 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 o GRASP Instance: This refers to an instantiation of a GRASP
protocol engine, likely including multiple threads or processes as protocol engine, likely including multiple threads or processes as
well as dynamic data structures such as a discovery cache, running well as dynamic data structures such as a discovery cache, running
in a given security environment on a single device. in a given security environment on a single device.
o Network Interface: Unless otherwise stated, this refers to a o Interface or GRASP Interface: Unless otherwise stated, these refer
network interface - which might be physical or virtual - that a to a network interface - which might be physical or virtual - that
specific instance of GRASP is currently using. A device might a specific instance of GRASP is currently using. A device might
have other interfaces that are not used by GRASP. have other interfaces that are not used by GRASP and which are
outside the scope of the autonomic network.
3.2. High Level Deployment Model 3.2. High Level Deployment Model
A GRASP implementation will be part of the Autonomic Networking A GRASP implementation will be part of the Autonomic Networking
Infrastructure in an autonomic node, which must also provide an Infrastructure in an autonomic node, which must also provide an
appropriate security environment. In accordance with appropriate security environment. In accordance with
[I-D.ietf-anima-reference-model], this SHOULD be the Autonomic [I-D.ietf-anima-reference-model], this SHOULD be the Autonomic
Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. It is Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. It is
expected that GRASP will access the ACP by using a typical socket expected that GRASP will access the ACP by using a typical socket
programming interface. There will also be one or more Autonomic programming interface and the ACP will make available only network
Service Agents (ASAs). In the minimal case of a single-purpose interfaces within the autonomic network. If there is no ACP, the
device, these components might be fully integrated. A more common considerations described in Section 3.5.1 apply.
model is expected to be a multi-purpose device capable of containing
several ASAs. In this case it is expected that the ACP, GRASP and There will also be one or more Autonomic Service Agents (ASAs). In
the ASAs will be implemented as separate processes, which are the minimal case of a single-purpose device, these components might
probably multi-threaded to support asynchronous and simultaneous be fully integrated with GRASP and the ACP. A more common model is
operations. expected to be a multi-purpose device capable of containing several
ASAs. In this case it is expected that the ACP, GRASP and the ASAs
will be implemented as separate processes, which are probably multi-
threaded to support asynchronous and simultaneous operations.
In some scenarios, a limited negotiation model might be deployed In some scenarios, a limited negotiation model might be deployed
based on a limited trust relationship such as that between two based on a limited trust relationship such as that between two
administrative domains. ASAs might then exchange limited information administrative domains. ASAs might then exchange limited information
and negotiate some particular configurations. and negotiate some particular configurations.
GRASP is explicitly designed to operate within a single addressing
realm. Its discovery and flooding mechanisms do not support
autonomic operations that cross any form of address translator or
upper layer proxy.
A suitable Application Programming Interface (API) will be needed A suitable Application Programming Interface (API) will be needed
between GRASP and the ASAs. In some implementations, ASAs would run between GRASP and the ASAs. In some implementations, ASAs would run
in user space with a GRASP library providing the API, and this in user space with a GRASP library providing the API, and this
library would in turn communicate via system calls with core GRASP library would in turn communicate via system calls with core GRASP
functions. Details of the API are out of scope for the present functions. Details of the API are out of scope for the present
document. For further details of possible deployment models, see document. For further details of possible deployment models, see
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
An instance of GRASP must be aware of the network interfaces it will An instance of GRASP must be aware of the network interfaces it will
use, and of the appropriate global-scope and link-local addresses. use, and of the appropriate global-scope and link-local addresses.
skipping to change at page 13, line 4 skipping to change at page 13, line 15
A suitable Application Programming Interface (API) will be needed A suitable Application Programming Interface (API) will be needed
between GRASP and the ASAs. In some implementations, ASAs would run between GRASP and the ASAs. In some implementations, ASAs would run
in user space with a GRASP library providing the API, and this in user space with a GRASP library providing the API, and this
library would in turn communicate via system calls with core GRASP library would in turn communicate via system calls with core GRASP
functions. Details of the API are out of scope for the present functions. Details of the API are out of scope for the present
document. For further details of possible deployment models, see document. For further details of possible deployment models, see
[I-D.ietf-anima-reference-model]. [I-D.ietf-anima-reference-model].
An instance of GRASP must be aware of the network interfaces it will An instance of GRASP must be aware of the network interfaces it will
use, and of the appropriate global-scope and link-local addresses. use, and of the appropriate global-scope and link-local addresses.
In the presence of the ACP, such information will be available from In the presence of the ACP, such information will be available from
the adjacency table discussed in [I-D.ietf-anima-reference-model]. the adjacency table discussed in [I-D.ietf-anima-reference-model].
In other cases, GRASP must determine such information for itself. In other cases, GRASP must determine such information for itself.
Details depend on the device and operating system. In the rest of Details depend on the device and operating system. In the rest of
this document, the term 'interfaces' refers only to the set of this document, the terms 'interfaces' or 'GRASP interfaces' refers
network interfaces that a specific instance of GRASP is currently only to the set of network interfaces that a specific instance of
using. GRASP is currently using.
Because GRASP needs to work with very high reliability, especially Because GRASP needs to work with very high reliability, especially
during bootstrapping and during fault conditions, it is essential during bootstrapping and during fault conditions, it is essential
that every implementation is as robust as possible. For example, that every implementation is as robust as possible. For example,
discovery failures, or any kind of socket exception at any time, must discovery failures, or any kind of socket exception at any time, must
not cause irrecoverable failures in GRASP itself, and must return not cause irrecoverable failures in GRASP itself, and must return
suitable error codes through the API so that ASAs can also recover. suitable error codes through the API so that ASAs can also recover.
GRASP must not depend upon non-volatile data storage. All run time GRASP must not depend upon non-volatile data storage. All run time
error conditions, and events such as address renumbering, network error conditions, and events such as address renumbering, network
skipping to change at page 19, line 39 skipping to change at page 19, line 51
Further details are out of scope for this document. Further details are out of scope for 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. NOT exceed the link MTU size.
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 but the details are
itself does not provide for error detection or retransmission. Use out of scope for this specification. However, GRASP itself does not
of an unreliable transport protocol is therefore NOT RECOMMENDED. provide for error detection or retransmission. Use of an unreliable
transport protocol is therefore NOT RECOMMENDED.
Nevertheless, when running within a secure ACP on reliable
infrastructure, UDP MAY be used for unicast messages not exceeding
the minimum IPv6 path MTU; however, TCP MUST be used for longer
messages. In other words, IPv6 fragmentation is avoided. If a node
receives a UDP message but the reply is too long, it MUST open a TCP
connection to the peer for the reply. Note that when the network is
under heavy load or in a fault condition, UDP might become
unreliable. Since this is when autonomic functions are most
necessary, automatic fallback to TCP MUST be implemented. The
simplest implementation is therefore to use only TCP.
For considerations when running without an ACP, see Section 3.5.2.1. For considerations when running without an ACP, see Section 3.5.2.1.
For link-local multicast, the GRASP protocol listens to the well- For link-local multicast, the GRASP protocol listens to the well-
known GRASP Listen Port (Section 3.6). For unicast transport known GRASP Listen Port (Section 3.6). For unicast transport
sessions used for discovery responses, synchronization and sessions used for discovery responses, synchronization and
negotiation, the ASA concerned normally listens on its own negotiation, the ASA concerned normally listens on its own
dynamically assigned ports, which are communicated to its peers dynamically assigned ports, which are communicated to its peers
during discovery. However, a minimal implementation MAY use the during discovery. However, a minimal implementation MAY use the
GRASP Listen Port for this purpose. GRASP Listen Port for this purpose.
skipping to change at page 21, line 15 skipping to change at page 21, line 15
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, because the peer in question will answer directly the same interface, because the peer in question will answer directly
if still operational. If it has no cached response, it will relay if still operational. If it has no cached response, it will relay
the discovery on its other interfaces, for example reaching a higher- the discovery on its other GRASP interfaces, for example reaching a
level gateway in a hierarchical network. If a node receiving the higher-level gateway in a hierarchical network. If a node receiving
relayed discovery supports the discovery objective, it will respond the relayed discovery supports the discovery objective, it will
to the relayed discovery. If it has a cached response, it will respond to the relayed discovery. If it has a cached response, it
respond with that. If not, it will repeat the discovery process, will respond with that. If not, it will repeat the discovery
which thereby becomes iterative. The loop count and timeout will process, which thereby becomes iterative. The loop count and timeout
ensure that the process ends. will ensure that the process ends.
A Discovery message MAY be sent unicast (via UDP or TCP) to a peer A Discovery message MAY be sent unicast (via UDP or TCP) to a peer
node, which SHOULD then proceed exactly as if the message had been node, which SHOULD then proceed exactly as if the message had been
multicast, except that when TCP is used, the response will be on the multicast, except that when TCP is used, the response will be on the
same socket as the query. However, this mode does not guarantee same socket as the query. However, this mode 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
skipping to change at page 22, line 48 skipping to change at page 22, line 48
Because Discovery Responders will be cached in a finite cache, they Because Discovery Responders will be cached in a finite cache, they
might be deleted at any time. In this case, discovery will need to might be deleted at any time. In this case, discovery will need to
be repeated. If an ASA exits for any reason, its locator might still be 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 GRASP interfaces.
refer to this as a 'relaying instance'. We refer to this as a 'relaying instance'.
Constrained Instances (Section 3.5.2) are always single-interface Constrained Instances (Section 3.5.2) are always single-interface
instances and therefore MUST NOT perform discovery relaying. instances and therefore 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 new 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 GRASP 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, which are sent to the and is never used to address Response packets, which are sent to the
relaying instance, not the original initiator. 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
skipping to change at page 24, line 6 skipping to change at page 24, line 6
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 (using M_REQ_NEG) A negotiation initiator sends a negotiation request (using M_REQ_NEG)
to a counterpart ASA, including a specific negotiation objective. It to a counterpart ASA, including a specific negotiation objective. It
may request the negotiation counterpart to make a specific may request the negotiation counterpart to make a specific
configuration. Alternatively, it may request a certain simulation or configuration. Alternatively, it may request a certain simulation or
forecast result by sending a dry run configuration. The details, forecast result by sending a dry run configuration. The details,
including the distinction between dry run and an actual configuration including the distinction between a dry run and a live configuration
change, will be defined separately for each type of negotiation change, will be defined separately for each type of negotiation
objective. objective. Any state associated with a dry run operation, such as
temporarily reserving a resource for subsequent use in a live run, is
entirely a matter for the designer of the ASA concerned.
If no reply message of any kind is received within a reasonable Each negotiation session as a whole is subject to a timeout (default
timeout (default GRASP_DEF_TIMEOUT milliseconds, Section 3.6), the GRASP_DEF_TIMEOUT milliseconds, Section 3.6), initialised when the
negotiation request MAY be repeated, with a newly generated Session request is sent (see Section 3.8.6). If no reply message of any kind
ID (Section 3.7). An exponential backoff SHOULD be used for is received within a reasonable timeout, the negotiation request MAY
subsequent repetitions. be repeated, with a newly generated Session ID (Section 3.7). An
exponential backoff SHOULD be used for 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
negotiate (using M_NEGOTIATE). It will reply with a proposed negotiate (using M_NEGOTIATE). It will reply with a proposed
alternative configuration that it can apply (typically, a alternative configuration that it can apply (typically, a
configuration that uses fewer resources than requested by the configuration that uses fewer resources than requested by the
negotiation initiator). This will start a bi-directional negotiation negotiation initiator). This will start a bi-directional negotiation
(using M_NEGOTIATE) to reach a compromise between the two ASAs. (using M_NEGOTIATE) to reach a compromise between the two ASAs.
skipping to change at page 26, line 15 skipping to change at page 26, line 20
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].
A GRASP device with multiple link-layer interfaces (typically a A GRASP device with multiple link-layer interfaces (typically a
router) MUST support synchronization flooding on all interfaces. If router) MUST support synchronization flooding on all GRASP
it receives a multicast Flood Synchronization message on a given interfaces. If it receives a multicast Flood Synchronization message
interface, it MUST relay it by re-issuing a Flood Synchronization on a given interface, it MUST relay it by re-issuing a Flood
message on its other interfaces. The relayed message MUST have the Synchronization message as a link-local multicast on its other GRASP
same Session ID as the incoming message and MUST be tagged with the interfaces. The relayed message MUST have the same Session ID as the
IP address of its original initiator. incoming message and MUST be tagged with the IP address of its
original initiator.
Link-layer Flooding is supported by GRASP by setting the loop count Link-layer Flooding is supported by GRASP by setting the loop count
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
skipping to change at page 32, line 49 skipping to change at page 33, line 10
3.8.6. Request Messages 3.8.6. Request Messages
In fragmentary CDDL, Request Negotiation and Request Synchronization In fragmentary CDDL, Request Negotiation and Request Synchronization
messages follow the patterns: messages follow the patterns:
request-negotiation-message = [M_REQ_NEG, session-id, objective] request-negotiation-message = [M_REQ_NEG, session-id, objective]
request-synchronization-message = [M_REQ_SYN, session-id, objective] request-synchronization-message = [M_REQ_SYN, session-id, objective]
A negotiation or synchronization requesting node sends the A negotiation or synchronization requesting node sends the
appropriate Request message to the unicast address (directly stored appropriate Request message to the unicast address of the negotiation
or resolved from an FQDN or URI) of the negotiation or or synchronization counterpart, using the appropriate protocol and
synchronization counterpart, using the appropriate protocol and port port numbers (selected from the discovery result). If the discovery
numbers (selected from the discovery results). result is an FQDN, it will be resolved first.
A Request message MUST include the relevant objective option. In the A Request message MUST include the relevant objective option. In the
case of Request Negotiation, the objective option MUST include the case of Request Negotiation, the objective option MUST include the
requested value. requested value.
When an initiator sends a Request Negotiation message, it MUST When an initiator sends a Request Negotiation message, it MUST
initialize a negotiation timer for the new negotiation thread. The initialize a negotiation timer for the new negotiation thread. The
default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is default is GRASP_DEF_TIMEOUT milliseconds. Unless this timeout is
modified by a Confirm Waiting message (Section 3.8.9), the initiator modified by a Confirm Waiting message (Section 3.8.9), the initiator
will consider that the negotiation has failed when the timer expires. will consider that the negotiation has failed when the timer expires.
skipping to change at page 38, line 24 skipping to change at page 38, line 35
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
protocol and port number for reaching the target. For this reason, protocol and port number for reaching the target. For this reason,
the Locator Options for IP addresses and FQDNs include this the Locator Options for IP addresses and FQDNs include this
information explicitly. In the case of the URI Option, this information explicitly. In the case of the URI Option, this
information can be encoded in the URI itself. information can be encoded in the URI itself.
Note: It is assumed that all locators are in scope throughout the Note: It is assumed that all locators are in scope throughout the
GRASP domain. GRASP is not intended to work across disjoint GRASP domain. As stated in Section 3.2, GRASP is not intended to
addressing or naming realms. work across disjoint addressing or naming realms.
3.9.5.1. Locator IPv6 address option 3.9.5.1. Locator IPv6 address option
In fragmentary CDDL, the IPv6 address option follows the pattern: In fragmentary CDDL, the IPv6 address option follows the pattern:
ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address, ipv6-locator-option = [O_IPv6_LOCATOR, ipv6-address,
transport-proto, port-number] transport-proto, port-number]
ipv6-address = bytes .size 16 ipv6-address = bytes .size 16
transport-proto = IPPROTO_TCP / IPPROTO_UDP transport-proto = IPPROTO_TCP / IPPROTO_UDP
skipping to change at page 39, line 52 skipping to change at page 40, line 14
The content of this option is the Uniform Resource Identifier of the The content of this option is the Uniform Resource Identifier of the
target [RFC3986]. target [RFC3986].
Note 1: Any URI which might not be valid throughout the network in Note 1: Any URI which might not be valid throughout the network in
question, such as one based on a Multicast DNS name [RFC6762], MUST question, such as one based on a Multicast DNS name [RFC6762], MUST
NOT be used when this option is used within the Divert option. NOT be used when this option is used within the Divert option.
Note 2: Normal GRASP operations are not expected to use this option. Note 2: Normal GRASP operations are not expected to use this option.
It is intended for special purposes such as discovering external It is intended for special purposes such as discovering external
services. services. Therefore its use is not further described in this
specification.
3.10. Objective Options 3.10. Objective Options
3.10.1. Format of Objective Options 3.10.1. Format of Objective Options
An objective option is used to identify objectives for the purposes An objective option is used to identify objectives for the purposes
of discovery, negotiation or synchronization. All objectives MUST be of discovery, negotiation or synchronization. All objectives MUST be
in the following format, described in fragmentary CDDL: in the following format, described in fragmentary CDDL:
objective = [objective-name, objective-flags, loop-count, ?any] objective = [objective-name, objective-flags, loop-count, ?any]
skipping to change at page 47, line 4 skipping to change at page 47, line 14
impact on personal privacy. Nevertheless, traffic flow paths, impact on personal privacy. Nevertheless, traffic flow paths,
VPNs, etc. could be negotiated, which could be of interest for VPNs, etc. could be negotiated, which could be of interest for
traffic analysis. Also, operators generally want to conceal traffic analysis. Also, operators generally want to conceal
details of their network topology and traffic density from details of their network topology and traffic density from
outsiders. Therefore, since insider attacks cannot be excluded in outsiders. Therefore, since insider attacks cannot be excluded in
a large network, the security mechanism for the protocol MUST a large network, the security mechanism for the protocol MUST
provide message confidentiality. This is why Section 3.5.1 provide message confidentiality. This is why Section 3.5.1
requires either an ACP or an alternative security mechanism. requires either an ACP or an alternative security mechanism.
- Link-local multicast security - Link-local multicast security
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 only sent
available to on-link eavesdroppers, and could be forged by on-link on interfaces within the autonomic network (see Section 3.1 and
attackers. In the case of Discovery, the Discovery Responses are Section 3.5.1). They are however available to on-link
unicast and will therefore be protected (Section 3.5.1), and an eavesdroppers, and could be forged by on-link attackers. In the
untrusted forger will not be able to receive responses. In the case of Discovery, the Discovery Responses are unicast and will
case of Flood Synchronization, an on-link eavesdropper will be therefore be protected (Section 3.5.1), and an untrusted forger
able to receive the flooded objectives but there is no response will not be able to receive responses. In the case of Flood
message to consider. Some precautions for Flood Synchronization Synchronization, an on-link eavesdropper will be able to receive
messages are suggested in Section 3.5.6.2. the flooded objectives but there is no response message to
consider. Some precautions for Flood Synchronization 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
skipping to change at page 52, line 13 skipping to change at page 52, line 24
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
Toerless Eckert, Joel Halpern, Barry Leiba, Charles E. Perkins, and Toerless Eckert, Joel Halpern, Barry Leiba, Charles E. Perkins, and
Michael Richardson. 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, Joel Jaeggli,
Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Markus Stenberg, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman,
Rene Struik, Dacheng Zhang, and other participants in the NMRG Markus Stenberg, Rene Struik, Martin Thomson, Dacheng Zhang, and
research group and the ANIMA working group. other participants in the NMRG research group and the ANIMA working
group.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "CBOR data Birkholz, H., Vigano, C., and C. Bormann, "CBOR data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-greevenbosch-appsawg- express CBOR data structures", draft-greevenbosch-appsawg-
cbor-cddl-10 (work in progress), March 2017. cbor-cddl-10 (work in progress), March 2017.
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control-
plane-06 (work in progress), March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 53, line 27 skipping to change at page 53, line 48
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
9.2. Informative References 9.2. Informative References
[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]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control-
plane-06 (work in progress), March 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-05 (work in progress), March 2017. keyinfra-05 (work in progress), March 2017.
[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-
skipping to change at page 65, line 26 skipping to change at page 65, line 41
RESOLVED: No, on AD advice. RESOLVED: No, on AD advice.
o 67. Remove normative dependency on draft-greevenbosch-appsawg- o 67. Remove normative dependency on draft-greevenbosch-appsawg-
cbor-cddl? cbor-cddl?
RESOLVED: No, on AD advice. In worst case, fix at AUTH48. RESOLVED: No, on AD advice. In worst case, fix at AUTH48.
Appendix C. Change log [RFC Editor: Please remove] Appendix C. Change log [RFC Editor: Please remove]
draft-ietf-anima-grasp-12, 2017-05-19:
Updates following IESG comments:
Clarified that GRASP runs in a single addressing realm
Improved wording about FQDN resolution, clarified that URI usage is
out of scope.
Clarified description of negotiation timeout.
Noted that 'dry run' semantics are ASA-dependent
Made the ACP a normative reference
Clarified that LL multicasts are limited to GRASP interfaces
Unicast UDP moved out of scope
Editorial clarifications
draft-ietf-anima-grasp-11, 2017-03-30: draft-ietf-anima-grasp-11, 2017-03-30:
Updates following IETF 98 discussion: Updates following IETF 98 discussion:
Encryption changed to a MUST implement. Encryption changed to a MUST implement.
Pointed to guidance on UTF-8 names. Pointed to guidance on UTF-8 names.
draft-ietf-anima-grasp-10, 2017-03-10: draft-ietf-anima-grasp-10, 2017-03-10:
 End of changes. 36 change blocks. 
97 lines changed or deleted 126 lines changed or added

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