On Sat, Jan 31, 2026 at 8:38 AM Sue Hares via Datatracker <[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. > 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? 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. > > 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. 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. 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. 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. - 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. > - 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? > | 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? -------------------------------------------------------------------------------------------------------------------- > | 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". -------------------------------------------------------------------------------------------------------------------- > | 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. -------------------------------------------------------------------------------------------------------------------- > | 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. > > -------------------------------------------------------------------------------------------------------------------- > | 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/ - 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. The clients of which I'm aware show the end-to-end timings like ping does, yes. 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. Bill
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
