Internet Engineering Task Force 111, 26 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF111-IPSECME-20210726-2130

Description

IPSECME meeting session at IETF111
2021/07/26 2130

https://datatracker.ietf.org/meeting/111/proceedings/

A

All right, thank you. Paul paul has just volunteered for taking minutes.

B

Yay, that's good all right, so I think my clock is now half hour past midnight, so we are about to start so it's 9 30 utc. So this is ipsec maintenance and extensions working group. uh I think it was supposed to be minor extensions. Did I misspell that all right anyway? So this is the idea meeting. So we have a note. Well, you have probably seen that before and noted it well.

B

So we need some minute takers. We don't need not yet chopper site scribe, because we can actually read the chopper in the chat here. So I don't think we actually need that one, but that paul has already agreed to take the minutes.

B

So that's actually nice there's a minutes are there's already template made in the uh eater part, so use that and and if anybody else, while paulo's talking, for example, you can make some notes for also for that and or help him to add some things, and if, if you ask something, you can also go and type your question there to get it correctly, you know written down all right, so I don't think we have any other administer tasks.

B

So our agenda is quite tight because we had on one hour, so I don't think we actually want to go too much detail in.

C

B

So we have a let's start with the status report of the you know documents. So we have two documents waiting for chair review and write up so the ice versus two intermediate and uh I basically made the iptfs.

B

I was actually doing the chair review for iptfs and I had some questions and but then I run out of some other meetings and so on. I couldn't actually come back to them, so I tried to get them. You know resolved okay, let's.

B

Go ahead for a christian.

B

Hear me: yes, we can hear you.

D

Okay, great yeah, so um I just wanted to. uh We started that thread on the on the list about a month back hoping to get some comments um from you on that. But it's uh I do have comments from offline.

D

The thing I did about a month back, we published a new version that you know took some of your comments on the the reordering. I don't know we covered all of your comments, but you know we think we covered the gist of you know, um and you know it's about added about a paragraph uh that talked about reordering.

B

um Yeah, I'm sorry that I haven't been able to really because in last month I have been. You know, having two weeks of ieee meeting and one week of moving and two weeks of sailing in one last month.

D

B

D

I guess you know the only thing that we'd ask is that um you know if there are any more changes to make. If we could, you know work together to quickly turn those around because we've been through. You know: we've been through a full cycle. uh App post-working group last call that'd be great yeah.

B

Let's, let's try to do that during this week. I will try to get it tomorrow or something like that then go to the when I have some time, because there's only.

E

B

Hours of sisters.

B

Because they have 10 hour or 12 hours of sessions during the day.

D

Cool. Thank you thanks.

B

And paul has some assume I assume for the historic stuff. Now we can't hear you, he can't hear.

B

B

Silence silence.

F

Something has been doing funny things my audio gain without me, so I have to check.

E

Does it work now? Yes,.

B

No introduction, okay.

E

um So for labeled ipsec, the same thing applies: there's no really no changes. It's I I think last meeting we decided on working with lascal would start, and I think that's should be moved up to your list for waiting for a write-up chair review and be put on your to-do list for next week.

B

Did we do the uh vertical for the lab labeled a basic already, I'm trying to think we actually did that. I think it was waiting for this to the you know, working club last call to start wasn't it.

E

I think so yeah, that's what the data tracker told me when I think when I looked at it yesterday,.

B

All right, so I will start a working group last call for that, because I think it's mostly ready for actually getting their work into the last ghost. For start with that, one all right anything else.

B

Okay, so then we have a couple of documents like we have the young and meep documents we have covering going through them, and then we have multiple key exchange and that is also working. I think valerie's probably had some comments on that. Go ahead. Valerie.

C

All right hi, can you hear me.

B

Yes, we can hear you.

C

uh I just uh I just uh want to uh second christian hope that you will find uh time to uh write uh uh separate review for uh iq to intermediate. um It's been waiting for you for chair review for since previous idea and yeah quite a lot of interoperable implementation, and I think the traffic is quite ready for publishing terrorism.

B

All right, I will go, go through that. One also.

C

A

Or maybe I will.

B

That would be awesome, yeah, okay, so um I don't think we have anything for the uh uh this gi version two and I don't think, there's a have lots of happening in the the rfc 82 to 9bs.

B

That's my understanding, but anyway, okay, so let's go forward with this one so and then we start with the presentations. So the first one is the hybrid version, 2 interrupt testing, so valerie. If you can connect and start presenting, I go just say that I will switch slides uh when you say.

C

