Subject: [secdir] SecDir Review of draft-ietf-l2vpn-vpls-mcast-14

From: Catherine A Meadows <[email-masked]>
Date: Thu, 19 Sep 2013 14:21:05 -0400

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This ID describes a method by which service providers for Virtual Private LANs can use multicast trees for routing
muilticast messages to customers in VPLS.  This extends RFC's  4761 "Virtual Private LAN Service using
BGP for Auto-Discovery and Signaling" and 4762, "Virtual Private LAN Services
over MPLS Label Distribution Protocol (LDP) Signaling".  In these RFC's, the ingress Provider Edge Device (ingress PE)
replicates a copy of the message for each relevant exit PE.  This can become a performance bottleneck when the
number of recipients is large.  This ID addresses this problem.

This ID addresses mainly internal network management, and so, as the authors point out in the Security Considerations Section,
it does not introduce many security problems other than already discussed in those RFC's, which are mainly addressed by the
security features of BGP, upon which the protocols rely.  The main security issue introduced by this draft is that neither
BGP nor VPLS provide for secrecy of the multicast tree data.  However, as the authors point out, providing such security
is the responsibility of the Service Provider managing the LAN, and this is beyond the scope of VPLS.

I do not think any modifications or extensions need to be made to the security section, but I have a couple of other questions:

This ID is described as being intended for use with RFC's 4761 and 4762, but when I checked on 4761 in the ID tracker,
it said that it is updated by 4762, although 4762 itself says nothing about this.  In that case, is there any reason to provide support for 4761?  Or was this an error in the ID tracker?

Likewise, the ID refers to both 4761 and 4762 for definitions of terms.  What happens if the two RFC's don't agree on
a definition?  Should one default to 4762, or to the RFC the implementer is using?  According to RFC 4762, the protocol
defined by the two RFC's, although they perform similar functions, are independent and incompatible, so this could
make possibly a difference.

Cathy Meadows

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 23 Sep 2013 12:04:19 +0100

Cathy,

Thank you for the review.

The only update I can see, which only shows in
the tools page and not the datatracker, is by
RFC5462, and given the subject matter of RFC5462
the only change can be the renaming of the EXP
bits to TC bits. This is well known in the MPLS
community, and enhances rather than diminishes
security. There were a few people that
felt inclined to do production network experiments
with these distinctly non-experimental bits and the
purpose of RFC5462, was to stop that happening.
There is no implication for this draft.

- Stewart

On 22/09/2013 23:50, Yakov Rekhter wrote:
> Cathy,
>> This ID describes a method by which service providers for Virtual
>> Private LANs can use multicast trees for routing
>> over MPLS Label Distribution Protocol (LDP) Signaling".  In these RFC's, the
>> ingress Provider Edge Device (ingress PE)
>> This ID addresses mainly internal network management, and so, as the authors
>> point out in the Security Considerations Section,
>> it does not introduce many security problems other than already discussed in
>> those RFC's, which are mainly addressed by the
>> security features of BGP, upon which the protocols rely.  The main security
>> issue introduced by this draft is that neither
>> BGP nor VPLS provide for secrecy of the multicast tree data.  However, as the
>> authors point out, providing such security
>> I do not think any modifications or extensions need to be made to the
>> security section, but I have a couple of other questions:
>>
>> This ID is described as being intended for use with RFC's 4761 and 4762, but
>> when I checked on 4761 in the ID tracker,
>> it said that it is updated by 4762, although 4762 itself says nothing
>> about this.  In that case, is there any reason to provide support for
>> 4761?  Or was this an error in the ID tracker?
> If indeed the ID tracker said that 4761 is updated by 4762, then this
> indeed is an error in the ID tracker.
>
>> a definition?  Should one default to 4762, or to the RFC the implementer
>> is using?  According to RFC 4762, the protocol
>> defined by the two RFC's, although they perform similar functions,
>> are independent and incompatible, so this could
> To the RFC the implementer is using.
>
> Yakov.
>
> .
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 22 Sep 2013 15:50:09 -0700

Cathy,

Yakov.