Re: IP backbone numbering/naming

2002-11-16 Thread Jahowering
The DOS attack should be a real concern when using RFC 1918. A (distributed) smurf attack, or one of it's derivatives, can cause the icmp echo replies to be sent to that src. address. Since the attackers just use blocks and blocks of spoofed addresses, you could become the sourced address victim. Of course, ingress and egress rfc 1918 filtering will prevent this...it's just something else to think about...

-jake

In a message dated 11/16/2002 12:19:36 AM Eastern Standard Time, [EMAIL PROTECTED] writes:

[EMAIL PROTECTED] wrote:

You could also use RFC1918 numbers for your point-to-point /30 
aggregation blocks with the customers.. But.. since that would have 
effect on customer's premise equipment, it would be better to give 
them globally unique space as well, who knows if your customer comes 
back and yells at you for not being able to get to his router's serial 
interface IP.


This practice was implemented here in the early days, before I came 
along. There have been almost no requests to change by clients, and 
very, very few who even noticed/cared enough to ask why.

But as more VPNs are deployed, I've seen this break some 
implementations. So for two reasons we've begun the (large) task of 
renumbering all the /30 ptp links either public or unnumbered:

1) Ensures all clients who decide to implement VPN don't run into 
frustration because of this practice. We want to encourage better 
security practices, and VPN can be an integral part of that.

2) The script kiddies won't mistakenly assume that we're not doing 
source address filtering. I'm sure that seeing a private address in 
traceroute probably makes you a more desirable target in certain circles.

There is only one case where I would recommend using a private address 
on a public link. We have a client periodically attacked, and in some 
cases the attackers have simultaneously attacked our own infrastructure. 
They now have only one path to them here, and every hop past the border 
is RFC1918.




Re: IP backbone numbering/naming

2002-11-16 Thread Joe Provo

On Fri, Nov 15, 2002 at 03:33:51PM -0800, Steve Rude wrote:
 
 I am trying to collect information about using RFC 1918 space on an ISP 
 backbone.  I have read the RFC several times, and I don't see where it 
 says that you cannot use 10/8 space to number your backbone links (/30s).  

As mentioned, routers tend to be seen as 'category 3' devices. See also 
second and 3rd para on page 4.

 I know this is an old thread that has been rehashed several times, 
 but can anyone please send me links or information that I can use to 
 convince my boss that we should use our arin alloc'd space on our 
 backbone instead of using private space.

If you are indeed a leaf-node, enterprise network your boss may be 
right.  There are ways to do things with unnumbered links too. But
how important is being able to diagnose and repair problems quickly?
The more complex the network is, the more fragile it is and the longer 
your boss' boss will be yelling at your boss to yell at you to get it
fixed.

I prefer to just use /31s (see rfc3021) - the 'wasted address space' 
whine evaporates.

-- 
 [EMAIL PROTECTED] * [EMAIL PROTECTED] * [EMAIL PROTECTED]
 RSUC / GweepNet / Spunk / FnB / Usenix / SAGE



Re: IP backbone numbering/naming

2002-11-16 Thread Mike Lewinski

[EMAIL PROTECTED] wrote:


The DOS attack should be a real concern when using RFC 1918.  A 
distributed) smurf attack,  or one of it's derivatives,  can cause the 
icmp echo replies to be sent to that src. address.  Since the 
attackers just use blocks and blocks of spoofed addresses,  you could 
become the sourced address victim.  Of course,  ingress and egress rfc 
1918  filtering will prevent this...it's just something else to think 
about...


Well, those routes not being globally distributed mitigates that danger. 
The reverse argument could actually be made- I'm unlikely to see any DoS 
backscatter directed at the RFC1918 addresses, while the publics will 
always see it.

I forgot one of the most important reasons we are migrating away from 
this practice. We do source address filtering via RPF verification at 
the edge, but it allows the /30 to leak because there is a valid route 
for it internally. Meaning that deliberately spoofed packets can still 
escape our network, and allowing just one per client is still too many.

The better answer to our DoS victim, of course, is an ACL for every hop 
from the border at the border;that will be implemented as we complete 
the purge of RFC1918.


Steve- the pain of renumbering is simply not worth it... take it from 
someone who's been there and don't use 'em. Backbone links might be 
easier to do than clients, but in the end you WILL end up renumbering 
when it breaks something a client needs. Save yourself the hassle and do 
it right from the start.



Re: IP backbone numbering/naming

2002-11-15 Thread Stephen J. Wilcox

Very old thread!

   Private hosts can communicate with all other hosts
   inside the enterprise, both public and private. However, they cannot
   have IP connectivity to any host outside of the enterprise.

   All other hosts will be public and will use globally unique address
   space assigned by an Internet Registry.

Then you have the policy that its best to filter any rfc1918 packets ingress
which then leads on to broken path mtu, missing traceroute hops... etc..

for the tiny number of addresses you need on p2p why does your boss care. 

Steve

On Fri, 15 Nov 2002, Steve Rude wrote:

 
 Hi All,
 
 I am trying to collect information about using RFC 1918 space on an ISP 
 backbone.  I have read the RFC several times, and I don't see where it 
 says that you cannot use 10/8 space to number your backbone links (/30s).  
 
 I know this is an old thread that has been rehashed several times, but can 
 anyone please send me links or information that I can use to convince my 
 boss that we should use our arin alloc'd space on our backbone instead of 
 using private space.
 
 Also if anyone has opinions on naming conventions for backbone such as why 
 to or why not to even have dns resolution for your backbone and some 
 conventions please let me know.
 
 TIA!
 
 --
 Steve Rude
 [EMAIL PROTECTED]
 
 




