David, > 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). Ok. > > > 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). That is fine. Thanks for the text ! Yakov.