Subject: [nat66] NAT66 and internal topology

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Oct 2010 17:04:09 +0000

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?

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 19:25:03 +0200

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

In my understanding, a NAT66 doesn't hides the internal topology (while the stateful NAT66 does, and does better regarding privacy).

Any CPE that includes a FW having a stateful processing anyway, I personally have doubts that that there is a need for stateless NAT66's in CPEs.
But if people believe they know whet they do with NAT66's, and prefer to have them stateless, why not. 
It's up to them.
   
RD

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 10:36:56 -0700

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

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.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Oct 2010 18:26:20 +0000

> From: Fred Baker [mailto:[email-masked]], Sent: Tuesday, October 26, 2010 10:37 AM
>

>> 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?
>
> I guess my question is whether that's an issue. If folks would prefer a stateful NAT, 
> we can obfuscate the source address further. 

We certainly can. We could for example use encryption to map the 64 bit internal EID to an encrypted 64 bit external EID, then compute the checksum differential on all bits of the address and remap the subnet ID. That would be almost stateless, the only state being the encryption key maintained by the NAT. Not that I am advocating that, I am just raising the issue to make sure it is considered.

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

There was a long thread about this issue when we discussed the simple security model, so I am pretty sure that some people do care. They may or may not be misguided. I am ready to believe that you know better than them. But then, there is a long history of know-nothing not following the IETF designs...

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

I don't have a sheep in this race. I am just pointing out a tradeoff in the draft between simplicity and obfuscation. At a minimum, it would be useful to make that tradeoff explicit.

-- Christian Huitema

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 11:33:25 -0700

> There was a long thread about this issue when we discussed the simple security model, so I am pretty sure that some people do care. They may or may not be misguided. I am ready to believe that you…

I guess my biggest comment is one I made about two years ago.
      http://www.ietf.org/proceedings/73/slides/behave-14.pdf

I would recommend that people that implement this technology also implement an optional stateful firewall, so that people can turn it on. They might consider referring to

http://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-simple-security
  "Recommended Simple Security Capabilities in Customer Premises Equipment
  for Providing Residential IPv6 Internet Service", James Woodyatt,
  21-Oct-10

which is in the RFC Editor's inbox.

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 11:38:04 -0700

>      http://www.ietf.org/proceedings/73/slides/behave-14.pdf

I should have said which slide it was. Slide 33.

> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Chris Engel <[email-masked]>
Date: Tue, 26 Oct 2010 15:21:07 -0400

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 settings just because I want to do something different with my internal architecture.

Christopher Engel
Network Infrastructure Manager
SponsorDirect
[email-masked]
www.SponsorDirect.com
p(914) 729-7218
f (914) 729-7201

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Fred Baker
> Sent: Tuesday, October 26, 2010 1:37 PM
> To: Christian Huitema
> Cc: [email-masked]
> Subject: [SPAM] - Re: [nat66] NAT66 and internal topology -
> Email has different SMTP TO: and MIME TO: fields in the email
> addresses
>
>
>
> > 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.

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 12:52:50 -0700

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

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…

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

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

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

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…

Which brings me back to my comments on applications needing to know something about IP, and how that's a bad thing.

---

From: Chris Engel <[email-masked]>
Date: Tue, 26 Oct 2010 17:11:52 -0400

> From: Fred Baker [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 3:53 PM
> To: Chris Engel
> Cc: Christian Huitema; [email-masked]
> Subject: Re: [nat66] NAT66 and internal topology
>
>
>
> > 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'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.
>
> > - 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.

> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Fred Baker
> >> Subject: [SPAM] - Re: [nat66] NAT66 and internal topology
> - Email has
> >> different SMTP TO: and MIME TO: fields in the email addresses
> >>
> >>
> >>
> >> Yes, there is a 1:1 translation. It may even be the same value, if
> >> the checksum update is being done in the EID.
> >>
> 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
> become you
> >> at the application layer next time you access a site that
> uses http
> >> instead of https and pushes cookies.

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 14:28:20 -0700

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

Well, I'm sorry you feel that way. You're asking for a different solution than is the stated topic of this list, and as near as I can tell the reason you want it in IPv6 is because you have had it in IPv4. From that perspective, it's off-topic for this list, which is talking about stateless network prefix translators, not stateful network address translators. If there is a market for what you want, I think we can expect vendors to make products for it; that product won't be this one.

So I'm not going to further discuss stateful NAT in IPv6 in this thread.

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

Well, thanks for making my point, which is that address obfuscation at the network boundary isn't much of a solution. By accident, it gives you part of what you are actually looking for, which is a stateful firewall, but it is not a stateful firewall.

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

Yes, they probably should. Your stateful firewall should know what traffic your policy permits into your network, and if your policy is (as they usually are) based on prefix or address, it should be looking at prefixes and addresses.