That's once again a matter of defaults -- routers should _by default_ discard all packets from interfaces which they won't use for forwarding those packets back.
This is a sweeping statement.
Note that _by default_ implies that there's a way to override it. Now, in practically all LANs and corporate networks paths are symmetrical unless something is misconfigured. Forceful prevention of asymmetrical paths is the Good Thing, then -- that allows to identify problems before something crashes. All single-homed customers of ISPs also have tail-link part of their paths symmetrical; and forced rejection of wrong source addresses brings no harm and allows to prevent a lot of damage caused by malicious attacks or simply misconfigured machines. Backbones use asymmetrical routing a lot, they also have a skilled personnel (well, usually) who would know how to disable the backward-path checks when necessary.
1. Prevention of IP spoofing.
Yes.
2. Prevention of asymmetric routing.
Not. Backbones have to have asymmetry, in general case, if you want to compress routing information.
3. Better TCP windowing and better performance when all packets follow the same path.
Not really. TCP mostly cares about round-trip, not timing of forward and backward paths.
However, are the benefits worth the overhead?
That's not significant, as such filtering is done at tail-link routers, which are not overloaded (generally).
What are the effects on network redundancy?
Does limiting ability to do hard-to-trace denial of service attacks count as improving network redundancy?
What other issues am I overlooking?
Inertia. Even obviously Good Things like doing persistent static routing by default aren't getting deployed, although the current cisco's default of "floating" static routes is the #1 contributor to route flap. Does any major ISP override the default by adding "backup" routes to Null0 in a systematic way? I think not. In the same vein, how many people don't forget to add "no ip proxy-arp" to their interface definitions? I know quite a few who were bitten by forgetting about that default. Or take interfaces being active (and listening!) to routing updates by default, or silly recommendations in manuals, or ... (you continue, the list is nearly endless). The Rules of Safe (and Reliable) Networking are: 1) Disable All Features You Don't Need. 2) Don't Do Any Dynamic Routing Where Only One Path Exists. 3) Do Not Allow Packets To Go To Where They Are Not Supposed To Go To And Come From Where They Aren't Supposed To Come From. (The short form of that maxim is "Filter!".) 4) Don't Accept Suspicious Routes And Watch What You're Announcing. (The short form of that maxim is also "Filter!"). 5) K.I.S.S. 6) Don't Trust Anyone. Unfortunately the feature-happy router vendors do everything to make following those rules very hard by enabling virtually everything by default and so encouraging users to shoot themselves in the feet. I.e. to _disable_ stuff you need to be an expert and know what it does! Most simply don't bother. --vadim
Vadim, ] 2) Don't Do Any Dynamic Routing Where Only One Path Exists. Certainly I would not agree with this rule. If I have a tail router that is down, I do not want to send traffic to him, when he is not there to receive it. Rather, I would want my intermediate router to reject it right off. Furthermore, I do not want to extend nondynamic notification in my network. ------------------------ = ------------------------ Network: rtra --------+-------+ | | rtrb --------+ rtrd +--------- rtre ------- rtrf | | rtrc --------+-------+ ------------------------ = ------------------------ If rtra is down, I do not want rtre to send packets to rtrd to get to rtra, do I? Wouldn't I prefer them to be stopped ASAP? Certainly this is a debatable point. * Another situation is what happens when you renumber networks? What hapens when you've large number of downstream networks? Do you really want static routes in rtrf for all networks attached to rtrs a,b,c,d,e? What I find, is that in running a "large" network, filtered dynamic routing is far preferrable to either static leaf nodes, or unfiltered dynamic routing. I want my dynamic routing to be binary: what I should get, or nothing. -alan
On Jul 11, 20:53, Alan Hannan <alan@gi.net> wrote:
If rtra is down, I do not want rtre to send packets to rtrd to get to rtra, do I? Wouldn't I prefer them to be stopped ASAP?
This makes no difference. For most intents and purposes, one-way traffic doesn't exist. The only thing going down that line will be the odd packet intended to open a conversation -- the volume of this will be minimal compared to normal traffic volumes. And even if you had one-way traffic in volume, it wouldn't exceed normal traffic levels, for which you will already have the capacity. Whenever you do dynamic routing when it isn't necessary, you -will- be emitting unnecessary updates, which nobody is interested in. We have several ASs behind unstable lines behind us, from which we do not propagate routing changes; we set origin AS and announce nailed-up static routes in their AS. Neat, stable, works -- no flap and no global propagation delay when the connection comes back up.
* Another situation is what happens when you renumber networks?
Your router configuration will be changed ... ? :-)
What hapens when you've large number of downstream networks? Do you really want static routes in rtrf for all networks attached to rtrs a,b,c,d,e?
Where you cut dynamic updates off doesn't really matter. The key issue is not to propapgate unnecessary updates. I mean, is it really interesting that a tail circuit in Cargolia went down? Does this event -have- to be announced to the Net? A different issue is that there are many networks with broken configuration. If these people would "do the right thing", and not announce their instability to the Net, we'd be rid of, what?, 90% of all route flap. -- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse@EU.net
From reading this discussion, I think that there are two separate issues being discussed or argued here - specifically internal versus external routing methodologies.
Generally, you should never announce internal instability/reachability problems to the real world. There are some exceptions of course - most notably issues regarding full "SPLITS" of internal networking (you end up with two distinct networks which don't have connectivity to them) - but in most of these cases you're screwed in any case as you've probably got aggreated CIDR blocks split up. As far as your internal routing goes, there's arguments both ways. In my network I have some "customer edge" border routers which are quite frankly incapable of "null0" routing. When they get a packet which is bound for a link which is down they forward it back to their default, which, under static routing, would forward it back to them, and on and on until the TTL is expired. I personsonally use dynamic routing between the braindead router and the more clueful one (cisco) to enable discarding of packets. When the route flaps down, the cisco now uses the null0 path. When it flaps back up, the cisco then starts forwarding packets again. However, the world never needs to see this - it's an internal routing issue and when the internal route flaps it shouldn't affect the external routes. So in summary: 1) Never flap your routes in public. What you do in your own home is your own business. -forrestc@imach.com On Fri, 12 Jul 1996, Per Gregers Bilse wrote:
On Jul 11, 20:53, Alan Hannan <alan@gi.net> wrote:
If rtra is down, I do not want rtre to send packets to rtrd to get to rtra, do I? Wouldn't I prefer them to be stopped ASAP?
This makes no difference. For most intents and purposes, one-way traffic doesn't exist. The only thing going down that line will be the odd packet intended to open a conversation -- the volume of this will be minimal compared to normal traffic volumes. And even if you had one-way traffic in volume, it wouldn't exceed normal traffic levels, for which you will already have the capacity.
Whenever you do dynamic routing when it isn't necessary, you -will- be emitting unnecessary updates, which nobody is interested in. We have several ASs behind unstable lines behind us, from which we do not propagate routing changes; we set origin AS and announce nailed-up static routes in their AS. Neat, stable, works -- no flap and no global propagation delay when the connection comes back up.
* Another situation is what happens when you renumber networks?
Your router configuration will be changed ... ? :-)
What hapens when you've large number of downstream networks? Do you really want static routes in rtrf for all networks attached to rtrs a,b,c,d,e?
Where you cut dynamic updates off doesn't really matter. The key issue is not to propapgate unnecessary updates. I mean, is it really interesting that a tail circuit in Cargolia went down? Does this event -have- to be announced to the Net?
A different issue is that there are many networks with broken configuration. If these people would "do the right thing", and not announce their instability to the Net, we'd be rid of, what?, 90% of all route flap.
-- ------ ___ --- Per G. Bilse, Mgr Network Operations Ctr ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 6233803, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since 1982 --- http://www.EU.net e-mail: bilse@EU.net
3. Better TCP windowing and better performance when all packets follow the same path.
Not really. TCP mostly cares about round-trip, not timing of forward and backward paths.
Really, consider a link where the path carrying most of the data has a time of N and the path carrying the ack has a path 2N or N + 1/2N You are computing an average which seems like it could be skewed based on the path the ack takes. Does anyone know of any papers on the effect of asymetric paths on TCP performance? This is a subject I have been thinking about in my free time :) bjp@eng.umd.edu | Disclaimer: Can you be sure I even uunet!eng.umd.edu!istari | exist: Let alone represent anyone Brad Passwaters (Network Ronin) | or anything. ------------------------------------------------------------------------------- Here we are. Born to be kings. We're the princes of the universe. Here we belong, fighting to survive in a war with the darkest power. Network Manager's Theme Song (QUEEN)
participants (5)
-
Alan Hannan -
avg＠ncube.com -
Bradley J. Passwaters -
Forrest W. Christian -
Per Gregers Bilse