Finding asymmetric path

Joe Greco jgreco at ns.sol.net
Sat Nov 28 17:56:39 UTC 2009


> 
> On Sat, Nov 28, 2009 at 09:41:09AM -0600, Joe Greco wrote:
> [attributions lost]
> > > >>> I'm reasonable certain a customer of ours who is using one of our 
> > > >>> netblocks is using a different reverse path to reach us.  How might I 
> > > >>> figure out who is allowing them to source traffic from IPs that belong 
> > > >>> to us?
> > > >> you are implying that they are not allowed to multi-home using the ip
> > > >> space you have assigned to them.  good way to lose a customer.
> > > > Does it count as multihoming when we are the only ones announcing the
> > > > space?
> > > 
> > > almost an interesting question.  but i think it is playing with words.
> > > if i understand your original statement, they are clearly attached to at
> > > least two providers.
> > > 
> > > perhaps it is fear of what they, possibly mistakenly, perceive to be
> > > your policy regarding announcement of space that keeps them from
> > > announcing normally to both, or more, links?
> 
> It wasn't clear that the customer was a BGP downstream though by saying 
> 'We are the only ones announcing the space', I think not.  Non-BGP 
> multihoming is broken* and when not done out of ignorance generally is
> the smoke pointing to the fire of someone trying to hide something.
> Was very common for spammers to abuse no-uRPF networks in the early
> days of broadband.

This is still rather common for people to do, at least where there's a
significant cost differential.  There are enough networks that can accept
arbitrary traffic that BGP doesn't really play into it at all.

> > It could also be something simple like pricing.  For example, in a large
> > colo facility, you might easily find that a number of providers offer
> > low cost transit, but not IP space.  For a customer who is heavy on the
> > outbound traffic, they might find it more affordable to buy their inbound
> > plus IP space from you, and then dump onto Cogent or something like that
> > for outbound.  Unless your contract specifically prohibits this, you're
> > probably not going to be able to prevent it.
> 
> I wonder if there is a drift of baseline assumptions between the current
> wave of operators and previous ones?  To me (and BCP38) it is beyond bad 
> practice to allow -and if allowed, to make use of- such sloppy edges.  

Of course it is.

> If the other network truly is practicing bad forwarding hygiene then 
> they are a security problem for everyone else and IMO would be good for 
> naming and shaming.

Sure.  But it's easy enough to go to, for example, $BACKBONE_OF_CHOICE
and say "I'm delegated 1.2.3.4/24 from $SMALLISP, I would like you to
accept traffic from that prefix, here's my SWIP'd WHOIS to prove that"
and there are lots of providers for whom that won't be a problem; it is
not the same sort of security problem that a complete lack of filtering
is.  Generally speaking, what's needed is a control over what's being
cast into the network.  

> * for the majority of the cases. I know there are purposeful Non-BGP 
>   MOAS/anycast purposefully run by those who understand the implications.
>   It is unfortunate that their use of lack of inherent BGP path security
>   contribute to fuzzing what would otherwise have been a clear indicator
>   of 'bad' behavior.  But same could be said for the deaggregators 
>   using longest-match to have everyone else do their TE; water under
>   the bridge pushing work onto everyone else. 

:-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.




More information about the NANOG mailing list