Bill: You are correct that I could have stated the missing items in section 9 more clearly. I apologize for the wording of my review regarding the “lack” of security section. Please see the clarification of the specific issues.
See my detailed comments inline with your questions. Your work is a very important addition to the toolbox of Internet debugging. If correctly coded and deployed, it could really help network operators. Therefore, I tried to think about the problems rather than just a pro forma review. Sue PS – As always, your work is careful and well-thought out. From: Bill Fenner <[email protected]> Sent: Tuesday, February 3, 2026 12:41 AM To: Susan Hares <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-intarea-rfc8335bis-02 early Opsdir review On Sat, Jan 31, 2026 at 8:38 AM Sue Hares via Datatracker <[email protected]<mailto:[email protected]>> wrote: It has two issues as a document (not a technology): it lacks a management/operations considerations section and a security considerations section. I'm a little confused as to what you mean by "lacks ... a security considerations section". You may think that section 9 is insufficient, but I think there are other ways to say that. The management/operations section should provide tips for managing pings/probes within a network to prevent overloading routers or hosts. Ok. I'll write a management/operations section. Sue-2: Are you planning a yang model for configuration? If so, it might help this section. If not, The Security section should talk about the critical information found in interface names, identifiers or addresses. The spec already talks about interface names: For example, a malicious party can use PROBE to discover interface names. Having discovered an interface name, the malicious party may be able to infer additional information. I could see adding some text saying that you can use PROBE to discover interface addresses and neighbor addresses, but I don't have anything to say about that fact other than "if you don't want them to do that then don't enable PROBE" - do you have more specific text about what is dangerous about this? Old text:/ However, malicious parties can use PROBE to obtain additional information. For example, a malicious party can use PROBE to discover interface names. Having discovered an interface name, the malicious party may be able to infer additional information. Additional information may include: * interface bandwidth * the type of device that supports the interface (e.g., vendor identity) * the operating system version that the above-mentioned device executes Understanding this risk, network operators establish policies that restrict access to ICMP Extended Echo functionality. / The term “critical information” in my comments implies information that reveals things about critical network infrastructure (interfaces, bandwidth, routers, devices, or OS) that allows attackers to gain access to a network. We’ve been using “critical information” in this fashion in routing documents. Your comment:/ I'm not sure what critical information there is in the interface index. Perhaps the concern is that if they are densely allocated, it's easy to find out how many interfaces a router has? Suggested wording would definitely help me understand the concern here./ You understand the issue on the policy at a router or device. I agree that you must be able to enable/disable the functions (ICMP Extended Echo, L-bit, specific query types). However, you need to protect the passing of configuration information or monitoring information via secure means. Otherwise, snooping can gather things from configuration leakage. You provided an excellent addition with the VPN PROBE being specific to a VPN. Well done! NITS: 1. Section 1.3 needs to untangle the English in this sentence to multiple sentences. ...It can be written as 2 sentence to clarify. Ok. 2. Technical NIT - RFC8335 behavior being extended. Sometimes, it is just necessary to code around the bad behavior of initial implementations. However, the authors should realize that the IESG really, really hates a document that codes around the bad behavior of an RFC that is being deprecated. This is what the working group decided to do and I've been working on for 2 years. I'll wait to hear from the IESG that I've been wasting my time. [Sue]: Sigh, understood. We’ve both been at 2 year work where the IESG says “no”. Best wishes for a “yes”. Just thought you should think about this carefully. The bad behavior also allows some data to be passed after the Interface Identification Object without having any checksum or integrity. Seems like a questionable concept. I was looking for the security section to explain to me why you thought this was reasonable. The data is covered by the ICMP checksum, so it does have a checksum / integrity. And the data is only processed (if at all) by the originator, so I fail to see the danger. Bill. Your work is always amazing. Would you kindly point what these two paragraphs mean then? I’m now confused by the text which checksum these two sections describe. Section 1.3 This document defines a unique use of ICMP Extensions [RFC4884]: while normally, ICMP Extensions are defined to start at a given point and continue to the end of the packet, if the extension object is an Interface Identification Object as defined in this memo, then the extension structure (including the checksum) consists only of that single ICMP Extension Object. From section 2. * ICMP Extension Structure: The ICMP Extension Structure contains an Interface Identification Object that identifies the probed interface. The checksum in the ICMP Extension structure covers the Interface Identification Object but not any (optional) data that follows. This confusion raises this issue to a “please explain or resolve status”. 3. Editorial NIT section 2.0, paragraph starting with Section 7. last sentence old text/ The behavior when it contains a different Extension Object is not defined by this memo but may be defined in the future./ New text:/ The behavior when it contains a different Extension Object is not defined by this memo./ We are the IETF, new standards can always update old standards. The last clause for this sentence is not needed. Well, it was requested by a previous review. To some people, it's obvious that the IETF can change its own documents, to others, it's important to state the obvious. I'm afraid I have no way to satisfy everyone here, other than add the text and remove it and wait for the next review to request that it be added again. For now, with your forgiveness, I'll keep the current text. [Sue]: I am fine with it being kept as is. 4. Compliance with operational guidelines (optional but recommended): - Fault Management: Are failure detection/recovery mechanisms specified? Error handling for packet fields is covered in ICMP Message Processing Code Field processing. It would be good to know what happens, if experience (which is evident by the bis), has denoted any other failure conditions. I think the document is pretty complete in its coverage of error conditions. I do not know of any other failure conditions. Sue: Ok. Just checking that a machine does not get overwhelmed by Fault processing as a DoS. Have implementations been tested for DoS attacks using PROBE message? You are usually very careful with testing on code prior to writing IETF documents. - Configuration Management: Are configuration changes to enable/disable the feature clearly defined? The configuration is hinted at in main document and Appendix A (with application). =It would be useful to know if a YANG model is planned/exists. Section 9 has a list of several configuration items. No YANG model exists or is planned. [Sue]: So, configuration is being done by configuration mechanisms specific to a vendor. How is the configuration for this important feature protected against attack? - Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly identified? I did not find hte performance metics for correct operations of the code. I'm not sure what you're looking for here. Should we be stating that the implementation shouldn't take too long to process and respond to the packet? [Sue]: The appropriate thing would be to give some general guidance (in management section), and then give to the IESG some test results from existing implementations. What inquiring minds want to know is “what type of load this feature places on a device?” Again, based on your past excellent work with protocols, I hoped your specification was created from lessons learned from multiple implementations. I just hoped you pass on some of this hard-won knowledge here. | Review Item | RFC 5706 Considerations |----------------- |------------------------------------------------------------------------------------------------- | deployment | As a BIS, this document must have hints for deployment and managed in a network. That wisdom | | | is missing (probably should go to manageability/operations section) | I feel like this advice applies to a more complicated protocol. Would you ask for deployment hints for ping? [Sue]: Yes. Actually – Ping is one of the wonderful features that “grew up” with the Internet. It glues things together. This feature has the same potential. -------------------------------------------------------------------------------------------------------------------- | Migration path | The RFC8335 path plan is to allow "stuff" after ICMP Extension Structure. When "stuff" is | | | allowed after valid fields without an integrity checksum, bad things can be passed | The ICMP checksum covers the "stuff". [Sue]: See my earlier confusion based on the text in sections 1.3 and 2.1. Three things are possible: 1) I totally misunderstand your text, 2) Your text has a NIT in the text, or 3) there is a real bug. This comment was because of the text in 1.3 and 2.1. -------------------------------------------------------------------------------------------------------------------- | transition from | It would be good to know if early deployments have found any problems when transition from | | RFC8335 to bis | RFC8335 to this solution. Does this solution help ward off DOS attacks? Is there a place | | | during the transition that might cause operational issues. | There's no real transition, since this document describes the only thing that was ever deployed. I found zero implementations of RFC8335 that did not also include the additional data handling described in rfc8335bis. [Sue]: Good news. Did I miss that in the text or the appendix? -------------------------------------------------------------------------------------------------------------------- | Impact on network| What happens when this protocol gets used to attack a node? Is there more traffic on node | | Operation control| when this happens: | plane | | There's no opportunity for traffic amplification, if this is your question - it's like attacking someone with ICMP echo. [Sue]: There are DDoS attacks with ICMP echoes. For example, Ping attacks (rate of ping), Smurf attacks (amplification from proxy node), Ping of Death (too large packet). It might be nice to understand why PROBE or policy around the PROBE protects you against these attacks. What configuration policy turns on something that protects each attack. And if the policy is correctly engaged, it might be nice to indicate why SMURF and Ping of Death are not possible. Now if the WG stated these DDoS should not be covered in the document, it will ease your way through the IESG to put the information in the shepherd’s report. -------------------------------------------------------------------------------------------------------------------- | Verifying Correct| Has a test plan been written for performance for this new feature? if so, can it be shared? | | Operation | Do utilies show up ETE probe timings like Ping timing? What load on routers or hosts? | I've written some test resources, https://github.com/aristanetworks/probe-tools/<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_aristanetworks_probe-2Dtools_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=yR9RCJVbYVwK1wGet6QnfGpKcT1rYVGkfc3jKhnFTkwVegFmYV6wx76Ay5j2GP8L&s=iC_r4nsJJD24TbtO4ZHMzNt3iUWLHtqkW5Ss4I0qDi8&e=> - there's no test plan per se. This git repo contains a straightforward client to send a query to a responder and print the response, and a synthetic responder that returns every possible response so that a client's handling of a given packet can be tested without having to set up a router with a given configuration. [sue]: These probe-tools shows the careful think that I’ve come to expect from you over the years. The clients of which I'm aware show the end-to-end timings like ping does, yes. [Sue]: I noticed that your appendix showed hints of this. Hence, I asked the question. The load, of course, depends on the implementation - e.g., if it uses a linear search through a linked list of thousands of addresses, it will be slow - but a well designed implementation results in a minimal load because it is a straightforward information lookup to respond to any given query. [sue]: This is the point I wanted to you to make some place as a “hint” to avoid bad implementations in the field. You have probably experienced some devices with less “clue” in the code be incredibly slow for this reason. Bill
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
