All things related to multicast

[Leonard Giuliano <>]

The following is a DR and RP register filter that will only allow groups 
in 224/8 and 233/8 to send registers from the DR and allow registers at 
the RP (along with blocking some bogon sources/groups).  MSDP filters can 
then be used to filter the SAs that RPs exchange with one another.

I'm in the process of adding these register filters to 
http://www.juniper.net/solutions/literature/app_note/350051.pdf, which is 
a BCP on hardening a mcast infrastructure.  This BCP suggests using 
whitelists to only allow 224/8, 232/8 and 233/8 traffic.  By allowing only 
these three /8s, you can eliminate 81% of the random junk.  If you still 
want the random junk to be permitted locally, you can just apply these 
whitelists at your borders.


protocols {
    pim {
        rp {
            /* config rp-reg-policy on RP */
            rp-register-policy [ Bogon-Sources ASM-Allow ];
            /* config dr-reg-policy on source DR */
            dr-register-policy [ Bogon-Sources ASM-Allow ];
        }
    }
}
policy-options {
    policy-statement ASM-Allow {
        term Bogon-Groups {
            from {
                route-filter 224.0.1.2/32 exact;
                route-filter 224.0.1.3/32 exact;
                route-filter 224.0.1.8/32 exact;
                route-filter 224.0.1.22/32 exact;
                route-filter 224.0.1.24/32 exact;
                route-filter 224.0.1.25/32 exact;
                route-filter 224.0.1.35/32 exact;
                route-filter 224.0.1.39/32 exact;
                route-filter 224.0.1.40/32 exact;
                route-filter 224.0.1.60/32 exact;
                route-filter 224.0.2.1/32 exact;
                route-filter 224.0.2.2/32 exact;
                route-filter 224.77.0.0/16 orlonger;
            }
            then reject;
        }
        term ASM-Whitelist {
            from {
                route-filter 224.0.0.0/8 orlonger;
                route-filter 233.0.0.0/8 orlonger;
            }
            then accept;
        }
        term Deny-Everything-Else {
            then reject;
        }
    }
    policy-statement Bogon-Sources {
        term RFC-1918-Addresses {
            from {
                source-address-filter 10.0.0.0/8 orlonger;
                source-address-filter 127.0.0.0/8 orlonger;
                source-address-filter 172.16.0.0/12 orlonger;
                source-address-filter 192.168.0.0/16 orlonger;
            }
            then reject;
        }
    }
}




On Fri, 15 Aug 2008, Pekka Savola wrote:

-) Hi,
-) 
-) We're providing anycast-RP service to universities.  The problem is that 
some
-) universities are sending a lot of junk to our anycast RP, and in some cases
-) this may cause quite a load on the RP routers.  This junk includes:
-) 
-) 1) global source addresses, global but identifiable group addresses (e.g.
-)    norton ghost -like applications)
-) 
-) 2) global source addresses, pretty much random group addresses (e.g. by
-)    various p2p softwares, rtp "broadcast" addresses some voip phones are
-)    using etc.)
-) 
-) 3) private source addresses, group address either in category 1) or 2).
-) 
-) We can drop these at the RP end, but I'm wondering if there is any BCP or
-) just suggestions how the institutions should configure their equipment not 
to
-) spew junk at us.
-) 
-) An "alternative" to this would be to connect sites just using MSDP but this
-) seems pretty heavyweight for most users. (And then they couldn't use Linux 
as
-) a DR because there is no software.)
-) 
-) I guess 1) and 2) could be tackled by blacklisting non-allocated IANA 
address
-) space (but this will impair the use of local apps that do use addresses in
-) that range) in "ip pim rp-address x.x.x.x ACL". 3) seems like a more
-) difficult problem. You can't filter based on source address in rp-address
-) ACLs.  What are the other options?  Drop these in input ACL at the LAN 
border
-) (may impair valid use of intra-campus multicast)?  Some other means?
-) 
-) I'd be interested in hearing experiences how folks have dealt with this (or
-) if they tried, failed, and just scrapped mcast or moved to MSDP).
-) 
-) Pekka Savola
-) 
-)