Subject: [v6ops] network topology hiding

From: Toru Kuboshiki <[email-masked]>
Date: Wed, 15 Dec 2010 16:46:45 +0900

Hello, everybody.
My name is Toru Kuboshiki, the student of Meijo University in JAPAN.
This is the first time I post on this mailing list.

I am studying how we can familiarize IPv6.
I think that one of reasons, why IPv6 does not become popular, is that
IP addresses in the local network are seen from the outside. In IPv4,
NAT conceals a whole network and this gives the network manager
security. If IPv6 network can be concealed from the outside, it seems
to be very useful. However, some IPv6 promoters insist that NAT is a
bad idea, because it prevents end to end communication. They admit
that it is not good if terminals in the network are known, but that
can be solved by using temporary addresses. They also say that it is
not needed to conceal sub-net ID, and the thought of RFC4864 is not
needed. I cannot resist the above opinion, because I do not have
enough knowledge yet.

I come to the idea that I can ask the question to the WG. RFC4864 says
that if subnet IDs are randomized, scanning attacks become difficult,
however, it is thought that the effect is not so large because address
spaces in IPv6 are huge enough.

If someone knows the clear reason why subnet ID should be concealed,
please give me some advises.

Regards.

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Dec 2010 01:33:55 -0800

On Dec 14, 2010, at 11:46 PM, Toru Kuboshiki wrote:

> If someone knows the clear reason why subnet ID should be concealed, please give me some advises.

<opinion>
The short answer is that people have a notion that it improves security. However, it is made very obvious in application layer protocols like SMTP and SIP/SDP, so the security benefits, if they exist at all, are pretty marginal.
</opinion>

---

From: "t.petch" <[email-masked]>
Date: Wed, 15 Dec 2010 10:37:04 +0100

----- Original Message ----- 
From: "Toru Kuboshiki" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 15, 2010 8:46 AM

> security. 

<more emotion than engineeering>

Put forward this point of view on some lists, the main IETF one for 
example, and, judging by past experience, you will get a firestorm of 
protest that NAT adds no security.  I think that the truth is closer to
that than you say, that NAT adds a little security, but not much.  I have
worked with a number of managers who are convinced that it adds 
a lot, and I think that that is a dangerous position to take.

At the same time, you will see a lot of support for the view that NAT
destroys end-to-end communication, which I personally think untrue
in almost all cases.  The protocols used by the vast mass of Internet
users overcame NAT years ago, and there are just a few protocols,
unknown to almost everybody in the world at large, which have not,
but for most people, that is irrelevant.

So, roll on NAT! we won't need it to in IPv6 as an address proxy, 
and it won't add security, but I still expect it to happen.

</more emotion than engineeering>

Tom Petch

>              If IPv6 network can be concealed from the outside, it seems
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Wed, 15 Dec 2010 02:55:42 -0800

>> NAT conceals a whole network and this gives the network manager

The prevalence of botnets is a testament to the adaptability of
attackers to exploit any and all attack surfaces.  NAT has not
hindered botnets one bit.

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 15 Dec 2010 12:07:14 -0200

Hello all, and welcome Toru,

I fully agree with the view expressed here that NAT adds little to no
security. Moreover, most recent attack/exploits are no longer
network-based but application-based and for which NAT means nothing in
terms of added protection.

I do disagree with Tom in one point: NAT does break end-to-end in one
direction, namely you cannot receive incoming connection requests. I
agree with Tom that many protocols punctured/bypassed NAT a long ago,
but I rather see this as an unfortunate side effect of having to deal
with pervasive NAT usage.

IMO, protocol designers SHOULD NOT (in rfc-parlance :-) ) have to
worry about funky stuff going on at the network layer. If
traffic/connections are administrative filtered (read firewalled),
fine, just use the appropiate ICMP messages to signal the situation.

In my experience, NAT ends up being used as a "easy firewall". Instead
of worrying about reflecting routing/connectivity policy in a set of
rules, just number with RFC 1918 and NAT the whole thing out. From
this point onwards, layers of NATs start piling up. I have seen
diagrams of people i rather not mention with three and four layers of
NAT just to accomodate some new servers without renumbering. Needless
to say, everytime something breaks, a meeting is needed just to see
whose layer might be responsible.

