[30446] in North American Network Operators' Group
Re: Strange things which should never happen (was Re: RFC 1918)
daemon@ATHENA.MIT.EDU (Josh Richards)
Sun Aug 6 18:53:36 2000
Date: Sun, 6 Aug 2000 15:32:21 -0700
From: Josh Richards <jrichard@cubicle.net>
To: nanog@merit.edu
Message-ID: <20000806153221.A27891@datahaven.freedom.gen.ca.us>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/"
Content-Disposition: inline
In-Reply-To: <4.2.2.20000716121006.032b44e0@ianai.net>; from patrick@ianai.net on Sun, Jul 16, 2000 at 12:19:35PM -0400
Errors-To: owner-nanog-outgoing@merit.edu
--pWyiEgJYm5f9v55/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
* Patrick W. Gilmore <patrick@ianai.net> [20000716 09:06]:
>
> I think Sean is worried about the response to that packet. The host migh=
t=20
> send the reply/ACK/return/whatever packet out the second interface. If t=
he=20
> e1 is addressed with RFC1918 space, and the packet were sourced from an=
=20
> RFC1918 address in another network, the reply would obviously go to the=
=20
> wrong location. If someone knew your internal network well enough, this=
=20
> might even be used as a form of DoS attack.
For example, say the source address of the inbound RFC1918 packet just=20
happened to be the same as your own (the e1 address)...
Actually that may be an answer right there (to the earlier discussion): Fo=
r=20
the same reason it is Good Practice(tm) to filter inbound packets at your=
=20
borders that have source addresses in your IP ranges to prevent outside=20
originated spoofing, if you use *any* RFC1918 space internally you shoulder=
=20
filter RFC1918 space inbound at the border since, effectively, that RFC1918=
=20
space you are using is part of your IP ranges (read: just as exploitable=20
from outside originated spoofing as your global IP blocks).
So those that use RFC1918 addresses internally for inter-mediate routers th=
at=20
argue that other providers should not filter RFC1918 _source_ addressed pac=
kets
should consider that they themselves may be open to spoofing attacks. As l=
ong
as you allow RFC1918 into your _own_ networks, regardless of any other a
anti-spoofing protection you may have in place (i.e. for your global public
IP blocks). If a provider uses RFC1918 addresses internally and practices=
=20
what I've heard some say, allowing RFC1918 source addressed packets into th=
eir=20
AS, that _is_ a provable security hole--it's open to basic IP spoofing just=
as
things were before you had your global IP blocks anti-spoof access-lists in=
=20
place.
Just because you use private IP addresses inside doesn't mean I can't explo=
it
them from the outside.
"I" is *not* meant in a literal sense above. :-)
Also I may be stating the obvious, I don't know. <shrug>
-jr
----
Josh Richards [JTR38/JR539-ARIN]
<jrichard@cubicle.net/fix.net/freedom.gen.ca.us/geekresearch.com>
Geek Research LLC
IP Network Engineering and Consulting
--pWyiEgJYm5f9v55/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjmN51QACgkQ8VgqD3XNPNWSdACfVmSXYdZovkKI7CRtSTgrfDCX
PRAAoNYQHx+Cb1e27UmhR611XZUYo+sy
=scsA
-----END PGP SIGNATURE-----
--pWyiEgJYm5f9v55/--