Okay, so it's a very short informational message that we've had a high pre-tech between the ability to test an event. So next, please it was on july the 1st it was organized by uh secunet, and there were three pacific participants, trump swan, uh elvis plus and genoa, and uh we performed uh quite a lot of testing um based on a combination of iqr2 intermediate and iq2 multiple key exchange, and we performed a real post quantum crypto key exchange based uh also implementation.

C

We used and leap ocus library that contains quite a lot of port quantum uh key exchange and signature implementations from the east third around east. That's our next! Please.

C

So the result was that strong, swan and ls plus performed up to four additional key exchanges with different algorithms, like kyber saber for the km psych and all works very well, except for minor issues that the same uh additional case changes uh voice letters that was prohibited by roxy and with genoa. Initially, there were some troubles with creation when using lipos, but later they fixed on the second day, and they also successfully performed to interpret interoperability testing.

C

But flights are a bit dated, so it is not on the slides, but actually all three implementation were interoperable. So the next please.

C

So the results are that uh results that there are at least three independent implementation of this drought, so they are interoperable or we badly need common identifiers and I'll request to assign code points for multiple key soon, and we also need a temporary identifiers for post quantum and the reason, because there are quite a lot of them. We use some private numbers that are on the right on the screen and uh genna and with passwords are interested in testing uh machines which doesn't fit in multiple key because it has a very large public keys.

C

So it is based on beyond 64 contract and we're going to perform this test uh later, probably in september.

C

So that's all so the conclusion uh the draft is, quite I I mean multiple key exchanges quite stable, so we have three interoperable implementations and I think, as a co-alpha and I've discussed it with my classes, the draft is ready for working group. Passcode.

B

All right was that all of it that was the last largest okay, any questions on that. So I think we should uh uh probably start. You know vertical blast on that. If you think it's.

G

uh It's ludovic barrett. uh I I have one question.

H

G

Could you explain a little bit? What was the experiment that you perform? So I I saw there is securenet, so you have a three different implementation of the ipsec post, quantum hybrid, uh and so you you you so you are three that implemented in uh some uh uh ipsec client, including libor, qs, that's right and after you you test, if it's more or less working, and so do you try to have some performance comparison or not at all.

G

Well, uh the goal of.

C

This event was to uh to to confirm that implementation are interoperable, so we didn't perform some uh performance testing well from from uh my experience uh as a user, uh it takes a bit longer well, but it's still tolerable to to to to establish, uh I can say, with up to four uh post quantum key exchange, algorithms, but it's it's! It takes about half a second or probably one second, but keep in mind that the implementation was on the different uh countries. So it's it's!

C

You can add some network delay to this, and uh so it's tolerable, it's a bit slow, but but not not that much that one can expect.

G

So yes, indeed, since it's uh I hybrid things, you are doing more, so it's it's clear that it's uh slower, so it's good to know that it's not too slow and so.

B

G

Point is that in the draft, so you consider uh the key exchange step, but not the authentication with certificates with the breed certificates.

C

That's true because uh the draft that was tested, multiple key exchange, is focused on the post, quantum key exchange and not on post quantum signature. So if you want to perform post quantum signature, it's a different thing. It is not yet addressed yet addressed in high quality.

G

B

Okay, scott.

B

Scott, do you have some question or or something you're in the queue.

I

Okay, am I listening now? Okay, uh could you a quick, a quick request? Could you please post the uh code points to the main list, so we have a semi permanent record of what what you've actually used.

C

uh It's on the on the slides some on previews. uh Well, it's probably not it's like okay. Can you please uh move the slide uh back. One slide.

J

Yes, oh no, no, you were you're on the right slide. Okay,.

I

What's the question.

J

Which algorithm did you test.

I

No, no! No! No. Could you please post the points that you give us your that you used to to do the uh to the mailing list so that we have a permanent, a permanent record of what of what you, okay,.

B

I

C

Somebody else wants to test.

B

Them they can actually try to use the same private numbers, okay, okay, sure, all right, yeah, okay- and I think I think there was one question in the chat about the 3k access using the same algorithm. Was that intentional or failure in negotiation, or was it a failure? I actually was a bargain that it code.

C

Yeah, it was a bug and actually at least it was back in my in my implementation- I've already fixed it, but I fixed it after uh that went take place. So probably the next uh internal wheelchair I went uh we'll try to to to figure out whether this fix works, all right. Okay,.

B

I think that was that, let's move to the next one right on time, so the next one is then improv improvements for porsche quantum. I question too daniel is going to.

D

uh So can you hear.

