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

[Tony Rall <trall@almaden.ibm.com>]

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