🚀 go-pugleaf

In article <54c48ac0.0208181042.79852937@posting.google.com>,
Kevin Joseph <kejoseph@hotmail.com> wrote:
:I am connecting to a remote Unix box using its NAT'ed IP address. I
:want to X-Display something back onto my local PC using X-Client. To
:do this I need to provide the remote system the IP address of my local
:PC (via the DISPLAY variable ).
:  How do I find out the NAT'ed address of my PC which I need to feed
:to the DISPLAY variable ?

Three unix commands which might be useful for this purpose are:

who
last
netstat

In article <ajp0ov$24a$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc.ca> wrote:
>Three unix commands which might be useful for this purpose are:
>
>who
>last
>netstat

That's almost certainly not going to work.  NAT tables
contain addresses and port numbers, with mappings being done
on a per-port basis rather than per-host.  What's needed is
a tunnel between the two systems - probably the simplest,
most straightforward way about it is to use ssh.  Both
OpenSSH for Windows and TTSSH will forward X, and they'll
put the correct DISPLAY variable in the environment, to
boot.

The best solution, as always, is to take the NAT and smash
it to bits before incinerating what's left and shooting the
ashes into space.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

kejoseph@hotmail.com (Kevin Joseph) writes:
> I am connecting to a remote Unix box using its NAT'ed IP address. I
> want to X-Display something back onto my local PC using X-Client. To
> do this I need to provide the remote system the IP address of my local
> PC (via the DISPLAY variable ).
>   How do I find out the NAT'ed address of my PC which I need to feed
> to the DISPLAY variable ?

It doesn't work that way.  The easiest way to do what you want is to
use "ssh -X" to connect to the remote machine.  See the ssh man page
for details.

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@forte-intl.com>      Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084  4A88 8851 E6C8 69E3 B00B

Or you can do a port forwarding with your natd software to that nated
ip address. I'm just thinking in this line .... maybe someone has got
better idea regarding this.

which port does x require?

raqueeb hassan
bangladesh

TCP port 6000, often referred to as X11.

For info, we use Reflection X from WRQ and it passes our random DHCP given
IP's to the Xhost dynamically.
But it's all done by friendly wizards.

"Raqueeb Hassan" <raqueebh@yahoo.com> wrote in message
news:2545b34c.0208182314.347e79e0@posting.google.com...
> Or you can do a port forwarding with your natd software to that nated
> ip address. I'm just thinking in this line .... maybe someone has got
> better idea regarding this.
>
> which port does x require?
>
> raqueeb hassan
> bangladesh

In article <ajp1am$o05$1@panix3.panix.com>, shore@panix.com says...
> 
> The best solution, as always, is to take the NAT and smash
> it to bits before incinerating what's left and shooting the
> ashes into space.
Just get rid of NAT. Well there's an easy solution. I'll reserve a /24 
for each of my clients with 5 hosts. 

Maybe when IPv6 becomes prevalent, when every light bulb in the world 
has its own IP address, then maybe we can get rid of NAT.  

BTW, nice tagline. Almost makes me want to harrass you :-)
-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring

Dave Phelps <tippenring@deadspam.com> writes:

> Maybe when IPv6 becomes prevalent, when every light bulb in the world 
> has its own IP address, then maybe we can get rid of NAT.  

I would dearly love that.  Everyone who has an ISP has 64K IP
addresses, free of charge!  But it's not going to happen.  ICANN Screw
You Out Of The Internet will ruin it for everyone, like they always
do.

-- 
Eric McCoy (reverse "ten.xoc@mpe", mail to "ctr2sprt" is filtered)

"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass."	- John Novak, rasfwrj

In article <MPG.17cb5c97939967059898fc@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>Just get rid of NAT. Well there's an easy solution. I'll reserve a /24 
>for each of my clients with 5 hosts. 