Cheers!

Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://www.labs.lacnic.net
=========================

---

From: Arturo Servin <[email-masked]>
Date: Wed, 15 Dec 2010 12:49:43 -0200

> </more emotion than engineeering>

	People with PA space also use NAT to avoid re-numering when changing providers, I am not saying that is good or bad, but some people is considering NAT in IPv6 for this task. Also, in multi-homing with PA space, NAT in IPv6 could play a roll (again, not saying that is good or bad, only that is being considered as solution).

-as

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Dec 2010 07:19:39 -0800

> but for most people, that is irrelevant.

These protocols are probably obscure /because/ they don't work over NAT, not the other way around.  NAT prevents certain kinds of useful interoperability quite effectively. The fact that it does not prevent /all/ interoperability is hardly a ringing endorsement. :)

---

From: Roland Bless <[email-masked]>
Date: Wed, 15 Dec 2010 16:58:27 +0100

Hi,

> but for most people, that is irrelevant.

I don't agree. One problem is that NATs are an obstacle for new
protocols (e.g., especially transport protocols). Currently, it's really
hard to deploy "new" protocols like SCTP or DCCP across NATs without any
UDP encapsulation. Thus, NATs actually hinder innovative applications or
protocols and I wouldn't dare to say in general
that some useful future protocols or applications are irrelevant.
Furthermore, stateful NATs restrict incoming data flows due to missing
binding states, unless you use some rendezvous point in the public
address realm - another aspect of broken e2e communication.

Regards,
 Roland

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 15 Dec 2010 08:50:21 -0800

> address realm - another aspect of broken e2e communication.

asymetric routing  is one example where this is a particular challenge.
stateless device have no trouble with such situations but PAT does.

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Dec 2010 10:36:11 -0800

> If someone knows the clear reason why subnet ID should be concealed, please give me some advises.

p1. There is an important distinction to be drawn between 'concealed' and 'randomized' in this discussion.  When RFC 4864 talks about randomizing the subnet identifier, the idea is to make it harder for worms to guess a valid subnet identifier at an advertised network prefix.  On the other hand, some proponents of IPv6/NAT think that concealing the subnet identifier behind the obfuscating function of a translator is a good idea, but RFC 4864 is talking about how to obtain the desired properties of concealment without using a translator.

p2. The usual reason people give for wanting to obfuscate the subnet identifier portion of network prefixes in IPv6 addresses with a translator is to prevent disclosure of enterprise network topology to exterior domains.  The traditional counter to that argument is to point out that untranslated addresses easily leak from enterprise networks via application protocols like SMTP and others, so the obfuscation provided by the translator is too easily defeated to be of any significant security value.  Naturally, that's a controversial value judgment, and experts on both sides are in vigorous disagreement.  Keep an eye out for bolts of lightning.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Dec 2010 17:23:26 -0300

Hi,

> that some useful future protocols or applications are irrelevant.

Well, deeming that as "bad" would be based on the assumption that the
"raison d'etre" of most networks out there is innovation, which I'd
argue it is not. For many (if not most) organizations, their networks
help in getting work done.

-- Yes, you and me possibly like to be able to play with protocols on
the 'Net. But that doesn't mean that everybody should be willing to do so.

> address realm - another aspect of broken e2e communication.

Again, while for some this might be a drawback, for many others this is
a desired feature. Simple/dumb example: think about infamous "ping of
death"-like vulnerabilities. A simple "allow only return traffic" policy
would help mitigate this - and such a policy can also mitigate (to some
extent) some layer-3/4 trivially-remotely-exploitable 0-day vulnerabilities.

"Don't allow/enable stuff unless you really need it" is, in general,
your friend.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Sander Steffann <[email-masked]>
Date: Wed, 15 Dec 2010 21:30:58 +0100

> help in getting work done.

But now the innovations can never be deployed to get those things done because of NAT...
- Sander

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Dec 2010 07:45:36 +1030

On Wed, 15 Dec 2010 10:37:04 +0100

> a lot, and I think that that is a dangerous position to take.

