[arin-ppml] IPv6 Non-connected networks

[Chris Engel]

Michael Richardson wrote:


# This is what security experts (LIKE MYSELF) call:
#     depth-in-security

# I regularly argue with these johnny-come-lately security "experts", because they rarely
# understand the tradeoffs of each layer of security.


So how many years does one have to have in the industry to not be considered a johnny-come-lately or to get the quotes removed from around "expert" ?  I've been in the industry since '90...is that enough time for you? Note...I don't claim to be a security "expert" ....as the scope of my job isn't limited to security alone...like many IT Pros in small to mid-size Enterprises...I wear ALOT of hats and my job involves alot of different areas of IT. Never-the-less, I've had a fair amount of experience with security...I'm very familiar with the concept of "Defense-in-Depth", "Mutil-Layered Security" or whatever euphamisim is in vogue this month. You don't have to read a book to understand the concept. The people who configure security mechanisms are human beings. Human beings make mistakes. If you rely on a single control for security then chances are you are going to get burned by it sooner or later. "Single point of failure"... that's something any IT pro can understand regardless of what area of IT they work in.

OF COURSE there are trade-offs with each layer...there are trade-offs with pretty much EVERY security mechanism implimented. That doesn't mean the trade-offs aren't worth it in the majority of cases ...though they may not be in some?

Let's look at a simple example..... STRONG PASSWORDS.... The most straight-forward trade-off with requiring strong passwords as opposed to weak ones is that they are harder for the human brain to remember...and easier to mistype. You impliment a STRONG PASSWORD policy...you WILL get more account lockouts, more complaints, etc. That doesn't mean that the policy isn't worth it in many cases. Furthermore people CAN misbehave in thier use of such passwords in ways which partialy invalidate thier value...write them on yellow post-it notes stuck to thier monitor, etc.... just like people can route RFC 1918 space when they aren't supposed to... Does that mean that strong passwords are no longer considered a viable security mechanism? (Not that there aren't other mechanisms which are as good or better...but all come with thier own trade-offs).

As far as the value of NAT and Address Obfuscation. I've seen it listed as a reccomended security measure in PCI, DISA, & NIST guidelines to name just a few (Not to mention just about every one of the dozens of security audits I've been put through)...so you'll have to forgive me if I place a little more stock in those (not to mention my own personal experiences) then what I hear from a couple of posters on an Address Policy mailing list.

It's NOT a substitute for good filtering rules...but as an adjunct it DOES have value.

# The major advantage of ULA-C is that is provides a much better way to audit what is what,
 # particularly when there are multiple organizations connecting together in various ways.

Not really sure what you mean by this....other then the implication that ULA-C is uniquely assigned to an organization.... so less chance of it being duplicated in multiple org's when they connect together... I think we all get that advantage over RFC1918 or ULA-Random (although it comes with it's own trade-off too)... but I don't really see a significant difference here from Owens GUA-tainted....a rose is a rose and all that.


# It also permits sane auditing of multiple remote-access connections from laptops/etc. for
# visiting consultants, etc.

# ULA-C for NCN is much more robust than "tainted" GUA as far as failing closed.

# But, for it to have any value over RFC1918 (i.e. NOT USING IPv6), it has to solve problems
# which RFC1918 has caused.

# Split-DNS is one of those things. (I started implementing split-DNS systems back in 1992...
# It was useable then because nobody had laptops.  By the time it became universal for
# enterprises, it was unworkably useless, and /etc/hosts or literal IPs began to replace it)

I agree that the option for using public DNS/RDNS for owners of that space that WANT to use it. However, for many situations Split-DNS is a perfectly workable solution and not even neccesarly much of a head-ache. Laptops need not be some sort of special mystical animal..where all the rules for working with them go out the window. If you provide connectivity for them to your network (say via VPN) they CAN use your internal DNS servers...just like any other device directly cabled to that network. There are alot of mechanisms provided within DNS for working with name spaces that aren't local (Forwarders, Conditional Forwarders, Stub Zones & replication, etc) so it's not impossible to do in most cases. I could see how some organizations might just say... screw it, there are just too many hoops to jump through to do this internaly...lets just make everything public.... and I think that should be an option for those who WANT it. However, lets not pretend there aren't trade-offs with that either. Personaly....beyond the issue of publishing internal host-names & IP's... if I have apps that are designed for use with internal resources...I like the idea of them NOT being able to resolve the names of resources they need to connect to if they don't have internal connectivity. Sometimes you WANT things to break....and break in predictable ways...if the conditions under which they were designed to run don't exist.


Christopher Engel