asymmetric routing
Michael Kjorling
michael@kjorling.com
Sun, 27 Jan 2002 15:53:29 +0100 (CET)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Pim, and everyone,
Just a few thoughts on the matter from someone who has most experience
with this from the other end of the issue. (As I am not allowed to
make changes to our router.)
I commonly get traffic coming in to my network that shouldn't belong
on the global Internet in the first place. Packets hitting the
exterior firewall from RFC 1918 IPv4 addresses is commonplace. Aside
from the question whether such traffic should be routed at all or not,
I would just like to say that IMNSHO, it does not belong on the
Internet in any shape or form. Still lots of ISPs (including a very
large ISP in the US - and yet it was indices, not proof, that led me
to this conclusion) route the traffic out on the Net, it is allowed to
clog up the links only to be blocked by my firewall. I have talked to
our ISP but they say it is not possible for some reason to block the
traffic at their border routers. And I am certain that there is some
spoofed traffic being allowed through, too.
The RFCs very clearly spell out that link and site local traffic
should not be forwarded outside its scope (link or site,
respectively), but I have not seen any references to routing traffic
originating from within one's network but having an incorrect source
address. I cannot imagine any legitimate reason to route such traffic,
and a lot of reasons why it should not be routed. Sure, it won't solve
every possible problem, but it makes it a lot easier to track down
from where malicious traffic is originating, and if necessary block
it.
Just my two cents for the moment, and a cheer to you Pim for a good
initiative!
Michael Kjörling
On Jan 27 2002 12:28 +0100, Pim van Pelt wrote:
> Hallo,
>
> I had always suspected it to be the case, but recently I have been monitoring
> the traffic that goes through the TunnelBroker at IPng.nl, and see that
> several of my downstream users are pushing foreign traffic through my
> router in Amsterdam.
>
> I would like to bring this to your attention, because of the following.
> Many people seem to believe that IPv6 is the solution to all current IPv4
> problems, such as spoofing, broadcast and others.
>
> The spoofing aspect, which is demonstrated by the IPng situation, will not
> be properly taken care of unless we (the IPv6 administrators of today) set
> a good example and refuse to route traffic on our borders that does not
> originate within our own networks.
>
> In the example of my tunnelbroker, I am now dropping all the traffic sourced
> from outside of the IPng space, typically 3ffe:8114:2000::/52 and
> 3ffe:8114:1000::/48, trying to traverse the tunnelbroker from downstream
> to upstream.
>
> Is this common practice with tunnelbrokers? Does anybody want to share their
> experience on this matter ? Installing these simple rulesets 'as default'
> should not seem that big a deal with today's routing hardware.
>
> What do the folk from Cisco think about these anti-spoof measures being set
> to enabled state per default (user overridable of course) ?
>
> I for one would like to see my fellow tunnelbroker admins enable these types
> of rulesets on their infrastructure. It will make collecting tunnels
> impossible, a thing that is common on tunnelbroker+irc land, but no longer
> possible at my site.
>
> groet,
> Pim
- --
Michael Kjörling -- Programmer/Network administrator ^..^
Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/
PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e
``And indeed people sometimes speak of man's "bestial" cruelty, but
this is very unfair and insulting to the beasts: a beast can never be
so cruel as a man, so ingeniously, so artistically cruel.''
(Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov')
*** Thinking about sending me spam? Take a close look at
*** http://michael.kjorling.com/spam/ before doing so.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Public key is at http://michael.kjorling.com/contact/pgp.html
iD8DBQE8VBRtKqN7/Ypw4z4RAhB/AKDDddzB+VE/iFpk23D1d6mmS+o6KACg6ucq
rvGwAc/2ixZu5BMtygzAKXg=
=Bj1T
-----END PGP SIGNATURE-----