NAT topology hiding is functionally equivalent to camouflage. It
provides a minimal defence in depth mechanism, however anything that
uses it also a big gun, can run fast, can kick hard, or bite savagely
to resort to when the camouflage fails. People who seem to vehemently
defend topology hiding seem to be coming from a position that there is
no need for any other prevention or response mechanisms, which is quite
false.

> in almost all cases.

I don't think you fully understand what "end-to-end" is referring to.

The nature of the Internet is supposed to be, and was originally 
peer-to-peer. A peer-to-peer network architecture means that if a
node has an network address, it has an equal ability to directly send or
receive packets to any other node that also has an address and is
attached to the same network. What the end-nodes, and more
specifically, what the applications put in those packets was irrelevant
to the newtork. The roles of "client" or "server" are only supposed
to be relevant to application architecture and roles. A node attached
to a peer-to-peer architecture network should be able to concurrently
run client or server components of applications without any network
imposed limitations - it was exclusively an end-nodes choice as to what
application role it wanted to play, not the network's. Also,
because the network doesn't care about what applications
it was being used for, the network doesn't need to be upgraded
before new applications can be deployed.

NAT has broken the peer-to-peer nature of the Internet. The
consequences have been that some end-nodes can't directly send traffic
to other end-nodes, so they have relay the communications via another
intermediary node that is visible to both the end-nodes. This
intermediary node then becomes another possible failure point, an
possible traffic interception point and a potential performance
bottleneck point. Applications that are forced to use an intermediary
become less reliable, less naturally secure and less scalable. Yet
there is no other choice if the end-nodes cannot directly send packets
towards each other. That is the limitation that NAT has imposed on
end-nodes. NAT exists because there aren't enough IPv4 addresses to
give all end-nodes unique addresses, and therefore not all remote-end
nodes that local end-nodes might want to send packets to are uniquely
identifiable and therefore reachable. Giving every end-node a network
unique Internet address (i.e. an IPv6 one), will give them back their
ability to exclusively choose what role they want to play in the
application architecture.

>  The protocols used by the vast mass of Internet

NAT boxes "overcame" those limitations be incurring the hidden costs of
forcing public intermediary servers to exist, and application
developers to have develop client-server applications where a
peer-to-peer application architecture would have been far more
reliable, secure and scalable. The costs of dealing with a network
layer problem, namely lack of IPv4 addresses, has been shifted onto the
application developers and ultimately the end-users of those
applications. People have accepted them because there is no other
choice an an IPv4/NAT scenario - but with the deployment of IPv6
without NAT those costs can disappear. So we'll have more reliable, more
naturally secure and more scalable applications at less cost.

> and it won't add security, but I still expect it to happen.

Returning to the original question, for the comparative advantage of
network camouflage, verses the other costs NAT incurs, I'm willing to
go without it.

Regards,
Mark.

---

From: Roland Bless <[email-masked]>
Date: Wed, 15 Dec 2010 23:27:45 +0100

Hi Fernando,

> help in getting work done.

No, that's not my opinion and a real misinterpretation of my statement.
The reason for most protocols out there is to get a problem solved and
some service accomplished - it's definitely not for having innovation
per se.
Nevertheless, at some point in time you need to deploy new protocols in
order to
offer new or better services - that's where innovation is required.

> the 'Net. But that doesn't mean that everybody should be willing to do so.

No, it's not about playing with new protocols in the net.
The IETF's mission is to make the Internet work better and
that includes deployment of some new protocols in many cases.

> extent) some layer-3/4 trivially-remotely-exploitable 0-day vulnerabilities.

The individual security requirements may vary widely, but IMHO
these things should be better realized by appropriate firewall
mechanisms, not by accidentally missing NAT bindings...
IMHO end-system security will never be perfect, and as Erik
already mentioned: NATs didn't prevent the advent of Botnets
and threats by trojan horses and the like are more serious
and not prevented by this policy.

> "Don't allow/enable stuff unless you really need it" is, in general,

That's maybe a cautious choice/policy, but it can be realized
in many ways, e.g., a default drop policy in your firewall.

Regards,
 Roland

---

From: Michael Newbery <[email-masked]>
Date: Thu, 16 Dec 2010 12:12:42 +1300

> but for most people, that is irrelevant.

SIP?

Hardly irrelevant, and the basis of not only VoIP but also various instant message protocols.

