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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 03 Dec 2015 04:48:55 -0800

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.)

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?

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.)

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 4 Dec 2015 09:18:44 +0000

Hi Stephen,

Thanks a lot for the detailed comments, please see the inline comments.

Best regards,
Yuanlong

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, December 03, 2015 8:49 PM
> To: The IESG
> Cc: [email-masked]; Dr. Nabil N. Bitar;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's No Objection on draft-ietf-l2vpn-vpls-pe-etree-10: (with
> COMMENT)
> 
[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.

> 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).

> could be enough to say if one knows which bits of kit need hardening
[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.

Thanks again,
Yuanlong

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 12:33:33 +0000

Hiya,

On 04/12/15 09:18, Jiangyuanlong wrote:
> Best regards, Yuanlong
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Thursday, December 03,
>> 2015 8:49 PM To: The IESG Cc:
>> [email-masked]; Dr. Nabil N. Bitar; 
>> [email-masked]; [email-masked] Subject: Stephen Farrell's No
>> Objection on draft-ietf-l2vpn-vpls-pe-etree-10: (with COMMENT)
>> 
>> 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.
>> 
>> 
> [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