Subject: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

From: Alvaro Retana <[email-masked]>
Date: Mon, 05 Mar 2018 11:32:18 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-trill-directory-assisted-encap-10: Discuss

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-directory-assisted-encap/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have significant concerns about this document; as currently written, I
believe the technology is underspecified and can cause significant damage to a
DC network where it might be deployed.  I am then balloting a DISCUSS.

The document (including the security considerations) is written assuming that
the TRILL-ENs can be trusted (and are not compromised), and that the directory
information is accurate.  However, I believe there are several cases that have
been overlooked.

(1) There aren't any basic safeguards specified to at least make sure that a
TRILL-EN is doing the right thing (or something sensible).  For example, what
if the Ingress RBridge Nickname field in the TRILL header doesn't correspond to
the first rBridge at the domain boundary?  Should that frame be accepted?

(2) rfc8171 talks about issues with incorrect directory mappings.  Consider the
case where a TRILL-EN uses (on purpose!) an incorrect mapping.  That "can
result in data being delivered to the wrong end stations, or set of end
stations in the case of multi-destination packets, violating security policy."
[rfc8171]  How can this risk be mitigated?

I don't think that there are easy mitigations for these issues, but at least
mentioning them so that operators are aware of the risk would be enough to
clear this DISCUSS.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Mar 2018 15:27:26 -0500

Hi Alvaro,

On Mon, Mar 5, 2018 at 2:32 PM, Alvaro Retana <[email-masked]> wrote:
> ...

This concern doesn't seem very different from the general insecurity of Layer 2.

If a link has no TRILL router adjacencies, then I guess it it
reasonable to check that the ingress nickname is that of the receiving
RBridge but it gets harder if you have a mixed link with both end
stations and TRILL routers (probably rare in deployments but, on the
other hand, in TRILL a "link" can be a bridged LAN...).

> [rfc8171]  How can this risk be mitigated?

I'm not sure how using "an incorrect mapping" is that different from
just using whatever nicknames it feels like...

> mentioning them so that operators are aware of the risk would be enough to

It is certainly reasonable to mention these. One possible mitigation
is the use of end-to-end encryption.

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

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 5 Mar 2018 13:37:23 -0800

On March 5, 2018 at 3:27:43 PM, Donald Eastlake ([email-masked]) wrote:

Exactly!

The endnode can do anything it wants.  BTW, I just made the same comment
for draft-ietf-trill-smart-endnodes — we should be able to solve both in
one update (to draft-ietf-trill-smart-endnodes).

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Mar 2018 13:48:05 -0500

Donald and Alvaro: 

Do we have an agreed upon text changes?   If so, can we send a proposed change to Alvaro for review prior to Thursday's meeting? 

Sue Hares

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Monday, March 5, 2018 3:27 PM
To: Alvaro Retana
Cc: The IESG; [email-masked]; [email-masked]; Susan Hares; trill IETF mailing list
Subject: Re: Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

Hi Alvaro,

On Mon, Mar 5, 2018 at 2:32 PM, Alvaro Retana <[email-masked]> wrote:
> I have significant concerns about this document; as currently written, 
> I believe the technology is underspecified and can cause significant 
> damage to a DC network where it might be deployed.  I am then balloting a DISCUSS.
>
> The document (including the security considerations) is written 
> assuming that the TRILL-ENs can be trusted (and are not compromised), 
> and that the directory information is accurate.  However, I believe 
> there are several cases that have been overlooked.
>
> (1) There aren't any basic safeguards specified to at least make sure 
> that a TRILL-EN is doing the right thing (or something sensible).  For 
> example, what if the Ingress RBridge Nickname field in the TRILL 
> header doesn't correspond to the first rBridge at the domain boundary?  Should that frame be accepted?

If a link has no TRILL router adjacencies, then I guess it it reasonable to check that the ingress nickname is that of the receiving RBridge but it gets harder if you have a mixed link with both end stations and TRILL routers (probably rare in deployments but, on the other hand, in TRILL a "link" can be a bridged LAN...).

> (2) rfc8171 talks about issues with incorrect directory mappings.  
> Consider the case where a TRILL-EN uses (on purpose!) an incorrect 
> mapping.  That "can result in data being delivered to the wrong end 
> stations, or set of end stations in the case of multi-destination packets, violating security policy."

I'm not sure how using "an incorrect mapping" is that different from just using whatever nicknames it feels like...

> I don't think that there are easy mitigations for these issues, but at 
> least mentioning them so that operators are aware of the risk would be 
> enough to clear this DISCUSS.

It is certainly reasonable to mention these. One possible mitigation is the use of end-to-end encryption.

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

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 7 Mar 2018 16:48:18 -0500

Hi Alvaro,

Attached is a candidate -10 version of the trill-directory-assisted-encap
draft (my internal version 27) as encap27fftoc.txt. I've also attached a
diff against the currently posted -09.

Are these changes satisfactory?

Thanks,
Donald

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Mar 2018 13:53:39 -0800

On March 7, 2018 at 4:48:35 PM, Donald Eastlake ([email-masked]) wrote:

Yes, these changes work for me.

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 7 Mar 2018 18:07:06 -0500

Alvaro:

Thank you for reviewing the changes. 

Cheerily, Susan Hares 

From: trill [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: Wednesday, March 7, 2018 4:54 PM
To: Donald Eastlake
Cc: [email-masked]; trill IETF mailing list; The IESG; Susan Hares; [email-masked]
Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-directory-assisted-encap-10: (with DISCUSS)

Thanks!

Alvaro.