Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)

Toerless Eckert <tte@cs.fau.de> Fri, 02 October 2020 08:06 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 D79B23A03FB; Fri, 2 Oct 2020 01:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 L9yHh9DJ4PsE; Fri, 2 Oct 2020 01:06:22 -0700 (PDT)
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 8409F3A03F1; Fri, 2 Oct 2020 01:06:19 -0700 (PDT)
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 AD73C54864E; Fri, 2 Oct 2020 10:06:14 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A5486440059; Fri, 2 Oct 2020 10:06:14 +0200 (CEST)
Date: Fri, 2 Oct 2020 10:06:14 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-anima-autonomic-control-plane@ietf.org, anima-chairs@ietf.org, anima@ietf.org, Sheng Jiang <jiangsheng@huawei.com>
Message-ID: <20201002080614.GA374@faui48f.informatik.uni-erlangen.de>
References: <159727599109.5414.1617295798802435987@ietfa.amsl.com> <20200911125956.GA63981@faui48f.informatik.uni-erlangen.de> <20201001223244.GP89563@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201001223244.GP89563@kduck.mit.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/IZKUzPbLLjTsbpJjxA5l9qEbQMU>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-autonomic-control-plane-28: (with DISCUSS and COMMENT)
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: Fri, 02 Oct 2020 08:06:25 -0000

Thanks, Ben

Let me just comment on possible AI for you, i will do my AI in a few
days when i have more time.

On Thu, Oct 01, 2020 at 03:32:44PM -0700, Benjamin Kaduk wrote:
> I think A.6 is an interesting idea and don't want to drop the idea, but the
> current state of the text in A.6 is better suited for a separate doc than
> inclusion in this one.  I suppose I could try to do a shorter rewrite that
> might be a better fit for this doc if you want; let me know.

A separate doc would have to be an actual spec of the mechanism IMHO,
and alas i do not have the time right now to start it (and after
we have an ACP RFC maybe i can also find other WG participants to
contribute ;-)). So i do not want to loose the thought and think an
 appendix is the best reminder for the problem and solution directions.

Aka: Yes: If you want to send replacement text, please send it,
and i will replace A.6 with it verbatim.

> > End-to-end communication (inside or outside the ACP) will use the
> > ACP address, and it could authenticate its IPv6 address (the ACP
> > address) by using the ACP certificate during end-to-end authentication,
> > but this spec does not mandate that.
> 
> I would like (and will put in my forthcoming COMMENT) to at least mention
> that there are cases where you could do this sort of check, even though it
> is definitely impossible in some cases (such as the secure channel) and
> even if it is not mandated.  I think I can live with not requiring it,
> though.

What do you think would be achieved with such a check ? If we write anything,
we should know (if not write down) the most obvious/relevant attack vector
prohibited:

a) I do not quite care about discovering e.g.: a TCP proxy, because that
to me seems like the most obvious thing we could discover (TLS connection
end to end via TCP proxy). Indeed, in BRSKI we already explicitly benefit
from the BRSKI proxy which is a TCP proxy. So i am worried that unqualified
address comparison would eliminate future positive use of TCP proxies.

b) Where address check really would be beneficial is something where we
are missing a key bilding block, so it would at best be written into
an appendix as a reminder: We need a GRASP authentication block. Example:
ACP node announces (multicast GRASP) a service. We want to know if that
service announcement is actually authentic from the ACP node that
owns the ACP address in the GRASP announcement. If the GRASP message
had an auhentication extension, we would know that the announcement
and its ACP address is from the ACP who claims that address.

c) hmmm... what else... drawing blank...

Let me know what you think...

Cheers
    Toerless