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

kathleen.moriarty.ietf@gmail.com Thu, 30 June 2016 01:14 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E6112D83A; Wed, 29 Jun 2016 18:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWRwY6LpdVUx; Wed, 29 Jun 2016 18:14:50 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0129A12D090; Wed, 29 Jun 2016 18:14:49 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id o76so5668035qke.0; Wed, 29 Jun 2016 18:14:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ls3mITwErZxu0k/FTh/7YzGbxphAJvvCquSRJmdlI4A=; b=xPpVf2ZHJ9msUYfjMuEftSYjUIkBgffmXrQRjqI5vQT5N08upmK6TX7geViMF5/Nmp raBRamA9ApoSwb3ZsU9u4n7sxoerwAbTpC+zy1wdWDGDYSai8145c5WRtDOkSnn1bCxu 0X/msijW+IpSmxRzL+LzPgYDr30+FVUSs+pObWeB51eU9CkC5fb60W6TQKMUHpqcMTL/ fcEwe/ctJzPCWmmZfR9cWQd8F2Lq7ocQrXq0zF5q+wTFvTRgT7T4llsh41FbyUMHB0/C rQcDNLjv15C1+0Womc1LkHoe4ymBwF1u2w/FG4/JE9mfeLfpAOXJ5Mppqho83Ibu+QcZ nmFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ls3mITwErZxu0k/FTh/7YzGbxphAJvvCquSRJmdlI4A=; b=NmWZlX9O54pCG14XPS/6aSHV1kgjEj40ARkwNzVg+u526z2Wf2LSW+xkoJ2WYtGj8E V3Dkt7yVjXTGpcU3IXFgSH4MH6yO5J+z+T5/ybH+MeCW86VNo7WrqksEkvjfU/0GcsEu FTp/UlNQ3eMtaToUMFcXmP4LFQom9wkQif153zeMLEnHOv2Vx20qhcJNsIKvi6KGn59Y 8QZyKAZ+nTSzLBnoCGUACgO10hj9Q0hvhhoxy7pAAlybQv2w0oHFdb//s+q4dO7HmTXv YQklQeokjQQumETCG3S02Q6U1Vh02lxotzJh+Xlqn8BIPuQE9rNmyUKjLU57opZiryVq 86Gw==
X-Gm-Message-State: ALyK8tJUo1+ujxqzFYBy0BPhSRu77tdJZLGAQQcy9+AfEZyj0wIEbVJj1DSaOVi6a2imkA==
X-Received: by 10.55.184.5 with SMTP id i5mr14982913qkf.33.1467249288950; Wed, 29 Jun 2016 18:14:48 -0700 (PDT)
Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id g15sm386095qta.33.2016.06.29.18.14.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Jun 2016 18:14:48 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: kathleen.moriarty.ietf@gmail.com
X-Mailer: iPhone Mail (12H143)
In-Reply-To: <CAF4+nEEOmuXKAsYrE1h8nrTZqejMKCm27FjVy_qi99XMDBzSzA@mail.gmail.com>
Date: Wed, 29 Jun 2016 21:14:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <962ACF5E-046F-4867-ACE4-5784D5C4A203@gmail.com>
References: <20160629194308.30337.11173.idtracker@ietfa.amsl.com> <CAF4+nEEOmuXKAsYrE1h8nrTZqejMKCm27FjVy_qi99XMDBzSzA@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/sFN-qML3mgAnFFcArgyeNBi6Qgs>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>, The IESG <iesg@ietf.org>, "trill@ietf.org" <trill@ietf.org>, "draft-ietf-trill-irb@ietf.org" <draft-ietf-trill-irb@ietf.org>
Subject: Re: [trill] Kathleen Moriarty's No Objection on draft-ietf-trill-irb-13: (with COMMENT)
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 01:14:51 -0000

Hi Donald,

Thanks for your quick response, inline.

Sent from my iPhone

> On Jun 29, 2016, at 6:57 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> 
> Hi Kathleen,
> 
> See below.
> 
> On Wed, Jun 29, 2016 at 3:43 PM, Kathleen Moriarty
> <Kathleen.Moriarty.ietf@gmail.com> wrote:
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-trill-irb-13: No Objection
>> 
>> ...
>> 
>> ----------------------------------------------------------------------
>> 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).
> 
> I am not sure what you mean by "session".
> 

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 


> 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
> d3e3e3@gmail.com