On 07/06/2017 11:24, Toerless Eckert wrote: > 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.
EKR didn't like the loose mention of TLS. It would be perfectly fine to revive SONN in the ACP draft or even in a separate ACP 'profile' draft. But I had the impression that IPSec was the preferred model for ACP. In either case you will have exactly the same discussion with EKR, and he's probably right ;-). In other words you have to fully describe how cert/key management works. I think DULL is more fundamental to GRASP and it doesn't contain any undefined mechanism. A reminder: assuming GRASP is approved by the IESG, it will block at the RFC Editor until the ACP is also approved. So I think it makes sense to focus all the security details in the ACP draft, to minimise loops between the documents. > > 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). I think your text and the existing text intend to say the same thing. But do you really want to go back to the IESG with a completely new text? Can we wait and see what the DISCUSSing ADs think about the changes so far? > > 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" ? ;-)) Hmm. That text first appeared in draft-ietf-anima-grasp-08. To me it seems self-defining, but if it doesn't seem that way to you, it should be retouched. There's a slight discrepancy between the way the current text uses "instance" (a GRASP instance in a single node) and your usage above (the set of such instances that share a security regime). So a bit more terminology tweaking is still needed. > 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. I have always ducked this because I understood that discussing domains and domain boundaries was future work for Anima. But logically, that makes sense. > 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'd need to read the whole thing to be sure of that. > I also do no not understand where outside of DULL you would need the > consideration > of not doing Rapid Mode. Can we assume secure multicast except inside the ACP? I don't think so. > > 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, internet-dra...@ietf.org 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 >>> i-d-annou...@ietf.org >>> 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 >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima