draft-ietf-anima-grasp-14.txt   draft-ietf-anima-grasp-15.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: January 3, 2018 Univ. of Auckland Expires: January 8, 2018 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
July 2, 2017 July 7, 2017
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-14 draft-ietf-anima-grasp-15
Abstract Abstract
This document specifies the GeneRic Autonomic Signaling Protocol This document specifies the GeneRic Autonomic Signaling Protocol
(GRASP), which enables autonomic nodes and autonomic service agents (GRASP), which enables autonomic nodes and autonomic service agents
to dynamically discover peers, to synchronize state with each other, to dynamically discover peers, to synchronize state with each other,
and to negotiate parameter settings with each other. GRASP depends and to negotiate parameter settings with each other. GRASP depends
on an external security environment that is described elsewhere. The on an external security environment that is described elsewhere. The
technical objectives and parameters for specific application technical objectives and parameters for specific application
scenarios are to be described in separate documents. Appendices scenarios are to be described in separate documents. Appendices
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 3, 2018. This Internet-Draft will expire on January 8, 2018.
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 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 5 2. GRASP Protocol Overview . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. High Level Deployment Model . . . . . . . . . . . . . . . 7 2.2. High Level Deployment Model . . . . . . . . . . . . . . . 7
2.3. High Level Design . . . . . . . . . . . . . . . . . . . . 8 2.3. High Level Design . . . . . . . . . . . . . . . . . . . . 8
2.4. Quick Operating Overview . . . . . . . . . . . . . . . . 11 2.4. Quick Operating Overview . . . . . . . . . . . . . . . . 11
2.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 12 2.5. GRASP Protocol Basic Properties and Mechanisms . . . . . 12
2.5.1. Required External Security Mechanism . . . . . . . . 12 2.5.1. Required External Security Mechanism . . . . . . . . 12
2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP . . . . 13 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP . . . . 13
2.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 14 2.5.3. Transport Layer Usage . . . . . . . . . . . . . . . . 14
2.5.4. Discovery Mechanism and Procedures . . . . . . . . . 14 2.5.4. Discovery Mechanism and Procedures . . . . . . . . . 15
2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 18 2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 19
2.5.6. Synchronization and Flooding Procedures . . . . . . . 20 2.5.6. Synchronization and Flooding Procedures . . . . . . . 21
2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22 2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 23
2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 23 2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 24
2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23 2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 25
2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 23 2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 25
2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 24 2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 25
2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 25 2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 26
2.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 25 2.8.4. Discovery Message . . . . . . . . . . . . . . . . . . 26
2.8.5. Discovery Response Message . . . . . . . . . . . . . 26 2.8.5. Discovery Response Message . . . . . . . . . . . . . 28
2.8.6. Request Messages . . . . . . . . . . . . . . . . . . 27 2.8.6. Request Messages . . . . . . . . . . . . . . . . . . 29
2.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 28 2.8.7. Negotiation Message . . . . . . . . . . . . . . . . . 30
2.8.8. Negotiation End Message . . . . . . . . . . . . . . . 29 2.8.8. Negotiation End Message . . . . . . . . . . . . . . . 30
2.8.9. Confirm Waiting Message . . . . . . . . . . . . . 29 2.8.9. Confirm Waiting Message . . . . . . . . . . . . . 30
2.8.10. Synchronization Message . . . . . . . . . . . . . . . 29 2.8.10. Synchronization Message . . . . . . . . . . . . . . . 31
2.8.11. Flood Synchronization Message . . . . . . . . . . . . 30 2.8.11. Flood Synchronization Message . . . . . . . . . . . . 31
2.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 31 2.8.12. Invalid Message . . . . . . . . . . . . . . . . . . . 32
2.8.13. No Operation Message . . . . . . . . . . . . . . . . 31 2.8.13. No Operation Message . . . . . . . . . . . . . . . . 33
2.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 31 2.9. GRASP Options . . . . . . . . . . . . . . . . . . . . . . 33
2.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 31 2.9.1. Format of GRASP Options . . . . . . . . . . . . . . . 33
2.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 32 2.9.2. Divert Option . . . . . . . . . . . . . . . . . . . . 33
2.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 32 2.9.3. Accept Option . . . . . . . . . . . . . . . . . . . . 34
2.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 32 2.9.4. Decline Option . . . . . . . . . . . . . . . . . . . 34
2.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 33 2.9.5. Locator Options . . . . . . . . . . . . . . . . . . . 34
2.10. Objective Options . . . . . . . . . . . . . . . . . . . . 35 2.10. Objective Options . . . . . . . . . . . . . . . . . . . . 36
2.10.1. Format of Objective Options . . . . . . . . . . . . 35 2.10.1. Format of Objective Options . . . . . . . . . . . . 36
2.10.2. Objective flags . . . . . . . . . . . . . . . . . . 36 2.10.2. Objective flags . . . . . . . . . . . . . . . . . . 38
2.10.3. General Considerations for Objective Options . . . . 36 2.10.3. General Considerations for Objective Options . . . . 38
2.10.4. Organizing of Objective Options . . . . . . . . . . 37 2.10.4. Organizing of Objective Options . . . . . . . . . . 39
2.10.5. Experimental and Example Objective Options . . . . . 39 2.10.5. Experimental and Example Objective Options . . . . . 41
3. Implementation Status [RFC Editor: please remove] . . . . . . 39 3. Implementation Status [RFC Editor: please remove] . . . . . . 41
3.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 39 3.1. BUPT C++ Implementation . . . . . . . . . . . . . . . . . 41
3.2. Python Implementation . . . . . . . . . . . . . . . . . . 40 3.2. Python Implementation . . . . . . . . . . . . . . . . . . 42
4. Security Considerations . . . . . . . . . . . . . . . . . . . 41 4. Security Considerations . . . . . . . . . . . . . . . . . . . 42
5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 43 5. CDDL Specification of GRASP . . . . . . . . . . . . . . . . . 45
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.1. Normative References . . . . . . . . . . . . . . . . . . 47 8.1. Normative References . . . . . . . . . . . . . . . . . . 49
8.2. Informative References . . . . . . . . . . . . . . . . . 48 8.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Open Issues [RFC Editor: This section should be Appendix A. Open Issues [RFC Editor: This section should be
empty. Please remove] . . . . . . . . . . . . . . . 52 empty. Please remove] . . . . . . . . . . . . . . . 54
Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 52 Appendix B. Closed Issues [RFC Editor: Please remove] . . . . . 54
Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 61 Appendix C. Change log [RFC Editor: Please remove] . . . . . . . 62
Appendix D. Example Message Formats . . . . . . . . . . . . . . 68 Appendix D. Example Message Formats . . . . . . . . . . . . . . 70
D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 68 D.1. Discovery Example . . . . . . . . . . . . . . . . . . . . 71
D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 69 D.2. Flood Example . . . . . . . . . . . . . . . . . . . . . . 71
D.3. Synchronization Example . . . . . . . . . . . . . . . . . 69 D.3. Synchronization Example . . . . . . . . . . . . . . . . . 71
D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 69 D.4. Simple Negotiation Example . . . . . . . . . . . . . . . 72
D.5. Complete Negotiation Example . . . . . . . . . . . . . . 70 D.5. Complete Negotiation Example . . . . . . . . . . . . . . 72
Appendix E. Requirement Analysis of Discovery, Synchronization Appendix E. Requirement Analysis of Discovery, Synchronization
and Negotiation . . . . . . . . . . . . . . . . . . 71 and Negotiation . . . . . . . . . . . . . . . . . . 73
E.1. Requirements for Discovery . . . . . . . . . . . . . . . 71 E.1. Requirements for Discovery . . . . . . . . . . . . . . . 73
E.2. Requirements for Synchronization and Negotiation E.2. Requirements for Synchronization and Negotiation
Capability . . . . . . . . . . . . . . . . . . . . . . . 73 Capability . . . . . . . . . . . . . . . . . . . . . . . 75
E.3. Specific Technical Requirements . . . . . . . . . . . . . 75 E.3. Specific Technical Requirements . . . . . . . . . . . . . 77
Appendix F. Capability Analysis of Current Protocols . . . . . . 76 Appendix F. Capability Analysis of Current Protocols . . . . . . 78
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81
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].
skipping to change at page 12, line 11 skipping to change at page 12, line 11
Some example messages and simple message flows are provided in Some example messages and simple message flows are provided in
Appendix D. Appendix D.
2.5. GRASP Protocol Basic Properties and Mechanisms 2.5. GRASP Protocol Basic Properties and Mechanisms
2.5.1. Required External Security Mechanism 2.5.1. Required External Security Mechanism
GRASP does not specify transport security because it is meant to be GRASP does not specify transport security because it is meant to be
adapted to different environments. Every solution adopting GRASP adapted to different environments. Every solution adopting GRASP
MUST specify a security substrate used by GRASP in that solution. MUST specify a security and transport substrate used by GRASP in that
solution.
The substrate MUST enforce sending and receiving GRASP messages only The substrate MUST enforce sending and receiving GRASP messages only
between members of a mutually trusted group running GRASP. Each between members of a mutually trusted group running GRASP. Each
group member is an instance of GRASP. The group members are nodes of group member is an instance of GRASP. The group members are nodes of
a connected graph. The group and graph is created by the security a connected graph. The group and graph is created by the security
substrate and called the GRASP domain. The substrate must support and transport substrate and called the GRASP domain. The substrate
unicast messages between any group members and (link-local) multicast must support unicast messages between any group members and (link-
messages between adjacent group members. It must deny messages local) multicast messages between adjacent group members. It must
between group members and non group members. Substrates MUST use deny messages between group members and non group members. With this
cryptographic member authentication and message integrity for GRASP model, security is provided by enforcing group membership, but any
messages. This can be end-to-end or hop-by-hop across the domain. member of the trusted group can attack the entire network until
The security substrate MUST provide mechanisms to remove untrusted revoked.
members from the group.
Substrates MUST use cryptographic member authentication and message
integrity for GRASP messages. This can be end-to-end or hop-by-hop
across the domain. The security and transport substrate MUST provide
mechanisms to remove untrusted members from the group.
If the substrate does not mandate and enforce GRASP message If the substrate does not mandate and enforce GRASP message
encryption then any service using GRASP in such a solution MUST encryption then any service using GRASP in such a solution MUST
provide protection and encryption for message elements whose exposure provide protection and encryption for message elements whose exposure
could constitute an attack vector. could constitute an attack vector.
The security substrate for GRASP in the ANI is the ACP. Unless The security and transport substrate for GRASP in the ANI is the ACP.
otherwise noted, we assume this security substrate in the remainder Unless otherwise noted, we assume this security and transport
of this document. The ACP does mandate the use of encryption; substrate in the remainder of this document. The ACP does mandate
therefore GRASP in the ANI can rely on GRASP message being encrypted. the use of encryption; therefore GRASP in the ANI can rely on GRASP
The GRASP domain is the ACP: all nodes in an autonomic domain message being encrypted. The GRASP domain is the ACP: all nodes in
connected by encrypted virtual links formed by the ACP. The ACP uses an autonomic domain connected by encrypted virtual links formed by
hop-by-hop security (authentication/encryption) of messages. Removal the ACP. The ACP uses hop-by-hop security (authentication/
of nodes relies on standard PKI certificate revocation or expiry of encryption) of messages. Removal of nodes relies on standard PKI
sufficiently short lived certificates. Refer to certificate revocation or expiry of sufficiently short lived
[I-D.ietf-anima-autonomic-control-plane] for more details. certificates. Refer to [I-D.ietf-anima-autonomic-control-plane] for
more details.
As mentioned in Section 2.3, some GRASP operations might be performed As mentioned in Section 2.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 running across a separate GRASP domain with a security structures running across a separate GRASP domain with a security and
substrate. In the most simple case, each point-to-point interdomain transport substrate. In the most simple case, each point-to-point
GRASP peering could be a separate domain and the security substrate interdomain GRASP peering could be a separate domain and the security
could be built using transport or network layer security protocols. and transport substrate could be built using transport or network
This is subject to future specifications. layer security protocols. This is subject to future specifications.
An exception to the requirements for the security substrate exists An exception to the requirements for the security and transport
for highly constrained subsets of GRASP meant to support the substrate exists for highly constrained subsets of GRASP meant to
establishment of a security substrate, described in the following support the establishment of a security and transport substrate,
section. described in the following section.
2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP 2.5.2. Discovery Unsolicited Link-Local (DULL) GRASP
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, for example as part of discovery for establishing associations, for example as part of discovery for establishing
security associations such as a security substrate for GRASP. security associations such as a security substrate for GRASP.
Such operations being intrinsically insecure, they need to be Such operations being intrinsically insecure, they need to be
confined to link-local use to minimize the risk of malicious actions. confined to link-local use to minimize the risk of malicious actions.
skipping to change at page 13, line 33 skipping to change at page 13, line 37
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 on a single interface and MUST be confined to a separate operations on a single interface and MUST be confined to a separate
insecure instance of GRASP with its own copy of all GRASP data insecure instance of GRASP with its own copy of all GRASP data
structures. This instance is nicknamed DULL - Discovery Unsolicited structures. This instance is nicknamed DULL - Discovery Unsolicited
Link-Local. 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 MAY send Discovery or Flood Synchronization link- o An initiator MAY send Discovery or Flood Synchronization link-
local multicast messages which MUST have a loop count of 1, to local multicast messages which MUST have a loop count of 1, to
prevent off-link operations. Other GRASP message types MUST NOT prevent off-link operations. Other unsolicited GRASP message
be sent. types MUST NOT be sent.
o A responder MUST silently discard any message whose loop count is o A responder MUST silently discard any message whose loop count is
not 1. not 1.
o A responder MUST silently discard any message referring to a GRASP o A responder MUST silently discard any message referring to a GRASP
Objective that is not directly part of a service that requires Objective that is not directly part of a service that requires
this insecure mode. this insecure mode.
o A responder MUST NOT relay any multicast messages. o A responder MUST NOT relay any multicast messages.
skipping to change at page 14, line 14 skipping to change at page 14, line 17
To minimize traffic possibly observed by third parties, GRASP traffic To minimize traffic possibly observed by third parties, GRASP traffic
SHOULD be minimized by using only Flood Synchronization to announce SHOULD be minimized by using only Flood Synchronization to announce
objectives and their associated locators, rather than by using objectives and their associated locators, rather than by using
Discovery and Response. Further details are out of scope for this Discovery and Response. Further details are out of scope for this
document document
2.5.3. Transport Layer Usage 2.5.3. Transport Layer Usage
All GRASP messages, after they are serialized as a CBOR byte string, All GRASP messages, after they are serialized as a CBOR byte string,
are transmitted as such directly over the transport protocol in use, are transmitted as such directly over the transport protocol in use.
which itself runs within the security environment discussed in the The transport protocol(s) for a GRASP domain are specified by the
previous section. security and transport substrate as introduced in Section 2.5.1.
GRASP discovery and flooding messages are designed for use over link- GRASP discovery and flooding messages are designed for GRASP domain
local multicast UDP. They MUST NOT be fragmented, and therefore MUST wide flooding through hop-by-hop link-local multicast forwarding
NOT exceed the link MTU size. An implementation should report any between adjacent GRASP nodes. The GRASP security and transport
attempt to send a longer message as a run-time error. substrate needs to specify how these link local multicasts are
transported. This can be unreliable transport (UDP) but it SHOULD be
reliable transport (e.g., TCP).
All other GRASP messages are unicast and could in principle run over If the substrate specifies an unreliable transport such as UDP for
any transport protocol. An implementation MUST support use of TCP. discovery and flooding messages, then it MUST NOT use IP
It MAY support use of another transport protocol but the details are fragmentation because of its loss characteristic, especially in
out of scope for this specification. However, GRASP itself does not multi-hop flooding. GRASP MUST then enforce at the user API level a
provide for error detection or retransmission of its unicast limit to the size of discovery and flooding messages, so that no
messages, so an unreliable transport protocol MUST NOT be used. fragmentation can occur. For IPv6 transport this means that those
messages must be at most 1280 bytes sized IPv6 packets (unless there
is a known larger minimum link MTU across the whole GRASP domain).
For considerations when running without an ACP, see Section 2.5.1. All other GRASP messages are unicast beteween group members of the
GRASP domain. These MUST use a reliable transport protocol because
GRASP itself does not provide for error detection, retransmission or
flow control. Unless otherwise specified by the security and
transport substrate, TCP MUST be used.
For link-local multicast, the GRASP protocol listens to the well- The security and transport substrate for GRASP in the ANI is the ACP.
known GRASP Listen Port (Section 2.6). For unicast transport Unless otherwise noted, we assume this security and transport
sessions used for discovery responses, synchronization and substrate in the remainder of this document when describing GRASPs
negotiation, the ASA concerned normally listens on its own message transport. In the ACP, TCP is used for GRASP unicast
dynamically assigned ports, which are communicated to its peers messages. GRASP discovery and flooding messages also use TCP: These
during discovery. However, a minimal implementation MAY use the link-local messages are forwarded by replicating them to all adjacent
GRASP Listen Port for this purpose. GRASP nodes on the link via TCP connections to those adjacent GRASP
nodes. Because of this, GRASP in the ANI has no limitations on the
size of discovery and flooding messages with respect to fragmentation
issues. UDP is used in the ANI with GRASP only with DULL when the
ACP is built to discover ACP/GRASP neighbors on links.
For link-local UDP multicast, the GRASP protocol listens to the well-
known GRASP Listen Port (Section 2.6). Transport connections for
Discovery and Flooding on relay nodes must terminate in GRASP
instances (eg: GRASP ASAs) so that link-local multicast, hop-by-hop
flooding of M_DISCOVERY and M_FLOOD and hop-by-hop forwarding of
M_RESPONSE and caching of those responses along the path work
correctly.
Unicast transport connections used for synchronization and
negotiation can terminate directly in ASAs that implement objectives
and therefore this traffic does not need to pass through GRASP
instances. For this, the ASA listens on its own dynamically assigned
ports, which are communicated to its peers during discovery.
Alternatively, the GRASP instance can also terminate the unicast
transport connections and pass the traffic from/to the ASA if that is
preferrable in some implementation (eg: to better decouple ASAs from
network connections).
2.5.4. Discovery Mechanism and Procedures 2.5.4. Discovery Mechanism and Procedures
2.5.4.1. Separated discovery and negotiation mechanisms 2.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 2.8.4) synchronization process. Upon receiving a Discovery (Section 2.8.4)
message, the recipient node should return a response message in which message, the recipient node should return a response message in which
skipping to change at page 15, line 37 skipping to change at page 16, line 25
discovery objective will respond directly (with M_RESPONSE). A discovery objective will respond directly (with M_RESPONSE). A
neighbor with multiple interfaces may respond with a cached discovery neighbor with multiple interfaces may respond with a cached discovery
response. If it has no cached response, it will relay the discovery response. If it has no cached response, it will relay the discovery
on its other GRASP interfaces. If a node receiving the relayed on its other GRASP interfaces. If a node receiving the relayed
discovery supports the discovery objective, it will respond to the discovery supports the discovery objective, it will respond to the
relayed discovery. If it has a cached response, it will respond with relayed discovery. If it has a cached response, it will respond with
that. If not, it will repeat the discovery process, which thereby that. If not, it will repeat the discovery process, which thereby
becomes iterative. The loop count and timeout will ensure that the becomes iterative. The loop count and timeout will ensure that the
process ends. Further details are given below. process ends. Further details are given below.
A Discovery message MAY be sent unicast (via UDP or TCP) to a peer A Discovery message MAY be sent unicast to a peer node, which SHOULD
node, which SHOULD then proceed exactly as if the message had been then proceed exactly as if the message had been multicast, except
multicast, except that when TCP is used, the response will be on the that when TCP is used, the response will be on the same socket as the
same socket as the query. However, this mode does not guarantee query. However, this mode does not guarantee successful discovery in
successful discovery in the general case. the general case.
2.5.4.3. Discovery Procedures 2.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. A Discovery message is sent by a discovery initiator via objective. If the security and transport substrate of the GRASP
UDP to the ALL_GRASP_NEIGHBORS link-local multicast address domain (see Section 2.5.3) uses UDP link-local multicast then the
(Section 2.6). Every network device that supports GRASP always discovery initiator sends these to the ALL_GRASP_NEIGHBORS link-local
listens to a well-known UDP port to capture the discovery messages. multicast address (Section 2.6) and and all GRASP nodes need to
Because this port is unique in a device, this is a function of the listen to this address to act as discovery responder. Because this
GRASP instance and not of an individual ASA. As a result, each ASA port is unique in a device, this is a function of the GRASP instance
will need to register the objectives that it supports with the local and not of an individual ASA. As a result, each ASA will need to
GRASP instance. 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 2.8.5) with locator a unicast Discovery Response message (Section 2.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. However, on a link that supports link-local multicast, it Responder. However, it SHOULD NOT respond with a cached response on
SHOULD NOT respond with a cached response on an interface if it an interface if it learnt that information from the same interface,
learnt that information from the same interface, because the peer in because the peer in question will answer directly if still
question will answer directly if still operational. operational.
If a device has no information about the requested discovery If a device has no information about the requested discovery
objective, and is not acting as a discovery relay (see below) it MUST objective, and is not acting as a discovery relay (see below) it MUST
silently discard the Discovery message. silently discard the Discovery message.
The discovery initiator MUST set a reasonable timeout on the The discovery initiator MUST set a reasonable timeout on the
discovery process. A suggested value is 100 milliseconds multiplied discovery process. A suggested value is 100 milliseconds multiplied
by the loop count embedded in the objective. by the loop count embedded in the objective.
If no discovery response is received within the timeout, the If no discovery response is received within the timeout, the
skipping to change at page 17, line 23 skipping to change at page 18, line 13
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.
2.5.4.4. Discovery Relaying 2.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 GRASP interfaces. running in a router) MUST support discovery on all GRASP interfaces.
We refer to this as a 'relaying instance'. We refer to this as a 'relaying instance'.
Constrained Instances (Section 2.5.2) are always single-interface DULL Instances (Section 2.5.2) are always single-interface instances
instances and therefore MUST NOT perform discovery relaying. 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 GRASP 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 and
incoming discovery message and MUST be tagged with the IP address of Initiator field as the incoming (see Section 2.8.4). The Initiator
its original initiator (see Section 2.8.4). Note that this initiator IP address field is only used to allow for disambiguation of the
address is only used to allow for disambiguation of the Session ID Session ID and is never used to address Response packets. Response
and is never used to address Response packets, which are sent to the packets are sent back to the relaying instance, not the original
relaying instance, not the original initiator. initiator.
The M_DISCOVERY message does not encode the transport address of the
originator or relay. Response packets must therefore be sent to the
transport layer address of the connection on which the M_DISCOVERY
message was received. If the M_DISCOVERY was relayed via a reliable
hop-by-hop transport connection, the response is simply sent back via
the same connection.
If the M_DISCOVERY was relayed via link-local (eg: UDP) multicast,
the response is sent back via a reliable hop-by-hop transport
connection with the same port number as the source port of the link-
local multicast. Therefore, if link-local multicast is used and
M_RESPONSE messages are required (which is the case in almost all
GRASP instances except for the limited use of DULL instances in the
ANI), GRASP needs to be able to bind to one port number on UDP from
which to originate the link-local multicast M_DISCOVERY messages and
the same port number on the reliable hop-by-hop transport (eg: TCP by
default) to be able to respond to transport connections from
responders that want to send M_RESPONSE messages back. Note that
this port does not need to be the GRASP_LISTEN_PORT.
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. For example, the rate limit possible denial of service attacks. For example, the rate limit
could be set to a small multiple of the observed rate of discovery could be set to a small multiple of the observed rate of discovery
messages during normal operation. The relaying instance MUST cache messages during normal operation. The relaying instance MUST cache
the Session ID value and initiator address of each relayed Discovery the Session ID value and initiator address of each relayed Discovery
message until any Discovery Responses have arrived or the discovery message until any Discovery Responses have arrived or the discovery
skipping to change at page 22, line 37 skipping to change at page 23, line 52
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. This user port MUST listen to for link-local multicasts when UDP is used for
MAY also be used to listen for TCP or UDP unicast messages in a M_DISCOVERY or M_FLOOD messages in the GRASP instance This user
simple implementation of GRASP (Section 2.5.3). port MAY also be used to listen for TCP or UDP unicast messages in
a simple implementation of GRASP (Section 2.5.3).
o GRASP_DEF_TIMEOUT (60000 milliseconds) o GRASP_DEF_TIMEOUT (60000 milliseconds)
The default timeout used to determine that an operation has failed The default timeout used to determine that an operation has failed
to complete. 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 47, line 47 skipping to change at page 49, line 37
Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman, Zhenbin Li, Dimitri Papadimitriou, Pierre Peloso, Reshad Rahman,
Markus Stenberg, Martin Stiemerling, Rene Struik, Martin Thomson, Markus Stenberg, Martin Stiemerling, Rene Struik, Martin Thomson,
Dacheng Zhang, and participants in the NMRG research group, the ANIMA Dacheng Zhang, and participants in the NMRG research group, the ANIMA
working group, and the IESG. working group, and the IESG.
8. References 8. References
8.1. Normative References 8.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, "Concise 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-11 (work in progress), July 2017.
[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-06 (work in progress), March 2017. plane-07 (work in progress), July 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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
skipping to change at page 48, line 47 skipping to change at page 50, line 37
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <http://www.rfc-editor.org/info/rfc8085>. March 2017, <http://www.rfc-editor.org/info/rfc8085>.
8.2. Informative References 8.2. Informative References
[I-D.carpenter-anima-asa-guidelines] [I-D.carpenter-anima-asa-guidelines]
Carpenter, B. and S. Jiang, "Guidelines for Autonomic Carpenter, B. and S. Jiang, "Guidelines for Autonomic
Service Agents", draft-carpenter-anima-asa-guidelines-01 Service Agents", draft-carpenter-anima-asa-guidelines-02
(work in progress), January 2017. (work in progress), July 2017.
[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-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-06 (work in progress), May 2017. keyinfra-07 (work in progress), July 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-
anima-reference-model-03 (work in progress), March 2017. anima-reference-model-04 (work in progress), July 2017.
[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-02 (work in progress), February anima-stable-connectivity-03 (work in progress), July
2017. 2017.
[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-04 (work in (GRASP API)", draft-liu-anima-grasp-api-04 (work in
progress), June 2017. progress), June 2017.
[I-D.stenberg-anima-adncp] [I-D.stenberg-anima-adncp]
Stenberg, M., "Autonomic Distributed Node Consensus Stenberg, M., "Autonomic Distributed Node Consensus
skipping to change at page 61, line 7 skipping to change at page 62, 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-15, 2017-07-07:
Updates following additional IESG comments:
Security (Eric Rescorla): missing brittleness of group security
concept, attack via compromised member.
TSV (Mirja Kuehlewind): clarification on the use of UDP, TCP, mandate
use of TCP (or other reliable transport).
Clarified that in ACP, UDP is not used at all.
Clarified that GRASP itself needs TCP listen port (was previously
written as if this was optional).
draft-ietf-anima-grasp-14, 2017-07-02: draft-ietf-anima-grasp-14, 2017-07-02:
Updates following additional IESG comments: Updates following additional IESG comments:
Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify
dependency against security substrate). dependency against security substrate).
Strengthened requirement for reliable transport protocol. Strengthened requirement for reliable transport protocol.
draft-ietf-anima-grasp-13, 2017-06-06: draft-ietf-anima-grasp-13, 2017-06-06:
 End of changes. 33 change blocks. 
147 lines changed or deleted 220 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/