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

[Stewart Bryant <[e-mail]>]

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


-- 
For corporate legal information go to:

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