Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On Tue, 7 Jun 2022, Daniel Migault wrote: 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 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. The authors of RFC 4106 really did not want to have the different versions with different ICVs but were pressured into it. That is why RFC 8221 and RFC 8247 basically say: As the advantage of the shorter (and weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet ICVs remain at the MAY level. I don't think people saw the packet counter as fundamental in this. I think mostly the strenth of the ICV length itself mattered. Also, since I think Robert cares about FIPS for this, CNSA only allows the 16 byte ICV, see RFC 9206: https://datatracker.ietf.org/doc/html/rfc9206#section-5 So I think it is best if you would stick to the 16 bytes ICV here :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
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 wrote: > > > On 6/7/22 08:43, Daniel Migault wrote: > > > > On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz > 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,,,)? >> > >>
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On Mon, May 16, 2022 at 4:47 PM 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 > sure we can, but the transform itself is a bit outside EHC. > > 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... > > we are saying up to which likely corresponds to an extreme case and something like 18 bytes seems reasonable. > > 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. > > yes. if that is not in the doc, it might be we said it too many times that we finally forgot ;-). > 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"? > > currently not, but this is actually what we think we should do. > 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: > > no. whatever is used to describe the compression descripression will not be implemented by setting a compressor / decompressor for at least ESP software implementation. The changes are minor. On the other hand, things may be a bit more complex for hardware based ESP which cannot be modified. In that case, we probably need to implement the compression / decompression steps outside ESP. > 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? > > The context is per SA, so I suppos ethe suggestion is to make it per SA if that has not been clearly specified in the IKE extension document. > 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. > > We probably need to clarify this. It seems the baseline is pretty much any layer related to traffic selectors, which I think could theoretically be pretty high up in the layers though in practice this may be reduced to IP and transport. > 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? > could be. > > 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,,,)? > > probably > Layer 5 protocols SHOULD be via standard SCHC with the SCHC Rule ID > included... > > I tend to agree. > 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 > -- Daniel Migault Ericsson
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On 6/7/22 08:43, Daniel Migault wrote: On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz 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
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
On Tue, Jun 7, 2022 at 8:14 AM Robert Moskowitz 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 > >
Re: [IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
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
[IPsec] Comments: New Version Notification for draft-mglt-ipsecme-diet-esp-08
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
