[IPsec] 答复: New Version Notification for draft-guo-ipsecme-ikev2-using-shangmi-00.txt
Hi Paul: Thanks for your advices and the comments for the draft! About your suggestion of ISE process, and the IPSecME WG "Expert Review", we will follow this existing way. For the comments corresponding to the CBC and GCM variant, please find my response as follows: For CBC variant, we keep it here because for IKEv2 and ESP (RFC 7296, RFC 3602), this encryption mode is still valid and not deprecated (see the reference https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5). In addition, the specification for the using of ShangMi in IPsec in China also keeps CBC mode. Considering backward compatibility and the above reasons, deprecating the CBC mode perhaps may be not a good choice in our draft. For GCM variant, currently, there may be no ghash hardware instructions which can be used directly by GCM variants, but we can use the multiplication instruction to speed up ghash. SM4 computation can also benifit from CPU instruction acceleration. I hope the above response can address your concern and any other comments are welcome any time. Thanks! B.R. Frank -邮件原件- 发件人: Paul Wouters 发送时间: 2024年3月11日 8:29 收件人: Xialiang(Frank, IP Security Standard) 抄送: ipsec@ietf.org; guoyanfei ; Yu Fu 主题: Re: [IPsec] New Version Notification for draft-guo-ipsecme-ikev2-using-shangmi-00.txt On Mon, 29 Jan 2024, Xialiang(Frank, IP Security Standard) wrote: > We have submitted this new draft “Using ShangMi in the Internet Key Exchange > Protocol Version 2 (IKEv2)”, which defines a set of cryptographic transforms > for using in the IKEv2 based on Chinese cryptographic standard algorithms > (called "ShangMi" or “SM” algorithms). > The SM algorithms are mandatory in China, so this document provides a > description of how to use the SM algorithms with IKEv2 and specifies a set of > cryptographic transforms so that implementers can produce interworking > implementations. Thanks for the document. I believe the best way forward for these would be via the ISE. In which case the Working Group and Intended Status would need to be updated. But if the document proceeds that way, please keep the IPsecME WG in the loop. All the registries involved are "Expert Review", so it can be registered regardless of where or how the specification is published. As for the draft itself, I have two questions. Is the CBC variant really neccessary? CBS is being made historic or deprecated for all other IETF uses (eg see TLS 1.3). Why introduce it now for IKEv2 and ESP in combination with ShangMi ? For the GCM variants, do you know if these can make use of the ghash hardware instructions? As in, would ENCR_SM4_GCM also benefit from CPU hardware instructions available? Regards, Paul > Your comments are warmly welcome! > > B.R. > Frank > > -邮件原件- > 发件人: internet-dra...@ietf.org > 发送时间: 2024年1月29日 14:09 > 收件人: Xialiang(Frank, IP Security Standard) > ; guoyanfei ; Yu Fu > > 主题: New Version Notification for > draft-guo-ipsecme-ikev2-using-shangmi-00.txt > > A new version of Internet-Draft > draft-guo-ipsecme-ikev2-using-shangmi-00.txt > has been successfully submitted by Liang Xia and posted to the IETF > repository. > > Name: draft-guo-ipsecme-ikev2-using-shangmi > Revision: 00 > Title:Using ShangMi in the Internet Key Exchange Protocol Version 2 > (IKEv2) > Date: 2024-01-29 > Group:Individual Submission > Pages:14 > URL: > https://www.ietf.org/archive/id/draft-guo-ipsecme-ikev2-using-shangmi-00.txt > Status: > https://datatracker.ietf.org/doc/draft-guo-ipsecme-ikev2-using-shangmi/ > HTMLized: > https://datatracker.ietf.org/doc/html/draft-guo-ipsecme-ikev2-using-sh > angmi > > > Abstract: > > This document defines a set of cryptographic transforms for using in > the Internet Key Exchange Protocol version 2 (IKEv2). The transforms > are based on Chinese cryptographic standard algorithms (called > "ShangMi" or “SM” algorithms). > > The use of these algorithms with IKEv2 is not endorsed by the IETF. > The SM algorithms are mandatory in China, so this document provides a > description of how to use the SM algorithms with IKEv2 and specifies > a set of cryptographic transforms so that implementers can produce > interworking implementations. > > > > The IETF Secretariat > > > ___ > 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] IETF 119 agenda items
If you have anything that you want to be included in the IETF 119 agenda, please send email to the IPsecME WG chairs (ipsecme-cha...@ietf.org) as soon as possible, as I will be making the final agenda tomorrow... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
On Mon, 11 Mar 2024, Panwei (William) wrote: Indeed, splitting the 32-bit SPI into two sub-fields, the VPN ID sub-field and SPI sub-field, may also be one option. This solution doesn't need to change the ESP packet format, but it also has some disadvantages. The first one is the scalable issue. 256 VPN IDs may be enough for use for current RAN Sharing scenario, but when considering the service slicing feature, thousands and even more VPNs will be needed in the future. So, it's better to assign 16 bits to the VPN ID sub-field. Therefore, the SPI sub-field will be trenched to 16 bits, which means the available SPIs are 64k. This can have a negative impact on the expansion of usable scenarios in the future. The second problem is the high possibility of packet disorder. Although all VPNs share one actual SA and the sender assigns sequence numbers in sequence to all the traffic no matter which VPN they belong to, different VPNs will use different SPIs in the ESP packets. This will interfere with the load balance process of the on-path routers because they usually look at the SPI field when doing the hash. This may lead to packet disorder at the IPsec receiver. Therefore, we currently still prefer a separate field representing the VPN ID. But we are open to more discussions and future changes. Thanks, those arguments are clear. Perhaps Steffen can take these into consideration as well when thinking about ESPv4 / WESP :) > The VPN ID could be done via notify instead of new traffic selector. Or > you could add a new traffic selector type of just the VPN ID instead of > copying and extending the existing v4/v6 types - similar to RFC 9478. We did consider this option before. A new notify or traffic selector type of just the VPN ID is also acceptable but has some disadvantages. When using the new notify or traffic selector type along with the existing traffic selectors of v4/v6 types, it will be impossible to differentiate which traffic selector of v4/v6 types is associated with which VPN. Therefore, all traffic selectors of v4/v6 types will be associated with each VPN, which may cause unwanted traffic to be included in the traffic selection result. When using the new notify or traffic selector type alone, it will allow all the traffic (from any to any) of one VPN to be selected, which will also cause unwanted traffic to be included. By considering this, our current design of copying and extending the existing v4/v6 types want to keep a more precious traffic selection. Indeed. That is also the reasoning for the Labeled IPsec traffic selector types. You could use those too, nothing prevents you from filling the label with simple 16 bit numbers :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Hi Paul, Thanks for your quick comments. But I'm sorry for the late response due to I was out of the office for a few days. > I can see how you want an extra SPD selector for the VPN ID - but > maybe call it Namespace ID or something else as VPN ID is confusing. Thanks for pointing out this, we'll change it to a better name in the next version. > Your gateway that needs to support say 256 VPN IDs could split up its > SPI range so it can detect which VPN to send it to based on SPI range ? > That would need no ESP changes. In linux terms that would mean you > “mark” the skbuf with the VPN ID to steer it into the right place > before/after decrypting / encrypting. > In Linux you could also use the “labeled IPsec” to label the packet with > the VPN ID. > It would require you keep track of the SPI bundle of the SA, but again in > Linux terms you could use marking of packets based on keeping a list of > peer SPIs per VPN ID. Indeed, splitting the 32-bit SPI into two sub-fields, the VPN ID sub-field and SPI sub-field, may also be one option. This solution doesn't need to change the ESP packet format, but it also has some disadvantages. The first one is the scalable issue. 256 VPN IDs may be enough for use for current RAN Sharing scenario, but when considering the service slicing feature, thousands and even more VPNs will be needed in the future. So, it's better to assign 16 bits to the VPN ID sub-field. Therefore, the SPI sub-field will be trenched to 16 bits, which means the available SPIs are 64k. This can have a negative impact on the expansion of usable scenarios in the future. The second problem is the high possibility of packet disorder. Although all VPNs share one actual SA and the sender assigns sequence numbers in sequence to all the traffic no matter which VPN they belong to, different VPNs will use different SPIs in the ESP packets. This will interfere with the load balance process of the on-path routers because they usually look at the SPI field when doing the hash. This may lead to packet disorder at the IPsec receiver. Therefore, we currently still prefer a separate field representing the VPN ID. But we are open to more discussions and future changes. > Usually, hardware offload and queueing looks at some (hash of) IP > properties (eg port numbers or SPI). This might interfere but since you > have many tunnels that might not matter? I think this will matter because on-path routers will look into the SPI field and one possible result is packet disorder at the IPsec receiver. > The VPN ID could be done via notify instead of new traffic selector. Or > you could add a new traffic selector type of just the VPN ID instead of > copying and extending the existing v4/v6 types - similar to RFC 9478. We did consider this option before. A new notify or traffic selector type of just the VPN ID is also acceptable but has some disadvantages. When using the new notify or traffic selector type along with the existing traffic selectors of v4/v6 types, it will be impossible to differentiate which traffic selector of v4/v6 types is associated with which VPN. Therefore, all traffic selectors of v4/v6 types will be associated with each VPN, which may cause unwanted traffic to be included in the traffic selection result. When using the new notify or traffic selector type alone, it will allow all the traffic (from any to any) of one VPN to be selected, which will also cause unwanted traffic to be included. By considering this, our current design of copying and extending the existing v4/v6 types want to keep a more precious traffic selection. Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
