RE: Where NAT disenfranchises the end-user ...
|> From: Charles Sprickman [mailto:spork@inch.com] |> Sent: Thursday, September 06, 2001 9:16 PM |> On Thu, 6 Sep 2001, Roeland Meyer wrote: |> > To be honest, even though I've used NAT myself and have |> implemented NAT for |> > friends and clients, I would NEVER represent that a NAT'd |> address has the |> > full connectivity to the Internet that a static address does. |> |> True... neither does a well-firewalled LAN. There is a substantial difference between broken access and controlled access.
On Thu, 6 Sep 2001, Roeland Meyer wrote:
|> True... neither does a well-firewalled LAN.
There is a substantial difference between broken access and controlled access.
Yes, but there are plenty of apps that will not work if you do not leave open large, arbitrary ranges of udp ports. This is fundamentally incompatible with most sane firewalls. Or NAT. Why write a protocol that way? Just to prove NAT sucks? Charles
|> True... neither does a well-firewalled LAN.
There is a substantial difference between broken access and controlled access.
Yes, but there are plenty of apps that will not work if you do not leave open large, arbitrary ranges of udp ports. This is fundamentally incompatible with most sane firewalls. Or NAT.
Why write a protocol that way? Just to prove NAT sucks?
Charles
No, because they were either written before NAT existed and tried hard to conform to the end2end principles of Internet Architecture or they were written after NAT existed and tried hard to conform to the end2end principles of Internet Architecture. NAT violates the end2end principles of the Internet Architecture by placing one or more policy abstraction layer(s) between the endpoints. That said, NAT is a tool in the tool box. I'd like to think that its worth the effort to try and recover true end2end. --bill
It seems a pretty simple argument to me. Do I want as many people using (and maybe _buying_, what a concept!) my app as possible with the least amount of network clue and setup headaches, or do I want to eliminate most of the corporate, SOHO, cable, DSL, Linux population because I cant be bothered to develop my app to be NAT-friendly. Duh! All the previous times this discussion has arisen here, I have concluded that "real" IPs should only be owned and used by folks with clue, everyone else gets a NATed IP. Discuss. jm
|> True... neither does a well-firewalled LAN.
There is a substantial difference between broken access and controlled access.
Yes, but there are plenty of apps that will not work if you do not leave open large, arbitrary ranges of udp ports. This is fundamentally incompatible with most sane firewalls. Or NAT.
Why write a protocol that way? Just to prove NAT sucks?
Charles
No, because they were either written before NAT existed and tried hard to conform to the end2end principles of Internet Architecture or they were written after NAT existed and tried hard to conform to the end2end principles of Internet Architecture.
NAT violates the end2end principles of the Internet Architecture by placing one or more policy abstraction layer(s) between the endpoints.
That said, NAT is a tool in the tool box. I'd like to think that its worth the effort to try and recover true end2end.
--bill
-- jon_mansey@verestar.com Chief Science Officer ------------------------------------------------------------------ Verestar Networks, Inc. http://www.verestar.com 1901 Main St. tel (310) 382 3300 Santa Monica, California 90405 fax (310) 382 3310 ------------------------------------------------------------------
On Fri, 07 Sep 2001 10:26:02 PDT, Jon Mansey <jon_mansey@verestar.com> said:
All the previous times this discussion has arisen here, I have concluded that "real" IPs should only be owned and used by folks with clue, everyone else gets a NATed IP. Discuss.
There are those who would argue that you just disenfranchised every user that connects via <insert list of top 10 access providers here>. On the other hand, you *DID* just solve the address space problem - since we know that the majority of dialup users are clueless, and the majority of .com's are lame too, the average ISP should be able to get by with just 10 or 15 IP addresses and NAT everybody behind those. That's like saying "You're only allowed to direct-dial your phone if you know how many volts are between the red and green wires, and what it's there for - everybody else has to ask the operator for assistance". Cross out "operator" and put in "NAT", and that's your proposal..... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
On Fri, Sep 07, 2001 at 02:02:57PM -0400, Valdis.Kletnieks@vt.edu pontificated:
That's like saying "You're only allowed to direct-dial your phone if you know how many volts are between the red and green wires, and what it's there for - everybody else has to ask the operator for assistance".
Cross out "operator" and put in "NAT", and that's your proposal.....
fortunately, we don't need a hyoomun to translate every packet - if we had s/operator/automated non-human directory assistance/ I'd go along with your allegory. :)
-- Valdis Kletnieks Operating Systems Analyst Virginia Tech
-- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m UNIX | IP networks | security | sysadmin | caffeine | BOFH | general geekery GPG public key 0xCB33CCA7 illum oportet crescere me autem minui
Sez you. As you design you app, please consider how many NATs the packets must traverse and what each may do to your packets while in flight (without telling you squat) before they reach the intended destination (and for that matter, how do you tell when you've arrived?) NAT designers mess with MTU, headers, and even the data. By the time the packets "reach" the intended receipient, they're not even mine anymore. But that is a comforting thought. Plausable Deniability. "No UrHonour, I never sent that. It did not come from my machine." Again, NAT is a tool. Where it makes sense to share fate, impose random policy, and (oh yeah) save some slots in Friend Bushes routing table, NAT is your friend. :Random Ob: Flip NAT over, use RFC 1918 space as the "global" address space and run everything else "inside" as private space. This may be the "poison pill" that solves the apparent routing table problems if the IRTF & IESG can't solve the problems for us in time. --bill (needing more sleep)
It seems a pretty simple argument to me.
Do I want as many people using (and maybe _buying_, what a concept!) my app as possible with the least amount of network clue and setup headaches, or do I want to eliminate most of the corporate, SOHO, cable, DSL, Linux population because I cant be bothered to develop my app to be NAT-friendly.
Duh!
All the previous times this discussion has arisen here, I have concluded that "real" IPs should only be owned and used by folks with clue, everyone else gets a NATed IP. Discuss.
jm
|> True... neither does a well-firewalled LAN.
There is a substantial difference between broken access and controlled access.
Yes, but there are plenty of apps that will not work if you do not leave open large, arbitrary ranges of udp ports. This is fundamentally incompatible with most sane firewalls. Or NAT.
Why write a protocol that way? Just to prove NAT sucks?
Charles
No, because they were either written before NAT existed and tried hard to conform to the end2end principles of Internet Architecture or they were written after NAT existed and tried hard to conform to the end2end principles of Internet Architecture.
NAT violates the end2end principles of the Internet Architecture by placing one or more policy abstraction layer(s) between the endpoints.
That said, NAT is a tool in the tool box. I'd like to think that its worth the effort to try and recover true end2end.
--bill
jon_mansey@verestar.com Chief Science Officer ------------------------------------------------------------------ Verestar Networks, Inc. http://www.verestar.com 1901 Main St. tel (310) 382 3300 Santa Monica, California 90405 fax (310) 382 3310 ------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Why write a protocol that way? Just to prove NAT sucks?
Charles
No, because they were either written before NAT existed and tried hard to conform to the end2end principles of Internet Architecture or they were written after NAT existed and tried hard to conform to the end2end principles of Internet Architecture.
NAT violates the end2end principles of the Internet Architecture by placing one or more policy abstraction layer(s) between the endpoints.
That said, NAT is a tool in the tool box. I'd like to think that its worth the effort to try and recover true end2end.
What is "true end2end"? I just want to understand what that means. NAT rewrites certain packet data fields (src addr, src port, sometimes mac addr). So does a ordinary router (ttl decrement). One breaks end2end, the other does not. What is the difference? I think you will find that a definition of "end2end" is a lot more squishy than you want it to be.
--bill
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO5kKJUksS4VV8BvHEQLP/ACgovrim/k0P2vyogKbozKUUUMnKPAAnRZs n7zCvrBAaT1aN47YEQMZg3+3 =GOFQ -----END PGP SIGNATURE-----
On Fri, 7 Sep 2001, Mike Batchelor wrote:
NAT rewrites certain packet data fields (src addr, src port, sometimes mac addr). So does a ordinary router (ttl decrement). One breaks end2end, the other does not. What is the difference?
I think you will find that a definition of "end2end" is a lot more squishy than you want it to be.
Actually I think It's very simple... in a world were potentially any device can be a tcp based server the fredom to connect to it regardless of what network it's behind is critical... if all my devices are on different networks, behind different nats connecting between them becomes very hard... if we have for example, my cell phone behind a nat at my cell provider, my home computer, behind my home nat because my provider will only give me one ip, and my home nat behind my provider nat, because my provider doesn't have enough v4 address space, how do I initiate a connection between my cell phone and my home-computer, or vice-versa, if we add a third device, my laptop sitting behind a broadband wireless providers nat how do I interconnect them, that fact that they're all ip enabled has in fact bought me squat. end-to-end is the freedom to initiate a connection between any two tcp enabled devices. something which some of us take for granted in the ip world, but which is being rapidly eroded. joelja -- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.
I seem to be able to connect to port-forwarded services behind my office NAT firewall just fine from my laptop behind my home NAT box. Whats the problem? jm At 11:25 AM -0700 9/7/01, Joel Jaeggli wrote:
On Fri, 7 Sep 2001, Mike Batchelor wrote:
NAT rewrites certain packet data fields (src addr, src port, sometimes mac addr). So does a ordinary router (ttl decrement). One breaks end2end, the other does not. What is the difference?
I think you will find that a definition of "end2end" is a lot more squishy than you want it to be.
Actually I think It's very simple... in a world were potentially any device can be a tcp based server the fredom to connect to it regardless of what network it's behind is critical... if all my devices are on different networks, behind different nats connecting between them becomes very hard... if we have for example, my cell phone behind a nat at my cell provider, my home computer, behind my home nat because my provider will only give me one ip, and my home nat behind my provider nat, because my provider doesn't have enough v4 address space, how do I initiate a connection between my cell phone and my home-computer, or vice-versa, if we add a third device, my laptop sitting behind a broadband wireless providers nat how do I interconnect them, that fact that they're all ip enabled has in fact bought me squat.
end-to-end is the freedom to initiate a connection between any two tcp enabled devices. something which some of us take for granted in the ip world, but which is being rapidly eroded.
joelja
-- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.
On Fri, 7 Sep 2001 11:56:31 -0700 Jon Mansey <jon_mansey@verestar.com> wrote:
I seem to be able to connect to port-forwarded services behind my office NAT firewall just fine from my laptop behind my home NAT box. Whats the problem?
when you try and use an IPSec client to connect through a NAT box to a corporate IPSec appliance, you'll see a problem (unless the client and box are using an agreed upon proprietary solution, which some do.) richard -- Richard Welty Averill Park Networking rwelty@averillpark.net 518-573-7592
On Fri, Sep 07, 2001 at 10:55:49AM -0700, Mike Batchelor wrote:
NAT rewrites certain packet data fields (src addr, src port, sometimes mac addr). So does a ordinary router (ttl decrement). One breaks end2end, the other does not. What is the difference?
NAT rewrite more than that, try reading http://www.cisco.com/warp/public/cc/pd/iosw/ioft/ionetn/prodlit/1195_pp.htm In particular, it rewrites addresses _in the data portion of the packet) for the following protocols: ICMP, FTP, NetBIOS, RealAudio, CuSeeMe, DNS, Netmeeting, H.323, PPTP and several others. That's what makes it violate the end2end principal, your _data_ is changed by NAT. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Sep 07, 2001 at 10:55:49AM -0700, Mike Batchelor wrote:
NAT rewrites certain packet data fields (src addr, src port, sometimes mac addr). So does a ordinary router (ttl decrement). One breaks end2end, the other does not. What is the difference?
NAT rewrite more than that, try reading http://www.cisco.com/warp/public/cc/pd/iosw/ioft/ionetn/prodlit/11 95_pp.htm
In particular, it rewrites addresses _in the data portion of the packet) for the following protocols:
ICMP, FTP, NetBIOS, RealAudio, CuSeeMe, DNS, Netmeeting, H.323, PPTP and several others.
That's what makes it violate the end2end principal, your _data_ is changed by NAT.
Well of course, that was my point. Where do you draw the line? The packet as received is not identical to the packet as it was sent, even when NAT is not involved. Along the way, various things get modified, the packet is encapulated, unwrapped, re-encapsulated, TTLs get decremented, ... all things that are necessary and part of the process of getting the packet to its destination. NAT just has more necessary things to change. I'm not defending NAT, I dislike it as much as the next clueholder, I am just taking the devil's advocate position for the sake of discussion.
-- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO5kYlEksS4VV8BvHEQJ5nQCfUlQrmIDUO8dbGrGfoVztMjv1rZEAn0xz a7Fr2Bw2UtP2W4CNgL5UjHuw =LHb7 -----END PGP SIGNATURE-----
On Fri, Sep 07, 2001 at 11:57:24AM -0700, Mike Batchelor wrote:
Well of course, that was my point. Where do you draw the line? The packet as received is not identical to the packet as it was sent, even when NAT is not involved. Along the way, various things get modified, the packet is encapulated, unwrapped, re-encapsulated, TTLs get decremented, ... all things that are necessary and part of the process of getting the packet to its destination. NAT just has more necessary things to change. I'm not defending NAT, I dislike it as much as the next clueholder, I am just taking the devil's advocate position for the sake of discussion.
Encapsulation does not modify the encapsulated packet. It just sends a new packet that happens to have a data portion which can be interpreted by the remote end as being a packet which it should forward from there. TTL decrement A) was intended to be rewritten on a per-packet basis, by design, and B) is not identity information in any fashion. Please name one part of a "normal TCP connection" (IE, without anything in between but, say, some copper wire and ethernet NICs carrying IP directly, and a router or two doing straight per-hop forwarding) which both gets rewritten, and has *any* form of identity, or for that matter, wasn't explicitly intended to be rewritten per-hop by the origional spec. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://www.lightbearer.com/~lucifer
On Fri, Sep 07, 2001 at 11:57:24AM -0700, Mike Batchelor wrote:
Well of course, that was my point. Where do you draw the line? The packet as received is not identical to the packet as it was sent, even when NAT is not involved. Along the way, various things get modified, the packet is encapulated, unwrapped, re-encapsulated, TTLs get decremented, ... all
It violates a layering principal. An application never 'creates' a packet (particularly when thinking about TCP). Thus the application doesn't pick the initial TTL, for instance. So there's no reason the application should expect it to be a particular value at the end. An application very much creates it's own data stream, and expects a reliable transport scheme to pass it _unaltered_. Note, NAT can cause issues here. If I run a telnet server on port 53, telnet to it through a NAT gateway, and send data that looks like an AXFR, it will probably change it, thinking it's operating on DNS. That's pretty dangerous. It also crosses an interesting legal line. If your an ISP customer and it's ok for the ISP to read your data stream and alter it in real time to provide NAT, why wouldn't it be legal for them to read your e-mail in real time as it passes, and alter what you said? The same boxes could do it. What makes it ok to alter an IP address here and there, but not alter a word? Why are they different? -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
On Fri, 7 Sep 2001, Leo Bicknell wrote:
It also crosses an interesting legal line. If your an ISP customer and it's ok for the ISP to read your data stream and alter it in real time to provide NAT, why wouldn't it be legal for them to read your e-mail in real time as it passes, and alter what you said? The same boxes could do it. What makes it ok to alter an IP address here and there, but not alter a word? Why are they different?
Leo, let's not get crazy here. One is content, the other a content-delivery mechanism. Think about the post office. It's perfectly acceptable for them to stamp a forwarded address on the envelope to ensure it's delivery, but perfectly unacceptable to modify the content inside. I know you're being facetious, but come on... Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Fri, Sep 07, 2001 at 05:09:43PM -0400, Andy Dills wrote:
One is content, the other a content-delivery mechanism. Think about the post office. It's perfectly acceptable for them to stamp a forwarded address on the envelope to ensure it's delivery, but perfectly unacceptable to modify the content inside.
But NAT goes further. Consider if the post office opened up your letter, looked at the return address on it, saw that was wrong and stuck the new one on it, put it back in the envelope and then sent it on its way. That's exactly what NAT does with some protocols. I have no problem with people using NAT, and I have used it myself. Specifically, I don't my the {IP,port} translation basic NAT does. Yes, it breaks some protocols, but as long as that's known it's ok. I have a big problem with the data modification of more recent NAT implementations. It does have some interesting implication as to who can modify data as well. If a device in the middle has license to modify data in the middle of a data stream, what are the limits of that license? If my service provider uses NAT without my consent can I sue them for reading/changing my data? If not, why would I be able to sue them if they do the same thing to e-mail? What is the difference? -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
But NAT goes further.
well, the distinction between delivery information and content (not to mention their layering in the packet itself) is pretty clear with most protocols. to be more clear, if there were an encrypted data transmission protocol that you wanted to use, you could expect that the content of the packet (the data portion of the packet) wouldn't be modified -- it would make it impossible for the recipient to decrypt -- but that some of the delivery information (source addr/port, dest addr/port) might be modified, say, by your ISP if it were to their (and perhaps even your) advantage. so if your packet travels from your box to the remote box that you intend, you should be happy. the content is unmodified, it got there, you probably don't care terribly much about the path it took (as long as it got there quickly enough), or even whether any of the non-data portions of the packet were rewritten. the only time NAT should (and does, really) rewrite the data portion of the packet is if the protocol includes intended delivery information in the data portion of the packet. since NAT will keep your packet from getting from point A to point B in that case, it rewrites only the portions of the packet needed to keep parties at A and B communicating merrily along. i'm sure that an ISP you threatened with legal action for modifying your data would be perfectly happy to leave the data portion untouched, but then your protocol might not work so well. when you write a protocol, regardless of the application, that tries to make requirements _in the data portion_ about how the remote side should write its _header portion_, you really are asking for trouble. anyone that wants these protocols to work over firewalls is going to have to explain to the world where to look in the packet for the appropriate information, and is going to have to expect that it's likely to be rewritten. the same goes for NAT. setting up a server of any kind behind a NATted address isn't impossible -- and if the protocol requires header information to be specified in the data portion of the packet, they need to let people know how to rewrite it so that it can merrily move from point A to point B. imagine that, say, a TCP-based protocol for delivering email specified the _route_ that it required a packet to take in the data portion of the packet. or that the data portion required that the return packet have a particular breed of frame wrapped around it. i don't think that many ISPs would find this reasonable, because those decisions are typically left up to the ISP to make. NAT != evil, so let's try to be a little bit more evenhanded about this. anytime you try to compensate for a limited resource, you're going to have to make sacrifices. the main sacrifice i can see with NAT, really, is that people who want to write protocols need to make sure that they get the word out about anything in the data portion (or in the protocol itself) that places restrictions upon headers in the packet. and the understanding that if there are such restrictions, it might be a little while (i.e. until all NAT implementations everywhere plug in a handler for the new protocol in question) before all networks in the world are going to be able to pass their packets around with ease and zen-like harmony. is that really so much to ask? s.
steve uurtamo wrote:
when you write a protocol, regardless of the application, that tries to make requirements _in the data portion_ about how the remote side should write its _header portion_, you really are asking for trouble.
Explain how to build a protocol for the following: A -| |-Nat-<>-C B -| A wants to tell C how to contact B for a multi-party app. A 'knows' the address of B, so why should it require C to take several seconds to look it up by name? Even if C were to look up the name, it would map back to A as far as C is concerned, so C might not go into multi-party mode because it has one name and single matching locator.
NAT != evil, so let's try to be a little bit more evenhanded about this.
NAT is just a technology, so your statement is arguably true. As long as the end user has elected NAT as the tool for solving the current problem, he accepts the associated drawbacks. The evilness appears when humans get involved and NAT is forced on the end user. This could either explicitly, or (to be truly evil) unannounced by the service provider, while at the same time claiming that they are selling Internet service. (This is the point that started the original thread)
and the understanding that if there are such restrictions, it might be a little while (i.e. until all NAT implementations everywhere plug in a handler for the new protocol in question) before all networks in the world are going to be able to pass their packets around with ease and zen-like harmony. is that really so much to ask?
Actually it is. It is equivalent to insisting that my PI prefix be distributed globally. From an end user perspective there is no reason a little pain on the ISPs part should prevent me from having continuous connectivity through full prefix announcement multi-homing. Yet ISPs are fat-&-happy pointing out that developers should never require a protocol to carry locator information in the data stream. There are reasons to do it, so it is incumbent on the service providers that enforce NAT to be straight with their customers about the fact the service is not full capability transparent Internet access. Tony
On Fri, 7 Sep 2001, Leo Bicknell esoterically agitated:
It does have some interesting implication as to who can modify data as well. If a device in the middle has license to modify data in the middle of a data stream, what are the limits of that license? If my service provider uses NAT without my consent can I sue them for reading/changing my data? If not, why would I be able to sue them if they do the same thing to e-mail? What is the difference?
You can sue whoever you want, for whatever you want, whenever you want. Can you show damages in the situation of email? Yes. With packets? No. And before you come back at me with some crazy convoluted contrived scenario, let's just realize how far off the beaten path we are at this point. If your ISP is going to force you to use NAT, "against your will", get a new fricking provider. For that matter, what ISP NATs you against your will? What, do you wake up the next morning with a sore router, feeling ashamed and hurt, telling yourself you should have known better, and wondering where you should go first: the hospital or the police? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Fri, Sep 07, 2001 at 07:50:05PM -0400, Andy Dills wrote:
On Fri, 7 Sep 2001, Leo Bicknell esoterically agitated:
It does have some interesting implication as to who can modify data as well. If a device in the middle has license to modify data in the middle of a data stream, what are the limits of that license? If my service provider uses NAT without my consent can I sue them for reading/changing my data? If not, why would I be able to sue them if they do the same thing to e-mail? What is the difference?
You can sue whoever you want, for whatever you want, whenever you want.
Can you show damages in the situation of email? Yes. With packets? No. And before you come back at me with some crazy convoluted contrived scenario, let's just realize how far off the beaten path we are at this point. If your ISP is going to force you to use NAT, "against your will", get a new fricking provider. For that matter, what ISP NATs you against your will?
I've been waiting for an answer to this since the thread started -- but then I realized that the NAT argument is just a smokescreen which enables Meyer to continue his prefix filtering flamewar. The sooner you all stop paying attention to him, the better off this list will be. --Adam -- Adam McKenna <adam@flounder.net> | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A
On Fri, Sep 07, 2001 at 07:50:05PM -0400, Andy Dills wrote:
Can you show damages in the situation of email? Yes. With packets? No. And before you come back at me with some crazy convoluted contrived scenario, let's just realize how far off the beaten path we are at this point. If your ISP is going to force you to use NAT, "against your will", get a new fricking provider. For that matter, what ISP NATs you against your will?
You're thinking civil law I think not criminal law. Criminal law does not require you to show damages, and generally doesn't care if you were breaking the law "to help someone" or to hurt them. I do realize this is a bit absurd, but here's the real lift situation that concerns me. Imagine if you will that your ISP asks you to sign a disclosure (or contract with disclosure) allowing them to "read and modify packets in the course of providing service". You ask them, dilligently about this and they tell you that they are using NAT, and you're ok with that. It all sounds well and good, but to me you also just gave them carte blanche to read your e-mail or other traffic, the way I read it. A loophole perhaps, but one large enough to drive a mac truck through, in legal speak. I would not be surprised if a skilled lawyer could get a 'wiretapper' off the hook, by showing them that someone consented to this sort of monitoring / modification, particuarly with so many non-technical judges. None of this has anything to do with the technical merits of NAT though, where I still maintain that 'plain nat' (no payload modification) is a useful tool, provided you know it breaks some things, and that 'nat' as currently marketed with all of its mucking around in the data layer is dangerous on a number of technical, political, and legal grounds. -- Leo Bicknell - bicknell@ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
For that matter, what ISP NATs you against your will?
Every ISP that utilizes a transparent caching HTTP proxy. NEXT!
Andy
-----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO5lqu0ksS4VV8BvHEQKx1wCfcRZtKto0PYyvnQmSTDSK8Hr8CBoAoIm0 YABQSZTS2/lIH/GG3ZqE6SHJ =t14y -----END PGP SIGNATURE-----
Can you show damages in the situation of email? Yes. With packets? No. And before you come back at me with some crazy convoluted contrived scenario, let's just realize how far off the beaten path we are at this point. If your ISP is going to force you to use NAT, "against your will", get a new fricking provider. For that matter, what ISP NATs you against your will?
Not quite so friend Andy. Someone in UAE claims that I sent porn to them. And investigation shows that not only is there a NAT one hop away from the purported victim, there is -another- NAT in the path, injected by some intermediate ISP as well as the one injected by my provider. Now I can chage my provider to one w/o NAT. I can even get the PV to change their provider (well maybe, given they are in UAE) But how can we avoid the intermediate ISP that is in the transit path? And can I persuade the judge that since NATs are known to muck about w/ addresses & such that I can construct a case that what was received did not come from me. So the porn came from one of the NAT operators.
Andy Dills 301-682-9972 Dialup * Webhosting * E-Commerce * High-Speed Access
And can I persuade the judge that since NATs are known to muck about w/ addresses & such that I can construct a case that what was received did not come from me. So the porn came from one of the NAT operators.
similarly, the anonymous remail operator sends all outbound mail, eh? i dunno. s.
participants (15)
-
Adam McKenna -
Andy Dills -
bmanning＠vacation.karoshi.com -
Charles Sprickman -
Joel Baker -
Joel Jaeggli -
Jon Mansey -
Leo Bicknell -
Mike Batchelor -
Richard Welty -
Roeland Meyer -
Scott Francis -
steve uurtamo -
Tony Hain -
Valdis.Kletnieks＠vt.edu