Subject: Re: [pim] pim-sm-v2-new-09 and PMBR issues

From: Pavlin Radoslavov <[email-masked]>
Date: Tue, 06 Apr 2004 16:26:53 -0700

[Note: a reply to a 2 weeks old email]

I will reply only to Issue 2 below.
I will leave other folks to reply re. Issue 1.

> Hi,
> 
> (I read through the pim spec, and I'll be writing up my comments in a 
> couple of days .. but there's one biggest issue which I wanted to 
> raise immediately..)
> 
> Section 4.7 defines the behaviour of PIM-SM router which is 
> interfacing a different multicast routing protocol, referring to RFC 
> 2715.
> 
> Issue 1: the whole point may be moot because RFC 2715 is
> Informational, and this is aimed aa Standards Track; there can be no
> normative reference to it.
> 
> Possible resolution: decrease the weight of RFC 2715 in this document,
> and move RFC 2715 off to informative references.
> 
> Issue 2: the wildcard receiver requirement (see below) is completely
> unrealistic, could be an enermous DoS component, and is completely
> inpractical -- not to mention failing to work with mechanisms like
> SSM, Embedded-RP or Bidir-PIM (?) -- where a random edge router does
> not know about all the groups in a domain.  Imagine a case where you
> could associate with a PIM-SM router, and act as a wildcard receiver.  
> Instand multicast DoS as the PIM-SM router would have to join to every
> source in the Internet!!!! 
> 
> Suggestion: discuss this requirement.  My feeling is that it should be
> deprecated (with caveats, and describing its limitations) or removed
> completely.

The (*,*,RP) Join is generated only by the border routers for the
RPs within their own domain. In other words, the (*,*,RP) Join is
not carried across domains. Hence, you cannot use it for
inter-domain DoS attacks.
Within a domain, the assumption is that you trust your own routers
for the (*,*,RP) Join generation (among all other stuff), hence it
can't be used for intra-domain DoS attack either.

Pavlin

> ============
> 4.7.2.  Sources Internal to the PIM-SM Domain
> 
> A PMBR needs to ensure that traffic from sources inside the PIM-SM
> domain reaches receivers outside the domain.  Using terminology from RFC
> 2715, there are two possible scenarios for this:
> 
> o Another component of the PMBR is a wildcard receiver.  In this case
>   the PIM-SM component of the PMBR must ensure that traffic from all
>   internal sources reaches the PMBR until it is informed otherwise.
> 
> o No other component of the PMBR is a wildcard receiver.  In this case
>   the PMBR will receive explicit information as to which groups or 
>   (source,group) pairs the external domains wish to receive.
> 
> In the former case, the PMBR will need to send a Join(*,*,RP) to all the
> RPs in the PIM-SM domain.  This will cause all traffic in the domain to 
> reach the PMBR.  The PMBR may then act as if it were a DR with directly
> connected receivers, and trigger the transition to a shortest path tree
> (see Section 4.2.1).
> 
> In the latter case, the PMBR will not need to send Join(*,*,RP)
> messages.  However the PMBR will still need to act as a DR with directly
> connected receivers on behalf of the external receivers in terms of
> =========
> 
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pim

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim