PROBE: A Utility for Probing Interfaces
draft-ietf-intarea-probe-10

Note: This ballot was opened for revision 07 and is now closed.

(Alia Atlas) Yes

Suresh Krishnan Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2017-12-13 for -09)
No email
send info
-1.2: There is at least one lower case MUST. Unless that is intended as normative, please consider using the boilerplate from RFC8174.

-8, last paragraph: "MUST NOT leak information" seems more like a goal or a statement of fact than a normative requirement. (I think the 2nd MUST in that paragraph describes the real normative requirement")

(Benoît Claise) No Objection

Comment (2017-12-14 for -09)
No email
send info
No objection to the publication of this document. However, some comments.

So basically you specify the same functionality as remote ping MIB in RFC4560 where
- probing interface = SNMP manager
- proxy interface = SNMP agent
- probed agent = destination
Right? So any connection with RFC4560?

I guess this mechanism is a similar functionality as RFC 6812, where
- proxy agent = sender
- responder = destination
... even the technology is not based on the ICMP extended echo
As such I believe that the RFC 6812 IPR applies here as well.
However, I'm not the one to make the call. So I will forward to the appropriate persons.

Potentially the OWAMP IPRs apply as well.
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-ippm-owdp

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Warren Kumari (was Discuss) No Objection

Comment (2017-12-14 for -09)
No email
send info
In the version I'd initially reviewed there were codes for things like: "E (Ethernet) - The E-bit is set if the A-bit is also set and IPv4 is running on the probed interface.  Otherwise, the E-bit is clear."
I was going to fuss and ask what makes Ethernet special -- but, seeing as this is removed in the newest version I have nothing to fuss about. :-)

The below was originally a DISCUSS, changed to NoObj -- but wanted it noted:
This is, I believe a minor DISCUSS, and I'll happily clear it once a commitment is made that it will be addressed / on the call (AKA, I'm not going to hold up the document, but there isn't a "Comment" and "Very important comment" in the datatracker).

Stefan Winter's OpsDir review contains:
"* Introduction
states "[...] if it appears in the IPv4 Address Resolution Protocol (ARP) table [RFC0826] or IPv6 Neighbor Cache [RFC4861]." "Appears" is a rather loose word, as entries in those tables can have multiple states. E.g. for IPv6, which of the states DELAY, STALE, REACHABLE do you mean? All? Or only a subset? In IPv4, do you mean the "C" flag exclusively?
Also, when the proxy operates remotely (i.e. bases the reply on ARP/Neighbor Cache rather than ifOperStatus), does it actively ping the interface in question itself? If not, how does it handle an interface address which is not in the ARP/Neighbour table simply because the entry has timed out? The interface might be up and active nontheless. In such a case, reporting "does not exist" is false."

Ron Bonica's suggested solution in: https://www.ietf.org/mail-archive/web/int-area/current/msg06136.html works for me, but I do not see it in the version being discussed. This would make a substantive change to the document, I wanted to draw attention to it.

Mirja Kühlewind No Objection

Comment (2017-12-14 for -09)
No email
send info
I just had a very brief read of this document, but otherwise I'm missing something, I believe the bit lengths of the fields of the Interface Identification Object are not specified. Is there maybe an image missing?

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2017-12-12 for -09)
No email
send info
This is a fine document.

One small comment about the note in the IANA Considerations section suggesting that the whole section is to be removed before publication. This note is not correct, as IANA needs to be able to point to documents which originated various IANA actions.

(Kathleen Moriarty) No Objection

Comment (2017-12-13 for -09)
No email
send info
Thanks for your responses on the SecDir review.  

There were 3 points and I think you've come to a conclusion on each of them, but let me verify from the updated text in versions 8 and 9.

From the review:
* The probed interface can be identified by an IEEE 802 address (presumably, a MAC address). This is an important detail from a security point of view. Normally you don't expect a remote node to be able to access machines by MAC address, and many firewall deployments enforce access control solely at the IP level.

KMM: The following was added in 4.1:

         "o  The L-bit is set and the ICMP Extension Structure does not	
 	      identify any local interfaces	
 		
 	   o  The L-bit is clear and the address or addresses found in the	
 	      Interface Identification object appear in neither the IPv4 Address	
 	      Resolution Protocol (ARP) Table nor the IPv6 Neighbor Cache"

And that's an improvement, thank you.

* Similarly, in an IPv4 setting, the proxy can be identified by a routable address, and used to probe a non-routable (RFC 1918) address.

KMM: I don't see added text to point out this as was requested.  Can you point me to the text or add some?

* "The incoming ICMP Extend Echo Request carries a source address that is not explicitly authorized for the incoming ICMP Extended Echo Request L-bit setting" - this implies a per-node whitelist listing all IP addresses that are allowed to probe it. I don't think we mean seriously to list all the addresses that can ping a given node, so this smells like security theater - sorry.

KMM: The last one - I agree with Ron, it is common practice to have explicit allow only lists, at least for any organization I worked. I think this is a good recommendation to keep in the document. 

Thank you!

(Eric Rescorla) No Objection

Comment (2017-12-12 for -09)
No email
send info
I share Yaron Sheffer's concern about the incoming ACL. Do you really mean to list all the probe-capable nodes?

   or IPv6 Neighbor Cache [RFC4861].  Otherwise, it reports that the
   interface does not exist.
Hmm... So you don't try to ping it yourself? That's interesting.


      the probed node.  The L-bit is clear if the probed interface is
      directly connected to the probed node.
Maybe I'm missing something here, but how does the probing node know?
I.e., can it address by IP address and set L=0?


View Inlinedraft-ietf-intarea-probe.txt:365
      Ethernet is running on the probed interface.  Otherwise, the E-bit
      is clear.
This seems pretty limited. Does "WiFi" count for instance?

Alvaro Retana No Objection

Comment (2017-12-13 for -09)
No email
send info
(1) The Code field of the Request is set to 0 - what happens if a different value is received? 

(2) The Request includes 2 fields (Identifier and Sequence Number) that are used “to aid in matching Extended Echo Replies to Extended Echo Requests”.  Their use seems to be a local matter (as the values are simply copied in to the Reply.  Can you please provide guidance on their use?  Why are there 2 fields (and not just a single one)?  I’m assuming/hoping that the design had use cases in mind that can be reflected in the document.

(3) It would be nice to set up a registry for the Reserved fields.

(4) I’m not sure I understand the use/intention of the L-bit.  The description says that it is used (on the Request) to indicate whether the probed interfaces resides on the proxy node (or not).  How does the originator of the Request know that information?  The other function of this bit seems to be to control how the Interface Identification Object can identify the probed interface…while it seems to make sense that a probed interface that doesn’t reside on the proxy node would only be identified by it’s address, it still makes me wonder how the sender of the Request would know, and why it even matters that it does and that it indicates it to the proxy node.