Mailing List Archive

While this is technically correct, actually changing the addresses in ICMP
payloads violates my first rule of debugging complex systems:

Diagnostics should be a simple as possible and never be altered by any
non-diagnostic system.

(Which begs the question of should people be using these addresses locally
at all. Which is kind of metaphysical except that it *does* preserve
address space, which is a universal good. Some people do this for security
reasons too, although it's at best only moderately effective security
measure and could produce a false sense of security inside such an
addressing realm.)

I agree that ever having a source or destination IP that's RFC1918 outside
the domain is a very bad thing.

-jcp-


----------
> From: Paul A Vixie <paul@vix.com>
> To: nanog@merit.edu
> Subject: RFC 1918 addresses
> Date: Saturday, May 31, 1997 4:38 PM
>
> I think that any exposure of these addresses outside their addressing
realm
> is a mistake. Using them for otherwise unnumbered serial links would be
fine
> if Cisco had an option to "use loopback address when sending ICMP's" but
they
> don't. Traceroute is sending increasing-TTL'd UDP datagrams, and if you
are
> seeing a 10.0.0.2 source address on an router's ICMP to you it means you
would
> get that as a normal ICMP too -- meaning not just one due to a diagnostic
like
> Traceroute. I think this is an error.
>
> Exposing an RFC 1918 private address in, say, a "Received:" header in
e-mail
> is less of a problem, though the spammers who do it are actually better
able
> to cover their origins, there's no way to prevent it and no normal damage

> from doing it.
>
> No IP datagram with an RFC 1918 address in the protocol headers should be
> allowed outside a private addressing realm. This means not the source
> address, not the destination address, and not the encapsulated addresses
> inside an ICMP payload.

> While this is technically correct, actually changing the addresses in ICMP
> payloads violates my first rule of debugging complex systems:
>
> Diagnostics should be a simple as possible and never be altered by any
> non-diagnostic system.

Except in the case of ICMP's and L3 NAT, I agree with this. Correctness is
also important.

> (Which begs the question of should people be using these addresses locally
> at all. Which is kind of metaphysical except that it *does* preserve
> address space, which is a universal good. Some people do this for security
> reasons too, although it's at best only moderately effective security
> measure and could produce a false sense of security inside such an
> addressing realm.)

RFC 1597 was a great thing. RFC 1918's language wasn't as strong as I would
have liked (that is, I liked 1597's applicability statement better) but it
names the same nets and thus I approve heartily of it. Private networks are
a good thing. But they have to be private, and as shown by the ICMP examples
as well as the PMTUD reference earlier in this thread, transit links are not
private. So, use private addresses for leaf nets (even multiply homed ones
if you can find a NAT solution that will do that for you), not transit nets
like ISP T1's.

> I agree that ever having a source or destination IP that's RFC1918 outside
> the domain is a very bad thing.

I don't see anyone here disagreeing with that, but apparently a number of
ISP's did not consider the ICMP case when they gave numbers to their T1's,
and so it's a question of definition rather than of intent. Transit nets
are public, not private, and so they have to have public, not private,
addresses.

Yikes. A technical discussion on NANOG. What's the world coming to?

> Exposing an RFC 1918 private address in, say, a "Received:" header in
e-mail
> is less of a problem, though the spammers who do it are actually better
able
> to cover their origins, there's no way to prevent it and no normal damage

> from doing it.

Unless the SMTP server used to proxy email through a firewall is able to
strip headers, it's unavoidable.
I would like to see that feature added to SMTP servers, however, I do hate
letting internal host names and addresses out.

Matt

I believe a number of firewall packages and a few anonymous remailers
(sendmail based) support header stripping. I know for a fact spammer
software does it.

-Deepak.

On Sat, 31 May 1997, Matthew James Gering wrote:

>
> > Exposing an RFC 1918 private address in, say, a "Received:" header in
> e-mail
> > is less of a problem, though the spammers who do it are actually better
> able
> > to cover their origins, there's no way to prevent it and no normal damage
>
> > from doing it.
>
> Unless the SMTP server used to proxy email through a firewall is able to
> strip headers, it's unavoidable.
> I would like to see that feature added to SMTP servers, however, I do hate
> letting internal host names and addresses out.
>
> Matt
>

Paul,

>> I agree that ever having a source or destination IP that's RFC1918 outside
>> the domain is a very bad thing.

>I don't see anyone here disagreeing with that, but apparently a number of
>ISP's did not consider the ICMP case when they gave numbers to their T1's,
>and so it's a question of definition rather than of intent. Transit nets
>are public, not private, and so they have to have public, not private,
>addresses.

I want to respectfully disagree. I do run internal routing protocols
that can't handle VLSM or CIDRization permitting cutting up a class C
into 64 disconnected pieces. , igrp in particular. Because of this I
would burn too many network numbers by having to use public network
numbers for all my T1's. I never permit a case where both sides of a
router have RFC1918 address space so there is no confusion in a
traceroute at to where to address questions about routing issues.
Purity of addresses is valuable but I am willing to compromise on this
in this instance.

Walt