private ip addresses from ISP

> -----Original Message-----
> From: owner-nanogmerit.edu [mailto:owner-nanogmerit.edu] On Behalf
Of
> David Schwartz
> Sent: Wednesday, May 17, 2006 1:37 PM
> To: nanognanog.org
> Subject: RE: private ip addresses from ISP
> 
> 
> 
> > Our router is running BGP and connecting to our
> > upstream provider with /30 network.   Our log
reveals
> > that there are private IP addresses reaching our
> > router's interface that is facing our upstream
ISP.
> > How could this be possible?  Should upstream ISP
be
> > blocking private IP address according to standard
> > configuration?  Could the packet be stripped and
IP be
> > converted somehow during the transition? It
happens in
> > many Tier-1 ISP though !
> >
> > Thank you for your information
> 
> 	Do you mean:
> 
> 	1) You are seeing BGP routes for addresses inside
private space?
> 
> 	2) You are seeing packets with destination IPs inside
private
space
> arriving at your interface from your ISP?
> 
> 	3) You are seeing packets with source IPs inside
private space
> arriving at
> your interface from your ISP?
> 
> 	If 1, feel free to filter them. You ISP probably uses
them
> internally and
> is leaking them to you. Feel free to complain if you
want.
> 
> 	If 2, make sure you aren't advertising routes into
RFC1918 space
to
> your
> ISP. If not, you should definitely ask them what's up.
> 
> 	If 3, that's normal. These are packets your ISP
received that
are
> addressed
> to you and the ISP is leaving to you the decision of
whether to accept
> them
> or not. Feel free to filter them out if you wish. (It
won't break
anything
> that's not already broken.)
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.

Andrew

In reality, from what I see, most large ISP doesn't care
about RFC1918.
I've been dealing with this issue for a while.
Not all of them, because I didn't deal with all of them.
But some of them has strange policy for ACL, because it has
large impact 
on router platform CPU utilization.
Strictly some ISP doesn't allow to put ACL for more than 24
hours 
including RFC1918 ip address space originated traffic.
So I'm doing it from our core router to block those
traffic, and fun to 
watch the counters increasing so rapidly. ^.^

For an example,
hryuchc-core-r1> show firewall filter XXX-in
Filter: XXX-in
Counters:
Name                                                Bytes 
Packets
XXX-in-default                      430738360735883        
743436641099
XXX-in-rfc1918-10                       12742937908         
   41900221
XXX-in-loopback                           785367140         
    2678266
XXX-in-dhcp-default                        36982506         
     413978
XXX-in-rfc1918-172-16                    1240646548         
   13026411
XXX-in-test-net                               44318         
        621
XXX-in-rfc1918-192-168                   1806857741         
   17309861
XXX-in-reserved-e-class                           0         
          0
ospf-deny                                           14135 
     35
h323                                              8785570 
186042
XXX-in-microsoft                       305199975828         
 5751955784
ms-exclude                                      424428929 
696688
on-fire                                      173190029170 
5970455314


I'm wondering whether this is really about router platform
issue, and 
they want their customer including smaller ISPs to bill more
because of 
these junk traffic.

Hyun



Andrew Kirch wrote:
> 
>> -----Original Message-----
>> From: owner-nanogmerit.edu
[mailto:owner-nanogmerit.edu] On Behalf
> Of
>> David Schwartz
>> Sent: Wednesday, May 17, 2006 1:37 PM
>> To: nanognanog.org
>> Subject: RE: private ip addresses from ISP
>>
>>
>>
>>> Our router is running BGP and connecting to our
>>> upstream provider with /30 network.   Our log
reveals
>>> that there are private IP addresses reaching
our
>>> router's interface that is facing our upstream
ISP.
>>> How could this be possible?  Should upstream
ISP be
>>> blocking private IP address according to
standard
>>> configuration?  Could the packet be stripped
and IP be
>>> converted somehow during the transition? It
happens in
>>> many Tier-1 ISP though !
>>>
>>> Thank you for your information
>> 	Do you mean:
>>
>> 	1) You are seeing BGP routes for addresses inside
private space?
>>
>> 	2) You are seeing packets with destination IPs
inside private
> space
>> arriving at your interface from your ISP?
>>
>> 	3) You are seeing packets with source IPs inside
private space
>> arriving at
>> your interface from your ISP?
>>
>> 	If 1, feel free to filter them. You ISP probably
uses them
>> internally and
>> is leaking them to you. Feel free to complain if
you want.
>>
>> 	If 2, make sure you aren't advertising routes
into RFC1918 space
> to
>> your
>> ISP. If not, you should definitely ask them what's
up.
>>
>> 	If 3, that's normal. These are packets your ISP
received that
> are
>> addressed
>> to you and the ISP is leaving to you the decision
of whether to accept
>> them
>> or not. Feel free to filter them out if you wish.
(It won't break
> anything
>> that's not already broken.)
> 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.
> 
> Andrew
> 
> 
> 

On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew Kirch
wrote:
> 
> > 	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. 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. There are
semi-legitimate reasons for 
packets with those sources addresses to float around the
Internet, and 
they don't hurt anything. If you really can't stand seeing
an RFC1918 
sourced packet over the Internet it is more of a personality
problem than 
a networking problem, so a good shrink is probably going to
be more useful 
than a good firewall.

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)

