On Wed, Jun 07, 2017 at 12:38:42PM +1200, Brian E Carpenter wrote:
> 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.
>
Ack. see PM with Eric. I think we can have all that text in ACP.
> I think DULL is more fundamental to GRASP.
Yes.
> and it doesn't contain any undefined mechanism.
Well... i disagree (SONN didn't have this either), but not worth arguing.
> 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.
Well... I would love if the GRASP RFC would make it obvious that
GRASP could proliferate into as many environments as its beneficial.
To me this means that GRASP should say that it can run on any
secure transport and that ACP is just an example thereof. Maybe
specify the requirements of the secure transport. But ACP should not
need to be a normative reference.
Now i don't know if you even want to have this argument with the IESG...
Right now thhe text does tie GRAASP very tightly to the ACP.
Would IP have to be a normative reference for a new transport protocol built
today ?
[lots of ignored proposed text deleted]
> 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?
I can only make sugestions, you decide.
> > 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.
I think this is today quite simple. I also think that one can not really explain
what a "secure transport is without having the term of a GRASP domain:
The secure transport needs to provide authentication (and optionally encryption)
for unicast packets between any GRASP peers in the GRASP domain.
It must prohibit traffic between any GRASP peers in the GRASP domain and
nodes outside the GRASP domain.
ACP can provide secure transport for a GRASP domain that extends across
a complete ACP because it offers these security functions.
> > 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.
Multicast is a red herring. The fact that we use link-local-scope multicast
is to make life easier for GRASP, but when using the ACP you would not even
need it, because you do know upfront the IPv6 link-local unicast addresses
of your GRASP peers. Instead of sending link-local multicast you could therefore
also send link-local unicast.
Consider a non-ACP solution for GRASP: You just rely on the autonomic domain
certificate. You use DULL to on all interfaces to discover your GRASP neighbors.
You set up persistent TLS connections to your GRASP neighbors. You set up
dynamic TLS connections to your (remote) GRASP peers. Aka: Same thing as when
using ACP except that you replace TCP with TLS.
Consider physcial security based secure transport (which the IETF crypto mafia
would
of course argue is totally unacceptable): The physcial infrastructure is
secured,
eg: Data Center internal network. Any links outside the physcial secure domain
have
filters for GRASP link-local multicast. Maybe even filters for some GRASP
specific
TCP port to be even more secure. Again, you run DULL for GRASP neighbor
discovery. You
build GRASP TCP to all neighbors, you build dynamic TCP to all GRASP peers.
Its not really rocket science.
Aka: the non-DULL "multicast is always inside whatever you define to be your
secure transport.
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
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
