NAT etc. (was: Spam Control Considered Harmful)

Mailman List Mirror (Read Only)
1

[ I removed "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> from the CC list of
  this message after noting that he had been kind enough to remove me from
  the CC list of his mail. After this I will stop publically noting it when
  someone does the polite thing, i.e., doesn't CC me on mail to the list, and
  just twang this string when someone does the impolite thing, i.e., does CC
  me on mail to a list that they know I'm on. ]

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

Well, yes, Paul, but unless I misunderstood you, that's exactly the
point. If a client inside a NAT cloud does a DNS lookup to a
supposedly authoritative server outside, and the NAT box is _required_
to strip off the signature (which it would, because it has to change
the data), then it's not possibile, by definition, for any client
inside such a NAT box to make any use of SecDNS.

I think I may have been too easily misunderstandable, so I won't fault your
interpretation other than to say that since the folks inside a NAT are in a
separate addressing domain and therefore have their own "root" name servers,
the certification chain for DNSSEC is entirely valid, and entirely separate,
within each NATspace.

The point is that you _can't_ regenerate the signature, usefully to the
client, anyway, precisely because _it is a signature_.

And the client, and its NAT box, and their root name servers, are all very
consistent and share all of their keys and Everything Just Works. What's
going on here is that when you tell your interior clients how to find their
interior root name servers, you have to tell them the interior root DNS key
(the public one that is). If your NAT box is advanced enough to intercept
DNS to external root name servers and redirect it toward interior ones so
that the clients can all be configured as if they were normal (public) DNS
clients, then your internal net can't use DNSSEC. Depending on the size of
your organization, internal DNS validity checking may not have been the
reason you wanted to use DNSSEC anyway -- most of us are concerned about the
data which comes from _outside_ our networks.

2

[ I removed "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> from the CC list of
  this message after noting that he had been kind enough to remove me from
  the CC list of his mail. After this I will stop publically noting it when
  someone does the polite thing, i.e., doesn't CC me on mail to the list, and
  just twang this string when someone does the impolite thing, i.e., does CC
  me on mail to a list that they know I'm on. ]

I use Mutt, and I'm about to propose to them a new "reply" key which
notes that one of the addresses on a reply you're about to send is a
list you've defined, and weeds the headers appropriately.

IE: you're welcome, Paul. :slight_smile:

> > 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.
>
> Well, yes, Paul, but unless I misunderstood you, that's exactly the
> point. If a client inside a NAT cloud does a DNS lookup to a
> supposedly authoritative server outside, and the NAT box is _required_
> to strip off the signature (which it would, because it has to change
> the data), then it's not possible, by definition, for any client
> inside such a NAT box to make any use of SecDNS.

I think I may have been too easily misunderstandable, so I won't fault your
interpretation other than to say that since the folks inside a NAT are in a
separate addressing domain and therefore have their own "root" name servers,
the certification chain for DNSSEC is entirely valid, and entirely separate,
within each NATspace.

They're in a separate _IP_ addressing domain.

They are _not_, in the cases Sean advocates using NAT for, in a
separate _DNS_ addressing domain/namespace.

And that's exactly the problem.

DNS provides mapping between names and IP addresses. NAT provides
mapping between IP addresses in one domain, and IP addresses in a
different domain. DNSSEC provides authentication that a particular
reply from a particular DNS server in fact actually came from that
server.

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.

> The point is that you _can't_ regenerate the signature, usefully to the
> client, anyway, precisely because _it is a signature_.

And the client, and its NAT box, and their root name servers, are all very
consistent and share all of their keys and Everything Just Works. What's
going on here is that when you tell your interior clients how to find their
interior root name servers, you have to tell them the interior root DNS key
(the public one that is). If your NAT box is advanced enough to intercept
DNS to external root name servers and redirect it toward interior ones so
that the clients can all be configured as if they were normal (public) DNS
clients, then your internal net can't use DNSSEC. Depending on the size of
your organization, internal DNS validity checking may not have been the
reason you wanted to use DNSSEC anyway -- most of us are concerned about the
data which comes from _outside_ our networks.

Precisely, which is why the fact that NAT and DNSSEC will not
interoperate -- they _can't_, by design (not that such design was
purposeful; it was unavoidable) -- is so important to understand.

Does anyone wish to correct me? I'm a pretty decent thinker, but it's
possible I may misunderstand some specifics, I'm _not_ a DNSSEC or NAT
mechanic.

Cheers,
-- jr '"marvelous"? Thanks, Paul' a

3

Does anyone wish to correct me? I'm a pretty decent thinker, but it's
possible I may misunderstand some specifics, I'm _not_ a DNSSEC or NAT
mechanic.

  I am not intimate with the internals of DNSSEC to comment on the
  interoperability with NATs at this time.

  As such, I wouldn't question your assertion. I do, however,
  question this premise as being directly relevant to the
  advancement of NAT use in the internet infrastructure.

  It is likely that the scaling properties of the internet
  will demand a change in the lower level protocols.

  When this happens, the higher layer protocols (like DNSSEC) will
  have to be reworked.

  So DNSSEC gets broken. Fix DNSSEC after we fix the
  infrastructure.

  With NAT you can subdivide the network to many orders of growth.
  The sum work saved by doing this vastly outweighs the work
  required to adapt DNSSEC.

  For example, the root name system could interoperate with the NAT
  machines in a controlled manner. No, it's not a trivial task.
  However, isn't it easier than renumbering the entire address space
  and putting more space into the problem?

  -a

4

> Does anyone wish to correct me? I'm a pretty decent thinker, but it's
> possible I may misunderstand some specifics, I'm _not_ a DNSSEC or NAT
> mechanic.

  I am not intimate with the internals of DNSSEC to comment on the
  interoperability with NATs at this time.

  As such, I wouldn't question your assertion. I do, however,
  question this premise as being directly relevant to the
  advancement of NAT use in the internet infrastructure.

Well, let's look at that.

  It is likely that the scaling properties of the internet
  will demand a change in the lower level protocols.

  When this happens, the higher layer protocols (like DNSSEC) will
  have to be reworked.

  So DNSSEC gets broken. Fix DNSSEC after we fix the
  infrastructure.

  With NAT you can subdivide the network to many orders of growth.
  The sum work saved by doing this vastly outweighs the work
  required to adapt DNSSEC.

Well, I don't know as where that's necessarily true, and as I noted in
a private reply to someone else on this, there's a trend to make
fundamental architectural changes in the net with, I think, too little
attention to how many assumptions will get broken, there.

An analogy is in order here.

A few years back, someone had the bright idea that tires, which are
incredibly difficult to recycle effectively, might be well used as
filler in manufacturing asphalt to pave roads.

Apparently, however, insufficient testing was performed... as the roads
started _catching on fire_.

Changes as fundamental as breaking the assumptions currently safe about
end-to-end connectivity and routability in something as pervasive and
mission critical as the Internet Backbone (ie: the collective capacity
of the 26 or so current commercial and government backbones) merit
_extensive_ real-world testing.

  For example, the root name system could interoperate with the NAT
  machines in a controlled manner. No, it's not a trivial task.
  However, isn't it easier than renumbering the entire address space
  and putting more space into the problem?

Not necessarily. What would be required here would be for a given
nameserver to query a NAT server for the appropriate translation, put
_that_ address is it's response, and sign the result, avoiding the
necessity of the layer 3 NAT box to poke into the layer 4 DNS response.

And, of course, then the DNS server is professing to be authoritative
for the NAT server... and trust isn't necessarily commutative.

I agree with Paul; we've dragged this out about as far as it will go;
let's adjourn further discussions to the NOD list, shall we?

Cheers,
-- jra