On 01/06/2017 00:59, Eric Rescorla wrote:
>
>
> On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter
> <[email protected] <mailto:[email protected]>> wrote:
>
> On 31/05/2017 11:30, Eric Rescorla wrote:
> > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter <
> > [email protected] <mailto:[email protected]>> wrote:
> >
> >> On some other points that are dangling after previous messages:
> >>
> >> On 31/05/2017 00:29, Eric Rescorla wrote:
> >>> On Mon, May 29, 2017 at 10:14 PM, Brian E Carpenter <
> >>> [email protected] <mailto:[email protected]>>
> wrote:
> >>>
> >>>> Eric,
> >>>>
> >>>> On 25/05/2017 14:32, Eric Rescorla wrote:
> >>>> ...
> >>>>>
> ----------------------------------------------------------------------
> >>>>> DISCUSS:
> >>>>>
> ----------------------------------------------------------------------
> >> ...
> >>>> Finally, I don't
> >>>>> understand the security story for the multicast packets.
> >>>>
> >>>> I think I already typed this a day or two ago, but with an ACP,
> >>>> they are secured, because the ACP is a secure virtual overlay
> >>>> network.
> >>>>
> >>>
> >>> This document then needs to state which precise properties of
> >>> ACP it is relying on for that. A brief skim of ACP suggests that
> >>> it relies on other protocols for its actual transport security and
> >>> at least some of those protocols (e.g., DTLS) do not support
> >>> multicast.
> >>
> >> Indeed, but as I understand it they will emulate link-local multicast
> >> over the secured connections.
> >
> >
> > It's not clear to me what that means. You perhaps expect to tie up
> > a connection to every counterparty in the network?
>
> That is exactly what the ACP does, as I understand it.
>
>
> That's not what I got from 5.4.3, which says:
>
> GRASP discovery and flooding messages are designed for use over link-
> local multicast UDP. They MUST NOT be fragmented, and therefore MUST
> NOT exceed the link MTU size.
>
> Perhaps a ladder diagram of how this works would help, both here
> and in the document.
Regardless of that, we will try to ensure that the next draft makes
this clear without too much repetition. By the time the reader gets
to 5.4.3, it should be clear that multicast UDP is via the ACP
just like unicast TCP.
I'll try a diagram but not right now as I have to run.
>
> >>> That is the trust model, but really as an explanatory matter I think
> >>>> it belongs in draft-ietf-anima-reference-model rather than here.
> >>>> I will add a few words in the High Level Deployment Model
> >>>> section and/or the Security Considerations.
> >>>>
> >>>> What we do say already is that authorization of ASAs is out of scope.
> >>>> I am certain that it needs to be tackled, but not here.
> >>>>
> >>>
> >>> I don't see how you have a complete protocol without that.
> >>
> >> The starting position is that we trust all autonomic nodes and
> therefore
> >> the ASAs installed in them. We are in the context of a single operator
> >
> > so this isn't really a stretch.
> >
> >
> > I certainly can see how someone might decide to deploy a system like
> > this, but it seems pretty problematic to have a system that is so
> brittle
> > to single-point compromise (The term of art here is "distributed single
> > point of failure")
> >
> >
> >> The questions around life cycle
> >> management of ASAs, which would certainly involve authorization,
> >> were intentionally not in the initial WG charter. I think it's true
> >> that you can't have a complete *system* without that, but I disagree
> >> that it's a requirement for the protocol.
> >>
> >
> > At minimum you need to specify that this is your trust model and
> > then work through the implications of compromise of some subset
> > of nodes, as well as of an attacker who can influence which nodes
> > you talk to.
>
> That really, really belongs in the reference model or the ACP draft;
> it's in no way specific to GRASP, because nodes could use any protocol
> they please over the ACP.
>
>
> It's a WG decision which document it goes in, but it's something
> that needs to exist, because otherwise it is not possible to assess the
> security of this document.
Then it had better be the ACP, which is normative.
(!Toerless again!)
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
