IETF Logo Mail Archive

Re: [IPsec] [saag] IETF 114 IPsecME report

Valery Smyslov <smyslov.ietf@gmail.com> Tue, 31 January 2023 13:20 UTC

Return-Path: <smyslov.ietf@gmail.com>
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 0527DC15155E for <ipsec@ietfa.amsl.com>; Tue, 31 Jan 2023 05:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LysWeegpC8GM for <ipsec@ietfa.amsl.com>; Tue, 31 Jan 2023 05:20:07 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8B2C15155B for <ipsec@ietf.org>; Tue, 31 Jan 2023 05:20:07 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id x40so24091356lfu.12 for <ipsec@ietf.org>; Tue, 31 Jan 2023 05:20:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=hriEIMIVHS5wvTF8i28MXyRlq86Um3bFu+CCfE19EHU=; b=TZkdxxdN8HY5oBFz0bOgoLZxxtX6+yBpGnpgYeEWtILYab6G/bQEWxnd6suu35ODgE ucaEv8e/hmaLBGp3rzRg83GUDmH+MFmHSUgcaBWEW31/3imjXNW3mlGWevxl/wkdNYIn WVGC3cmzAstoM4VgV/BXhj8OQrCz5AVwa3/q52D9lp1mQsOkIfCmfBWXKv6CYwKiv7M2 8wOb7E0jlm3UxgPyiWc8V3Og/y5S5lvOnPYzUDRhtx06I8EK/pBZsKPlK4XN9zgOmPOL Bf1pDaNM3uaa8m3Yvlku6a4FbElv+DhA/zrMNgTxwlCNfkGuWuffdg3uB8a3qj+atqzT PyWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=hriEIMIVHS5wvTF8i28MXyRlq86Um3bFu+CCfE19EHU=; b=JAFUZdu8iyBNFW9qgWgdxC1X3Vg70OIK1xQW8y1kpqV9FmAfA6p43mUO2TAOXkQwMf wuS3mHrTZRyw7cTSesjHcST3icsND6izONENxT6QX74bd7edLLTWS0SdbwAJQ2IumvVJ zN3D8eXXFksO06wEONRcledEhb/Hvw4RiDLjQQak2+JWr8PIgGDENNuCHRc7gUqGW91F th5bsIQj0QEfME3lCqIySnvlCBBVgd3tmx2ewDVqz9l8PQuIMkqe5iSQhSYXnZADuJYH Ekdax8xEzjfqnJja49QQKa/0V1cJisw14gR7ZAIcYO3EOC+KylpU4Im/A/ru1nD2zyYM JOLw==
X-Gm-Message-State: AFqh2krv19JOhDKVdC9QN5HpucDbWwIhwfVrCklEsQb5C1oeIJSQfnjZ uN56/7zVEO1HjkdnnGoj8icqMFwpHw0=
X-Google-Smtp-Source: AMrXdXtOvvkcaK8Bzf7Z91jQt3/XU9sByrg7RiAORcvdxV8KpWhEJdYa9zFMUuCV02KANz6gSamcRQ==
X-Received: by 2002:ac2:44d5:0:b0:4d1:d8b8:84bc with SMTP id d21-20020ac244d5000000b004d1d8b884bcmr12124536lfm.10.1675171205311; Tue, 31 Jan 2023 05:20:05 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id v4-20020ac25b04000000b004d85f2acd8esm537450lfn.295.2023.01.31.05.20.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2023 05:20:04 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, 'Paul Wouters' <paul.wouters@aiven.io>, ipsec@ietf.org
Cc: 'Yoav Nir' <ynir.ietf@gmail.com>, 'Roman Danyliw' <rdd@cert.org>
References: <25311.20490.971667.883557@fireball.acr.fi> <CAGL5yWbWUvqPPsC3e-rqEc5i00WWXAhe=_SurmiWDNzfF54rRg@mail.gmail.com> <CAGL5yWbpx2K3X7FpMVASUeTzQZ2A=tKDw9s5UBqWUKbGnTgxiw@mail.gmail.com> <25558.47779.655532.512440@fireball.acr.fi>
In-Reply-To: <25558.47779.655532.512440@fireball.acr.fi>
Date: Tue, 31 Jan 2023 16:20:04 +0300
Message-ID: <016301d93576$bb63c030$322b4090$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIgvL5PIvTMn4bG60OyNKXMODbfRQLH29ciAg85jPgCEOUVAq3x4/xg
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/jTzK_Pc1cBpNMVLWfyf1WFfnmuw>
Subject: Re: [IPsec] [saag] IETF 114 IPsecME report
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 31 Jan 2023 13:20:11 -0000

Hi Tero,

few comments inline.

[a lot of text snipped]

> This document should simply say that TS_SECLABEL MUST NOT be used
> alone. This document must not try to do incompatible change to the
> base RFC7296 which would make conforming implemntations
> non-conforming.

Unfortunately, this won't work. It is not enough to add new TS type,
with security labels the semantics of TS types should be changed
so, that there are "primary" TS types and "additional" ones.

This is because in RFC 7296 individual Traffic Selectors in TS payload 
are combined with OR. In other words, traffic matching
combination of any Traffic Selector in TSi and 
any Traffic Selector in TSr is protected.

TS_SECLABEL cannot be treated with this semantics, 
it must be treated with AND (as additional condition for 
the traffic to match), which requires RFC 7296 update.

I agree with you that current document text doesn't take into considerations 
the existence of other "primary" TS types, like TS_FC_ADDR_RANGE.

> So I do not think this document should update RFC7296 at all, so most
> of the section 3 is wrong.

The "proper" way would be to introduce new TS types
TS_IPV4_ADDR_RANGE_WITH_SECLABEL and TS_IPV6_ADDR_RANGE_WITH_SECLABEL.
I recall that it was already tried before, but I don't remember
why this way was abandoned.

Regards,
Valery.

> --
> kivinen@iki.fi
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email