On Tue, May 30, 2017 at 4:19 PM, Brian E Carpenter < [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]> 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? > With no ACP they are of course wide open, unless some new > >> magic has been invented that I'm not aware of. Hence the > >> restrictions in 3.5.2.2. "Discovery Unsolicited Link-Local" > >> > > > > As above, you need to specify which properties you are relying > > on, > > But in DULL we aren't relying on anything; we're just sending GRASP > packets over an interface. I don't see anything that needs specifying. > As you indicate, DULL has a whole pile of rules. Why are those rules sufficient? > and how you bridge multicast to unicast. > > ? We don't do that. > Huh? You send out a discovery packet in multicast and then expect someone to connect to you via unicast, no? >> 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. -Ekr
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
