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

[Yakov Rekhter <[e-mail]>]

Cathy,

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

If indeed the ID tracker said that 4761 is updated by 4762, then this
indeed is 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.

To the RFC the implementer is using.

Yakov.