[23788] in North American Network Operators' Group
Re: address spoofing
daemon@ATHENA.MIT.EDU (Andrew Brown)
Fri Apr 23 17:39:56 1999
Date: Fri, 23 Apr 1999 17:38:23 -0400
From: Andrew Brown <twofsonet@graffiti.com>
To: "Forrest W. Christian" <forrestc@iMach.com>
Cc: Daniel Senie <dts@senie.com>, nanog@merit.edu
Reply-To: Andrew Brown <atatat@atatdot.net>
In-Reply-To: <Pine.BSF.3.96.990423150607.19583G-100000@workhorse.iMach.com>; from Forrest W. Christian on Fri, Apr 23, 1999 at 03:17:09PM -0600
Errors-To: owner-nanog-outgoing@merit.edu
>First of all, everyone seems to think that this paragraph:
>
>> "Because private addresses have no global meaning, routing information
>> about private networks shall not be propagated on inter-enterprise
>> links, and packets with private source or destination addresses should
>> not be forwarded across such links. Routers in networks not using
>> private address space, especially those of Internet service providers,
>> are expected to be configured to reject (filter out) routing information
>> about private networks. If such a router receives such Information the
>> rejection shall not be treated as a routing protocol error."
>
>means that packets with source addresses from RFC 1918 space should not be
>permitted on the global internet. While I agree that RFC 1918 addresses
>should not be used on internet visible interfaces, I'm unaware of anywhere
>in the RFC's where it says that "routers should be configured to reject
>packets coming from RFC 1918 space." In fact, I can think of several
>things which this will likely break, such as MTU path discovery. Note
>that "routing information" is NOT the same as "packets from RFC1918
>space".
well...there is that part about
...packets with private source or destination addresses should not be
forwarded across such links.
that sort of clears it up for me.
>Also, I've seen several people filtering stuff on borders such as:
>
> deny tcp any any eq 2049
> (and several other >1024 port numbers)
>
>Remember, on machines where nothing is bound to 2049, 2049 is a perfectly
>acceptable port to use for ANY type of TCP connection. Only ports below
>1024 are reserved. If you happen to have a filter on say port 2049
>between you and the destination and your TCP implementation gives you 2049
>for a given TCP connection, the connection will fail.
...which was a mistake anyway. whoever it was that was developing nfs
decided to hardcode 2049 so that (a) it could be done as a regular
user and (b) it could be done even without portmapper support (even
though it was rpc based). it *should* have been moved to a reserved
or well-known port before official release, but it was not.
--
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org * "ah! i see you have the internet
twofsonet@graffiti.com (Andrew Brown) that goes *ping*!"
andrew@crossbar.com * "information is power -- share the wealth."
