Session Date/Time: 19 Mar 2026 03:30
Tero Kivinen: All right, seems to be 11:30 now. So let's start. This is IPsecME meeting. I'm Tero Kivinen, I'm a co-chair. Yoav is in the online also. You can say hi.
Yoav Nir: Hello.
Tero Kivinen: All right. So this is the Note Well. You have been seeing this already and you can scan the QR code and read the actual text in there before. All right. And we have one note taker. It would be better if people who could also help writing minutes into the—just questions and answers especially. People who make the questions or answers to them. Actually if they would actually go and check out that their questions and answers are, you know, properly written there, it would be very useful. All right. So we have very packed agenda. So we will see how far we should be able to get through everything, I hope, but we will see. All right. So we start with the working group status. So we actually published three new RFCs since the last time. So we have renaming the Extended Sequence Numbers transfer type in IKEv2, and we have a group key management using IKEv2, and then we have mixed pre-shared keys in IKE intermediate and CREATE_CHILD_SA of IKEv2. So and we have nothing in the RFC editor queue anymore. We don't have anything in the publication requested, but that should be changing very soon. We have—I think we have at least two drafts should be going there, you know, after we get the shepherd write-ups and so on done. All right. So there is draft-ietf-ipsecme-ikev2-pqc-auth and draft-ietf-ipsecme-ikev2-mlkem. And I think Scott is already written the one of the shepherd write-ups. I don't know have we posted it yet or what's the current status with that. We have three that are last call done: the draft-ietf-ipsecme-ikev2-downgrade-prevention and I think that's I will also go to the publication requested very soon. The draft-ietf-ipsecme-diet-esp and draft-ietf-ipsecme-ikev2-diet-esp-extension have been in last call or last call done state for a very long time. Hopefully we can get them forward at some point. They have been waiting all kind of other things going on and you know, so on. So they're not really waiting for us, it's waiting for, you know, the other parts of the, you know, whether we actually, you know—there were some discussion on the transport area and so on. So and currently we don't have anything that is working group last call or actually even asked to be like in the working group last call now, or if there is, I don't actually remember it. All right. Comment from Tirumaleswar Reddy. Go ahead.
Tirumaleswar Reddy: Hey, hey, good morning. The draft-ietf-ipsecme-ikev2-pqc-auth draft has been in write-up for almost four months now. I was wondering if you could help accelerate that.
Tero Kivinen: The pqc-auth, yes. That's in my list of to be done, you know, after this meeting.
Tirumaleswar Reddy: Thank you. Thank you so much.
Tero Kivinen: All right. So we have lots of drafts that are in the working process. We have draft-ietf-ipsecme-hybrid-kem-ikev2-frodo, we have draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt which I think was waiting one of the other drafts was the draft-ietf-ipsecme-ikev2-prf-plus if I remember correctly. We have draft-ietf-ipsecme-ikev2-reliable-transport. We have draft-ietf-ipsecme-ikev2-beet-mode. We have draft-ietf-ipsecme-eesp and draft-ietf-ipsecme-eesp-ikev2. We have draft-ietf-ipsecme-esp-ping and draft-ietf-ipsecme-encrypted-esp-ping which has been completely silent since the last IETF if I remember correctly. We have draft-ietf-ipsecme-ikev2-prf-plus and draft-ietf-ipsecme-sha3. And we haven't been seeing that much of discussion on those in the mailing list. The draft-ietf-ipsecme-eesp they sent an update just, you know, before the IETF. But of course on that, I would actually rather also have, you know, some implementation results before we actually get—because it's a big change and I would actually rather hope to see some that they are actually be able to get some benefits from it before we actually go and make a completely new ESP. But so there is one more draft which is the draft-ietf-ipsecme-ikev2-reliable-transport at the same time with the draft-ietf-ipsecme-ikev2-beet-mode. draft-ietf-ipsecme-ikev2-beet-mode of IKEv2 is the negotiation in IKE but there is also, you know, the actual ESP parts of that, which is going to be separate draft and we are looking at that in the end if we have time. All right. So let's go to the presentation. So first one is the post-quantum hybrid KEM with IKEv2 with FrodoKEM. So I'll give slides to this one. Here, you should be able to use that. One more.
Guilin Han: Okay, so I'll—go to the close to the mic at—or turn the mic—make sure the mic is, you know, you're talking to the mic. Is it on? It's fine. Okay. Yeah. Okay, so I'm happy to give a presentation for Frodo in IKEv2. Yeah, so here's the basic information for draft-ietf-ipsecme-hybrid-kem-ikev2-frodo. Okay. Yeah, I think some experts already know what we are going to do for this one, so I won't repeat. Thanks for the group adoption. It's done by the beginning of February. So basically we have received about the 20 experts for the support from 20 experts as I understanding, no opposition. Yeah, so a number of comments received and then we try to reply and revise our document as the 00 version for working group documents. Yeah, so next I will give this kind of the short summary what we have done to respond all of these comments. Okay, the first one is the running pure FrodoKEM. We explicitly say how we can do this one. So we add a new paragraph in section one to explain this. Next one is for PPK, post-quantum pre-shared key plus FrodoKEM. So it is can be also run this way as a one kind of the possibility for hybrid KEM. Yeah, so we also add a one small paragraph in section 5.2 for this reason. A more consideration is about security. For security, we thanks for the experts give our comments and remind maybe we can align the security discussion with the hybrid ML-KEM draft, which is going on a last call. Yeah, soon maybe I say. Yeah, so we discussed a few issues together with the forward secrecy or forward security. Yeah, so we largely extend our security discussion in section six. Yeah, so a number of issues there. Yeah, like we mentioned, okay, about the ciphertexts, about the randomness. Basically it should be required randomness for different crypto procedures there should be independent from each other. This is important. Yeah, it's mentioned here in a very good for engineer themselves. Yeah. So we also mentioned, okay, how to prevent the downgrade attacks, because downgrade attack is the draft is already adopted as well. Next about the recipient test. For this one, we checked both specification for ISO and also for IETF draft, Frodo algorithm I mean, but we did not found any specific information about the recipient test. Yeah, so currently we just add a special subsection to mention this. Yeah, for it is—at this moment, we may don't need the recipient test for either ciphertexts or the public key. But we are also aligning with the authors of the CFRG draft authors, to check if we should add any further information in future. Yeah, so also have some question about explanation of fragmentation. But this one we have discussion and even have some proposed text. But finally we decided not put it now, because we believe currently we actually explained this issue in our draft together with actually we cited the normative reference both the RFC 9242 and the RFC 9370. So we hope it's enough. Yeah, so all of you, yeah, are welcome to have a check our document and give your opinion as well. Yeah, another thing is about the title and hybrid meaning, because in my understanding the hybrid could be quite general one. Yeah, if we specifically refer to a particular scheme, we will cite the document. Yeah, so in that case, another thing is about title. Title actually currently suggest three of them. Yeah, but we still would like to keep the current one, because the hybrid it is highlighted the post-quantum, highlighted the hybrid. Yeah, other two, yeah, may considered but still I replied in the mailing list maybe not that good, but we still open to accept suggestions. And a normative reference, yeah, we switched the ISO document and the CFRG document as suggest. Yeah, and slim down the background about the necessary to do PQ migration. So we did this one. Yeah, just cut three original paragraph in our version 03. So we also did quite a number of editorial comments, yeah, for the whole document. Especially some IETF keywords, we may don't use it that right. Yeah, thanks a lot for the comments from Scott and Tom. Yeah, that's all. I think in the—in the appendix, we gave the detail comments and our reply and action we have done. Yeah, most of draft I think we already addressed quite completely. Some a few maybe need to a little further attention. Yeah, that's all I think. Yeah, thanks. So we hope you get your further review and if any issue we may have to address before considering, yeah, working group last call. Yeah, thanks.
Tero Kivinen: This is Tero Kivinen. So one of the things I think we should be aligning this and ML-KEM draft to be about the same because they are actually about the same. They are defining how we put the post-quantum algorithm inside the key exchange payload. And that's almost all they that they actually need to be. They don't need to go to any of the background of the quantum already, they can mention that yeah, there's an issue with fragmentation, there is, you know, we can use this multiple key—you can actually use it in the initial exchange if you want, you can do whatever, but those are also always, you know, just it should be very short, we should be the most of the stuff to be just describe how to put it in there. And I would really like to have this to be aligned with the ML-KEM that they would be about the same kind of, you know, thing. Okay, thanks. And that's also I think the, you know, the draft name should be about the same would be—ML-KEM is just to saying we have an, you know, this for IKEv2 and I think this should be just FrodoKEM for IKEv2 or something like that. It doesn't need to mention any of the other things. Okay, thank you.
Tirumaleswar Reddy: Yeah. Yeah, I had a similar comment that both the ML-KEM and this draft have lot of similarities with regard to fragmentation and various other issues. So it would be good to either add them in one document so that the other document refers them to avoid duplication. And the second comment was ML-KEM doesn't have any dependency, right? I mean it's already a FIPS document so I think they can progress but this has a dependency on FrodoKEM in CFRG. I don't think it's adopted yet. So how do we plan to progress this right? I mean, are we going to push CFRG to adopt that or like—
Guilin Han: Yeah, about the reliable transportation or run actually pure Frodo, yeah, so we have a new paragraph already. But for the dependence on the CFRG draft, yeah, we may consider later. Yeah, we will align with the author there. Yeah, thank you.
Tirumaleswar Reddy: But I don't think we can—it's question back to the chairs. I thought my understanding was unless CFRG adopts this and progresses that to become an RFC or we can go in parallel and publish this?
Tero Kivinen: So I think we can also if I mean—we can have informational references to the CFRG draft that you know, and that we can still publish it even if it's a draft. But if it's a normative reference then we have to have wait for that one. But also I think the normative draft in—I don't know how much of the normative reference is into the CFRG draft or is to the actual, you know, FrodoKEM, you know, specification which I think is also published in some papers or something like that that we could actually probably use as a reference also.
Guilin Han: Currently we still select the CFRG draft as the normative reference in our draft as suggest in the—
Tero Kivinen: Yeah. Yeah, I think I think it's good for now. But I mean that's one of the things that if we—if they—if the CFRG are not going forward with the draft then then we might actually want to, you know, change the normative reference to be actually FrodoKEM.
Guilin Han: On the other side actually ISO standard, I had ISO standard for FrodoKEM will be published soon, maybe in a few months.
Tero Kivinen: All right. Scott, please.
Scott Fluhrer: Okay. I believe that because it depends so heavily on FrodoKEM, you cannot have a informational reference to that. It needs to be normative. If you point to the CFRG doc, that's—you'll have to wait until—publication will have to wait until that's actually published. I don't know what the IETF view is on ISO docs.
Tero Kivinen: All right. So but we talk about that later. We just get that draft ready anyway now and through the last working group last call and that kind of thing. So we can actually solve the references issues later. Deb has some comments also.
Deb Cooley: Well, you have to solve the reference issues before you pass it to me, right? That CFRG draft is unadopted. It's an individual draft in CFRG. They would have to adopt it and it would have to progress. Because you can't do it—
Tirumaleswar Reddy: Deb, I have something else to add as well, right? So what is happening in the LAMPS working group is the FrodoKEM drafts were proposed for both certificates and CMS messages. And then the chair said that they won't adopt it till—till the CFRG adopts the FrodoKEM document, right? So I think probably some guidance from the AD would be helpful for all the working groups which are working on these kind of non-NIST standardized PQC algorithms.
Deb Cooley: So the charters are different between IPsecME and LAMPS. LAMPS clearly says in its charter that it has to be either a NIST specification or a CFRG specification. IPsec doesn't say that in its charter, so it's a little more open. On the other hand, FrodoKEM, you have to find a reference to FrodoKEM that's not either paywalled or unfinished. Right? Because you need a normative reference to FrodoKEM that's stable and not behind a paywall.
Tero Kivinen: But anyway, I think let's bring that back to the—to the list because we are running out of the time anyway unless you have a very short comment on.
Scott Fluhrer: Maybe the chairs should talk to the CFRG chairs.
Tero Kivinen: I can do that. I actually think it's probably going to be wider discussion about that. All right. So we talk to the CFRG chairs pretty often. We have not done it this time. I can add this to the list of things to talk to them about if you want me. Okay. So this was still—All right. So the next one is Valery. KEM-based Authentication in IKEv2. Hello. Can you hear me? Can you hear me now? Okay. This is a draft that was presented in the last IETF. It was still—it was published a new version. So first a few words about motivation. So usually with post-quantum crypto, KEM at least for ML-KEM, ML-KEM data is much smaller than ML-DSA. ML-KEM also demonstrate better performance. So it is a good reason to introduce KEM-based authentication because there was a long history of such work starting from MQV, HMQV, and IKEv1 we also have had public key encryption authentication mode. There are also a couple of works individual draft in TLS that deal with KEM-based authentication. So this draft tries to introduce KEM-based authentication for IKEv2. So the outline is the peer perform first ephemeral hybrid key exchange and then also exchange their long-term KEM public keys, public certificates certifying the KEM public keys. Peers perform two exchanges with these using these certificates and then proof that they know shared secret generated from this ephemeral key exchange and steered with this long-term key exchanges from certificates. So in IKEv2 we try to reuse the existing feature that we already have. So the ephemeral key exchange can be based on RFC 9370 multiple key exchanges. So we also can reuse hash and URL for retrieving large certificate if they reside somewhere outside and are publicly available. So we also use IKE_INTERMEDIATE exchange for confirming authentication. So it's all—all existing feature. And we also rely on downgrade prevention because it's highly recommended for protecting against downgrades. And so what's new in 03 version? So we were pointed out by some reviewers that the current draft doesn't protect initiator and responder identities against active attacks at all because certificates were exchanged before any operation on them are performed, using them are performed. So the active attacker can see both of them and know identity for both parties. So it's generally—it's generally not possible to protect both identities against active attacker because one of the peers should reveal its identity first. But it's possible to protect at least one identity. So this draft was challenged to add this feature and it requires some redesign of the protocol. So for this reason we added a new payload, it's called encrypted certificate payload, ESERT. And a new certificate encoding that is just X.509 bundle. X.509 bundle was designed in—was defined in IKEv2 RFC 7296, but it was only used for hash and URL, hash and URL bundle. But now it can be used inside IKEv2. So the exchange. So first IKE_SA_INIT. Then we perform IKE_INTERMEDIATE confirming—proceeding with hybrid key exchange and perhaps with some other purposes for example post-quantum key exchange as defined in RFC 9370. Then we perform IKE_INTERMEDIATE that is concerned with the KEM—KEM protocol itself. How—how it is called. So first responder sends its certificate first and then initiator sends its certificates encrypted using the key that—that is produced using responder's certificates so that only responder can decrypt initiator certificate. So this case we provide protection against active attacker. So and IKE_AUTH just complete the authentication. So session key are computed as in previous draft, no change here. We slightly change authentication, so we get return AUTH_KEM_DATA instead introduced AUTH_KEM_CIPHERTEXT and AUTH_KEM_SSCON. Role of SSCON was explained before. So just to save time I will not—I will not repeat its role. So it is needed to—to protect against misconfiguration when for some reason private and public key are not corresponded to each other. Since we immediately steer shared key into the session key for IKE_AUTH, in this case of misconfiguration we will get garbage all decryption. So AUTH payload it was explained before. IKE_AUTH announce method that encrypted—encrypted certificate payload. So it's just resembles an encrypted payload but inside instead of another IKE payloads it's certificates, content of one or several certificates that are formed in the X.509 bundle. So we need to have only one encrypted certificate payload, it's easier to encrypt one payload instead of several payload, that's the reason to introduce it. So it's the bundle encoding taken from IKEv2 RFC. Security properties I will not repeat it. So it's very interesting about protocol optimization. So currently we need to have two additional IKE_INTERMEDIATE exchange for AUTH_KEM. And the idea is that we can get—we can get rid one of these additional exchanges with some complication of the protocol. And so what is the idea? The idea is that we send ESERT responder ESERT certificate in the ESERT payload in previous IKE_INTERMEDIATE exchange. In this case it will not be protected with session key generated from ephemeral intermediate exchange ephemeral hybrid key exchange. It is not good. So we can complicate it a little bit more. So we can still send encrypt this certificate responder certificate in new ESERT payload and encrypt it with the key that will be generated for the next exchange. It is still possible for responder to already know this key, it just don't use it yet. So in this case we will have all the security properties from the base protocol but we will remove one intermediate key exchange. So only one additional round trip for KEM-based authentication. So I believe it's doable but the question is whether it is worth to—it's a little bit complicated but still doable. So I believe I'm a little bit over. So comments and perhaps consider adoption.
Tero Kivinen: Yeah, I think we probably need to check it out on the list that working group should be able to adopt this document I think it's—I don't see any reason for not and I don't see anybody coming up and say we shouldn't be. And of course they can bring it up in the adoption call. All right. I think you have the next presentation also.
Valery Smyslov: Yes. Just go forward a bit next slides. Oh, it's me. Okay. Sorry.
Scott Fluhrer: All right. Okay, because for adoption, I would ask questions whether or not the performance gains would be sufficient to justify the additional complexity that this adds. My opinion is it doesn't look like it, but I think that's also something that the working group would need to consider.
Valery Smyslov: Yes, it must be—it should be evaluated. But I also want to point out that there are slightly different security properties that can be very attractive for somebody. For example in this protocol it is responder who reveals its identity first instead of initiator. So it protects initiator's privacy. And another interesting security properties is the complete repudiation. So both party can regenerate all the transcript so nobody can proof the third party that communication have taken place. So it's slightly different. Perhaps it is attractive for somebody besides of performance. So thank you. So use of IKE fragmentation for large messages. So what is large? Well, when IKE fragmentation was being developed we thought that 3KB messages are large messages because they cause IP fragmentation. IKE fragmentation was developed for messages of that size and we believe that it handles them very well. So perhaps 20 or 30 or 60KB are large messages like some post-quantum signatures like SLH signature for example. Well, those signatures are still fit into the IKE payload. We have more fragments but we still hope that IKE fragmentation will handle them. But what if we think about several hundred kilobytes? Well known one KEM that has a public key of this size. And first of all we need new format for IKE payload and we have a good candidate and I just want to request chairs to issue adoption call for this draft because I raised a hand when you spoke about status but it was—I was missed. So it just take time to because I have an implementation and we have an application for this big payload. So if you issue adoption call it will be very good. So but coming back to IKE fragmentation. What the number of fragment will be very large for UDP and so is it really doable? So just I did some experiments because we have these seven and eight additional key exchanges transforms we can actually configure up to eight key exchange method in total and I just created this Christmas tree. So I added a lot of different KEMs and taking the largest possible variants of them. So you can see it's in total all these KEMs must be performed in order to to create a single SA. So and I have two desktop connecting via 1 gigabit network and sometimes I switch it to 100 megabit just to see if there is a difference. So it's the data. First using TCP. With TCP it works. IKE fragmentation still needed because of the for classic McEliece. But it takes about 20 seconds or something a little bit more to create an IKE SA with all these messages. It doesn't matter whether it is 1 gigabit or 100 megabit. Then I switched to UDP. It works but you can see that the number of really transferred fragments is much higher than the number of fragments in the message is fragmented to especially for McEliece with big sizes. So the message is fragmented into 3,000 fragments. But because of IKE fragmentation is not efficient we in reality we send 8,000 fragments because of retransmission because each time each time we resend the whole message with all the fragments. So if if the number of fragment is few it's not a problem. But for large number of fragments it's just very inefficient because network has been filled with garbage traffic and receiver need to process all these fragments in discard them it takes power, congestion, and what solution can be what can we propose? Actually we can add some status receipt notification that can be sent from receiver to the sender indicating which fragments it has already received. So that these fragment are these fragments are not retransmitted. And this idea was actually was thought when IKE fragmentation was developed but at that time for the few fragment it was considered too complex. But now for the larger number of fragments perhaps this it makes sense. So actually there are two proposals one from Antony a second from me. Antony Stefan and Tobias and the second from me. And the overview is very simple just receiver of fragmented message sends status report to the sender if not all fragments are received. And sender just retransmit only those fragments that are not received. So if we compare the proposals the devil is no—not the devil, but the difference in the details. So in my proposal I use a specially crafted IKE fragment message and Antony's proposal use notification payload inside non-fragmented message. And I use bitmap and Antony use a list of fragment number and so on. So in my my proposal is not negotiated and Antony's is negotiated. And that's the details. So just to check I created a proof of concept implementation and repeated my experiments. So you can see that the number of resend fragment is in blue is several times smaller than when this extension is not used. So we just it is not as TCP of course is more effective. But if you for some reason do not want to use TCP or cannot use TCP but still need to send fragmented messages with substantial number of fragment this extension can help. So it's very easy to implement it took me perhaps one day or couple of days to to implement it in existing IKE implementation. So any comment? First question is it needed? And if it is needed perhaps it should be adopted.
Antony Antony: Um, yeah, thanks Valery for summarizing both of the proposals and you know the technical details are very minor but I would like the working group um feedback on both of them so that we can get the best of the best of the two. Thank you.
Tero Kivinen: All right, then Yuan-hu. Next. Oh, I can see.
Yuan-hu: Yeah, Yuan-hu here. So one comment that I think like you said, right? So one straightforward solution would be just using TCP. I know somebody don't want to use TCP because using TCP also means that using TCP for the ESP. But if we could have a mechanism that separate the IKE and ESP for example IKE using TCP ESP stay as UDP, then I think that problem should be solved in most in most cases.
Valery Smyslov: That's true and I agree with you but I've heard that some people cannot afford TCP for their implementation for some reasons that even for IKE because they they may have some proprietary operating system with very constrained devices that just don't implement TCP at all. Well I guess for from from my point of view majority of our flows don't have this issue so I mean that would be much straightforward way to forward this.
Antony Antony: Again like I don't think that is true because the TCP and UDP creates lot of two problems, one is if you have a NAT, you need to open two connection, one to TCP to go through the NAT and one to UDP to go through the NAT, that's an overhead. And also if you do in the hardware, you have to maintain the TCP socket as well as UDP socket which is also double the overhead. And that's one reason we are pushing for a UDP based solution.
Tero Kivinen: All right. So I think that's everything we had for that. Let's continue that discussion on the list and then go to the next one. Who's the next one is Tero? Oh, it's me. Oh, it's yours. You are doing—okay. Just continue then. So this is about this presentation is about using hybrid KEM in IKEv2. A composite hybrid KEM. So currently what we have currently? Currently large KEMs cannot fit an IKE_SA_INIT so we use IKE_INTERMEDIATE for this and we developed multiple key exchange in RFC 9370 to be able to fit all the shared secret to steer all the shared secret that were calculated in all additional key exchanges into the session keys and we believe this is secure and everything is okay, except that it takes additional round trips and despite the we believe the it is secure, the mainstream of cryptography thinks that combining KEMs with traditional elliptic curve shared secret should be done via especially designed combiners. They were well—the cryptographer put a lot of efforts to to invent a proper way to combine these things so TLS is using this combiner and so they most of cryptographers think that the right way to to combine traditional and post-quantum key exchange is to do composite hybrid key exchange. I don't say most cryptographers, but at least it is used in TLS and TLS well is a mainstream for now. So can we use composite hybrid key exchange in IKEv2? So this draft defines how to use it. So first of all we now have separate transport draft that allow IKEv2 to run over TCP and ESP still like still run over IP or over UDP. So this raise also the problem that with the big payloads with a large payloads in the IKE_SA_INIT. And so we can just put a larger payload into the IKE_SA_INIT if IKE is run over TCP with no problems. And actually if there is a closed environment with no IP fragmentation problem you can run IKE over UDP too. But we consider separate transport as a main main more general idea for for this for this solution. So we a combined payload containing both public keys is placed into IKE_SA_INIT and response contains a both shared secrets that are concatenated and so we calculate shared secret using universal key combiner and that's all. So SK_d it is performed as defined in RFC 7296 but using combined shared secret as shared secret. So which algorithms are considered? It's Curve25519, ML-KEM-768, ECDH-P-384, ML-KEM-1024, and Curve25519, ML-KEM-768 using the draft reference to a draft. So any comments?
Guilin Han: Hi, here is Guilin from Huawei International. So may go to slides three, I think it's slides three, about the untested constructions. Yeah, this one. I don't understand what does it mean untested hybrid construction.
Valery Smyslov: Well, it means that the way how we do in in RFC 9370 is not approved by formal analysis of cryptographers because they put all the effort cryptographers put into hybrid KEMs was to invent a combiner for hybrid for composite hybrid KEMs and not for non-composite. For non-composite we we believe it is secure, we think it is secure, but we don't have a vetted analysis from cryptographer community because they just didn't look at it.
Guilin Han: Okay. I see, I see. I roughly understand. Yeah, maybe we can communicate later. My second comment is that from my understanding is that you are trying to solve the same question, yeah, as the previous one, yeah, by different approach right? This one basically proposed to use TCP transportation, the other one actually try to do is solve the same problem but just in IKEv2 itself. Yeah, so I suggest to actually look both of the draft together and considering which one maybe select or maybe decided both.
Valery Smyslov: I would like to review the draft. Yeah, thanks. Yes, the previous presentation was a generic presentation how to transfer larger payloads using only UDP but this is not strictly related to this because if we put large payload into IKE_SA_INIT no fragmentation takes place. IKE fragmentation is only available starting after IKE_SA_INIT. For IKE_SA_INIT we only have to use either TCP from the very beginning or we have to be sure that no IP fragmentation problem in the network, for example we have closed environment and we do know there are no firewalls, NATs and so on and fragmentation works very well. So in this case we can put a larger payload into IKE_SA_INIT. But previous presentation was concerned with IKE fragmentation. IKE fragmentation is not available in the IKE_SA_INIT.
Scott Fluhrer: All right, Scott Fluhrer, Cisco Systems. I just because we already have a existing solution which addresses this, I'm wondering if the need for a yet another solution which covers essentially the same material with the extra limitation that it has to go through TCP. Although the complexity isn't very much, it's just basically defining another KE payload. I'm still wondering is it worth the effort to fragment the community to have two different ways of of addressing the same problem. Thanks.
Tero Kivinen: All right. I think that's let's go to the next presentation then because now we are getting into delay and that's not you anymore. It's not me. So I think I had Marcus—it was Tiger Hu? Okay. You can use the clicker here. No remote presenter at all yet. Okay. Hello everyone. I'm Xiao Hu from China Mobile Cloud. I'm newcomer to IPsec working group although this draft is almost 10 years old. The reason that I want to refresh this draft is I believe this draft is still very useful in today's use cases. The first use case is used IPsec for SD-WAN scenarios. Currently many cloud providers along IPsec user to use multiple parallel IPsec tunnels to improve the total bandwidth between the customer side and the cloud side. Beside some cloud providers also use IPsec tunnels to secure the traffic traversing their data center interconnection one for security and compliance purpose. To further utilize the bandwidth bandwidth over the WAN and the internet, it's better to leverage UDP tunnels to transport IPsec traffic. Encapsulation IPsec ESP over UDP is very simpler. It's has same logic as other UDP tunneling technologies such as VXLAN. Another useful scenario for IPsec ESP over UDP is many IPsec gateways are implemented in the form of multi-core X86 server. In that case, to improve the performance, the RSS module will use hash function to distributed received packets over multiple CPU cores. In this case, if we can implement IPsec ESP over UDP with UDP source port as entropy field, then we can make better load balancing over multiple CPU cores. As I mentioned before, the encapsulation scheme almost is same with other UDP based encapsulations such as VXLAN, MPLS over UDP, LISP and some others. Here the source port is used entropy field, which is used to indicate a given flow. If two IPsec gateways are encapsulating multiple flows over a single tunnel, then they can use source port to distinguish different flows over that given tunnel. Currently there are multiple implementations about this technology. One example is Junos, which has implemented on its router product. The authors believe this draft is ready for working group adoption adoption call. Um, that's all. Any comments or suggestions are welcome.
Valery Smyslov: Valery Smyslov. So I read the draft and I have some questions. First of all I'm not—it's not clear for me why do you need to allocate a new port. So from my understanding all the functionality that you define are already available in the IPsec because actually if you use UDP encapsulation IPsec, source port is not used at all. It is thrown away. You can put it into any value. The only the only problem is that if NAT is detected and usually UDP encapsulation is active with NAT is detected, so the the peer that is not behind the NAT should update its destination port based on the packets authenticated packet received from a new port. But this can be disabled very easily if you make for example if you use MOBIKE that doesn't implement this feature this is forbidden for MOBIKE. Or for example if you forced UDP encapsulation, it's it's easy, you just put a garbage or some fixed value into the NAT detection destination NAT detection destination IP. And your peer will think that it is behind NAT. Because it is behind NAT, it will not update its source port. And then you can put any value into the source port of your ESP packets. Because it's they are source port is not used for processing of incoming UDP encapsulated ESP packets. So I believe that everything is there already. So I'm not clear what what new would you want and especially why do you want a special a new port allocated for this reason.
Xiao Hu: Okay. As I mentioned before, although cloud provider currently just use multiple tunnels to improve load balancing, but it will consume multiple public addresses which is expensive, right? Expensive. Especially when the traffic volume become larger and larger in the AI scenario, they will transport very large volume traffic and this traffic is security sensitive. IPsec would be used in this case. That's why I think it's time to refresh this draft. If the volume is very slow, maybe just two tunnel is good enough. But load balancing you just do load balancing.
Valery Smyslov: Yeah, but load balancing you can do just randomize source port not the destination port.
Tero Kivinen: All right. But anyway, so we are running out of the time. So let's take to the list and yeah. So okay. Thank you. So the next one is Jianming from China Mobile. Hello everyone. This is Jianming from China Mobile and I would like to introduce the draft Multi-Path Secret Sharing for QKD Key Relay in IP Networks. So let me share the motivation first. And the security of the QKD network is guaranteed by the quantum mechanism and does not define depend on computation complexity. But but but in the long distance QKD network due to the physical distance limitation, it is necessary to rely on intermediate trusted relay nodes to forward keys. And at these nodes the key exist in plain text. And the key will decrypted from quantum state to electronic signal and re-encrypted to quantum states that negotiated with the next hop. And because of this, the relay nodes become the potential exposure points. And so this cause a challenges. This the long distance QKD network security model is an all or nothing security model. So as long as all relay any relay node on the path is compromised, whether physically or logically, the entire end-to-end key will be completely leaked. As the network scale expands, the probability of node compromise increase significantly. So we propose a solution that called multi-path secret sharing. This draft propose the solution aim to transform the security model from single point trust to threshold security in the QKD network. So secret sharing multi-path planning is combined with secret splitting to mitigate the trust node problem. So as you can see, here is a QKD network architecture logically and the quantum layer and the key management layer are responsible for random number seed generate random number seed and transmitted. And the routing layer which which is the solution be deployed is responsible for the network path management. And the application layer is connected with the traditional network through IPsec or IKEv2. So this solution has four parts. The part one is key splitting. So we we can use a threshold secret sharing scheme for example Shamir's secret sharing split the the generated random number seed. And the multi-part two multiple transmission. The origin key can only be recovered at least t share are collected. And path isolation is using SRv6 technology enforced that the n share are transmitted over n physical disjoint path to ensure no common relay nodes. And the finally we can recover the key in at the destination nodes. And I think that is the whole solution. Next step.
Tero Kivinen: I think we have to take the questions into the list because we have three minutes and we have still one more presentation which was supposed to be given in five minutes so I should be faster.
Jianming: Okay. Okay. And one question. I'm not sure the draft solution is within or without the scope of this working group charter.
Tero Kivinen: I think people need to read the draft and be able to say I my guess is it's not necessarily so but anyway so yeah. Thank you. All right. Let's go to the final presentation and no, we don't have time for Antony. Okay. I should be faster. Okay, so I would like to present our new draft called the Multi-Authentication in IKEv2. This is the 00 version. Yeah, so the first we give some a little bit history of current work in IKEv2 authentication. Basically the main idea is actually use the supported authentication message notification type from the RFC 9593. So currently two drafts there. Yeah, one is actually use ML-DSA and SLH-DSA or any PQ signature for pure PQ signature authentication. Yeah, second draft is from Jianming called the composite signature authentication. But this one actually it's special specifically refer about the certificates. It could be dual-signature certificate or actually composite certificate specifically as it currently. Yeah. And for this draft, we would like to actually specify a flexible multiple authentication. The basic idea is actually two peers are able to negotiate multiple authentication message, yeah, in IKEv2 authentication and this multiple message not necessarily symmetric. Yeah, different direction have different set of message to authenticate. And one more thing is of course this message not necessarily belong to the same category. Could be different combination. Here is some example, could be a MAC plus PQC signature or maybe traditional signature and PQC signature or maybe PSK and PQC signature or even more. So what we can do is our basic idea is just mimic the means of negotiate ADDK for key exchange. So we would like to provide flexible choice between the two peers. So basic idea is the first guy like A can send a set a number of set of authentication message, yeah, to the other peer B. Then B can select one authentication message from each of the set and give the answer. But of course this way can be done from B to A as well. Yeah. So this draft specify how actually we can do this by extending the authentication message announcement specified by RFC 9593. So here example actually we try to actually give some compact answers so that it can save some communication payload. Yeah. So here we give three kind of answer, the answer have particular meaning. The first case if actually here we have some ten or twelve algorithms. Yeah, like A can actually separate the ten algorithm in three set, just asking B to select one algorithm for authentication, select one from each set. Yeah, so like this one B just reply okay A1, A4 and A7. So these three algorithm will be used for authentication for both direction from A to B and from B to A for authentication. And second case still select algorithm in these three category. Yeah, but actually the authentication message from A to B and from B to A are different. Yeah, and the last one is for general case. If B cannot select algorithm for A, yeah, in that case B will select or give the general query to A as A just did before. Yeah, so next one is just how we can do this by use the notification and type specified the previous RFC. So in the first line, yeah, we have a what is particular authentication code for multi-authentication. Then we will specify okay in this notification how many authentication message group we are giving, yeah, together with the okay for the first of the set how many authentication message announced in this payload. Yeah, then just a concrete detail about the first authentication message and second authentication message etc. A little bit complex, but basic idea is simple. Here is just an example how we can do run the protocol procedures. I think that's all. Yeah, appreciate your comments and review. Yeah, thanks.
Tero Kivinen: All right. So this—this was the last presentation. I think we have to take all the list because we are minus two minutes now. And one of the things we should—somebody was sending a list—email to the list or asking for comment you should actually mention how this differs from the, you know, the multiple authentication exchanges we already have in IKEv2 as well. Oh yeah, yeah in our draft we mentioned this one. Okay. All right. Okay. So we don't have any time for any other business. We did ask for one and a half hours for this week, but we only get one hour so that's why we are a little bit cutting short but we are, you know, have to do with what we get.
Deb Cooley: This will be easier going forward you know, right? Because we don't have to deconflict with Paul's working group anymore.
Tero Kivinen: Excuse me? I couldn't—
Deb Cooley: This will be easier to schedule going forward because we don't have to deconflict between Paul's working group and my working group.
Tero Kivinen: Oh yeah, that's true. That's true. Paul is always the—the problem my understand. Exactly.
Tero Kivinen: All right. Okay. Thank you and see you next time.