-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Very simply : Would you accept traffic from a customer who insists on sending 0
prefixes across a BGP session?
J
- --
COO
Entanet International
T: 0870 770 9580
http://www.enta.net/
are you advertising them routes?
If so then why wouldn't you expect traffic?
As long as I knew the src ip blocks used by the customer and could
craft an appropriate ingress filter, sure. I'm guessing that your
customer simply wants to send outbound bits without attracting any
return traffic, which is perfectly acceptable as long as he can't
source packets from IP space he don't have the right to use.
--Jeff
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Neil J. McRae wrote:
are you advertising them routes?
If so then why wouldn't you expect traffic?
Very simply : Would you accept traffic from a customer who insists on
sending 0
prefixes across a BGP session?
Expecting the traffic is not a problem, just want some way of verifying that the
traffic isn't malicious/spoofed (e.g. by using unicast RPF or similar)
- --
COO
Entanet International
T: 0870 770 9580
Does that somehow make their money not [green,colorful,whatever]?
-Bill
Is there some reason a filter wouldn't work?
-Bill
Whether or not the customer plans on advertising prefixes via BGP,
your standard contract/AUP should contain a provision that:
(a) requires that the customer provide a list of IP blocks from which
traffic may be sourced, and
(b) allows you to drop any packets with a source IP not in the list.
The mechanism you use to keep track of this info (post-it notes,
email, automated route-registry system, etc.) may be subject to
negotiation, but the underlying requirement should not be.
Ideally, you'd keep all this in a database and auto-generate BOTH
prefix filters (for the BGP session) AND packet filters (for the
interface) every time the customer registered a new route.
--Jeff
James Blessing wrote:
Very simply : Would you accept traffic from a customer who insists on sending 0
prefixes across a BGP session?
I just ran through a related issue with one of my upstream peers. It appears that they have a RPF strictly enforced policy, yet during the process of renumbering a customer of a customer from another ISPs space, they were wanting to throw all traffic (our IPs and the other provider's) out to us.
It comes down to a simple question of policy, and if you are going to mandate how your customers route proper, valid traffic. I about pulled the plug in my situation, but finally got it sorted out. Thank goodness some routers can allow exceptions to RPF and other providers just use ACLs instead.
0 prefixes is no different than partial prefixes. Asymmetric routing should not be a crime on the Internet because "I don't like it" or "but basic RPF is easier and you're doing something funky anyways".
Jack Bates