NAT introduces a host of other problems, including
nasty protocol interactions, host unreachability, and
security unpleasantness (NAT is indistinguishable from an
attacker).  They undermine network performance and jack up
the cost of equipment (there are several large manufacturers
I can think of that I would guess are each spending about
$10,000,000/year figuring out how to work around problems
that NAT introduces).  Many of the workarounds also double
as tools to allow your users, should they choose to do so,
to violate local firewall policy.  But hey, it's your
network.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

In article <ajs8n5$hav$1@panix3.panix.com>, shore@panix.com says...
> In article <MPG.17cb5c97939967059898fc@news.charter.net>,
> Dave Phelps  <tippenring@deadspam.com> wrote:
> >Just get rid of NAT. Well there's an easy solution. I'll reserve a /24 
> >for each of my clients with 5 hosts. 
> 
> NAT introduces a host of other problems, including
> nasty protocol interactions, host unreachability, and
> security unpleasantness (NAT is indistinguishable from an
> attacker).  They undermine network performance and jack up
> the cost of equipment (there are several large manufacturers
> I can think of that I would guess are each spending about
> $10,000,000/year figuring out how to work around problems
> that NAT introduces).  Many of the workarounds also double
> as tools to allow your users, should they choose to do so,
> to violate local firewall policy.  But hey, it's your
> network.

Good points, but totally unresponsive to his statement.

In article <ajs8n5$hav$1@panix3.panix.com>, shore@panix.com says...
 
> NAT introduces a host of other problems, including
> nasty protocol interactions, host unreachability, and
> security unpleasantness (NAT is indistinguishable from an
> attacker).  They undermine network performance and jack up
> the cost of equipment (there are several large manufacturers
> I can think of that I would guess are each spending about
> $10,000,000/year figuring out how to work around problems
> that NAT introduces).  Many of the workarounds also double
> as tools to allow your users, should they choose to do so,
> to violate local firewall policy.  But hey, it's your
> network.
 
I don't entirely disagree, so I will only mention the points that I 
disagree with you on for brevity.

NAT is indistinguishable from an attacker? I'm not sure what you mean 
there.

NAT doesn't significantly increase the cost of equipment. You may need 
more memory, but memory is cheap (unless you buy "Cisco" memory LOL). 
The router folks wrote the code for NAT because the demand, and lack of 
IP space, was there. They either had to support NAT, or put a rush on 
the IPv6 code, which I suspect wasn't near standardized at the 
introduction time of NAT.

A lot of the problems NAT introduces is because of programmers that have 
written code without regard for the OSI model. If they would have left 
IP addresses at layer 3, there wouldn't be nearly the problem that there 
is. FTP and Netmeeting are two examples.

As far as firewalling, NAT performs as a very good, cheap firewall for 
millions of hosts every day on networks without incident. For many 
people, the router performing NAT is the firewall also. If people want 
to enforce a more stingent firewall policy, then they must be prepared 
to spend the money that it takes. 

Tell me, exactly how does NAT enable users to violate firewall policy? I 
don't see how translating an internal address at the firewall somehow 
bypasses firewall restrictions.

-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring

In article <MPG.17cb70dd853f18d09898ff@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>NAT is indistinguishable from an attacker? I'm not sure what you mean 
>there.

There's no way to tell if you're getting an unexpected IP
address because there's an attacker in the middle or because
there's a NAT.  This breaks IPSec and makes other protocols,
like STUN, impossible to secure.

>NAT doesn't significantly increase the cost of equipment. 

Sure it does.  The two principle mechanisms for getting
non-trivial protocols across NAT have been stateful
inspection/payload rewrite, and proxies.  (Note that both
prevent you from securing your applications end-to-end.)
That means that you've got another participant in protocol
processing and that that participant has to support the
protocols that are causing you problems (FTP, SIP, H.323,
MGCP/megaco, gaming protocols, instant messaging protocols
... ), which in turn means that you need more processing
power in the boxes themselves and that the manufacturer
needs a team (or several teams, in the case of some of the
bigger manufacturers who have multiple product lines) of
developers adding protocol support to the NAT or proxy.

