Session Date/Time: 19 Mar 2026 08:30
Wassime Haddad: Okay, let's get started. Hello everyone. Welcome to the IntArea working group, IETF 125. I am Wassime Haddad, co-chair, and with me today is Juan Carlos Zúñiga from Cisco. So let's go quickly through the chair slides. Note Well, I think by now you have seen this slide many, many times. Just a quick reminder, you have all consented when you participated in the meeting to follow our code of conducts. Please keep in mind the session is being recorded. Make sure you sign in using Meetecho and use Meetecho to join the mic queue. And please make sure your audio and video are off unless you are chairing or presenting during a session. So the agenda is available on the link that you can see. And our agenda today, we have six items. We're going to see again the problem statement for the cross-layer vulnerabilities due to forged ICMP error. And we are going to see a new draft about ICMP query for node information, and a broadband network user plane specific information sub-option for the DHCP relay agent option. And we have a draft about extending ICMP for multi-path and a presentation about DNS at the IETF at the end. Quick housekeeping. So, want to remind you please that each time we start a working group last call, it's very, very, very important that we get at least five reviews to progress the draft. We have had some issues before with some draft. It's not enough to say, "Yes, I support, it's good." But not good enough. We would like to see people really reviewing and providing feedback for the authors so we can move the draft forward. So, finished working group last call, we have a draft that is waiting for an updated version, the draft-ietf-intarea-rfc8335bis. The shepherd is waiting for the authors to submit an update and then we can push the draft to submit it to the IESG. And we have three drafts already submitted to the IESG. So let's get started. The first presentation. Erik, please.
Erik Vyncke: Can I just go on stage by the way? If you want to go, go. I was just about the three drafts that are missing. The proxy has been currently in the IESG evaluation. It will be most probably approved in early April. The Node ID, I'm waiting for a revised ID to approve it for more than 180 days now, so I don't know what's happening there. And the V4 Next Hop by V6, AD review has been done, I will start the, I think even the last call has been started. So we are progressing well. It's just the status.
Wassime Haddad: Okay, thank you. First presentation, please come.
Li Zhaoxi: Hello everyone, I'm Li Zhaoxi from Tsinghua University with my colleague Ao Wang. And I'm here to present "Problem Statement for Cross-Layer Vulnerabilities due to Forged ICMP Errors". As we all know, ICMP is the internet essential feedback mechanism, but it has an inherent challenge: the validation against ICMP error is weak. The attacker can easily forge ICMP error to deceive the victim TCP/IP stack. Based on our research, we classify four cross-layer vulnerabilities: information disclosure, state desynchronization, semantic validation deficiencies, and source authentication failures. The first one is information disclosure, which means a lower-layer field unintentionally expose upper-layer secret. There's a example, IPID side channel. A forged ICMP error can force the victim IP layer to change its IPID generation policy. This creates a side channel where the IPID leaks information about TCP layer events. The attacker can observing the IPID increment and then infer the TCP sequence number to do TCP session injections. The second one is state desynchronization, which means the protocol layer have an inconsistent view of shared resources. There's a good example, IP fragmentation injection attack. A forged ICMP error can desynchronize the path MTU between the IP and TCP layers. This cause TCP to generate segments that are unexpectedly fragmented. The attacker can then inject malicious IP fragment which incorrectly reassembles with legitimate ones, and this will cause a packet injection. The third one is semantic validation deficiencies. The meaning is a protocol receive a control message that it cannot fully validate. The example here is ICMP redirect traffic hijacking. The attacker can forge UDP datagram and a corresponding ICMP redirect message. And the victim stack check the embedded header in the ICMP message, find a matching but forged flow, and accept it and redirect. This semantic gap in validation leads to traffic being hijacked. Last but not least is the source authentication failure. The meaning simply is a lack of source authentication allow attacker to impersonate a trust network entity like a router or access point. The example here is wireless network routing cache poisoning. The attacker can impersonate a AP to send a forged ICMP redirect to victim on a Wi-Fi network. The message contain a crafted UDP payload to bypass validation check. The victim accept the redirect, poisoning its routing cache and make the attacker its new gateway. All subsequent traffic is redirected through the attacker who can intercept or manipulate it. So what is the mechanism? As studied by my colleague, ICMP error messages for stateless traffic are easily forged by off-path attackers. To fix this, we propose challenge-confirm mechanism. Here is how it works. First, the challenge. Upon receiver an ICMP error message, host B embed a stateless and computed nonce in the next ongoing packet for the flow. The nonce is a hash of a secret key and flow information. Second, verification. As you can see in the left diagram, a real on-path router sees and reflects the nonce, proving it's on the path. However, on the right diagram, an off-path attacker never sees the nonce and cannot forge a valid response. So the attack fails. Then we have a summary of all updates for the past IETF meetings. So after IETF 122, we try to answer three questions about state storage, amplification attack, and packet lost. And in IETF 123 and 124, we also try to resolve three questions. Question one, why not just check the embedded packet? The reason is that the check only works for stateful TCP, since its headers contain secrets like sequence numbers that are hard for an off-path attacker to guess. But for stateless UDP and ICMP, the headers have no secrets. They are trivial to forge. This is exactly the vulnerability we are going to fix. The draft now better emphasize this. Question two was about story-based document style. We have rewritten the document to be a direct technical specification. And question three was about multi-path routing. What if a packet take a different path? In a single event, the challenge will miss the original router and the host receives no confirmation and ignores the ICMP error. But what happens next is a stateless recovery. Since our mechanism is stateless, if the application sends another packet that hits the same error again, a new ICMP error is generated. This restarts the process, a new independent challenge will be sent. A new section rewrite is added to discuss this problem. That's all about our revision. We are welcome to collaboration and comments. Thank you.
Wassime Haddad: Thank you. Any question, comment? Ron, go ahead.
Ron Bonica: A quick question about the nonce. You said that it's computed from a shared secret. How does the secret get shared?
Ao Wang: We try to simulate the mechanism like sync cookies. The secret key may be a secret key used like in sync cookies. It may be a secret key maintained in system. It may be refreshed several minutes once a time.
Ron Bonica: Does this mean if the attacker could observe the sync cookies, he knows the shared secret?
Ao Wang: Yeah, if the attacker knows the secret key, it can attack the mechanism. But the secret key is maintained in the system level, so it's a hard thing to steal the secret key.
Ron Bonica: But doesn't it have to be shared as part of the session? It's not pre-shared ahead of time, is it?
Ao Wang: Yeah, it may be shared by different session. We will take this problem into our future consideration. We now consider this secret key may be used by the host and shared by different connections. We use hash to generate session secret, so it's hard to doing the invert. You cannot infer the secret from the shared keys. And our target is off-path attackers. For off-path attackers, it's a difficult thing to have such a secret key on the host. It typically cannot observe traffic between the host, between two host in communication.
Wassime Haddad: Okay, any other question? Thank you, gentlemen. Next item. Ron, are you going to present?
Ron Bonica: Yes, thank you very much. Okay, we would like to introduce two new ICMP messages for a very specific purpose. Let's say one peer wants to ask a question of another. Any question. We'd like to introduce two new messages: a Query Request that requests information from a node, and a Query Response that responds to it. It's generic for any question in the world. Next slide. What's the syntax? Both messages include an ICMP extension structure. An ICMP extension structure includes objects. We will define many objects. Each object represents a piece of information. So the object identifies the question that it's asking and leaves a little space for the answer. So you send a query with the object, you get a response, the object or possibly its response flavor comes back to you. And there's an example of this in draft-ietf-6man-icmpv6-ioam-conf-state. It's a way to ask questions about the IOAM configuration state. And we will define many new objects as needed, one for each new question. Next slide. So, a few more things. The Query Request and Response are defined for both ICMPv4 and v6. Like all ICMP messages, they must be rate limited. And in fact, these might be rate limited more strictly than other ICMP messages. Not so much because we're worried about the bandwidth that it might take to service these, but it might actually require some CPU to figure out what the answers are. So these might be rate limited a little more strictly. And the Query Response must not be longer than the corresponding Query Request. This prevents amplification attacks. Next slide. Why did we use a new ICMP message type? We had two options. One was the Information Request. We didn't use that first because it was deprecated, and second because we couldn't put an extension header in it. It was only good for the information that it requests today, or that it used to request yesterday. And why didn't we use the Extended Echo Request and Extended Echo Reply? First is because we didn't want the ping semantics that those messages bring with us. Second, there's some confusion around those messages as to whether the extension structure is the last member in it, because people have implemented those messages in funny ways. Probably we shouldn't use them anymore for anything. Next slide. The next slide is an ask for review and comment. Also, we'd like to adopt this as a working group item as quickly as possible. And the reason why is other at least one other draft depends on it already, the draft that we mentioned a couple slides back about IOAM state. And that's it. Questions?
Jen Linkova: Hi Ron. Can you hear me?
Ron Bonica: Yes.
Jen Linkova: So, I quickly looked at the draft and after your slides I have a question. So you go away to deprecate 8335 or what?
Ron Bonica: Do you mean does it duplicate RFC 8335?
Jen Linkova: Yeah, like Extended Ping.
Ron Bonica: In very many ways it's like RFC 8335. In fact, with 20/20 hindsight we should have done this generic query-query response back then. But back then I was thinking about only ping and came up with something that was much, much less generic than we should have had. Now, it's actually possible that you can put an interface identification object in these two messages and they could replace the Extended Echo and Extended Response. But since Extended Echo and Extended Response is widely deployed, PROBE is widely deployed, we might as well let them continue doing what they're doing, and for all new applications we'll use this generic message.
Jen Linkova: Hmm, okay. So, I don't remember what your security consideration section says. It's kind of a bit scary when you say you can ask whatever. I'm just a bit afraid that people might like block it just in case because they don't want to explicitly enumerate what your router could tell you and what could not, or should not.
Ron Bonica: I forget exactly, but I think there is a response for each object. One response is, "I don't support this object." Another response, if it's not in there it should be, "I do support this object, but I don't want to tell you the answer to the question you're asking."
Jen Linkova: Yeah, I'm more thinking about like, let's say I have a router, how do I configure that stuff, right? So we probably need to be like a little bit more specific about that, right? Do we want by default like everything to be I'm not gonna tell you anything and permit explicitly and so on? That's just my concern. But yeah. Okay, thank you.
Ron Bonica: Dave.
Dave Thaler: Hey Ron, can you hear me okay?
Ron Bonica: Yes.
Dave Thaler: Yeah, so I have a similar-ish question, but mine is about RFC 4620, which is the IPv6 Node Information Queries, which is a generic object in that sense that it contains the ability to have multiple types, not just addresses. And it does have replies that you can say, "Here's the reply," you can say, "I'm not going to tell you," and you can say, "I don't know." So those things it does have, it's experimental but it's 20 years old. And so I guess my suggestion to you would be in this document, you should have maybe a section on prior work and how this is different and whether it obsoletes those or whatever. Because clearly, I mean the one that I'm talking about was experimental, you could say well this is the replacement for that experiment, or this uses that experiment, or here's the failures in that experiment. Right now you don't reference the RFC that Jen was talking about or this one. And so I would say what's the difference, and it would be great if the answers were in the document, because right now it looks like it's duplicating the intent of RFC 4620, maybe with some improvements admittedly, but it's really duplicating the intent of that one.
Ron Bonica: Okay, let's see. If it's RFC 4620, it predates the extension object. So there's probably a good reason why we want to do something new so we can have different objects in it. Thank you very much. We'll put in a section that talks about RFC 4620 and RFC 8335.
Dave Thaler: Okay, thank you. And so I can't comment on the adoption as working group item until I see the differences and stuff. And then I might have an opinion, but right now I don't have any opinion. So thanks, Ron.
Ron Bonica: Okay, thanks a lot.
Wassime Haddad: Thank you. Any other question? Okay, thanks Ron. Third item, is Chenyang in the room? Okay.
Chenyang Wen: Good afternoon chairs and experts. This is Chenyang Wen from China Unicom. The title of my presentation is "Broadband Network UP-Specific Information Suboption for the DHCP Relay Agent Option". And other authors include Lin Zhu and Yutao Zhang. So this draft has three main part. The first one is Broadband Network UP-Specific Information Suboption. This part include the format of UP-specific information suboption.
Erik Vyncke: Excuse me, Erik Vyncke. No hat. I read briefly the draft and I'm pretty sure many people in the room have no clue that UP means user plane. If you are not in 3GPP, you don't know. For me UP was upstream, but UP it's user plane, right?
Chenyang Wen: Yeah, yeah. So we can supplement. I have the same issue. So let's continue. In the first part, UP-specific information suboption include format and SGRP ID and UP identifier considerations. And the second part is DHCP relay agent behavior and third part is DHCP server behavior. So let's start with the motivation and problem statement. In the control plane and user plane separated broadband network architecture, user planes backup function as multiple UPs to the same UP backup group, forming a backup or load sharing relationship between multiple UPs. And SGRP is a group of subscribers together that share same backup state. So we think the best practice is the same SGRP on a specific UP shall be assigned addresses from the same address segment. So there are a question. Since the DHCP server cannot know the subscribers are born by which UPs, it may assign addresses from different address segment to subscribers on the same UP, which is not conducive to address aggregation on the UP. So in this draft, we add a sub-option to the DHCP packet, enabling the CP to add SGRP information and UP information involved in the DHCP request messages. So let's move on to the format of UP-specific information suboption. These three figures shown the format of DHCP messages, relay agent information option and sub-options. So based on this, we design the format of Broadband Network UP-Specific Information Suboption. The field include code, length, reserved, SGRP ID and UP identifier. SGRP ID means the ID of SGRP, which should be any integer value between 0 to 2 to the power of 32 minus 1. And UP identifier means the identifier of UP, which currently carrying the group of users and corresponding to the SGRP ID. So next, the considerations of UP-specific information suboption. The first one is SGRP ID considerations. The SGRP ID should be fixed, and the CP which is the DHCP relay agent should use the single identifier value constantly for a SGRP. And the SGRP ID used by a relay device should be committed to stable storage unless the relay device can regenerate the value upon reboot. So second, UP identifier considerations. The UP identifier should be fixed and unique. And if the UP identifier configured in the relay agent is not unique within its administrative domain, resource allocation problem may occur as the DHCP server attempts to allocate the same resource to subscribers behind two different UPs. Then UPs cannot implement IP prefix convergence. So let's move on to the DHCP relay agent behavior. The DHCP relay agent is assumed by the CP. And the DHCP relay agent should be configured to include the relay agent information option when relaying DHCP messages. In order to support the UP-specific information suboption, the SGRP ID should be correspondingly to the SGRP configuration parameters in the broadband network CP. The UP identifier can be loopback address of UP or other identifiers. As for DHCP server behavior, this sub-option provides additional information to the DHCP server. If it is configured to support this sub-option, the DHCP server may use this information to first divide the address pool into small blocks using the SGRP ID and UP identifier as indexes. And second, allocate an address in the address block indicated by the SGRP ID and UP identifier. The next steps, we will consider the impact of this sub-option on network security and solicit comments and refine the draft. That's all my presentation. Thanks for your listening. Questions and suggestions are welcome. Thank you.
Juan Carlos Zúñiga: Thank you. Any questions, comment?
Erik Vyncke: So Erik Vyncke, responsible AD for IntArea. I think we talk about it by email. Do you intend to also, as long as the DHC working group exist, I think this draft would be better suited in DHC? Now, DHC working group will close most probably in one year or two from now, so depending upon the timing it may end up in IntArea or move to DHC. DHC working group is not meeting this week, so that's a nice way to present it here. Reading the draft, there are many I think very specific terms like UP, SGRP, I guess it's subscriber group, but as the reader, if you want to get good review from this draft, which is mandatory for call for adoption, you need to be sure that it's readable. So all the specific acronyms that are there like AN, I guess it's Access Network, but I don't have to guess when I read a draft, right? So I need to be sure. Need to be cleared, right? So you need to really to explain everything there. Another point that kind of scares me, if you go back on a couple of slides, one of the first one when you were showing the packet format, the one before this one I think, it takes time. It's obviously a DHCPv4, right? Yes. And do you intend as well to do the same thing for DHCPv6?
Chenyang Wen: Maybe we will consider it a next step. Now we haven't considered.
Erik Vyncke: So now putting back my responsibility hat, it will never be passed to me, right? At the IESG evaluation if it doesn't support V6. Just to be clear, right? But it's most probably that it's very easy to do. But it will not pass, okay? Okay, thank you. Thank you and thank you for the work.
Juan Carlos Zúñiga: Okay, then please ask for feedback on the mailing list because we haven't seen any activity on the IntArea mailing list, so it would be good to continue the discussion. Okay?
Chenyang Wen: Okay, okay. Thank you. Sure.
Juan Carlos Zúñiga: Okay, thank you. Next item. Is Li Zhang in the room? Okay, he's here. Let's go.
Li Zhang: Good afternoon everyone. This is Li Zhang from Huawei. I'll introduce our work on extending ICMP for multi-path. Okay, here is the introduction for traceroute. Traceroute use ICMP Time Exceeded message to collect the nodes' information along the route, including the IP addresses and the host name of nodes and other information. Based on that, RFC 4884 redefines the ICMP message to support multi-part operation. It defines a new extension structure at the end of ICMP message to carry the additional message. So RFC 5837 extends the ICMP message with a interface information object to carry the interface information including the ifIndex, IPv4 addresses, IPv6 addresses, the name and also the MTU. And in addition, RFC 8335 defines a tool which is named PROBE which is used to query the status of an interface by sending an ICMP extended echo request message. The echo reply message includes a state field to reflect the state of the ARP table or neighbor cache entry to indicate whether the interface is reachable. So the motivation for our work is that the traceroute is typically used to collect the information of a single path. When using traceroute in a multi-path topology, which means we can have multi-path to the destination, then the traceroute can only get one of the path information and don't know that there are other paths that can go to the destination. So as shown in the figure below, there are six nodes and there are two paths from node A to node F. And the ECMP is enabled in node B, then the traffic can be forwarded in both paths. But if we use traceroute to get the forwarding paths, we can only get one of them. So if there are some mistakes or problems on another path, then the traceroute is very hard to locate it. So we define a new ICMP extension object which is named the multi-path interface information object to collect the multi-path or the multi-interface information. In this object, we define a C-Type which indicates the types of the interface information. It can be a IPv6 interface or an IPv4 interface. And then it has a sequence number and a total number which indicates the sequence of this interface and the total number of the interface that can reach the destination. And in the we also have interface indicator which can control the following multi-path interface information in this object. It can control the interface ifIndex, the IP address, and name, MTU and also other information in the following. So the multi-path interface information carries the detail, the multi-path interface information as specified in the information indicator field. For the information we reuse the ifIndex, IP address, name, and MTU formats that already defined in RFC 5837. The next hop and state information is new in this object. For the next hop bit indicates that whether the IP address sub-object is exist for the next hop. And if both the IP address and next hop bit are set, then the two sub-objects must be placed in order. And we also have the state bit which indicates the interface state sub-object is included. The format of it is the same as defined in the PROBE tool. Okay, and so since this is the zero-zero version, so I would like to ask whether the motivation and use case is clear and whether it is fail-in face-in the IntArea working group. And we also would like to collect the comments and suggestions to improve the document. That's all. Thank you.
Juan Carlos Zúñiga: Thank you. Any question, comment?
Erik Vyncke: Erik Vyncke, no specific hat. As you ask for "is it clear", clarification question if you don't mind. So it's still an ICMP return message by extension done on hop limit exceeded. Right? So you get information only on one node. How do you detect then that you are using a different path? If you can come back on the slide with the topology. This one? Yeah. Yes, so if we with this extension, the node B will return the two, there are two interfaces information, right? For to C and to D. Then the traceroute in the following traceroute packets, it can use a different UDP port number to let the traceroute packet go through another path.
Erik Vyncke: Yeah, but the node generating, if you do a trace route let's say from A to F, the node generating the ICMP with this specific option will be the router F on the right hand side. Correct? But how does it know if there are switches? It has no information about the layer two path. Only the switch E, if it's a switch, it will never generate a hop limit exceeded. Or is it a router as well, the E?
Li Zhang: Sorry, I didn't get your question. What's the matter with switch E?
Erik Vyncke: So for the traceroute packet you add the TTL every time. Yeah, and you for example you generate a ICMP packet and you from A to B and to C and to E and to F. F is the end, is the destination node. Right?
Erik Vyncke: No, actually maybe there's a misunderstanding here. But a normal trace route, you send packet from A to G or H, which is not even on the picture, with varying hop limit or TTL if you are using IPv4. And all the routers, not switches, routers, layer 3 device, when they forward it and they find the hop limit becoming zero or one depending upon the version, they generate an ICMP error. Right? So is it what you are doing? That's routers, layer 3 device. So now maybe your graphic is wrong and you should have put in routers then switch.
Li Zhang: Yeah, I think is wrong maybe we should write routers. Yeah.
Erik Vyncke: But then you will get, in this case, you will never get, if the trace route, I mean the packet with the varying hop limit follow the path A, B, C, E, F, node D will never receive such a packet, right? He will never, right? So even with the option, I don't know how you can get information.
**Li Zhang:**With this extension, the router B can return the interface information that "I have two interfaces that can reach to reach the destination". I have interface to C and I have interface to D, that both of them can reach to destination F.
Erik Vyncke: Okay. So if you do the trace route and sorry if I understand very slowly, when you do the trace route from A to F, that's the node B, which is a router, that will send the information which is useful.
Li Zhang: Yes, yes.
Erik Vyncke: It will say there are two in my, in my FIB I got two entries for instance.
Li Zhang: Yeah, yeah, I have two interfaces.
Erik Vyncke: Ah, okay, okay. Thank you. You may want to clarify to clarify this in the draft with maybe one example, because honestly right now I mean on the slide is not really clear.
Li Zhang: Okay, thank you for the explanation.
Juan Carlos Zúñiga: I see no other hands, so.
Wassime Haddad: Okay, thank you.
Erik Vyncke: Yes, one more point Wes, if you are still online. Getting small groups, right, with kind of different conflict, also allow the scheduling exercise. And Warren in the room will remember that when we scheduled the agenda for this week, we got multiple conflicts. So if we split in small group, maybe with less conflict than having a big group with thousands of conflict, makes things way easier.
Wes Hardaker: Yeah, the other thing to note about, especially related to Warren's concern is, one advantage of the dispatch function would be that it would be an indication of where a draft was going to go. So, it doesn't state it explicitly anywhere because nobody stated it explicitly enough for us to really write it down, but everybody DNS-related should probably attend the dispatch mailing list and interim so that they could see what direction or to what group something they really cared about was going was going to fly. There's not a huge amount of information or comments that that distills from, but but there definitely was some of that.
Erik Vyncke: And the last point about the dispatch: even if you dispatch one draft like the DHCP thing that we got here in IntArea, we can move it to DHC working group and back here. So don't be fooled and you know it, right? But don't be fooled by the working group being a silos and draft being stuck into one working group. We can move it. It just, you put it the documentation and my slide said that, you know, there will probably be those rare cases where something will move because, you know, it changed from "well, it seemed like an operationally simple comment and, you know, thing" until we ran into real issues and now it has to go to development.
Erik Vyncke: Yeah, look about DNS multi-Q type, right, for instance. Okay, thank you again.
Wassime Haddad: Okay, thank you very much, gentlemen. See you in Vienna. Thank you. Thank you.