Re: [secdir] SecDir review of draft-ietf-trill-o-pw-03

[Donald Eastlake <[e-mail]>]

Hi Yaron,

On Thu, Dec 12, 2013 at 4:58 PM, Yaron Sheffer <[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 specifies how multiple networks running TRILL can be
> connected using pseudowires.

I am puzzled as to why you think this document has to do with
"multiple networks" or what you mean by that.

As background, a transit TRILL switch acts like a router in the sense
that it logically discards the Layer 2 header on an incoming packet,
decrements the TRILL hop count and discards the packet if it has
counted down, and adds a new Layer 2 header appropriate to the
outgoing link type in the process of sending that packet out a port.

When a TRILL switch port is connected to a port on a different TRILL
switch by a link type that TRILL can use, the TRILL switches peer with
each other (unless TRILL control plane security was configured to
block such peering). It makes no difference what the link technology
is; in particular, there is nothing different at the TRILL level for a
pseudowire link as compared with, say, an Ethernet link or some other
link technology. If the two TRILL switches involved happen to be psrts
of two different TRILL campuses, then this must be the first
connection between those campuses and the connection causes the TRILL
campuses to merge into one TRILL campus with a single shared link
state database. If the two TRILL switches are alrady part of the same
TRILL campus, then this is just a change in topology (unless the two
TRILL switches were already connected by a different link, in which
case there isn't even a change in campus topology (except that their
might be a reduction in link cost due to the availability of greater
bandwidth across the parallel links)).

> Summary
>
> Coming from the L3 security community, I am very worried by this
> document and its predecessors. It seems to me that we are creating
> the infrastructure for larger and larger L2 networks, often spanning
> large geographical distances, but the security mechanisms are not
> keeping up with this wider scope.

There is no mention in this draft of "larger L2 networks" or of
"spanning large geographic distances" nor do I see why there should
be. You can construct TRILL campuses spanning a small or large
geographic distance with a small or large number of nodes regardless
of what link technology or set of link technologies you use between
your TRILL switches.

> I am not familiar with either the TRILL or PWE3 standards. Nor am I
> familiar with their real-life implementations. If secure deployments
> are common, I will be happy to be proven wrong (though I would
> expect such best practices to be documented and standardized).
>
> Details
>
> - This document copies the following text from the analogous PPP
> transport RFC: "not all implementations need to include specific
> security mechanisms at the pseudowire layer, for example if they are
> designed to be deployed only in cases where the networking
> environment is trusted or where other layers provide adequate
> security.  A complete enumeration of possible deployment scenarios
> and associated threats and options is not possible and is outside
> the scope of this document.'

Maybe the paragarph you quote part of above should be dropped. I'm
not sure it is necessary since it seems to me that what it says is
normally true.  For example, I would say that it is not always
necessary to use IP security because some combination of the security
of the environment, the security of the link layers over which IP is
running, and/or the security of the application layers running over IP
are adequate. I think the same is true of TRILL.

> I beg to differ. I think Security Considerations should recommend
> such solutions, and discuss the specific issues that come up when
> deploying them in this context: how should endpoints be
> authenticated?

So, for example, would you say that a hypothetical "IP over the Foobaz
link protocol" draft would have to have an extensive discussion of how
IP routers are authenticated to each other and how IP can be secured?
Wouldn't references to IP security and a reference to Foobaz link
security be sufficient in most cases? This document is TRILL over
pseudowires. For various reasons given in the document, this happens
to be specified as, in effect TRILL over PPP over pseudowire.  There
are references to TRILL security, PPP security, and pseudowire
security.

By the way, if by "endpoints" you mean the TRILL switches at the two
ends of the pseudowire, they are authenticated to each other with
TRILL IS-IS Hellos as specified in the TRILL base protocol
specification, RFC 6325, and further detailed in RFC 6327 (being
replaced by draft-ietf-trill-rfc6327bis which is in IETF Last Call
simultaneously with this TRILL over pseudowire draft). But I don't see
why this draft needs to talk about that as it is independent of link
technology.

> What protocol information should be protected?  How do TRILL
> identities map to identities authenticated by the selected security
> protocol etc. In general, although not ALL implementations need
> security mechanisms, I assume an overwhelming majority of them does.

In my opinion, a simple "X over Y" draft, where there are approved
protocol X standards covering the security of X and approved protocol
Y standards covering the security of Y, both referenced by the "X over
Y" draft, does not normally require the re-hashing of security for
either protocol X or protocol Y. You seem to want a complete
re-hashing of TRILL security just because of this effort to specify a
strightforward encoding of TRILL over a link type.