K

D

Wrong out of order, sorry.

K

Can can you hear me, does it work great? So um I will talk about the improvements for pos quantum iqv2 and the main point of issue we had with uh post quantum migrate ii uh are intermediate intermediate exchanges so next place they are rather complex, especially designing of them, and especially when used with fragmented messages or fragmented exchanges, and since the post quantum key exchanges are rather large. They are most of the time fragmented, so the the signing of them is quite complex, and that means always the risk of of bugs and security.

K

Critical box is always there and we also have a higher cost of maintenance and implementation. um Furthermore, large post quantum key exchanges like make a list require data to be sent more than two megabytes. We got in large parameter sets and doing this before authentication leads to vulnerabilities against the os attacks or ddos attacks, so we moved them in our implementation to the follow-up key exchange.

K

um How that looks next place we see here so that is the state machine of of igv2. With all these drafts applied and there we see we perform iksa in it, and thereafter we move on to intermediate exchanges, doing all all the exchanges which do not require large amounts of data, so it might like no mecalis, for example. Then we authenticate, then we immediately um re-key the iksa and during the re-king we perform all the exchange of the the key exchanges which require too much data to be sent during ike intermediate.

K

So we decided all the exchanges which require the beyond 64k draft to be applied, have to be performed after uh authentication, and then they are performed during fallout ke. um That is the status quo. How we decided to implement the the drafts, as they are presented right now next place.

K

The the first thing we uh propos would propose is uh to remove the intermediate exchanges in this for this context, because we have to to have this workflow anyway, where we conduct additional exchanges after authentication in during the follow p, and since this has an inherent risk for an attacker being able to break the initial exchange during arkansas life, because they would then be able to recalculate the message authentication code, which is the the anchor for security after authentication, we propose to add quite simple, hybrid key exchanges like a ecdh and psych, for example, something that fits into.

K

I can say unit and then it all. It is already secure on its own for someone needing a high level of security for a long time. So, like I don't know, 10 years or more, um there is the possibility to have additional key exchanges after authentication, which also, if maybe in 10 years, someone has a efficient way of breaking psych, for example, or n2 in a small parameter set and acdh.

K

um There is still the the the uh michaelis or frodocam whatever, which is also it should be secure. Also then, so a record in harvest attack is impossible and the second exchange, uh the second change we would introduce, is uh related to the state machine being not cleared in this state because we, after ike off, we cannot rely on the essays being created and success successfully established so next place.

K

We propose to introduce an additional exchange which is rather similar to ike off, but it explicitly says that the the sas are not yet established and we require a.

K

We require a further key exchanges to be conducted, otherwise um yeah the extra um the handshake has to be awarded, and also we have the possibility uh to introduce another hash of the the public key from the follow-up exchanges, which is then also signed. So we do have uh an additional anchor for security, also for the exchanges, key exchanges. After the alternative, auth and yeah, then we have the more clear stuff.

K

We have a more clear state, machine or clearer state machine which is uh easy to maintain uh next, please so the benefits of these changes are. We are rather ind for, for the use case of post quantum key exchange. We are independent of the complex arg intermediate exchanges.

K

We um uh have a, we introduced, the large quantum key exchanges, but drs protected because they're after authentication, it is a more clean estate machine um because if we introduce them after the classical icos, like auth, doesn't mean, as the key handshake has finished and in general we have a new place of for exchanging handshake data after establishing an authenticated channel due to the new exchange type, which might also be uh yeah making, which might which might also make the introduction of post-quantum signatures easier. But that is another point, so that's it thanks a lot.

K

So I think we have some questions.

B

Yeah, well very, very, very short comments. I think we need to take the most of this to the list.

C

Actually, we discussed a little bit with daniel already his proposal, and I think that there are a few things that uh that I don't like about it. First, I can't immediately is not used only for the exchange, it is also it may be useful and uh I suspect it will be useful for the sins too, and so, if this proposal completely drops, uh I get immediate.

C

I think it's not a good thing, then I don't think that this proposal makes state machine simpler and then then it is, I think it might make, makes it more complex and the new uh authentication exchange. I think it's a new exchange, it's not that gross. It's like uh icon, alternative off it's another exchange with which must be implemented with.

C

It is not clear for me right now what this exchange should contain until probably draft will be written on something more detailed explanation, so it's difficult to to make a conclusion whether it is more simple or more from my understanding. It is more complicated than I can immediately and I get immediate because it's all problems uh it's a bit.

B

C

And uh those attacks concern is very serious and I think addressed and but otherwise I don't think this proposal is.

