ietf
[Top] [All Lists]

Re: draft-ietf-nat-protocol-complications-02.txt

2000-04-22 02:50:03
    > From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>

    > there are far too many problems to NAT, affecting far too many
    > applications ... and the list is constantly growing larger.

Perhaps if there was a document that explained how to design an application
so that it worked through a NAT box, the list might not be growing so quickly?

Although I wouldn't want to be the person to write such a document, since
they're going to have to wade through hordes of flak from people who seem to
convinced that if they just flame enough about how worthless NAT boxes are,
and how they ought to be banned/exterminated, NAT boxes will go away. ("Back,
tides!")


We could also contemplate the possibility of producing fixes for old things
that NAT boxes break, but on the record so far, I'm not very sanguine.

(The enquiring mind wonders why this isn't happening - but doesn't have to
look too far. In addition to the usual IETF problem of too many problems and
too few people, there's the other camel in the tent, to whit - whose ox will
be gored if we make NAT boxes work better? And who will be the big losers if
we don't make NAT work better - why, the users, of course. But who cares
about them?)

For a classic example, look at the recommendations of the IAB Workshop last
year about IPSEC (and I'll asssume for the moment that IPSec is important to
securing the Internet, and stay away from the debates about IPSEC versus SSL,
etc):

   It is urgent that we implement and deploy IPsec using some other
   identifier than 32-bit IP addresses ... The current IPsec specifications
   support the use of several different Identity types (e.g. Domain Name,
   User(_at_)Domain Name). ... We strongly urge the IETF to completely
   deprecate the use of the binary 32-bit IP addresses within IPsec
   ... in particular any IP address dependencies should be eliminated from
   ISAKMP and IKE. Ubiquitous deployment of the Secure DNS Extensions ([8])
   should be strongly encouraged to facilitate widespread deployment of IPsec
   (including IKE) without address-based Identity types.

So, has any of this happened? AFAIK, no; I may be wrong, but I don't recall
seeing anything about either deprecating use of address-based identities, or a
fix to IKE/etc to remove all address dependencies.  Sure, everyone's busy, but
has anyone in the IAB/IESG/etc been tasked with making this happen?

The really ironic thing about this particular case is that people who want to
deploy IPv6 would probably benefit from this particular fix, too. Right now,
as far as I can tell (sorry, it's been a while since I looked at this, and the
details made my eyes glaze over), a number of the different IPv4<->IPv6
interoperability tools don't work with IPSec, both because of the use of
address-based identities, and address dependencies in IKE. Removing these
dependencies might allow IPSec to work in IPv4<->IPv6 interactions.

But has anything happened here? Nope. Can't do anything to make NAT boxes
work better, can we?


Even more radically, we could start requiring that new stuff works through
NAT boxes. What a concept!

While to an objective observer that might seem like a fairly reasonable step,
given how widely NAT boxes are deployed, G-d forbid we do anything so
rational. I mean, who cares if we screw over the users, that's their own
fault for not realizing how tasteless NAT is.

Damn the users, full steam ahead!

        Noel