Subject: PIM-SM and SSM State Maintenance

From: Marshall Eubanks <[email-masked]>
Date: Tue, 05 Dec 2000 13:04:27 -0500

Hello;

In 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/dtssm.htm

there is :

     State Maintenance Limitations

     In PIM-SSM, the last hop router will continue to periodically send
(S, G) Join messages if 
     appropriate (S, G) subscriptions are on the interfaces. Therefore,
as long as receivers send (S, G) 
     subscriptions, the shortest path tree (SPT) state from the
receivers to the source will be 
     maintained, even if the source is not sending traffic for longer
periods of time (or even never).

     This case is opposite to PIM-SM, where (S, G) state is maintained
only if the source is sending 
     traffic and receivers are joining the group. If a source stops
sending traffic for more than 3 
     minutes in PIM-SM, the (S, G) state will be deleted and only
reestablished after packets from the 
     source arrive again through the RPT. Because no mechanism in
PIM-SSM notifies a receiver that source 
     is active, the network must maintain the (S, G) state in PIM-SSM as
long as there are receivers 
     requesting receipt of that channel.

I can find no mention of this in 

http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-01.txt  nor in

http://www.ietf.org/internet-drafts/draft-sandick-pimsm-ssmrules-00.txt
nor in 

http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-05.txt nor
even in

http://www.ietf.org/internet-drafts/draft-holbrook-idmr-igmpv3-ssm-00.txt

(BTW, this last document mentions a section 10.2 on page 2 which does
not apparently exist.)

Did I just miss it ? Or is this not part of the protocol ? 

Wouldn't this permit
a DOS, where a computer would just start issuing joins to every possible
group in 232/8 
for the victim's IP address, 
thereby creating a lot of state in the victim's first hop router ?

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 201
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com

---

From: Hugh Holbrook <[email-masked]>
Date: Tue, 5 Dec 2000 12:29:05 -0800 (PST)

> thereby creating a lot of state in the victim's first hop router ?

The SSM service model spec, draft-holbrook-ssm-arch-01.txt, has a
Security Considerations section (attached) that notes the DoS
possibility, suggests possible ways of alleviating it, and identifies
the risks of doing so.  This issue applies to SSM in general (both
PIM-SSM and IGMPv3 have this vulnerability, and would also apply to
most future implementations of SSM that I can reasonably imagine).
This is why it seemed somewhat appropriate to put it in the SSM
architecture spec rather than in a specific protocol spec, but feel
free to suggest otherwise.

> (BTW, this last document mentions a section 10.2 on page 2 which does

Ahah -- a section-renumbering casualty due to insufficient knowledge
of nroff.  It should refer to section 3.5.  Thanks.

-Hugh

----------------------------------------------------------------

7.  Security Considerations

7.1.  Denial-of-Service

A subscription request creates (S,G) state in a router to record the
subscription and invokes processing on that router and possibly causes
processing at neighboring routers.  A host can mount a denial of service
attack by requesting a large number of subscriptions.  A denial of
service can result if:

    - a large amount of traffic arrives when it was otherwise undesired,
    consuming network resources to deliver it and host resources to drop
    it

    - a large amount of source-specific multicast state is created in
    network routers, using router memory and CPU resources to store and
    process the state

    - a large amount of control traffic is generated to manage the
    source-specific state, using router CPU and network bandwidth

To reduce the damage from such an attack, a router MAY have a
configuration option to limit the following items:

    - The total rate at which all hosts on any one interface are allowed
    to initiate subscriptions (to limit the damage caused by forged
    source-address attacks)

    - The total number of subscriptions that can be initated from any
    single interface.

Holbrook/Cain                                                   [Page 9]

INTERNET-DRAFT          Source-Specific Multicast       24 November 2000

Any decision by an implementor to artificially limit the rate or number
of subscriptions should be taken carefully, however, as future
applications may use large numbers of channels.  Tight limits on the
rate or number of channel subscriptions would inhibit the deployment of
such applications.

A router SHOULD verify that the source of a subscription request is a
valid address for the interface on which it was received.  Failure to do
so would exacerbate a spoofed-source address attack.

We note that these attacks are not unique to SSM -- they are also
present for Any-Source Multicast.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 05 Dec 2000 16:32:50 -0500

Hi Hugh;

Thanks for the info.

> The SSM service model spec, draft-holbrook-ssm-arch-01.txt, has a

Note that in
http://www.ietf.org/ids.by.wg/none.html

this draft has exactly the same name :
"Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 11/30/2000. (27503 bytes)
as does
http://www.ietf.org/internet-drafts/draft-holbrook-ssm-00.txt :
"Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 03/13/2000. (37881 bytes)

wouldn't it be a good idea to give the two documents a different tag ? It took me a while to realize that they were, in fact,
different documents (not just different versions of the same draft).

> free to suggest otherwise.

But what occured to me is that if the state of the whole tree is maintained
IN THE ABSENCE OF ANY SOURCE ACTIVITY, then it would be very hard to
shut off, given some zombies with repeat requests. Maybe first hop routers should take note
of requests to (S,G) where there isn't actually a source, and deny repeated requests.

Marshall

> of nroff.  It should refer to section 3.5.  Thanks.

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com