> - Moreover, text such as the following (RFC 6325) strongly hints
> that this traffic will be passing under the radar of many security
> devices: "TRILL ignorant devices with firewall features that cannot
> be detected by RBridges as end stations will generally not be able
> to inspect the content of such frames for security checking
> purposes."

I don't see how this is different from any new protocol. Generally
speaking, looking at a packet, there will be some sort of header for
the new protocol and a device that don't understand that new protocol
will be unable to parse that header or any following information.
Firewall-like devices certainly have the option to discard such
packets, which perhaps should be been explicitly mentioned in RFC
6325. Is it your opinion that the IETF standardization of a protocol
should not be permitted until it has been demonstrated that
understanding of that protocol has been actually deployed to all
firewall-like devices in the universe?

> - The Security Considerations recommend end-to-end security as a
> replacement for link-level security. Though attractive from a
> security point of view, such solutions (security protocols between
> end hosts) are far from ubiquitous in large networks and so cannot
> replace link-level mechanisms.

The sentence in this draft most relevant to your comment above is as
follows:

   "For applications involving sensitive data, end-to-end security
   should always be considered, in addition to link security, to
   provide security in depth."

That doesn't sound like "replacement" to me.

> - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL
> islands. RFC 6361 does in fact discuss specific security mechanisms (yes,
> one wonders about CHAP being recommended in a 2011 document). The current
> document does not do so.

I think the claim you make that RFC 6361 uses PPP to "bridge the TRILL
islands" is incorrect unless you consider every TRILL switch to be a
one node "island" and every link between two TRILL switch ports to be
a "bridge".  There is no difference, from the TRILL protocol point of
view, between links of different technology between TRILL switches
(except that links configured as point-to-point are treated somewhat
differently from multi-access links).

This draft is "Transport of TRILL Using Pseudowires", effectively
specified as TRILL over PPP over pseudowires. Pseudowires are over
either MPLS or IP, and MPLS and IP are over some link protocol. So
link security between two TRILL switch ports connected by a pseudowire
can potentially be protected by security mechanisms provided by (1)
TRILL, (2) PPP, (3) pseudowires, (4) MPLS or IP, and (5) the link
technology being used by MPLS or IP. (Although, the PPP layer is
somewhat vestigial - mostly used to conveniently distinguish TRILL
Data and TRILL IS-IS packets.) I'd be happy to try to clarify in
the Security Considerations section that link security can come from
any combination of these layers. but I do not think the draft is the
appropriate place for detailed discussion of all of these types of
security and their permutations and combinations.

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

> Thanks,
>         Yaron



On Thu, Dec 12, 2013 at 4:58 PM, Yaron Sheffer <[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 specifies how multiple networks running TRILL can be connected
> using pseudowires.
>
> Summary
>
> Coming from the L3 security community, I am very worried by this document
> and its predecessors. It seems to me that we are creating the infrastructure
> for larger and larger L2 networks, often spanning large geographical
> distances, but the security mechanisms are not keeping up with this wider
> scope.
>
> I am not familiar with either the TRILL or PWE3 standards. Nor am I familiar
> with their real-life implementations. If secure deployments are common, I
> will be happy to be proven wrong (though I would expect such best practices
> to be documented and standardized).
>
> Details
>
> - This document copies the following text from the analogous PPP transport
> RFC: "not all implementations need to include specific security mechanisms
> at the pseudowire layer, for example if they are designed to be deployed
> only in cases where the networking environment is trusted or where other
> layers provide adequate security.  A complete enumeration of possible
> deployment scenarios and associated threats and options is not possible and
> is outside the scope of this document.' I beg to differ. I think Security
> Considerations should recommend such solutions, and discuss the specific
> issues that come up when deploying them in this context: how should
> endpoints be authenticated? What protocol information should be protected?
> How do TRILL identities map to identities authenticated by the selected
> security protocol etc. In general, although not ALL implementations need
> security mechanisms, I assume an overwhelming majority of them does.
>
> - Moreover, text such as the following (RFC 6325) strongly hints that this
> traffic will be passing under the radar of many security devices: "TRILL
> ignorant devices with firewall features that cannot be detected by RBridges
> as end stations will generally not be able to inspect the content of such
> frames for security checking purposes."
>
> - The Security Considerations recommend end-to-end security as a replacement
> for link-level security. Though attractive from a security point of view,
> such solutions (security protocols between end hosts) are far from
> ubiquitous in large networks and so cannot replace link-level mechanisms.
>
> - This document is analogous to RFC 6361, which uses PPP to bridge the TRILL
> islands. RFC 6361 does in fact discuss specific security mechanisms (yes,
> one wonders about CHAP being recommended in a 2011 document). The current
> document does not do so.
>
> Thanks,
>         Yaron
> _______________________________________________
> secdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview