Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]