Yakov, > How about if I'll add the following at the end of 5.5: > > Aggregation procedures would require two labels stack. > This does not introduce any new implications on MTU, > as even VPLS multicast supported by ingress > replication requires two labels stack. Sure, minor suggestion - "two labels stack" -> "two MPLS labels in the label stack" (twice). > > I'd suggest an initial sentence: > > > > Replication of traffic within a multicast tree, and flooding > > of traffic (see section 14) could be employed as traffic > > amplifiers in denial of service attacks. > > I'll add this. Ok, but see below for a combined text suggestion that includes ... > > Followed by a sentence or sentences that list a few important applicable > > countermeasures (your choice), explaining why each is applicable and > > indicating where each is described (this document, RFC 4761 or RFC 4762). > > I would greatly appreciated if you would help me with "a sentence > or sentences" to cover this. I don't think RFC4761 or RFC4762 > describe any of such countermeasures. The security considerations section already contains this sentence: As mentioned in [RFC4761], there are two aspects to achieving data privacy and protect against denial-of-service attacks in a VPLS: securing the control plane and protecting the forwarding path. The rest of that paragraph covers data privacy and black-holing. Perhaps just extend the last sentence, e.g.,: OLD In addition, compromise of the control plane could result in black- holing VPLS multicast data. NEW In addition, compromise of the control plane could result in black- holing VPLS multicast data and could provide opportunities for unauthorized VPLS multicast usage (e.g., exploiting traffic replication within a multicast tree to amplify a denial of service attack based on sending large amounts of traffic). Thanks, --David > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@xxxxxxxxxxx] > Sent: Tuesday, September 24, 2013 8:13 PM > To: Black, David > Cc: Yakov Rekhter; tsv-dir@xxxxxxxx; raggarwa_1@xxxxxxxxx; y.kamite@xxxxxxx; > lufang@xxxxxxxxx; ietf@xxxxxxxx; l2vpn@xxxxxxxx; stbryant@xxxxxxxxx > Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14 > > David, > > > Yakov, > > > > First of all, thank you for overlooking the "off-by-one" error on > > the year :-) - > > > > > > Review Date: September 23, 2012 > > > > IETF LC End Date: September 23, 2012 > > > > Of course, 2013 was intended, twice ;-). > > :-) > > > On the two items (both are editorial, IMHO): > > > > > > (1) The techniques in this draft appear to add an MPLS label to the > > > > stack in order to identify the MPLS multicast tree. Does that added > > > > label raise any MTU concerns in practice? > > > > > > No more than any other use of label stacking (and there are plenty > > > of other uses of label stacking). > > > > I concur, which is why I noted this item as editorial - I don't think > > it's an actual issue. > > > > > Furthermore, rfc3032 ("MPLS Label > > > Stack Encoding") does cover the MTU issue. > > > > A sentence to that effect (lots of uses of label stacking, MTU effects > > are both well understood and not a problem in practice) with a > > reference to RFC 3032 should suffice. > > How about if I'll add the following at the end of 5.5: > > Aggregation procedures would require two labels stack. > This does not introduce any new implications on MTU, > as even VPLS multicast supported by ingress > replication requires two labels stack. > > > > > (2) Two techniques used by this draft - replication of traffic within > > > > a multicast tree, and flooding of traffic (section 14) - could be > > > > employed as traffic amplifiers in denial of service attacks. A short > > > > discussion of this possibility and the applicability of countermeasures > > > > described in this draft, RFC 4761 and/or RFC 4762 would be good to > > > > add to the security considerations section. > > > > > > The Security Consideration section already talks about 4761 and 4762: > > > > > > Security considerations discussed in [RFC4761] and [RFC4762] apply to > > > this document. > > > > > > Suggestion on any additional text would be greatly appreciated. > > > > I'd suggest an initial sentence: > > > > Replication of traffic within a multicast tree, and flooding > > of traffic (see section 14) could be employed as traffic > > amplifiers in denial of service attacks. > > I'll add this. > > > Followed by a sentence or sentences that list a few important applicable > > countermeasures (your choice), explaining why each is applicable and > > indicating where each is described (this document, RFC 4761 or RFC 4762). > > I would greately appreciated if you would help me with "a sentence > or sentences" to cover this. I don't think RFC4761 or RFC4762 > describe any of such countermeasures. > > Yakov. > > > > > > -----Original Message----- > > > From: Yakov Rekhter [mailto:yakov@xxxxxxxxxxx] > > > Sent: Tuesday, September 24, 2013 10:27 AM > > > To: Black, David > > > Cc: tsv-dir@xxxxxxxx; raggarwa_1@xxxxxxxxx; y.kamite@xxxxxxx; > > > lufang@xxxxxxxxx; yakov@xxxxxxxxxxx; ietf@xxxxxxxx; l2vpn@xxxxxxxx; > > > stbryant@xxxxxxxxx; yakov@xxxxxxxxxxx > > > Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast- > 1 > 4 > > > > > > David, > > > > > > > I've reviewed this document as part of the transport area directorate's > > > > ongoing effort to review key IETF documents. These comments were written > > > > primarily for the transport area directors, but are copied to the > > > > document's authors for their information and to allow them to address > > > > any issues raised. When done at the time of IETF Last Call, the authors > > > > should consider this review together with any other last-call comments > > > > they receive. Please always CC ​tsv-dir@xxxxxxxx if you reply to or > > > > forward this review. > > > > > > Thanks for your review. > > > > > > > Document: draft-ietf-l2vpn-vpls-mcast-14 > > > > Reviewer: David L. Black > > > > Review Date: September 23, 2012 > > > > IETF LC End Date: September 23, 2012 > > > > > > > > Summary: This draft is basically ready for publication, but has nits > that > > > > should be fixed before publication. > > > > > > > > This draft describes multicast optimizations for VPLS via use of MPLS > > > > multicast distribution trees within the service provider (SP) network. > > > > > > > > In general, the techniques in this draft are an improvement, as they > > > > should typically result in reduction of SP network traffic required > > > > to carry the same level of multicast traffic originating from the VPLS > > > > edges. I have reviewed primarily for transport-related topics; while > > > > I don't have the expertise to review for MPLS and VPLS concerns, I'm > > > > confident in the expertise of this author team in those technologies. > > > > > > > > I found a couple of items that are effectively editorial: > > > > > > > > (1) The techniques in this draft appear to add an MPLS label to the > > > > stack in order to identify the MPLS multicast tree. Does that added > > > > label raise any MTU concerns in practice? > > > > > > No more than any other use of label stacking (and there are plenty > > > of other uses of label stacking). Furthermore, rfc3032 ("MPLS Label > > > Stack Encoding") does cover the MTU issue. > > > > > > > > > > > (2) Two techniques used by this draft - replication of traffic within > > > > a multicast tree, and flooding of traffic (section 14) - could be > > > > employed as traffic amplifiers in denial of service attacks. A short > > > > discussion of this possibility and the applicability of countermeasures > > > > described in this draft, RFC 4761 and/or RFC 4762 would be good to > > > > add to the security considerations section. > > > > > > The Security Consideration section already talks about 4761 and 4762: > > > > > > Security considerations discussed in [RFC4761] and [RFC4762] apply to > > > this document. > > > > > > Suggestion on any additional text would be greatly appreciated. > > > > > > Yakov. > > > > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer > > > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > > > +1 (508) 293-7953            FAX: +1 (508) 293-7786 > > > > david.black@xxxxxxx       Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > > > > > > > > >