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

Daniel Migault <mglt.ietf@gmail.com> Tue, 24 May 2022 21:26 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 86794C2B0010 for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 14:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, 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=unavailable 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 S3__Yr_uXLKV for <ipsec@ietfa.amsl.com>; Tue, 24 May 2022 14:26:54 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 AC1EFC2B381E for <ipsec@ietf.org>; Tue, 24 May 2022 14:26:54 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id u23so32971815lfc.1 for <ipsec@ietf.org>; Tue, 24 May 2022 14:26:54 -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=ptCAs3aBgU3YYaAB9w/yf/dkKSpkpz9OReXTGZE0ppk=; b=RA10dJvpQhcdC1qvNqdKTR/Z6aaWi4uFdQ1sSH61SmQG+DQ+1PhnWCWXvGPqwyik2u ZhiH8xgOkIIhVoDpbOz1nYQ7Ct1XDto/i7tGqCjcKNqgEOJQ2F3eZLJMAop2Olq3VAPP b0c8mBmLpHgWlaOWwVfWa3ILIzBe4BfcYjkBQwh0AzT/WUTBOs/6lBKvBK4hStqv6drZ xIYnCcej+jYFBu5gel1I/wYo4Y5niJxDr2tCsbjFXJiybNAPvSk03rBlZmeNHZY2jP1I f+DLgMJYuZYcc2zvLZ3gd8z+wumO52Lbvu0wqb8BjX509fusrjIPl4xdSHiPoQog5CL8 wZgg==
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=ptCAs3aBgU3YYaAB9w/yf/dkKSpkpz9OReXTGZE0ppk=; b=33k6/lfOE7XQPpAtpJIVzcKN5kE9phs6Yse2RzoUfPECQpMPrPPDdA8qUcuHNM5Bat Ne7CZ6wA2SOxZzWvs5WT1Hi7c7smwc9Jbmr4AlvBRcjLrk4+b9poO1lZKWUjZqHdtPrZ I6Ct1rAWRkbIkt4VLmMMwbzT/3+9213ttkpPRtlAw5TTuAq5cWf/xHaliJ4WLWvohxzO 3seSXQfHhtCbaYaGk4+APp0T6D2vz4+wzm1UVAH/LQyGPIjAhmuKGoOFrqxEB60CEbeC iDaiEo2Z6yJdbzZ3NI1OYfX5a6FzCh/wBDfAjE03bbQ4YAq2OoSveFbca0OvtT4iQTD2 MZog==
X-Gm-Message-State: AOAM53018E6SBc2qZzE1kDGblaW2aAkwnpjJsiMkbuFYc23XJNEytoEc JdJhPX370la+cwGrgtUBGs7WULsgdWnGINo3ZitHbsxcFK8=
X-Google-Smtp-Source: ABdhPJzk8GIrPkBHSrrB0l8GynIFFM2AyvnVsu8ewnlc3uSNnlCS6QSYsih9GMnrNODungx5KkIEFflHOoG2yks8aqQ=
X-Received: by 2002:a05:6512:55a:b0:478:54e1:efee with SMTP id h26-20020a056512055a00b0047854e1efeemr14920135lfl.448.1653427612296; Tue, 24 May 2022 14:26:52 -0700 (PDT)
MIME-Version: 1.0
References: <245277bb-6d70-dbcd-b99e-badc435b9c4d@htt-consult.com> <CAGL5yWa=hjCZD912YJPWM-x_=ChTo=yULk1P5FRfkfB9Db9+Gg@mail.gmail.com> <CADZyTknARDjj=SZmstnBqxo5hJp-NzH09a6cH5Dxj3Zg7VfyAw@mail.gmail.com> <f55061a1-b1af-8ce5-7ecc-8d7ccef0ee03@htt-consult.com> <CADZyTknQSiCrBvdsnjQU8OcTCRhCOBeNW0CC10xhK6cHnD+76g@mail.gmail.com> <bf9499e1-0533-a503-e72b-ddd6ea62835a@htt-consult.com>
In-Reply-To: <bf9499e1-0533-a503-e72b-ddd6ea62835a@htt-consult.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Tue, 24 May 2022 17:26:41 -0400
Message-ID: <CADZyTk=x7WD+e5T+XF2VQuJevz_SexHysgSw=-rYjuOEZxRYEg@mail.gmail.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Cc: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, IPsecME WG <ipsec@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007e308205dfc89d86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/YbVNF2ZQBqSYOwclDse5CpjuRZk>
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 21:26:58 -0000

The IKE negotiation is for diet-esp is currently defined in a specific
draft:
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-ikev2-diet-esp-extension/

I think you are suggesting that the architecture description details what
is negotiated by IKEv2. Am I correct ?

Yours,
Daniel

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

> In My Highly Biased Opinion,,,
>
> There should be a section on the IKE negotiation of diet-esp, specifically
> calling out how this is done.  Especially the incoming SPI selection.
>
> Then there should be a section, perhaps sub-section of above, on incoming
> datagram processing to recognize a shortened SPI on the wire and pass it
> off to diet-esp processing.
>
> I keep thinking back to when we had fun writing 2410 and one implementor
> did not get the joke and did it wrong and would not interop in null mode
> with any other product.
>
> They were really not happy campers...
>
> On 5/24/22 16:47, Daniel Migault wrote:
>
> The issue only comes when a gateway wants to support all sizes of SPIs 0 -
> 1 - 2 - 3 - 4 bytes - which is very unlikely. For a deterministic lookup, I
> would suggest using IP addresses and the minimum allowed byted compressed
> SPI.
> If you use 2 - 3 bytes, the likelihood of collision might still be very
> low to support an additional signature check.
>
> Yours,
> Daniel
>
> On Tue, May 24, 2022 at 4:30 PM Robert Moskowitz <rgm-sec@htt-consult.com>
> wrote:
>
>> That is the 'easy' part.
>>
>> What does the code do when it receives an ESP packet?  How do it know
>> that it is a diet-esp packet and apply the rules?
>>
>> Next Header just says: ESP.
>>
>> On 5/24/22 16:23, Daniel Migault wrote:
>>
>> This is correct. IKEv2 is used both to agree on the use of Diet-ESP as
>> well as values to be used for the compression/decompression.
>>
>> Yours,
>> Daniel
>>
>> On Tue, May 24, 2022 at 11:14 AM Paul Wouters <paul.wouters=
>> 40aiven.io@dmarc.ietf.org> wrote:
>>
>>>
>>> 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
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>> _______________________________________________
>> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>
> _______________________________________________
> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>
>
>

-- 
Daniel Migault
Ericsson