Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08

[Daniel Migault <[e-mail]>]

On Mon, May 16, 2022 at 4:47 PM Robert Moskowitz <[e-mail]>
wrote:

> Thanks, Daniel for the update.
>
> Now some comments.
>
>      The necessary state is held within the IPsec Security Association and
>
>     The document specifies the necessary parameters of the EHC Context to
>     allow compression of ESP and the most common included protocols, such
>     as IPv4, IPv6, UDP and TCP and the corresponding EHC Rules.
>
> Should any reference be made to cipher compression?  At least reference
> to 8750?  Or since this is just the abs
>

sure we can, but the transform itself is a bit outside EHC.

>
>     It also
>     defines the Diet-ESP EHC Strategy which compresses up to 32 bytes per
>     packet for traditional IPv6 VPN and up to 66 bytes for IPv6 VPN sent
>     over a single TCP or UDP session.
>
>
> In UDP transport I am reducing 18 bytes (assuming cipher with zero
> padding) to 4 bytes.  Also worth noting here...
>
> we are saying up to which likely corresponds to an extreme case and
something like 18 bytes seems reasonable.

>
>     On the other hand, in IoT
>     communications, sending extra bytes can significantly impact the
>     battery life of devices and thus the life time of the device. The
>     document describes a framework that optimizes the networking overhead
>     associated to IPsec/ESP for these devices.
>
>
> You say nothing about constrained comm links.  This compression may make
> ESP viable over links like LoRaWAN.
>
> yes. if that is not in the doc, it might be we said it too many times that
we finally forgot ;-).


>     ESP Header Compression (EHC) chooses another form of context
>     agreement, which is similar to the one defined by Static Context
>     Header Compression (SCHC).
>
> Reference rfc 8724.
>
> And more than 'similar"?  Maybe "based on the one"?
>
> currently not, but this is actually what we think we should do.

>     The context
>     itself can be negotiated during the key agreement, which allows only
>     minimal the changes to the actual ESP implementation.
>
> I don't get this.  What only allows minimal changes?  The key agreement
> protocol or ECH?  If the later then perhaps:
>
> no. whatever is used to describe the compression descripression will not
be implemented by setting a compressor / decompressor for at least ESP
software implementation.  The changes are minor. On the other hand, things
may be a bit more complex for hardware based ESP which cannot be modified.
In that case, we probably need to implement the compression / decompression
steps outside ESP.

>     The context
>     itself can be negotiated during the key agreement, which then needs
> only
>     minimal the changes to the actual ESP implementation.
>
> More for introduction:
>
> Perhaps you can add that in transport mode, an SA may be for a single
> transport/port to tune the ECH for that use and that multiple SAs could
> be negotiated for this case.
>
> Question:  Can a single IKE exchange produce multiple SAs?
>
> The context is per SA, so I suppos ethe suggestion is to make it per SA if
that has not been clearly specified in the IKE extension document.

> Here is my use case:
>
> Between the UA and GCS are two flows.  One for Command and Control (C2)
> the other streaming video.  Both over UDP, but different ports.  So
> instead of having carry the UDP ports in all the messages, negotiate
> separate SAs with the appropriate ECH.
>
> Ah, I see this in Sec 5.  You should say something about this in the intro.
>
> sec 4.
>
>     EHC is able to compress any protocol encapsulated in ESP and ESP
>     itself.
>
> No really true per other claims.  Does it offer compressing RTP?  I need
> that, probably, for my streaming video app.
>
> We probably need to clarify this. It seems the baseline is pretty much any
layer related to traffic selectors, which I think could theoretically be
pretty high up in the layers though in practice this may be reduced to IP
and transport.

> to compress any IP and transport protocol...
>
> And only TCP and UDP are shown, what about, say, SCTP?
>
> BTW, I note that you use 'IKEv2'.  At this point is that really needed?
> Should just IKE be enough?  Has not IKEv1 been depreicated?
>
could be.

>
> 6.  EHC Context
>
>
>     The EHC Context is defined on a per-SA basis.  A context can be
>     defined for any protocol encapsulated with ESP and for ESP itself.
>
> Should that be "any IP or Transport protocol"?  To exclude layer 5
> protocols (CoAP, RTP,,,)?
>
> probably

> Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID
> included...
>
> I tend to agree.

> Or maybe 'typically'?  As some layer 5 might be easy?  RTP maybe?
>
> So this is it for this round of comments.  I am looking at Appdx A and
> making a UDP example.  Including IIV.
>
> Bob
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>


-- 
Daniel Migault
Ericsson