NAT etc. (was: Spam Control Considered Harmful)

Mon Nov 3 04:48:34 UTC 1997

:: Jay R. Ashworth writes ::
> 
> The problem on point is that NAT cannot interoperate with DNSSEC.
> 
> That the DNSSEC chains on each side of a NAT box are clean is
> immaterial, because *the DNS server and the NAT box are, by definition,
> not within the same span of administrative control*.
> 
> If I'm the client asking that DNSSEC server about something, I want
> _it's_ authentication.  I may not be willing to trust my NAT box's
> operator, so the fact that _he_ signs it is immaterial to me.

In the current world, we have Router Operators between users and
servers, and those Router Operators have to be trusted.  Those
same organizations would be running NAT boxes in the Brave New World
of NAT in the backbone.  So putting NAT in the backbone doesn't really
mandate that you trust anyone else.

Let's suppose you query on "www.webserver.com" and get back an A record
with IP address 11.22.33.44, with a compeltely valid set of signatures. 
Then, assuming you trust the security of the DNSSEC model, you know
with a high degree of confidence that the owner of the webserver.com
domain claims that the IP address of www.webserver.com is 11.22.33.44. 
But it makes no claims that if you send a packet to 11.22.33.44, that
packet will route where the owner of webserver.com thinks it will.  In
fact, that packet will route wherever the owners of the routers between
you and 11.22.33.44 want it to route.  So you've got to trust them,
even without NAT.

DNSSEC can be enhanced to reflect that trust:

In a NAT + DNSSEC world, suppose that Sprint maintains a NAT between
themselves and MCI.  And that, rather than translating information in
DNSSEC packets, they append signed translation information.  Assume you
want to connect to WWW.X.COM.  Your DNS query could return with:
   WWW.X.COM (A record) 22.33.44.55 (signed by company X)
   22.33.44.55 (NAT's to) 33.44.55.66 (signed by Sprint)
(The first line came from X's DNS.  The second line was added by
Sprint's NAT box.)

You can tell from that that you should send your connection
request to 33.44.55.66.  In order to do that, you have to trust
Sprint's claim that they will translate 33.44.55.66 to 22.33.44.55, but
remember, even in the non-NAT world, you were already trusting Sprint. 
(Distribution of Sprint's public key, and the public keys of all other
NAT box operators, would have to occur somehow, and that's almost
certainly non-trivial, but also almost certainly doable.)

In short, NAT would break DNSSEC is its current incarnation, but the
problems could be fixed, and DNS in a NAT world could be made as secure
as DNSSEC currently is in a non-NAT world.

I still don't like NAT in the backbone, though.

          - Brett  (brettf at netcom.com)

------------------------------------------------------------------------------
                               ... Coming soon to a      | Brett Frankenberger
.sig near you ... a Humorous Quote ...                   | brettf at netcom.com