Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

[Yakov Rekhter <[e-mail]>]

Maria,

> Hi Marshall,
> 
> > This is of course true for normal (non L3VPN) multicasts, and has
> > largely been dealt with
> > by a combination of filtering and rate limiting 
> 
> In MVPN we are dealing with very large scale and very dynamic
> environment, with multiple MVPNs provisioned on the same PE. We have to
> be generous with multicast route volume (their number and frequency)
> because such are customers' needs. We implemented all possible
> protection knobs that were reasonable to customers and to us as a
> Service Provider to be able to deal with large volume of MVPNs and their
> size. 
> 
> My point about announcing Active Source BGP routes when source is not
> active is that it makes MVPN vulnerable to misconfigured or malicious
> end-users/PCs. Specifically, a multicast (C-S, C-G) BGP route is sent
> only to a specific upstream PE while Active Source BGP routes are sent
> to all PEs (in a given VPN) and for each (C-S, C-G) BGP route there is a
> corresponding Active Source route. If there is an end-user/PC which is
> misconfigured or even malicious, it can generate lots of invalid IGMP
> (S,G) joins which will be translated to Active Source A-D routes and
> replicated on every MVPN PE. All those Active Source routes would be
> useless but will take up BGP resources. 

See the e-mail from Thomas Morin on this topic that he sent today
(I attached it).

