Subject: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-irb-13: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 29 Jun 2016 12:43:08 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-trill-irb-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-trill-irb/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In reading the draft and security considerations, I had the same concern
as Stephen's second point.  Are there any security issues if the session
is not encrypted?  I see the concern for sensitive data and that is good,
but are any exploits possible if the session is not encrypted (like on
the tenantID as Stephen asked).

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 Jun 2016 18:57:49 -0400

Hi Kathleen,

See below.

On Wed, Jun 29, 2016 at 3:43 PM, Kathleen Moriarty
<[email-masked]> wrote:
> ...

I am not sure what you mean by "session".

Simplifying a little: there are two types of TRILL packets, TRILL
IS-IS (control plane) packets and TRILL Data packets. IS-IS has an
authentication feature but does not provide confidentiality. There is
currently no general TRILL feature for securing TRILL Data packets.

The purpose of TRILL is to provide connectivity between end stations.
Those end stations are connected to the TRILL edge by Ethernet so, if
supported by the TRILL edge switch Ethernet port, an end station can,
for example, use MACSEC (802.1AE) to secure its connection to the
TRILL edge. Also, since TRILL is mostly transparent, end stations
talking to each other can use IPsec or TLS/DTLS or whatever they want
to secure their conversation. (There is an incomplete personal draft
that talks about link security between TRILL switches and/or between
an ingress TRILL edge switch and an egress TRILL edge switch.)

The Tenant ID does not normally occur in a TRILL Data packet. The
tenant the packet belongs to is encoded in other ways. An adversary
knowing a valid Tenant ID would mostly enable them to better forge
IS-IS control PDUs where the Tenant ID does occur. But the if the
network manager is not protecting the IS-IS control traffic, they
presumably believe that possible problems due to forged IS-IS control
traffic is not significant.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: [email-masked]
Date: Wed, 29 Jun 2016 21:14:47 -0400

Hi Donald,

Thanks for your quick response, inline.

Sent from my iPhone

> On Jun 29, 2016, at 6:57 PM, Donald Eastlake <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> See below.
> 

Thanks for the response below, it's helpful, but my question was keyed off of the text in the security considerations section that says,
"Particularly sensitive data should be encrypted end-to-end, ..."

No method was specified in this section, but below you do say IPsec and other session based encryption protocols are possible.  My question was to understand if there are security reasons why encryption should be used in addition to data confidentiality for completeness in this section.  

Thank you,
Kathleen

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 29 Jun 2016 23:50:31 -0400

Hi Kathleen,

See below.

> No method was specified in this section, but below you do say IPsec and other session based encryption protocols are possible.  My question was to understand if there are security reasons why encry…

No, I wouldn't say there was some reason to "encrypt" user data
end-to-end if there is already "data confidentiality" end-to-end. Is
the whole problem just that the authors happen to have used the word
"encrypt" rather than "secure" or something?

As I explain, there is no reason to say much about end-to-end security
between end stations connected to a TRILL campus since one of the
goals of a TRILL campus is to be transparent to end stations (except
in the case of special TRILL aware end stations). There is certainly
no reason I can see for this document to specify or require or
recommend or prohibit any particular end-to-end security protocol
between end stations that are attached to a TRILL campus.

The paragraph is supposed to just be the routine general security
advice that use of end-to-end security should be considered.

How about saying something like this:

   Consideration hould be given to securing data end-to-end, that is,
   from the source end station to the destination end station. Since
   the TRILL campus is, for the most part, transparent to end station
   traffic, such end stations are free to use whatever end-to-end
   security protocol they would like.

Thanks,
Donald