Re: [IPsec] Labeled IPsec options

Tero Kivinen <kivinen@iki.fi> Mon, 16 December 2019 21:38 UTC

Return-Path: <kivinen@iki.fi>
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 402A112092F for <ipsec@ietfa.amsl.com>; Mon, 16 Dec 2019 13:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 Ixd7yC9bV1Da for <ipsec@ietfa.amsl.com>; Mon, 16 Dec 2019 13:38:02 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CEA120026 for <ipsec@ietf.org>; Mon, 16 Dec 2019 13:38:00 -0800 (PST)
Received: by fireball.acr.fi (Postfix, from userid 15204) id B6E3625C16A7; Mon, 16 Dec 2019 23:37:57 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24055.63797.695416.153493@fireball.acr.fi>
Date: Mon, 16 Dec 2019 23:37:57 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: ipsec@ietf.org, 'Sahana Prasad' <sahana@redhat.com>, 'Paul Wouters' <paul@nohats.ca>
In-Reply-To: <046401d5b1c6$98ed09d0$cac71d70$@gmail.com>
References: <alpine.LRH.2.21.1912092333560.23963@bofh.nohats.ca> <01f501d5b0b2$facb4370$f061ca50$@gmail.com> <24050.43728.115813.170898@fireball.acr.fi> <046401d5b1c6$98ed09d0$cac71d70$@gmail.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 9 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/oUw6Y5OjS_bvCYgLxi-CzQfbH8Q>
Subject: Re: [IPsec] Labeled IPsec options
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: Mon, 16 Dec 2019 21:38:04 -0000

Valery Smyslov writes:
> In our case the strategy for initiator is: retransmit and wait.
> If even after several retransmission it doesn't receive message
> with SECLABELS_SUPPORTED, then there is no reason to continue
> with IKE_AUTH (if using labels is mandatory for initiator).
> If it receives a message with SECLABELS_SUPPORTED, then go with it.

Which means configuration errors result in timeout instead of getting
clear error message that there is configuration error.

I.e., when initiator changes configuration and add
SECLABELS_SUPPORTED, and then tries to connect SGW, instead of getting
error message saying SECLABLES were not supported by other end it will
result in unauthenticated error messages and then finally timeout.

I always prefer to get proper authenticated error message from the
other end for configuration errors. I.e., if we instead propose
traffic selectors with SECLABELS and we should get TS_ACCEPTABLE error
message from the responder and that clearly indicates that there is
configuration error.

>From the RFC7296 section 2.9:

----------------------------------------------------------------------
...
   If the type of Traffic Selector proposed is unknown, the responder
   ignores that Traffic Selector, so that the unknown type is not
   returned in the narrowed set.
...
The responder performs the narrowing as follows:

   o  If the responder's policy does not allow it to accept any part of
      the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
      Notify message.
...
----------------------------------------------------------------------

I.e., if the other end does not support TS type containing labels, it
will ignore them and not include them in the narrowed set. If the
narrowed set becomes empty because of that it will return
TS_UNACCEPTABLE error message to the initiator and that gives clear
feedback that there is configuration error.

This is much more preferred than waiting for some time and then after
timeout decide that there might have been configuration error...
-- 
kivinen@iki.fi