On Oct 26, 2010, at 12:21 PM, Chris Engel wrote:
> 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.
I disagree. I'll state it in a little more nuanced way.
I'm not saying to not put locks on the door; see comment on stateful firewalls,
and btw take note that prophylactic security isn't much of a security solution
- it can be part of defense in depth, but 80% of attacks come, I'm told, from
behind the firewall. So while I do have a firewall at my home, I don't depend
on it for security. If you're using an IPv4/IPv4 NAT as a stateful firewall,
you misunderstand one or the other and perhaps both, IMHO. IPv4/IPv4 NAT gives
you address amplification. By accident, it also gives you some of the features
of a stateful firewall. That said, if you're looking for security services,
what you want is the stateful firewall - what address is used in the process is
irrelevant.
Topology obfuscation would be the counterpart of preventing people from
figuring out the floorplan of your house. What I'm saying is that if I can see
through your windows, I don't NEED to open your door to determine the floorplan
of your house or what window I should play the peeping tom at, and that
depending on the lock you placed on the door for the purpose is therefore an
exercise in self-delusion.
> - 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.
I agree. They are responsible for what they divulge. The problem (well, one of
them) I am pointing out is that what they divulge is what you're saying you
want not divulged.
> - 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.
Well, perhaps. But I can determine many of the subnets that exist. I can also
identify a system to attack without scanning for addresses; if I can get a
virus into one system in a subnet, it is generally trivial ("ping
<all-local-hosts>") to find the others, and then I'm in. And yes, with a NAT,
if I know what I am doing I can often thread it to inject data to folks. We
even have companies that do that for a living - they call it "ad insertion",
and I call it "injecting executable code into a data stream headed into a host".
> - 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.
True. Another principle of security is to not depend on solutions that
demonstrably don't help. See comment above on the difference between a NAT and
a Stateful Firewall. I'm very much in favor of stateful firewalls. I don't see
the value of address amplification, which is what an IPv4/IPv4 NAT primarily
gets you.
> - 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.
See comment above on the difference between a NAT and a Stateful Firewall.
> - 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 sett
ings just because I want to do something different with my internal
architecture.
Which brings me back to my comments on applications needing to know something
about IP, and how that's a bad thing.
> 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
