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

From: Stefan Winter <[email-masked]>
Date: Mon, 04 Dec 2017 06:01:51 -0800

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.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Dec 2017 22:07:11 +0000

Stephan,

Thanks for the thoughtful review. Responses inline.

                               Rpn

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Stefan Winter
> Sent: Monday, December 4, 2017 9:02 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Opsdir telechat review of draft-ietf-intarea-probe-07
> 
> Reviewer: Stefan Winter
> [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?

> 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
[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?

>    [ 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
> 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

> 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

> 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

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

> (three T's). The fourth T is superfluous.
[RB ] 
Good catch. Fixed in the next version.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 22 Dec 2017 12:46:03 +0100

Hello,

I've taken a look at -10 now.

All of my nittry-gritty has cleared. The one thing I'm still not sure
about the /wording/ is the L-bit question.

With your explanations below, I think I now get the intent of the L-bit
and understand its usefulness.

The text I see in -10 still doesn't seem to be in line with those
explanations. Maybe it's just English grammar issues, feel free to tell
me if I'm on the wrong side of the language barrier.

* I understood your explanations to mean: with the L-Bit, the probING
interface directs the PROXY interface:

- L-Bit set: probing interface requests that proxy interface only
considers the internal state of (its own) probED interface
- L-Bit not set: probING interface instructs PROXY interface to consult
ARP/NC to infer the state of probED interface

It is then a simple corollary that clearing the L-bit only makes sense
when probing by address; because that's the only identifier that is
contained in the ARP / NC databases.

But when I read chapter 2 / ICMP fields: L bit text:

"The L-bit is set if the probed interface resides on
      the proxy node.  The L-bit is clear if the probed interface is
      directly connected to the proxy node."

And this is where I difficulties. The relationship between proxy and probed is either "resides-on" or "connected-to". So the probING device does almost never have a degree of freedom when populating the L-bit. The only opportunity when it can make a choice is if it is identifying the probed interface by-address, and the address exists both on the proxy node and on a link on a directly connected node. Then, and only then, the L-Bit actually signals "I mean the remote one / I mean the local one". In all other cases, the L-Bit is superfluous as its set/notset state is dictated by the network architecture.

This is, ultimately, what the quoted text above says - but it's written in a back-to-front way IMHO; it doesn't tell an implementer what to /do/ with the L-bit, but rather where it's value came from.
 
With my interpretation of the intent, a text which fits much more naturally to me would be along the lines of:

"If the L-bit is set, the proxy interface must infer the most adequate reply from its internal state; if it is not set, the proxy interface must consult the ARP and/or Neighbor Cache databases for the probed interface address to determine its state."

If I'm still totally besides the point, I'm prepared to give up and let go on this point :-)

The only other significant point I'd like some more discussion on is:

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

Does this work for you?"

That's much better than before! It now comes out clearer that any reply that's given does not have certainty ("No such Entry" != "doesn't exist"; "No error" != "Interface active right now". That reply has a low operational value though (it had that before the wording change already). I.e. I sent a PROBE to find out if address X is alive and kicking, but the reply is "maybe" because old entries in ARP/NC might not reflect current reality. I wouldn't trust PROBE's results if operating in cleared-L-Bit mode (and, ultimately, wouldn't care to use it at all in many circumstances).

I believe the draft could do more to get actual, fresh data from directly connected probed interfaces: it could allow the proxy interface to execute a PING of its own towards the address to get an /actual, real-time/ status. That's an information I would trust much more than merely looking at ARP/NC.

Text-wise, it's simple to retrofit this: just before the ARP/NC lookup introduce a MAY execute PING4/6 which updates the DB if active. Of course, this does generate extra traffic, and it's a question if this is desirable. IMHO, the freshness of the resulting data warrants it. 

It might make sense to add
- a Request flag "Active Probing" (probing node allows proxy node to actively reach out to probed interface)
- a Reply flag "Real-Time" (proxy interface signals that it has fresh data; arguably one could then also set the "A" flag as the interface is then known to be active)

I realise I'm feature-creeping here. Do what you like with it :-)

Greetings,

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Ron Bonica <[email-masked]>
Date: Wed, 27 Dec 2017 18:28:04 +0000

Hi Stephan,

Happy Holidays! 

Response inline.......

                                 Ron

> From: Stefan Winter [mailto:[email-masked]]
> Sent: Friday, December 22, 2017 6:46 AM
> To: Ron Bonica <[email-masked]>; [email-masked]
> Subject: Re: [OPS-DIR] Opsdir telechat review of draft-ietf-intarea-probe-07
> 
> Hello,
> 
> All of my nittry-gritty has cleared. The one thing I'm still not sure about the
> /wording/ is the L-bit question.
> 
> With your explanations below, I think I now get the intent of the L-bit and
> understand its usefulness.
> 
> The text I see in -10 still doesn't seem to be in line with those explanations.
> Maybe it's just English grammar issues, feel free to tell me if I'm on the
> wrong side of the language barrier.
[RB ] 

Let the dialog begin ;-)

> - L-Bit set: probing interface requests that proxy interface only considers the
> internal state of (its own) probED interface
[RB ] 
I think we are saying the same thing, but I will say it a different way, just to be certain that we have the same picture in mind.

The probing node sets the L-bit to instruct the proxy node that the probed interface resides on the proxy node.
The probing node clears the L-bit to instruct the proxy node that the probed interface  does not reside on the proxy node. Instead, it is directly connected to the proxy node.

> It is then a simple corollary that clearing the L-bit only makes sense when
> probing by address; because that's the only identifier that is contained in the
> ARP / NC databases.
[RB ] 
True!

> And this is where I difficulties. The relationship between proxy and probed is
> either "resides-on" or "connected-to". 
[RB ] 
Yes, this may be where we are getting into trouble.  Let me offer an illustration to clarify the phrases "resides on" and "connected to":

Assume a topology where Nodes A and B are connected by a point-to-point link. On Node A's side, the link address is 192.0.2.1. On Node B's side, the link address is 192.0.2.2.

In this topology, 192.0.2.1 is local to Node A, while 192.0.2.2 is directly connected to Node A. Conversely 192.0.1.2 is local to Node B, while 192.0.2.1 is directly connected to Node B.

So the probING device does almost
> never have a degree of freedom when populating the L-bit.
[RB ] 
This is where we diverge. The probing node *always* determines the value of the L-bit. Recall that the L-bit appears in the Echo Request, but not in the Echo Reply. 

 The only
> opportunity when it can make a choice is if it is identifying the probed
> interface by-address, and the address exists both on the proxy node and on
> a link on a directly connected node. Then, and only then, the L-Bit actually
> signals "I mean the remote one / I mean the local one". In all other cases, the
> L-Bit is superfluous as its set/notset state is dictated by the network
> architecture.
[RB ] 
Here, you have a point. If the probing node probes by name or index, the L-bit is redundant. It only adds value when we are probing by address.

I could have ignored the L-bit when probing by name or index, but decided to insist that it be set correctly. OCD at work ;-)

> 
> This is, ultimately, what the quoted text above says - but it's written in a
> back-to-front way IMHO; it doesn't tell an implementer what to /do/ with
> the L-bit, but rather where it's value came from.
> 
> "If the L-bit is set, the proxy interface must infer the most adequate reply
> from its internal state; if it is not set, the proxy interface must consult the
> ARP and/or Neighbor Cache databases for the probed interface address to
> determine its state."
> 
[RB ] 
The point that you raise is very important. Please take a look at the last two paragraphs in Section 1.0. They might satisfy the requirement.

> If I'm still totally besides the point, I'm prepared to give up and let go on this

[RB ] 
I think that you are on target. But again, take a look at those last two paragraphs in Section 1.0.

> "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.
> 
> That's much better than before! It now comes out clearer that any reply
> that's given does not have certainty ("No such Entry" != "doesn't exist"; "No
> error" != "Interface active right now". That reply has a low operational value
> though (it had that before the wording change already). I.e. I sent a PROBE to
> find out if address X is alive and kicking, but the reply is "maybe" because old
> entries in ARP/NC might not reflect current reality. I wouldn't trust PROBE's
> results if operating in cleared-L-Bit mode (and, ultimately, wouldn't care to
> use it at all in many circumstances).
> 
> I believe the draft could do more to get actual, fresh data from directly
> connected probed interfaces: it could allow the proxy interface to execute a
> PING of its own towards the address to get an /actual, real-time/ status.
> That's an information I would trust much more than merely looking at
> ARP/NC.
[RB ] 
I thought about pinging the remote interface and decided against it. This would make the protocol stateful, with all of the attendant security considerations. It might even prevent deployment.

> 
> Text-wise, it's simple to retrofit this: just before the ARP/NC lookup
> introduce a MAY execute PING4/6 which updates the DB if active. Of course,
> this does generate extra traffic, and it's a question if this is desirable. IMHO,
> the freshness of the resulting data warrants it.
> 
> - a Reply flag "Real-Time" (proxy interface signals that it has fresh data;
> arguably one could then also set the "A" flag as the interface is then known
> to be active)
> 
[RB ] 
Thanks again for the thoughtful review. Let's get together in London to discuss the remote ping problem.

                                                           Ron

> >> 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:
> >
> > 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.
> >
> >> 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).
> >
> >> 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
> > 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?
> >
> > 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 ]
> >> 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 ]
> >> "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
> >> 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 ]
> > 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 ]
> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de
> la Recherche 2, avenue de l'Université
> L-4365 Esch-sur-Alzette
> 
> Tel: +352 424409 1
> Fax: +352 422473
>