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

On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> 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.
>
> We are basically balancing re-using a framework used / standardized by the
IETF versus defining our own framework. So it is just to remain more
aligned or coherent with what the IETF does.

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

I think we do not enable compression of the signature as the security
implications are too hard to catch. When an reduced ICV is needed, there is
a need to define the transform. In your case rfc4106 seems to address your
concern with a 12 and even 8 byte ICV.

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

-- 
Daniel Migault
Ericsson