On 6/7/22 08:43, Daniel Migault wrote:
On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz
<rgm-...@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.
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
> 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
_______________________________________________
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
