So.. in the ACP document, the hop-by-hop GRASP connections across
the ACP are using TCP because there is no added benefit of TLS
given how the connection is to a direct neighbor to which the
ACP already uses the secure channel encryption (e.g.: IPsec).
End-to-end GRASP connections across the ACP are expected to use TLS.
So, i would argue that the peer-to-peer communication of GRASP
across ACP is a secure session layer. Just the discovery by
its nature requires to trust the third party mitigating the
discovery. Because we're doing hop-by-hop forwarding this means
discovey needs to trust the intermediate GRASP ACP nodes. If we had
a client-server model, (e.g.: unicsat DNS servers), we'd have to
trust those servers.
So i am not quite sure what you suggested to change.
Maybe in the generic case of an undefined "secure transport substrate"
below GRASP you give the app the option whether or not to encrypt ?
Maybe i am confused ?
Cheers
Toerless
On Wed, Nov 13, 2019 at 09:01:48AM +1300, Brian E Carpenter wrote:
> Hi,
>
> While thinking about what we need in an ANIMA ecosystem, and about how
> we might marry ANIMA with more traditional techniques like NETCONF/YANG
> (as indicated in RFC8368), I remembered one suggestion that I think came
> from Toerless: is there a way for an ASA to use a secure "clear channel"
> across the ACP? But of course if we do that, many of the features of
> GRASP would be lost (discovery, session management).
>
> So here's a possible solution. Allow an ASA to use GRASP discovery etc.
> to set up a secure session with another ASA, but then instead of using
> GRASP negotiation or synchronization messages, simply take over the session
> and use simple send/receive primitives for whatever it wants.
>
> No sooner thought than done. I added one optional parameter to
> grasp.req_negotiate() to indicate this mode, and two new functions
> grasp.send() and grasp.recv(), and GRASP became a secure session layer.
> The code is really too new for me to commit to GitHub, but it's a very
> convincing proof of concept.
>
> Regards
> Brian Carpenter
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
