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

[Thomas Morin <[e-mail]>]

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
>