Session Date/Time: 16 Mar 2026 03:30
Verbatim Transcript:
Yoshiro Yoneya (Yoshi): Okay, we will start the meeting very soon.
[Silence and background noise]
Yoshi: Okay, let's get started. So this is TCPM working group meeting. Please make sure you are in the right room. My name is Yoshi, one of the co-chairs of this working group, and Michael is online right now.
Michael Scharf: Hello.
Yoshi: Uh, this is Note Well. I think you're already familiar with this one, but just in case, uh, this Note Well describes how you participate IETF meeting, Code of Conduct, and so on. In addition to this, uh, this Note Well describes how intellectual property is handled in IETF. So if you have any concerns in this kind of topic, please read this Note Well carefully. You can find same contents on the IETF web page.
Yoshi: So, this is meeting tips for the meeting. So if you participating in person, uh, please make sure to sign session in Data Tracker or QR code. And if you are remote participant, make sure turn off your audio and video unless you are making comment or making presentation. And for all participant, uh, when you make a comments, please state your name before you start making comment so that Note-taker can track your comment.
Yoshi: And this is logistics. Uh, thanks Stuart for Note-taking. And Michael will take care of Jabber. Thank you so much. And this is short reminder. Uh, when you submit your internet draft to this working group, please make sure to include TCPM as a part of your name of your, uh, draft so that we can track the status of your draft very easily.
Yoshi: And this is agenda for today. Uh, we start from Working Group Status Update, and after that, uh, we have, uh, one presentation for working group document, which is TCP ACK Rate Request option. Uh, Carles will talk about it.
[Technical pause]
Michael Tuxen: I can't hear Stuart.
Michael Scharf: I turned the microphone on. Does that help now?
Michael Tuxen: Yes. Thank you.
Michael Scharf: Okay. So, I saw the notes in the chat with people saying the audio was not good. Uh, if it's still no good, let us know.
Yoshi: Uh, okay. Like this?
Michael Tuxen: Yes. Please get closer to the mic, Yoshi.
Yoshi: Oh, okay. Like this?
Michael Tuxen: Yes.
Yoshi: Okay, sorry about that. So, uh, so and after the, uh, presentation for working group document, we have three presentation for individual draft. Uh, first one is TCP Reset Diagnostic Payload. Jason will talk about it. And the next one, uh, Bowen will talk about Provenance Identifier TCP Option. And lastly, uh, Tony will talk about TCP-AO. Uh, any question or comments or suggestion to this agenda?
Yoshi: If not, we are moving on. Okay, so this is the status of working group document. Uh, it took some time, but, uh, we finally published RFC 6937 bis draft. So draft now becomes RFC 9937. Thank you so much. And for Accurate ECN, this draft also takes lots of time, but the current status is AUTH48. Uh, so there seems to be we still need to update document a little minor things, but, uh, I think we are getting close. So I don't have a specific concern on this draft right now.
Yoshi: And then the next one is EDO. Uh, this draft has been around for a long time. Uh, this is because, uh, extending TCP option space is a very difficult discussion. But, you know, today we have some related discussion about extending option space. So let's see how we can proceed this draft or how we can extend TCP option space in the meeting.
Yoshi: And the next one is Ghost ACK. So in chair's understanding, uh, the authors are working on updating new version of this draft. So from chair's point of view, we are waiting for the new version of the draft. And once the new version has been submitted, uh, the chairs will check it and review it and decide discuss if this document is ready for working group last call or not. So that's the plan.
Yoshi: And then last one is ACK Rate Request. I think this document is very getting close. Uh, and we have a discussion, uh, today. So let's see if there are any other remaining item or we can conclude this draft in the meeting. So that's the plan. So any comments on the current working group items?
Yoshi: Okay, if not, uh, we only have one hour, so let's move on to the presentation.
[Technical pause while slides are loaded]
Yoshi: Okay. So Carles, are you ready?
Carles Gomez: Okay. Yes, I'm ready. Can you hear me?
Yoshi: Yeah, I can hear you.
Carles Gomez: Okay, thank you. Okay, uh, hello everyone. My name is Carles Gomez and I'm going to present the last update of the draft entitled "TCP ACK Rate Request TARR option". Uh, my co-authors are Jon Crowcroft and Michael Tuxen. By the way, Michael has joined as co-author in this last version of the draft.
Carles Gomez: So first of all, a quick reminder on the motivation for this draft. Delayed ACKs is a widely used mechanism which is intended to reduce protocol overhead. However, it may also contribute to suboptimal performance in a number of scenarios, uh, such as so-called large congestion window scenarios, meaning those where congestion window size is much greater than the MSS, where saving more than one of every two ACKs may help improve performance. And so-called small congestion window scenarios, meaning congestion window size up to about one MSS, uh, where Delayed ACKs may incur too much delay or limit congestion window growth and so on.
Carles Gomez: So this is the main format for the TARR option. The R field indicates the ACK rate which is requested by the sender, meaning after how many received data segments the receiver is requested to send an ACK. Currently, there's the maximum value for this field of 127 and there's the special case of R equal to zero, which indicates the request of an immediate ACK, while keeping the steady-state value of R.
Carles Gomez: On the status of the draft, it was adopted three years ago and today I'm presenting version 11, uh, which provides a new Section 7 on socket API considerations, which is intended as informational and it aims to show how the socket API can be extended to allow an application to use the functionality defined in this document. And, uh, this is an initial version for this section and possibly a basis for further discussion.
Carles Gomez: So let's go through the actual new content, which is again in Section 7. Section 7.1 provides an overview of the, uh, new TCP socket options that have been defined, uh, in this section and their main characteristics are summarized in the table that you can see on the slide. There are three main such TCP socket options. The first one is TCP_ACK_RATE_REQUEST_ENABLE, which can be used with the set and get, uh, functions, and it can be used to set whether TARR is used or not, or check whether it has been negotiated for a TCP connection. The second one is TCP_ACK_RATE_REQUEST_PROCESS, which can be used with the set function, and it can be used, uh, to set whether the processing of incoming TARR options, uh, is allowed. And the third one is TCP_ACK_RATE_REQUEST_SET, which can be used with the set function to establish which is the ACK rate that will be requested in the next segment to be transmitted by the sender.
Carles Gomez: So a few more details on these three, uh, socket options. Again, the first one is TCP_ACK_RATE_REQUEST_ENABLE. So the setsockopt function can be used with this option for a TCP socket in state CLOSED or LISTEN. And negotiation of TARR can then be disabled by providing a zero option value, or enabled otherwise. Then the getsockopt function, uh, can be used with this option, uh, for a connected TCP socket and the option value returned will be zero if TARR support has not been negotiated for the TCP connection, or non-zero otherwise.
Carles Gomez: For the second, uh, TCP socket option newly defined here, uh, it's the TCP_ACK_RATE_REQUEST_PROCESS. And the setsockopt function can be used with this option for a TCP socket, uh, to establish, uh, if processing of incoming TARR options is enabled. That would be by providing a non-zero option value, or disabled otherwise. Then the default value of this socket option is that incoming options are processed, and for accepted sockets, this socket option is inherited from the listening socket.
Carles Gomez: Finally, the third new TCP socket option is TCP_ACK_RATE_REQUEST_SET. The setsockopt function can be used with this, uh, socket option for a connected TCP socket, and in this case, a TARR request for the ACK rate specified in the option value will be sent with the next TCP segment.
Carles Gomez: So, uh, this is the new content in Section 7. Uh, if you have any comments or feedback, please let us know.
Carles Gomez: So, uh, then you may recall that, uh, the last time we presented this draft was in Madrid. And we expressed that the authors, uh, were not aware of outstanding issues on the draft, but then, uh, there was some, uh, discussion and the outcome was that it would be good to collect some additional, uh, experience from implementation and or evaluation. And we are actually working in both directions. In terms of implementation, uh, in addition to the, uh, prototype implementation for FreeBSD that, uh, Michael, uh, was leading, there's also some, uh, new very initial right now implementation work for Linux, uh, which among others doesn't yet cover the socket API functionality that I presented. And, uh, about simulation, uh, we have also some simulation code that has been developed, it's more mature compared to the implementation part and, uh, it's still in progress. This is for the network simulator, uh, called ns-3, and you can find the link to this to the code, uh, on the slide. And we would like to encourage also the community to contribute in either implementation or evaluation and, uh, in any case, uh, any feedback or reviews would be very much welcome.
Carles Gomez: So I think that is my last slide. Uh, I don't know if there may be any comments or questions.
Yoshi: Any comments or questions?
Yoshi: Uh, Yoshi's, uh, I have one comment as an individual. So when you enable when you use enable option, so you have to make sure the gets value by using getsockopt, right? And to make sure the option is enable or not. But if implementation don't call getsockopt and then after that, it call set request, uh, other socket option what will happen? It cause errors or it just ignore silently ignored?
Michael Tuxen: Um, you don't you don't have to call getsockopt. So you set soc- you enable the negotiation with the setsockopt and you can check whether it was negotiated or not. If it's not- it wasn't negotiated and you call setsockopt for a rate, uh, you'll get EINVAL.
Yoshi: But, uh, let's say the negotiation failed. Then even if you set, it's fail it's not negotiated. But can we still use other APIs? That's my question. What will happen if we call?
Michael Tuxen: What is other APIs? You can query that the negotiation has been- has failed, but you can't set a rate.
Yoshi: Yeah, but it cause- does it cause socket some error for setsockopt after?
Michael Tuxen: For the setsockopt, yes, I would say.
Yoshi: Okay.
Michael Tuxen: But you can- you can continue to use the socket.
Yoshi: Oh, yeah, socket is okay, but I just would like to check if the API call return errors or not. The draft is a little ambiguous from my point of view. That's all.
Michael Tuxen: Yes. Okay. We can- we can add that.
Yoshi: Yeah.
Michael Tuxen: Thank you.
Yoshi: Okay, any other comment? I think, uh, in chair's understanding, uh, there is positive support of this draft and previous discussion, uh, the remaining comment was adding API for this draft. And now they did. So, uh, do you think this document is ready for working group last call or is there any comment about it? If anyone want to speak up, please do.
Michael Tuxen: I would like to get some feedback from the Linux people, at least, on the socket API.
Yoshiiro: Is Jeff's comment-
Stuart Cheshire: Hello, yeah. Uh, I was going to say something similar to Michael. I was asking where was the Linux code, um, that you talked about because that sounded very interesting to know that someone had implemented this or tried to implement this in Linux. Is that code available somewhere?
Carles Gomez: So, actually not yet because it's very, very initial at the moment. Uh, and standard's also, the prototype implementation for FreeBSD, uh, not sure exactly, uh, what might be not covered yet in that one either. But yeah, uh, at least we'll try to progress and make that code available, uh, soon as possible.
Stuart Cheshire: Okay. And, um, the second part to that is the API. It would be- it would, I think, be really good to have some feedback on the API because, um, that bit is going to be fixed in this when we publish. So, uh, just some eyes. I- I love the idea that there's going to be some code that's tried to implement this. So, um, thanks ever so much for taking that extra step. That's really useful. And I encourage, um, implementation section in the draft just a short few words saying, um, prototype code exists or whatever you think is useful there. Thank you for doing that.
Carles Gomez: Thank you very much.
Yoshi: Okay, then I think this draft is getting really close, but, uh, so maybe you can update the draft and then checking with Linux implementation and then we can proceed to finish this document later.
Carles Gomez: Okay. Thank you.
Yoshi: Okay. Thanks so much. Thanks Carles.
Carles Gomez: Thank you.
Yoshi: Okay, then moving on to the next presentation. Uh, Jason, it's your turn.
Jason: Yeah, uh, Jason, I would be very happy to review Linux implementation of that draft. Yeah.
Yoshi: Okay. Thank you. Uh, wait a second. I'm waiting. I'm going to head control. Yes. Go ahead. Uh, yep.
Jason: Hi. Hi everyone. My name is Jason. I'm presenting the version 16 of TCP RST Diagnostic Payload. Before we get dive right in the pending issue from IETF 124, I would briefly introduce the how basically the draft works. Prior to this draft, we have not any visible tool or any implementation to help us understand the underlying behavior when we receive or send a RST packet. With this draft applied in the Linux kernel implementation, we can have a we can have a deeper understand of why we send this RST packet and why we received this packet.
Jason: Uh, we received two prime concerns from IETF 124. The first one is do we need more exhaustive internet experiment to verify it's 100% right when it will be deployed in the real world? And the second one is the format. CBOR format is way too complex to use and implement.
Jason: The current status includes how we deal with those pending issues and some software updates I will talk about later. We replaced CBOR with a much more compact plain text, uh, Michael has volunteered to complete the common socket API extension that we can implement in different kernels on top of this extension, so many thanks here. Uh, and we also see the FreeBSD kernel, uh, Wireshark, and most importantly, we change our intended status from Standards Track to Experimental, uh, to avoid much more discussion around the internet work internet experiment that should be done to prove if it can work 100% right in the real world. So our roadmap of this draft is, uh, we achieve the experimental document first and we, uh, we, I mean different developers across on different software to implement its corresponding code, and we will see if it works very well maybe one or two or three years later, we will change we will consider it as the standard track, I assume.
Jason: Uh, this is the first format I'd like to introduce. Uh, it's a it's a compact format. Uh, there uh, it comprises three values. The first one is a fixed value, uh, that is magic number. And the subsequent two values are respectively Reason Code and PEN. We have two kind of combinations of these two values. Uh, the highly recommended way from my side is please use the Reason Code only. Uh, you can find there are 70 reason codes in the table two in this draft if you have some interest you can find them there. Uh, if someone argues if they want to apply their own private code, please set this PEN to a certain number that has been already registered in the Enterprise Number, and you can use your own reason code.
Jason: Uh, and we also provide alternative that is the free description format. We replace the previous reason code and PEN with a bulk of reason description, so this length can be flexible. The maximum number can be 255 bytes, I think. Uh, and let me revisit a little bit. This length is is a fixed, it's eight. And this is flexible, more flexible.
Jason: And, uh, this is how Michael and I and some other people working together on this socket options, and there are three options. The first one is Reason Enable, that is a knob to decide if the application want to enable this feature. Uh, so we can launch a set sockopt to enable or disable it. Uh, by default, uh, we disable this feature to avoid some unexpected behavior that can happen in in between two servers. And second one is the Reason Code. Uh, we can use the get sockopt to retrieve the code from the kernel and and and let the application, uh, be aware of the what exactly the reason that causes the termination. And we uh, it's worth mentioning there is a setsockopt for the Reason Code. That is used to particularly handle one special case here. Uh, if the application uh, if application use the SO_LINGER feature and then calls close system call, it will actively perform the termination with sending an RST because of this application. Uh, so this set setsockopt provides a tunnel let the application use their own, uh, code to uh to tell the remote side. And the third one is the Reason Description, that is used to serve the free description format.
Jason: Uh, there are some updates in the Linux in the kernel's implementation. Michael has done the complete patch targeted at FreeBSD kernel at this link. Uh, and and in the Linux kernel, part of this draft has been already merged in the main line in 2024 by me. I mean, uh, there is some much remaining work to be done like how to communicate between two two sides and how we can use the recently added the socket API.
Jason: Uh, and we also notice there is a commit that implement the version 15. I don't see much difference between the version 15 and 16, uh, 15 and 16. Uh, last but not least, I'm humbly requesting the working group adoption since we changed our intended behavior intended status to Experimental. Thanks. Any questions and suggestion are welcome.
Yoshi: Any comments?
Jeff Haas: Hi, this is Jeff Haas. I I would urge you to be very careful about, you know, the free-form reason code, especially since it uses UTF-8. I have pasted into the group chat, you know, a BGP RFC that, uh, very similarly used, you know, UTF-8 to communicate things. Uh, it has unfortunately been proven to be a source of, you know, security issues. Uh, UTF-8 is very tricky to encode correctly, uh, even if you're getting the length of the individual UTF-8 characters correct, uh, getting all the other non-displayable character considerations, you know, uh, correct is also very difficult. I'm not saying you can't do it, but I would urge you to think very strongly, what are you expecting a receiv- receiver of this reset to actually do with this display message? Thank you.
Jason: Okay. Uh, I might have missed part of them because of the voice. Uh, you mean, you mean it can take a risks when we try to transfer the encoded format to like the the leaking users' information, something like that? I'm not sure if I'm understanding right.
Jeff Haas: I see that we're very close to end of this presentation. I will post my stuff into the chat.
Jason: Okay.
Lars Eggert: Hi, Lars Eggert, Mozilla. Um, so I think I had a similar comment that Jeff just made, but first of all, thank you for removing the CBOR option. I think that that was a huge improvement. Um, I've been wondering why we actually need this free-form text form of the option at all. I think the PEN plus custom code, um, lets an entity express anything it wants to express, um, and removing the free-form code option has a bunch of benefits specifically like Jeff mentioned, right, encoding Unicode and decoding Unicode is problematic. So I would encourage us, if we adopt this, to only adopt the PEN plus code version of the extension. Thank you.
Jason: Okay. I will take that into consideration. We can we can discuss it a little bit more of the later.
Michael Tuxen: Michael Tuxen as an individual. Uh, I second what the speaker before said. I also only implemented the compact form in FreeBSD and will not implement the free-form. Uh, I don't think we need this and, uh, I have concerns not only about the encoding but also about the size. So adding eight bytes is okay, but right now you can add, uh, large number of bytes there which does not serve any function.
Jason: Right. The highly recommended way is use the compact format.
Michael Tuxen: So just get rid of that free-form thing.
Jason: Pardon? You mean get rid of this free description compact?
Michael Tuxen: Yes. Only- right now it's like the one thing is mandatory, the other is optional, and we can just remove the socket API reflects that you can just remove the one socket option and the format and everything's fine in my view.
Jason: I'm not so sure about that. I mean, if we can still keep this because this draft is experimental, and after we implement this draft across different kernels, and we can then decide if we need to get rid of this. What do you think is acceptable for you?
Michael Tuxen: I accept my individual opinion as the two other, um, people in the queue that they would suggest remove this when after working group adoption it's the decision of the working group, uh, before it's your.
Jason: Okay, I got it. Thanks.
Yoshi: Okay, so seems to be the consensus is to remove the free format. Right. But I just would like to check if there is another concern on this draft. Okay, then my take is no, you can update the draft, remove free format, and then we can discuss, no, we can ready for adoption call or not. Okay. It resolves the question that raised by I don't know that guy. Yeah. Right. Thanks.
Yoshi: Thank you so much.
Yoshi: Okay, so moving on to the next presentation. Bowen, your turn. Wait for a second. I'm waiting. I'm going to head control. Yes. Go ahead. Just press, you can test it.
Bowen Liang: Uh, hi everyone. Uh, I am Bowen Liang and I'm here to present my like very first draft working with IETF. And the draft is about TCP Provenance Identifier Option. And it simply means an ID that help you to track the origin of the TCP connection.
Bowen Liang: Let's start with some background information. Uh, so the the draft is actually not designed for open internet and at the modern network evolve, the enterprise network like cloud-native or data center networks has become increasingly complex in architecture. So that's including lots of the widely deployed middleboxes. And most of the traffic connection they will traverse NATs, proxies, or load balancers. And for some operational purpose, like maintaining the observability of the connections is essential actually to later diagnose the network issues.
Bowen Liang: And here is the challenge appears. So some of the middleboxes like NAT or Layer 7 proxies, they will rewrite the connection identifier. So then the connection provenance is lost. So as shown in this figure, uh, when a traffic or a TCP connection from Host A to Host B, if it traverse a NAT before the NAT the Source IP is Host A, and then after the NAT, the Source IP will be rewritten to NAT. So uh, this will cause some trouble for the operators. And also, uh, even in the case that the Source IP will not be rewritten, we argue that the IP address alone is insufficient for troubleshooting. And we will explain a little bit more when we talk about the use case.
Bowen Liang: Okay, so the draft is basically propose a solution called Provenance Identifier. And uh, is going to uh enable the is able to correlate the different connection segments that are logically one connection. And also is going to provide ability to faster operational troubleshooting. So by design is going to carry in a TCP option and it should be preserved across middleboxes. And we also let it support a more fine-grained level information in contained in this Prov ID. So the design here is pretty simple. Uh, I think this is just a standard format with an extra Prov ID here. and is currently designed as a fixed 8-bytes. and is what we will argue as a minimal bytes of information that is needed to address the problems we mentioned before.
Bowen Liang: Okay, so to help you better understand the idea of this, here is a use case. And this is actually based on a prototype we implement using eBPF. Uh, so the Prov ID here is simply defined as the host IP, uh, plus a process ID, the PID. So with the information of this is able to link connection segments observed at different network points. So like along this connection path, like whenever you met, uh, an alert on reach controls, you can observe at either middleboxes or the destination service, you can just directly provenance to the source IP and then you can, uh, take action on the origin. And the work also enable a fast provenance to the fine-grained entities, like by design is PID here. and we will see is important in modern environments. Since, uh, we actually implement this one in a cloud-native environment. So in this case, there will be lots of pods running in one host. So lots of pods or processes sharing a host. And then for operators, they really want to take action at the minimal level. Like if you, uh, if we observe an alert at Host B and it said this, uh, traffic is overreach- overreaching, and we want to find the origin and take actions. We really do not want to like shut down the Host A, but rather to find which pod or which process is, uh, creating this connection and we want to take action at that fine-grained level. And why we choose PID is just by sort of the nature of the cloud-native environment. If you have the host IP and PID, you can actually do a trace back like from the PID you can trace back to Cgroup, and Cgroup to container, container to the pod. So you can actually do a whole like the path correlation. And it's going to be faster than the operator without the Host IP and PID information, they would just have to figure another way to diagnose like who actually initiated this connection.
Bowen Liang: Okay, so, uh, as I mentioned before, this draft is really at a beginning stage. So it's kind of my first work and it has not been updated like into details yet. So there will be a lot of open question remaining. So like when and how should the option be initiated? How should we standardize the sender and receiver behaviors?
Bowen Liang: So, uh, I think I'll just try to I hope I make the idea here clear already. and we welcome any discussion, feedback, and collaborations. Okay, thank you.
Yoshi: Thank you. Any questions? Lars?
Lars Eggert: Hi, Lars Eggert, Mozilla. Um, I have a question about your scenario what you showed, the two endpoints and a NAT in the middle. Are you saying this would be deployed within a data center so all of these boxes are within under the control of one operator, or is this an end-to-end deployment scenario?
Bowen Liang: Uh, so the scenario we we mentioned is that these are all managed by the operators.
Lars Eggert: Okay, so basically there's more to the right of Host B where it connects to the internet and you would expect to then strip out that option when you egress the packets?
Bowen Liang: Uh, so I'm not too sure what you mean after the Host B received the option what they will do.
Lars Eggert: So I'm wondering if Host A, the NAT, and Host B are within one data center or if Host A is in a data center and the NAT and Host B are somewhere else on the internet.
Bowen Liang: Yeah, they are within one data center. So we actually implement this prototype in a like cloud-native environment, so everything is managed by the operators.
Lars Eggert: Okay, so everything's in one data center. Okay. Um, why do you need a standard?
Bowen Liang: Uh, so the real difficulty here is, uh, how to collaborate with the middleboxes. So I think for Layer 7 middlebox, when they rewrite the source IP, they will also try to drop the option here.
Lars Eggert: Right, but so these are middleboxes that whoever operates the data center installed in that data center. Right? So they should configure them correctly to not do that.
Bowen Liang: Uh, I think you can only do that if you have like you are really the hardware producer of the middleboxes.
Lars Eggert: No, well, if you're the person or the entity deploying them, you should be able to configure them, and if you can't configure them, then you've maybe have purchased the wrong middlebox. Um, so so basically my I'm wondering if this is a problem that requires a standard to solve it, or whether you can just deploy this in a data center, you know, like you said you've done an implementation and, you know, it worked.
Bowen Liang: So the scenario we we met in the prototype is actually we cannot let the all the proxies support the option here, so they will drop the option. Yeah.
Lars Eggert: Okay, so your real problem is that the NATs are doing things to your traffic and you want them to stop. Um, so 20 years of of dealing with NATs in the IETF means this this will not happen. You cannot stop NATs from changing packets. Uh, so so I don't think this is going to be a solution for you. But I've taken up enough time, I'm going to get off. Thank you.
Magnus Westerlund: Magnus Westerlund, Ericsson. Uh, yeah, I think I agree with Lars that the from the perspective of deployability here, either you have the control over the middleboxes, so then you can configure them to let this option through, otherwise it will be stripped and not work anyway. Um, also, I mean, this is a privacy concern in general. It's really needs to be only in this limited deployment cases where this would be acceptable, I think, for use. Uh, I also have a question about if I count this correctly, you will burn 12 bytes of the option space. So you're unless we have more option space, is this really what you're spending option space on?
Bowen Liang: Uh, thank you for the comments.
Yoshi: Hi, just one point question. State your name, please.
Zhonglun Li: Oh, Zhonglun Li from Tsinghua University. Uh, I wonder whether the PID is transferred in plain text. Um, the question is that if it indeed is transferred in plain text, then there may be some leak- privacy leakage since the, uh, middlebox and the receiver, uh, does know the exact PID of the sender. So how do you think of this?
Bowen Liang: Uh, yeah, that's some privacy and security consideration. But like we currently design it as plain text cause it's sort of, uh, designed for a self-managed network. So, uh, supposed to be protected by other mechanism already. So yeah. and also we did not really go detail to the security consideration yet, so yeah. Thanks for the comments. Okay, thanks.
Yoshi: Okay, so please make it quick, sorry. Uh, just to remind everybody
[Laughter]
Stuart Cheshire: My name is Stuart Cheshire, I work at Apple, I'm taking notes, I came to the microphone to remind everybody to, uh, join the queue, um, because if you're not in the queue and I don't know your name, then whatever you say doesn't go into the notes. So if you care about what you said being recorded in the notes, please help me out by putting your name in the queue so I can keep up with my typing. Thank you.
Mirja Kuehlewind: So I think actually this is interesting to look at this besides the data center scenario, because this is a scenario we've been using we designed Quick Migration for. And in Quick, we put like a lot of effort into like all this privacy and consideration. So for example, the connection ID is changed whenever you change your address or whatever. And there is encryption context in Quick, so that makes it easier which is not here. So I think, you know, if you want to solve that problem, I think you need to consider all these things and maybe look at Quick and get inspired there.
Bowen Liang: Okay, thank you.
Yoshi: Thank you so much. So maybe my suggestion is, no, if you want to collaborate some, you know, content provider or something, then you might get some more tangible use case, tangible requirement, then, you know, you can sophisticate your draft a little bit more. That's my suggestion.
Bowen Liang: Thanks for the advice.
Yoshi: Thank you. Okay.
[Pause]
Tony Li: Hi, I'm Tony Li, and this is not my first internet draft. Um, I'm here to talk today about extending TCP Authentication. As you may or may not know, uh, very much big parts of the internet today are running BGP with only HMAC-MD5 protection. Uh, this should make you very, very scared. Um, it is now time for us to start doing PQC and so the end goal is to figure out how do we do that.
Tony Li: Uh, the real problem that we have are blind reset attacks. and this started happening very early on in the early 90s. Uh, we slapped HMAC-MD5 on, um, we've started moving towards TCP-AO and we've done this on every segment. Um, and by the way, TCP-AO is not universally deployed yet. Um, we wish it was. Uh, what we currently have are some older crypto algorithms, and we would like to move towards newer ones.
Tony Li: Uh, and the PQC stuff in particular. Uh, there is an issue with putting enough data into the TCP options field. and so in our draft, we are specifying how to do truncated and untruncated versions of these algorithms.
Tony Li: Uh, doing the truncated stuff is not particularly difficult. Uh, if we do untruncated things, then we run into the 40-byte option limit. Uh, we've already talked about two ways of getting around that limit. Uh, not going to rehash that discussion now. Okay? Here they are, take a look at them, let's not argue about it right yet. Let's talk about crypto first.
Tony Li: And by the way, I'm a BGP geek, so, you know, if you've got a hard crypto question, I'm going to have to pass on it. Um, so when wouldn't we have to have untruncated authentication in TCP-AO? Um, we have some strong things, do we have to have them on strong algorithms and long hashes on the SYN packet? Uh, when do we have to have that? and are these things compatible with legacy TCP implementations? these seem to be the major questions on the table.
Tony Li: We've got lots of discussion going on. Um, it's fine with us if we take a long time to figure this out, that's fine. Uh, we can discuss the requirements, we can talk about separate solutions. What we are asking is that we allow uh our proposal for how to do this uh extended options, we want to proceed that forward as experimental. Uh, and that way that allows customers to get something deployed quickly, uh, which we'd like to do because some people are ready to cut over to it very soon.
Tony Li: Uh, what's the risk here? Um, well, being experimental is not a big deal, okay? We are not asking for code points. We don't have a problem. If the experiment fails, then we move on to something else and we mark it historic and move on. It's not the not the big deal at all. Uh, if this does become useful and everybody agrees on it, then we can simply take it from experimental to proposed standard, um, that becomes long-term solution. Okay? So this is a low-risk request.
[Technical issues with slides]
Tony Li: Okay, slides are stuck. Yoshi? Never mind, last slide. Um, so in our draft we are proposing a bunch of crypto for both untruncated and truncated versions. Um, I'm not going to get into the crypto details here. If there are questions, please feel free.
Yoshi: On the queue. Oh yeah. On the queue. How can I unlock queue? Let's see. Oh, this one? Yes. Go ahead.
Magnus Westerlund: Magnus Westerlund, Ericsson. So, I think the on the algorithm side, just pick reasonable choice of algorithms, get that published as soon as possible. On the untruncated, I don't see the usefulness of it. Symmetric algorithms is not perceived to my understanding to be affected by quantum computing breakage. It's the handshake that's the problem on the whole PQC debate. Um, so really long tags might not help us. I mean, it's long tags but it's the strength is really pretty good when you get to actual 128-bit tags. So I think running long keys, truncated 128 bits with modern algorithms will make a lot of difference to just meet the security requirements you actually have here. And I think that's the requirements part of the security side is is maybe what needs to be clarified and how much future options you have. But I think this part and this draft should be fairly easy to progress because it's mostly selecting reasonable set of algorithms and go forward, so.
Tony Li: So, we think we have selected some reasonable algorithms, although we have some recent feedback about otherwise, we will certainly take that into consideration. Uh, as to the truncated versus untruncated, uh, security is not binary, you know. Different people have different security requirements.
Magnus Westerlund: Yes, I'm just requesting that you express these requirements in relation what is it? Do you need FIPS algorithms? What's what is the different requirements you actually see from the market and the governmental etc. contract etc. That's I think you maybe need to express a little bit on what what level of security do you actually need to meet.
Tony Li: Uh, the algorithms that we have specified so far seem to meet the requirements that we have been given. I do not claim that the people giving us requirements are security gods. Um, they've told us what they want. Okay. And I don't know how sophisticated they are and I don't know whether they're correct, but I do know that they want what they want.
Magnus Westerlund: Okay, yeah. So, um, on the extended options, um, I I think it's fine from my perspective. I mean, this is clearly limited deployment, specific applicability etc. and be clear on that that this is not expected to work immediately or maybe never over general internet on the extended options, that's then I guess it's this clear to right group discuss further on how how exactly this what is the best structure etc. for that to make it work. But yeah.
Tony Li: We are certainly happy to stipulate limited scope. Any other questions? Allison?
Allison Mankin: Uh, yes, hi, um, this is Allison Mankin, um, dialing into this having been very involved a long time ago when the first started. Um, I really liked the discussion on the mailing list and and how it got separated out into threads. Um, I support allowing the draft to proceed, um, and um, for the reasons that Tony and and Ron have talked about. Um, also I spent some time with the uh the current uh papers in the Real World Crypto, uh, conference, which just took place, um, I guess last week in Taiwan, and there's probably some good hallway conversations to be had to bring some people who were there to to put some pressure on the on the security ADs if that's the problem because there seems to be a lot of consensus that that truncating to 128 not a lot but papers that are saying don't worry about truncating to 128 bits even even for because of the benefit of the modern algorithms. So I would just encourage you to get some more voices. Um, I'll try to post a couple of the ones that I was looking at and also see if I can convince a couple colleagues to to weigh in a little bit, but I just wanted to put in a word of of gratitude that this is actually being extended for to modern algorithms.
Tony Li: Thank you. Um, we certainly acknowledge that some people feel like truncating is not a problem. Um, we are not convinced that everyone feels that way yet. And and the problem is everyone, right? Not everyone is sufficiently sophisticated to understand those papers and feel that they are secure. So.
Allison Mankin: Right, and there's a there's a I mean, this is rough consensus stuff, but I think having some people join the conversation who might not even know it exists at the moment might help with the um, I don't know who exactly are the most the people feeling most insecure, but surely they're the most insecure without making any changes at all. So, um, but I also think that that a case may be makeable and and I've been preparing for for something else for IETF, but I I will try to get a few words onto the mailing list in a near future myself.
Tony Li: Um, the people the customers that we are talking to have crypto that they consider to be mission-critical and they have extreme requirements and they are most insistent. They may not be right, but they are insistent.
Yoshi: So Tony, can I ask one interruptive question? So can you make two draft? One is truncated, the other one is non-truncated.
Tony Li: Uh, to what end?
Yoshi: To internet draft, separate two internet draft. One is for non-truncated version, the other one is truncated version.
Tony Li: Uh, again, I don't understand how this helps. Um, we are interested in doing both.
Yoshi: Okay.
Tony Li: Um, the quest- the only question is how do we uh put what version of extended options do we use, if any, right? Okay. And other than that, this is this is knobs the customers pick.
Yoshi: Yeah, I was just wondering.
Tony Li: Yeah. And sooner rather than later please.
Yoshi: Yeah. Thank you. Okay, that concludes the discussion for this TCPM working group meeting. Thanks for joining. Uh, so see you next IETF meeting. Thank you so much.
Michael Tuxen: See you and thanks for the Note-taker.
[End of recording]