Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04

Paul Wouters <paul@nohats.ca> Thu, 21 January 2021 02:28 UTC

Return-Path: <paul@nohats.ca>
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 DD70C3A16B3 for <ipsec@ietfa.amsl.com>; Wed, 20 Jan 2021 18:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 WMdnVlKwM6jA for <ipsec@ietfa.amsl.com>; Wed, 20 Jan 2021 18:28:27 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D7E3A16B1 for <ipsec@ietf.org>; Wed, 20 Jan 2021 18:28:25 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DLmXQ2fN3zDtk; Thu, 21 Jan 2021 03:28:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1611196102; bh=R9QWFYhVtk4oJtXnlt9+bN4ZYqZX4DVWC+FV0Li9kQ8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hk+fK64IXghev4yFAcL2aGffu3B8g2HtF3WwEyZ6gNVAz7DKu0y8MFz8GWI75uBiK bbdAZ1+9JY8JVELlyGsk3JpzCiBLrI+FaP1mvO1tzrFWte0ZA8FgrfgwG+45sriR3G f2VYxYwyuwLPPaaxNPzUbRkMtsbgGq/Lmc8Bh22c=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pd4JtBO9is_b; Thu, 21 Jan 2021 03:28:20 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 21 Jan 2021 03:28:20 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 039946029B62; Wed, 20 Jan 2021 21:28:18 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EF01B66A9A; Wed, 20 Jan 2021 21:28:18 -0500 (EST)
Date: Wed, 20 Jan 2021 21:28:18 -0500
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <smyslov.ietf@gmail.com>
cc: IPsecME WG <ipsec@ietf.org>, Sahana Prasad <sahana.prasad07@gmail.com>
In-Reply-To: <03e801d6ef2d$88820f00$99862d00$@gmail.com>
Message-ID: <da8f5de-d64d-595c-74bc-9f486b7161e@nohats.ca>
References: <03e801d6ef2d$88820f00$99862d00$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3_7qzN_L6HVGaIIB-V0Ug2oPmwI>
Subject: Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04
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, 21 Jan 2021 02:28:30 -0000

On Wed, 20 Jan 2021, Valery Smyslov wrote:

> First, it's not clear for me why zero length TS_SECLABLE is prohibited.
> The draft currently says
>
>   A zero length Security Label MUST NOT be used.  If a received TS
>   payload contains a TS_TYPE of TS_SECLABEL with a zero length Security
>   Label, that specific Traffic Selector MUST be ignored.
>
> I wonder what's rational behind this restriction. From my point of view
> zero length TS_SECLABLE can be used to express that using Security Labels
> is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector
> along with other  TS_SECLABEL Traffic Selectors to indicate that responder
> is free to not use security labels for the SA.

We did discuss this earier in the WG. There is no use case of "optional"
security labels. You either insist on these, or you don't use these.

Implementing "optional" ones by using a zero length label is asking for
implementation problems. Especially when people consider these labels
as strings and run strlen() on the empty (but NULL terminated string)
and interpret that as wildcard.

Since there is no use case, and significant implementation danger, the
document makes an explicit case to reject these. Our implementation
will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL.

> Currently draft suggests
> the initiator to perform several attempts to establish IPsec SA
> with and without TS_SECLABEL Traffic Selectors in such situation,
> which is more complicated and less efficient. Am I missing something?

It was what the WG preferred to do. The reasoning was that labels are
surely very much preconfigured and connections will not be migrated
from "no security" to "security label" where the operator wants to
operate insecurely first. That is, opportunistic security labels is
not a thing.

The case you describe is very unlikely. Either the endpoints wants a
label or doesn't want one. optional security is not security.

> Another my concern is that draft allows security labels to differ
> in TSi and TSr without giving any possible semantic interpretation for this.

Correct. But the label is clearly defines as opaque to the IKE layer.
The IKE layer should not be making any kindds of assumptions or
interpretations, but just relay this to the underlying label security
consumer (eg in our case the LSM of SElinux). Note that our
implementation only supports symmetrical labels so far, because
that is how SElinux labeling works. But the protocol can accept
other methods.

> This looks weird. I think that at least some possible interpretation
> of such situation must be given, e.g. TS_SECLABEL in TSi is used
> for traffic from initiator to responder and TS_SECLABEL in TSr
> is used for the return traffic. In this case it is clear that
> they can differ in some situations.

I'm not sure why this is not clear? TSi and TSr entries apply to
one direction.  TS_SECLABEL does not change that.

> And the last (but not the least). It seems to me that Section 3
> (which aims to update Section 2.9 of RFC 7296) oversimplifies
> the negotiation process.

Again, we followed the consensus of the group here.

> In particular, the sentence
>
>   A responder MUST create its TS response by selecting one of each
>   TS_TYPE present in the offered TS by the initiator.
>
> is inaccurate in my opinion, since it implies (as I read it) that responder can pick
> exactly one traffic selector of each TS_TYPE and can only return it unmodified.

How about this clarification:

 	A responder MUST create its TS response by selecting at least
 	one of each TS Type.  One exception is that a responder MAY omit
 	a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least
 	one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected.
 	Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content
 	set MAY be selected.

Note that this is mentioned already in section 1.2:

    A Traffic Selector payload (TS) is a set of one or more Traffic
    Selectors of the same or different TS_TYPEs, but MUST include at
    least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE.

If you prefer other text, please provide your suggestion.

Paul