Re: [trill] draft-ietf-trill-o-pw comments

Erik Nordmark <nordmark@acm.org> Tue, 26 November 2013 22:42 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACA61AE012 for <trill@ietfa.amsl.com>; Tue, 26 Nov 2013 14:42:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
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 v8cBIZwIE14T for <trill@ietfa.amsl.com>; Tue, 26 Nov 2013 14:42:53 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D91ADFF2 for <trill@ietf.org>; Tue, 26 Nov 2013 14:42:53 -0800 (PST)
Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAQMgpJm019767 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 26 Nov 2013 14:42:51 -0800
Message-ID: <529523EC.8030307@acm.org>
Date: Tue, 26 Nov 2013 14:42:52 -0800
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@gmail.com>, Erik Nordmark <nordmark@acm.org>
References: <52938AC0.5060901@acm.org> <CAF4+nEGxbc-as6bZ5TNXoLGoYCsZtSxO7f7Ws4=PpohdaVgkBQ@mail.gmail.com>
In-Reply-To: <CAF4+nEGxbc-as6bZ5TNXoLGoYCsZtSxO7f7Ws4=PpohdaVgkBQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;NKHPFOxW4xGu42E96sd3kQ== M;RrjiFOxW4xGu42E96sd3kQ==
Cc: "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] draft-ietf-trill-o-pw comments
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 26 Nov 2013 22:42:56 -0000

On 11/26/13 1:52 PM, Donald Eastlake wrote:

>> In security considerations we have
>>     For security considerations introduced by carrying PPP TRILL links
>>     over pseudowires, see [RFC3985].
>> I assume RFC 3985 doesn't talk about TRILL - but about PPP in general. Thus
>> it would be more clear if we drop "TRILL" from that sentence.
>
> Actually, RFC 3985 is not PPP specific but talks about the risks
> generally introduced by sending protocols that previously assumed a
> local point-to-point link on a pseudo wire built on a packet switched
> network. So I suggest replacing
>
> "For security considerations introduced by carrying PPP TRILL links
> over pseudowires, see [RFC3985]."
>     with
> "For security considerations introduced by carrying PPP TRILL links
> over pseudowires, see [RFC3985] which discusses the risks introduced
> by sending protocols that previously assumed a point-to-point link on
> a pseudo wire built on a packet switched network (PSN)."

Works for me.

>> The 3rd paragraph starts with
>>     Not all implementations need to include specific security mechanisms
>>     at the pseudowire layer ...
>> Is this a relaxation of the general PW security requirements? Or merely
>> re-stating the stance for security for PW? It would make sense to spell that
>> out in the document.
>
> That paragraph is an edit of the following paragraph that appears in
> the Security Considerations section of RFC 6361 on TRILL over PPP:
>
>     Not all implementations need to include specific security mechanisms
>     at the PPP 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.  For
>     applications involving sensitive data, end-to-end security should
>     always be considered in addition to link security to provide security
>     in depth.

For clarity I think it makes sense adding a reference to RFC 6361 with 
something like
	Just like in RFC 6361, not all ...

It probably makes sense to separate out the last added sentence ("In 
this context, such end-to-end security should
    be between the end stations involved so as to protect the entire path
    to, through, and from the TRILL campus") into a separate paragraph.

That hopeful makes it more clear to the security folks what is new and 
different.

Thanks,
    Erik

> I think the paragraph is just talking about the range of security
> environments and PWE3 TRILL transport uses, that in some cases you
> don't need to worry so much about it while in others you should also
> be using end station to end station security no matter how good you
> think your PWE3 security is. I also think it would be better if "...
> implementations need to include ..." was replaced by "... deployments
> need to use ..." or something like that.
>
> Thanks,
> Donald
> =============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street, Milford, MA 01757 USA
>   d3e3e3@gmail.com
>
>>     Erik
>