Running SIP through NATs is horrible, but there are techniques involving application level gateways that mostly work. Right up to the point at which people start using encryption, at which point NAT/ALGs become impossible.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Dec 2010 20:21:40 -0300

Hi, Roland,

> No, that's not my opinion and a real misinterpretation of my statement.

My apologies. :-)

> order to offer new or better services - that's where innovation is required.

There has not been much of that in he last 25 years or so. And I'd argue
that, if anything, for the most part innovations seems to be ocurring at
layers higher than 4.

> that includes deployment of some new protocols in many cases.

My point is that while we'd probably like a "default allow", for many
(most?) organizations "default deny" makes more sense.

> mechanisms, not by accidentally missing NAT bindings...

A NAT-PT ends up being (kinda accidentally) a "only allow return
traffic" firewall. (you need a mapping in the NAT for the packet to get
into the internal realm, which means that communication had to be
initiated from the internal realm).

> and not prevented by this policy.

Nor would IPsec prevent this. So what?

> in many ways, e.g., a default drop policy in your firewall.

At that point, the only app protocols that break are those that include
network-layer address in the app protocol -- which some might argue is
not much of a "clean" design.

Thanks!

Kind regards,

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 15 Dec 2010 23:48:36 -0800

Totally agree with all that Mark has said below.

Another variable is accountability which is made easier without the use of NAT.  *If* you want this...i.e. tie physical machines to logging data which almost always relates to identification via IP addresses, it's much easier if the address is not NATed.  

- merike

---

From: "t.petch" <[email-masked]>
Date: Thu, 16 Dec 2010 11:13:45 +0100

--- Original Message ----- 
From: "Mark Smith" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Toru Kuboshiki" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 15, 2010 10:15 PM
> application architecture.

Mark

Yes, I do understand end-to-end; I am familiar with the Dave Clark paper
and do go back to it now and then.

But I am also aware of what the current reality is, and was reminded of
it when I had cause to review ISP offerings earlier this year.  The focus
is on video download, online TV, phone and web browsing, of which
only SIP might be a cause for concern with NATs.

I even was told 'We do not support FTP' by the major ISP here,
and eventually got to know that that is what the salesmen are trained to
say when someone asks them about something they have not been 
trained in; second line technical support were trained in FTP and yes,
it works.  But I may still be denied by my ISP what many on this list would 
take for granted (the likes of whois, NTP,... )

So what I am saying is that the vast majority of the Internet as of now
is domestic users and they, as in previous technological advances,
determine what the market is.  And the vast mass of protocols that we
come up with are just not relevant so the fact that NAT disables them is 
also not relevant.  If NAT offers some operational advantage to those
ISPs, then they will use it.

Tom Petch

---

From: Erik Kline <[email-masked]>
Date: Thu, 16 Dec 2010 12:53:38 -0800

> ISPs, then they will use it.

There's a critical difference between "real" and "perceived" benefit.
In my experience, the latter tends to outweigh the former by several
orders of magnitude.

Oh well.  :-/

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Dec 2010 09:29:42 +1030

Hi Tom,

On Thu, 16 Dec 2010 11:13:45 +0100

> > > > This is the first time I post on this mailing list.

<snip> 

> determine what the market is.

I don't really think you can conclude that common end-users of the
Internet will continue to want to be limited to being "clients", rather
than also truly "equal peers" or "servers", in an IPv6 Internet, based
on the history of the IPv4/NAPT era. The ability to be an application
peer or server has been severely limited in the IPv4/NAPT Internet, and
required relatively complicated knowledge and actions to overcome (i.e.
setting up port forwarding, assuming you didn't have competition for
the port). That created a barrier that most people don't even know
exists, let alone would be willing to spend the time learning how to
overcome (e.g. understanding what an IP address is, what transport
layer protocols and ports are). When that hidden barrier is removed via
IPv6, and the equal peer/server capability returns to being as cheap and
available to use as is being a client, we may see far more peer-to-peer
architecture applications emerge, because they now can, far more easily
than in the past.

Regards,
Mark.

>  And the vast mass of protocols that we

---

From: Toru Kuboshiki <[email-masked]>
Date: Tue, 21 Dec 2010 18:48:47 +0900

