RE: Where is the edge of the Internet? Re: no ip forged-source-address
One of my clients is currently a victim of an over-zealous ISP recklessly trying to implement rpf. One (of two) ISPs are trying to monitor my customer's circuit by watching the serial interface (IP address) of the cpe (customer owned and controlled) router (IP address is from ISP's block). Due to the fact that this customer has a T1 to one ISP and a DS-3 to another ISP, the return path of this monitoring traffic is sent via the 2nd ISP's link. This 2nd ISP (DS-3) is dropping the packets because they are being sourced from the serial interface (IP address of 1st ISP). Advertised routes != valid source addresses.... is this not obvious? I can think of MANY examples of different sets of prefixes being advertised across different links, while the routing decision for outbound packets does not consider what routes are being advertised. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of alok Sent: Thursday, November 07, 2002 3:00 PM To: Majdi S. Abbas; nanog@merit.edu Subject: Re: Where is the edge of the Internet? Re: no ip forged-source-address On Fri, Nov 08, 2002 at 01:01:33AM +0530, alok wrote:
there was a comment from chris saying..."never possible to knw what networks an bgp customer uplinks via you" which is very true.. ..so i assume u mean non-bgp customers? loose or strict, rpf will not work for aasymterically connected bgp neighbouring AS....
How does loose not work in this scenario? If it's not in the global tables -at all-, it's not reachable, and might as well be discarded. ------> the scenario is this... a BGP customer uplinks network a.b.c.d via me, but advertises it via some place else (some other network he peers with) and some other bgp peer/router to bring that traffic back into his AS... this can also happen mainly due to BGP metrics blah blah.... now, essentially a.b.c.d can be anything...and he need not tell me what he uplinks from me, all he tells me are the networks he downlinks via me so as to tell me what routemaps to put with acls for bgp advertisements from him...... infact people tend to use this very often (also a way of providing link failure etc by multihoming) ..and they have the choice to uplink anything from anywhere and downlink it from another location...they certainly dont need to tell you what they uplink..as far as i know... now the point is that if you use loose rfp here.... what are u filtering on? you dont even know what he is uplinking to you... i assume the subject is still DDoS attacks...using spoofed ips... now when u dont know what he is uplinking from ur networks, how do u even know what to block? if u say "loose" simply means check if the entry for the network is there in the routing table..then the entire internet is there in the routing table...(thanks to bgp)....so it certainly work on bgp based "edges" the other point u made about not reachable...well not reachaable from where? from a ospf running node which uses 0.0.0.0 ? a lot of ones own networks etc may not be reachable from there i guess...as they are covered in default routes... for a bgp running router...all valid internet addresses are "reachable" , for an ospf router....all is reachable either via 0.0.0.0, and if u remove default any, it doesnt even know what the customer networks are.....so a lot "isnt" reachable.... i think as was rightly defined...the edge is the place where the end user/host gets onto the net...
One of my clients is currently a victim of an over-zealous ISP recklessly trying to implement rpf.
Assuming the provider is doing the right thing by filtering routing announcements, and assuming the customer has done the right thing by informing their provider of the blocks they _might_ announce (either via irr or email, depending on provider) it appears the provider is _not_ doing the right thing by adding exceptions to rpf to make it semi-strict based upon this data. With this sort of setup, it wouldn't matter if the customer actually was announcing the routes or not. Anything, when used incorrectly can have bad impact. The various implementations of RPF that I've seen allow for these situations, they can't however hold the provider or customer's hand.
participants (2)
-
bdragon@gweep.net
-
H. Michael Smith, Jr.