C

Is worse to drop like intermediate and replace it with this proposal,.

B

Okay, so I think I think you need to connect to this to the list, because otherwise it's going to take too long, and I I agree that there is things that we probably need to you know solve in this, but I would like to send you to send the description of the problem and the solution to the list or actually make a drafty, and then we can start continue discussing.

B

Okay, thank you.

B

So the next is, then the iptfs and yangon snmp drafts kristen.

H

Actually, it's done don, I'm going to present.

H

Okay next chart, um so no no changes. uh We we've submitted the draft, it's so um basically it's it's. The management for the ipsec, uh so for the iptfs and uh the only the only difference is the uh the base file the base yang that we augmented for this is now an rfc uh next chart, and uh so the tree this was was presented before. So these are the management objects for iptfs and the counters that we have for the iptfs okay next chart.

H

So so, basically, there's there's two documents, because one is mib and one is snmp and they're, basically in the same state.

H

So if you go to the next chart, um we we used the uh the yang to to produce snmp um objects that could be uh were were the same as the as the yang, and so it's it's. Basically one model that and and there's two views, there's the yang view and then there's the snmp mid view. That's um so you can read it and we we talked about this before that's, because some people still um would like to be able to read this with snmp and just, for example, the next chart.

H

um So here are the objects in the mib that correspond to the one before so. The summary is that we we think because the iptfs draft is is progressed. um The these two drafts are the management model and they're ready to go for workgroup last call.

H

So any comments.

B

Okay, any comments on this.

B

I just started couple of last calls: we have now three working club last goals ongoing, so I would actually like to uh postpone these and concentrate and get iptfs out and then getting the three last calls out and then hopefully start this after we get iptfs forward. So we don't consume resources for these. While we are actually trying to get the main core document out. First.

B

So I that would mean probably you know last call in month or so.

H

Okay, yeah that'd be great right.

B

Anybody else have any comments.

H

I, I guess uh the only thing I'd I'd say is: uh having had another yang uh document go through work group last call uh to get the uh yang doctors on to. It would probably be a good step that we could start initiating.

B

Did we already have the young doctors looking at it.

H

Not that I'm aware of.

B

Okay, okay, so I think there were some issues, some questions about that earlier. Okay, it might be some other thing all right. So, okay, any other comments is, I guess not so, let's go forward so the next one is the uh this equation. Two configuration for encrypted dns lorry.

C

So this draft was already presented. uh I think it was presented a couple of times, but it has some significant changes from the last 8 years. The design was greatly simplified and it was lined with a recent add work in particular with itf edg dnr design.

C

It's also leverage svgb is a way to to transfer parameters for encrypted dns servers, and the draft address comments released by the working group in idea 114 through his deployment section to appendix it's. A minor comment and a magic comment was to reliable magnitude with data and certificate, so we introduced uh instead of using picayo, introduced a new attribute that can weigh sufficient the dns server certificate, so the next piece.

C

So what is simplified design instead of having six uh attributes for uh two uh versions, families and three uh protocols like uh dot, doh and doku? uh We have only two uh attributes now for version four inversions at leadership on their competition. Six and uh all the specifics of uh encrypted dns server is conveyed in uh service parameters. uh That has a format of what we see so connect. Please and a new attribute is introduced.

C

Its attribute contains a hash of the encrypted dns server certificate and the hash is computed using official algorithms from the ip2 cache organism registry. So there's no no need for new registry. We use an existing one and at the same time we have algorithm agility. That's a good thing and sha 2 256 is my data template so the next please.

C

So uh the client requests in request uh includes an mdns digest info attribute with a list of hash algorithm. It supports and a server chooses, selects one of this algorithm computes cache or use a precompute hash of the certificate and includes, in response refresh of the dns server certificate, along with a special gifts identifier.

C

So the next please.

C

So this is the diagram that just illustrates what I've said, so that please so next steps, and we think that the draft is now in the good shape, and I think it is uh already it can be considered for adoption by this working group. So please consider adoption of this job.

C

B

The comments, I guess paul- has something.

E

Yeah, sorry, I forgot so these digests are these fields inside the server certificate, or are these like different cert payloads.

C

uh This giant it's a giant digest over or serve dns server certificate that is transferred inside iksa, so that the next slide please. This next slide has a diagram.

C

So you can see that uh the client requests uh the parameters of the encrypted dns server and the responder returns a hash of the dns server certificates, uh which the client can further uh compare with the certificates that dns server is using. So this time this way a client verifies its uh uh by authentication with responder.

