Re: [Anima] GRASP as a secure session layer

Brian E Carpenter <> Thu, 14 November 2019 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CF2112007A for <>; Wed, 13 Nov 2019 19:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S03xBmnyPcGF for <>; Wed, 13 Nov 2019 19:20:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC54912006B for <>; Wed, 13 Nov 2019 19:20:20 -0800 (PST)
Received: by with SMTP id f19so2726973pgk.11 for <>; Wed, 13 Nov 2019 19:20:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tx1H0+nFHZ2QvOdhbTuI+x/WP7Ya7GKJZaOsGO8MrOY=; b=V4+jV5npg7JHg6cnBeoDJNI3AYbRVFjG+Xet+bj0SfXj1M77zE6flJFHYLDIE69I6O mQFR1APynfkCWn9QSZbOWroUCrjqRg7Rct3Cy4b9EZOixRS4o3pCTWCcMaaoEPID5ich TYztuH4SSW0BEkJyPwG92vSUI81Tyc+41xY0zBaztloXzPUmcL136hFachauSM8H8FdW CzRcedcYG4AStS8ag0/eAPbEW9t/LVWiCj+lYxsSmP9Nlef7X09gI6XccAgNzcjGuHKH ekZPv/BV5226geRdgrieMPKx9tiiAJdcLx9A6QriuehWhhn0NVnLLGk6lGwHxPGxzXgy 8+OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tx1H0+nFHZ2QvOdhbTuI+x/WP7Ya7GKJZaOsGO8MrOY=; b=DU9FyXAw96f71cf6srX7qUaS9VNmQSyEw4f7Yr6a0/Lb5osGQOx10C7bTA0aacJZgY mqC9hm0SiOCjsC0MhmfeAUN0SNxTus3g4u/Zgzocad5E5XhV0MJKTs1jMAfSP3UR+IFS 0nDxWqXoDLtB+Y9yzcUGMzbTBklieB8dpmn66txSA6aRVfGZ6Us9A1bmh2b7rMP5aAlT Zl5H3dDhHBYy+nzh/SK28wI5cyZ3OMMIFBwNCZkTXJr22HTN8lytfp5ZMnMWgWuz/f4s qJVlw7+G6ziE1YXwqDo2MqgEicmOnjMBs8i4HjfV7tUHDZDO71MdXgY8vufEU9FQfgY6 oLUg==
X-Gm-Message-State: APjAAAWtT1SfzqEam7iennvnfzwHeWwQa/ogaH4XeCkS4wSxs4a5iUsK vb9I2NAqeJXxf09yjRuwOFbKbBH7
X-Google-Smtp-Source: APXvYqzVrGuLgx5cHfCIVFHYTe2Xo5WAy/UoVQpQymGR9Q6Ks2D3Ewp6iOwLf33lTFqiDuN/GjzEUg==
X-Received: by 2002:a63:3603:: with SMTP id d3mr7452960pga.259.1573701619802; Wed, 13 Nov 2019 19:20:19 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id w8sm4079408pfi.60.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 19:20:19 -0800 (PST)
To: Toerless Eckert <>
Cc: Anima WG <>
References: <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Thu, 14 Nov 2019 16:20:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] GRASP as a secure session layer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 03:20:24 -0000

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:

Client: discover peer (GRASP M_DISCOVERY etc)
        send GRASP M_REQ_NEG
        do forever:

> 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
and at

I will be arriving Friday evening in SG and will likely hang around the


> 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