Re: [Anima] GRASP as a secure session layer

Toerless Eckert <tte@cs.fau.de> Thu, 14 November 2019 01:49 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F3120044 for <anima@ietfa.amsl.com>; Wed, 13 Nov 2019 17:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n68r8cH9apuT for <anima@ietfa.amsl.com>; Wed, 13 Nov 2019 17:49:45 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A341200C1 for <anima@ietf.org>; Wed, 13 Nov 2019 17:49:45 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DFA2854800B; Thu, 14 Nov 2019 02:49:39 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D51A1440015; Thu, 14 Nov 2019 02:49:39 +0100 (CET)
Date: Thu, 14 Nov 2019 02:49:39 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Anima WG <anima@ietf.org>
Message-ID: <20191114014939.GB33266@faui48f.informatik.uni-erlangen.de>
References: <87eb9861-114d-b910-fb97-9405470715be@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87eb9861-114d-b910-fb97-9405470715be@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/SY35Qg_4e5bHoKhlENe5umQzJYU>
Subject: Re: [Anima] GRASP as a secure session layer
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2019 01:49:49 -0000

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
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
tte@cs.fau.de