Re: [Anima] some comments on -- draft-ietf-anima-grasp-01

[Brian E Carpenter <[e-mail]>]

Hi Michael,

Thanks for reading and commenting.

On 30/11/2015 10:43, Michael Richardson wrote:
> 
> 
> section 2.1, part 2.
> 
>> 2.1.  Requirements for Discovery
>>   2.  When an ASA first starts up, it has no knowledge of the specific
>>   network to which it is attached.  Therefore the discovery process
>>   must be able to support any network scenario, assuming only that the
>>   device concerned is bootstrapped from factory condition.
> 
> I'm thinking that there is more to this: the ASA may assume that the device,
> having been bootstrapped, now has a secured ACP with the local machine.

Yes, you could argue that there's a local sandbox I guess, but is that
a protocol issue?

> 
> (The exception being a bootstrap ASA, but I'm not convinced GRASP should be
> used for that)

I tend to agree - we can have a *dummy* ASA for discovery purposes, but I
don't think the actual bootstrapping transaction needs to or should go
through GRASP.

> 
> I think that we should also need to think about channel binding mechanisms so
> that the ASA doesn't have to do all it's own security work, and so that an
> ASA can potentially put a bit more trust into the source address of a packet.

Well, GRASP effectively provides a session layer and the spec says it MUST
be secured, preferably by the ACP. I'm not clear what more you want.

> 
> We also need to discuss how/if an ASA that do wants to do its own security
> gets access to the validated device identity. The possibility that the device
> would act as a sub-CA signing each of the ASAs.  Another model would have the
> device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating
> that ASA-specific-CA being a meta goal.)

Right, but given that ASA authorization is out of scope for GRASP,
what are you asking for? I agree there should be an API giving access
to the security credentials such as the ID, but shouldn't that be provided
by the security function itself, not by GRASP?

> 
>>   8.  The discovery process must not generate excessive (multicast)
>>   traffic and must take account of sleeping nodes in the case of a
>>   resource-constrained network [RFC7228].
> 
> First, 7228 defines constrained devices, and challenged networks.
> "resource-constrained network" isn't a thing in 7228, so that needs to be
> clarified.

OK, wording detail, got it.

> 
> Second, if the ACP is implemented as I think it ought to, we won't support
> any kind of native multicast.  We could provide multicast via
> draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM.

There *will* be link-local multicast. In fact I spent most of today finding
out how to send and receive IPv6 LL multicasts in Python, and just half an
hour ago my code said:
 My goodness, I received a multicast
 b'\xf0\x00\xba\xaa' ('fe80::28cc:dc4c:9703:6781%12', 53330, 0, 12)

However, I agree that we should not ask the ACP to support multicast routing.
If there was some magic by which the ACP could secure LL multicast, that
would be wonderful, but I assume not.

> I don't think it's worth doing any of these things at the IP layer, I think
> that there will be grasp daemons running at each vertice of the ACP, and so I
> think that we should do flooding at the application layer, much like DNCP
> does for Homenet.

Yes and no. Absolutely there needs to be a GRASP relay agent on every
box that has more than one interface. But do you really want to do
unicast replication if there are a hundred nodes on the link?

> 
>>   25.  The protocol needs to be fully secured against forged messages
>>   and man-in-the middle attacks, and secured as much as reasonably
>>   possible against denial of service attacks.  It needs to be capable
>>   of encryption in order to resist unwanted monitoring, although this
>>   capability may not be required in all deployments.  However, it is
>>   not required that the protocol itself provides these security
>>   features; it may depend on an existing secure environment.
> 
> I feel like there is too much hedging.  This is where my comment that we seem
> to be writing at cross-purposes come to play.   I think it would be better to
> say:
> 
>         + 25.  The protocol is expected to run on top of a secure
>                infrastructure provided by the Autonomic Control Plane (ACP)
>                [I-D.ietf-anima-autonomic-control-plane].  The ACP is
>                expected to defend against: forged messages and man-in-the
>                middle attacks, as well as provide for mitigation of against
>                denial of service attacks from nodes not into the ACP.  The
>                ACP is further expected to provide a private channel.

The thing is that the ACP is supposed to be a SHOULD but the external
security has to be a MUST.

Life would be simpler if the ACP was a MUST but that would be a big change.
More below.

> 
> I think that the words here:
>   > , although this
>   >   capability may not be required in all deployments.
> 
> are insufficiently supported.  Why should the protocol be complicated in this
> fashion?  

That was specifically qualifying the encryption requirement. Personally,
I wouldn't mind removing it, but that's a WG decision.

> 3.3.1 goes on to say:
> 
>> 3.3.1.  Required External Security Mechanism
>>
>>   The protocol SHOULD run within a secure Autonomic Control Plane (ACP)
>>   [I-D.ietf-anima-autonomic-control-plane].  The ACP MUST provide a
>>   status indicator to inform GRASP that the ACP is operational.
>>
>>   If there is no ACP, the protocol MUST use another form of strong
>>   authentication and SHOULD use a form of strong encryption.  TLS
>>   [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based
>>   on a local Public Key Infrastructure (PKI) [RFC5280] managed within
>>   the autonomic network itself.
> 
> so, let's not sit on the fence here.  Can we please decide if we want an ACP,
> and if we don't, then let's stop working on it.

Of course we want an ACP.

> If the designers of GRASP are thinking of using it in some other
> non-Autonomic situation, then please write a new document that inherits from
> draft-ietf-anima-grasp for that purpose.

That isn't that point. The point is (I thought this was made somewhere in
the draft, but maybe not) two operators might want to use some autonomic
capability across the boundary between them, and they will not want
to merge their ACPs. So that specific autonomic capability would need
to be protected separately, presumably by a conventional solution
such as TLS. So we don't want to exclude that by construction; IMHO it
has no impact on the protocol itself either way.

Regards
      Brian