Subject: (NAT) Re: Last Call: DNS extensions to Network Address Translators (DNS_ALG) to Informational

From: Andrew Brown <[email-masked]>
Date: Fri, 7 May 1999 12:52:26 -0400

>> in spite of its effects on dnssec, this draft as a whole strikes me as
>> the wrong answer to a problem.  since dns doesn't actually use ip
>> addresses in it's transport in order to function (unlike ftp), this
>> seems to me to be a completely unnecessary and, in fact, damaging
>> document.
>> 
>> unless i don't understand the problem that's being addressed here.
>
>This document is about how you translate IP addresses in DNS payloads so
>you can access a remote DNS server through a NAT and get back locally-valid
>IP addresses in its reply.

well then, if you're talking about changing the addresses in dns
responses, then that's just a bad idea.  it will probably completely
break dnssec functionality, since the signatures on answers will no
longer be verifiable.  dns responses should not be changed in transit.

what does "locally valid ip addresses" mean?

if you have machines behind a nat device that need to access hosts on
the outside of the nat, then the nat should be remapping the ip
traffic on the way in and out of the nat.  dns service should be fine
as it exists without any tampering by the nat.

if you have machines that are behind a nat device that are asking for
the addresses of machines outside the nat, but you want to redirect
them to machines inside the nat, then the machines on the inside need
to be reconfigured, not the nat.  either that, or you need an internal
dns server to do answering and forwarding for the machines inside the
nat.

if you have machines inside the nat that answer dns queries and you
want those machines to be able to answer questions (and perhaps
provide other services) from outside the nat, those machines should be
outside the nat in the first place, but with a much higher security
stance.

>(If you want to continue this thread, I encourage you to do so on the
> NAT WG mailing list, [email-masked])

cc added.  :)

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 9 May 1999 08:52:21 -0700 (PDT)

> longer be verifiable.  dns responses should not be changed in transit.

Andrew -  Have you actually read the draft? Do let us know if your concern 
is not addressed in section 7 of the draft.

> what does "locally valid ip addresses" mean?

To give an example, 10.0.0.1 could be a locally valid IP address within my 
private enterprise, but not externally. For NAT terminology, you need to 
refer the draft <draft-ietf-nat-terminology-02.txt>

> as it exists without any tampering by the nat.
Yes.

> to be reconfigured, not the nat.  

I have no idea where are you are going with this. The draft does not
talk about this scenario. 
>                                   either that, or you need an internal

Have you looked at section 2 of draft? 

> > NAT WG mailing list, [email-masked])

cheers,
suresh
-

---

From: Andrew Brown <[email-masked]>
Date: Sun, 9 May 1999 16:24:51 -0400

>is not addressed in section 7 of the draft.

i have.  and now again, only much more carefully and with a yellow
magic marker.  :)

section 7 does make note of the draft's effect on dnssec.  it
basically admits to breaking it.  if you're trying to improve security
by using firewalls and internal and external name servers and a dmz,
dnssec ought not to be something you deliberately break.

>refer the draft <draft-ietf-nat-terminology-02.txt>

i've read that too.  the term just seems to be a little misplaced.

>> as it exists without any tampering by the nat.

yet the draft seems to me to be describing how the response ought to
be altered.

>talk about this scenario. 

it is difficult for me to see exactly what you are attempting to fix
with this draft.  i was just trying to cover all (as i could see it)
possible configurations.

>Have you looked at section 2 of draft? 

yep.  that's where the meat of it is.  :)

hosts visible to the external world should not be behind a nat.  if
they are, then the nat will have to give them static addresses that it
can map to, so that "outsiders" can make connections from the external
world.  the nat itself should not be remapping the source address on
an inbound connection, only the destination address so that the
connection can be established.

i still can't tell from the draft though, what exactly is is that
you're trying to fix or change.

perhaps should try to summarize what i see and you can tell me where
i'm wrong?

i'm not trying to be annoying...i'm just trying to understand
something that makes no sense to me.  and also seems be a little
(imho) misguided.

ps - stylistically, you should probably not be using "external.com"
and "private.com" in your examples.  perhaps outside.example.com and
internal.example.com would be better.

---

From: Randy Bush <[email-masked]>
Date: Sun, 9 May 1999 13:32:00 -0700 (PDT)

> dnssec ought not to be something you deliberately break.

are you aware of in the middle address translations which do not break
dnssec?  if not, where does this path lead which is useful?

randy
-

---

From: Andrew Brown <[email-masked]>
Date: Sun, 9 May 1999 16:36:15 -0400

>dnssec?  if not, where does this path lead which is useful?

um...no?  i'm not quite following your question...

and what path?  mine?