C

It verifies that the dns service certificate is valid.

E

Okay, so I guess I'm a little confuses. Why? Wouldn't we almost just send an svcp presentation, format, dns record to the client and say like this is what we have you figure out what you want to use? Why is there an additional authentication here, because the the ike exchange itself is already authenticated, so why does that? Do we have to have a separate authentication in this step?

E

C

Authentication because ike authenticates.

C

Security association between client and initiate and responder, and we need to also authenticate, uh not authenticate, but we did the dns server certificate in a server with the different entities and responded. And so we need to know that uh certificates that is used by dns server is weighted from responding by authentication.

E

So, isn't that exactly what the svcb record does with the information inside that record? uh Well, I'm not sure.

C

I I don't know.

E

I think it can contain a lot of.

C

Different information, information and it's quite.

E

uh Because so I think it includes things like pub key and other things and sure it's not maybe not authenticated. If you do it that way um anyway, I'll I'll take this on the list. I'll have another look at it, because it's now changed quite a bit so I'll have another look and and clarify my questions. Okay,.

B

I have one question because it seems to be here here: you have a hash. Algorithm item requires, yes, seems to indicate there's a list of them, but how do you actually? Is there some kind of end marker, or is there actual number of them and if there are multiple certificate tickets? Also, if you have multiple house algorithms.

C

uh Well, the client includes least, of uh algorithm identifiers. It supports, but responder uh returns on the single algorithm.

B

So this is actually 16 b, so the hass algorithm identifiers here is only always 16 bits and- and you know, there's only one known length- okay, so it's just the graphics. Here is a little bit funny. You.

C

Just got to fight in the drone yeah, so sorry! So sorry, it is not clear from the slides, but in the droplet yeah all right.

B

Okay, any other questions on this topic.

B

Do paul have still something more?

B

No, he went away run away. Okay, so I think that's it for this, and then we move to the next presentation, which is beyond beyond 64 kilobytes limit of ice version, two payloads valerie again.

C

Okay, so um this presentation was also presented uh as in the couple idea before, but we had some changes so next, please.

C

So uh what is motivation for this round? uh We have iq to multiple gear and it addresses issues of using large keys for key exchange method, but it still has a limit on the key size that is limited by any equity load, that is 64 kilobytes and most nist candidates uh fit into the into this restriction.

C

But there is one notable exception: it's a classic mechanism and uh with a small ski size of 255 kilobytes, some national regulators, like bsi, recommend using classic mechanics so because it is very conservative and some cartographers think that it is most uh most conservative and that's why most trustable of all the candidates- and we also anticipate that with quantum digital signature will be used in likely too and looking into the needs. Third-Round candidates, at least two algorithms that are either candidates, so alternative candidates have either signature size or public key size, greater than 64 kilobytes.

C

It's a rainbow and picnic.

C

So next, please.

C

So the goal for the draft is to define a way of transferring some specific data blocks and ip2s that grow beyond 64 kilobytes, and these specific data blocks are publicly for key exchange methods, signatures and certificates, and we want this mechanism to be report compatible and we want to address reliability.

C

We want so the performance of episode, traffic uh not suffer, and uh we want that. This mechanism must be as simple as as possible and reasonable and introduced minimal change, typically something next, please and not: gold, not gold, to define the generic mechanism of transfer any load greater than 64 kilobytes, because it it requires to redesign ip2 and reload format and accents that it's it's announceable.

C

Yes, please. So uh the approach is very simple: if some block of data doesn't fit into the single blue, just split it into the chunks less than 64 kilobytes and uh place it into the sequence of adjacent adjacent reloads of the same type and the responder will concatenate all these chunks and receive a large global data.

C

So this approach works very well if there is only uh one preload of a given type in a message.

C

So, for example, like exchange, pollutant oat, and it's not true for server load, but it can be walked around, and another problem is that if this sequence of a load of each of which is less than 64, kilobytes is encrypted, so it is placed inside in critical load, so the encrypted load will always be greater than 64 carbons, but the reason that, if we use like fermentation, then the actual length of the critical load is never transferred, and so it doesn't matter.

C

We can use a value of zero for to indicate it and just deduce it from the message lens, because it is always the last polaroid in the message. So the next piece.

C

So it's it's an example, so we have, I can say need then I get immediately with uh with ballots that are in blue. It's this uh a lot that are split into in into several loads, a large block of blocks of data that are split into several prologues, for example. This is in this diagram. It is key exchange below circuit loans and hospitals.

C

So the next please.

C

