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
- [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Tero Kivinen
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Russ Housley
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Hu, Jun (Nokia - US/Mountain View)
- Re: [IPsec] Labeled IPsec options Tero Kivinen
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters
- Re: [IPsec] Labeled IPsec options Valery Smyslov
- Re: [IPsec] Labeled IPsec options Paul Wouters