I’m Toru Kuboshiki, a topic starter.
Thanks for many opinions. But the arguments are slightly different
what I want to know.

I know that NAT is imperfect tool for security. But it does conceal a
whole network, which firewall can not do. While, NAT breaks end-to-end
communication, that is “NAT traversal problem”. So I think it is very
effective if there is a method that can achieve end-to-end
communication, and also can conceal the network. I think there are two
methods to realize this.

Method1:
The method to apply the principle of Mobile IPv6 as written in
RFC4864. In this method, Internal Node (IN) that is under Gateway
corresponds to Mobile Node (MN), Gateway corresponds to Home Agent
(HA), and External Node (EN) corresponds to Correspondent Node (CN).
IN has two addresses, those are routable address and a randomized
address. The randomized address is registered to Dynamic DNS server
every time it power on in order to be able to initiate communication
from EN. Of the randomized address, the subnet ID and the interface ID
fields are randomized. Communication between HA and IN is capsulated
with IN’s routable address and HA’s address. With this method,
end-to-end communication is achieved because there is no address
translation, and also the network is concealed because IN’s address is
randomized.

Method2:
The method to use a privacy address shown in RFC4941 for IN’s address.
IN’s address is registered to DDNS server same with the above case.
This method is very simple, and the interface ID is randomized, and
also end-to-end communication is possible, however, subnet ID is seen
from the outside of the network.

I really want to know that IN’s subnet ID should be concealed or not.
Method 1 can do that but complicated, Method 2 can not do that but
simple. Which method do you recommend, or are there any other methods?

Sincerely.

---

From: Mark Smith <[email-masked]>
Date: Tue, 21 Dec 2010 21:29:14 +1030

On Tue, 21 Dec 2010 18:48:47 +0900

> simple. Which method do you recommend, or are there any other methods?

ISATAP could be used with private IPv4 addresses. It would present all
IPv6 hosts as coming from a single /64, presented to the Internet by
the IPv6 Internet/ISATAP edge router. The underlying IPv4 addressing
scheme would disclose a level of topology, although it wouldn't be
reachable from the Internet, and reverse DNS PTRs couldn't be used to
associate those private IPv4 addresses with any names behind the IPv4
network structure, which typically seems to be the major concern
addressed by topology hiding - the names give away what security
domains/subnets the hosts exist in.

Depending on the effort you're willing to go do, you could also achieve
similar to the above without disclosing the underlying IPv4
addressin, with a variety of other IPv6 over IPv4 tunnelling methods to
the end-nodes e.g. IPsec, GRE, L2TP etc. In that case, you'd have
individual manually configured point-to-point IPv6 over IPv4 tunnels
between the end-nodes and the IPv6 Internet edge router, assign the
IPv6 end-node addresses out of a single /64, use host routes to push
the traffic towards them down the correct individual end-node tunnel.
If neighbor discovery is supported over the tunnels, you may not even
need to configure the host routes, and would be able to have the IPv6
end-nodes use privacy addresses for their IIDs.

Regards,
Mark.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 21 Dec 2010 12:26:56 +0100

I am one of the authors of RFC4864.
I speak here with my personal hat on, and not from my employer or
co-authors perspective.

I do not think that Method-1 has to be difficult. Biggest issue is the
mobile IP stack 
availability on the end-systems. If that is available, then its actually
quite simple.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Toru Kuboshiki
Sent: dinsdag 21 december 2010 10:49
To: [email-masked]
Subject: Re: [v6ops] network topology hiding

I'm Toru Kuboshiki, a topic starter.
Thanks for many opinions. But the arguments are slightly different
what I want to know.

communication, that is "NAT traversal problem". So I think it is very

Method1:
with IN's routable address and HA's address. With this method,
translation, and also the network is concealed because IN's address is
randomized.

Method2:
The method to use a privacy address shown in RFC4941 for IN's address.
IN's address is registered to DDNS server same with the above case.
This method is very simple, and the interface ID is randomized, and
also end-to-end communication is possible, however, subnet ID is seen
from the outside of the network.

I really want to know that IN's subnet ID should be concealed or not.
Method 1 can do that but complicated, Method 2 can not do that but
simple. Which method do you recommend, or are there any other methods?

Sincerely.

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Dec 2010 20:25:16 -0800

