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