Hi Joe,
please see inline.
Regards,
Valery.
From: to...@strayalpha.com [mailto:to...@strayalpha.com]
Sent: Monday, May 23, 2022 6:14 PM
To: Valery Smyslov
Cc: tsv-art; draft-ietf-ipsecme-rfc8229bis@ietf.org; ipsec@ietf.org;
last-c...@ietf.org
Subject: [***SPAM***] Re: [Tsv-art] T
On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz
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
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 pic
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 xx07?
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.
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 wrote:
>
> On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz
> wrote:
>
>> I think there is something e
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
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 perfor
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 ve
The easiest way would be to assign the first few bits of the SPI to indicate
the SPI size; for example, all 8 bit SPIs might be allocated to have the first
two bits being 11; all 16 bit SPIs might have those two bits being 10; etc.
That way, an examination of the first few bits of the SPI would
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 shorten
I agree, maybe we should be more explicit in the security consideration. I
think at the time we wrote it, we did not want to define a SPI format and
leave it to the implementer. But I agree mentioning it as an example would
be clarifying.
An example where a 0 byte SPI could be used is when the pair
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 2
12 matches
Mail list logo
