Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec
Tobias Brunner <tobias@strongswan.org> Thu, 09 December 2021 13:42 UTC
Return-Path: <tobias@strongswan.org>
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 0602A3A0C8B for <ipsec@ietfa.amsl.com>; Thu, 9 Dec 2021 05:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.752
X-Spam-Level:
X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 i4SQGRZRtB3s for <ipsec@ietfa.amsl.com>; Thu, 9 Dec 2021 05:42:17 -0800 (PST)
Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0729E3A0C74 for <ipsec@ietf.org>; Thu, 9 Dec 2021 05:42:15 -0800 (PST)
Received: from [IPv6:2a01:8b81:5407:c100:7df8:a4df:67c3:3c39] (unknown [IPv6:2a01:8b81:5407:c100:7df8:a4df:67c3:3c39]) by mail.strongswan.org (Postfix) with ESMTPSA id 0BC4140209; Thu, 9 Dec 2021 14:42:13 +0100 (CET)
To: Paul Wouters <paul@nohats.ca>, Valery Smyslov <smyslov.ietf@gmail.com>
Cc: ipsec@ietf.org, 'Tero Kivinen' <kivinen@iki.fi>
References: <24831.15082.263253.443690@fireball.acr.fi> <2d1501d799ba$af76bc40$0e6434c0$@gmail.com> <ed3d346-8f66-620-1914-d55e0dd9f2c@nohats.ca>
From: Tobias Brunner <tobias@strongswan.org>
Message-ID: <1a61d1fa-9b4e-effd-3819-3b735c077ac2@strongswan.org>
Date: Thu, 09 Dec 2021 14:42:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <ed3d346-8f66-620-1914-d55e0dd9f2c@nohats.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/bH_iyXUSa7S5FaOI-oUSvz5Lj5M>
Subject: Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec
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, 09 Dec 2021 13:42:19 -0000
Hi Paul, >> 8. Section 3.2: >> It would be unlikely that the traffic for TSi and TSr would have a >> different Security Label, but this specification does allow this to >> be specified. >> >> Can you please provide some examples of possible semantics of >> different TS_SECLABELs in TSi and TSr? Sending different >> security labels in different directions? Just for curiosity. > > I cannot, but I wanted to ensure not to accidentally forbid it. What > we do see with our implementation though, that we end up with two > IPsec Sa's where each is only used in one direction. For example, > image you have an SElinux context for nfs-server and nfs-client. What > happens is that the NFS client triggers one label on the outgoing > connection, triggers ACQUIRE, sets up an IPsec SA with a label > "nfs-client". The first packet hits the NFS server, which to reply > hits a different SElinux context of "nfs-server". So it will trigger > an ACQUIRE and setup a second IPsec SA with a label "nfs-server". Both > IPsec SA's will only be used in one direction. I did not add any > of this into the document, as it is very SElinux specific, where as > the draft is agnostic on the meaning of SEC_LABEL and allows for > other mechanisms that might not have this complexity. In the SELinux case, and using your example, could the client actually propose "nfs-client in TSi and "nfs-server" in TSr? So the server could set "nfs-client" on the inbound SA/policy and "nfs-server" on the corresponding outbound SA/policy of the CHILD_SA (and vice-versa on the client)? Or won't that work? If it's a valid use case, should the document specify which of the two labels is to be applied to what SA/policy? Or is that an implementation aspect that you explicitly want to keep out of it? Also, I don't fully get the multiple label in TSi part. If multiple labels are allowed/supported per SA by the implementation (not sure how that would work inbound, but let's assume there is a way to mark packets with some kind of meta label that covers multiple negotiated ones), why would any narrowing take place for TSr? On the other hand, if multiple labels are not supported, in what situation could proposing multiple labels be useful? Wouldn't traffic with the omitted labels just get dropped afterwards? Or is the assumption that this triggers a new acquire/SA? If so, would the request not contain multiple labels again and, if that's the case, what prevents the peer from selecting the same label as before? Is it to keep track of what label it selected previously and that the intention of the initiator now might be that another should get selected? Or is it up to the initiator not to propose multiple labels the second time around (or just omit the ones it already has an SA for)? If so, why would it send multiple the first time (in particular if the SA was triggered by an acquire)? I think either the narrowing to a single label should be optional, or sending multiple labels in TSi should be prohibited in the first place. Regards, Tobias
- [IPsec] WGLC of draft-ietf-ipsecme-labeled-ipsec Tero Kivinen
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Benjamin Kaduk
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Valery Smyslov
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Valery Smyslov
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Valery Smyslov
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Valery Smyslov
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Tobias Brunner
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Paul Wouters
- Re: [IPsec] WGLC of draft-ietf-ipsecme-labeled-ip… Tobias Brunner