Re: NAT etc. (was: Spam Control Considered Harmful)
Security based on IP address.
Here I disagree, not only for the obvious reason that forgery is easy, but also because basing anything on IP address that does not involve looking back up through the DNS (which is also not yet safe) is incompatible with NAT.
...which brings me to think if it isn't so that Secure DNS (at least as currently specified) and widespread deployment of NAT boxes which fiddle with the contents of DNS reply/request packets isn't exactly a properly working combination. As I understand it you can have NAT or Secure DNS with e.g. signed A records but you can't (easily?) have both. (Which brings us even further afield from the original subject... ;-) Regards, - Håvard
[ I just removed these addresses: Havard.Eidnes@runit.sintef.no smd@clock.org peter@wonderland.org jlewis@inorganic5.fdt.net paulp@winterlan.com ...from the recipient list, since I know they are all on NANOG. I would not be offended by each of the above people thanking me publically for not making them see two copies of this reply. Perhaps that would set some kind of an example for the rest of the audience, most of whom just say "reply-all". ] Havard said:
...which brings me to think if it isn't so that Secure DNS (at least as currently specified) and widespread deployment of NAT boxes which fiddle with the contents of DNS reply/request packets isn't exactly a properly working combination. As I understand it you can have NAT or Secure DNS with e.g. signed A records but you can't (easily?) have both.
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.
Havard said:
...which brings me to think if it isn't so that Secure DNS (at least as currently specified) and widespread deployment of NAT boxes which fiddle with the contents of DNS reply/request packets isn't exactly a properly working combination. As I understand it you can have NAT or Secure DNS with e.g. signed A records but you can't (easily?) have both.
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.
(While I have replied to Paul, this raving is for everyones general amusment. - bill) I think this is correct. However, this line of thinking when seen in the light of end2end IPSEC seems to indicate that NAT/Firewall technologies mandate a regenerated security "envelope" at the NAT/Firwall edge. This tends to be what corporations/governments want, while others tend toward the endpoints being indivdually oriented. I, for one, (and I expect I'm in the minority here) don't want to hand my keys over to BBSS, Sprint, GTE, WCOM, the FBI, the Governement of France... so they can decrypt the packets that I am sending to you. So, while I agree that NAT/Firewall techniques are an approch to dealing with heirarchy/scaling issues, I think that MJR was right. NAT/Firewalls are bandaids to be used until we have reasonable endsystem/endsystem IP security. If you really buy off on the catanet arguement, then there is no need to reuse IP. FIDOnet, TCP on PPPover(mediaofchoice), DECnet adnausa are available and you win with application transparency. Jumping through all those hoops to make NATs work "seamlessly" is a glittering bauble. Lots of interesting knots to go untangle as folks rework and undo one of the basic assumptions behind IP which is a single, common addressing space. And its really an admission of failure. Too many people saying, "Its too hard to make true end2end work, (even across the existant IP (thats IPv4 for you Sean) space) so we must carve it up into tiny bits that each party can claim as their very own." Buying into NATs dooms people to live in thier private hells. Embrace Brigadoon. --bill
[ On Sat, November 1, 1997 at 13:14:35 (-0800), bmanning@isi.edu wrote: ]
Subject: Re: NAT etc. (was: Spam Control Considered Harmful)
Buying into NATs dooms people to live in thier private hells.
Yes, exactly. It might work for some people, for some applications, for some period of time, but it's not the right solution for a long term open Internet. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Jumping through all those hoops to make NATs work "seamlessly" is a glittering bauble. Lots of interesting knots to go untangle as folks rework and undo one of the basic assumptions behind IP which is a single, common addressing space. And its really an admission of failure.
Buying into NATs dooms people to live in thier private hells.
Bill's comments are dramatically on point. If you lived through the DECNET Phase 4 address translators of the day (HEPNET et al), you will recall the massive splintering of the DECNET world that resulted from a violation of one simple assumption: predictible end to end connectivity resulting from a single, semantically consistent address space. Area boundary translators of the day (now called NATs) are and were at best stopgaps. Many of us who aggressively eliminated phase 4 from the backbones of the day did so due to the massive operational headaches resulting from the NAT's violation of the end to end reachability and least surprises principle. In fact, I often thought the death of phase 4 was dramatically accelerated by this very issue. Trying to find ways to better automate these translators is just yet another constraint to the application developer and network operator, similar to unusual or unexpected proprietary application gateways. Eventually, it becomes too costly or complicated. And something else is put into place. Looking practically at this problem, many voices have called out loudly about the issues of developing routers capable of simpling switching the current and future traffic levels. Now, we hear suggestions of inter-ISP NATs that must look at every single packet, transform it without error, regenerate security, routing, transport and checksum information, and do it all at wire speed. These views are incompatible and irreconcilable. I would suggest that address renumbering technology is not identically equal to the protocol conversion problem. Renumbering is a triggered event whose administration can be automated at any layer of the topology. Protocol conversion happens for potentially every packet, all the time. Its impact is widespread across all facets of architecture, application and infrastructure. And I personally have never seen it work seamlessly, despite multitudes of generations of attempts. Protocol conversion is the ugly child of the datacom world. Lets not build it into the design of the Internet by intent. I believe the end to end argument has driven much of the success and value of the global Internet. Its worth preserving as an architectural principle. Eric Carroll Tekton Internet Associates
[ I removed Bill from the CC list so that he will only get one copy of this; it would have been very nice to have seen Bill remove me from the CC list of his earlier reply, so that I would only have seen one copy of THAT. ]
I think this is correct. However, this line of thinking when seen in the light of end2end IPSEC seems to indicate that NAT/Firewall technologies mandate a regenerated security "envelope" at the NAT/Firwall edge. This tends to be what corporations/governments want, while others tend toward the endpoints being indivdually oriented. I, for one, (and I expect I'm in the minority here) don't want to hand my keys over to BBSS, Sprint, GTE, WCOM, the FBI, the Governement of France... so they can decrypt the packets that I am sending to you.
I don't expect that France will ever move into private address space. I do expect WCOM and GTE and the FBI to each do so for their internal networks, and then I expect the NAT boxes between their private networks and the public network to unwrap all the security goo (checking it using keys which are all public inside the addressing domain they came out of) and regenerate it for the far side (again using keys which are meaningful and available in the addressing domain they are being sent into.) This means personal certificates can work, i.e., PGP and to some extent SSH. It means DNSSEC can work. I don't know what it means for IPsec but if IPsec can't be used this way then it will fail in the marketplace. As I kept telling the IETF when I used to attend their meetings, the market does what it feels like doing and the way to appear to lead it is to predict motion and then run out in front of the crowd in that direction. This goes back to the same old descriptive/prescriptive thing Padlipsky was talking about.
So, while I agree that NAT/Firewall techniques are an approch to dealing with heirarchy/scaling issues, I think that MJR was right. NAT/Firewalls are bandaids to be used until we have reasonable endsystem/endsystem IP security.
The key to understanding private addressing is that each addressing domain (which is any private one, or the public one), is an addressing universe unto itself. It has to have its own root name servers. It has to have its own DNS keys. User level certificates a la PGP and sort-of SSH can be shared between multiple addressing domains, but network level certificates like DNS cannot. This can be a bug or a feature depending on your point of view. More in a moment, Jay A. has asked a marvelous bracketing question about this.
On Sat, Nov 01, 1997 at 12:34:13PM -0800, Paul A Vixie wrote:
Havard said:
...which brings me to think if it isn't so that Secure DNS (at least as currently specified) and widespread deployment of NAT boxes which fiddle with the contents of DNS reply/request packets isn't exactly a properly working combination. As I understand it you can have NAT or Secure DNS with e.g. signed A records but you can't (easily?) have both.
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. The point is that you _can't_ regenerate the signature, usefully to the client, anyway, precisely because _it is a signature_. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
[ 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.
On Sat, Nov 01, 1997 at 03:49:37PM -0800, Paul A Vixie wrote:
[ 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. :-)
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 -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
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
On Sun, Nov 02, 1997 at 11:12:50PM -0500, Alan Hannan wrote:
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 -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
:: 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@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
This is it: my last message on this thread. This will be the third time I have tried to explain the answer to "why NAT doesn't break DNSSEC" and this is now the point where I feel I must sure as hell be "wasting my time and annoying the pig" as R.A.H. once said.
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.
The DNS data from one IPspace is not relevant or useful in any other IPspace. The name servers, mail servers, and addresses you get back will all have to pass through a NAT before they will be usable in the "other" IPspace. If you are in a nonoverlapping IPspace (in both addresses and names) then the names won't have to be translated and in that sense you'd be justified in letting the MX RR's be visible to the other-space clients. The NS RRs are all wrong, though, since they are part of an alternative-universe DNSspace (with its own root name servers, whose delegation chain may be different than the one you follow). And of course the A RRs are suspicious since they refer to addresses you cannot reach in any normal sense. If your packets ever reach those addresses it will be with translated source addresses and NAT-border forwarders to get you your responses back, but it's more likely that your packets will NOT reach the destination but will rather terminate at the NAT-border and be processed at the application layer, with application layer regeneration on the other side. In no case can a DNS response generated by a host in some IPspace be seen in its original glory by some host in some _other_ IPspace. What a querier will hear is "whatever the NAT wants it to hear" which will be "whatever it takes to get the job done for the end-user". This means you could ask for the MX RRset for VIX.COM and while the "real" answer (in VIX.COM's IPspace) is: VIX.COM. IN MX 0 GW.HOME.VIX.COM. GW.HOME.VIX.COM IN A 192.5.5.1 you might get back either: VIX.COM. IN MX 0 GW.HOME.VIX.COM. GW.HOME.VIX.COM IN A 10.0.0.53 or VIX.COM. IN MX 0 NAT-MX.YOU. NAT-MX.YOU. IN A 10.0.0.53 Given this serious disconnect between the truth and what you have to hear in order to keep you sane and reachable, it rather follows that the DNSSEC data in the original (correct, truthful) DNS response has to be processed by the NAT (which as a NAT-border has "sight" in both IPspaces) and verified and so on, and then if DNSSEC is in use in the querier's IPspace (which is shared by one side of the NAT box and by the rootish name servers in that IPspace) then new (faked but consistent and verifiable) DNSSEC signatures have to be made. Clean? No. But neither is NAT. What it can be is: effective and secure. And: the idea of forwarding NS RRs of _any_ kind is just right out.
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.
Sean's current stated thesis seems to be that ISP's can operate NAT boxes. And for captive accounts like old-AOL and old-Compuserve and old-MSN that is absolutely right. However, in the new generation ISPs who offer IP/PPP to their users, this won't work, and precisely for the reason you stated. But I disagree with the implication that ISP's have to offer NAT in order for NAT and IPv4 to succeed. Ford Motor Company, Digital Equipment Corporation, and Sony Corporation of America all have Class A networks and they are NOT ISP's. They no more allow external IP to reach their desktop then they would allow unshielded plutonium to reach their desktops. THOSE are the places that have to run NAT -- they already have tight firewalls, and new companies building what 1997 calls an "intranet" generally feel that NAT makes them more secure anyway. These people ain't buying the end-to-end arguments, they want their users to be secure and effective and they don't think Pee Cees can be made so. If someone replies to me personally on this thread I will answer. I'm done reading NANOG for a few days, I'll check back when I think this discussion is dead and gone.
participants (8)
-
Alan Hannan -
bmanning＠ISI.EDU -
Brett Frankenberger -
Eric M. Carroll -
Havard.Eidnes＠runit.sintef.no -
Jay R. Ashworth -
Paul A Vixie -
woods＠most.weird.com