Re: [Pals] Stephen Farrell's No Objection on draft-ietf-l2vpn-vpls-pe-etree-10: (with COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 04 December 2015 12:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E641A9004; Fri, 4 Dec 2015 04:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 MTj0lXIWmt4U; Fri, 4 Dec 2015 04:34:21 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB6B1B30CE; Fri, 4 Dec 2015 04:33:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AE92EBE3F; Fri, 4 Dec 2015 12:33:36 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeUv_gX--mbQ; Fri, 4 Dec 2015 12:33:34 +0000 (GMT)
Received: from [10.87.48.95] (unknown [86.46.20.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71895BE38; Fri, 4 Dec 2015 12:33:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449232414; bh=wmGGXWaZ66UALgg7tM6tI0XMXVuZOnJi2yoT/MAtt/o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xRFCzjbibhjpDmHCe5ptR02eiSOj3yA0z5sbkrp2uqhDdVwdmVFBJt4co7pxOujNH PlLMNMvMLsIsic8iYlFyrdgesMwU8A0obsc282b8wIKdn/fxYxRzMVdT3l7WrxjkAy 26p6GHBiQcAu7Z5HsM0dsXQAg7li/qGNAFRDrqCo=
To: Jiangyuanlong <jiangyuanlong@huawei.com>, The IESG <iesg@ietf.org>
References: <20151203124855.28537.59385.idtracker@ietfa.amsl.com> <3B0A1BED22CAD649A1B3E97BE5DDD68B91600B18@szxema506-mbs.china.huawei.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <5661881D.3040202@cs.tcd.ie>
Date: Fri, 04 Dec 2015 12:33:33 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B91600B18@szxema506-mbs.china.huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/AEpAyz7Oz3jkaif-hmgLL0a6CfA>
Cc: "Dr. Nabil N. Bitar" <nabil.n.bitar@verizon.com>, "draft-ietf-l2vpn-vpls-pe-etree@ietf.org" <draft-ietf-l2vpn-vpls-pe-etree@ietf.org>, "draft-ietf-l2vpn-vpls-pe-etree.all@ietf.org" <draft-ietf-l2vpn-vpls-pe-etree.all@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "stbryant@cisco.com" <stbryant@cisco.com>
Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-l2vpn-vpls-pe-etree-10: (with COMMENT)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 12:34:23 -0000

Hiya,

On 04/12/15 09:18, Jiangyuanlong wrote:
> Hi Stephen,
> 
> Thanks a lot for the detailed comments, please see the inline
> comments.
> 
> Best regards, Yuanlong
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, December 03,
>> 2015 8:49 PM To: The IESG Cc:
>> draft-ietf-l2vpn-vpls-pe-etree@ietf.org; Dr. Nabil N. Bitar; 
>> draft-ietf-l2vpn-vpls-pe-etree.all@ietf.org; pals-chairs@ietf.org; 
>> stbryant@cisco.com; pals@ietf.org Subject: Stephen Farrell's No
>> Objection on draft-ietf-l2vpn-vpls-pe-etree-10: (with COMMENT)
>> 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-l2vpn-vpls-pe-etree-10: 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-l2vpn-vpls-pe-etree/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
Could you explain a bit to me how prevention of leaf-to-leaf
>> communication is enforced? I wasn't clear about that from a quick 
>> read, sorry. (I know it might not be quite in scope, being an 
>> implementation issue, but I'd like to know if it's easy to
>> explain.)
>> 
> [YJ] In a nutshell, a PE will not send packets it receives tagged
> with a leaf VLAN to any leaf nodes. More specifically, for a PE
> including a bridge module with IEEE 802.1-2014 capability: For each
> port of the bridge module, there is an egress VLAN translation table
> which indicates how to translate a VLAN for a frame received from
> T-VSI. If a port is attached with a leaf node, then leaf VLAN is
> translated to 0xFFF, and the frame will be discarded automatically. 
> On the other hand, if a port is attached with a root node, then leaf
> VLAN is translated to a normal VLAN (or removed) and the frame will
> be delivered to the root node.

Thanks for that.

> 
>> Are there possible attacks on signalling - e.g. to send fake
>> packets saying some node is a root, when it's a leaf? If so
>> shouldn't those be recognised in the security considerations?
>> 
> [YJ] if a PE is compromised or LDP is spoofed by some middle-man
> (though rarely for carrier networks), this may happen indeed. It
> seems the Security considerations in LDP protocol (RFC3036/5036)
> already cover the signaling security as a whole, and indirectly
> referenced in this document (by referring to Security considerations
> of RFC4762). One argument would be: this fake root situation is no
> worse than the construction of a VPLS where every CE node is actually
> a root (a PE could choose to do so if it is compromised).

(Generally, I'm not a fan of "no worse than" arguments, as they
cause us to forget or not notice many of the ways in which things
can be compromised. And in many cases the thing that we are "no
worse than" is not very robust from a security perspective, even
sometimes depending on trusting non-compromised behaviour from
every single host inside a network!)

I think you could note the additional attack vector introduced
here, and then (if you must:-) say that it's "no worse."

> 
>> I think section 9 should describe the kind of node compromises
>> that would invalidate the "no leaf to leaf" protections that are
>> needed for this to work. The intent should be just to allow
>> implementers to realise when a node that they are designing or
>> deploying might need to be (better) protected against compromise.
>> Were is possible to say something useful about how to mitigate such
>> compromises, that'd be good too. (But it may amount to "harden your
>> kit" I guess, which could be enough to say if one knows which bits
>> of kit need hardening against what.)
>> 
> [YJ] it seems authenticity and integrity measures are needed for LDP
> session messages, as dictated by RFC3036/5036. Not sure whether it
> make sense to add a note for service providers in the document, such
> as: if a root node or root VLAN is inappropriately configured,
> service frames may be leaked out unintentionally.

I'd say "inappropriately configured or compromised" and do think it'd
be a good addition as you'd be describing the security considerations
related to this document, in this document, which is the goal of that
section of this document:-)

S.


> 
> Thanks again, Yuanlong
>