private ip addresses from ISP

Mailman List Mirror (Read Only)
1

Date: Tue, 23 May 2006 09:36:30 -0400
To: nanog@nanog.org
From: Daniel Senie <dts@senie.com>
Subject: Re: private ip addresses from ISP

> > Date: Tue, 23 May 2006 03:33:34 -0400
> > From: Richard A Steenbergen <ras@e-gerbil.net>
> > To: nanog@nanog.org
> > Subject: Re: private ip addresses from ISP
> >
> >
> > >
> > > > 3) You are seeing packets with source IPs inside private space
> > > > arriving at
> > > > your interface from your ISP?
> > ...
> > > Sorry to dig this up from last week but I have to strongly disagree with
> > > point #3.
> > > >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.
> > >
> > > The ISP shouldn't be "leaving" anything to the end-user, these packets
> > > should be dropped as a matter of course, along with any routing
> > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918 space
> > > into my network piss me off, and get irate phone calls for their
> > > trouble.
> >
> > The section you quoted from RFC1918 specifically addresses routes, not
> > packets.
>
>I quote, from the material cited above:
> " ..., and packets with private source or destination addresses
> should not be forwarded across such links. ... "
>
>There are some types of packets that can legitimately have RFC1918 source
>addresses -- 'TTL exceeded' for example -- that one should legitimately
>allow across network boundaries.

Really? You really want TTL-E messages with RFC1918 source addr? Even
if they're used as part of a denial of service attack? Even though
you can't tell where they actually came from?

"Can be" is not sufficient (in and of itself, that is) reason to block.
_Anything_ "can be" used as part of a DOS attack.

TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space, addressed to 'public
internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'?
Ever use it where packets went across a network using RFC1918 internally?
Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses
network?

If you don't like that example, substitute "host/network unreachable", or
'ICMP redirect'. Or packet-size limit exceeded for a 'DNF' packet. If you
don't get those messages back, you can't communicate.

