RE: draft-ietf-opsec-infrastructure-security-01 - Infrastructure Hiding

["Ryan Mcdowell \(rymcdowe\)" <rymcdowe@cisco.com>]

Granted I'm biased, but chiming in as another person who really likes
the whole core hiding idea.  

First, I don't think anybody is proposing using RFC1918 addresses for
the physical interface IP's (ie POS, TenGE, etc) in a public SP network
as this would, as you mentioned, cause all sorts of layer 8 problems.
The RFC1918 addressing is just for loopbacks to tie your iBGP to (unless
of course you can infrastructure ACL off your loopbacks in which case
public IP's are fine).  Your physical interfaces must still be publicly
addressed (or unnumbered using a public IP loopback), just not routable
within your network.  You advertise the /16 or whatever aggregate but
don't carry the /31 point to point links within your igp or BGP; this
way any response from these IP's still pass uRPF checks and bogon acls
but any traffic sent to them is dropped on the first router in your
network (hits a /16 route to null0).  The point is to make everything
the same as it is now on your network, just folks cannot send traffic
directly to router interface addresses (unless of course you are
directly connected, ie eBGP).  This is the same thing that has been done
for years with infrastructure ACL's, but now it can be done with a
routing trick and remove the main obstacles to why some SP's don't use
iACLs: high OPEX and older HW that doesn't do line-rate ACLs.  

Yes, you can still attack routers by sending nasty traffic through them
(ip options/ttl expiry, cough cough), but its far easier to kill a
router with receive traffic than with transit traffic.  But once you get
to the point where the only attack vector is link saturation, you're in
really good shape.  Granted that is still a problem, but that's a whole
different problem.  

Also, most routers nowadays rate-limit ICMP unreachable for you by
default, so you are probably already doing this :)  I was working with
some cable providers over the last couple years and they have a serious
problem here.  They have lots of end users downloading
probe/pinger/tester programs that traceroute and ping all the routers in
the path.  When you have 5-10 million people doing this on your network,
they have seen copious amounts (I think 5000-10000pps) of icmp-echo
hitting a single router.

----------------------------
Ryan McDowell
PGP Fingerprint: EED9 192F 9F45 FAE4 F6A3 8764 FEE1 299D 1B62 A361 
----------------------------

-----Original Message-----
From: owner-opsec@psg.com [mailto:owner-opsec@psg.com] On Behalf Of Tony
Rall
Sent: Thursday, April 26, 2007 9:16 PM
To: opsec@ops.ietf.org
Subject: RE: draft-ietf-opsec-infrastructure-security-01 -
Infrastructure Hiding

On Thursday, 2007-04-26 at 18:44 CST, "Smith, Donald" 
<Donald.Smith@qwest.com> wrote:
> From rfc 1918:
> Some examples, where external connectivity might not be required,
> are:
> <snip>
> "Interfaces of routers on an internal network usually do not need to 
> be directly accessible from outside the enterprise."
> <snip>
> "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. If such a router receives such 
> information the rejection shall not be treated as a routing protocol 
> error."
> So the way I read that as long as we don't provide a path back to the
rfc1918 
> space and don't expect external connectivity directly to the 1918 
> space
this is 
> within the guidance of the rfc.

Not in my mind.  In no way is an ISP's network private (ok, parts of it
might be, but those parts would not be on the path of transit traffic).

> While that clearly says enterprise I believe it can be applied here.
> Your statement "assuming you ever source packets with these addresses 
> to

> targets outside your "private" network" is of course correct.
> But when mixed with other infrastructure core hiding techniques it
should be 
> possible to never source traffic outside your "private network".

But if you never source such packets, you're breaking all sorts of RFCs
- mainly related to icmp.
 
> Making portions of your network, such as core routers, "untargetable" 
> specifically making the control plane addresses not routable 
> externally
makes 
> it EXTREMELY difficult to attack those portions.

Certainly it's still possible to target them.  Perhaps you can't
overload them by direct addressing, but all that's necessary is to get
traffic to go through them.

Regardless, I never buy the argument that adding any subtle amount of
protection for my network justifies breaking all kinds of other things.
If it's really thought otherwise, I don't know what stops those who do
from using the ultimate firewall - wire cutters.

> you have probably already ratelimited icmp unreachables.

Nope, never done this.  But that is not nearly as bad as cutting them
out completely.  I can justify some collateral damage in response to an
actual attack, but I can't condone blindly blocking (whether by
filtering or using invalid addresses) of legitimate traffic.

> To stop people from doing negitive scanning of our infrastructure I 
> require SILENT drops (not tcp reset no icmp
unreachables) from 
> network vendors.

This is really pushing the "security by obscurity" modus.  I see no
value in it, and plenty of problems.
 
> No rfc that I know of requires I publish/advertise all the IPs of a
router.

Certainly not, but those addresses that communicate outside your network

should be legitimate and reachable.

> PTMUD has been blocked in many networks as a result of this issue.

Yes, and I consider that a significant negative against what has been 
proposed (and any other techniques that cause the same problem).  I do
not 
consider this a "best" practice or even a slightly good practice.

Don't get me wrong - I feel the other sections (other than 6.x) of the 
draft might be beneficial, but I wanted to strongly object to 6.

--
Tony Rall