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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 09:13:45 +0300 (EEST)

> can't be used for intra-domain DoS attack either.

How about SSM where you don't have any RPs and no (similar) multicast
domain?  The wildcard receiver argument applies equally to that as
well, AFAICS.

What about embedded-RP (or maybe also bidir-PIM, not sure), where the 
multicast domain practically includes all of the Internet?

(with multicast domain I refer to the area for which the group is 
active on under one RP or no RP at all (SSM).)

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 09:13:45 +0300 (EEST)

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 07 Apr 2004 02:05:54 -0700

> domain?  The wildcard receiver argument applies equally to that as

The (*,*,RP) Joins don't apply for the SSM multicast address range
simply because the RPs exclude that address range.

> active on under one RP or no RP at all (SSM).)

Still, the (*,*,RP) Joins don't cross domain boundaries (and here by
domain I mean entities as AS).
They are used by the border routers of a domain only to pull-out the
data traffic from within that domain when that traffic doesn't know
how to reach other domains on its own.

Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Wed, 07 Apr 2004 02:05:54 -0700

Pavlin

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Apr 2004 22:10:09 +0300 (EEST)

> simply because the RPs exclude that address range.

You miss the point.

Are you saying that PIM-SSM does not need to interoperate with other 
multicast routing protocols, as described in section 4.7?

This is orhogonal to whether (*,*,RP) is relevant or not in SSM, as 
that is just a specification detail.  I'm interested in more 
high-level issues.

> domain I mean entities as AS).

Do you mean that such a join would be blocked at the border of the PIM
domain (AFAIK not -- one only blocks BSR messages?), for example if
the routers along the path were manually configured to use
out-of-domain RP?

> how to reach other domains on its own.

The problem here is that "domain" is sufficiently ill-defined concept 
to make this "Wildcard receiver" feasible.

What is a domain when you want to "wildcard receive" all PIM-SSM 
sessions in the domain?  How is that done?  For that matter, what is 
the domain when you use embedded-RP where the you practically have 
only one domain per group?  Equally impossible considitions to 
satisfy.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Apr 2004 22:10:09 +0300 (EEST)

You miss the point.

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 09 Apr 2004 00:17:21 -0700

> multicast routing protocols, as described in section 4.7?

Yes.

> the routers along the path were manually configured to use

Yes, I think that any external (*,*,RP) messages should be blocked
at the border of the PIM domain. However, if you are exposing your
internal RPs to routers outside of your domain then you have to make
the administrative decision whether this means expanding the
boundaries of your PIM domain.

> only one domain per group?  Equally impossible considitions to 

You cannot use (*,*,RP) to receive the PIM-SSM sessions in the
domain. The (*,*,RP) messages can be used only for ASM.

In case of embedded-RP where you assume that the whole network is
one single PIM-SM domain you don't need (*,*,RP).
You need (*,*,RP) only when you are interconnecting a PIM-SM domain
with other domains.

Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 09 Apr 2004 00:17:21 -0700

Yes.

Pavlin

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 16:02:36 +0300 (EEST)

On Fri, 9 Apr 2004, Pavlin Radoslavov wrote:
> > multicast routing protocols [...] ?
> 
> Yes.

That is not apparent from section 4.7 or RFC2715, so if people agree
with this, we'd *at least* need an applicability statement in sectin
4.7 stating that PIM is not interoperable in certain scenarios.

> boundaries of your PIM domain.

Is this statement on what you believe should be done, or what is being 
done?

I've heard of no implementations blocking these messages.  It would be
painful, and it is not even specified in the specification AFAICS.
 
> domain. The (*,*,RP) messages can be used only for ASM.

That much is obvious, of course.  But the rules do not say that.  They 
give an impression that interoperability is always possible, with all 
protocols if you follow the rules.  

That's what I'm arguing against;  I'm saying that the rules only work
with traditional PIM-SM+MSDP.  They don't work with SSM.  They don't
work with Embedded-RP.  They don't work (AFAICS) with Bidir-PIM.

So is it really useful to have such rules here in the first place?

Or, if it is useful, we have to add a lot more "truth in advertising" 
so that the readers wouldn't be let to believe the interoperability, 
as described in section 4.7 would be actually possible except in the 
traditional scenario.

> one single PIM-SM domain you don't need (*,*,RP).

Were you listening or are you weaseling with words :)?  From 4.7.2:

.. there is no way to ensure that because you do not know about the 
internal sources, as there is no central intra-domain RP to keep track 
of all the sources.

> You need (*,*,RP) only when you are interconnecting a PIM-SM domain

I don't want to discuss whether you need (*,*,RP) or not.  I want to
discuss whether it is possible (or feasible, if possible) for PMBR to
know about all the "internal sources" (whatever that might mean e.g.  
with SSM, embedded-RP or bidir).  That is a must, but it's seems to be
clearly impossible.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 Apr 2004 16:02:36 +0300 (EEST)

---

From: John Zwiebel <[email-masked]>
Date: Fri, 9 Apr 2004 09:26:31 -0700

> with SSM, embedded-RP or bidir).  That is a must, but it's seems to be

2cents:

When PIM was first developed, the "denseness" or "sparseness" was
allocated to a router interface.  It didn't take too long to figure
out that this created all kinds of interoperability problems.

So, "denseness" and "sparseness" became allocated to a group and
that was for everywhere the group was to be transmitted to.  When
SSM came along, the group range 232/8 was allocated for it so there
would be no problems with interfering with dense or sparse.

Now, dense is atrophying and hopefully pim-sm will.  By extension
(and I confess there is probably no document that specifically
says this) the idea that the group uses a certain type of forwarding
behavior and that behavior is applicable everywhere is still in force.

So, I would not think that anything in the pim-sm spec has anything to
do with any other forwarding mode.  It is applicable to sparse-mode 
only.

ie, "all internal sources" is applicable to sparse-mode only.  I believe
this is the general understanding of the folks who work on this.

---

From: John Zwiebel <[email-masked]>
Date: Fri, 9 Apr 2004 09:26:31 -0700

2cents:

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 09 Apr 2004 11:18:34 -0700

> painful, and it is not even specified in the specification AFAICS.

If it is not in the spec then maybe it should.

There is nothing difficult about not accepting at the border routers
the external (*,*,RP) Join/Prune messages that arrive on specific
interfaces.

> work with Embedded-RP.  They don't work (AFAICS) with Bidir-PIM.

The rules do work with Bidir-PIM.
In case of SSM, if you need inter-operability between two
explicit-joins protocols that support (S,G) Joins, then you don't
need (*,*,RP) because inter-operability is trivial. If you try to
inter-operate between, say, PIM-SM and PIM-DM for SSM, then the
simple answer is you can't. You need additional mechanism to achieve
that and this mechanism doesn't need to be specified in the PIM-SM
spec.
In case of Embedded-RP if you explicitly (or implicitly) configure
your border routers with the limited set of embedded-RP router
addresses within your domain, then you can still use (*,*,RP).
Otherwise, I'd say that Embedded-RP doesn't work with the (*,*,RP)
mechanism, not the other way around :)
Remember that the (*,*,RP) rules were written long time ago when
there was no SSM, Bidir-PIM or Embedded-RP. The rules are there to
take advantage of them when you need so.

Yes.

> with SSM, embedded-RP or bidir).  That is a must, but it's seems to be

If you think that the wording "all internal sources" is what makes
the text confusing, then the answer is yes, you cannot use (*,*,RP)
to get the traffic from "all internal sources". You cannot get
the traffic from SSM sources, and you cannot get the traffic from
ASM sources when the RP is outside of the PMBR's domain (in the
latter the PMBR in the remote domain with the RP will take care
of that source).
In that case, the spec just needs to clarify this particular
statement.

Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 09 Apr 2004 11:18:34 -0700

Yes.

Pavlin

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 10:42:47 +0300 (EEST)

> do with any other forwarding mode.  It is applicable to sparse-mode 

The spec describes SSM, which by some definition is not "sparse-mode"?
(not sure where you draw the line..)

> this is the general understanding of the folks who work on this.

(.. but if you include it in sparse-mode, it's not applicable to "all 
internal sources")

The problem is IMHO that the document makes an unstated (and flawed)  
assumption that PIM-SM would make work precisely the same way that in
a domain (in the autonomous system sense) you could somehow know all
the internal sources.

Model like embedded RP has shown that this is not true.  (I think the 
same would apply to bidir when used with embedded RP as well.)

So, I'm not sure how applicable that section is in the first place, or 
whether major clarifications would be sufficient.  Impossible to say 
without considering the clarifications...

---

From: Pekka Savola <[email-masked]>
Date: Sat, 17 Apr 2004 10:42:47 +0300 (EEST)