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

["Smith, Donald" <Donald.Smith@qwest.com>]

First let me say I really appreciate the fact that you commented.
I disagree with some of your statements. 
 
 
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.
 
 
 
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".
 
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. 
 
When the diagnostic features of a router/network are used constantly in attacks against the infrastructure you have to make a decision about diagnostic features vs. network stability. Yes that may violate other rfc's. But if you ever implemented blackhole filtering then you have probably already ratelimited icmp unreachables. To stop people from doing negitive scanning of our infrastructure I require SILENT drops (not tcp reset no icmp unreachables) from network vendors.
 
No rfc that I know of requires I publish/advertise all the IPs of a router.
Not advertising all the ips for a given router name is one method that was used to assist in mitigating the BGP reflective attack against grc. 
 
PTMUD has been blocked in many networks as a result of this issue.
http://www3.ietf.org/proceedings/05nov/slides/tcpm-4.pdf <http://www3.ietf.org/proceedings/05nov/slides/tcpm-4.pdf> 
 
 
donald.smith@qwest.com giac

________________________________

From: owner-opsec@psg.com on behalf of Tony Rall
Sent: Thu 4/26/2007 5:56 PM
To: opsec@ops.ietf.org
Subject: draft-ietf-opsec-infrastructure-security-01 - Infrastructure Hiding



-----------------------
6.  Infrastructure Hiding

   "Hiding the infrastructure of the network provides one layer of
   protection to the devices that make up the network core."

Please reconsider.  Not only does this whole section provide no better
than weak protection, it violates numerous suggestions and mandates in
other RFCs.

---------------------
6.1.  Use Less IP

   "One way to reduce exposure of network infrastructure is to use
   unnumbered links wherever possible."

Ok, I suspect this subject doesn't really mean "use less Internet
Protocol"; perhaps it means "use fewer IP addresses".

Regardless, unnumbered interfaces don't bother me too much, although
anything that hides what is actually going on generally ends up causing
pain - to both users of a network and the providers themselves.  (Likewise
with section 6.2.)

----------------------
6.4.2.  Address Core Out of RFC 1918 Space

   "In addition to filtering the visibility of core addresses to the
   wider Internet, it may be possible to use private RFC 1918 [RFC1918]
   netblocks for numbering infrastructure when IP addresses are required
   (eg, loopbacks)."

NO!  This isn't using 1918, it's violating 1918 (assuming you ever source
packets with these addresses to targets outside your "private" network).

  "This added level of obscurity takes prevention of
   wide distribution of your infrastructure address space one step
   further.  Many networks filter out packets with RFC 1918 [RFC1918]
   address at ingress/ egress points as a matter of course.  In this
   circumstance, tools such as traceroute can work for operations and
   support staff but not from outside networks."

Is it really desirable to prevent other folks from diagnosing problems in
traversing your network?  Since we've yet to see a network that has never
had problems, we should be improving diagnostic options, not crippling
them.

And, as Warren mentioned, this would contribute to the breakage of such
things as PMTUD - and all path based icmp error messages.

   "Care should be taken to
   limit reverse-resolution of descriptive DNS names to queries from
   internal/support groups."

Another RFC violation (I think) and generally a bad idea.

--
Tony Rall





This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.