>A lot of the problems NAT introduces is because of programmers that have 
>written code without regard for the OSI model. If they would have left 
>IP addresses at layer 3, there wouldn't be nearly the problem that there 
>is. FTP and Netmeeting are two examples.

IP doesn't follow the OSI model, particularly.  If you're
talking about cleanliness between the layers, IP is
generally in pretty good shape there.  Dynamically
allocating data streams is good practice and while H.323 may
be misdesigned, its use of dynamically-allocated ports is
not the problem.  The problem, in the case of NAT, was that
one of the most fundamental design principles behind IP was
that addresses are globally unique and globally routable and
that they are immutable end-to-end.  NAT obviously breaks
that, and the consequences are pretty much what you'd
expect.

>Tell me, exactly how does NAT enable users to violate firewall policy? I 
>don't see how translating an internal address at the firewall somehow 
>bypasses firewall restrictions.

I said that many of the mechanisms that are being developed
to accomodate NAT provide the means for users to violate
local firewall policy.  There's an arms war going on between
manufacturers, who need to make sure that applications work
despite the presence of NATs, and users, who find firewalls
a big nuisance and who are using the NAT workarounds as
tools to allow them to run unauthorized servers, etc.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

In article <ajt9ku$fvh$1@panix3.panix.com>, shore@panix.com says...
> In article <MPG.17cb70dd853f18d09898ff@news.charter.net>,
> Dave Phelps  <tippenring@deadspam.com> wrote:
> >NAT is indistinguishable from an attacker? I'm not sure what you mean 
> >there.
> 
> There's no way to tell if you're getting an unexpected IP
> address because there's an attacker in the middle or because
> there's a NAT.  This breaks IPSec and makes other protocols,
> like STUN, impossible to secure.
I think your first sentence is based on the fact stated in your second. 
I understand what you're getting at now. However, people that are likely 
to use those protocols are more likely to be looking at getting public 
IP address space anyway. And I would recommend it in that case.

> 
> >NAT doesn't significantly increase the cost of equipment. 
> 
> Sure it does.  The two principle mechanisms for getting
> non-trivial protocols across NAT have been stateful
> inspection/payload rewrite, and proxies.  (Note that both
> prevent you from securing your applications end-to-end.)
> That means that you've got another participant in protocol
> processing and that that participant has to support the
> protocols that are causing you problems (FTP, SIP, H.323,
> MGCP/megaco, gaming protocols, instant messaging protocols
> ... ), which in turn means that you need more processing
> power in the boxes themselves and that the manufacturer
> needs a team (or several teams, in the case of some of the
> bigger manufacturers who have multiple product lines) of
> developers adding protocol support to the NAT or proxy.
Ok. So maybe the cost is more significant than I originally implied. I 
still stand by my point that it was necessary anyway, due to the lack of 
IP space, and so was unavoidable.
> 
> >A lot of the problems NAT introduces is because of programmers that have 
> >written code without regard for the OSI model. If they would have left 
> >IP addresses at layer 3, there wouldn't be nearly the problem that there 
> >is. FTP and Netmeeting are two examples.
> 
> IP doesn't follow the OSI model, particularly.  If you're
> talking about cleanliness between the layers, IP is
> generally in pretty good shape there.  Dynamically
> allocating data streams is good practice and while H.323 may
> be misdesigned, its use of dynamically-allocated ports is
> not the problem.  The problem, in the case of NAT, was that
> one of the most fundamental design principles behind IP was
> that addresses are globally unique and globally routable and
> that they are immutable end-to-end.  NAT obviously breaks
> that, and the consequences are pretty much what you'd
> expect.
True, NAT breaks the end-to-end plan. However, it goes back to the fact 
that the IP space was not available, and incidentally, still isn't.
> 
> >Tell me, exactly how does NAT enable users to violate firewall policy? I 
> >don't see how translating an internal address at the firewall somehow 
> >bypasses firewall restrictions.
> 
> I said that many of the mechanisms that are being developed
> to accomodate NAT provide the means for users to violate
> local firewall policy.  There's an arms war going on between
> manufacturers, who need to make sure that applications work
> despite the presence of NATs, and users, who find firewalls
> a big nuisance and who are using the NAT workarounds as
> tools to allow them to run unauthorized servers, etc.
If the users don't have administrative access to the box performing NAT, 
then there really isn't a problem with users running unauthorized 
servers. Sure, there are ways the users can get by NAT to run 
unauthorized servers, such as relaying thru another public server to 
which they have a session (essentially connecting to a public proxy), 
however, NAT isn't the cause of the problem. Even if the user had a 
public IP , no NAT, and his traffic was passing thru a firewall, he 
would still be able to run his unauthorized server.