---

From: Randy Bush <[email-masked]>
Date: Sun, 9 May 1999 13:44:12 -0700 (PDT)

as it seems to be a given that nat in the middle breaks dnssec, let us
presume that it is known that this draft will not work with dnssec.  given
that it even admits to this, we might be looking at the draft's other
attributes.

randy
-

---

From: Andrew Brown <[email-masked]>
Date: Sun, 9 May 1999 16:51:00 -0400

>that it even admits to this, we might be looking at the draft's other

it does?  i wasn't aware.  i thought that nat was only supposed to
rewrite internal addresses, not external ones as well.

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 May 1999 07:02:19 -0700 (PDT)

> it does?  i wasn't aware.  

Yes, it does. 

>                            i thought that nat was only supposed to

That depends on the NAT type. Twice-NAT  will rewrite both.

cheers,
suresh
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 May 1999 08:00:30 -0700 (PDT)

> i have.  and now again, only much more carefully and with a yellow
OK. Thanks.

> dnssec ought not to be something you deliberately break.
As Randy mentioned in another e-mail, the draft admits to breaking dnssec. 

> i've read that too.  the term just seems to be a little misplaced.
Where in particular?

> yet the draft seems to me to be describing how the response ought to

Andrew - the problem is that your use of NAT terminology is unclear.
I assumed you meant Basic-NAT, when you refered NAT. Hence, my response 
was specifically in the context of Basic-NAT. Refer - sections 3.3, 5.1, 5.2

But, if you are refering to twice-NAT or another type of NAT, they are addressed
as well in the draft.

> with this draft.  i was just trying to cover all (as i could see it)

DNS_ALG helps translate Name-to-Private-Address mapping in DNS payloads
into Name-to-external-address mapping and vice versa using state
information available on NAT.

> world. 

That is an approach. I have no problems with that.

>         the nat itself should not be remapping the source address on
That is exactly what Twice-NAt does. 

> something that makes no sense to me.  and also seems be a little

I understand. Let me give it another try to summarize. 

Say, you make the assumption that host names (i.e., FQDN) must be end-to-end 
unique in order for end nodes to communicate with each other. In such a  case, 
multiple private routing realms with the same address space can exist, so long 
as their names are unique.

DNS-ALG, in conjunction with NAT  helps facilitate such a communication
from private realms.

cheers,
suresh
-

---

From: Andrew Brown <[email-masked]>
Date: Mon, 10 May 1999 13:58:49 -0400

>> >that it even admits to this, we might be looking at the draft's other

can you tell me, briefly, how it does this?  the actual source address
of a dnssec reply should not affect the validation of the response.
only the altering of its contents would do that.

>That depends on the NAT type. Twice-NAT  will rewrite both.

nat is supposed to be transparent from the external viewer's point of
view.  isn't it?  so it ought not to matter if there are zero, one, or
two nats (or more, i suppose) between any two service points.

---

From: Andrew Brown <[email-masked]>
Date: Mon, 10 May 1999 14:33:06 -0400

>As Randy mentioned in another e-mail, the draft admits to breaking dnssec. 

it still shouldn't be doing so.  admitting that you are breaking
something is not the same as not breaking it.

>> i've read that too.  the term just seems to be a little misplaced.

perhaps "misplaced" is the wrong word.  but there's no specific
mention of "locally" valid ip addresses in the nat terminology draft,
so i was confused.

>was specifically in the context of Basic-NAT. Refer - sections 3.3, 5.1, 5.2

my use of nat terminology stems from my use of such, not from having
written some drafts (note: *not* putting down your efforts here) or
experiencing the particular problem you are trying to solve here.

>But, if you are refering to twice-NAT or another type of NAT, they
>are addressed as well in the draft.

i'm just trying to get a picture in my mind of the problem that this
draft is addressing.

>information available on NAT.

and why does the nat not use dyndns to update the dns master server so
that dns_alg becomes unnecessary?

>That is exactly what Twice-NAt does. 

so nat-dns-02 deals with how the twice-nat should rewrite dns
responses that it processes so as to make it appear that "it" is the
entire internet?

>> perhaps should try to summarize what i see and you can tell me where

(oops.  i meant "i".  and the summary.  sorry.  :)

>Say, you make the assumption that host names (i.e., FQDN) must be
>end-to-end unique in order for end nodes to communicate with each
>other. In such a case, multiple private routing realms with the same
>address space can exist, so long as their names are unique.
>

...so that my machine ("andrew.ex", behind a nat) numbered 10.0.0.1
can talk to your machine ("suresh.ex", also behind a nat) which is
also numbered 10.0.0.1 and either party can establish the connection,
because i can attempt to connect out to your "public" address on the
outside of your nat, or vice versa.

