Mainly agreed, but see in line..
On 08/06/2017 08:55, Toerless Eckert wrote:
> 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.
Well yes, but for discovery & flooding you actually need to emulate
multicast. GRASP assumes that the ACP VRF will do that. If not, GRASP
would have to access the adjacency table and send N copies. I could
code that, but I don't think I should need to.
> 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.
Well yes. Wouldn't you rather sub-contract all that to the ACP? I would.
> 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.
Well, it's just an ACP by another name. We aren't disagreeing. However,
relying on physical integrity of the network might work for an enterprise
IT manager, but that is a bit out of the IETF's scope.
> Aka: the non-DULL "multicast is always inside whatever you define to be your
> secure transport.
Yes.
Brian
>
> 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
