Subject: Re: [BEHAVE] Question on TURN lockdown

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 4 Dec 2006 10:20:29 -0800

Hi Alan,

If you can propose some specific language that describes this kind of
an exception I'll look at putting it in the draft.  Current however,
the UNSAF and Security Considerations rely heavily on the property
that Dan described.

thanks,
-rohan

On 11/30/06, Dan Wing <[email-masked]> wrote:
> 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
> >
> > 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
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
>

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