router worms and International Infrastructure

Pekka Savola pekkas at netcore.fi
Thu Sep 22 17:58:36 UTC 2005


On Thu, 22 Sep 2005, Christopher L. Morrow wrote:
>>
>> Not quite (feasible path check is different from loose RPF) -- I
>> didn't understand the documentation myself at first we had to open a
>> case to get this cleared :-(.  I was not sure of your example, but I
>> think what you're saying..
>>
>> Let me try to clarify.
>>
>> Let's assume you have a router with one interface to the customer with
>> 1.1.1.0/24 and 10.1.1.0/30 on that link.  If you enable strict uRPF
>> towards the customer, only packets coming from 1.1.1.0/24 or
>> 10.1.1.0/30 are accepted (except if you have a more specific route).
>>
>> Now, let's consider you have the second interface to the customer
>> (let's say on the same router, for simplicity) which has the same
>> 1.1.1.0/24 but different 10.1.2.0/30.  With simple strict uRPF, only
>> one of the interfaces is active at the time.  If the traffic is
>> asymmetric, packets will get dropped coming from the wrong customer's
>> interface.
>>
>> Feasible RPF (or possibly manual tuning of route preferences to affect
>> strict RPF) helps here.  It allows packets from 1.1.1.0/24 from both
>> interfaces no matter which one is active at the moment.  So, you could
>> consider feasible path RPF to be "strict RPF++".
>>
>> The customer cannot send packets (on either interface) from any source
>> address other than 1.1.1.0/24, 10.1.1.0/30, and 10.1.2.0/30 -- even if
>> you have a route to one of these networks pointing somewhere else.
>
> Meaning the customer also has 23.23.23.0/24 which they have routed into
> your network on some other router on your network, that traffic isn't
> accepted on the 2 links above... which is much more like 'strict' mode.

No, I just described here the simple case.  The feasible path strict 
uRPF works if the customer connects to two routers as well.  It's just 
required that all the prefixes are routed towards the customer's each 
interface (even if the routes would not be active).  In the case of 
BGP, it requires that the customer advertises all the prefixes on each 
link, and that's it.

What *isn't* supported, however, that forwards traffic to the ISP on a 
link without proper advertisements (when using BGP or a routing 
protocol) on *all* links.

As said, the preferences can be adjusted in any suitable manner (this 
is different from plain strict uRPF), but the consistent advertisement 
must be there.

>>> Also, consider the cases where customers push packets your way (for uRPF
>>> strict,  which isn't available for JunOS, but is for IOS depending on
>>> platform/code/hardware-rev... ugh!)
>>
>> Uhh? uRPF strict is definitely availabe for JunOS.. we've used it for
>> 3-4 years towards all the customers..
>
> the documentation again is probably lacking :( it doesn't mention strict,
> just 'active' and 'feasible'.

The configuration is done at two different places: under the 
forwarding options, you configure whether you want "plain" or 
"feasible".  Under interfaces where you activate uRPF, you configure 
strict (the default) or loose.

>>> and never send you a route for the
>>> traffic back to them? Maybe they are just a transit and don't even hear
>>> the routes for their customer who chose a 'cheaper' path that doesn't
>>> include them nor me directly on this link in question?
>>
>> For uRPF to work, you have to have a route toward the interface.
>> With feasible path strict uRPF, the route doesn't need to be active
>> (e.g., it can be prepended so that it's never used).
>
> often it's never sent on this link at all, I don't pretend to understand
> why a customer would do this, they just do.

Yeah, this is one of the things that cannot be fixed other than by 
educating the user.  For example, smuggle it in the contract, and when 
the packets get dropped, explain the situation ;-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



More information about the NANOG mailing list