Where NAT disenfranchises the end-user ...

Mailman List Mirror (Read Only)
1

> >> 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

2

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

3

-----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.

4

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.....

5

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

6

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.

7

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. :slight_smile:

8

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

9

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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.

10

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

11

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.

12

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?

13

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

14

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?

15

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.

16

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

17

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

18

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

19

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.

20

-----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!