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

[Jiangyuanlong <[e-mail]>]

Hi Stephen,

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

Best regards,
Yuanlong

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, December 03, 2015 8:49 PM
> To: The IESG
> Cc: [e-mail]; Dr. Nabil N. Bitar;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 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.

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

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

Thanks again,
Yuanlong