Hi,
I have one big issue with this version, and a few other comments below.
> 5.2. Neighbor discovery via mDNS/DNS-SD
>
> Autonomic devices use DNS-SD/mDNS to discover the IPv6 link-local
> address of autonomic neighbors across L2 adjacencies. The result is
> stored in the AN Adjacency Table, see Section 5.1.2.
Why? We have carefully designed GRASP discovery so that it could do this.
While I understand that bootstrap wants to use mDNS/DNSSD to cover the case
of non-AN devices, the ACP by definition is only active in AN devices which
will all support GRASP by definition.
There are two arguments hidden in the change log that seem spurious to me:
> Bootstrap
> protocol team decided to go with mDNS to discover bootstrap proxy,
> and ACP should be consistent with this.
Why? ACP should also be consistent with the rest of Anima. That's
a magical argument, not a technical one.
> ... b) Using GRASP both for the
> insecure neighbor discovery and secure ACP operatations raises the
> risk of introducing security issues through implementation issues/
> non-isolation between those two instances of GRASP.
Firstly, as mentioned again below, there may indeed be no isolation
because the implementation may use internal modes, not separate
instances. But the argument is empty: the fact that discovery requests
are public (unsecured link-local multicast) doesn't make GRASP itself
vulnerable. Discovery responses can be secured by GRASP/TLS as soon
as bootstrap has occurred.
I think this is the completely wrong approach for Anima.
(As I said in another message, making mDNS/DNSSD mandatory-to-implement
for bootstrap is reasonable, but bootstrap needs to support
GRASP discovery as well, to allow "100 pure Anima" deployments.)
--- Other comments ---
> An example:
>
> anima.acp+FD99:B02D:8EC3:0:200:0:6400:1...@example.com
>
> The ACP address MUST be specified in its canonical form, as specified
> in [RFC5952], to allow for easy textual comparisons.
RFC5952 requires lower-case, so your example is wrong and should be
anima.acp+fd99:b02d:8ec3:0:200:0:6400:1...@example.com
> 5.5.4. GRASP/TLS negotiation
...
> TBD: The exact negotiation steps in GRASP to achieve this outcome.
Right; the first thing is to define the format of the relevant GRASP
objective, then I think the rest will follow very naturally. We should
try to hold a side meeting about this in Berlin.
> 5.5.5. ACP Security Profiles
>
> A baseline autonomic device MUST support IPsec and SHOULD support
> GRASP/TLS
It's the GRASP spec that says that a GRASP implementation MUST
support TLS when there is no ACP. And every autonomic device
MUST support GRASP. So I think this should say
A baseline autonomic device MUST support IPsec and GRASP
> ... and dTLS. A constrained autonomic device MUST support
> dTLS.
Hmm. I think we need to talk about dTLS. I find it hard to believe
that a node incapable of supporting TLS will ever be an autonomic node.
Also, if dTLS is a MUST for some nodes and a SHOULD for others,
we don't have guaranteed connectivity.
> Autonomic devices need to specify in documentation the set of secure
> ACP mechanisms they suppport.
That doesn't help anybody. Autonomic nodes need to interoperate in
plug and play mode without any human needing to consult documentation
or check consistency. Security has to deploy itself with no intervention.
> 5.6. GRASP instance details
>
> Received GRASP packets are assigned to an instance of GRASP by the
> context they are received on:
>
> o GRASP packets received on an ACP (virtual) interfaces are assigned
> to the ACP instance of GRASP
>
> o GRASP packets received inside a TLS connection established for
> GRASP/TLS ACP negotiation are assigned to a separate instance of
> GRASP for that negotiation.
Just to repeat what I said a while back, this might not be how it's
implemented. There might equally be a single instance of GRASP in a
node but with several modes (insecure/ACP/TLS) that apply to individual
sessions. Sessions are distinguished explicitly in the GRASP protocol,
as well as by port number. Even if the implementation chooses to
launch separate instances of GRASP (rather than just a single multi-threaded
instance) there have to be common data structures shared between them.
> TBD: The Details of the GRASP objective/packet formats still need to
> be defined. Eg: Need to define an allocation for the objective of
> "Autonomic Node".
Yes. And its primary application would be ACP neighbor discovery, which
is why we don't need mDNS/DNSSD.
Brian
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
