Quick BGP peering question
-----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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFm6S6R+KszLBLUT8RAm1zAJ0Tvm7yaw/3tMrYWbsbEVZTxgSYpACfWuZ8 bdI+Wum4MI+2MkwA6R0clxQ= =I/xW -----END PGP SIGNATURE-----
are you advertising them routes? If so then why wouldn't you expect traffic?
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of James Blessing Sent: 03 January 2007 12:43 To: nanog Subject: Quick BGP peering question
-----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/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFm6S6R+KszLBLUT8RAm1zAJ0Tvm7yaw/3tMrYWbsbEVZTxgSYpACfWuZ8 bdI+Wum4MI+2MkwA6R0clxQ= =I/xW -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Neil J. McRae wrote:
are you advertising them routes? If so then why wouldn't you expect traffic?
-----Original Message----- 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 http://www.enta.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFm7FaR+KszLBLUT8RAiD3AJ4u8/MIL3tuaJc2ZLZLJ9EsiKgROACcC9J9 L91GI1SQ4nYDwGhuxDuJBxA= =4C4p -----END PGP SIGNATURE-----
On Wed, 3 Jan 2007, James Blessing wrote: > 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) Is there some reason a filter wouldn't work? -Bill
On Wed, Jan 03, 2007 at 01:36:26PM +0000, James Blessing wrote:
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)
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
On Wed, Jan 03, 2007 at 12:42:34PM +0000, James Blessing wrote:
Very simply : Would you accept traffic from a customer who insists on sending 0 prefixes across a BGP session?
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
On Wed, 3 Jan 2007, James Blessing wrote: > Very simply : Would you accept traffic from a customer who insists on sending 0 > prefixes across a BGP session? Does that somehow make their money not [green,colorful,whatever]? -Bill
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
participants (5)
-
Bill Woodcock -
Jack Bates -
James Blessing -
Jeff Aitken -
Neil J. McRae