RAS> Date: Tue, 23 May 2006 03:33:34 -0400
RAS> From: Richard A Steenbergen

RAS> If you're receiving RFC1918 sourced packets

#include "flamewars/urpf.h"
#include "flamewars/pmtud.h"


Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network
building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
____________________________________________________________
____________
DO NOT send mail to the following addresses:
davidcbrics.com -*- jfconmaapaqintc.net -*- sameverquick.net
Sending mail to spambait addresses is a great way to get
blocked.
Ditto for broken OOO autoresponders and foolish AV software
backscatter.

On May 23, 2006, at 3:33 AM, Richard A Steenbergen wrote:

>>> 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 know it was late when you wrote that, RAS, but from the  
_very_first_sentence_:

>> and packets with private source or destination
addresses
>>    should not be forwarded across such links


> 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. There are
semi-legitimate  
> reasons for
> packets with those sources addresses to float around
the Internet, and
> they don't hurt anything. If you really can't stand
seeing an RFC1918
> sourced packet over the Internet it is more of a
personality  
> problem than
> a networking problem, so a good shrink is probably
going to be more  
> useful
> than a good firewall.

Incorrect.  Not to mention Just Plain Wrong.

Please read BCP38 again.  (For the first time? 

-- 
TTFN,
patrick

On Tue, May 23, 2006 at 12:23:54PM -0400, Patrick W. Gilmore
wrote:
> 
> I know it was late when you wrote that, RAS, but from
the  
> _very_first_sentence_:

Er yeah I meant to say it says nothing about filtering 1918
packets. 

> Please read BCP38 again.  (For the first time? 

Clearly allowing anyone to inject large quantities of
spoofed packets into 
the Internet is Bad (tm), no one is arguing that. First of
all note that I 
was talking about how you deal with packets you receive, not
packets you 
send. Hate to bust out the old "be conservative in
what you send and 
liberal in what you receive" line, but in this case it
is true. There are 
legitimate uses for RFC1918 sourced packets (as has been
pointed out many 
times, for example, ICMP responses from people who want/need
their routers 
to not source packets from publicly routed space).

Filtering every last 1918 sourced packet you receive because
it might have 
a DoS is like filtering all ICMP because people can ping
flood. If you 
want to rate limit it, that is reasonable. If you want to
restrict it to 
ICMP responses only, that is also reasonable. If on the
other hand you are 
determined to filter every 1918 sourced packets between AS
boundries 
(including ttl exceed, mtu exceed, and dest unreachable)
because an RFC 
told you you "should", you are actually doing
your customers a disservice.

If you are an end-user network or don't transit other
people's packets and 
you want to do yourself a disservice then by all means
filter 1918 sourced 
packets until you are blue in the face. If on the other hand
you do handle 
other people's packets, I would encourage you to fully
consider the 
ramifications before you go out and apply those filters.
This is why k00ks 
who can only cite RFC's instead of think for themselves and
large networks 
tend to be a bad mix. 

-- 
Richard A Steenbergen <rase-gerbil.net>       http://www.e-gerbil.net/r
as
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41
5ECA F8B1 2CBC)

On May 23, 2006, at 1:14 PM, Richard A Steenbergen wrote:

[...]

> Filtering every last 1918 sourced packet you receive
because it  
> might have
> a DoS is like filtering all ICMP because people can
ping flood. If you
> want to rate limit it, that is reasonable. If you want
to restrict  
> it to
> ICMP responses only, that is also reasonable. If on the
other hand  
> you are
> determined to filter every 1918 sourced packets between
AS boundries
> (including ttl exceed, mtu exceed, and dest
unreachable) because an  
> RFC
> told you you "should", you are actually
doing your customers a  
> disservice.
>
> If you are an end-user network or don't transit other
people's  
> packets and
> you want to do yourself a disservice then by all means
filter 1918  
> sourced
> packets until you are blue in the face. If on the other
hand you do  
> handle
> other people's packets, I would encourage you to fully
consider the
> ramifications before you go out and apply those
filters. This is  
> why k00ks
> who can only cite RFC's instead of think for
themselves and large  
> networks
> tend to be a bad mix. 

No one is arguing that you should ruin your business because
an RFC  
told you to.  (At least no one reasonable.)  However, in
your first  
post you said:

> If you're receiving RFC1918 sourced packets, for the
> most part you really shouldn't care. There are
semi-legitimate  
> reasons for
> packets with those sources addresses to float around
the Internet, and
> they don't hurt anything.

I disagree.  As do many people.  You -should- care when
people do bad  
things.  And passing bogon-source packets between ASes is a
Bad Thing.

You suggest thwacking people "over the head with a
cluebat" when they  
send you 1918 prefixes.  Is that really a problem?  It's
easy to  
filter (as everyone should be doing already), and doesn't
really  
'break' anything.  So why the vehemence?  Because it is a
Bad Thing.   
And the Internet doesn't work if everyone does Bad Things. 
As a  
result, you get upset when people do Bad Things.

But, as you point out, sometimes customers are stupid.  So
sometimes  
you have to do things that upset you.  You get paid for
connectivity,  
and customers don't understand why certain actions hurt the
Internet.

For instance, I get pissed when someone sends 256 /24s
instead of  
one /16.  But that doesn't mean I suggest filtering all 256
/24s.   
Customers would get pissed if they can't reach their fav
pr0n server  
in that /16.  Similarly, if someone sends you 1918-sourced
packets,  
you may have to accept them to keep your customers happy. 
But you  
should care.  And you should be upset.

Telling people they need to see a shrink for trying to keep
the 'Net  
clean is not the correct response.

-- 
TTFN,
patrick

> Filtering every last 1918 sourced packet you receive
because it might have 
> a DoS is like filtering all ICMP because people can
ping flood. If you 
> want to rate limit it, that is reasonable. If you want
to restrict it to 
> ICMP responses only, that is also reasonable. If on the
other hand you are 
> determined to filter every 1918 sourced packets between
AS boundries 
> (including ttl exceed, mtu exceed, and dest
unreachable) because an RFC 
> told you you "should", you are actually
doing your customers a disservice.

Well, some of us happen to disagree. I have been very happy
to see that
both at my previous and at my present employer (large SPs by
Norwegian
standards), all 1918 traffic is filtered at the borders. We
have never
had any trouble from customers because of this, and we
certainly intend
to keep the filters. And yes, we have had these filters in
place for
several years...

Steinar Haug, Nethelp consulting, sthaugnethelp.no