|
Security Basics
Removing ping/icmp from a network Mar 25 2008 04:29PM Secure This (lists securethis net) (7 replies) Re: Removing ping/icmp from a network Mar 26 2008 02:55PM Jason Thompson (securitux gmail com) (4 replies) Re: Removing ping/icmp from a network Mar 26 2008 07:08PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (2 replies) Re: Removing ping/icmp from a network Mar 27 2008 04:25PM Jason (securitux gmail com) (2 replies) Re: Removing ping/icmp from a network Mar 27 2008 11:29PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) Re: Removing ping/icmp from a network Mar 28 2008 04:34PM Jason (securitux gmail com) (1 replies) Re: Removing ping/icmp from a network Mar 29 2008 07:35PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) Re: Removing ping/icmp from a network Mar 31 2008 10:29PM Jason (securitux gmail com) (1 replies) Re: Removing ping/icmp from a network Apr 04 2008 12:28PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (2 replies) Re: Removing ping/icmp from a network Apr 05 2008 05:17PM Mark Owen (mr markowen gmail com) (1 replies) Re: Removing ping/icmp from a network Apr 05 2008 12:06AM Jason (securitux gmail com) (1 replies) Re: Removing ping/icmp from a network Apr 06 2008 02:54PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) Re: Removing ping/icmp from a network Mar 27 2008 05:09PM Mark Owen (mr markowen gmail com) (2 replies) Re: Removing ping/icmp from a network Mar 27 2008 06:52PM Jason (securitux gmail com) (1 replies) Re: Removing ping/icmp from a network Mar 27 2008 08:49PM Michael Painter (tvhawaii shaka com) (2 replies) Re: Removing ping/icmp from a network Mar 27 2008 11:48PM Razi Shaban (razishaban gmail com) (2 replies) RE: Removing ping/icmp from a network Mar 28 2008 03:07PM Adewale, Akin (IT Services - Infosec Team) (Akin Adewale capita co uk) Re: Removing ping/icmp from a network Mar 28 2008 04:27AM Michael Painter (tvhawaii shaka com) (2 replies) Re: Removing ping/icmp from a network Mar 28 2008 04:44PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) R: Removing ping/icmp from a network Mar 27 2008 06:33PM Vega - Brunello Ivan (I Brunello vegaspa it) Re: Removing ping/icmp from a network Mar 25 2008 05:32PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) Re: Removing ping/icmp from a network Mar 25 2008 05:17PM Jon R. Kibler (Jon Kibler aset com) (1 replies) Re: Removing ping/icmp from a network Mar 26 2008 12:13PM Secure This (lists securethis net) (1 replies) DoD aproved disk wiping tool Mar 27 2008 01:31PM JP Vicente (jvicente asft net) (4 replies) RE: DoD approved disk wiping tool Mar 27 2008 11:38PM Steve Armstrong (stevearmstrong logicallysecure com) (1 replies) RE: DoD aproved disk wiping tool Mar 27 2008 07:50PM Kevin Ortloff (Kevin Ortloff j2global com) (1 replies) Re: DoD aproved disk wiping tool Mar 27 2008 04:56PM John Syers (jsyers acm org) (1 replies) RE: DoD aproved disk wiping tool Mar 27 2008 03:21PM Timmothy Lester (Timmothy Lester primeadvisors com) RE: Removing ping/icmp from a network Mar 25 2008 04:56PM Hopke, Greg (GHopke libertymgt com) (1 replies) Re: Removing ping/icmp from a network Mar 25 2008 06:12PM Mark Owen (mr markowen gmail com) (2 replies) RE: Removing ping/icmp from a network Mar 26 2008 01:58PM Ramsdell, Scott (Scott Ramsdell cellnethunt com) (1 replies) Re: Removing ping/icmp from a network Mar 26 2008 06:44PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) (1 replies) RE: Removing ping/icmp from a network Mar 27 2008 02:19PM Ramsdell, Scott (Scott Ramsdell cellnethunt com) (1 replies) Re: Removing ping/icmp from a network Mar 27 2008 02:34PM Ansgar -59cobalt- Wiechers (bugtraq planetcobalt net) |
|
|
Privacy Statement |
From: "Ansgar -59cobalt- Wiechers"
Sent: Friday, March 28, 2008 6:44 AM
> On 2008-03-27 Michael Painter wrote:
>> I'm not sure what 'clean' means, but I'm not supposed to see 10/8
>> addresses on the "Internet".
>
> You aren't seeing them "on the Internet".
Aloha Ansgar
Poor choice of words, maybe? How about via the Internet?
Anyway, there are (at least) two schools of thought on this, as shown by this thread from NANOG.
http://www.cctec.com/maillists/nanog/historical/0102/threads.html#00702
I've excised a couple, posted below.
--Michael
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(From RFC 1918)
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.
>
> > > > There are good reasons to want to get those packets (traceroutes from
> > > > people who have numbered their networks in rfc1918 networks,
> >
> > No John, there are exactly zero reasons, good or otherwise, for allowing
> > any traffic with RFC-1918 source addresses to traverse any part of the
> > public Internet. Period! :-)
>
> You are being religious, and I shall not descend into this sort of
> discussion with you. It is simply non productive nor professional.
OK, sorry, let me qualify that:
No John, there are exactly zero TECHNICAL reasons, good or otherwise,
for allowing any traffic with RFC-1918 source addresses to traverse any
part of the public Internet. Period! :-)
> I disagree, and believe that other reasonable people do so as well,
> and there is therefore argument over this issue. People should not
> assert canonicity upon it. End of story.
In all of the past discussions on this issue there have never been any
presentations of technical reasons for allowing RFC-1918 addresses (in
either the source *or* destination fields) to traverse the public
Internet. (At least none have been presented while I've been watching,
not anywhere.)
Yes those who have the misunderstanding that they can use such addresses
are going to fail to filter them lest they block their own uses, but
that's circular reasoning, even if it is technically correct within the
microcosms of those people's own minds.
However in public there is no possible valid technical argument, by mere
definition of the way RFC-1918 defines the fact that such addresses are
solely for PRIVATE use, and private use ONLY. Unfortunately RFC-1918 is
not also a STD-* document, but even as it is just a Best Current
Practice, it can only ever really succeed even as a BCP if everyone
co-operates completely, and since people are eager to use PRIVATE
addresses that pretty much forces the rest of you to co-operate since
we're going to filter the heck out of your "mis-uses".
RFC-1918 also clearly suggests that non-unique PRIVATE addresses are
really only useful where external connectivity is not used -- i.e. for
private networks that are never in any way connected to the public
Internet. I.e. use of private addresses on public devices, with or
without filtering at network borders, is still "wrong". One might even
go so far as to argue that use of PRIVATE addresses behind a proper NAT
is similarly "wrong", though of course with a proper NAT you'd never
know! :-)
Note that any part of the Internet which joins any two independently
controlled and operated nodes is, by definition, public. That means
that even an ISP with just direct customers must still never allow
RFC-1918 addresses to appear at either their customer sites, or on their
back-haul(s) to the rest of the Internet. Their customers have just as
much right to make private use of RFC-1918 addresses as does any other
participant on the public Internet. Any use by any ISP of any RFC-1918
addressing violates that right.
The only other technical option is to forget about allocating private
address space, deprecate RFC-1918, and open up the address space to full
and proper routing. Though I do find private address space handy, I
wouldn't mind making all that space publicly available too. So, do we
want RFC-1918 promoted to a full standard, or deleted? You choose.
------------------------------------------------------------
RFC1918 addreses cause real problems. They are not supposed to be used. It
cannot be made much clearer than that. Choosing to ignore the wishes of
the rest of the Internet community in order to make your own life a little
bit easier is not a question of free will, it is a matter of
selfishishness.
Furthermore, if you claim that you have the right to violate spirit and
intent of Internet BCPs then I certainly have the right to complain about
it without being labelled as psycho/paranoid/nazi.
Thanks
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
>
> Source host
> |
> Router (206.126.0.5)
> |
> Router (66.135.224.201)
> |
> :
> :
> |
> Router (63.237.224.30)
> | <-- packet entering Microsoft's network
> Router (207.46.36.249)
> |
> :
> :
> |
> Router (207.46.34.38) <-- Router doing NAT
> | <-- packet entering private network
> Router (10.22.0.26)
> |
> :
> :
> |
> Destination host
>
> Traceroute reports the IP addresses of the "en-route" hosts the packets
> traverse. That may include private IP addresses.
>
> Regards
> Ansgar Wiechers
> --
> "All vulnerabilities deserve a public fear period prior to patches
> becoming available."
> --Jason Coombs on Bugtraq
[ reply ]