Re: [secdir] secdir review of draft-ietf-trill-directory-framework-05

[Donald Eastlake <[e-mail]>]

Hi Charlie,

Thanks for the review, I believe I agree with all your points!

See below.

On Thu, Jul 11, 2013 at 1:20 AM, Charlie Kaufman <[e-mail]> wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> This document describes a framework for adding a central control mechanism to trill to replace or supplement its autoconfiguring mechanism of dynamically learning the locations of all addresses on the LAN. The specific protocols for supplying and consuming this configuration information will presumably appear in future specs. This sort of configuration control is useful in a datacenter where all connections are carefully configured rather than being plug and play. It is particularly applicable in a "cloud" environment where virtual machines are moved between physical machines by some sort of Virtual Machine Management System that will also assign addresses and place them.
>
> The Security Considerations section of this document is very bland, noting that reachability depends on the correct delivery of information and stating that there may be security considerations specific to particular directory assistance mechanisms. The feature is designed to improve performance rather than security. I believe this seriously understates the security advantages that are possible if a central control mechanism replaces the autoconfiguration mechanism. In particular, the main protection/isolation mechanisms available today on a LAN concern partitioning by VLAN. Within a VLAN, any node can impersonate any other and can arrange to receive traffic addressed to another node. This can be prevented if the network learns the addresses belonging to each physical connection port not from looking at what the node transmits but rather from a central controller. A node cannot receive traffic addressed to someone else simply by sending a packet from that address or responding to an ARP searching for an IP address. In fact, such packets can be blocked by the ingress Rbridge. So control is much more fine-grained than with VLANs. The network guarantees the authenticity of the source address of each incoming packet.

Right.

> The directory framework could be made more useful in serving this security functionality if its configuration included in each entry not simply the IP address, MAC/VLAN, and list of attached Rbridges, but also a port identifier for each attached RBridge. Egress RBridges could use this information to impose more precise limits. If this information is not in the database, a central controlling mechanism would need a separate protocol and communications path to communicate this information to the Egress RBridges. The current spec allows such information to be included in the directory, but does not require it.

Another good point. How about if we replace the Security
Considerations Section as follows:

OLD
   Accurate mapping of IP addresses into MAC addresses and of MAC
   addresses to the RBridge from which they are reachable is important
   to the correct delivery of information. The security of specific
   directory assisted mechanisms will be discussed in the document or
   documents specifying those mechanisms.

   For general TRILL security considerations, see [RFC6325].

NEW
   For general TRILL security considerations, see Section 6 of
   [RFC6325].

   Accurate mapping of IP addresses into MAC addresses and of MAC
   addresses to the RBridges from which they are reachable is important
   to the correct delivery of information. The security of specific
   directory assisted mechanisms for delivering such information will be
   discussed in the document or documents specifying those mechanisms.

   Directory assisted TRILL edge can substantially improve on the
   security of the default MAC address learning from the data plane used
   in a TRILL campus. With that data plane learning, any node can
   impersonate any other in the same data label (VLAN or FGL [FGL]) and
   can arrange to receive traffic addressed to another node.

   This can be prevented by disabling data plane MAC address learning
   and using trusted directory services, espeically if, when
   appropriate, ARP and ND messages are intercepted and responded too
   locally. Then end stations cannot receive traffic addressed to
   someone else simply by sending a packet from that MAC address or
   responding to an ARP or ND searching for an IP address. (Security ND
   or use of secure ESADI [ESADI] may also be helpful to security.) In
   fact, such possibly malicious packets can be blocked by the ingress
   RBridge. So control is much more fine-grained than the scope of a
   data labels, limiting spoofing to imposters directly connected to the
   same RBridge or, if RBrige port information is also provided by the
   directory, to on-link imposters.

and also add just a few words earlier on mentioning improved security
with a reference to the Security Considerations Section?

> Nits:
>
> Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence"

OK.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]