On Tue, May 30, 2017 at 6:59 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote:
> On 31/05/2017 11:30, Eric Rescorla wrote: > > On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < > > brian.e.carpen...@gmail.com> 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 < > >>> brian.e.carpen...@gmail.com> 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. >>> 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. -Ekr > Brian >
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
