Thanks, Brian. Lot of good work.
I was surprised to see SONN go away. I do not understand what was considered to
be
underspecified about it. Everything about that text was IMHO "OK". Now i was
not a big fan of the text, but if you do not want to bring it back then IMHO
we would need some other equivalent explanation.
Just as a reminder: The use-case for SONN is the ACP:
- you discover a candidate ACP neighbor with DULL
- You build a TLS connection to that candidate ACP neighbor
- You run "SONN" inside the TLS connection to negotiate the ACP protocol, eg:
IPsec
with/without GRE, or dTLS or IP over CoAP or what the heck.
- YOu build the ACP.
- Then you run the ACP instance of GRASP also across this new ACP leg.
The "SONN" instance dies as soon as the ACP is up to the neighbor.
I do not think that the "SONN" instance is anything special. Thats why i do not
necessarily need to see the text reinstated. But it was nicely listing out the
implications of running a separate instance of GRASP across just a single p2p
connection. Especially the fact that you wouldn't want to flood any M_DISCOVERY
from that instance over to all the interfaces you use for the ACP instance was
IMHO well explanatory.
If i look at -13 wrt to these considerations:
> The protocol SHOULD always run within a secure Autonomic Control
> Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is
> assumed to carry all messages securely, including link-local
> multicast when it is virtualized over the ACP. A GRASP instance MUST
> verify whether the ACP is operational.
"SHOULD always run within a secure ACP" is not a good sales pitch
and might confuse readers how easy it is to proliferate GRASP. In
that respect its IMHO factually not correct.
Here is how i would propose to write it resolving both the missing SONN text
and replacing that above paragraph:
GRASP is defined without authentication/encryption. Every ("normal") instance
of GRASP MUST
either rely on an underlying transport that authenticates (and optionally
encrypts)
messages from/to GRASP neighbors or the instance of GRASP MUST be constrained.
One such
constrained instance type of GRASP is defined below - DULL.
Devices may need to be able to run more than one normal instances of GRASP,
each with
a separate set of GRASP neighbors. No data structures of GRASP can be shared
across
instances (including registered/cached objectives). No messages received from a
neighbor in one instance eof GRASP can be forwarded to a neighbor in another
instance
of GRASP (eg: M_FLOOD messages that forwarded to all GRASP neighbors are
forwarded
only to all GRASP neighbors in the same instance).
In ANI devices, the main instance of GRASP is the ACP instance. The ACP is the
transport
that performs authentication and encryption of all GRASP messages for this
instance.
Before the ACP can be built to a neighbor, GRASP may also be used to negotiate
how to build the ACP to that neighbor. This negotiation happens over a separate
instance of GRASP running over TLS. This is a normal, but separate (from ACP)
instance
of GRASP. We call such an instance also a (normal) p2p instance, because it
operates
to only one GRASP neighbor. SUch a p2p instances implementation can be
simplified
because a range of functions do automatically not apply to it (forwarding of
M_FLOOD
messages, redirect messages, ...).
(aka: normal p2p instance would be exactly what SONN was).
> 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.
I am hesitant about the term "security level" that you introduce here. I would
not
know how to define that term. "Clarence, this interface has Clearance" ? ;-))
What would happen if you simply deleted the whole paragraph ? (but took my text
above) ?
> 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.
So... IMHO, it would be great if we had some clear terminology, eg:
GRASP domain: a connected graph of nodes. Each node in the graph is a (normal)
instance of GRASP running on a different (virtual) device.
GRASP neighbors: grasp nodes to which an instance has an edge in the graph
GRASP peers: all nodes (GRASP instances) in the graph
Instances of GRASP expect that they can unicast send/receive packets to all
peers.
GRASP does not need to know the addresses of neighbors because it addresses
neighbors via link-local multicast (M_DISCOVERY and M_FLOOD).
The section 2.5.2 about constrained instances :
With my proposed text qove IMHO you would not need any additional text for the
non-ACP case.
I also do no not understand where outside of DULL you would need the
consideration
of not doing Rapid Mode.
Cheers
Toerless
On Tue, Jun 06, 2017 at 10:22:20AM +1200, Brian E Carpenter wrote:
> This version includes a second round of responses to IESG comments.
>
> We may not be done yet, but please check the diffs. Here are the main changes:
>
> Removed all mention of TLS, including SONN, since it was under-
> specified.
>
> Clarified other text about trust and security model.
>
> Banned Rapid Mode when multicast is insecure.
>
> Explained use of M_INVALID to support extensibility
>
> Corrected details on discovery cache TTL and discovery timeout.
>
> Improved description of multicast UDP w.r.t. RFC8085.
>
> Clarified when transport connections are opened or closed.
>
> Noted that IPPROTO values come from the Protocol Numbers registry
>
> Protocol change: Added protocol and port numbers to URI locator.
>
> Removed inaccurate text about routing protocols
>
> Moved Requirements section to an Appendix.
>
> Other editorial and technical clarifications.
>
> Regards
> Brian
>
> On 06/06/2017 08:57, [email protected] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Autonomic Networking Integrated Model and
> > Approach of the IETF.
> >
> > Title : A Generic Autonomic Signaling Protocol (GRASP)
> > Authors : Carsten Bormann
> > Brian Carpenter
> > Bing Liu
> > Filename : draft-ietf-anima-grasp-13.txt
> > Pages : 79
> > Date : 2017-06-05
> >
> > Abstract:
> > This document specifies the GeneRic Autonomic Signaling Protocol
> > (GRASP), which enables autonomic nodes and autonomic service agents
> > to dynamically discover peers, to synchronize state with each other,
> > and to negotiate parameter settings with each other. GRASP depends
> > on an external security environment that is described elsewhere. The
> > technical objectives and parameters for specific application
> > scenarios are to be described in separate documents. Appendices
> > briefly discuss requirements for the protocol and existing protocols
> > with comparable features.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-anima-grasp-13
> > https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-13
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-grasp-13
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
