Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)

Toerless Eckert <tte@cs.fau.de> Thu, 18 June 2020 01:57 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF143A0A93; Wed, 17 Jun 2020 18:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level:
X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 3zvKIf4fFwzB; Wed, 17 Jun 2020 18:57:39 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff: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 F12D33A0A92; Wed, 17 Jun 2020 18:57:38 -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 18499548440; Thu, 18 Jun 2020 03:57:33 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 12040440043; Thu, 18 Jun 2020 03:57:33 +0200 (CEST)
Date: Thu, 18 Jun 2020 03:57:33 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Paul Wouters <paul@nohats.ca>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Yoav Nir <ynir.ietf@gmail.com>, "ipsec@ietf.org WG" <ipsec@ietf.org>, draft-ietf-anima-autonomic-control-plane@ietf.org
Message-ID: <20200618015733.GG16371@faui48f.informatik.uni-erlangen.de>
References: <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> <20200617170403.GA18378@faui48f.informatik.uni-erlangen.de> <alpine.LRH.2.22.394.2006171357170.2234@bofh.nohats.ca> <20200617183127.GX16371@faui48f.informatik.uni-erlangen.de> <alpine.LRH.2.22.394.2006171556370.2234@bofh.nohats.ca> <872.1592440656@localhost> <alpine.LRH.2.22.394.2006172047440.16139@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.22.394.2006172047440.16139@bofh.nohats.ca>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/oFZ0nDWUeAlfSwp-jdRLCZ8o4iM>
Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2020 01:57:41 -0000

On Wed, Jun 17, 2020 at 08:55:12PM -0400, Paul Wouters wrote:
> The RFC states:
> 
>    The USE_TRANSPORT_MODE notification MAY be included in a request
>    message that also includes an SA payload requesting a Child SA.  It
>    requests that the Child SA use transport mode rather than tunnel mode
>    for the SA created.  If the request is accepted, the response MUST
>    also include a notification of type USE_TRANSPORT_MODE.  If the
>    responder declines the request, the Child SA will be established in
>    tunnel mode.  If this is unacceptable to the initiator, the initiator
>    MUST delete the SA.
> 
> 
> But note that the responder has already installed the IPsec SA in tunnel
> mode. So if the initiator finds that unacceptable, it must send the
> delete. During all this time, connectivity between the nodes will be
> blocked. The intention here is that transport mode is optional and
> should not be mandated by other protocols. Otherwise, the IKEv1
> style negoation of transport OR tunnel mode would have been kept.

How about my mails ask that i read this text such that the initiator will
delete the SA (not only client SA) if transport mode is not supported
be responder. Aka: the last two sentences to me describe exactly the
case where the initiator can/want only support transport mode.

Aka: i can not read your interpretation into this text.

Please answer the other questions from my reply mail.

> So I would recommend to follow the intention of RFC 7296 and not make
> up your own restrictions.

Again, i had a lot of arguments in my email that i need to see answers
to so that we can make progress here.

Cheers
    Toerless