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

[Robert Moskowitz <[e-mail]>]

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