So what are the changes from zero zero version? uh Eye fermentation is not mandatory for both udp and tcp. uh It is because the gcp individual's message size is still limited. The imessage size is still limited to 64 kilobytes, because tcp lens prefix is 16 bit lens, so we have to use incrementation even with tcp, then we introduce a so-called mix transport mode and the mix transfer transport mode is a way of avoid problems that ipsec traffic esp traffic have when it is encapsulated in tcp.

C

So with this mod ike is using tcp, so it has started from udp and then switched to tcp as the first time intermediate exchange, but child desire still created so that they use either direct transport to udp encapsulation. So.

C

With this mixed mode, we have a reliable transfer of very large data in ike essay, but still doesn't don't have uh problems uh that with performance that are caused by using gcp transport for esp. So it's an optional mode. It is negotiated by exchanging new notification ico with tcp, and we think that for transforming large public keys, it's very useful condition.

C

So we also need some clarification: how to tweet cleanse or foreign and actually actually results or for the changes. That's the next piece and uh a very important respect is joseph tex.

C

We have a section that discussed them a bit and we said rfc 1819, but we think that some more discussion is needed in the draft because of the large large data blocks, something next please so anyway, there is some interest in uh using at least in using my keyless from uh in interest from vendors. So we think that the draft is uh in the situation in the state when it can be adopted, and so if the working group is saying that this work is worse to to conduct. So we ask for adoption.

B

E

Okay, just just one comment now like requiring tcp is a really heavy-handed change to the ike protocol like well. While the world is moving more towards udp, we would be moving towards requiring tcp, which would be really scary and easily filtered easily blocked. So I would be very not in favor of requiring tcp.

C

Well, actually, it is not required to use tcp it is. It is an optional, an option because uh with udp, it's quite difficult to reliably transfer mcalee's public keys. Actually, I performed some experiments on the local local network on the land and even using edp. It is manageable to to exchange michaelis public keys. At least I managed to do it it. It usually takes about a couple of seconds and about couple of three year, transmits of all the uh to 55 kilobytes message, but it works, but with tcp is much more reliable.

C

So it's an optional, but we have to address reliability too.

A

um Yeah, so I'd like to agree that the you can get better reliability with udp like they get in quick, but you need the quick mechanism. Just can't just use the thing you. What we have in ike is not nearly as robust as what they have in grid. um I'd like to push back on the statement that it's a non-goal to make it a generic mechanism.

A

I think you could, if you just uh made the length field bigger, like adopt some of those seven reserved bits next to the length field and use that as an extra length field, and you could get payloads that are um four megabytes or eight megabytes depending if you use the last one, and I think that would be a simpler thing than the way you do it with multiple ident, multiple, similar payloads one after the other.

C

That was an option too and the last atf I presented some ideas of a new balloon format, but as far as I remember that wasn't received very well and actually uh actually it's uh it's quite a light change to to to the protocol. It's a larger change, more more deeper change, because uh look for format is very, very inside the um the protocol of the code, and you have to also negotiate using new feature and the code compatibility.

C

So well, it's an option, so we can discuss it, but if there is an interest in the working group for now for now, we think that this approach, our purchasing, it's it's not ideal and, of course it's some protocol hack, but it's.

A

A simple hack, it just seems to me that having a big certificate in uh one big payload is better than having one certificate in multiple search payloads. But that's just me.

B

And actually, actually you could have you know five, you know certificates in the same, you know.

E

B

Message and each of them would be fragmented in multiple pieces, and you have to have somehow separate them and of course you add- and if you have to, if you think about that understanding, is that all the beyond 64 kilohertz buckets are inside the encrypted payloads, yes uh with, which means that at the encrypted payload that you're proposing or handling it so that the uh you know that uh length of field of that is going to be zero, which means that all the old implementations are going to be barf at that point anyway, because they will actually check that.

B

So after you get past that check that okay, that group, the payload negative, zero okay, then we can actually, you know, go to the other part and say that okay, now we just change they change the you know: payload numbers to payload links to 32 bits, or something like that. I don't know, but this is something that I think we should probably uh think about it when we are actually processing those.

B

So you are proposing before this for the working group adaption, and I think this was in our charter, so we can probably, but it actually try to did remember, add this already to the charter.

B

But that actually it goes anyway, it goes with. You know the uh you know, post quantum crypto stuff anyway, because we need that for for it anyway. So I think we can actually still uh adopt this as a working group document, so I will think we are good for the last two. Actually, I think we probably going to be making a adoption course quite soon.

C

B