> > If you're receiving RFC1918 *routes* from anyone, you need to
> > thwack them over the head with a cluebat a couple of times until the cluey
> > filling oozes out. If you're receiving RFC1918 sourced packets, for the
> > most part you really shouldn't care.
>
>*I* care.
>
>When those packets contain 'malicious' content, for example.
>
>When the provider =cannot= tell me which of _their_own_customers_ originated
>that attack, for example. (This provider has inbound source-filtering on
>their Internet 'gateway' routers, but *not* on their customer-facing
>equipment
>(either inbound or outbound.)

So you really don't want ANY packets with RFC 1918 source addresses
then, not even ICMP TTL-E messages, since they could be used in a
malicious fashion, and you would not be able to determine the true origin.

You need to learn to read. I said "malicious content", not 'used in a
malicious fashion'.

Packets that could have legitimate meaning should be passed on.

Packets that _cannot_ have legitimate meaning should not be.

>It's even more comical when the NSP uses RFC1918 space internally, and does
>*not* filter those source addresses from their customers.

You mean like Comcast using Cisco routers in their head-ends and
having the 10/8 address show up in traceroutes and so forth?

not at all. You're either ignorant of network architecture, or trying
to pick fights.

I was talking about a situation where a customer machine of a network
that uses RFC1918 addresses internally starts sending malicious packets
with a RFC1918 source address that _matches_ that of one of the *in*use*
addresses on the service-provider network. AND the service-provider does
not do ingress (from the customer) or egress (to the customer) filtering
of RFC1918 address-space. Customer A's machine starts attacking Customer
B, C, D, E, F ...; those ill-informed customers don't null-route outbound
RFC1918 addresses; you get an 'inadvertent' smurf attack on the NSP resource.
It's comical, because the ISP's 'bad practice' facilitated the attack on
the ISP.

"Traceroute", by the way, *is* one of those 'legitimate' cases for which
RFC1918 source-address packets should be allowed across network boundaries.

Proper "good net neighbor" egress filtering of RFC1918 source addresses
takes a number of separate rules. Several 'allows', followed by a default
'deny'.

                                                             Not sure
to what degree it's the NSP's fault vs. the router vendors', but yes.

Can't imagine why you think it might be the fault of the router vendor.

Can't imagine why think it is somebody's "fault".

> > There are semi-legitimate reasons for
> > packets with those sources addresses to float around the Internet, and
> > they don't hurt anything.
>
>I guess you don't mind paying for transit of packets that _cannot_possibly_
>have any legitimate purpose on your network.

Along with this goes the usual flamewar over RFC 2827, ingress
filtering (of which URPF is a subset implementation).

If everybody did _egress_ filtering of 'cannot possibly be legitimate' traffic,
ingress filtering of that traffic would not be necessary. Unfortunately, not
everybody does, so ingress filtering _is_ necessary.

'ingress' filtering is self-defense.
'egress' filtering is about 'being a good net neighbor'.

2

Robert Bonomi wrote:

TTL-E messages _do_ have legitimate function in network management.
TTL-E messages _can_ originate from RFC1918 space, addressed to 'public
internet' addresses. Usefully, and meaningfully. Ever hear of 'traceroute'?
Ever use it where packets went across a network using RFC1918 internally?
Ever had a route die _between_ two RFC1918 addressed nodes on somebody elses
network?

I guess this means that providers who utilize rfc1918 along their hops should make an effort to ensure these addresses are not used for icmp messages or translate these addresses when they source icmp.

Understandably, translation on providers networks is not always feasible.

A feature on routers that sourced icmp packets to be told specificaly which address of the router to source it from would also help.

3

Proper "good net neighbor" egress filtering of RFC1918 source addresses
takes a number of separate rules. Several 'allows', followed by a

default

'deny'.

Really?
Do you have those rules on your network?
Any reason why you didn't post the operational
details on this operational list?

Have you ever read your peering agreements or
service contracts to see if filtering of RFC 1918
sourced traffic is specifically covered by them?
If it is not covered by the contract, then why should
your peers/upstreams filter it?

Another good question is whether or not every
service contract and peering agreement should
contain unique text or whether there should be
some community-developed best practices statement
that could be plugged in by reference. For instance,
software publishers can publish their software
under the terms of the GPL without including the
full text of the GPL verbatim in their software
license.

Does NANOG have a role in developing some best
practices text that could be easily imcorporated
into peering agreements and service contracts?

--Michael Dillon

4

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
Behalf Of Joe Maimon
Sent: Tuesday, May 23, 2006 10:15 AM
To: Robert Bonomi
Cc: nanog@nanog.org
Subject: Re: private ip addresses from ISP

Robert Bonomi wrote:

>
> TTL-E messages _do_ have legitimate function in network management.
> TTL-E messages _can_ originate from RFC1918 space,
addressed to 'public
> internet' addresses. Usefully, and meaningfully. Ever
hear of 'traceroute'?
> Ever use it where packets went across a network using
RFC1918 internally?
> Ever had a route die _between_ two RFC1918 addressed nodes
on somebody elses
> network?

I guess this means that providers who utilize rfc1918 along
their hops
should make an effort to ensure these addresses are not used for icmp
messages or translate these addresses when they source icmp.

Understandably, translation on providers networks is not
always feasible.

A feature on routers that sourced icmp packets to be told specificaly
which address of the router to source it from would also help.

In the Cisco world, I thought that the source would always be the interface
that replies to the ICMP packet. That seems to be good form to me.

Where am I going wrong?

5

Brian Johnson wrote:

In the Cisco world, I thought that the source would always be the interface
that replies to the ICMP packet. That seems to be good form to me.

Where am I going wrong?

You are correct, however it could be usefull in regards to the topic at hand if this was configurable.

6

Folks are sounding as if they'd never 'traceroute'd THROUGH a set of
unroutable IP addresses. I have seen cases where my 'traceroute' looked
like this [when I've had the patience to not hit Interrupt at the first
sign of stars]:

1 1 ms 1 ms 1 ms router.here
2 10 ms 10 ms 10 ms router.there
3 * * *
4 * * *
5 * * *
6 * * *
7 80 ms 80 ms 80 ms router.over.yonder
8 90 ms 90 ms 90 ms host.over.yonder

It works!

7

...

Does NANOG have a role in developing some best
practices text that could be easily imcorporated
into peering agreements and service contracts?

...

RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38

RFC 3013 == BCP 46

RFC 3704 == BCP 84

Are these followed?

8

Joseph S D Yao wrote:

Folks are sounding as if they'd never 'traceroute'd THROUGH a set of
unroutable IP addresses. I have seen cases where my 'traceroute' looked
like this [when I've had the patience to not hit Interrupt at the first
sign of stars]:

1 1 ms 1 ms 1 ms router.here
2 10 ms 10 ms 10 ms router.there
3 * * *
4 * * *
5 * * *
6 * * *
7 80 ms 80 ms 80 ms router.over.yonder
8 90 ms 90 ms 90 ms host.over.yonder

It works!

Its also quite annoying to wait for each hop to timeout.

9

Robert, to quote your own words: "You're either ignorant of network architecture, or trying to pick fights."

TTL-E messages "can" originate from any IP address. They should not. And allowing packets with RFC1918 source addresses to leave your administrative domain is bad network administration (not to mention going against the RFC). There are no loopholes here, you are being a bad 'Netizen if you pass packets with bogon source addresses to your peers. Period.

If you have issues where you need to send DNF or other messages to peers, it is incumbent upon _you_ to ensure those messages originate with valid source addresses.

It is perfectly acceptable - even good network hygiene - for other networks to drop any packets with bad source addresses at their boarder. You cannot expect them to accept your packets just because you don't know how to architect a network properly. If that breaks traceroute or PMTU-D or anything else, that is your fault, not theirs.

Please read RFC1918 again, as well as BCP38. And perhaps a book on networking.

10

...

Its also quite annoying to wait for each hop to timeout.

Well, yes. ;-} But as someone hinted, that's purely a problem with my
own psyche, which I do [to some degree] control.

