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

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 22 Apr 2000 08:05:17 -0700 (PDT)

--- Jeffrey Altman <[email-masked]> wrote:
> I have so many issues with this reply that I am only going to focus on
> one.
> 
> > Agreed. How do you expect the intruders  will steal the tickets, without
> > being recipients of the ticket? Unless, you are assuming that the private
> > network is not trusted and that there are intruders within the private 
> > network.
> 
> There is no such thing as a trusted network.  One of the first things
> you learn about security (having nothing to do with computer security)
> is that most attacks occur from inside the organization.  There is no
> such thing as a trusted network.
> 

I hear what you say. Thanks.

> I have pointed you in directions you need to follow.  Stating that the
> a problem in one context is described in the described in another
> context is not useful in this document.  It is exactly because of this
> approach that the document comes across sounding as if the problems
> described are trivial and inconsequential.
> 
> 

Dont get me wrong. I was not suggesting that it suffices to point out
one end of the problem (ex: X-Windows Server redirection). I was merely
stating that the document covered one end, but failed to cover the other
end of the problem (i.e., Setting the DISPLAY variable from a Telnet 
session, using an IP address).
  
> 
>     Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
>                  The Kermit Project * Columbia University
>               612 West 115th St #716 * New York, NY * 10025
>   http://www.kermit-project.org/k95.html * [email-masked]
> 
> 

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Apr 2000 11:55:02 -0400

It might be useful to point out more clearly the common characteristics
of protocols that are broken by NATs. These include, in particular,
protocols that use one connection to establish another data flow. Such
protocols include ftp, SIP and RTSP (the latter is not mentioned yet in
the draft, but NATs also interfere with its operation). Note that unless
we forego such control protocol designs altogether, NATs in principle
break these unless every host has an external DNS mapping. (Thus, in
reference to a recent message to just design NAT-friendly protocols,
this means in practice that such "out-of-band" designs could not be
supported by this NATy version of the Internet. In effect, this leads to
the abomination of carrying real-time data in HTTP connections.)

Other protocol designs are those that are symmetric rather than
client-server based. This affects all Internet telephony or event-based
protocols (IM and generalizations) unless they maintain an outbound
connection with a server acting as their representative to the globally
routed Internet. The latter obviously does not address the media stream
addressing problems.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 23 Apr 2000 12:20:56 +0100

henning,

good stuff...
people would do well to read this - 

also, all attempts to fix NATs so as to ameliorate these problems
have _exactly_ the same deployment complexity as IPv6 - there's a
quote somewhere from yakov rehkter to this effect (can't find it
exactly, but he was coming the ther way saying why dont we use NATs
instead of v6 - same difference)

by the way, at least one router vendor has now lost a large contract
to a competitor becuase it couldn't provide v6 routing (forwardig,
yes, routing, no).... so perhaps we'll see the situation change quite
fast now:-)

 >>routed Internet. The latter obviously does not address the media stream

 cheers

   jon