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

[Daniel Migault <[e-mail]>]

On Wed, May 25, 2022 at 8:15 AM Robert Moskowitz <[e-mail]>
wrote:

>
>
> On 5/24/22 17:26, Daniel Migault wrote:
>
> 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 totally missed this draft.  It should at least be referenced in
> ipsecme-diet-esp.
>
 Sure.

>
> I will have to go read it to see if it covers my concerns.
>
>
> I think you are suggesting that the architecture description details what
> is negotiated by IKEv2. Am I correct ?
>
>
> This is an arch doc?  Does not read like one! I was thinking about
> explicit sections on IKE processes.  But now that I know that there is an
> IKE draft, at least referencing it in the intro should cover things.
> Maybe.  ;)
>
> By arch, I meant the description of where in the stack
compression/decompresison occurs. This is summarized in section 4
currently.

>
> Yours,
> Daniel
>
> On Tue, May 24, 2022 at 4:59 PM Robert Moskowitz <[e-mail]>
> 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 <[e-mail]>
>> 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=
>>> [e-mail]> wrote:
>>>
>>>>
>>>> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz <
>>>> [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>
>>>
>>>
>>> --
>>> Daniel Migault
>>> Ericsson
>>>
>>> _______________________________________________
>>> IPsec mailing [e-mail]://www.ietf.org/mailman/listinfo/ipsec
>>>
>>>
>>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>> _______________________________________________
>> IPsec mailing [e-mail]://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>
> _______________________________________________
> IPsec mailing [e-mail]://www.ietf.org/mailman/listinfo/ipsec
>
>
>

-- 
Daniel Migault
Ericsson