On 14-Nov-19 14:49, Toerless Eckert wrote:
> 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.
Assuming we are worried about MITM attacks by other nodes enrolled
in the ACP, yes. But if that isn't part of the threat model, TLS
isn't really needed there.
> 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.
Remember that I started this 3 weeks ago because I got bored
waiting for the real ACP. Running code, right? My first step was
to add shared-key encryption to *all* GRASP packets. My second
step was to use a Diffie-Hellman exchange to safely spread those
shared keys. All I've done now is add a new option where you use
GRASP discovery to find a server and a GRASP request message to
start a session. In effect, GRASP hands the socket over to you
(encrypted or not). It could work exactly the same if GRASP
was using TLS sockets. I'm sure you suggested something like that
a couple of years ago.
Server: wait for GRASP M_REQ_NEG
do forever:
grasp.grecv()
grasp.gsend()
Client: discover peer (GRASP M_DISCOVERY etc)
send GRASP M_REQ_NEG
do forever:
grasp.gsend()
grasp.grecv()
> Maybe in the generic case of an undefined "secure transport substrate"
> below GRASP you give the app the option whether or not to encrypt ?
I'm not suggesting that we should formally add encryption to GRASP. It's
not a game for amateurs. Remember that the main issue we have is insecure
multicast, which is why GRASP is defined only to use LL multicast. If DTLS
supported multicast, things could be different, But yes, we could choose to
handle this explicitly - it's really an implementation and API issue.
> Maybe i am confused ?
Maybe my explanations are confused. You can see examples testclient.py
and testserver.py at https://github.com/becarpenter/graspy
I will be arriving Friday evening in SG and will likely hang around the
hackathon.
Regards
Brian
>
> 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
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