> communication, and also can conceal the network. I think there are two

Is there any good document that shows that topology hiding achieves
anything meaningful?

* Specifically, does something exist that addresses the "net gain to
complexity ratio", which I personally consider to be far too low. *

DDOS attacks can easily fill upstream links for most organizations
without knowing anything about the internal structure.  And Stateful
Packet Inspection is still required for "defense in depth" (unless an
organization fully trusts that all nodes are individually secure).

In an algorithmic (i.e. Network Prefix Translation) usage scenario,
how long would it take to map out all reachable /64s in a /48 by
observing the kind of ICMPv6 responses from routers (network
unreachable vs host / port unreachable vs admin prohibited vs ...)?
How long given a botnet of 100,000 machines on which the controller
could start Teredo/6to4/...?

I assume a real security researcher could think of something more
sophisticated or effective, but off the top of my head I'd think you'd
need to be careful about the kind of ICMP code generated in response
to, say, fake TCP response packets or something.

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Dec 2010 21:01:19 -0800

> could start Teredo/6to4/...?

One RTT, if the right 65536 pings were sent simultaneously. Some would come back as ICMP echo replies and the rest would come back as Destination Unreachable Messages. The question is what code the "unreachable" messages carried:

   Code           0 - No route to destination
                  1 - Communication with destination
                        administratively prohibited
                  2 - Beyond scope of source address
                  3 - Address unreachable
                  4 - Port unreachable
                  5 - Source address failed ingress/egress policy
                  6 - Reject route to destination

The opening statement of NPTv6 is that it makes no pretense at being a security solution and suggests that folks looking for one implement draft-ietf-v6ops-cpe-simple-security.

So to NATs providing topology hiding - first, they don't need to, as hosts behind a NAT are reachable by anything that can observe the messages spewing forth from it, and it doesn't take much to RTS a TCP connection or otherwise disrupt. Second, the topology is often visible in application layer messaging - DNS, SIP, SMTP, and so on. If the information were not available through the application layer, RFC 2993 would not be valid.

---

From: Erik Kline <[email-masked]>
Date: Tue, 21 Dec 2010 23:37:55 -0800

> So to NATs providing topology hiding - first, they don't need to, as hosts behind a NAT are reachable by anything that can observe the messages spewing forth from it, and it doesn't take much to RT…

So it sounds like we can stop worrying about this topology hiding
business then.  ;-)

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 22 Dec 2010 00:26:25 -0800

> So it sounds like we can stop worrying about this topology hiding

only in the sense that it's not going to work.

---

From: Merike Kaeo <[email-masked]>
Date: Wed, 22 Dec 2010 01:46:50 -0800

> only in the sense that it's not going to work.

I so wish people understood that.  I am constantly dealing with folks deploying networks who 'trust' being behind a NAT.  Vendor FUD doesn't help (apologies to folks here who work for vendors whose sales and marketing people are simply insane...I know some of you are trying to help reign them in) :)

I just took a quick look at NPTv6 in its latest instantiations and am wondering whether some of the statements above can be part of the 'security considerations' section?!?  If nothing else it adds content as to why you should not rely on NAT as a security mechanism.   Every bit of enlightenment helps.

- merike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Dec 2010 10:58:42 +1300

> So it sounds like we can stop worrying about this topology hiding

I've always assumed that the people who are so keen on topology
hiding (i.e. subnet number hiding) are concerned about forms of
espionage against enterprise networks roughly like the following:

"I know that corporate SMTP server X is on subnet Y and its
name suggests it might be in city Z. [You can learn that
from an SMTP header.]

"Therefore, there's a good chance that the very important server Q
which I believe is in city Z is also on subnet Y.

"Therefore, I'll try a scanning attack on subnet Y to see if there
are any open ports I can get into, one of which might be on Q."

Of course, there are plenty of ways to deflect such attacks without
hiding subnet numbers. I note that many large enterprise networks
with strong security cultures don't bother to hide them.

As I believe Chris Engel pointed out, in the on-line card services
world, there is a formal requirement, summarised as

"1.3. Prohibit direct public access between the Internet and any system component in the cardholder
data environment."