Re: IP backbone numbering/naming

2002-11-15 Thread Owen DeLong

Generally it is not prohibited by the RFC, but it is bad form if you send
out ICMP that originates from 10space to places outside your network.
As such, it's generally bad form to use these numbers on intefaces in the
backbone, since those interfaces are likely to show up in ICMP time exceeded
messages unless you completely block traceroute through your backbone, which
is generally regarded as far worse form.

Owen


--On Friday, November 15, 2002 15:33 -0800 Steve Rude [EMAIL PROTECTED] 
wrote:


Hi All,

I am trying to collect information about using RFC 1918 space on an ISP
backbone.  I have read the RFC several times, and I don't see where it
says that you cannot use 10/8 space to number your backbone links (/30s).


I know this is an old thread that has been rehashed several times, but
can  anyone please send me links or information that I can use to
convince my  boss that we should use our arin alloc'd space on our
backbone instead of  using private space.

Also if anyone has opinions on naming conventions for backbone such as
why  to or why not to even have dns resolution for your backbone and some
conventions please let me know.

TIA!

--
Steve Rude
[EMAIL PROTECTED]







Re: IP backbone numbering/naming

2002-11-15 Thread Brian

Looking at the categories of hosts in the rfc, it would be my opinion that a
router that connects you to the outside world would fall into category3 and
therefore need globally unique space.  Just my opinion for the day.  Most
people frown heavily upon traffic that goes from one public node to another
crossing rfc1918 space, there were many threads in years past about @HOME's
use of this tactic.

Brian

- Original Message -
From: Stephen J. Wilcox [EMAIL PROTECTED]
To: Steve Rude [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 15, 2002 3:52 PM
Subject: Re: IP backbone numbering/naming



 Very old thread!

Private hosts can communicate with all other hosts
inside the enterprise, both public and private. However, they cannot
have IP connectivity to any host outside of the enterprise.

All other hosts will be public and will use globally unique address
space assigned by an Internet Registry.

 Then you have the policy that its best to filter any rfc1918 packets
ingress
 which then leads on to broken path mtu, missing traceroute hops... etc..

 for the tiny number of addresses you need on p2p why does your boss care.

 Steve

 On Fri, 15 Nov 2002, Steve Rude wrote:

 
  Hi All,
 
  I am trying to collect information about using RFC 1918 space on an ISP
  backbone.  I have read the RFC several times, and I don't see where it
  says that you cannot use 10/8 space to number your backbone links
(/30s).
 
  I know this is an old thread that has been rehashed several times, but
can
  anyone please send me links or information that I can use to convince my
  boss that we should use our arin alloc'd space on our backbone instead
of
  using private space.
 
  Also if anyone has opinions on naming conventions for backbone such as
why
  to or why not to even have dns resolution for your backbone and some
  conventions please let me know.
 
  TIA!
 
  --
  Steve Rude
  [EMAIL PROTECTED]
 
 





Re: IP backbone numbering/naming

2002-11-15 Thread haesu

Hey,

Usually numbering backbone routers with a 10/8 is not a necessary practice. 
Any backbone routers communicating with the outside world are marked category 
three and should have globally unique IP numbers. Plus, if you are an ISP (in 
which it looks like you are..), it will help others on public internet to try 
to track down abuse a little deeper through traceroutes, which will may be 
help them identify the upstream provider of the offender.

You could also use RFC1918 numbers for your point-to-point /30 aggregation 
blocks with the customers.. But.. since that would have effect on customer's 
premise equipment, it would be better to give them globally unique space as 
well, who knows if your customer comes back and yells at you for not being 
able to get to his router's serial interface IP.


Quoting Steve Rude [EMAIL PROTECTED]:

 
 Hi All,
 
 I am trying to collect information about using RFC 1918 space on an ISP 
 backbone.  I have read the RFC several times, and I don't see where it 
 says that you cannot use 10/8 space to number your backbone links (/30s).  
 
 I know this is an old thread that has been rehashed several times, but can 
 anyone please send me links or information that I can use to convince my 
 boss that we should use our arin alloc'd space on our backbone instead of 
 using private space.
 
 Also if anyone has opinions on naming conventions for backbone such as why 
 to or why not to even have dns resolution for your backbone and some 
 conventions please let me know.
 
 TIA!
 
 --
 Steve Rude
 [EMAIL PROTECTED]
 
 





This mail sent through TowardEX Webmail http://mail.towardex.com




Re: IP backbone numbering/naming

2002-11-15 Thread Mike Lewinski

[EMAIL PROTECTED] wrote:


You could also use RFC1918 numbers for your point-to-point /30 
aggregation blocks with the customers.. But.. since that would have 
effect on customer's premise equipment, it would be better to give 
them globally unique space as well, who knows if your customer comes 
back and yells at you for not being able to get to his router's serial 
interface IP.


This practice was implemented here in the early days, before I came 
along. There have been almost no requests to change by clients, and 
very, very few who even noticed/cared enough to ask why.

But as more VPNs are deployed, I've seen this break some 
implementations. So for two reasons we've begun the (large) task of 
renumbering all the /30 ptp links either public or unnumbered:

1) Ensures all clients who decide to implement VPN don't run into 
frustration because of this practice. We want to encourage better 
security practices, and VPN can be an integral part of that.

2) The script kiddies won't mistakenly assume that we're not doing 
source address filtering. I'm sure that seeing a private address in 
traceroute probably makes you a more desirable target in certain circles.

There is only one case where I would recommend using a private address 
on a public link. We have a client periodically attacked, and in some 
cases the attackers have simultaneously attacked our own infrastructure. 
They now have only one path to them here, and every hop past the border 
is RFC1918.