so nat-dns-02 provides a means for andrew.ex to look up your nat's
external address (or the external address it gave to suresh.ex) and
get back a response that says suresh.ex instead of nat.suresh.ex.

so why can't this all be kept in a dns server as it's configured?

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 May 1999 13:26:59 -0700 (PDT)

> only the altering of its contents would do that.

Why do you continue to refer dnssec in conjunction with Twice-NAT?

> view.  isn't it?  

Yes.

>                   so it ought not to matter if there are zero, one, or

Twice-NAT is not two NATs.  Please refer <draft-ietf-nat-terminology-02.txt>
for the definition of Twice-NAT.

cheers,
suresh
-

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 May 1999 13:48:23 -0700 (PDT)

> something is not the same as not breaking it.

I still dont understand what you want me to do about it.

> mention of "locally" valid ip addresses in the nat terminology draft,

An IP address can be valid within a local realm, but may not be so, outside
the realm. Ex: RFC1918 addresses are not globally unique.

> experiencing the particular problem you are trying to solve here.
NAT terms are defined in the "NAT Terminology and considerations" draft
just so everyone can be on the same page. I would appreciate if you would 
use the terms from that draft, rather than simply use the nat term as a 
catch-all - unless, of course, the statements are applicable to all flavors 
of NAT.

> that dns_alg becomes unnecessary?

Because, Name to address mapping must be changed only for hosts outside
the private realm. The mapping remains unchanged for hosts within
the private realm.

Yes.

> outside of your nat, or vice versa.
Sure.

> get back a response that says suresh.ex instead of nat.suresh.ex.
Sure.

> so why can't this all be kept in a dns server as it's configured?

The DNS server is configured keeping just one routing realm in mind
(say, private.example.com) and expects the IP addresses to be uniquely
assigned to hosts within that realm.  DNS-ALG comes into the picture 
when the service is extended to hosts outside that realm.

cheers,
suresh
-

---

From: Andrew Brown <[email-masked]>
Date: Mon, 10 May 1999 17:47:51 -0400

>Why do you continue to refer dnssec in conjunction with Twice-NAT?

i'm not saying nat that much, and i certainly didn't mention twice-nat
(which i've never seen used).  my point is that simply altering the
the source address of the dnssec response with a simple nat gateway
(ie, one that does not attempt to alter the contents of the dns
response) would not break dnssec.  only one that alters the contents
will.

>> nat is supposed to be transparent from the external viewer's point of

so why do you have to rewrite the contents of the dns response?  and
how does twice-nat satisfy the concept of "transparency"?

>for the definition of Twice-NAT.

4.3. Twice NAT

   Twice NAT is a variation of NAT in that both the source and
   destination addresses are modified by NAT as a datagram crosses
   routing realms. This is in contrast to Traditional-NAT and
   Bi-Directional NAT, where only one of the addresses (either source
   or destination) is translated. Note, there is no such term as
   'Once-NAT'.

yes.  you're right.  of course.  but that's another issue.  if nat-dns
is just being developed to support twice-nat, how is nat-dns supposed
to know what to change and what not to change?

ps - are all these nat technologies that you have defined being used
somewhere?  or does that draft just attempt to delineate all the
possible nat uses that you could come up with?

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 10 May 1999 15:04:51 -0700 (PDT)

> response) would not break dnssec.  only one that alters the contents

Agreed. 

NAT alters the IP header and DNS-ALG alters the DNS payload.
DNS-ALG alters the DNS payload whenever the payload contains addresses 
that are invalid from the view point of the receiver.

In the case of dnssec, the DNS server signs the records, as appropriate
to the realm for which the DNS server is configured. The assumption is 
that the addresses signed by dnssec may not be valid outside the realm.
Hence the need for DNS-ALG intervention.

> to know what to change and what not to change?
DNS-ALG described in the draft accomodates all flavors of NATs.
DNS-ALG must know the flvaor of NAT it is working with.

> possible nat uses that you could come up with?

There are products in the market, based on these technologies. 
DNS-ALG is also implemented in some of these products.

cheers,
suresh
-

---

From: Andy Heffernan <[email-masked]>
Date: Mon, 10 May 1999 15:05:45 -0700

[...]
> possible nat uses that you could come up with?

Most or all of the stuff described in this draft has been deployed in
customer networks to solve real problems for at least two years, if
memory serves, so the paper is documenting existing practice.  Since
NAT in its various forms breaks the end-to-end model of the Internet,
we readily concede that technologies that rely on this model can be
broken by NAT.

It is unfortunate that this happens, but it IS happening.
-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.