>                                         In addition, there is no
> requirement (and it shouldn't be) in the spec that only MI-PMSIs are
> used for C-S traffic but that also S-PMSIs can be used. The S-PMSIs
> could be, e.g., pre-provisioned in mVRFs. 

Your claim that "S-PMSIs could be .. "pre-provisioned" is incorrect, as
*by definition* S-PMSIs are not pre-provisioned, but are established
dynamically. 

> configuration could specify per root PE and per C-G an S-PMSI used for
> sending traffic from all C-S's of C-G attached to the root PE. All those
> tunnels would be useless but will take up VPN core transport resources.

To avoid useless S-PMSI tunnels one could require that S-PMSIs be
created only when there is traffic to be carried over these S-PMSIs.
In fact 7.2 of draft-ietf-l3vpn-2547bis-mcast-07.txt is very explicit
about this:

                  If a particular stream has a significant amount of
   traffic, it may be beneficial to move it to an S-PMSI that includes
   only those PEs that are transmitters and/or receivers (or at least
   includes fewer PEs that are neither).

> > I would think that the VPN situation would be even easier to control
> > (it should be easier to
> > determine what is and isn't authorized, for example).
> 
> There is really no way to control what multicast routes we receive in
> MVPN context and even MVPN customers tell us that they can't fully
> control it. What we see is that multicast routing in VPN is a completely
> different than unicast routing, i.e., we have to deal with end-user
> activity and not just with router activity. 
> I believe that MVPN technology should, if anything, make MVPN "tighter"
> that is less and not more exposed to such spurious multicast events. 
> According to BGP spec, each (C-S,C-G) PIM route might have tree
> different BGP versions: Source Tree Join route, Source Active A-D route,
> and possibly S-PMSI A-D route ...

That is incorrect - each (C-S, C-G) PIM route have just *one* version,
namely Source Tree Join C-multicast route.

> > Are you saying that you have seen these kinds of DOS attacks in  
> > practice
> 
> Yes. We saw large number of spurious sources. It was due to customer's
> misconfiguration of a large MVPN.

See the e-mail from Thomas Morin on this topic that he sent today
(I attached it).

Yakov.
-------------------------------------------------------------
Date:    Mon, 15 Dec 2008 11:51:24 +0100
To:      "NAPIERALA, MARIA H, ATTLABS" <[e-mail]>
cc:      [e-mail], Danny McPherson <[e-mail]>
From:    Thomas Morin <[e-mail]>
Subject: RE: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

Hi Maria,

NAPIERALA, MARIA H, ATTLABS :
> >
> > Might there be situations where receivers want to set up a multicast
> > route for
> > source regardless of whether the source is currently active, to reduce
> > the time for source data to propagate ? So in that case this would be
> > legitimate.
> > 
> > Otherwise, joins to sources that are not active will generally stop.
> > Or are you worried about
> > DOS attacks ?
> 
> Yes, I think that triggering Source Active A-D routes when receiving
> (S,G) Joins without the knowledge that S is actually "active" creates a
> security issue. 

I don't agree with your formulation. Let's suppose that there is a
security issue due to spurious state being created because of an
inactive source "mistaken" as active.  Let's suppose we try to solve the
issue by avoiding inactive sources to create these states.  The
"attacker" on the customer side can still create the same states by
making the right number of source active.


> A single end-user PC can generate a lot of spurious
> IGMP (S,G) joins that could trigger lots of BGP updates and potentially
> useless S-PMSIs in VPN core.

Well, I'm lost here : since when do IGMP S,G joins create S-PMSI
routes ?  

It is true that IGMP activity (and PIM) on the customer side will create
state on the PEs, and that this has to be controlled in some kind of
way, but this is not specific to BGP, nor related to S-A A-D routes or
S-PMSI routes...


Now, if we take a broader perspective, I agree that we must ensure that
there are safeguards to avoid that customers could creates an unbounded
amount of states in the PEs (and RRs) :
- it applies to state in the PEs that is created directly based on state
on the PE-CE interfaces : (S,G) and (*,G) joins
  * we need safeguards to avoid too much states created on PEs based on
customer PIM activity 
  * it implies having the operator configure upper bounds on the amount
of multicast states in the VRFs
  * this is true independently of the protocol used for C-multicast
routing
- it also applies to states created "indirecly" based on customer
activit: Source-Active and S-PMSI A-D routes
  * we need safeguards to cover these
  * S-PMSI routes are created based on (a) customer activity and (b) PE
policy defined by the operator   --> there is a need to bound the
amount, and frequency of changes, of S-PMSI state   (this critical to
protect P routers, and is true independently of the protocol used to
signal S-PMSIs)
  * S-A A-D routes are also created based on customer activity:
      -> in the context of section 13, they are only created based on
Source Tree Join routes, so if these are properly bounded, it should be
fine  
      -> in the context of section 14, they are created based on RP
activity, or PIM registers, or MSDP : bounds would typically also setup
here
      -> if we want more solive boundaries, it seems to me that it makes
sense to suggest that implementation should provide a way to set an
upper bound to the number of S-A A-D routes that can be advertised from
a VRF

Cheers,

-Thomas


> > -----Original Message-----
> > From: Marshall Eubanks [mailto:[e-mail]]
> > Sent: Sunday, December 14, 2008 8:33 AM
> > To: NAPIERALA, MARIA H, ATTLABS
> > Cc: Danny McPherson; [e-mail]
> > Subject: Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> > 
> > Dear Maria;
> > 
> > On Dec 12, 2008, at 4:17 PM, NAPIERALA, MARIA H, ATTLABS wrote:
> > 
> > > PIM-SM/RFC 4601 permits, quote, "a receiver to join a group and
> > > specify
> > > that it only wants to receive traffic for a group if that traffic
> > > comes
> > > from a particular source. If a receiver does this, and no other
> > > receiver
> > > on the LAN requires all the traffic for the group, then the DR may
> > > omit
> > > performing a (*,G) join to set up the shared tree, and instead issue
> > a
> > > source-specific (S,G) join only."
> > >
> > > Such behavior of end systems in PIM-SM means that a PE can receive
> > > Join
> > > (C-S, C-G) even for sources that are not active.
> > >
> > > Section 13.1 of draft-ietf-l3vpn-2547bis-mcast-bgp-05 requires that
> > > "whenever a PE creates an <C-S,C-G> state as a result of receiving a
> > > Source Tree Join C-multicast route for <C-S, C-G> from some other
> PE,
> > > the PE that creates the state MUST originate a Source Active A-D
> > > route."
> > >
> > > The procedure as described in section 13.1 might lead to useless S-
> > > PMSI
> > > creation for C-sources operating in sparse groups which are not
> > > active.
> > > This procedure should be enhanced to prevent triggering of S-PMSIs
> in
> > > such cases.
> > 
> > Might there be situations where receivers want to set up a multicast
> > route for
> > source regardless of whether the source is currently active, to reduce
> > the time for source data to propagate ? So in that case this would be
> > legitimate.
> > 
> > Otherwise, joins to sources that are not active will generally stop.
> > Or are you worried about
> > DOS attacks ?
> > 
> > Regards
> > Marshall
> > 
> > >
> > >
> > > Maria
> > >
> > >> -----Original Message-----
> > >> From: [e-mail] [mailto:[e-mail]] On
> > >> Behalf
> > >> Of Danny McPherson
> > >> Sent: Friday, November 21, 2008 8:52 AM
> > >> To: [e-mail]
> > >> Subject: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp
> > >>
> > >>
> > >> Please consider today the start of a 2-week last call
> > >> for draft-ietf-l3vpn-2547bis-mcast-bgp, available here:
> > >>
> > >> http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-bgp-05
> > >>
> > >> Input on this draft's suitability for publication as an
> > >> Internet Standards Track document is solicited, feedback
> > >> ends December 9, 2008.
> > >>
> > >> Thanks in advance for your feedback!
> > >>
> > >> Danny & Marshall
>