On 06/06/2017 11:41, Max Pritikin (pritikin) wrote: > >> On Jun 5, 2017, at 4:22 PM, Brian E Carpenter <[email protected]> >> 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. > > The -13 text maintains the “MUST be authenticated and encryption MUST be > used” but now there is no normative requirement on how this is met. Correct?
Correct, because EKR's DISCUSS was partly about the semi-specified usage with TLS. > > <t>As mentioned in <xref target="highlevel"/>, some GRASP operations > might be > performed across an administrative domain boundary by mutual > agreement, without the > benefit of an ACP. Such operations > MUST be confined to a separate instance of GRASP with its own copy > of all GRASP > data structures. Messages MUST be authenticated and encryption MUST > be used. > <!-- TLS <xref target="RFC5246"/> and DTLS <xref target="RFC6347"/> > based on a Public Key Infrastructure (PKI) > <xref target="RFC5280"/> are RECOMMENDED for this purpose.--> > Further details may be specified in future documents. > </t></section> > > As such I’m not sure this section is providing any value anymore. Perhaps > simply remove it? > Its only saying that some future work might discover an alternative > non-constained way of running GRASP. This is effectively already discussed > above: > > > <t>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. </t> Well, maybe we can see whether what we've already done handles the DISCUSS? (However, I see the logic in what you say.) > QUESTION: The BRSKI -06 draft generically references GRASP for discovery but > of course we know that this is prior to being able to establish an ACP. > Therefore we must be referencing something in <section anchor="secinst" > title="Constrained Instances”>. I think then that the BRSKI document should > be referencing specifically <section anchor="secinst-dull" title="Discovery > Unsolicited Link-Local”>. Do you agree? Yes. I'm afraid I just haven't had time to read the latest BRSKI, but that seems correct. Thanks Brian > - max > > >> >> 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 > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
