[Int-area] Opsdir telechat review of draft-ietf-intarea-probe-07

[Stefan Winter <[e-mail]>]

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.

* 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. 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; 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]
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]
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.

* 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).

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.

* 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.

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.