Re: [IPsec] diet-esp - How do you know?

Daniel Migault <mglt.ietf@gmail.com> Tue, 24 May 2022 20:32 UTC

Return-Path: <mglt.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 807F3C2740B6 for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 13:32:17 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 G9XsOqyn9KUQ for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 13:32:16 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 B0102C26E8B8 for <ipsec@ietf.org>; Tue, 24 May 2022 13:31:42 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id r3so15363506ljd.7 for <ipsec@ietf.org>; Tue, 24 May 2022 13:31:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OoQnKML/ddCht+n/ux+1FguvWpPOX6Yr6HUYkwgjxmo=; b=fK+WAxf8LXXx24nDm76GhHAxZLnQ+QZNNevInC+45lLXSJ54OOVkXyvnPrV9OHMymz Dv1EtOm0R8a0jy6loyGT2uyF7FgRB73QWBqLjNvGpVpVSpjTyp2dlp2y5c+H9C69SNB0 FUnaNxzDQNUsiF9j6uvxtzF8io3U7VvC6Y7nDskeGS1zO9WvRrjjJMX0aaCGwwFoNGiw gUilCX68m4g3CmaAs3UmEEEwMJc/+AtxWGd8sELQRoo1A+TpNHyqRqo/Q6+IJ2c26YBm pxPMkEm1vGfwDX1ug9eYxDkYbZXr4lYDBG8jFZec/sfTEyCtaX2yw2fFA8iFauswLlMZ 0IrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OoQnKML/ddCht+n/ux+1FguvWpPOX6Yr6HUYkwgjxmo=; b=CkH2Y3QzYevG5cjDq6xCjWklmlQtuqQSCHzEfy7cJ9LBPxqi49pr/sZZ8TLrgErvkF XAtO/2621T7Ux8YWaIdixYMCIpmd2sdMse5eugc3+0Vg3KMp/aMCcp8NXCdD/1rWadPm KQ7za/XGpnzr7qN+ad4log+53CA1nDwBeB90ZYS1QP/E3CfCrtUxs69mN+VWLN9vrZ08 QXKD4YogX1f2eZhiOAqbt5XRv0yHqF5P9FuKNWc4eUIR5YGh5u8yC1bDADX+pu3LmIHn NSOkK1tRu3VHSPn5YDtDgRX36EUuIFeMSsZ1d00sbkNvvCIE6p8SoMJ3taJeMxn1+7AM 0Usg==
X-Gm-Message-State: AOAM531fe3H/huQwZXqhzVk48RI9x/9zuT6EJ/VUj3BpVLYgHnS+pO1x Nv63Zrs2c7z8hubyJD/fomBJgc7jwS5FLXr4ONG/7Y3z
X-Google-Smtp-Source: ABdhPJwmnjFGE74i1UzGbhbVuiN3bnvLShA3ZY33rjjhGoT75d/OQ9fFjXvzsUwWSdzqxA21QmyQiBu2C/hlFYu+BFg=
X-Received: by 2002:a2e:b88d:0:b0:253:ee47:e6f6 with SMTP id r13-20020a2eb88d000000b00253ee47e6f6mr6130594ljp.53.1653424300621; Tue, 24 May 2022 13:31:40 -0700 (PDT)
MIME-Version: 1.0
References: <245277bb-6d70-dbcd-b99e-badc435b9c4d@htt-consult.com> <CAGL5yWa=hjCZD912YJPWM-x_=ChTo=yULk1P5FRfkfB9Db9+Gg@mail.gmail.com> <CH0PR11MB5444CB9D09A4C0E638D948F5C1D79@CH0PR11MB5444.namprd11.prod.outlook.com> <96a7be0e-49ad-e2b1-db42-6cf15f130a12@htt-consult.com>
In-Reply-To: <96a7be0e-49ad-e2b1-db42-6cf15f130a12@htt-consult.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 24 May 2022 16:31:29 -0400
Message-ID: <CADZyTkmcq8EX-Ps+jcHcM0aTOy1AraVUG2QPh6rdqq13FnnW6w@mail.gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, IPsecME WG <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001a01ea05dfc7d816"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/AhxEM3r18B2Jma-SYnlIdLqA_OE>
Subject: Re: [IPsec] diet-esp - How do you know?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.34
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, 24 May 2022 20:32:17 -0000

This is correct. There is currently some text in the security consideration
but we can re-emphasize this of course. This however does not seem to me a
huge issue as inbound SPI are selected by the peer using these inbound SPI.
Note also that a full SPI value is agreed with IKE, diet-esp only performs
the compression / decompression.

Yours,
Daniel

On Tue, May 24, 2022 at 12:14 PM Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> Scott,
>
> That is my question/point.  And if I understand diet-esp and lsb, then the
> 8-bit SPI maps to the full SPI in the SA is xxxxxx07?
>
> Ah, the *Receiver* picks the incoming SPIs.  It has been so many years
> since I looked into the protocol/code that I lost sight of this.  I had it
> reversed.  Thus the receiver MUST be careful in selecting its incoming SPIs
> such that there is no collision.
>
> The draft needs to spell this out.
>
> And for a UAS Network Remote ID Service Provider, it would use a 2-byte
> transmitted SPI to allow for a reasonable number of UAS in service at any
> time...
>
> On 5/24/22 11:30, Scott Fluhrer (sfluhrer) wrote:
>
> I believe that the question is “when someone receives an IPsec packet, how
> do they determine the SA, assuming that they have negotiated both standard
> SAs (with 32 bit SPIs), and diet-esp (with shorter SPIs).”
>
>
>
> My initial assumption was that, as the receiver picks its incoming SPIs,
> that they pick them to allow unambiguous lookup.  For example, if a
> diet-esp inbound SA has an 8 bit SPI of 07, that means that the
> implementation ensures that it does not have any standard inbound SAs with
> SPIs of the form 07xxxxxxxx.
>
>
>
> It might not be totally unreasonable if the diet draft spelled out a
> method for achieving this…
>
>
>
> *From:* IPsec <ipsec-bounces@ietf.org> <ipsec-bounces@ietf.org> *On
> Behalf Of *Paul Wouters
> *Sent:* Tuesday, May 24, 2022 11:14 AM
> *To:* Robert Moskowitz <rgm-sec@htt-consult.com> <rgm-sec@htt-consult.com>
> *Cc:* IPsecME WG <ipsec@ietf.org> <ipsec@ietf.org>
> *Subject:* Re: [IPsec] diet-esp - How do you know?
>
>
>
>
>
> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz <rgm-sec@htt-consult.com>
> wrote:
>
> I think there is something else I am missing here.
>
> How does the receiving system 'know' that the packet is a diet-esp packet?
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-02
>
>
>
> It's negotiated with IKEv2.
>
>
>
> I guess the IKE stack has to signal this to the ESP implementation on what
> to expect when
>
> the policy is installed ?
>
>
>
> Paul
>
>
>
> _______________________________________________
> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson