IETF Logo Mail Archive

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

Robert Moskowitz <rgm-sec@htt-consult.com> Tue, 24 May 2022 16:14 UTC

Return-Path: <rgm-sec@htt-consult.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 9A1BBC185158 for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 09:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.751
X-Spam-Level:
X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.857, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 nBl0S6lehXOj for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 09:14:37 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 AE240C16551B for <ipsec@ietf.org>; Tue, 24 May 2022 09:14:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 7E4826279D; Tue, 24 May 2022 12:13:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OR39OYaGjJLf; Tue, 24 May 2022 12:13:39 -0400 (EDT)
Received: from [192.168.160.11] (unknown [192.168.160.11]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 5391A62794; Tue, 24 May 2022 12:13:37 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------fAksSNM5jwDoUsGLCIvsapSS"
Message-ID: <96a7be0e-49ad-e2b1-db42-6cf15f130a12@htt-consult.com>
Date: Tue, 24 May 2022 12:14:20 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
Content-Language: en-US
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>
Cc: IPsecME WG <ipsec@ietf.org>
References: <245277bb-6d70-dbcd-b99e-badc435b9c4d@htt-consult.com> <CAGL5yWa=hjCZD912YJPWM-x_=ChTo=yULk1P5FRfkfB9Db9+Gg@mail.gmail.com> <CH0PR11MB5444CB9D09A4C0E638D948F5C1D79@CH0PR11MB5444.namprd11.prod.outlook.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <CH0PR11MB5444CB9D09A4C0E638D948F5C1D79@CH0PR11MB5444.namprd11.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/NHfA9nXBh9L1Ci4eRaCJEEaII8c>
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 16:14:38 -0000

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> *On Behalf Of *Paul Wouters
> *Sent:* Tuesday, May 24, 2022 11:14 AM
> *To:* Robert Moskowitz <rgm-sec@htt-consult.com>
> *Cc:* IPsecME WG <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 list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

v2.23.0 | Report a Bug | By Email