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

["NAPIERALA, MARIA H, ATTLABS" <[e-mail]>]

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. 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. For example, mVRF
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.



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

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


Maria

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