All right, so then we go to the next presentation right on time. I think one minute early.

B

L

Okay, um hello, everyone, my name is weipan and um I'd like to present the ik version. Two optional essay and ts payloads in child exchange, and this draft was previously uh presented at, uh was first presented at itf 105 and next slide.

L

L

um Currently, the draft is in version 007 and uh thanks a lot for um for the comments and feedbacks and suggestions. The whole solution now is much simpler and text is more readable for now. The whole optimization solution comprises of three steps. First, is a negotiation of support and after the negotiation, the initiator and the responder can do the optimization that is omitted. The sa payloads and wreaking ike essays and omitting the essay and ts pillows at the wreaking china essays for now. There is no more consideration for the situation of configuration change.

L

This considerations are a little bit more complexity previously. So, according to the rfc 8272 96, the configuration change isn't allowed for raking. So if you change the configuration, then you need to create the new ik essays and the child essays. So.

L

The new notify message, type notifications: there are only two uh notifications are needed now and the previous one is three, and uh the next pictures uh shows the comparison between the previous version and the current version. uh You can see that uh the the right picture, the current version- is much simpler and uh also now uh we have new two co-authors for others and melinchen and welcome them next slide. Please.

L

This picture this slide shows the steps. Three steps of optimization and the read read: parts are the new new notified notifications are added and you can see there is um uh it's much simpler and reduce the band package size of the rookie messages.

L

Next slide. Please.

L

For now about uh the draft there I've, um I also think there are some open questions. First, should the supporting the notify mean that peers may or should or must use? This method must may be too strong and we think should maybe better and second question is, alternatively, if the supporter notified could have a payload that signifies whether the old method is support or not. um We think this is not necessary and it will increase the complexity, so we don't want to do that, but we also want to hear others. Opinions.

L

Third is about whether a child essay was negotiated with pfs.

L

What should an optimized key do when there is no key payload send invalid k payload, and we also do want to hear from the colleagues next slide please uh and for now um we'd, like about next steps, we'd like to ask for working group adoption- and uh we are welcome others to discuss and close the open questions, and we also are looking for implementations to do inter testing.

L

B

Okay, well, all right: do you have some questions.

C

uh So uh may I ask for previews right.

C

So uh for the question, I think that supported always mean. May it's my opinion, because it's negotiation of capability and well, if you want to use it, should to use it as should then it just might support it, but something like always used and yeah for the third question for the third question, I have another question: what about the first child the same? Is it uh well, the first time child decide is created, so when I can say it's created, so is it considered as negotiated with pfs or not so it's just a first prompt.

C

I can say the.

L

um I think um uh about the wrecking iksa the pfs are um are used uh because it contains the key.

B

L

About the the child essay, it was um optional, you can include the k payload or not.

L

Yes. Now I understand.

C

All this thing, uh the question you you you have is when the child is saying was nick shaitan with space. I I'm asking what about the very first child they say. Is it considered as negotiated with papers or not with or without papers, because the first child they say uh in fact doesn't have its own bfas. It's just inherits uh key material from my case.

C

It's the first child that says it is created in icos, you exchange key exchange per load and I can say need and the resulting entropy is used for both child the same type. I say.

L

uh Yeah, I I think maybe paul want to answer this question or.

C

E

um So in the traffic selectors for that child essay in ike off there is the divi helmet group as a transform. So you do signal that it is one with pfs. Yes, yes, and so.

C

You know it should come.

E

With pfs next time, if you get a create child essay for it, uh okay.

C

Okay: let's go into the to the list.

B

So I don't think he actually like also includes that, but I think we actually are running out of time and we probably have one more presentation from paul. So I think we should take those questions to the list, but might be much easier to understand there. When we have a diagram that people can actually read the drafts.

B

Okay, paul, you can stay there and go to your presentation.

E

Okay, so this is about uh our purse per cpu or per q child essay. So um so, hopefully you have read the draft, because I uh I will definitely assume you've, read it for the questions or the the items. So next slide.

E

So just a summary, the goal of the draft is to get like 40 to 100 gigabit per second wire speed, ipsec using multiple cpu cores.

E

um Normally, you know it gets downgraded to two to five gigs, because we have one tunnel with one counter and synchronization issues, and so what we're planning to do is having multiple child assays in parallel bound to cpus or network queues that can independently push this traffic much faster and we have reached like 40 to 60 gig speeds. Using this.

B

E

In linux so next slide.

E

So some changes since the last draft. We changed the name of the draft we fixed it. um We separated the notify. So it's like an info notify that could apply to either cpu or a quality of service, and we we separated them into four clear notifies. So one is qos and qos info. One is cpu and cpu info.

