ietf
[Top] [All Lists]

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

2013-09-26 10:12:18
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.