Subject: Re: The Devil's in the Deployment RE: NATs as firewalls

From: [email-masked] (Noel Chiappa)
Date: Sun, 4 Mar 2007 16:36:47 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    > the problems that NAT causes, and that having suffcient address space
    > (a.k.a. IPv6) solves

This comment seems to posit that insufficient address space is the only thing
driving deployment of NATs (other than the modestly effective firewalls that
NAT provides), and that's just not correct.

Until the IETF fully understands and appreciates the forces which are driving
the deployment of NAT boxes - which have been spectacularly successful in the
marketplace, far more so than the purported official alternative - they will
continue to eclipse said purported official alternative.

        Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 05 Mar 2007 09:32:09 +1100

> continue to eclipse said purported official alternative.

	* lack of address space
	* to avoid of renumbering (high perceived cost)
	* stateful firewall
	* having internal addresses that are meaningless on the outside

	Now IPv6 gives you the address space.

	We have lots of mechanisms now, if people were willing to
	deploy them, they ease the cost of renumbering.  e.g. DHCP,
	stateless autoconf, DNS, secure DNS UPDATE, DNS DNAME, support
	for multiple prefixes at the lower levels.  Yes, more work
	could be done to ease the costs of renumbering.  Most of
	that however is vendor specific at this stage.
	
	We have stateful firewalls.
	
	We have IPv6 Locally Assigned Local Addresses.

	The biggest problem is IPv4 mindset, with NAT being just one
	example of it.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Mar 2007 07:39:56 +1100

> Doesn't this presume that if people used these locally assigned
> addresses they would then NAT to a public address space?

	No.  Locally Assigned Local Addresses are for talking to
	other machines within the locally assigned realm/scope.
 
> I think the main thing folks might miss is that a lot of people really
> want all of this on a single address--while having multiple addresses
> concurrent on a single machine is acceptable for larger machines,
> specifically servers, having multiples on a single host as a general
> rule hasn't met with much in the way of acceptability for the vast
> majority of hosts.

	Most people really don't care what address a machine has.
	They basically only ever use it as a client machine. You
	don't need fixed addresses for these machines.  You just
	need a address that can reach the servers you want to
	talk to.

	You then have the few servers.  For these you decide what
	clients they serve and give them addresses to match.  These
	addresses along with relevent ports for the services they
	are offering make it into firewalls, etc.

	Servers are also clients so they also use the same techiques
	as pure clients when choosing the address they use to initiate
	connections.

> At least that's what I'm hearing.
> 
> :-)
> 
> Russ
> 
> 
> - --
> [email-masked] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF7CNVER27sUhU9OQRAqf0AKCZuM30XPZO5SUYkFKpuueq3q/MIQCg/5k1
> TeUcUHxrrjd755ovY1cG1/E=
> =i0+D
> -----END PGP SIGNATURE-----

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Mar 2007 07:39:56 +1100

---

From: Russ White <[email-masked]>
Date: Mon, 05 Mar 2007 09:04:05 -0500

I think the main thing folks might miss is that a lot of people really
want all of this on a single address--while having multiple addresses
concurrent on a single machine is acceptable for larger machines,
specifically servers, having multiples on a  =
since the entities involved in the 802.11i 4-way handshake are, I think, =
quite different from the EAP entities.&nbsp; In general, the =
consumers/users of the keys that may be generated as a side-effect of =
EAP authentication are not identical to the EAP entities, however, a =
fact that seems to be if not lost then at least glossed over in this =
document.&nbsp; Further&nbsp; examples can be found in the definitions =
of &quot;Transient EAP Keys (TEKs)&quot;, where the EAP peers are =
presumed to continue sending &amp; receiving encrypted data after =
authentication is complete(!) and &quot;Transient Session Keys =
(TSKs)&quot;, where the EAP peers negotiate a ciphersuite for this =
purpose.&nbsp; Although I don't think it's prohibited for EAP methods to =
negotiate ciphersuites for subsequent use _by other protocols_ (such as =
802.11i, etc.), I don't know of any that do &amp; I don't think that =
that is what is meant in this definition: it is only the rather IMHO =
sloppy use of the terms &quot;authenticator&quot; and &quot;peer&quot; =
to mean, basically, &quot;whatever is hanging off the ends of the =
wire&quot; that allows this usage.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01C75E3E.929A9595--

--===============0938587276==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--===============0938587276==--

---

From: Russ White <[email-masked]>
Date: Mon, 05 Mar 2007 09:04:05 -0500

</BODY>
</HTML>

---

From: Russ White <[email-masked]>
Date: Mon, 05 Mar 2007 09:04:05 -0500

</BODY>
</HTML>

---

From: Russ White <[email-masked]>
Date: Mon, 05 Mar 2007 09:04:05 -0500

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Tue, 06 Mar 2007 13:06:19 -0500

> 	need a address that can reach the servers you want to

I disagree--people don't care what the specific address is, but they
have specific requirements about the number and types of addresses on
those machines, even down to the individual host.

We often conflate these two types of requirements.

:-)

Russ