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

[Robert Moskowitz]

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.


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.  ;)




Yours,
Daniel

On Tue, May 24, 2022 at 4:59 PM Robert Moskowitz 
 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
 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
 wrote:


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 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 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




-- 
Daniel Migault

Ericsson

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec




--
Daniel Migault
Ericsson

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Daniel Migault]

On Wed, May 25, 2022 at 8:15 AM Robert Moskowitz 
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 
> 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 
>> 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 >> 40aiven...@dmarc.ietf.org> wrote:
>>>

 On Sun, May 22, 2022 at 9:20 PM Robert Moskowitz <
 rgm-...@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
>
> ___
> IPsec mailing listIPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec
>
>
>

-- 
Daniel Migault
Ericsson
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06

[to...@strayalpha.com]

Hi, Valery,

Thanks - I will confirm when the update is posted so this can be closed out.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 24, 2022, at 4:27 AM, Valery Smyslov  wrote:
> 
> 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] Tsvart last call review of 
> draft-ietf-ipsecme-rfc8229bis-06
>  
> Hi Valery,
>  
> Notes below.
>  
> Joe
> 
> 
> On May 23, 2022, at 4:53 AM, Valery Smyslov  > wrote:
>  
> Hi Joseph,
> 
> thank for your review, much appreciated. More inline.
> 
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org  if you reply to or forward this 
> review.
> 
> Overall, this document adds useful clarifications to the original RFC on
> tunneling IPsec over TCP. There are a number of issues that should be 
> addressed
> as it proceeds, as noted below. All can be addressed relatively directly 
> (i.e.,
> none create new open issues).
> 
> General comments:
> 
> The document lacks (and would benefit from) a section providing details of the
> differences in this update.
> 
> Good point.
> 
> can add the following text at the end of 1.1:
> 
> In particular:
> o The interpretation of the Length field preceding every message is clarified
> o Use of NAT_DETECTION_*_IP notifications is clarified
> o Retransmission behavior is clarified
> o Using cookie and puzzles is described with more detail
> o Error handling is clarified
> o Implications of TCP encapsulation on IPsec SA processing are expanded
> o Interaction of TCP encapsulation with MOBIKE is clarified
> o Section describing interactions with other IKEv2 extensions is added
> o Recommendation for TLS encapsulation include using TLS 1.3
> 
> Is it OK?
>  
> Sure; it might also be useful to indicate the section where each is addressed 
> in most detail.
>  
>   Done.
>  
>> Figures should include captions.
> 
> I would leave this to RFC Editor (we tried to keep RFC 8229 text when 
> possible,
> and it doesn't have captions too).
>  
> The RFC Editor isn’t likely to care. These can be added without changing the 
> intent of RFC 8229; in most cases, the caption is fairly obvious from the 
> text.
>  
>   I’ve added titles for the figures defining headers and prefix 
> formats 
>   and removed anchors from figures in Appendix B (so they are now 
> “inline”).
>  
>> Given the new document adds primarily clarifications, it would be preferable 
>> if
>> the header numbering were not gratuitously modified vs. the original. The new
>> section 2 should be demoted to 1.2 as per the original; this would go a long
>> way to avoiding unnecessary confusion between the two.
> 
> OK, makes sense.
> 
> 
> Specific suggestions and concerns:
> 
> Section 3 clarifies the meaning of the 16-bit length field as including both
> the message and the message length field. This is counterintuitive and
> problematic, notably because ESP messages could be up to 65535 bytes long. 
> This
> possibility should be addressed (e.g., prohibit tunneling of messages over
> 65533 bytes).
> 
> This is a a good catch, we'll add this clarification.
> 
> 
> Section 4.2 claims the length cannot be 0 or 1 bytes; again, this suggests it
> might have been better to have the length field no include the length itself.
> 
> The design decision that length field includes both the message and the 
> message
> length was made back in 2016 when RFC 8229 was developed to align 
> it with 3GPP’s recommendation. We are not in a position to change this design.
>  
> Understood.
> 
> 
>> Regardless, it seems there are other lengths that are equally invalid (isn’t
>> there a min ESP header size? What about the IP packet header inside)? The 
>> true
>> min should be indicated.
> 
> TCP encapsulation is used for IKE too and "NAT keepalive" messages 
> may still be sent by IKE (even they are not needed for TCP), which are 1 byte 
> long.
>  
> It might be useful to mention that.
>  
>   This possibility is mentioned in Section 7.6. Added a clarific