Overall, I agree with you that NAT has made a nuisance of itself in 
soime cases, but I believe that the inconveniences of NAT are FAR 
outweighed by what NAT has made possible for Internet connectivity. 

-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring

In article <MPG.17ccc360a78e8145989900@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>I think your first sentence is based on the fact stated in your second. 
>I understand what you're getting at now. However, people that are likely 
>to use those protocols are more likely to be looking at getting public 
>IP address space anyway. And I would recommend it in that case.

Well, since STUN exists to help NATted endpoints find their
external address (something that's impossible to do reliably
without talking directly to the NATs along the path, but
STUN provides a reasonable heuristic in the absence of that
ability), pretty much by definition anybody who uses it is
NATted.  NATs are quite heavily used in organizations that
use IPSec VPNs, but either the translation is done before
encapsulation/after decapsulation or a NAT workaround
mechanism is used, risking adding additional instability to
the network, etc.

It's important to understand that there's no universal
solution to the problems that NAT introduces, nor can there
be.  As things stand right now you need to add stuff to your
network to get IPSec to work, other stuff to get H.323
(NetMeeting) to work, other stuff to get SIP and SIP-based
instant messaging to work, other stuff to get telephony
gateway protocols like MGCP and megaco to work, other stuff
to get gaming protocols to work, and the list gets ever
longer.  For the average home user behind a single NAT this
usually isn't a problem (unless he or she happens to want to
run a protocol for which there's no support), but for any
non-trivial network the effort and expense start to add up.
In some cases (large enterprises) they become quite
significant.

>True, NAT breaks the end-to-end plan. However, it goes back to the fact 
>that the IP space was not available, and incidentally, still isn't.

Let's be clear on something - address space was and is
available (current utilization is ~50%), but because of the
way distribution and ownership of addresses are handled the
folks who own address blocks benefit economically from
creating a false scarcity.  They make money selling
addresses.  This is a political and economic problem, not
technical.

Nevertheless, there is a technical solution, and that's
IPv6.  Over the medium-to-long term a transition to v6 is
almost certainly less expensive than continuing to pile on
NAT workarounds.

>If the users don't have administrative access to the box performing NAT, 
>then there really isn't a problem with users running unauthorized 
>servers. Sure, there are ways the users can get by NAT to run 
>unauthorized servers, such as relaying thru another public server to 
>which they have a session (essentially connecting to a public proxy), 
>however, NAT isn't the cause of the problem. 

Let's say that I run an IP-based PBX for my company and I
find that calls cannot get through my firewall/NAT.  I cast
around for a solution, like people do here, and I get a
response from company Splortsoft who tells me that their
software will solve the NAT traversal problem and that it
won't introduce any additional security holes.  In point of
fact it *does* introduce security holes by providing a means
to defeat local firewall policy - after all, if firewall
policy "understood" telephony protocols I wouldn't need to
buy anything from Splortsoft, right?  A wiser person than me
once said that there are no side effects, only effects, and
in this case it shouldn't be surprising that the stuff from
Splortsoft allows malicious contravention of firewall policy
in addition to allowing NAT traversal by protocols we like.
So here I am, the beleaguered network administrator,
installing software that allows people to violate the
policies I'm trying to enforce.  At this point it would make
more sense to chuck both the firewall and the software from
Splortsoft and get myself some addresses.

