Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote: I don't know 10,000 or 20,000 users trying to connect to a VPN server around the same time where each pair is 300 kilobytes or more would have a noticeable impact or not. It depends on many factors I think. One of the factors is how the server stores those data for its computations. Let's say each pair is a 0.5 megabyte, 20,000 users would be around 10G of memory/storage. So, the over all performance impact could be noticeable once in a while for some VPN network. If you need that much memory to keep state, I don't think it matters exactly how you receive and send that using IKEv2? Perhaps some post quantum algorithms are better in that you dont have to keep so much state during the exchange? And that could be a reason to favour those. But you are far more qualified to judge that, than I am. The intermediate exchange allows you to have many additional round trips if that helps you reduce CPU or memory use. So I think from an IKEv2 point of view, that is all the scaffolding we need to provide. When the new algorithms appear, we can go and implement those in a new RFC, using the intermediate exchange. I think Valery also had some ideas on how in the future, we could avoid doing a hybrid key exchange with a classic DH that just costs CPU and no longer gets us any security. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi Paul, I don't know 10,000 or 20,000 users trying to connect to a VPN server around the same time where each pair is 300 kilobytes or more would have a noticeable impact or not. It depends on many factors I think. One of the factors is how the server stores those data for its computations. Let's say each pair is a 0.5 megabyte, 20,000 users would be around 10G of memory/storage. So, the over all performance impact could be noticeable once in a while for some VPN network. Quynh. From: Paul Wouters Sent: Thursday, June 18, 2020 12:23 PM To: Dang, Quynh H. (Fed) Cc: Scott Fluhrer (sfluhrer) ; Panos Kampanakis (pkampana) ; Valery Smyslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote: > Hi Panos and Scott, > > That was exactly what I was thinking. We have been working remotely. > > One could have more than 300 kbytes for a pair of (public key + ciphertext > and public key + sig). The latter public key may be replaced by a > cert chain. > > The impact varies from one situation to another I think. > Speaking as a previous IPsec implementor, the biggest concern I had over IKE > performance was in the ‘flash crowd’ scenario; that is, you’re an > IPsec-based security gateway, and then suddenly everyone wanted to negotiate > with you. This can happen if it’s 8:00 AM (and everyone just > arrived at work), or if you’re a back-up gateway, and then the primary > gateway just failed. We have RFC 5685 REDIRECT for that. If your server becomes too busy, it can redirect new or existing clients to another gateway, provided that other gateway will authenticate itself identically to this gateway. I don't think the key sizes really matter here. Even if computation is 2x or 3x more CPU intensively, from an "overloaded server" point of view that just means like "redirect if at 3000 clients" vs "redirect if at 2000 clients". Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
On Thu, 18 Jun 2020, Dang, Quynh H. (Fed) wrote: Hi Panos and Scott, That was exactly what I was thinking. We have been working remotely. One could have more than 300 kbytes for a pair of (public key + ciphertext and public key + sig). The latter public key may be replaced by a cert chain. The impact varies from one situation to another I think. Speaking as a previous IPsec implementor, the biggest concern I had over IKE performance was in the ‘flash crowd’ scenario; that is, you’re an IPsec-based security gateway, and then suddenly everyone wanted to negotiate with you. This can happen if it’s 8:00 AM (and everyone just arrived at work), or if you’re a back-up gateway, and then the primary gateway just failed. We have RFC 5685 REDIRECT for that. If your server becomes too busy, it can redirect new or existing clients to another gateway, provided that other gateway will authenticate itself identically to this gateway. I don't think the key sizes really matter here. Even if computation is 2x or 3x more CPU intensively, from an "overloaded server" point of view that just means like "redirect if at 3000 clients" vs "redirect if at 2000 clients". Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
On Thu, 18 Jun 2020, Panos Kampanakis (pkampana) wrote: > I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). For libreswan, we recently went through performance enhancements, and we found a number of issues in our code that once meassured, were easilly fixed. There are still some linear lookups left in the Linux kernel for policies/states, but we found that with about 1000 users that keep connecting/disconnecting, it wasn't a big problem yet. Hopefully, more clients will use Session Resumption, which would at least cut out the (EC)DiffieHellman part of starting a session again, but on larger servers with that many clients, there tends to not be a guaranteed you can connect to the same server which can resume your session. Also, I'm not sure if we need to further postquantum prood the resumption mechanism (I don't think so, but I'm not a licensed cryptographer) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi Panos and Scott, That was exactly what I was thinking. We have been working remotely. One could have more than 300 kbytes for a pair of (public key + ciphertext and public key + sig). The latter public key may be replaced by a cert chain. The impact varies from one situation to another I think. Regards, Quynh. From: Scott Fluhrer (sfluhrer) Sent: Thursday, June 18, 2020 9:51 AM To: Panos Kampanakis (pkampana) ; Dang, Quynh H. (Fed) ; Valery Smyslov ; 'ipsecme mailing list' Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Speaking as a previous IPsec implementor, the biggest concern I had over IKE performance was in the ‘flash crowd’ scenario; that is, you’re an IPsec-based security gateway, and then suddenly everyone wanted to negotiate with you. This can happen if it’s 8:00 AM (and everyone just arrived at work), or if you’re a back-up gateway, and then the primary gateway just failed. That scenario requires a rather lot of care to avoid “congestion”, that is, where you’re so busy answering IKE messages that you don’t get enough time to complete any exchange before the IKE exchange times out. What you end up doing is effectively triage; deliberately ignore some exchanges for the moment so that you can complete others. Now, if you have large key shares, what that would add to the scenario is memory management; while processing the requests, you need to buffer the received key shares, and so part of your triage needs to worry about memory consumption in addition to the computational costs. It’s not clear what complexity it would add; I would certainly be concerned if I were still an IPsec implementor… From: IPsec On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 18, 2020 9:32 AM To: Dang, Quynh H. (Fed) ; Valery Smyslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quynh, > An obvious question is that what is the performance impact from this large > KEM using the approaches above when compared with a KEM (if its public key > and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq > signature algorithm has a small signature and a small public key) which would > work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays > up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server > ? > An obvious question is that what is the performance impact from this large > KEM using the approaches above when compared with a KEM (if its public key > and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq > signature algorithm has a small signature and a small public key) which would > work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays > up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server > ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2020%2F071&data=02%7C01%7Cquynh.dang%40nist.gov%7Ceb7f6d52110c4f293c6808d8138ecbb1%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637280851313023652&sdata=EB%2FUKHDskWiXpwz%2BamJIGcgp1820OOixHgxWx7s5EII%3D&reserved=0>. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov mailto:smyslov.i...@gmail.com>>; 'ipsecme mailing list' mailto:ipsec@ietf.org>> Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thank you Valery and thank you everyone who responded to me. The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ipsecme-ikev2-multiple-ke-00%23section-1.1&data=02%7C01%7Cquynh.dang%40nist.gov%7Ceb7f6d52110c4f29
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Speaking as a previous IPsec implementor, the biggest concern I had over IKE performance was in the 'flash crowd' scenario; that is, you're an IPsec-based security gateway, and then suddenly everyone wanted to negotiate with you. This can happen if it's 8:00 AM (and everyone just arrived at work), or if you're a back-up gateway, and then the primary gateway just failed. That scenario requires a rather lot of care to avoid "congestion", that is, where you're so busy answering IKE messages that you don't get enough time to complete any exchange before the IKE exchange times out. What you end up doing is effectively triage; deliberately ignore some exchanges for the moment so that you can complete others. Now, if you have large key shares, what that would add to the scenario is memory management; while processing the requests, you need to buffer the received key shares, and so part of your triage needs to worry about memory consumption in addition to the computational costs. It's not clear what complexity it would add; I would certainly be concerned if I were still an IPsec implementor... From: IPsec On Behalf Of Panos Kampanakis (pkampana) Sent: Thursday, June 18, 2020 9:32 AM To: Dang, Quynh H. (Fed) ; Valery Smyslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quynh, > An obvious question is that what is the performance impact from this large > KEM using the approaches above when compared with a KEM (if its public key > and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq > signature algorithm has a small signature and a small public key) which would > work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays > up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server > ? > An obvious question is that what is the performance impact from this large > KEM using the approaches above when compared with a KEM (if its public key > and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq > signature algorithm has a small signature and a small public key) which would > work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays > up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server > ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov mailto:smyslov.i...@gmail.com>>; 'ipsecme mailing list' mailto:ipsec@ietf.org>> Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thank you Valery and thank you everyone who responded to me. The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1 and https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good to me. It looks like if/when someone implements them and adds a large key and/or ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing implementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exchange, it contains a public key and a ciphertext) because I don't see any mentioning of the maximum IKEv2 message size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of some PQ KEM and signature algorithms and would like to use them in normal IKEv2 without the 2 methods above. In that situation, if the KEM has large public key and/or ciphtertext would have the IP fragmentation and packet drop issues. So, this KEM should use the approaches in the drafts above to deal with these issues. An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext a
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi Quynh, > An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server ? > An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ? > I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? > Would there be some noticeable impact on a high-volume connections VPN server ? We tested this in the context of TLS in https://eprint.iacr.org/2020/071. For a tunnel that stays up for a long time (not just a few seconds like HTTPS) and sends Megabytes of data or more, then the larger key+signatures size are amortized over the tunnel data. What becomes more important then is the keygen, encap, decap, sign/verify time. In other words, servers that terminate a lot of connections at the same time will be impacted by slower operations in the handshake (the server throughput drops), but their tunnels that send a few more kilobytes of handshake data and magnitudes more over the tunnel are not significantly affected especially if we are talking about UDP and not TCP (with congestion control slowing down the handshake). From: IPsec On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 12:37 PM To: Valery Smyslov ; 'ipsecme mailing list' Subject: Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Thank you Valery and thank you everyone who responded to me. The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section- 1.1 and https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good to me. It looks like if/when someone implements them and adds a large key and/or ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing implementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exchange, it contains a public key and a ciphertext) because I don't see any mentioning of the maximum IKEv2 message size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of some PQ KEM and signature algorithms and would like to use them in normal IKEv2 without the 2 methods above. In that situation, if the KEM has large public key and/or ciphtertext would have the IP fragmentation and packet drop issues. So, this KEM should use the approaches in the drafts above to deal with these issues. An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN server ? Regards, Quynh. <https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04> draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKEv2 Protocol This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE ... tools.ietf.org _ From: Valery Smyslov mailto:smyslov.i...@gmail.com> > Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) mailto:quynh.d...@nist.gov> >; 'ipsecme mailing list' mailto:ipsec@ietf.org> > Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quinh, please look at the draft-ietf-ipsecme-ikev2-multiple-ke-00. It specifically addresses your concern about large public keys of PQ KE methods. Actually, it's generally OK to have public keys/signatures up to 64Kbytes.
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi Quynh, Thank you Valery and thank you everyone who responded to me. The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1 and https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good to me. Note, that this is essentially the same approach - draft-multiple-ke is based on draft-ikev2-intermediate and only clarifies its usage for the particular case of KE methods with large public keys (and combining several KE too). It looks like if/when someone implements them and adds a large key and/or ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing implementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exchange, it contains a public key and a ciphertext) because I don't see any mentioning of the maximum IKEv2 message size (it is an implementation specific issue). There are already few implementations and they even had an interop last November. And you are right that the maximum IKEv2 message size is implementation dependent (in any case it is limited to 64 Kbytes). Let's say after 10 or 15 years from now, the group trusts the security of some PQ KEM and signature algorithms and would like to use them in normal IKEv2 without the 2 methods above. In that situation, if the KEM has large public key and/or ciphtertext would have the IP fragmentation and packet drop issues. So, this KEM should use the approaches in the drafts above to deal with these issues. These drafts were specifically written to address these issues. An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN server ? I think it depends on many factors. You are right that generally IPsec tunnels are relatively long lived. We also have an SA resumption mechanism (RFC 5723) that allows to quickly restore SA. But of course for the SA establishment we'll do have a penalty of performing more exchanges, and more data to transfer... Regards, Valery. Regards, Quynh. <https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04> draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKEv2 Protocol This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE ... tools.ietf.org _ From: Valery Smyslov Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) ; 'ipsecme mailing list' Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quinh, please look at the draft-ietf-ipsecme-ikev2-multiple-ke-00. It specifically addresses your concern about large public keys of PQ KE methods. Actually, it's generally OK to have public keys/signatures up to 64Kbytes. If you need to deal with larger keys, then some update of the specs is needed. Regards, Valery. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 4:49 PM To: ipsecme mailing list Subject: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi everyone, I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations. The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit. As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes. My guess is that some updates to the spec and/or implementations would make them work. Your data points and discussions are appreciated. Regards, Quynh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Thank you Valery and thank you everyone who responded to me. The approaches in the drafts https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-00#section-1.1 and https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04 look good to me. It looks like if/when someone implements them and adds a large key and/or ciphertext KEM, the maximum IKEv2 message size must be adjusted if the existing implementation does not already support the corresponding message size with the new KEM ( for an ephemeral key exchange, it contains a public key and a ciphertext) because I don't see any mentioning of the maximum IKEv2 message size (it is an implementation specific issue). Let's say after 10 or 15 years from now, the group trusts the security of some PQ KEM and signature algorithms and would like to use them in normal IKEv2 without the 2 methods above. In that situation, if the KEM has large public key and/or ciphtertext would have the IP fragmentation and packet drop issues. So, this KEM should use the approaches in the drafts above to deal with these issues. An obvious question is that what is the performance impact from this large KEM using the approaches above when compared with a KEM (if its public key and ciphertext are around 1,400-1,600 bytes in total) (assuming a pq signature algorithm has a small signature and a small public key) which would work well in a normal IKEv2's implementation ? I guess the impact is small generally because an IPsec tunnel normally stays up for a long time. Does my guess seem ok here ? Would there be some noticeable impact on a high-volume connections VPN server ? Regards, Quynh. draft-ietf-ipsecme-ikev2-intermediate-04 - Intermediate Exchange in the IKEv2 Protocol<https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-04> This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE ... tools.ietf.org From: Valery Smyslov Sent: Wednesday, June 17, 2020 9:57 AM To: Dang, Quynh H. (Fed) ; 'ipsecme mailing list' Subject: RE: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi Quinh, please look at the draft-ietf-ipsecme-ikev2-multiple-ke-00. It specifically addresses your concern about large public keys of PQ KE methods. Actually, it’s generally OK to have public keys/signatures up to 64Kbytes.. If you need to deal with larger keys, then some update of the specs is needed. Regards, Valery. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 4:49 PM To: ipsecme mailing list Subject: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi everyone, I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations. The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit. As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes. My guess is that some updates to the spec and/or implementations would make them work. Your data points and discussions are appreciated. Regards, Quynh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi Quinh, please look at the draft-ietf-ipsecme-ikev2-multiple-ke-00. It specifically addresses your concern about large public keys of PQ KE methods. Actually, it's generally OK to have public keys/signatures up to 64Kbytes. If you need to deal with larger keys, then some update of the specs is needed. Regards, Valery. From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Dang, Quynh H. (Fed) Sent: Wednesday, June 17, 2020 4:49 PM To: ipsecme mailing list Subject: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ? Hi everyone, I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations. The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit. As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes. My guess is that some updates to the spec and/or implementations would make them work. Your data points and discussions are appreciated. Regards, Quynh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
On Wed, 17 Jun 2020, Dang, Quynh H. (Fed) wrote: I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations. The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit. As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes. My guess is that some updates to the spec and/or implementations would make them work. Your data points and discussions are appreciated. https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Maximum sizes of IKEv2 messages and UDP messages ?
Hi everyone, I am interested in knowing what are typical maximum sizes for IKEv2 messages and UDP messages in implementations. The reason is that the IKEv2's spec has a must and a should being 1280 and 3000 bytes respectively for IKEv2 messages, but does not have a maximum limit. As you know some of the post quantum cryptographic candidates in our standardization process have large or very large public key , signature and/or ciphertext sizes. My guess is that some updates to the spec and/or implementations would make them work. Your data points and discussions are appreciated. Regards, Quynh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
