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

[Daniel Migault <[e-mail]>]

Yes, that what I then realized while reading the first email. At that point
a document is needed wich could be pretty straight forward I believe.

Yours,
Daniel

On Tue, Jun 7, 2022 at 8:50 AM Robert Moskowitz <[e-mail]>
wrote:

>
>
> On 6/7/22 08:43, Daniel Migault wrote:
>
>
>
> On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz <[e-mail]>
> 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.
>
>
> I was not clear.  A 8750 IIV-AES-GCM-12 cipher...
>
>
>
>
>
>
>>
>> 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
>>
>> _______________________________________________
>> IPsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>
> --
> Daniel Migault
> Ericsson
>
> _______________________________________________
> IPsec mailing [e-mail]://www.ietf.org/mailman/listinfo/ipsec
>
>
>

-- 
Daniel Migault
Ericsson