>Overall, I agree with you that NAT has made a nuisance of itself in 
>soime cases, but I believe that the inconveniences of NAT are FAR 
>outweighed by what NAT has made possible for Internet connectivity. 

There *is* an alternative.

(Trivial point, but a pet peeve nevertheless - the things
under discussion are "addresses," not "IPs.")
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

In article <ak0dap$bt6$1@panix2.panix.com>, shore@panix.com says...

> Let's be clear on something - address space was and is
> available (current utilization is ~50%), but because of the
> way distribution and ownership of addresses are handled the
> folks who own address blocks benefit economically from
> creating a false scarcity.  They make money selling
> addresses.  This is a political and economic problem, not
> technical.
That is probably true. However, I believe that, whatever the reason, 
without the address space conservation that has occurred, address space 
would probably be nearly consumed by now.
> 
> Nevertheless, there is a technical solution, and that's
> IPv6.  Over the medium-to-long term a transition to v6 is
> almost certainly less expensive than continuing to pile on
> NAT workarounds.
Very true.
> 
> Let's say that I run an IP-based PBX for my company and I
> find that calls cannot get through my firewall/NAT.  I cast
> around for a solution, like people do here, and I get a
> response from company Splortsoft who tells me that their
> software will solve the NAT traversal problem and that it
> won't introduce any additional security holes.  In point of
> fact it *does* introduce security holes by providing a means
> to defeat local firewall policy - after all, if firewall
> policy "understood" telephony protocols I wouldn't need to
> buy anything from Splortsoft, right?  A wiser person than me
> once said that there are no side effects, only effects, and
> in this case it shouldn't be surprising that the stuff from
> Splortsoft allows malicious contravention of firewall policy
> in addition to allowing NAT traversal by protocols we like.
> So here I am, the beleaguered network administrator,
> installing software that allows people to violate the
> policies I'm trying to enforce.  At this point it would make
> more sense to chuck both the firewall and the software from
> Splortsoft and get myself some addresses.
Using your example, you are not enabling anyone to violate firewall 
policy. Installing the Micro^H^H^H^H^HSplortsoft product simply fixes 
the necessary translations to trick the IP PBX software into thinking it 
has public IP's. You still have to create a rule to allow the traffic 
thru the firewall. It's no different than if you had public addresses. 
You would still have to permit the traffic thru the firewall. Surely you 
wouldn't abandon the firewall once you got public addresses?
> 
> >Overall, I agree with you that NAT has made a nuisance of itself in 
> >soime cases, but I believe that the inconveniences of NAT are FAR 
> >outweighed by what NAT has made possible for Internet connectivity. 
> 
> There *is* an alternative.
> 
> (Trivial point, but a pet peeve nevertheless - the things
> under discussion are "addresses," not "IPs.")
Point taken. It's just easier to say "IPs" than say "addresses". 

-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring

"Raqueeb Hassan" <raqueebh@yahoo.com> wrote ...
> Or you can do a port forwarding with your natd software to that nated
> ip address. I'm just thinking in this line .... maybe someone has got
> better idea regarding this.
>
> which port does x require?
>
X server (the machine with the graphics display, keyboard & mouse)
will typically run on port 6000 plus display number.
if DISPLAY=myhost:0   then the port is 6000
if DISPLAY=myhost:1  then the port is 6001 etc.

In article <MPG.17cf59442d7d34de989902@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>Using your example, you are not enabling anyone to violate firewall 
>policy. Installing the Micro^H^H^H^H^HSplortsoft product simply fixes 
>the necessary translations to trick the IP PBX software into thinking it 
>has public IP's. You still have to create a rule to allow the traffic 
>thru the firewall. 

Splortsort's stuff (and STUN and TURN and most firewall/NAT
workarounds) assume that all outgoing traffic is permitted 
unless you specify otherwise.  So, in order to accept incoming
connections, someone puts a relay outside the firewall/NAT,
sends a request to it and asks it to relay for them, establishes
a connection to it on the chosen port, and then the relay forwards
all incoming traffic matching a particular pattern (say, 
the standard 5-tuple) to that connection.  You've now got the
ability to receive incoming telephone calls.  You've also got
the ability to run unauthorized servers behind the firewall/
NAT and the ability to run unauthorized p2p applications 
behind the firewall/NAT.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

