Session Date/Time: 22 Jul 2026 12:00
[00:00:08] Chairperson: Okay. We are gonna get started. So this is Internet area working group session. So let's start with a note. Well, it's Wednesday, so you've seen probably this a few times already. But in any case, it's important that you take the time to to read it, scan the QR code, to see all the information. A quick summary. You have to be professional and and polite with your colleagues and the people around. And, of course, this is an ITM meeting, so any contribution is subject to the IPR policies. So please, if you are not aware, check those in with time. Then some tips. Well, the most important point is that you need to be using the Mitico tool even if you are on-site. Please use the Mitico tool because it's required to register your attendance to the session, and this is used for many things among others to know how many people are attending and to be able to dimension the rooms properly for next meetings. If you are using the full version of the tool that you are on-site, keep in mind that all please try to mute the the tool so we avoid any echo. And that's it. Some useful resources, the agenda, and some other information. I guess you are fully aware with this. So let's go into the actual agenda. Have a pack agenda today. We'll start with the administrative updates, then we have a presentation of a adopted document, and then we'll go into presentation from or about individual submissions. And since we have a packed agenda, there is already one item that, if time permits, will be presented. If not, well, we have to maybe think of discussing offline or in the next meeting in San Francisco. Regarding working group status updates, we have a few documents in the ISG RFC editor pipeline. We have one in the IT in the RSC editor queue that is interior proxy config. Then we have a couple of them that require an a revision when in ISG evaluation. Jen, you wanna go ahead?
[00:02:48] Jen Linkova: Yeah. Regarding those two, one of them kind of blocking a draft in six men and another is actually needed for another draft. I actually emailed Bill asking him if he, like, doesn't have time or energy to move them forward. I'm, like, happy to take them over, but I'm waiting for his response because it's part of my understanding both of them, like, been waiting for a long time for update, and I just think maybe those doesn't have, like, resources to work on them. So let's, like I I I have an action item to follow-up on this.
[00:03:23] Chairperson: Okay. Okay. Thanks. Yep. Okay. Okay. Yeah. In a in a so do we have a minute taker? I will be taking notes. But if do you know I forgot to say that, and thanks, Eric. We have the notepad tool to collaborative take notes. We will be taking notes, but in any case, it will be good to to have somebody else helping us with that. So any volunteer for that? Jen, did you get an answer about the draft? Or
[00:04:06] Jen Linkova: No. I I only signed it, like, yesterday.
[00:04:09] Chairperson: Okay. So I
[00:04:10] Jen Linkova: I I will
[00:04:10] Éric Vyncke: wait for
[00:04:11] Chairperson: it. Okay. Thanks. Anyone please help us with the notes? It's very easy just to take a note of this type of important things. Okay. Thank you. So then we we also have documents that completed the last call. I think we got everything. We there was a couple of things to update in the write up. I already did that. So, Eric, I think on the multicast application port, I think it's waiting for your go ahead. So I guess in the few next few days, you will go on on with that. Then we have another active working group document that we'll have on agenda today, actually after this point. Then we have a draft that has working group adopted draft. Interior tunnels expire. We send some email up to the authors asking for a revision addressing the comments that we received in in the in the working group last call. So far, we didn't get any any response, so we will probably follow-up on that. And if there is no answer, we will discuss with AV what to do next. And among the documents that we have today for discussion, there are a couple of them that could be potentially work based on the discussion that has taken place on the mailing list. And those are on the agenda today, so we will see how we we tackle those. And before we go to the next meeting, Eric, you requested to have one minute.
[00:06:07] Éric Vyncke: So thank you, Jas one minute of your time. As you may know, I'm stepping down as a in TD in March next year, so there will be a seat opening to replace me. If you want to step forward, feel free to come to me and talk and discuss what is the workload, what's the work, what is the joy, what are the benefits, what is the salary, zero, and so on. Right? But you make a lot of friends. Right? Because everyone wants to. I'm serious there. On Thursday, tomorrow at 11AM in the IHG Room, which is in the same floor, the small room at the end, other AD will be there explaining the experience and so on. Other point, Tim, you want to say a few words? Tim is the Internet directorator.
[00:06:53] Tim Chown: Hi. Yeah. Tim Shoen. One of my hats is the Internet directorate co chair with Schweather, who I don't think is here this week. Yeah. We one of the the important thing we do is to provide a review function to assist the ADs in Interior. So Eric will not everything that comes forward is reviewed, but Eric and the ADs will tag certain drafts that they wanna review, and then we try to find someone to review it. Usually, within two weeks, sometimes it's a bit short to notice. But what we're desperately lacking are reviewers. So if you're interested in doing that, please do let me or Eric know, and we can add you to the team. We've currently in a position where you've got all the interior working group chairs on the review team, and I'm not gonna name any names, but a good number of them just ignore the review request. So we might well be bumping them off, either bumping them off or bumping off the list, one or one or the other, and then hopefully replacing them with people that are keen and enthusiastic to do it. So on average, you maybe do review a document every two, three months, something like that, so it's not too onerous. And if you get a big one, we'll not give you another big one for quite some time. But it's a very important function. It helps Eric, and it helps the ADs. They don't wanna have to read everything and rely on their own judgment. It's great when you've got other reviewers. And if you look in the data tracker at any draft that's going into ISG, you will see all the area review teams review it. So there's seven, eight reviews of a given document by each of the areas. So it's very important we have that cross area review of everything. So please help us with that. Let me or Eric know. I'll hang around here if you wanna come and talk to me afterwards.
[00:08:26] Attendee: Thank you.
[00:08:27] Chairperson: Thank you, Tim. Thank you, Eric, Tim. Let let let us fully echo what Tim mentioned. That's a very important job. And I think that that's also another important way or another interesting way of learning the process as well and getting to know other people as well. So not as time demanding as being an AD. So maybe you can consider that. So we can move then to the first agenda point. Fang, are you in the room? Yes.
[00:09:21] Jen Linkova: So, good afternoon, everyone. This is Fang Zhang from China Telecom, and I'm presenting the update of the YANG Data Model for ARP extensions on behalf of the other quarters. And first is a quick recap of what does the model cover. We define the model ITF ARP extension, and it covers the extra bits of ARP implementation, the many vendor support, but not covered by the existing ITF young models, including like proxy ARP, gratuitous ARP, and its statistics. And the about a related YANG definitions, the basic ARP model basic ARP functionality is defined in in ITF IP on module, which is in RC eighty three forty four, and like the table and the list. And if you care about the IPv6 solution, and it was all the basic function was also defined in ITF IP module and there is an extension of the IPv6 Neighbor Discovery module in in another draft we submit to the six man looking group, if you think about it. And thanks to Shigong for the YANG doctor reviews, and we made several updates according to his comment. And here's the main changes since the last version. We changed the title from ARP to ARP extensions and renamed the documents, the module, the prefix. As pointed out in the review that the scope of this module is about the some extensions of the existing module, but but not the complete ARP model. So, we add word extensions to avoid confusion. And we removed the global configuration of dynamic ARP learning and including the top level container ARB and leaf dynamic learning. So we because we believe that the enabler in the interface level could have been enough for the ARP configuration, and we don't have to add in top level container for the ITF YANG model. And also, we renamed the gratuities are enabled to be consistent with the other names used in the document. And also, we changed the statistic types from YANG counter 33 to 64 32 to 64 to align with the statistics in other IETF modules like IETF interfaces. And also, as pointed out in the review that there are several nodes that meets the default value. As for the leaf dynamic learning, we added the default value as true, but however, for the gratuitous leaves, we just left it to the unspecified they were varied across different platform. And this one was discussed, the effects in ITF 104 RDGWG session, we care about. And also, the leaf experiment time was left unspecified as it's also varying practice. In the next, it's early editorial changes. We added some description in section three to clarify the relationship between the ITF IP and our ARP extension module. And also, modified Xparse expressions in section six to use full path listening. And also, we updated the references. Now, just about the examples, and we completed and validated all the examples by adding the previously omitted parameters. And that's all about it. And we would like to request the word root model for since the module has been stable for a while. Document is stable for a while too, there's no further common rules. And all the issues raised in the YANG doctor review has been addressed. That's it. Any comments?
[00:14:03] Chairperson: Okay. Thanks for for that. Think we will start the working group last call after this meeting. An important reminder is that during that process, we need feedback. So we have, like, at least a minimum threshold of five. That's the very minimum. So please go and and comment because this is the result of the working group, we need to ensure that is good and complete. And okay. Thank you. So
[00:14:46] Remko van Mook: alright. Good afternoon. Chairs, would you like to do the honors, or should I just Yep.
[00:14:55] Chairperson: Go ahead.
[00:14:55] Remko van Mook: Alright. Good afternoon, everyone. My name is Rumko. I'm here to present the draft that I've already presented back in in '20 at 01/2024. Updated IPv6-Resolved IPv4 Gateway. The the very, very, very short version of this is I would like to have a number from the special purpose address registry to use as a sentinel for a default gateway. What is the problem? Everyone every operator here wants and the ITF has been shooting for an I p v six only network. The one addressing plan, one resolution protocol, one filter surface. We're still at the point though where endpoints still want v four connectivity and are probably not gonna be stepping away from that inbound in time. Applications still speak at customers still by reachability, and the ecosystem still expects to shape. And the standard answers today are dual stack or translation mechanisms for x, for x, lab, map, DSLite. You know? I don't I don't need to explain any of that to you guys. The first is a dual architecture. The rest, shortest, does address sharing and trades away the per host endpoint identity. What's missing is the standard for a native I p v four as a service on a v six only segment. Now that may sound a little bit odd, but it actually follows a trajectory that this working group has been in, which is this one. We have RFC eighty nine fifty, which carries v four routes across v six with v six next hops on BGP. Then we have the the draft that's currently last called the v four via v six, which says router to router v four forwarding over v six only interfaces, which interestingly also forwards router to host v six only if you instructed to do so. Then, really, the only thing that's left for this entire stack to play together is actually host a router first hop without our no v four subnet. That's what this draft is about. So the goal is together have a single stack network architecture with dual stack endpoints. And the fundamental problem here is that the entire ecosystem expects a default gateway to look like a dotted quad. Every API, IPAM provisioning, billing system, every piece of tooling, every textbook written about IPv4 expects a v four gateway to look like a v four address. Changing that is gonna take decades. Let's be honest here. I mean, if you look at I think the h e p v six was implement adopted in '20 in 2003 as a as a as an r as a standard. And I think Android adopted it in 2025. I'm twenty two years. So my my stance is don't change what it looks like. Change what it means. And that's what it does. So is this already used somewhere? Yes. It is. You have a a whole bunch of hosting providers who are using all sorts of non standardized versions of having a gateway that is off net and does stuff. None of this is in our any RC. None of it is interoperable. Let's try to change that. And then the mechanism here is really quite simple. You take this special purpose number, and you just stick it into a DHCP for router option. So option three becomes 1920011. And the host receives that as a v four default gateway. And in instead of ARP, it's consults the v four the v six neighbor cache for the router MAC address and then just sends the v four packets towards that on the link layer frame to the first hop and the router forwards natively. The reverse path is v four via v six, which already exists or is about to exist. Let's let's be very clear. What's the interesting thing here? If we do it this way, you can do this completely with in completely incremental deployment, which means that if you start rolling out this gateway on in any normal network with any normal DHCP client and server, it works. And the only thing that actually is required for this to work is the router to answer for our request to 1920011. And then everything works out of the box. Zero host site changes required. And for updated hosts, well, you need to sort of incrementally change over this the the link layer address resolution to a v four v six neighbor cache and eventually eliminate ARP altogether. Because if you only have a single address configured, there is no subnet. There is no local network that you need to ARP for. The only thing that ARP is actually still used for is your default gateway. So how does that work? I mean, I've done both sides verification, done a setup of this. Every operating system that I could get my hands on any rate in a in a reasonable way currently works with this setup unmodified with a router responding to ARP. Updated host, I've built a bunch of reference implementation. This slide is actually out of date. I currently have user space implementations for Linux three BSD, Mac OS, and Windows, incredibly. And there's a conformance lab. There's a separate repo with all of the implementations, etcetera. And what does the router side do? It has a link scope address.
[00:21:18] Tom Hill: Is that? No.
[00:21:19] Remko van Mook: Okay. The return path per RFC eighty nine fifty, a host route per slash 32, however you learn it, and make sure that you don't forward packets with source and destination address of one ninety two zero zero eleven. I'm rushing through this because I'm expecting there to be questions and people at the microphone. Security, what does it do? ARP attack surface is actually mostly eliminated on update to segment. It it ARP is reduced to a single predictable exchange per unmodified host. The Sentinel address itself is topology independent. You'd never see it in forward packets. It's unreachable and unspoofable from off link and ARP inspection and the whole security source card chain around it sort of becomes trivial because the router is really the only legitimate arp responder on the segment, which is very easy to police and inspect. Status. Well, I've submitted the one of the draft end of June. History, I did first did a lightning talk at the right meeting about this, which then quickly followed with IETF one twenty four. I did a zero zero draft in April, got some good feedback from the working group. I updated draft, and it's now zero one. Discussion at the inter area, there's been some discussion outside of the working group as well in the I p six working group at Ripe. There's a Ripe Labs article that I published last week that had some good discussion. Implementation. So this is, again, outdated. I now have five five implementations open issues. There's actually one erratum I have for my current draft. I did I believe there was a there's a there's a there's a no that should be a yes. And there's a couple of open points that we might wanna talk about in working group. And I am requesting or will be requesting the chairs for working group adoption on this. And that is where I would like to leave it right now.
[00:23:36] Chairperson: Okay. We have people on the queue. Lorenzo?
[00:23:41] Lorenzo Colitti: Yeah. Lorenzo Corritti. I have a couple of questions. So do you still need to manage v four addresses for subnets?
[00:23:51] Remko van Mook: So the interesting thing is that if you do this, then you have a flat pool of v v four addresses. So there's no subnetting involved anymore. You can subnet you can do aggregation at at at your pleasure on locality, but you don't need to actually subnet anything.
[00:24:12] Lorenzo Colitti: So v four hosts can might or might not be able to talk to each other depending on what you choose?
[00:24:17] Remko van Mook: Well, they're they're they're always able to talk to each other, but it will always be through the gateway because there is no local subnet.
[00:24:24] Lorenzo Colitti: Okay. So you assign a subnet mask of 32, and you give them whatever random yeah.
[00:24:28] Remko van Mook: And to be very clear, this is a choice you can make per segment. If you do have segments like your home Wi Fi with a lot of lateral traffic, obviously, this would not be the deployment method of choosing. Then you would just go for dual stack.
[00:24:42] Lorenzo Colitti: Might wanna say what the methods are because, like, one one method is that you just assign one IP address to all the hosts because it doesn't need to be it can be the same on all the hosts. Right? Anyway Yep. So another question. Is it a requirement to, and does your implementation follow I p v six routing changes as RAs come and go? Yes. Right. And so it's a requirement to do that? Yes. Right? Because I think that is, like, something that is highly likely to be gotten wrong. And I wonder whether the loss of operational complexity sorry. The these operational simplifications that you bring with this are actually gonna be a good trade off when people get that wrong, and they realize that they can't renumber their v six networks because v four broke, because their v four DHCP implementation can't follow the changes in v six routing. That's do do you Pat, that was kind of fast. Did you follow that? Yeah. Yeah. Yeah. So so that's kind of a concern for me because anything to me that makes it more difficult to renumber v six subnets or to change routers, including, for example, breaking I p v four because of of a bad implementation of this draft is sort of a concern. And I wonder whether that it's worth it. Right? Because you still need to support ARP. You kind of need to support v four on the router. It's not a great simplification.
[00:26:06] Chairperson: Okay. Thank you.
[00:26:10] Attendee: Tobias Sibisch, Turvin. I'm I'm a big fan of the document and would like to see this being adopted and would like to work on it. One follow-up to Lorenzo. Like, I was a bit involved in the whole idea of what we're bringing forward. And the other alternative we had considered was doing DHCP v four over DHCP v six and adding a field to set a v six next to up to DHCP v four, but then we are doing a lot more DHCP. So think this is a more elegant way of doing it still. And there will always be some people who want to have v four.
[00:26:53] Tobias Fiebig: And I actually had to deal with the problem of splitting a slash 28 of IPv4 across 50 ish different routers, and it's possible today. And granted that you have to do the changes to the end hosts, it's unclear whether you can have the host all changed on a given network and whether the operational complexity of living with two different implementations will be
[00:27:23] Remko van Mook: So the the the the the notion is that as long as your router keeps replying to ARP, which I am very definitely considering optional in this in this document. Right? As long as your router keeps replying to ARPS for 1920011, a completely unmodified host as you have on your laptop or any other device today works. Right? Right. The incremental thing is that you actually don't need ARP anymore for that last sort of procedural purpose that is there.
[00:27:56] Tobias Fiebig: Exactly. And that's that's my question is, would we get away with just saying, hey. The routers will reply for that address ARP and be done with it. Yep. And then we don't need to modify the end host. Yep.
[00:28:16] Attendee: I wonder whether it might be beneficial also to describe what happens on the return path because it's sort of like outside of this document. And I wonder, is this probably all written with the mind that there is, like, point to point link. There's only one host on the network, so it's quite easy. Or it's a managed thing where it's, like, statically predetermined. But if I think of DHCP v four, and I would just configure DHCP to dynamically give IP for addresses from the pool to random, computers as they go, how exactly the default gateway of the network will figure out where to send the return traffic?
[00:28:53] Remko van Mook: Well, that's that's exactly what v four via v six does and whether I have the so there's an implementation in in the repo that is on the screen right now that actually, I mean, does, like, a a very simple simplified DNS mask plus scripts that does this. But the the thing is that if you have a v four via v six deployment where you already have a v six next hop for a v four prefix, there's absolutely nothing stopping you from having a slash 32 v four prefix having a v six next hop and that v six next hop actually being a host. And that's and so I intentionally didn't write it into this draft because it's sort of treading into the territory what's already there because v four via v six basically already does all of this.
[00:29:49] Attendee: Alright.
[00:29:55] Attendee: Lorenzo, mentioned earlier that you're concerned about not being able to renumber the v six network if that somehow gets pinned, I guess. I'm not sure how that would happen. As far as the next hop itself is concerned, that's a link local address. And what what v six global numbers you have should really not be relevant for this at all. To be
[00:30:14] Lorenzo Colitti: for default. There's nothing that that's. Says for that.
[00:30:16] Chairperson: Please go go go to the mic, please.
[00:30:19] Lorenzo Colitti: Failure mode is that the user space daemon does the app lookup only once, resolves it to a v six router, and never changes it. Okay. That's an easy part.
[00:30:27] Attendee: You're you're assuming the link local address in v six might refer to a different device at some point later. Okay.
[00:30:34] Lorenzo Colitti: Might get swapped.
[00:30:34] Remko van Mook: Okay. Okay. I I I already so to to to to I I already ran into all of this
[00:30:41] Lorenzo Colitti: Yeah. Yeah.
[00:30:41] Remko van Mook: And building implementations, and it's actually very trivial to to resolve this. So if
[00:30:49] Éric Vyncke: you
[00:30:49] Remko van Mook: would like to have a look at the implementation, by all means, do. It's already there. And and, no, you you definitely do not want to one shot this at the host site. You do wanna keep track of. And there's two ways of doing this. One is a very simple one. If your operating system actually allows you to set a v six NextUp for a v four address, then you basically just copy paste the v six Next Top into your v four routing table. Which can change. Which can change, and then you and then you do it again. So you did this you need to keep copying that out. And the other alternative that I found, which I had to use for Mac OS and Windows, is basically not change the routing table entry, but set the static ARP entry for the gateway, which then tracks the v six default gateway.
[00:31:41] Lorenzo Colitti: Static ARP seems better. Yeah. I what I wanted to say, it was it was different from that. I I mean, it's still that's still a concern I have. But the the thing that in the presence of a legacy host, you you're you're kind of not saving anything at all on the network side. And and so what I don't understand is, like I I do agree with the sentiment here, but it seems like you can do this with purely with I p v four today. You basically sign slash
[00:32:04] Remko van Mook: You can absolute I mean, you can mostly do this with v four today.
[00:32:10] Lorenzo Colitti: But It's like your static ARP entry is
[00:32:12] Remko van Mook: I mean, you so so, basically, the the the do nothing approach here is v four. But the elegance is you can actually drop a bunch of the complexity you have with v four right now with ARP and and your and your layer two resolution and just fold it in. And, I mean, I would very much like that to be in the working group discussion because I I think there's a way forward to be found. And I think having the working group sort of complete the arc of having v six, v four being routed across v six next hops all the way down to the host as a standard set, I think, would be very good.
[00:32:52] Lorenzo Colitti: So yeah. So I guess I guess I would say I support maybe adoption, but as long as it's not a solution that we're adopting but a problem statement. Because it you know, like I said, you can achieve the same thing by send by handing out slash 30 two's and I p v four slash 30 two's subnet addresses, and it just works. You can even assign the same address to everyone. And then because you have to keep ARP working anyway, that's just gonna work, and you don't have to change anything. And it achieves this pretty much the same thing. Plus, wanted to, like, go back to what Andre said. But but but, anyway, so he was like, well, how does the reverse path work? Well, it turns out for the reverse path, we have two protocols that can do this. One of them is called ARP, and one of is called ND, and they both only sport one protocol. We don't have a discovery protocol for v six v six extra three four addresses. Right? So so that's another complexity that we'd be adding here. So we are removing complexity. We're we're batting different failure modes. So I guess, yeah, let's maybe work on the problem, but maybe not necessarily tie ourselves to, like, using v six over v six Next up as a solution.
[00:33:56] Chairperson: Okay. Okay. Thank you. So we will follow-up on the working block question on the main list. Okay. Thank you. Thanks. Salim? Just one sec.
[00:34:21] Salim: Hello, everyone. My name is Salim. I've been working for a while on this thing called ILNP, the identifier located network protocol, which is both the name of a protocol and an addressing architecture, which is the main thing that is the result from the work I've been doing. The addressing architecture is based on I p v six components, and it changes the way that addresses are used in the end system stack. So on the left is the thing you're familiar with for, for example, transport state where you have both port numbers and you have both addresses as part of the end system stack. What ILNP does is introduce two new data types instead, an identifier that is bound to a node, not an interface, and a locator, which is a label for a network. So that can map, for example, to a network prefix. And then the bindings for those within the end system stack change. So now the transport layer stack only uses the identifiers that remain stable while the transport session is in progress. The locator values are mutable, and there are dynamic bindings between that new TCPN system state and these locator values. And this enables a whole load of things like dynamic multi homing, multi path capability from the address management point of view at the network level, and so you can build whatever you like on top, including multiple transport protocols, etcetera. This is based on research that I've been doing, at the University of Saint Andrews. K. So that's the basic idea behind it. How this works in terms of mapping to IP version six protocol components? Well, first of all, at the addressing level, the top there, you have the picture you're probably familiar with, which is an IP version six address. And at the bottom is an identifier locator vector. So this is the combination of a locator and a node identifier, which takes the place of an IP version six address within the packet that's sent. And, of course, the bindings, as I've said already, are different at the end system. So the locator has the same syntax and semantics as an address prefix in IP version six, but the node identifier is bound to the node as a whole, and those semantics are handled by new code in the operating system managing the bindings in the stack. We need to make sure that works over I p v six, and we've been testing this over a number of hackathons. And from an I p v six router's point of view, it just sees a normal I p v six packet. But when that packet gets to the end system as on the right, the source locator, the source node identifier, the destination locator, and the destination node identifier are handled separately, and this enables a number of things. I'm not gonna go over all the details of what it can enable. Very happy to answer questions that I have videos and screenshots and graphs from various hackathon, events where we've been doing testing on this. A couple of other protocol components are required to make this work. First is a destination option header in IP version six, and this has to be in every single ILNP packet. So there's two, serves two purposes. One is to identify that particular v six packet as an ILNP packet. And also because it contains a random nonce value, it gives some protection against certain off path attacks. Another protocol component is a simple handshake in ICMP that allows these locator values to be dynamically updated to enable things like mobility and dynamic multi homing and multipath capability. Those things are already defined in some RFCs, and we've been implementing those, testing them at hackathons, as I've mentioned. And through experience and feedback from various folk, I want to propose some changes, and that's what I have done now. There are some drafts, and I'm gonna walk through each of those to say what they're doing. But all these drafts basically encapsulate what we've learned from implementing this and feedback from others to try and make, IslandP much more friendly to the network to I p v six, both from an application point of view and from a a protocol point of view at the line level. This is just a screenshot from the hackathon that was, last Sunday, where we've just done the last lot of testing. And this actually uses locator and node identifier values from the DNS to run iPerf. So iPerf thinks it's running over I p v six, but in fact, it's running over ILNP. So one of the things you can have, for example, on the right is the client for iPerf just turns on multiple interfaces as the flow progresses, and the, throughput is fairly stable because the address management is at the network layer. Of course, if you were to press this hard, it would struggle because Cubic, the congestion control doesn't know it's going over multiple parts, and so it would start to complain. But nevertheless, the connectivity is maintained. Okay. So what are these different drafts? The first one, I'll just call the preferences draft, and you can have multiple locator values and node identifier values in the DNS that can be fetched as normal through get ADRA info. And this is really mainly for future ILMP aware applications. Those can have preference values, and the preference values are 16 bit unsigned integers. Lower preference is preferred, and it allows you to make an ordering for node identifier values and locator values to use as you like. And in the absence of any other policy or application specific requirements, that draft also says how they should be ordered. So it's not really for v six applications as such. It's for tidying up for future ILNP applications. The next draft, I'll just call textual representations. Very simple, intent for this. If I want to write identifier locator values, and I want to write an ILV, an identifier locator vector, and I want to clearly distinguish it from an I p v six address, I need a new notation for it. And so this just defines what that notation is. So at the top of the diagram there, you have two values for IP version six addresses, and the numerically equivalent identifier locator values are just shown on the line below. So that's all that draft is doing is saying, this is how you would write these values to distinguish them from I p v six. The next draft I'll call the nonce draft. And in the original RFC, the way the nonce was used was a little vague. In fact, it was very vague. It said that the nonce should be included in the initial packets for a session initiation, and that was that was pretty much it. But in fact, through implementation, we found it's best to include it in every packet to have a randomly generated value in that packet that's unique with respect to the initiator and that it's bidirectional. K? And the reasons for doing this are explained in the draft with some use cases, but that's just hiding up something we know that we've implemented and that works. And then the final draft I call the I p six apps draft. This is how you can use ILNP for existing I p v six applications today without modification. So the screenshot I showed you of iPerf was just a standard iPerf three binary. It's a v six binary. Wasn't recompiled. Wasn't re engineered. It can work over IPv6, and this graph just says how we do that so that the use of ILNP, underneath the v six application is intentional. You know you're really doing it, and it gives you no surprises. The way you use it is predictable. The idea is that I'd like to progress these drafts to experimental status because that's the status of the original RFCs just so that people who do want to implement this do have, some documentation of what we know over many hackathons now actually does work and gives you connectivity from at least from the hackathon sites back to Scotland. So at the very least, you'll be able to communicate to Scotland, but we have done some other tests in the lab between, Scotland and various other countries and between The US and some various other countries. So the idea for these drafts is really to improve compatibility with I p v six on the wire and with applications, so to make Ireland p more I p v six friendly. And that's it for me. Happy to take any questions. Thank you. Thank you.
[00:43:37] Chairperson: Well, having no questions, I think we have to move to the next agenda item. Thank you. Is Ron in the room? And it's not remote.
[00:44:13] Presenter: He was
[00:44:13] Chairperson: here. He's here. Yeah. Okay. But maybe we can we can move to the next one anymore. Eric? Yep. That's you. It's you. It's you. Let me
[00:44:39] Éric Vyncke: thank you. So Éric Vyncke, Cisco. As I said, I am in AD, but I'm presenting here without my head even if the request for this draft is coming from the ISG. So during a meeting with the ISG and the IANA, we discovered that couple of registries dating from ten or twenty years ago are missing some elements. For instance, they lack restoration procedure. Is it specification required? Is it ISG approval? Is it first come for serve and so on? So big question mark there. And some of them are completely unused and won't be used anymore. So we want to get some fixed. That's a very short draft, which is two, three pages so everyone can read it very easily. And I'll go through this. I was shocked when I discovered that the I p v four, yes, I can still talk about I p v four. Right? There was a registry for the TTL, the tank to lift. Obviously, everyone is falling out of his chair. Thanks god. There's a carpet below, so everyone is safe, but we will close it, basically. Right? There's there's no point. There is one which was used to transfer a NetWare option over the h e p v four. I run NetWare a year years ago when I was young. Maybe 30% of the room run it when they were young, but many people have even no clue what I'm talking about. Right? Looking at you, David, and others. He's not even listening to me. So this one will be closed. I mean, the intent is to close it. Right? Two other one that are terminal names. It was used for Telnet. It's still the term and the environment variable. Right? There was a registry for this, but I think everyone now is putting whatever they want there. So no restriction procedures. I simply want to make them first come, first served. If Jody wants to have Jody best terminal, he will get it. Tom will get your Tom worst terminal. No problem and so on and so on. Right? Simply send an email to the Anna and you get an your entry there. So there is some security consideration to it, obviously, because we can put offensive words in the name. I can do what you do with right now. The last one is IP option for p v four. It's actually a little bit complex. They are one byte that can be chained. They are two bits indicating specific thing and only five bits really. So 32 code points for them. If you look about it, the five bit code points means that we have only 32 entries, and a lot of them has already been used, zero to twenty five and thirty. Don't ask me why we don't use 31 and some whatever. Right? Long time ago. Bill Fenner years ago twenty years ago, has reserved four experimental a p v four option. Why four? Remember I say, yeah, two bits for different meaning. So all the combination of those two bits plus one value. Then for another Gong, there's a couple of code points. Those are p v four option. There is also other thing that says paper, I p v four option and not an option. Whether we agree with it, yes or no. But, basically, it says, don't use it. They will not fly over the Internet for sure. I mean, we know that p v six extension headers travel the Internet, but not everywhere and not so easy. Right? So that's something. So the point and I changed my mind based to some feedback that I received. My original intention in dash zero zero was to close this registry. I faced some opposition in the mailing list as well as on the ISG, so it will move to ISG approval. So it needs basically, like every document, no discuss. Right? That would be a point of any agenda if there is a draft arriving or requesting this kind of option. And, basically, that's it. So I would love to get some comment and review on the list. And, of course, Thierry, which is one of the guy who opposing the closing of registry. He's on the queue. We will talk to him shortly, But I would love to get working group adoption and most probably immediately after working group last call because there is basically little to comment. So happy to to talk to you here.
[00:49:27] Thierry: Yes. I I wanted to ask. So you say there are only 32 code points. And on the one hand, that's true, but we have four four categories, and two categories are fully, are are reserved. And we have, basically, in most implementations, the seven bits as, let's say, the distinction for the various options because one bit is for the copy. So and I wanted to basically yeah. Found it strange that that that this is so a harsh topic, apparently, also from from comments. Also, I I read the IP options are not an option paper, of course, and I put some comments in my in a in a draft that I that I put also to the mailing list. And this is I I think this basically blocks the entire so so not giving out IP option numbers would block entirely the, let's say, future use of IP options. So I I I like the idea that the Internet engineering steering group is would take this over. But I had a question, what would be then the the criteria? And and can we make IPv4 options? Let's say an option for limited domains. Yeah. This is this these are my concerns because we wanted to actually use this technology, and we were unhappily surprised by, let's say, the heavy resistance a little bit on the mailing list. And, yeah, that's that's that that that is what I wanted to bring in. Thanks.
[00:51:29] Éric Vyncke: So I I think just for the people in the room, I get some conversation. I I think all of conversation here, the way I public, but you have a specific use case in mind for IPPM, if not mistaken. Yeah. So but by the way, I forgot to add. There was an IB statement that says no work anymore in the ITF for IPv four only thing. We need to redo our stack. And we need to talk at some point of time. If I understood your use case correctly, there are other options. I mean, there are alternatives to use I rather than using IP option for what you want to do. There is a way to define new transport protocol. Right? And I it has been done notably for IPSec. So don't focus too much on the I p v four option. There are most probably other ways of doing it. And the criteria, if you come at the ISG, I don't know. It will depend upon the ISG. I will not be there after March. So who knows?
[00:52:28] Chairperson: Okay.
[00:52:28] Éric Vyncke: I'm sorry. I I understand you're not happy with the answer. But, honestly, I'm I'm sincerely believe that there are other ways than using a p v four option for your use case.
[00:52:40] Thierry: Yeah. One one thing I could consider is, let's say, something like the option headers in I p v six. So that could also be a a way of getting forward in this domain. You could maybe even have the similar approach in I p v four, I p v six.
[00:53:01] Éric Vyncke: Yep. This will be possible. Yeah. And, anyway, right, again, as far as I know, your use case is within a limited domain. For some definition of a limited domain, both of us agree on the what is a limited domain here? Talking about you indeed. But there are four experimental code points. Use them if you have no choice.
[00:53:29] Thierry: Okay.
[00:53:31] Attendee: Thank you.
[00:53:31] Chairperson: Yep. I'll
[00:53:33] Tom Hill: be very quick. Tom Hill from British Telecom. I actually, without any of my network nerd hats on, I really like old hardware. And there's a machine names registry full of things like Amigas and CD 30 twos and wonderful things like that. A real big problem that we have in that kind of little space is that there's not enough archiving going on. So it's just a plea really to make sure that any information that is made defunct, that make sure it is perfectly archived somewhere, you know, someone who's gonna look after that for posterity.
[00:54:04] Éric Vyncke: Which is perfectly fine. First come, first serve. Feel them. I mean, those registries are kept Right? They are I say, first come, first serve. If you the existing entry stays there, right, forever. I mean, for some definition of forever. And you can, if you want, add new ones. Or may I maybe it looks like I didn't understand the question.
[00:54:28] Tom Hill: No. Generally, all I'm saying is is if we remove some information, so there's a registry that gets deleted, turned off, making sure that it is archived somewhere. It's backed up. Someone actually cares about it.
[00:54:39] Éric Vyncke: The money, we don't delete stuff. So
[00:54:41] Tom Hill: Yeah. Alright. Thank you.
[00:54:43] Chairperson: Thank you, Eric. Thank you.
[00:54:45] Éric Vyncke: Thank you for the time. So we can go press call call for adoption?
[00:54:49] Chairperson: Yes. We will follow-up on maybe this. Yes. Yes. Is Ron is not yet here. Right? Okay. Is Richard here? Yes.
[00:55:15] Richard Patterson: Hey. Afternoon, interior. My name is Richard Patterson, a coauthor of this individual draft that we are calling DHCP explicit rate signaling. The problem that we're trying to solve with this draft occurs when the end to end service rate differs or is smaller than the physical interface or local interface speed or line rate. In a typical PON based fixed line broadband topology, an example, a CPU router is often connected to an ONT at one gig, 2.5 gig, or even 10 gig Ethernet these days, but then the customer is only purchasing a broadband product of, say, 400 megabits in this example. The issue itself is then that CPU router lacks the visibility of that 400 megabit service speed and is unable to configure itself for AQM or L4S. So the alternatives that I know other people are using to work around this issue, some ISPs are using TR 69 or three sixty nine to configure a managed CPE with these values that are provisioned in the OSS stack. But this sort of unmanaged CPEs will miss out on this, as well as other downstream access nodes in the path will also miss out this visibility. TR101, Broadband Forum, specifies some vendor specific options that get inserted by the access node, the DSLAM or the OLT, for the access line characteristics, upstream, downstream speeds, but this is generally for the benefit of the BNG or upstream and the radius, etcetera. These options are stripped off and do not make their way down to the CPE router. So this draft proposes some DHBV-four and DHBV-six container option to carry these upstream and downstream speed values to the client. DHBV-four has eight bit code option length and an eight bit length field. V six has 16 bit code field and 16 bit length field. The sub option codes are the same across both address families. We have eight bytes for upstream speed and eight bytes for downstream speed. We've also got a byte to signal whether the speed should be represented, or is represented as layer two or a layer three rate. Helps when we have DHB Relay agents in the path as well, or access nodes are doing DHB snooping. These devices can then passively inspect this option and act on it if required. So in this example, the DHB server is centralized, it's off the BNG. The BNG itself is a Relay Agent, and that's typically where you'd see these rates enforced, so it can inspect that and enforce it on the BNG. But likewise, so can other access nodes down the path also inspect it in the Relay header. This one's perhaps a little bit more controversial. We have specified that those Relay agents in the path could also add, modify, or delete this option. This is in conflict with nine thousand nine fifteen. The example I've given here is when the BNG So the DHB server itself doesn't know about the option, the speeds, so the BNG asks Radius. Radius tells it what the speed is. The BNG, as a relay, could then still insert it and pass it down. Realize this is potentially contentious, but there are real world examples of this type of behavior happening already. So yeah, a question of whether we should be updating 99.15 for this. Yep. So we would like to hear from people who have experienced this issue. I think it's an issue if you think this is a useful solution, if you have alternative solutions you think are better. And then we're also not sure where to pitch this draft as well. So whilst the charter doesn't prevent the DHC working group from picking up option codes, options we created. They typically don't like doing it there, and I believe that ADs are keen on closing that working group. But, yeah, as I say, we're potentially updating 09/2015, maybe, there. The Transport and Services Working Group, perhaps, they have a vested interest in this sort of stuff, or using these values. Personally, I think I'm quite keen on the Interior Working Group, hence why I'm here. But yeah, also open to other suggestions, so yep. And that's it.
[01:00:57] Attendee: Just a simple question. If you have this example that you had there where you have, like, service of 400 Mbits and, well, on a on a link that escapable of much more. And you said that you have options for the h c p v four and v six. Will both v four and v six show 400? And if yes, does it mean that the ACP can produce 400 v four and four hundred v six at the same time because this link is capable of that?
[01:01:24] Richard Patterson: Yeah. So we did that was one of the issues we worked on recently in in the current revision, talking about that sort of potential race condition between the address families, what do we do about it. We of agreed Well, we settled on We had one option of we just keep it stateless, and whichever one comes in last is the winner, or the lowest is the winner, or highest is the winner, those sort of options. What we've written at the moment is keep a state table, basically. So, yeah, keep a state table for both.
[01:01:55] Attendee: So can like, the should it account, like, both address families together somehow? Should it submit for for this purpose?
[01:02:05] Richard Patterson: Implementation specific. We haven't defined what the client should do with them, just that the client should record them and keep track of v four says this, v six says that. Okay. Thank you.
[01:02:18] Stuart Cheshire: I'm Stuart Cherisher from Apple. I I think there's a gap somewhere in this mechanism. On on your first slide or slide two, you you said the assumption here is that the CPE cannot do any kind of queue management. And if it can't do any queue management, I don't see how using DHCP to tell it the rate it should manage is helpful when our basic assumption is that it can't do that.
[01:02:48] Richard Patterson: Right. So if I verbalize it can't do any AQM, perhaps I misspoke, it it can't do effective like, if it doesn't know what rate it should be using, then it can't configure that specific rate. So it could do something. It just won't have visibility of the the rate. Therefore, how effective is it actually going to be?
[01:03:08] Stuart Cheshire: I think in in the spirit of trying to make a helpful suggestion that we'll let you deploy what you want today Appreciate it. Without waiting ten years for home gateways to get updated to support a new DHCP option, this seems like a discussion for transport area more than it is for inter area, and networking is complicated. People can't know everything, so there's no criticism implied. The end device, whether it's your computer or your iPhone, is easily able to put out 10 gigabits per second without breaking a sweat. So the question is, why doesn't your iPhone send 10 gigabits per second all the time? Because it could, and that is transport protocols. And anything on the path there, it doesn't have to be the CPE. If you are selling 400 megabits to the customer, at some point, you have to have some enforcement to make sure the customer is using 400 because that's what you're selling. And that enforcement can be anywhere on the path, and you either ECN mark the traffic to say, you've hit the threshold. I'm I mean, imagine you know how a slow start works. You make a TCP connection. It sends a little bit, and then it sends more, and then it sends more, and it's pushing to see how much the network will put up with. And when it reaches the 400, the network says, okay. That's your limit stop now. And you either use ECN congestion marking for traffic that supports ECN. You can look whether it says ECT in the IP header, or if it doesn't, then you drop the packet. And and that is what causes the sender, whether it's TCP or QUIC or Zoom video conferencing, whatever it is, once you start dropping or marking packets, it slows down. And if it really doesn't slow down, if somebody's just writing some malicious UDP sender that blast packets out, well, you just throw them all away. They're not going anywhere useful. There's no there's no incentive to do that because the person doing that gains nothing from it. They're just sending packets to dev null as fast as they can.
[01:05:15] Richard Patterson: Yep. Yep. So and that enforcement point where you're you're kinda referring to there is is on the BNG. That would be you'd be doing the, you know, dropping in l four s aware behavior. The CPE itself could also I think perhaps maybe the reason why it's still valid or useful is in the other direction. Upstream, if you're uploading to Dropbox or something, and then the CPE, yeah, it's things that's got a two and a half gig interface and it doesn't.
[01:05:44] Stuart Cheshire: So this this is maybe the non obvious thing. When you're uploading to Dropbox, it doesn't matter where on the path the packets are marked. The the sender will send 400 megabits because any excess above that gets dropped and it learns that that's counterproductive, so it stops doing it. So you don't have to police the traffic at the CPE. Policing it anywhere on the path results in 400 megabits end to end, and I'm standing here because that may not might might not be obvious. The other thing to look at is Kundeschepper Yep. Has got some really interesting work on a very lightweight traffic policer. Virtual traffic shapers are expensive because they actually queue packets. They buffer them and meter them out at a certain rate, and that takes RAM, and that takes timers to do that. Traffic policers historically have been very destructive because they just discard packets with no warning. Has developed a traffic policer that uses ECN marking. So instead of trashing packets with no warning, it actually gives a polite warning to the sender, which is you have reached the contracted rate, so stop now. And it's very cheap to implement. It's very effective. So here's, I think, an Internet draft. It's called SRM, and that's worth looking at. And that's deployable today, which is the benefit.
[01:07:08] Richard Patterson: K. I think I got those points. The first one, I think I think you're referring to the future where everything is, you know, is is L4S aware and can mark ECN and and and knows how to behave these things, and it's an ideal world. We're probably away from there
[01:07:28] Stuart Cheshire: yet. I'm I'm actually describing the way things have worked for the last thirty years.
[01:07:33] Attendee: Yep. K.
[01:07:34] Stuart Cheshire: Customer service. Let other people speak. I don't wanna place the microphone. I'm happy to talk to you afterwards on the break if that's helpful.
[01:07:43] Tim Winters: Tim Winners, QA Cafe. So first, you know, when we've traditionally seen this, we see this. I think you had it up there. USP t r 69 is how most people deal with this. It is underserving the people who don't do those things. So I think it's an interesting proposal. I'm wearing my DHCP chair hat. The you know, traditionally, we look at options. This, to us, looks just like another option, and we think that that kind of work doesn't belong in our group. It belongs in places like this or all the stuff that Stuart said about transport. We're here to support you guys to review the actual what's in the option. But from our perspective, this should be happening Yeah. Someplace else.
[01:08:21] Richard Patterson: I I think to the perhaps previous point about transport, I I I think I personally was steering away from transport because we're not telling the clients Yeah. How to use it or how what to do with it. We're just providing them the information, fixing the visibility problem, and then what they do with that is
[01:08:39] Tim Winters: Yeah. So, you know, from from my perspective on the CPE side, I think this is an interesting idea from the DHCP chair. Hat. We're here to help, but I don't think it should be in our group. Thank you.
[01:08:52] Éric Vyncke: So Eric Greenk is the responsibility for this. I would say, yeah, welcome to Interior. We are kind of the default route, right, for everything, which is IP layer. I mean, we discussed together before, right, but to the benefit of everyone. And I I think it's nice to do it into the upstream and the CPE because I think the main reasoning is to avoid overloading or congesting everything between the CPE to the BNG in when some link are shared, right, I think to the benefit of it.
[01:09:18] Richard Patterson: Yeah. Yeah. And and these ONT devices typically have shallow buffers and not much, and they're pretty harsh places.
[01:09:23] Attendee: So yeah. Okay. Thank you.
[01:09:28] Chairperson: Thank you. Thank you. Yes.
[01:09:59] Presenter: Today, I will show you my work name Security Requirements for IP Tunnel Nodes. As we know, the IP node is readily used in mining net networking serenials, including IPv four and IPv six translation, overlying networking transaction, traffic engineering, and so on. However, if a terminal node accepts a package from the authority here or forwarding invited in inner package without validation, it can intentionally become open relyer, enable to source source address spoofing or even, pass by extension filter, policy. Internal nodes are all now deployed almost everywhere in the data center, VPN, overrely, networking, and so on. As many internal endpoint become public, unreachable, the attacks, forces, natural expanded. Our ex recent research public on using security, find a large number of public, accessible terminaling hosts, on the Internet, such as in the in this figure, It demonstrates that certainly security security is no longer a theoretical issues. It has become a of optional concerns that deserve a standard security guidance. We reserve the extension RFC related to terminal documents such as those in the table, define the terminal mechanics or provide security considerations for a specific specified mechanism. However, they do not define a general security framework for turning those. Important topics including peer peer authority, so source address, validation, forward scope, turning, and IPvC extension headers, and the operational guidance either more missing or no longer capability. Our draft's commitment, the extension RFC, by providing a unified set of security requirements that can be applied across a different terminal mechanics. Before define the security requirements, we first describe the general terminal nodes processing model. In this pipeline, consists of the four stage. First, the node, validates the outer package and its source. Second, it opens the package. Third, it's well, this is a inner package, includes a source of stress verification and forwarding scroll of checks. Finally, it's either forwarding the package or delivers local according to the routing policy. Based on the this precise model, our draft defines the complement security framework. The frameworks includes a source address validation, IPv6 extension header, processing, security default configuration, and reclusive incapsibility, limited limited telemetry and optional management. Instead of instructed mechanical solutions, we focus on common security principle that apply to multiple tunneling technology. Our goal is to provide end to end security framework for tunneling those implementaries. The first requirement is a secure default configuration. Turn only should be disabled by default, and the terminal should not accept a terminal package from the authority resource. Transactors are forwarding this capability. Captions should also be disabled on use administrator intentionally enable it. In addition, man management's interface must be properly protected. This recommendation help providing academic pros pros pros caused by the default settings. Source address validation is normal requirements. For the other package, the sender should be authoritative and authorized for this inner package. Exhausting source address validation mechanics should be applied whenever appreciated. We also cram the four forwarding export validation package towards targeting the loopback, addressing most most data calls to address or other resisting destinations should be discarded rather than forwarding. Together, those tags significance reduce spoofing attack and the policy bypass. Reclusive in capsulation requires can be, explored as a resource or try trigger forwarding loops. Therefore, turning those should enforce configuration management maximum encapsulation. The our address requirement default maximum tips of no more than three. Package extensions are limited should simply be dropped. The provider is straightforward mechanic and to imitate the rescue encapsulation attract attacks. The IPv6 extension had the requirements and also additional processing commitments. Ternary nodes should process only the header that's necessary. All supports that all suspicious extension header should be discard. To avoid extension providing overhead, we also recommend limitation, the maximum extension header change, lens to eight. Those recommendation, improve both robust stake and, implementation consensus. Finally, security also defines the optional variable. Terminal nodes should generate load locks for the security level events, maintains useful contents for mallet monitoring, supporting encoding, investigation, and provide a security configuration management. This capability help operational operator detect attacks, troubleshooting problems, and, maintain security terminal deployment over time. Just to conclude, this draft proposed on unified security framework for IP terminal to note IP terminal nodes. Thank you for your attention, and welcome to any question and comments.
[01:18:08] Chairperson: Thank you. We have people on the line. Team?
[01:18:18] Éric Vyncke: Eric, you are
[01:18:19] Chairperson: Eric.
[01:18:20] Éric Vyncke: Eric, special ahead here. Have you read RFC sixty one sixty nine, which is about a p v a bit general consideration Yeah. And security? There is one RFC, sixty one sixty nine, if I'm not mistaken in the number
[01:18:42] Presenter: Six.
[01:18:43] Éric Vyncke: Which make a lot of things. Other point, good set of recommendation. Right? Many of them may already exist somewhere. The slide the the point number eight, maximum depth of recursive execution, and nine about the a p v six extension headers.
[01:19:01] Presenter: Yes.
[01:19:01] Éric Vyncke: I don't think they are really security issue at all, so they should not be there.
[01:19:10] Presenter: Why you don't think so?
[01:19:12] Éric Vyncke: That's a comment. Right? So
[01:19:14] Presenter: Okay. Okay.
[01:19:15] Éric Vyncke: Feel free to ignore.
[01:19:24] Chairperson: Okay. Yep. Okay. Yes. So we have one more comment.
[01:19:26] Thierry: Yeah. Thank thank you, Eric. So I had also a question about the extension headers. Because, basically, if you drop packets with extension headers, then you go the same way as many as in the IPv four four world, where then, basically, the extension header, framework becomes completely unusable. It is probably already partially unusable for IPv six, but it was nevertheless, yeah, designed so that you can ignore what you don't need as far as I understand extension headers and and IP options. So please take that into consideration.
[01:20:17] Chairperson: Okay. Thanks for the comment. Thank you. So thank you.
[01:20:35] Yushan Yang: Okay. Hello, everyone. I'm Yushan Yang. Okay. I'm here to introduce our draft to enhance ICMP error message authentication. Here's oh, okay. Here's the background. As we all know, the SMP protocol is essential to provide feedback to the Internet. However, the there's a inherent challenge that is validation of SMB error message is weak. All pass attackers can forge SMB errors to deceive the victim's TCPIP stack to trigger some unintended cross layer interactions. Based on our works before, we have concluded four classes of cross layer vulnerabilities. The first one is information disclosure. That is a lower layer field where unintentionally ex expose up layer secrets. The case is API ID side channel. We found that our fast attackers can send some false SMT PTP error message to force the victim's IP layer to change its IP ID generation policy. The vulnerability is found in Linux, and this will create a side channel where the IP ID counter will leak the up layer information such as TCP sequence numbers as the tagger can and hijack the TCP connections. The second one is state desynchronization. That is different protocol layers have an inconsistent view of our shared resource. The case is actually fragmentation injection attack. We found that our our pass attackers can send some also can send a fault false SMPPDB error message to desynchronize the passive m two value between the IP layer and the TCP layer, which will cause the TCP segments to be fragment fragmented as an IP layer, and the tagger can inject some malicious IP fragments. The third one is semantic validation deficiencies. That is a protocol receives a control message that it cannot fully validate. The case is s SMP redirect traffic hijacking. The attacker can use abuse the SMP redirects message with a forced UDP datagram to trick the victim's tag to accept the error message and then hijacks the traffic or denial of service. The last one is source authentication failures. That is the lack of source authentication, which will allow attacker to impersonate a trusted littered entity such as router or access point. So how to solve this problem? We have as inspired by TCP RFC five nine six one. When receiving our TCP reset packets, it should not be accepted directly. Instead, the and how should check the should challenge it with a challenge act packet. So we prove our mechanisms that is when receiving an SMP error, the should not directly accept it and update the pass m two value or update the network gateway. However, it should embed a stateless computing in the next outgoing packet for that flow. The it can be computed with by a hash function with a secret key and the flow information, and the lungs can be embedded in the opt off option field of the next outgoing packets. So you can see, as for the verification on the left diagram, the real onpass router, which can see the and reflects a challenge packet and prove it is on on the pass. However, in a attack offpass attacks scenario, the attacker cannot say the lungs, and then they cannot forge a valid response so the attacker will fail. Here are some updates since since ITF one to two. So the experts asks, why not just check the embedded packets of the SMT error message. So we found that the checks only works for TCP protocol because its headers have some contain some secrets, such as the sequence numbers, which is 32 bit non. It's hard for an off pass attacker to guess. But we found that for state of this UDP or SMG protocol, the headers have no secrets. They are trivial to fold. So this is a vulnerability we want to fix. And we have written the document to be our direct technical specification. And as for multi pass routing, some expert want to know what if the package takes a different pass. So in a single event, the challenge will miss the original router. But as a and the validating host receives no confirm about the challenge, so it will equal all the first ICMP error message. But as the mechanism is stateless, if the application sends a new package that hits a a same problematic pass or the problematic router, it a new ICMP error message will be triggered, and the process can be restarted. So we have added a new section to discuss this problem. Oh, that's that's all about my presentation. I'm happy to take your comments.
[01:25:47] Chairperson: Thank you. We have people on the line. Yep.
[01:25:49] Éric Vyncke: I'll be quick.
[01:25:50] Tim Winters: Tim Winners, QA Cafe. So RFC443 says has a magical line about checking the packets that you come from. There may or may not be test programs that do that. It is optional. You know, not every host does check those packets, but it it works if they do, which is why they should. So I there's a bunch of extra stuff here. If we just actually check the offending packet, it it should work. I have other questions about where you say it doesn't work. I'd like to work through those with you, but I can do that off list.
[01:26:22] Yushan Yang: Thank you.
[01:26:24] Éric Vyncke: Eric Link, no special hat. Your challenge packet is a simple ICMP request. Right?
[01:26:31] Yushan Yang: Sorry?
[01:26:33] Éric Vyncke: Your what you say, the ICMP challenge?
[01:26:35] Richard Patterson: Yeah.
[01:26:36] Éric Vyncke: You are sending an ICMP request with the data being the challenge?
[01:26:42] Yushan Yang: No. We just we use the next outgoing package that is from the application. We just mark the flow, and we embed our challenge in the option field of the next outgoing packet. We do do not use a new s m g a reply or else.
[01:27:04] Éric Vyncke: Okay. I will read the draft. It will
[01:27:06] Attendee: thank you.
[01:27:07] Yushan Yang: Okay. Thank you.
[01:27:08] Chairperson: Thank you. So we have three minutes. I don't know if Greg but Greg is
[01:27:25] Éric Vyncke: Thank you.
[01:27:26] Chairperson: To be as fast as possible.
[01:27:30] Attendee: I'm a be talking about reordering draft. So this is actually the third time that I've done a presentation on this in Interia, and just wanted to give updates on the draft. So first of all, why is this important? So we've got a situation where some very commonly used layer two links, think Wi Fi, think five g, think also DOCSIS cable modem networks, think they have to do everything they can to deliver packets in order. And in doing so, they add a lot of delay to packets that are not benefited by by being reordered. Because these layer two links aren't aware of the layer three context, aren't aware of the layer four context, they're delaying packets that are unrelated to the the packet that might be late arriving. So in the end, this functionality adds more degradation than benefit. An example case here is Wi Fi. So somewhere between one in 10% of the frames that are delivered on a Wi Fi link need to be retransmitted. All the other frames that arrive in the packet aggregate are held waiting for this retransmitted frame. And, again, many of them may be for other connections or TCP connections, quick connection connections, etcetera, and or delayed unnecessarily. The delay could be hundreds of milliseconds. So again, adding delay for for not much benefit. Updates from the draft. So we added a section on IPsec. Also had a discussion of CGNAT and IP fragmentation, some statistics on Wi Fi links, and then new reordering guidance. So no time to go over this in detail, but please take a look at the draft. And what are we missing? I'm sure we're missing some things. If you have other ideas on on ways that the IITF could provide better guidance to layer two links around reordering, resequencing, please let's let's try to get this issue solved. This is important because in September '11 is beginning work on what will become Wi Fi nine. There's a window of opportunity here. If we want something different from Wi Fi that we can potentially get that into eight zero two eleven. Similarly, discussions are happening in the six g arena around what to do about resequencing in six g. So I think that's about all the time I have. So I would like to get this adopted. There's been some discussion as to is in area the right place, or is there some other working group that's the right place? I don't know the answer myself, but I'd be open to thoughts and questions or comments on that.
[01:30:30] Chairperson: Very quickly, please, Ernesto, because we are out of time.
[01:30:33] Lorenzo Colitti: Thank you for writing this down. I think personally, I think it it would belong in TSVWG because that's where the standards that suffer when this isn't performed. I would advise against using the word reordering because reordering typically means packets are out of order. And it's very confusing what it actually means. You can and so, you could try to find another word.
[01:30:56] Attendee: Thanks. Yeah. Actually, draft does define, terms. Reordering means putting things out of order, and resequencing is putting them back in order. Although it's sometimes terribly difficult to
[01:31:06] Lorenzo Colitti: And you say introducing reordering, which it's not possible.
[01:31:09] Chairperson: One more time. Okay. Thank you very much, and meeting is finished. Thank you. So we need to ask Eric.