Fred, I've already mentioned before that for our purposes, we want statefull NAT....very similar to what we have now in IPv4, warts and all. However that doesn't mean that the NAT66 solution being proposed by you guys won't be useful to a different subset of Enterprises. So by all means, I think it's a worthwhile endeavor....even if it won't cover my particular needs.
Your other argument about obfuscation strikes me as a non-argument. It's the equivalent saying "Why bother putting a lock on your door if someone can just climb down your chimney to get into the house?" . It's a catch-22 because the guy building the chimney will just turn around and say "Why should I bother putting a capstone on your chimney, if you don't even have any locks on your door?" It's an argument for nihilism.... don't bother to take the first step in a thousand mile journey....because the first step won't get you to your destination. - You are taking responsibility for designing a particular protocol...not all of technology in existence. The only thing you really should be considering is what your particular protocol does/does not divulge. Let the guys who write mail clients worry about working on what they divulge and the guys who write web browsers or site-blockers worry about protecting that aspect of the computing environment. - Not every internal asset that an Admin wants to obfuscate is going to be sitting on a segment that sends outgoing SMTP or HTTP or has web clients that visit potentially malicious sites. Don't make assumptions that just because you can learn the internal IP of a device or two, that you can actually map the ENTIRE internal architecture of an organization. - Even assuming that you COULD map the internal architecture of an organization doesn't mean that doing so requires as little effort as doing an anonymous public WHOIS lookup for their assigned network space. It's a well accepted principle in security that it's impossible to design fool-proof systems. Security is all about designing protections that are good enough that it's generally not worth the effort for intruders to breach them. Just where that tipping point lies is going to vary with what those controls are designed to protect and who is likely to want to breach them. Under such a paradigm ANY measure that increases the net difficulty of breaching an environment by ANY degree has some degree of usefulness as a security measure. - Just because you can learn the IP of something doesn't mean you can breach it. You may know the internal IP of my printer but how are you going to pass packets to it if it's behind a statefull Many:1 NAT device and it doesn't establish any outgoing connections? Even in the absence of a FW filter, you have no way of addressing it. Only if the network boundary device allowed an external connection to specify it's own routing path through the internal network could you do that....and I know of very few devices that are configured to allow such these days. - Security is NOT the only reason to desire abstraction/obfuscation of internal addresses. It's useful to maintain a consistent, stable external advertisement of services independent of what you do with the internal architecture that provides it. In that case you may not care that an external source CAN learn the internal IP of a device providing a particular service.....you simply don't want them to NEED to learn that IP. If I'm providing an external service on 1.2.3.4:5555, I can move the hardware providing that service anywhere in my network that I want providing that I have a route to the boundary device that's binding that external IP. I can utilize any sort of internal addressing scheme or network architecture that makes sense to me....and all I have to do is change the mapping on the NAT device. What that saves me from doing would be calling up the 100 or so external organizations who may use that service and get their network admins to make a change to their FW settin gs just because I want to do something different with my internal architecture. Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Fred Baker > Sent: Tuesday, October 26, 2010 1:37 PM > To: Christian Huitema > Cc: [email protected] > Subject: [SPAM] - Re: [nat66] NAT66 and internal topology - > Email has different SMTP TO: and MIME TO: fields in the email > addresses > > > > On Oct 26, 2010, at 10:04 AM, Christian Huitema wrote: > > > The NAT66 draft enables NAT to rewrite the IPv6 header in a > "checksum > > compatible" way. NAT66 don't have to go fetch the UDP or TCP header > > and whack the checksum. That is certainly a simplification, but it > > comes at a cost. Since there is a simple mapping between > internal and > > external subnets, the external addresses carry information > about the > > internal topology. How is that as a tradeoff? > > Yes, there is a 1:1 translation. It may even be the same > value, if the checksum update is being done in the EID. > > I guess my question is whether that's an issue. If folks > would prefer a stateful NAT, we can obfuscate the source > address further. But at least to my mind, topology > obfuscation is a lost cause in the presence of applications > that carry IP addresses - I can reverse engineer the parts of > your network that I care about from the SMTP envelopes in > your email, from information . For example, you were using a > link local (169.254) address on your laptop when you sent the > email, and the email went through three servers within > Microsoft that are identified by DNS name and IP address, and > then the message got to AMS (IETF) and finally Cisco. Yes, on > the link from your home or your company to your upstream we > can diddle with your source address. Is that important? What > information do you actually think you're hiding, and from whom? > > Heck. Who needs IP addresses. I'll fire up firesheep and > become you at the application layer next time you access a > site that uses http instead of https and pushes cookies. > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
