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, [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
