> -----Original Message-----
> From: Fred Baker [mailto:[email protected]]
> Sent: Tuesday, October 26, 2010 3:53 PM
> To: Chris Engel
> Cc: Christian Huitema; [email protected]
> Subject: Re: [nat66] NAT66 and internal topology
>
>
>
> 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.
Firstly, I don't depend on NATv44 as a statefull firewall. I use NATv44 in
ADDITION TO a statefull firewall. 1 + 0.15 > 1.00 or to put it another way,
if my statefull firewall fails, NAT still provides me some measure of
protection. That measure of protection is better then no protection in the case
of a statefull firewall failing without NAT. That follows the principle of
Defence in Depth. Note that's not ALL the protections I use.... I also use
device FW's, device hardening, least privilage principles, various monitoring,
physical security, employee security training, etc. Just because NAT only
provides some measure of protection for a narrow range of exploits doesn't mean
it provides NO protection what-so-ever.
Using our analogy, I'm saying that if I want to prevent you from looking in my
windows I CAN put a blind on them, or build a house without windows. However if
you design a door that REQUIRES the floor-plan be posted on the front of
it....then no matter what I do with the windows, I can't stop you from getting
the floor plan. If I can get you, as the door designer, to design me a door
that doesn't have the floor plan on it....then I've got PART ONE of my home
security problem solved and I can go on talk to the window designer and the
chimney designer and the cat-door designer, etc to get the other parts
addressed.
Furthermore, just because you can see into the living-room window doesn't mean
that you know where in the House the SAFE-ROOM is located.
>
> > - 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.
Yeah, and I can try to address that with each of them in turn. Right now you
are basicaly telling me that you want to be part of the problem not part of the
solution.
>
> > - 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".
Yes and if you can walk into my offices and hold a sawed-off 12 GA shotgun to
my head, you can get me to map out the entire network for you and probably give
you every password I know. What's your point? I've got to deal with lots of
different attack vectors, not just the network boundary. That's not an excuse
for making it easier to compromise the network boundary....which transparency
does.
>
> > - 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.
NAT is not JUST about address amplification. It also provides a level of
infrastructure abstraction and some simple security functions. It does that
independant of the existance of a FW. That's not an arguement for not having a
Firewall.... just like having a Firewall is not an arguement for ignoring
physical security in your Data Center. NAT demonstrably helps....just because
it doesn't monitor the halls of your Data Center doesn't mean it provides ZERO
benefit.
>
> > - 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 settings 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.
So your arguement is that FW filtering rules shouldn't be based on IP
Addresses? I'll agree with you completely about higher level applications. But
it strikes me that devices which are intended to control access to the network
layer should... well know something about the network layer.
>
> > 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