OBTW, the 'ad hominem' attacks starting up in this thread should really
be deprecated [speaking of which].

11

> Does NANOG have a role in developing some best
> practices text that could be easily imcorporated
> into peering agreements and service contracts?
...

RFC 2267 -> RFC 2827 == Best Current Practice (BCP) 38
RFC 3013 == BCP 46
RFC 3704 == BCP 84
Are these followed?

No, the IETF BCP's are not followed and part of
the reason is that they are not written by network
operators but often by vendors and academics. The
fact is that the collective of network operations
people (in North America at least) does not have
any agreed set of BEST OPERATIONAL PRACTICES.
There are various camps that promote various sets
of rules which are often overly simplistic and
cannot be 100% adhered to in practice.

What we really need is a forum to discuss best
operational practices and resolve all these various
differences in opinion systematically. The end
result should be a set of best practices that
people really can follow with no exceptions. Of
course this means that the best practices must
incorporate various exceptions to the simple rules
and explain when those exceptions are and are not
appropriate.

So again, I ask the question: Is NANOG an appropriate
forum to develop some best practices text that
could be incorporated into service agreements and
peering agreements by reference in the same way
that a software licence incorporates the GPL
by referring to it?

--Michael Dillon

12

<snip>

So again, I ask the question: Is NANOG an appropriate
forum to develop some best practices text that
could be incorporated into service agreements and
peering agreements by reference in the same way
that a software licence incorporates the GPL
by referring to it?

Ah, I think we all assumed you were kidding when you asked that!

While I think NANOG *should* be the appropriate forum, I don't really think it will be -- there are too many personal agendas -- getting the community to agree on *anything* these days appears to be a losing proposition....

I suspect that a post suggesting we replace IP with a piece of wet spaghetti would:
b: Get n replies disagreeing
c: Possibly generate a post that is trying to be useful.
d: A fish (not a fish anything, just a random posting not related to anything on topic)
e: Spawn a thread screaming "Troll"
f: Get 2n replies asking if that will run on vendor X
g: Get 2n replies suggesting that an alternate root / better SPAM detection / would fix all our woes
h: Generate n^2 ad hominem attack threads.
i: Be sidetracked into a request for a contact for company Y
j: Get misinterpreted [supporting | blasting] someone's pet theory / idea / etc

Even the fairly simple question of whether a network should emit packets with RFC1918 sourced packets (a topic I am declining to comment on) exhibited many of the above. While I think having "some best practices text that could be incorporated into service agreements and peering agreements" would be great I suspect this isn't the forum to generate such a thing -- unless it looks like:

Best Common Practices (please circle appropriate field):

1: Interconnecting networks (agree to always) / (agree to never) / (agree to sometimes) emit packets with RFC1918 addresses
2: Interconnecting networks ( shall) / (shall not ) run some form of RPF
3: Interconnecting networks (will) / (won't) / (might) randomly depeer
...
etc.

Having "some best practices text that could be incorporated into service agreements and peering agreements" would be great -- lets how about setting up a forum for this?

Warren (who is feeling very grumpy and cynical this morning -- and might take all the above back once the coffee sinks in)

13

And this one will invariably start a "trout"/"salmon"/"swordfish"/"octopus"
debate.....

14

Date: Wed, 24 May 2006 15:26:15 -0400
From: Valdis.Kletnieks

d: A fish (not a fish anything, just a random posting not related to
anything on topic)

And this one will invariably start a "trout"/"salmon"/"swordfish"/"octopus"
debate.....

...at which point someone interjects that an octopus is a mollusk...

Eddy