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

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

-----------------------
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