Stephan,
Thanks for the thoughtful review. Responses inline.
Rpn
> -----Original Message-----
> From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Stefan Winter
> Sent: Monday, December 4, 2017 9:02 AM
> To: ops-dir@xxxxxxxx
> Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; ietf@xxxxxxxx
> Subject: Opsdir telechat review of draft-ietf-intarea-probe-07
>
> Reviewer: Stefan Winter
> Review result: Has Issues
>
> Issues:
>
> * 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.
[RB ]
If the L-bit is clear, the proxy interface does not ping the probed interface. Instead, the node upon which the proxy interface resides executes the following procedure:
- Search ARP Table / Neighbor Cache for the address that appear in the Interface Identification Object.
- If no entry is found, send a reply stating No Such Interface
- If an entry is found, send a reply stating that the interface is active
As you point out, the node upon which the proxy interface resides cannot infer that an interface is active because it appears in the ARP Table / Neighbor Cache. Likewise, the node upon which the proxy interface resides cannot infer that an interface does not exist because it does not appear in the ARP Table / Neighbor Cache.
So, I recommend that we change the procedure as follows:
- Search ARP Table / Neighbor Cache for the address that appear in the Interface Identification Object.
- If no entry is found, send a reply stating No Such ARP / NC Entry (This is a new error code)
- If an entry is found, send a reply with error code equal to 0 and the A, F, and S flags all clear
Does this work for you?
>
> * Request -> L-Bit.
> I don't get it. The Request part of the spec is used by the probING node. It
> always sends the request to a proxy node. The proxy node then is the one to
> figure out by local state if the interface that is to be probed is local to itself, or
> on a link.
[RB ]
Sometimes, this is not possible. For example, assume that a router has interfaces ge-0/0/0.0 and ge-0/0/1.0. The local side of ge-0/0/0.0 had the IPv6 link local address fe80::dead:beef. The remote side of the interface ge-0/0/1.0 has the same IPv6 link local address.
The user can set or clear the L-bit to indicate which interface is being probed. Without the L-but, PROBE would return an error (Multiple Interfaces Satisfy Query).
[RB ] > Now the question is of course: what purpose does setting the L-Bit
> on the *request* serve? The probed interface either is local to the proxy
> node or it's not; no amount of flipping bits changes the reality. I can see how
> this L-bit information could be set in a *Response* as an information
> element. But that's not what the document says;
[RB ]
See above
the document actually
> states two contradictory things a) L (local) - The L-bit is set if the probed
> interface resides on
> the probed node. The L-bit is clear if the probed interface is
> directly connected to the probed node
> [doesn't make sense, see above]
[RB ]
How are these contradictory? The user sets the L-bit if the proxy and probed interfaces are on the same node. The user clears the L-bit of the proxy interface is on a node that is directly connected to the probed interface?
> b) If the L-bit is set, the Interface Identification Object identifies
> the probed interface by name, index or address. It the L-bit is
> clear, the Interface Identification Object identifies the probed
> interface by address.
> [ makes more sense, but conflicts with previous statement]
[RB ]
I don't see the contradiction. If you are querying a non-local interface, you are going to search the ARP Table / Neighbor Cache. So, you need to query by address. You don't know the remote interface name or interface index.
The latter
> formulation be also begs the questions a) why would one ever clear the L-Bit;
> identifying an interface by address is also possible when it's set, so setting
> the L-bit is fit for all situations envisaged and provides a true superset of
> functionality that L-Bit cleared offers; b) what do you mean with "name,
> index **or** address". Is that an exclusive OR, or any subset of the three, or
> can they all three be set? Later text suggests that each Interface
> Identification Object can carry only one of the three (XOR), but previous text
> suggests that two such Objects might be required for unique idenficiation. So
> in the end either one or two can be used to identify an object, but not all
> three? That's totally fine, but could be made more obvious. I also suggest to
> ditch the L-Bit and operate in a mode as if the L-Bit was always set. It adds no
> value. I also contemplate later in the text that L-Bit set is default-on while L-
> Bit clear is default off already.
[RB ]
I'm not sure that I follow this paragraph
>
> * Response (chapter 3)
> The choice of flag names is not very intuitive. Why is IPv4 "F" and IPv6 "S"? I
> understand that those are the first letters of the words FOUR and SIX in
> English. But maybe the flags could actually be named "4" and "6". Those are
> ASCII characters like any other, and have a more direct recognition by
> humans (e.g. when the flags are displayed in protocol decoders).
>
[RB ]
Fair enough. I will change them to 4-bit and 6-bit
> Chapter 4, authorisation:
> "not explicitly authorized for the incoming ICMP Extended Echo Request L-bit
> setting" I don't understand why the L-bit is a major decision point for
> authorisation checks. It is in principle superfluous anyway as above, and then
> one is expecting that policy decisions of sorts "this probing address is allowed
> ask for interfaces based on properties different from the address, but this
> other node is only allowed to operate on address"? The use case for that
> escapes me; and also, it can be achieved with "define enabled query types"
> as per Security Considerations.
[RB ]
This objection may be cleared up as a side effect of clearing the previous objection
>
> * Security Considerations
> "For example, a malicious party can use PROBE to discover interface names."
> This would be discovery by brute forcing the interface name space? Because
> the reply doesn't give away the name when the request was via address -
> right? It would be good to make clear that this discovery has to happen as a
> hit-and-miss of guessed names rather than getting an enumeration on the
> silver platter.
> OTOH, there are many well-known naming conventions for interfaces and it's
> more like a dictionary attack rather than simple brute-force.
[RB ]
It is a dictionary attack using a very small dictionary ;-)
My point wasn't so much to explain how an attacker might discover interface names, but to warn that it is possible.
>
> Nits:
> * Chapter 2, Page 4, first bullet of the "ICMP fields" enumeration. The value
> is TTTT0 (four T's) but you then ask IANA to register things with only TTTx
> (three T's). The fourth T is superfluous.
[RB ]
Good catch. Fixed in the next version.