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

[Robert Moskowitz <[e-mail]>]

Daniel,

Back at it, now that ASTM is behind me...

what will it take to bring this in line with SCHC.  I don't know SCHC 
well enough to pick up the differences.

What will it take to add AES-GCM-12 to supported ciphers by IKE (and 
thus ESP)?  For my use case, I have a hard time seeing why I need a 
16-byte ICV.  Even an 30 min operation with streaming video is a limited 
number of packets.  I am going to talk to my contact at DJI to see what 
information they are willing to share...

Bob

On 5/16/22 16:47, Robert Moskowitz 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
>
>    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...
>
>
>    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.
>
>    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"?
>
>    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:
>
>    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?
>
> 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.
>
> 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?
>
> 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,,,)?
>
> Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID 
> included...
>
> 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