draft-ietf-anima-grasp-13.txt   draft-ietf-anima-grasp-14.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: December 8, 2017 Univ. of Auckland Expires: January 3, 2018 Univ. of Auckland
B. Liu, Ed. B. Liu, Ed.
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
June 6, 2017 July 2, 2017
A Generic Autonomic Signaling Protocol (GRASP) A Generic Autonomic Signaling Protocol (GRASP)
draft-ietf-anima-grasp-13 draft-ietf-anima-grasp-14
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 December 8, 2017. This Internet-Draft will expire on January 3, 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 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
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. Constrained Instances . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . 14
2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 18 2.5.5. Negotiation Procedures . . . . . . . . . . . . . . . 18
2.5.6. Synchronization and Flooding Procedures . . . . . . . 20 2.5.6. Synchronization and Flooding Procedures . . . . . . . 20
2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22 2.6. GRASP Constants . . . . . . . . . . . . . . . . . . . . . 22
2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 23 2.7. Session Identifier (Session ID) . . . . . . . . . . . . . 23
2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23 2.8. GRASP Messages . . . . . . . . . . . . . . . . . . . . . 23
2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 23 2.8.1. Message Overview . . . . . . . . . . . . . . . . . . 23
2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 24 2.8.2. GRASP Message Format . . . . . . . . . . . . . . . . 24
2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 25 2.8.3. Message Size . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 7, line 14 skipping to change at page 7, line 14
o Interface or GRASP Interface: Unless otherwise stated, these refer o Interface or GRASP Interface: Unless otherwise stated, these refer
to a network interface - which might be physical or virtual - that to a network interface - which might be physical or virtual - that
a 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 and which are have other interfaces that are not used by GRASP and which are
outside the scope of the autonomic network. outside the scope of the autonomic network.
2.2. High Level Deployment Model 2.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 (ANI) 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]. As a Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. As a
result, all autonomic nodes in the ACP are able to trust each other. result, all autonomic nodes in the ACP are able to trust each other.
It is expected that GRASP will access the ACP by using a typical It is expected that GRASP will access the ACP by using a typical
socket programming interface and the ACP will make available only socket programming interface and the ACP will make available only
network interfaces within the autonomic network. If there is no ACP, network interfaces within the autonomic network. If there is no ACP,
the considerations described in Section 2.5.1 apply. the considerations described in Section 2.5.1 apply.
There will also be one or more Autonomic Service Agents (ASAs). In There will also be one or more Autonomic Service Agents (ASAs). In
skipping to change at page 12, line 9 skipping to change at page 12, line 9
is to act as an announcement, avoiding the need for discovery of a is to act as an announcement, avoiding the need for discovery of a
widely applicable objective. widely applicable objective.
Some example messages and simple message flows are provided in Some example messages and simple message flows are provided in
Appendix D. Appendix D.
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
The protocol SHOULD always run within a secure Autonomic Control GRASP does not specify transport security because it is meant to be
Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is adapted to different environments. Every solution adopting GRASP
assumed to carry all messages securely, including link-local MUST specify a security substrate used by GRASP in that solution.
multicast when it is virtualized over the ACP. A GRASP instance MUST
verify whether the ACP is operational.
If there is no ACP, one of the alternatives in Section 2.5.2 applies.
Network interfaces could be at different security levels, in
particular being part of the ACP or not. All the interfaces
supported by a given GRASP instance MUST be at the same security
level.
The ACP, or in its absence another security mechanism, sets the
boundary within which nodes are trusted as GRASP peers. A GRASP
implementation MUST refuse to execute GRASP synchronization and
negotiation functions if there is neither an operational ACP nor
another secure environment.
Link-local multicast is used for discovery messages. Responses to
discovery messages MUST be secured, with one exception mentioned in
the next section.
2.5.2. Constrained Instances
This section describes some cases where additional instances of GRASP The substrate MUST enforce sending and receiving GRASP messages only
are appropriate, subject to certain security constraints. between members of a mutually trusted group running GRASP. Each
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
substrate and called the GRASP domain. The substrate must support
unicast messages between any group members and (link-local) multicast
messages between adjacent group members. It must deny messages
between group members and non group members. 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 substrate MUST provide mechanisms to remove untrusted
members from the group.
In these cases, since multicast packets are not secured, Rapid Mode If the substrate does not mandate and enforce GRASP message
discovery (Section 2.5.4.5) MUST NOT be used. encryption then any service using GRASP in such a solution MUST
provide protection and encryption for message elements whose exposure
could constitute an attack vector.
2.5.2.1. No ACP The security substrate for GRASP in the ANI is the ACP. Unless
otherwise noted, we assume this security substrate in the remainder
of this document. The ACP does mandate the use of encryption;
therefore GRASP in the ANI can rely on GRASP message being encrypted.
The GRASP domain is the ACP: all nodes in an autonomic domain
connected by encrypted virtual links formed by the ACP. The ACP uses
hop-by-hop security (authentication/encryption) of messages. Removal
of nodes relies on standard PKI certificate revocation or expiry of
sufficiently short lived 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. Messages MUST be authenticated and encryption MUST be structures running across a separate GRASP domain with a security
used. Further details may be specified in future documents. substrate. In the most simple case, each point-to-point interdomain
GRASP peering could be a separate domain and the security substrate
could be built using transport or network layer security protocols.
This is subject to future specifications.
2.5.2.2. Discovery Unsolicited Link-Local An exception to the requirements for the security substrate exists
for highly constrained subsets of GRASP meant to support the
establishment of a security substrate, described in the following
section.
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. Such operations being intrinsically insecure, they associations, for example as part of discovery for establishing
need to be confined to link-local use to minimize the risk of security associations such as a security substrate for GRASP.
malicious actions. Possible examples include discovery of candidate
ACP neighbors [I-D.ietf-anima-autonomic-control-plane], discovery of Such operations being intrinsically insecure, they need to be
bootstrap proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps confined to link-local use to minimize the risk of malicious actions.
Possible examples include discovery of candidate ACP neighbors
[I-D.ietf-anima-autonomic-control-plane], discovery of bootstrap
proxies [I-D.ietf-anima-bootstrapping-keyinfra] or perhaps
initialization services in networks using GRASP without being fully initialization services in networks using GRASP without being fully
autonomic (e.g., no ACP). Such usage MUST be limited to link-local autonomic (e.g., no ACP). Such usage MUST be limited to link-local
operations 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-
skipping to change at page 14, line 21 skipping to change at page 14, line 27
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. An implementation should report any NOT exceed the link MTU size. An implementation should report any
attempt to send a longer message as a run-time error. attempt to send a longer message as a run-time error.
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 but the details are It MAY support use of another transport protocol but the details are
out of scope for this specification. However, GRASP itself does not out of scope for this specification. However, GRASP itself does not
provide for error detection or retransmission. Use of an unreliable provide for error detection or retransmission of its unicast
transport protocol is therefore NOT RECOMMENDED. messages, so an unreliable transport protocol MUST NOT be used.
For considerations when running without an ACP, see Section 2.5.2.1. For considerations when running without an ACP, see Section 2.5.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 2.6). For unicast transport known GRASP Listen Port (Section 2.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.
2.5.4. Discovery Mechanism and Procedures 2.5.4. Discovery Mechanism and Procedures
skipping to change at page 35, line 41 skipping to change at page 35, line 41
The names of generic objectives MUST NOT include a colon (":") and The names of generic objectives MUST NOT include a colon (":") and
MUST be registered with IANA (Section 6). MUST be registered with IANA (Section 6).
The names of privately defined objectives MUST include at least one The names of privately defined objectives MUST include at least one
colon (":"). The string preceding the last colon in the name MUST be colon (":"). The string preceding the last colon in the name MUST be
globally unique and in some way identify the entity or person globally unique and in some way identify the entity or person
defining the objective. The following three methods MAY be used to defining the objective. The following three methods MAY be used to
create such a globally unique string: create such a globally unique string:
1. The unique string is a decimal number representing a registered 1. The unique string is a decimal number representing a registered
32 bit Private Enterprise Number (PEN) [I-D.liang-iana-pen] that 32 bit Private Enterprise Number (PEN) [RFC5612] that uniquely
uniquely identifies the enterprise defining the objective. identifies the enterprise defining the objective.
2. The unique string is a fully qualified domain name that uniquely 2. The unique string is a fully qualified domain name that uniquely
identifies the entity or person defining the objective. identifies the entity or person defining the objective.
3. The unique string is an email address that uniquely identifies 3. The unique string is an email address that uniquely identifies
the entity or person defining the objective. the entity or person defining the objective.
The GRASP protocol treats the objective name as an opaque string. The GRASP protocol treats the objective name as an opaque string.
For example, "EX1", "411:EX1", "example.com:EX1", "example.org:EX1 For example, "EX1", "32473:EX1", "example.com:EX1", "example.org:EX1
and "user@example.org:EX1" would be five different objectives. and "user@example.org:EX1" would be five different objectives.
The 'objective-flags' field is described below. The 'objective-flags' field is described below.
The 'loop-count' field is used for terminating negotiation as The 'loop-count' field is used for terminating negotiation as
described in Section 2.8.7. It is also used for terminating described in Section 2.8.7. It is also used for terminating
discovery as described in Section 2.5.4, and for terminating flooding discovery as described in Section 2.5.4, and for terminating flooding
as described in Section 2.5.6.2. It is placed in the objective as described in Section 2.5.6.2. It is placed in the objective
rather than in the GRASP message format because, as far as the ASA is rather than in the GRASP message format because, as far as the ASA is
concerned, it is a property of the objective itself. concerned, it is a property of the objective itself.
skipping to change at page 46, line 25 skipping to change at page 46, line 25
Contact: chair@ietf.org Contact: chair@ietf.org
Description: See Section 2.6 Description: See Section 2.6
Reference: RFC XXXX (this document) Reference: RFC XXXX (this document)
The IANA is requested to create a GRASP Parameter Registry including The IANA is requested to create a GRASP Parameter Registry including
two registry tables. These are the GRASP Messages and Options two registry tables. These are the GRASP Messages and Options
Table and the GRASP Objective Names Table. Table and the GRASP Objective Names Table.
GRASP Messages and Options Table. The values in this table are names GRASP Messages and Options Table. The values in this table are names
paired with decimal integers. Future values MUST be assigned using paired with decimal integers. Future values MUST be assigned using
the Standards Action policy defined by [RFC5226]. The following the Standards Action policy defined by [RFC8126]. The following
initial values are assigned by this document: initial values are assigned by this document:
M_NOOP = 0 M_NOOP = 0
M_DISCOVERY = 1 M_DISCOVERY = 1
M_RESPONSE = 2 M_RESPONSE = 2
M_REQ_NEG = 3 M_REQ_NEG = 3
M_REQ_SYN = 4 M_REQ_SYN = 4
M_NEGOTIATE = 5 M_NEGOTIATE = 5
M_END = 6 M_END = 6
M_WAIT = 7 M_WAIT = 7
skipping to change at page 46, line 51 skipping to change at page 46, line 51
O_ACCEPT = 101 O_ACCEPT = 101
O_DECLINE = 102 O_DECLINE = 102
O_IPv6_LOCATOR = 103 O_IPv6_LOCATOR = 103
O_IPv4_LOCATOR = 104 O_IPv4_LOCATOR = 104
O_FQDN_LOCATOR = 105 O_FQDN_LOCATOR = 105
O_URI_LOCATOR = 106 O_URI_LOCATOR = 106
GRASP Objective Names Table. The values in this table are UTF-8 GRASP Objective Names Table. The values in this table are UTF-8
strings which MUST NOT include a colon (":"), according to strings which MUST NOT include a colon (":"), according to
Section 2.10.1. Future values MUST be assigned using the Section 2.10.1. Future values MUST be assigned using the
Specification Required policy defined by [RFC5226]. Specification Required policy defined by [RFC8126].
To assist expert review of a new objective, the specification should To assist expert review of a new objective, the specification should
include a precise description of the format of the new objective, include a precise description of the format of the new objective,
with sufficient explanation of its semantics to allow independent with sufficient explanation of its semantics to allow independent
implementations. See Section 2.10.3 for more details. If the new implementations. See Section 2.10.3 for more details. If the new
objective is similar in name or purpose to a previously registered objective is similar in name or purpose to a previously registered
objective, the specification should explain why a new objective is objective, the specification should explain why a new objective is
justified. justified.
The following initial values are assigned by this document: The following initial values are assigned by this document:
skipping to change at page 47, line 29 skipping to change at page 47, line 29
EX4 EX4
EX5 EX5
EX6 EX6
EX7 EX7
EX8 EX8
EX9 EX9
7. Acknowledgements 7. 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 early review inputs were received made by Sheng Jiang and significant contributions were made by
from Toerless Eckert, Joel Halpern, Barry Leiba, Charles E. Perkins, Toerless Eckert. Significant early review inputs were received from
and Michael Richardson. William Atwood provided important assistance Joel Halpern, Barry Leiba, Charles E. Perkins, and Michael
in debugging a prototype implementation. Richardson. William Atwood provided important assistance in
debugging a prototype implementation.
Valuable comments were received from Michael Behringer, Jeferson Valuable comments were received from Michael Behringer, Jeferson
Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Jaeggli, Campos Nobre, Laurent Ciavaglia, Zongpeng Du, Yu Fu, Joel Jaeggli,
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
skipping to change at page 49, line 29 skipping to change at page 49, line 29
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-03 (work in progress), March 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-02 (work in progress), February
2017. 2017.
[I-D.liang-iana-pen]
Liang, P., Melnikov, A., and D. Conrad, "Private
Enterprise Number (PEN) practices and Internet Assigned
Numbers Authority (IANA) registration considerations",
draft-liang-iana-pen-06 (work in progress), July 2015.
[I-D.liu-anima-grasp-api] [I-D.liu-anima-grasp-api]
Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic
Autonomic Signaling Protocol Application Program Interface Autonomic Signaling Protocol Application Program Interface
(GRASP API)", draft-liu-anima-grasp-api-03 (work in (GRASP API)", draft-liu-anima-grasp-api-04 (work in
progress), February 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
Protocol", draft-stenberg-anima-adncp-00 (work in Protocol", draft-stenberg-anima-adncp-00 (work in
progress), March 2015. progress), March 2015.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <http://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 50, line 40 skipping to change at page 50, line 35
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003, RFC 3493, DOI 10.17487/RFC3493, February 2003,
<http://www.rfc-editor.org/info/rfc3493>. <http://www.rfc-editor.org/info/rfc3493>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
DOI 10.17487/RFC5226, May 2008, 2009, <http://www.rfc-editor.org/info/rfc5612>.
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, Signalling Transport", RFC 5971, DOI 10.17487/RFC5971,
October 2010, <http://www.rfc-editor.org/info/rfc5971>. October 2010, <http://www.rfc-editor.org/info/rfc5971>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>. March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
skipping to change at page 52, line 17 skipping to change at page 52, line 9
<http://www.rfc-editor.org/info/rfc7787>. <http://www.rfc-editor.org/info/rfc7787>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
2016, <http://www.rfc-editor.org/info/rfc7788>. 2016, <http://www.rfc-editor.org/info/rfc7788>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<http://www.rfc-editor.org/info/rfc8040>. <http://www.rfc-editor.org/info/rfc8040>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>.
Appendix A. Open Issues [RFC Editor: This section should be empty. Appendix A. Open Issues [RFC Editor: This section should be empty.
Please remove] Please remove]
o 68. (Placeholder) o 68. (Placeholder)
Appendix B. Closed Issues [RFC Editor: Please remove] Appendix B. Closed Issues [RFC Editor: Please remove]
o 1. UDP vs TCP: For now, this specification suggests UDP and TCP o 1. UDP vs TCP: For now, this specification suggests UDP and TCP
as message transport mechanisms. This is not clarified yet. UDP as message transport mechanisms. This is not clarified yet. UDP
is good for short conversations, is necessary for multicast is good for short conversations, is necessary for multicast
skipping to change at page 60, line 25 skipping to change at page 60, line 25
o 61. Is the SONN constrained instance really needed? o 61. Is the SONN constrained instance really needed?
RESOLVED: Retained but only as an option. RESOLVED: Retained but only as an option.
o 62. Is it helpful to tag descriptive text with message names o 62. Is it helpful to tag descriptive text with message names
(M_DISCOVER etc.)? (M_DISCOVER etc.)?
RESOLVED: Yes, done in various parts of the text. RESOLVED: Yes, done in various parts of the text.
o 63. Should encryption be MUST instead of SHOULD in Section 2.5.1 o 63. Should encryption be MUST instead of SHOULD in Section 2.5.1
and Section 2.5.2.1? and Section 2.5.1?
RESOLVED: Yes, MUST implement in both cases. RESOLVED: Yes, MUST implement in both cases.
o 64. Should more security text be moved from the main text into o 64. Should more security text be moved from the main text into
the Security Considerations? the Security Considerations?
RESOLVED: No, on AD advice. RESOLVED: No, on AD advice.
o 65. Do we need to formally restrict Unicode characters allowed in o 65. Do we need to formally restrict Unicode characters allowed in
objective names? objective names?
skipping to change at page 61, line 7 skipping to change at page 61, line 7
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-14, 2017-07-02:
Updates following additional IESG comments:
Updated 2.5.1 and 2.5.2 based on IESG security feedback (specify
dependency against security substrate).
Strengthened requirement for reliable transport protocol.
draft-ietf-anima-grasp-13, 2017-06-06: draft-ietf-anima-grasp-13, 2017-06-06:
Updates following additional IESG comments: Updates following additional IESG comments:
Removed all mention of TLS, including SONN, since it was under- Removed all mention of TLS, including SONN, since it was under-
specified. specified.
Clarified other text about trust and security model. Clarified other text about trust and security model.
Banned Rapid Mode when multicast is insecure. Banned Rapid Mode when multicast is insecure.
 End of changes. 26 change blocks. 
68 lines changed or deleted 87 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/