In article <ak58md$stl$1@panix2.panix.com>, shore@panix.com says...
> In article <MPG.17cf59442d7d34de989902@news.charter.net>,
> 
> ability to receive incoming telephone calls.  You've also got
> the ability to run unauthorized servers behind the firewall/
> NAT and the ability to run unauthorized p2p applications 
> behind the firewall/NAT.

I see. So if I fired up a server instead of my IP phone using a 
predetermined port number, how would I receive phone calls? I would be 
taking my phone out of service, because all requests would go to the 
server instead of my phone.

Alternatively, all calls can relay thru the call manager, and the 
firewall will allow inbound H.323 traffic to reach the call manager 
only, which prevents me from making a server public using that security 
hole (maybe bad design would be a better term than "security hole")
altogether.

Notably, without NAT, the same problem still exists. Even if I have an 
organization that uses exclusively public IP's, I still have to open the 
firewall for the H.323 traffic, where someone could potentially install 
a server instead of taking their phone calls.

-- 
Dave Phelps
Phone Masters Ltd.
deadspam=tippenring

In article <MPG.17d04343f28c6eb8989909@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>I see. So if I fired up a server instead of my IP phone using a 
>predetermined port number, how would I receive phone calls? I would be 
>taking my phone out of service, because all requests would go to the 
>server instead of my phone.

You'd establish a relationship with the server and agree
upon a port/address pair to which incoming call signaling
streams would be forwarded.

>Alternatively, all calls can relay thru the call manager, and the 
>firewall will allow inbound H.323 traffic to reach the call manager 
>only, which prevents me from making a server public using that security 
>hole (maybe bad design would be a better term than "security hole")
>altogether.

At some point, somebody somewhere has to have a routable
address.  One of the things that I don't like about H.323 
is its overreliance on centralized call signaling (the
gatekeeper, specifically), but it is a device that one
can reasonably expect to have a public address and to be 
a trusted entity within the network.  Endpoints register
with it and that registration can (and should) be authenticated.
There are several different ways of dealing with the firewall
and/or NAT, but even if you don't have the gatekeeper 
making requests directly of the firewall at least you've 
moved the policy point back within the network.  An awful
lot of the complexity comes from a really bad security
model ("put up a firewall, NAT the endpoints, and run
everything through a VPN").
>
>Notably, without NAT, the same problem still exists. Even if I have an 
>organization that uses exclusively public IP's, I still have to open the 
>firewall for the H.323 traffic, where someone could potentially install 
>a server instead of taking their phone calls.
>
>-- 
>Dave Phelps
>Phone Masters Ltd.
>deadspam=tippenring


-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it

In article <ak6c3c$qgr$1@panix2.panix.com>,
Melinda Shore <shore@panix.com> wrote:
[sent too soon]
>>Notably, without NAT, the same problem still exists. Even if I have an 
>>organization that uses exclusively public IP's, I still have to open the 
>>firewall for the H.323 traffic, where someone could potentially install 
>>a server instead of taking their phone calls.

Firewalls really are not very good security devices for reasons
like this, which is part of the reason that I'm an advocate
for allowing authenticated, authorized endpoints to make
requests directly of a firewall and have the firewall say
"yes" or "no."  Even today there are people who are using
bogus H.323 and SIP signaling to open pinholes for them.  The 
firewall vendors are responding by 1) examining signaling
more closely, and 2) adding heuristics so that if, say, in
an H.323 call an H.245 channel is allocated but media streams
are never opened, the pinholes are closed.  All of this 
pushes up the cost and comlexity of firewalls and isn't
completely reliable.  It also forces you to send signaling
streams in the clear, which is bad with SIP and really 
terrible in H.323 (DTMF is carried in H.245 messages).  A
security model that prevents you from protecting application
traffic really isn't a very good security model.
-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it