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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 02 Dec 2017 13:35:06 -0800

Reviewer: Yaron Sheffer
Review result: Has Issues

Summary

The Security Considerations section is extensive, given that this is not a
major protocol. However I think a few additional security risks should be
mentioned, see below. In addition, there are several points where this
(arguably uneducated) reader was confused, and which could benefit from
additional clarity.

Details (security-related)

* 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. * Similarly, in an IPv4 setting, the proxy can be identified by a
routable address, and used to probe a non-routable (RFC 1918) address. * "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.

Other Details

* Abstract: I think the word "alternatively" should really be "instead" (also
in the Introduction). * "The proxy interface resides on a probed node" - this
contradicts the previous paragraph that states that either the proxy is on the
same node, or it has direct connectivity to it (and is presumably on a
different node). * "The probed interface can reside on the probed node or it
can be directly connected to the probed node." I'm confused. This contradicts
the first paragraph of the Intro: "The probing interface resides on a probing
node while the probed interface resides on a probed node." * "encapsulated in
an IP header" - shouldn't that be "in an IP packet" (at least for IPv4)? *
"Ethernet is running on the probed interface" - is this well-defined? There are
numerous 802.* protocols. Do we mean any of them? Or just 802.3?

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Dec 2017 18:03:05 +0000

Hello Yaron,

Thanks for the thoughtful review. Responses inline......

                         Ron

> -----Original Message-----
> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Saturday, December 2, 2017 4:35 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Secdir telechat review of draft-ietf-intarea-probe-07
> 
> Reviewer: Yaron Sheffer
> The Security Considerations section is extensive, given that this is not a major
> protocol. However I think a few additional security risks should be
> * 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. * Similarly, in an IPv4 setting, the proxy can be identified by a
> routable address, and used to probe a non-routable (RFC 1918) address. *
> "The incoming ICMP Extend Echo Request carries a source address that is not
[RB ] 
I agree with all of the points that you raise above, except for the part about white listing. This isn't security theater. It's real.

For the most part,  hosts will stick with the default PROBE configuration. That is, they won't honor an ICMP Extended Echo Request of any type from any source.

A good number of network operators will enable PROBE on their routers, but for the reasons that you point out above, they won't want their routers being probed from untrusted subnetworks. They will probably restrict probe access to a few trusted subnets that are within their administrative domain (e.g., the NOC, network controllers).

I doubt if anyone will expose their routers to PROBING from all points on the Internet.
 
> Other Details
> 
> * Abstract: I think the word "alternatively" should really be "instead" (also in
> the Introduction). 
[RB ] 
I can fix that in the next version

* "The proxy interface resides on a probed node" - this
> same node, or it has direct connectivity to it (and is presumably on a different
> node). 
[RB ] 
Joel Halpern raised the same point in his review. In the next version, the probed node will be called the proxy node.

* "The probed interface can reside on the probed node or it can be
> directly connected to the probed node." I'm confused. This contradicts the
> first paragraph of the Intro: "The probing interface resides on a probing node
> while the probed interface resides on a probed node."
[RB ] 
Same fix as above

 *
"encapsulated in an
> IP header" - shouldn't that be "in an IP packet" (at least for IPv4)? 
[RB ] 
I will check RFC 792 and use whatever words they used
*
> "Ethernet is running on the probed interface" - is this well-defined? There
> are numerous 802.* protocols. Do we mean any of them? Or just 802.3?
> 
[RB ] 
Joel Halpern raised the same issue in his review. We will rename this bit to indicate that it is a Pseudowire endpoint, without mentioning what kind of PW endpoint it is.

                                   Ron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 6 Dec 2017 00:40:41 +0200

Hi Ron,

Thanks for putting me right about the expected use case. Please consider 
including these paragraphs more or less as-is in the security 
considerations. While informal, they give the reader a good idea how to 
use this facility securely.

Regards,
	Yaron