Date: Sat, 1 Nov 1997 17:37:57 -0500
From: "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us>
To: "You're welcome" <nanog@merit.edu>
Subject: Re: NAT etc. (was: Spam Control Considered Harmful)
[...]
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.
The point is that you _can't_ regenerate the signature, usefully to the
client, anyway, precisely because _it is a signature_.
Presumably, the NAT could,
o Verify the signature of the DNS responses it receives, and
dump any responses that don't meet its [authentication]
criteria, or
o Sign the the response it creates and let the client verify
the NAT's signature. Presumably, the client will trust
the NAT.
-tjs
Does anyone know if ANS, digex, mci etc.
provide communities that encompass their internal/customer routes?
If certain ones don't, is there any reason that they
have against such a community?
Thanks.
BR
Bradley Reynolds
breynolds@iagnet.net
Internet Access Group
Yup, it could, but as I noted to Paul, in the cases Sean is advocating,
the client and the NAT box may not be within the same span of
administration, either. IE: no, you may _not_ trust the NAT op.
Cheers,
-- jra
Yup, it could, but as I noted to Paul, in the cases Sean is advocating,
the client and the NAT box may not be within the same span of
administration, either. IE: no, you may _not_ trust the NAT op.
In today's internet, the DNS management, the routing
administration, and the ADM engineer are all outside of central
administration.
This is analagous to the case you bring up, and yet we work well.
Proxy aggregation of address space occurs, and yet the world goes
on.
That the NAT administration would be different from that of the
flow endpoints is orthagonal to the discussion.
Perhaps you mean that the client won't know where to go because
the information is changed. Well, yes, that's what NAT does.
Send it to an agent aware of the change, or reference that
modulation, and it will come together.
-a
No, I'm afraid I don't think that's true. This is a question of
_trust_, and if I don't wish to allow the operator of a NAT box to
proxy my trust in a nameserver operator, there really isn't any good
way around that.
Cheers,
-- jra
"Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> writes:
This is a question of _trust_, and if I don't wish to
allow the operator of a NAT box to proxy my trust in a
nameserver operator, there really isn't any good way
around that.
You could change your connectivity such that there is no
NAT between you and the set of nameservers from which you
feel you must have untouched responses.
In a "NAT Everywhere" world with a sufficiently large set
of such nameservers this may be completely impractical.
Given that not trusting the DNS is the default mode of
operation for the current Internet, the question is
whether the advantages of NAT justify a constraint on
DNSSEC or whether the advantages of DNSSEC justify a
constraint on NAT.
The problem seems simpler with a "NAT in some places"
model, especially where "some places" is mostly at
the borders of big corporations, however strings of NATs
do and will happen, and there will be these trust issues
to deal with in some places anyway.
I would perfer to avoid constraining the problem just
because it makes the NIMBY folks more quiescent, to be
honest, since it rankles as much the concept of "only some
people have to renumber to conserve address space and
preserve the scalable properties of hierarchical routing.
we won't, we're privileged (or too big or too understaffed)".
Like renumbering, NAT is out there, and making it seamless
and easy strikes me as a good and useful goal, even if it
complicates other good and useful goals.
One of the ways to make it and renumbering seamless is to
understand that IP addresses are subject to change over
time and topological distance.
Sean.
Wel, yes... <sigh>, but as I've noted before, that's an assumption that
the current design of the Internet does _not_ require.
Cheers,
-- jra