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

Donald Eastlake <d3e3e3@gmail.com> Thu, 30 June 2016 03:50 UTC

Return-Path: <d3e3e3@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 2E9D012D516; Wed, 29 Jun 2016 20:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 8TdzmIYBDmQj; Wed, 29 Jun 2016 20:50:46 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 453CB12B031; Wed, 29 Jun 2016 20:50:46 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id s66so47748634oif.1; Wed, 29 Jun 2016 20:50:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LClHq8ueCC9Fx3ecKfKLwCPT6vBvcN5O44sgt73tKow=; b=NNjrf2hUXpgXkkbaMntPkBkCnwBqifyAJTOPjllheEhhdxFvPJTo2Vtsi7xJmT5/Kc v6Rna6DccGn6pZXgVeVjQME4wXdjpEbjKF/JmotTwMZKhL5xE63xKSrepgnHT+6CCeuX B5k2t4+i5Z+Qc42vUFJUuesbgwYLCOcSyEpiFfWR1hGcZS+gsv5uhp8WbY0Sha81Clqi B7pUfVwzTe3Q94Fnrt8XEEingGJcTo7qts17yDhDnhaCoMcY4dkfQkCC01fdMRkOwimU dR1OGBKtrURrzzIGK354MccsCUIcRYOBSnunhvS+b7d0EojA3D9dkB1KrALGf1z7qXG8 x0DQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LClHq8ueCC9Fx3ecKfKLwCPT6vBvcN5O44sgt73tKow=; b=S9DjYISOlrCAplRT2qYlFrLvBLzFqMncJc6aGwAAN8BB/eF50v37wA39JS+rFIyyDJ cd1CE36QYqeJbJ9LGpEnwU6a950L99Wo00DiyQSj1LRj3ad5CtQr9+U/E8ZvhdbHBFDH 5egbAewGwMs8sBB+/TuyDwg8T6pFdR5IU1kFxSfMPrBwJWCS3b0cFneXHLX12pP9UlM/ ao7k+mbWdiKNPsJt8SDSdr5B7aM7Y1zqLlW8loLVGS+T97VFSWMhzzXEEJf+LxsufwkY qO6KcmhxXO5lk0VRelCLLe33t2Dgl6V8uTu2XfA6yBqbGqYkGoFJ2IIJGeyPZ/Mr/dMz 3P9Q==
X-Gm-Message-State: ALyK8tLecHysmTCXLNlwH5n4D1CPwhZQF6kcDBDBGcV18lNWvY/zTfV3E24HZ4dRiwLnYhegMHPD4y80HaJRkg==
X-Received: by 10.157.3.48 with SMTP id 45mr7882582otv.172.1467258645512; Wed, 29 Jun 2016 20:50:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.52.242 with HTTP; Wed, 29 Jun 2016 20:50:31 -0700 (PDT)
In-Reply-To: <962ACF5E-046F-4867-ACE4-5784D5C4A203@gmail.com>
References: <20160629194308.30337.11173.idtracker@ietfa.amsl.com> <CAF4+nEEOmuXKAsYrE1h8nrTZqejMKCm27FjVy_qi99XMDBzSzA@mail.gmail.com> <962ACF5E-046F-4867-ACE4-5784D5C4A203@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Wed, 29 Jun 2016 23:50:31 -0400
Message-ID: <CAF4+nEH7qZwhVSmDcFj_T+j6dtNjM=necgyCrvBrDh-=wmaEiw@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/xbpKjLv_jPjEN6LFop4uYdOCzdg>
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 03:50:48 -0000

Hi Kathleen,

See below.

On Wed, Jun 29, 2016 at 9:14 PM,  <kathleen.moriarty.ietf@gmail.com> wrote:
> 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.

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
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> 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