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