> > 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.
