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. We don't need wider scope multicast,
which is much harder to emulate. We'll try to make this expectation
clear.
> 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.
> and how you bridge multicast to unicast.
? We don't do that.
>> This is especially relevant for Rapid mode, where you are
>>> attaching real work to these multicast packets.
>>
>> Correct. I think we need to forbid that in the no-ACP case.
>>
>>> 2. I didn't find the security model very clear. As I understand
>>> things, basically anyone on the network who has ACP credentials
>>> is trusted to engage in negotiation with you, so, for instance,
>>> if you want to get parameter X, then you basically just trust
>>> whoever on the network offers you X. is that correct? That seems
>>> like it needs to be very explicitly called out. And if that's not
>>> true, then I don't understand the spec.
>>
>> 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. 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.
...
>> Finally, I don't see a spec for how you map CBOR onto the wire. Do you
>>> just shove them on? Something else?
>>
>> Yep, CBOR is just a string of bytes. That's CBOR 101 so I don't
>> think we need to say anything more.
>>
>
> I don't agree. JSON is just a string of bytes and yet ACME, for instance,
> contains
> a rather extensive protocol mapping to HTTP. So, you need to at least state
> that
> you just shove them on the wire.
Will do.
Brian
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