(https://www.pcisecuritystandards.org/documents/pci_ssc_quick_guide.pdf)

I see that in the latest update of PCI-DSS standard, they made this change:

"Removed specific references to IP masquerading and use of network address translation (NAT) technologies and added examples of
methods for preventing private IP address disclosure."

(https://www.pcisecuritystandards.org/documents/pci_dss_v2_summary_of_changes.pdf)

That sounds like progress.  In fact, if you read the actual text of the
PCI DSS v2.0 standard requirement 1.3.8 (not quoted here because there
is some legal gobblydegook associated with access to the standard),
NAT has been downgraded to be just one possible method of disclosing
internal IP addressing and routing info. The new text seems quite sane,
and compatible with RFC 4864.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Dec 2010 19:44:43 -0300

Erik,

> Is there any good document that shows that topology hiding achieves

That depends on the threat model. In some scenarios, knowing the network
topology may be valuable. In others, may be not. But usually for some
the principle of "if you don't need to provide such information, then
don't" applies.

> complexity ratio", which I personally consider to be far too low. *

My take is that in many cases, some benefits of NATs were perceived
"after the fact", rather than the aforementioned analysis being
performed before their deployment.

> without knowing anything about the internal structure.  

And that's also the case if you have an antivirus installed on your
system --- but it doesn't mean that you will uninstall your antivirus,
or that you don't need it, or that it does not provide anything useful
simply because they are not effective against DDoS (for instance, they
are not meant to!). (not that I am arguing in favor of the converse,
necessarily)

> unreachable vs host / port unreachable vs admin prohibited vs ...)?

That depends on a number of factors. Among others, how those prefixes
are assigned, and whether the ICMPv6 responses are actually allowed.

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Dec 2010 19:48:04 -0300

On 22/12/2010 06:46 a.m., Merike Kaeo wrote:

> I so wish people understood that.  I am constantly dealing with folks
> deploying networks who 'trust' being behind a NAT.  

My take is that the trust doesn't come from the "topology hiding" thing,
but rather from the fact that, indirectly, a NAT-PT ends up being a
stateful firewall with a policy of "only allow return traffic for
connections initiated from the inside".

Thanks!

Kind regards,

---

From: Fred Baker <[email-masked]>
Date: Wed, 22 Dec 2010 17:53:38 -0800

> connections initiated from the inside".

If they're using NAT-PT, we know their first problem.

No, a NAT is not the same as a stateful firewall. Reason: it *has* no policy. People confuse a NAT and a stateful firewall because a NAT only creates dynamic state in one direction. If you were running NAT-PT, though, it would create state in both directions, and draft-ietf-behave-v6v4-xlat doesn't even create state.

I can RST (Reset) your TCP connection through a NAT *or* a stateful firewall if I know a few particulars about your transmissions. Give me your pseudo-header (source/destination address/port and the fact that you're using TCP) and three numbers from your TCP header, and I can tell you that your peer has closed its window (set window=0), RST the connection, or several other things. All it requires is that my ISP not have BCP 38 turned on. Neither your NAT nor your firewall can tell the difference between my attack-o-gram and the real thing. And by bombarding your NAT, I can with some probability hit an open connection I don't know the details of if I know enough about your habits.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Dec 2010 23:53:26 -0300

Hi, Fred,

On 22/12/2010 10:53 p.m., Fred Baker wrote:
>> My take is that the trust doesn't come from the "topology hiding"
>> thing, but rather from the fact that, indirectly, a NAT-PT ends up
>> being a stateful firewall with a policy of "only allow return
>> traffic for connections initiated from the inside".
> 
> No, a NAT is not the same as a stateful firewall. Reason: it *has* no
> policy. 

It acts as a stateful firewall where all outgoing connections (i.e.,
originated from the inside) are allowed. You can have a stateful
firewall (with no NAT-PT functionality) that implements the same policy
(with no translation, though, obviously).

> People confuse a NAT and a stateful firewall because a NAT
> only creates dynamic state in one direction. 

I'm referring to the v4 NAT-PT.

> I can RST (Reset) your TCP connection through a NAT *or* a stateful
> firewall if I know a few particulars about your transmissions. 

And what? -- Firewalls are not meant to protect you against those threats.

> Give
> me your pseudo-header (source/destination address/port and the fact
> that you're using TCP) and three numbers from your TCP header, and I
> can tell you that your peer has closed its window (set window=0), RST
> the connection, or several other things.

You're asking a bit too much (in some scenarios, at least). In practice,
this requires that you are on-link, and/or that the TCP implementation
is really dumb (e.g. predictable ports and ISNs, etc.).

> All it requires is that my
> ISP not have BCP 38 turned on. Neither your NAT nor your firewall can
> tell the difference between my attack-o-gram and the real thing. And
> by bombarding your NAT, I can with some probability hit an open
> connection I don't know the details of if I know enough about your
> habits.

In order to hit a connection, you need to be able to guess a valid seq
number. That *might* be possible... but I don't think that's the type of
threat model for e.g. a home user.

As mentioned before, if there's a new 0-day that affects Windows that's
based e.g. on a crafted ICMP echo request, a NAT would prevent a node on
the Internet from nuking your home computer.

Is this all you need? Most likely, no. Does this provide *some*
protection (e.g., against the aforementioned attack)? -- I'd argue that
it does....

Thanks!

Kind regards,

---

From: Erik Kline <[email-masked]>
Date: Wed, 22 Dec 2010 19:24:08 -0800

> protection (e.g., against the aforementioned attack)? -- I'd argue that

I disagree.  It's not the N.A.T. function per se of a NAT device that
prevents this.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Dec 2010 00:42:33 -0300

> I disagree.  It's not the N.A.T. function per se of a NAT device that

Agreed. But it's the NAT box, and you cannot split the NAT-PT from this
functionality.

That's why I said that a NAT-PT ends up being operating as a stateful
firewall *indirectly*. -- i.e. it's not the NAT function per-se that
prevents the unsolicited packets from traversing the NAT, but the fact
that, as they are unsolicited, the NAT doesn't have a mapping for them,
and hence is not able to translate-and-forward them to the internal realm.

However, this is purism for us. For the user, what matters is what the
box accomplishes.

Thanks!

Kind regards,

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 23 Dec 2010 10:43:01 +0100

<>start<>
but the fact
that, as they are unsolicited, the NAT doesn't have a mapping for them,
and hence is not able to translate-and-forward them to the internal
realm.
<>end<>

Isn't this just identical what a stateful traffic filter (reflexive
access-list 
in Cisco speak) achieves? No need to have NAT for that.

G/

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Dec 2010 12:33:13 -0300

On Thu, Dec 23, 2010 at 6:43 AM, Gunter Van de Velde (gvandeve)
<[email-masked]> wrote:

> access-list in Cisco speak) achieves?

That's *exactly* the point... and the reason for which people probably
associate "NATs" with "security": they achive with NATs what they
could achieve with a stateful traffic filter.

> No need to have NAT for that.

Agreed. But since they use NATs "to share their Internet connection",
the converse is true, too: since they have a NAT, they don't need a
traffic filter (to achieve such a simple filtering policy).

Thanks!

Kind regards,
Fernando

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 23 Dec 2010 16:53:05 +0100

<>start snip<>

<>end snip<>

Two things get confused here.... 

1a) the functionality of the address translation to assist sharing an IP
address
1b) the security the simple reflexive Access filter provides
2) is confused with the fact that (1) and (2) do not provide 'real'
security in case of actual treat

The stateful filter can in theory be turned on by a simple click-box, so
it is simple.
Stateful filter will not solve the problem of address sharing for sure.

G/

---

From: Fernando Gont <[email-masked]>
Date: Sun, 26 Dec 2010 03:28:29 -0300

Hi,

> security in case of actual treat

This explanation is indeed confusing ;-)

Anyway, please see my other post on this thread about how a NAPT ends up
providing what you seem to be referring to as "reflexive filter".

Thanks,

---

From: Toru Kuboshiki <[email-masked]>
Date: Tue, 28 Dec 2010 07:54:23 +0900

Thanks for many opinions.

I could hear different opinions about network topology hiding and NAT security.

I intend to study hard and figure out an appropriate result.

Regards.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 27 Dec 2010 15:04:59 -0800

> I intend to study hard and figure out an appropriate result.

Please let let us know when you find one (and I don't mean that in jest).

Thanks
joel