[j-nsp] JUNOS Vulnerability

[Richard A Steenbergen]

On Thu, Jan 27, 2005 at 07:56:16AM +0100, Josef Buchsteiner wrote:
> Eric,
> 
>      in  the  past  rpd  may  have  asserted  once  you have defined a
>      community  but  no members are configured and therefor this check
>      was added. What Is the purpose to have communities defined without
>      members ?

Actually there are very valid uses for a community name (or any other 
policy object) defined without members, namely automation and 
standardizationn.

For example, lets say that I have standardized the roughly 70% of my 
config that is common across all routers, broken them up into groups for 
easy management, and have a simple junoscript based system for pushing out 
new code so that it is easy to manage changes across all routers.

Now, lets say that because of Juniper's oh-so-quirky way to get routes 
into BGP (namely policy statements injecting the routes in from another 
protocol on every export policy), I have a set of policies which handle 
redistribution and origination into BGP, setting communities on those 
routes which I need to announce globally. These policies can then be 
easily called (or not called) in an export policy chain.

Now, as we've learned previously, because of the oh-so-quirky lack of a 
bgp origination command, the only sure fire way to be able to get both 
static hold-down routes and directly connected interface routs into BGP is 
with a policy statement matching with route-filter, or better yet 
prefix-list. So consider that you now have a set of policies which are 
common to every router containing well-known standardized code, and one of 
the very few things that now needs to go into the router-specific policy 
section is the list of specific routes you need to originate, which is 
referenced by the standarized code through a prefix-list. Sounds very 
clean and efficient right?

policy-options {    
    apply-groups [ base-policy ... ];
    prefix-list bgp-originate {
        12.34.0.0/19;
    }
}

12.34.0.0/19 could be a static route with a hold-down to null0, it could 
be nailed to an interface as 12.34.0.1/19, etc. If you need to make this 
router originate a new route globally, you just stick it in this 
prefix-list (and make sure it exists somewhere of course :P) and you're in 
business.

UNLESS you happen to have a router that doesnt need to originate anything 
into bgp.

# set policy-options prefix-list bgp-originate

show:

    prefix-list bgp-originate;

But:

  'policy-options'
    Policy error: bgp-originate prefix-list referenced (in term originate) 
but not defined

So, what is the purpose of a prefix-list defined without any prefixes in 
it? So that you can standardize the config and later put prefixes in it 
easily if you need to. The exact same logic can apply to BGP communities. 
Actually BGP communities are even worse, because at least in the above 
example you can stick in a prefix that doesn't have a route like 
1.2.3.0/24, and still make the configuration commit. You probably don't 
want to be sticking random junk in your communities just to work around a 
silly config parser that makes invalid assumptions.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)