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

From: "Black, David" <[email-masked]>
Date: Mon, 23 Sep 2013 21:02:17 -0400

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 ​[email-masked] if you reply to or
forward this 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?

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

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Sep 2013 07:26:58 -0700

David,

> they receive. Please always CC ​[email-masked] if you reply to or

Thanks for your review.

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

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 24 Sep 2013 13:33:01 -0400

Yakov,

First of all, thank you for overlooking the "off-by-one" error on
the year :-) -

> > IETF LC End Date: September 23, 2012

Of course, 2013 was intended, twice ;-).

On the two items (both are editorial, IMHO):

> 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

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.

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

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

Thanks,
--David

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, September 24, 2013 10:27 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
> 
> David,
>

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Sep 2013 17:13:19 -0700

David,

> Of course, 2013 was intended, twice ;-).

:-)

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

> 	amplifiers in denial of service attacks.

I'll add this.

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

---

From: "Black, David" <[email-masked]>
Date: Wed, 25 Sep 2013 12:17:02 -0400

Yakov,

>   replication requires two labels stack.

Sure, minor suggestion - "two labels stack" -> "two MPLS labels in the label stack" (twice).

> > 	amplifiers in denial of service attacks.

Ok, but see below for a combined text suggestion that includes ...

> I would greatly appreciated if you would help me with "a sentence

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

> Sent: Tuesday, September 24, 2013 8:13 PM
> To: Black, David
> Cc: Yakov Rekhter; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-
> 1
> 4
> > >
> > > David,
> > >

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2013 09:28:54 -0700

David,

> in the label stack" (twice).

Ok.

>    service attack based on sending large amounts of traffic).

That is fine. Thanks for the text !

Yakov.