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

[Ron Bonica <[e-mail]>]

Hello Yaron,

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

                         Ron

> -----Original Message-----
> From: Yaron Sheffer [mailto:[e-mail]]
> Sent: Saturday, December 2, 2017 4:35 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Secdir telechat review of draft-ietf-intarea-probe-07
> 
> 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.
> 
[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
> 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). 
[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