E

We clarified the terms initial child assay because it's a little confusing when it's getting re-keyed. So we call that that the fallback child is saying we also added the info notified to be always added. If you want one of these additional child assists just to make it easier to recognize it, because someone could start a traditional. I guess a sorry, a traditional creature, let's say with no no identifiers, meaning that it's just separate from this mechanism.

E

So by adding the info, we know it's. It's meant for this mechanism.

E

um We ran into a bunch of corner cases about the number of tunnels you want to negotiate. So, um instead of the minimum, we picked the maximum.

E

So you basically pick the maximum of the two parties, uh obviously within like denial of service reasonability, um and that that gets you out of a lot of the the corner cases that we saw. We attempted to clarify the qos case, but I'll talk about that. A little bit more. um We added some operational considerations that we realized about mostly about acquires and if you don't have per cpu acquires um so next slide.

E

So then this was the major issue, so the authors on this drive don't are actually not quality of service experts and we we see a bunch of issues with quality of service um and how to do that. So, first of all, there's no code, so we can't actually test any of this. um Another question is: what do you do with qos? Do you like negotiate all of the possible combination flows at first, and so so? Do you start like 64 tunnels or do you just say like well?

E

I only have really like you know, bulk and important, so I only need two. So I want to start two of them, um then. As a comment, the question of how does quality of service work with ipv4 and ipv6 flow labels? If you combine a traffic selector with both v4 and v6 selectors like we, we just don't know.

E

We're wondering if when, if, if you reject a flow, if you need a new ts error or about traffic selectors or if you can reuse t as unavailable or sorry t is unacceptable and then another big question is: can you even combine the per cpu one with the per qos one and how does it really look and how what would work?

E

So we don't really know the answers to these questions, so we are kind of tempted to say. Maybe if there's really qos people, they should put all of this in their own draft and work on it and and get these things done, and we would like to see maybe kick this out of the our draft. So ardor focuses on you know the the cpu slash network, cues that are available because that's actually the code we're seeing we're implemented. We know about. We just have too many questions about this.

E

So so that's one question for the working group. So next slide.

E

There was some some talk about what to return error code wise, um and I know that valerie had had suggested no additional essays, but um we realized that there's one issue with that. If you have- and I can say with multiple child essays and with some of them, you want to do this, multiple children and with some of them you don't, then doing no additional essays might be confusing to say whether you mean no additional saves for this traffic selector set or or that it's still allowed to do other traffic selectors.

E

So so we think no additional assays is the wrong solution.

E

So we think it should still either be t, is unacceptable or maybe just a a custom new uh code, um and so there's a note here as well that um we've broken this for quite a few years, like I think, going back to prague a couple of years ago, um and so we would really like to do like see if the working group is interested because we we really need to know whether we should merge this code into the linux kernel and eye demons or whether we should give up on this and and look at other ways.

E

um So that that's an important point for us and I think that's the last slide.

B

Yeah, I think so yeah, so so the question there is that I'm not sure if the actually we don't have a chartered item for this, but it could be considered as a minor extension. So we should probably talk with the 80 about this.

B

The previous one could be actually put into the compression stop, but we have to think about it more. So I think we need to have a discussion with the lady and the authors and see if we need to reach our or something like that, but we are now running out of time. So we can't do that one now, but I uh please send a list to the email to the list and and remind this and then our added uh ccdiads and our creators are coming.

F

Right no, I agree we should talk about this offline, but I had I wanted to join the the queue to say something unrelated, which was since we were talking about post quantum, so much and hybrid techniques. Today I wanted to point out that tomorrow, at the sag session, we're gonna have a topic, for you know how should the ietf be handling post quantum stuff in general, which may be of interest to many of us here? So please come to that and share your opinions.

B

So with that, I think, with the last two months we go to the you know separate side question because of conversations into the list or they may email threads and see where defeat them. I think we don't have any time for anyone, because we have four means over time.

B

A

Let's cook this out already soon yeah.

B

Yeah the cookies out there in the gutter towel, so it's probably gonna grab them before people. Other people take them. Okay, so that's all for the high basic mma and I hope people we had a little bit uh problem with my my uh scheduling because I was in the vacation where I was supposed to schedule this meeting. So that's why we only get to one hour and in wrong location in overlapping or several other systems, but hopefully that was still useful and so okay.

B

So I think that's it see you next time in next ip. Secondly, hopefully I will schedule that.

G

F

F