Subject: [BEHAVE] Question on TURN lockdown

From: Alan Johnston <[email-masked]>
Date: Thu, 30 Nov 2006 14:03:13 -0600

My apologies for bringing up an old issue, but I've only just become 
aware of the removal of TURN's lockdown feature.  This was last in 
version draft-ietf-behave-turn-02 (I know, ancient history - shows when 
I last read the draft ;-)

Here is this old behavior described in Section 4:

  "TURN allows a client to
   obtain a transport address, from a server on the public Internet,
   which can be used in protocols meeting the above criteria.  However,
   the transport addresses obtained from TURN servers are not generally
   useful for receiving data from anywhere.  They are only useful for
   communicating with a single peer.  Once a host sends packets to that
   transport address, it is ``locked down'', meaning that the client
   cannot cause packets to be sent to that host through the relay.  The
   client will still receive packets sent from different peers to that
   transport address, but these are wrapped in TURN protocol headers,
   reducing their efficiency.  This is done purposefully, so as to
   prevent TURN from being used to run servers (such as a web server or
   DNS server) on a client behind a NAT.  In this way, enterprises which
   deploy NATs and firewalls to prevent users from running servers, can
   be confident that TURN will not cause any violations in their
   enterprise security policies."

The absence of this feature makes TURN unsuitable for a signaling relay, 
something that could potentially be extremely useful for NAT traversal 
in P2P SIP without proxy servers.

Is there any way we can bring back this feature, or some equivalent 
feature that allow a TURN user to at least receive notification that 
they are receiving packets from an arbitrary Internet host?  The current 
mechanism for granting permission could then be used to activate forwarding.

Perhaps this could have other uses as well, such as informing a user 
when their TURN server is being subject to a DOS attack, allowing the 
user to select another server.

Thanks,
Alan

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Nov 2006 13:02:39 -0800

It was a conscious design decision when TURN was written so that
the TURN client (the user agent) would need to know the IP 
address of the remote machine to communicate with the remote 
machine.  This was to assuage concerns of network security 
administrators that TURN could be used to establish a 
'server' from behind a firewall or NAT -- which is exactly 
what you're trying to allow.

It might be possible to dance around this issue gently so that
p2p-sip using TURN can do what you want, whereas a normal, 
non-p2p-sip TURN server would disallow this.  The authors of
TURN may have suggestions on how this could be accomplished
in the upcoming turn-03.

-d

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 12:03 PM
> To: [email-masked]
> Subject: [BEHAVE] Question on TURN lockdown
>