Hello Yaron,
Thanks for the thoughtful review. Responses inline......
Ron
-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@xxxxxxxxx]
Sent: Saturday, December 2, 2017 4:35 PM
To: secdir@xxxxxxxx
Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; ietf@xxxxxxxx
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