NAT etc. (was: Spam Control Considered Harmful)

Mailman List Mirror (Read Only)
1

Havard said:

> ...which brings me to think if it isn't so that Secure DNS (at
> least as currently specified) and widespread deployment of NAT
> boxes which fiddle with the contents of DNS reply/request packets
> isn't exactly a properly working combination. As I understand it
> you can have NAT or Secure DNS with e.g. signed A records but you
> can't (easily?) have both.

This is a misdirected concern. DNS clients inside a NAT cloud are
already proscribed from seeing DNS data from other NAT clouds or from
the Internet itself. The NAT technology has to strip off DNSSEC stuff
when it imports data but it tends to strip off DNS delegation and
authority data as well, and tends to alter the address and mail exchange
records. NAT borders are already DNS endpoints, with or without DNSSEC.
Whether and how to regenerate external DNS inside a NAT cloud is a matter
of NAT implementation, but the fact that it's _regenerated_, not forwarded
or recursed, is a design constant.

  (While I have replied to Paul, this raving is for everyones
  general amusment. - bill)

  I think this is correct. However, this line of thinking
  when seen in the light of end2end IPSEC seems to indicate that
  NAT/Firewall technologies mandate a regenerated security
  "envelope" at the NAT/Firwall edge. This tends to be what
  corporations/governments want, while others tend toward
  the endpoints being indivdually oriented. I, for one, (and
  I expect I'm in the minority here) don't want to hand my keys
  over to BBSS, Sprint, GTE, WCOM, the FBI, the Governement of
  France... so they can decrypt the packets that I am sending
  to you.

  So, while I agree that NAT/Firewall techniques are an approch
  to dealing with heirarchy/scaling issues, I think that MJR
  was right. NAT/Firewalls are bandaids to be used until we have
  reasonable endsystem/endsystem IP security.

  If you really buy off on the catanet arguement, then there is
  no need to reuse IP. FIDOnet, TCP on PPPover(mediaofchoice),
  DECnet adnausa are available and you win with application transparency.

  Jumping through all those hoops to make NATs work "seamlessly"
  is a glittering bauble. Lots of interesting knots to go untangle
  as folks rework and undo one of the basic assumptions behind IP
  which is a single, common addressing space. And its really an
  admission of failure.

  Too many people saying, "Its too hard to make true end2end work,
  (even across the existant IP (thats IPv4 for you Sean) space) so
  we must carve it up into tiny bits that each party can claim as
  their very own."

  Buying into NATs dooms people to live in thier private hells.
  
  Embrace Brigadoon.

--bill

2

[ On Sat, November 1, 1997 at 13:14:35 (-0800), bmanning@isi.edu wrote: ]

Subject: Re: NAT etc. (was: Spam Control Considered Harmful)

  Buying into NATs dooms people to live in thier private hells.

Yes, exactly. It might work for some people, for some applications, for
some period of time, but it's not the right solution for a long term
open Internet.

3

  Jumping through all those hoops to make NATs work "seamlessly"
  is a glittering bauble. Lots of interesting knots to go untangle
  as folks rework and undo one of the basic assumptions behind IP
  which is a single, common addressing space. And its really an
  admission of failure.

  Buying into NATs dooms people to live in thier private hells.

Bill's comments are dramatically on point. If you lived through the DECNET
Phase 4 address translators of the day (HEPNET et al), you will recall the
massive splintering of the DECNET world that resulted from a violation of
one simple assumption: predictible end to end connectivity resulting from
a single, semantically consistent address space. Area boundary translators
of the day (now called NATs) are and were at best stopgaps. Many of us who
aggressively eliminated phase 4 from the backbones of the day did so due
to the massive operational headaches resulting from the NAT's violation of
the end to end reachability and least surprises principle. In fact, I
often thought the death of phase 4 was dramatically accelerated by this
very issue.

Trying to find ways to better automate these translators is just yet
another constraint to the application developer and network operator,
similar to unusual or unexpected proprietary application gateways.
Eventually, it becomes too costly or complicated. And something else is
put into place.

Looking practically at this problem, many voices have called out loudly
about the issues of developing routers capable of simpling switching the
current and future traffic levels. Now, we hear suggestions of inter-ISP
NATs that must look at every single packet, transform it without error,
regenerate security, routing, transport and checksum information, and do
it all at wire speed. These views are incompatible and irreconcilable.

I would suggest that address renumbering technology is not identically
equal to the protocol conversion problem. Renumbering is a triggered event
whose administration can be automated at any layer of the topology.
Protocol conversion happens for potentially every packet, all the time.
Its impact is widespread across all facets of architecture, application
and infrastructure. And I personally have never seen it work seamlessly,
despite multitudes of generations of attempts. Protocol conversion is the
ugly child of the datacom world. Lets not build it into the design of the
Internet by intent.

I believe the end to end argument has driven much of the success and
value of the global Internet. Its worth preserving as an architectural
principle.

Eric Carroll
Tekton Internet Associates