Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>> b. MUST: Performs DNS-based Service Discovery [RFC6763] over
>> Multicast DNS [RFC6762] searching for the service
>> "_bootstrapks._tcp.local.".
> I missed the bit where we got consensus to only specify DNSSD for
> discovery. My understanding was that since all ANs will contain the ANI
> components, GRASP discovery was an equally valid option.
This topic has come up repeatedly, and we have discussed it a lot.
Maybe we need to do a full WG Consensus call about this?
===
We really like GRASP, and we want to use to find pieces of the bootstrap system.
a) We believe that bootstrap will be used by many devices which do not have
a full AN stack.
And it could be that a line card that will have a full AN stack, doesn't
even have a full AN stack when it boots up the first time. It might not
even know that it will have a full AN stack until such time as it receives
its first firmware update after/during NETCONF-style bootstrap.
b) We believe that having a MTI that is already present in constrained
devices that might never do a full AN is a win.
c) From a long history of security standpoint, we believe that restricting
GRASP to work within the secured ACP (only) will have significant attack
surface advantages. While one could run a second GRASP instance that is
disconnected from the first on the proxy node, it would have to get a
number of configuration parameters via the secured GRASP side.
The history of computing is replete with examples of priviledge escalation
attacks from situations that were not originally envisioned.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =- (Camping this week!)
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
