Subject: RE: [BEHAVE] STUN Relay

From: "Kevin Johns" <[email-masked]>
Date: Tue, 16 Jan 2007 10:34:56 -0700

Dan,

I took a quick look at your draft. The main drawback I see is that it
requires the firewall to implement it. Given the vast number of consumer
NAT/Firewall devices this seems to have limited applicability.

Having not thought through all the details, I was expecting that the UA
could send a STUN allocate request and upon getting a response, send a
binding request to the IP/Port assigned to the UA to associate the STUN
Relay with the UAs address and to open the NAT/Firewall binding. This
would then allow the ICE connectivity checks.

Alternatively, the UA could wait till it gets the SDP answer with the
remote UAs address info then send the connectivity checks which would
open the NAT bindings as well. The drawback to this is that the remote
UA might start connectivity checks as soon as they send the answer.
These would fail (no response) as the local UAs NAT will not have any
bindings to allow the connectivity checks through (although this is
currently the case and the receipt of the connectivity check cases a
trigger check to cut down on the delay of waiting for a timer to fire).

Kevin

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 11:28 PM
To: Kevin Johns; 'Brian Stucker'; [email-masked]
Subject: RE: [BEHAVE] STUN Relay

You need a bit more than STUN management traffic -- the endpoint needs
to also be able to send ICE connectivity checks through the TURN server.
Otherwise, the endpoint will never know that the path through the TURN
server is a viable path.

Implementing additional functionality in the TURN server, akin to what I
described in draft-wing-session-auth-00, should provide the hooks
necessary to block or detect attempts to use a TURN server without first
signaling via SIP.

-d

> -----Original Message-----
> From: Kevin Johns [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 9:26 AM
> To: Brian Stucker; [email-masked]
> Subject: RE: [BEHAVE] STUN Relay
> 
> Brian,
>  
> The concern is this, a UA needs to send a STUN message to a STUN Relay

> server to get an allocated address to put in its SDP. To allow this, 
> the policy enforcement point (CMTS, GGSN, AP, etc.) needs to have a 
> policy which allows the UA to send and receive messages from the STUN 
> Relay. Given the UA needs to communicate with the STUN Relay prior to 
> any session establishment, the policy needs to be static and apply to 
> all UAs. Now you have effectively installed a policy which allows UAs 
> to communicate freely via this static default policy.
> Now, this may not be a big issue if the network installs a dynamic 
> policy once the session is established and the dynamic policy takes 
> precedence over the static. However, if the network does not install a

> dynamic policy, the UA still has a free path to communicate with 
> another UA.
>  
> So it would be nice to be able to install a default policy which only 
> allows for STUN management traffic. Thus, if a UA requests a relay 
> address allocation the relay would happen on a different address/port 
> and thus block the UAs ability to relay media without a policy.
>  
> Kevin
> 
> ________________________________
> 
> From: Brian Stucker [mailto:[email-masked]]
> Sent: Monday, January 15, 2007 9:54 AM
> To: Kevin Johns; [email-masked]
> Subject: RE: [BEHAVE] STUN Relay
> 
> 
> What sort of policy management separation are you looking for? I am 
> assuming that you are talking about gating behavior at the relay?
>  
> Regards,
> Brian
> 
> 
> ________________________________
> 
> 	From: Kevin Johns [mailto:[email-masked]] 
> 	Sent: Monday, January 15, 2007 10:48 AM
> 	To: [email-masked]
> 	Subject: [BEHAVE] STUN Relay
> 	
> 	
> 	 
> 	One of the properties of STUN relay is that the STUN relay
server 
> handles both STUN messages and media on the same IP and Port. This 
> makes policy control a bit difficult as the policy enforcement point 
> has to be able to identify STUN messages over Media in order to 
> enforce policy. Has there been any discussion around having a 
> management only IP/Port and as part of the allocation process allocate

> a local transport address (the address and port the UA requesting the 
> allocation sends and receives from) in addition to the currently 
> allocated relayed transport address?
> 	 
> 	Such and approach would facilitate policy management as STUN
Relay 
> (and STUN for that matter) can be classified separately from the media

> traffic allowing for separate policy enforcement.
> 	 
> 	Regards,
> 	Kevin
> 
> 

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Jan 2007 10:18:56 -0800

> requires the firewall to implement it.

I realize my draft talks about firewalls.  However, that same function
(of deciding when to open/close a pinhole) can be implemented by a TURN
server. 

> Given the vast number of consumer

That isn't what I suggested.

> remote UAs address info

For TURN's connectivity checks to work, the offering UA needs to wait 
for the answer anyway.  This is because TURN purposefully does not allow
receiving packets from any IP address:  the transport address assigned
by the TURN server will only allow packets from IP addresses specified
by the STUN client in a Set Active Destination request.  See the 
top of http://tools.ietf.org/html/draft-ietf-behave-turn-02#section-9.2

> then send the connectivity checks which would

That's fine -- they are retransmitted by that remote UA until they're
successful.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Jan 2007 16:09:04 -0500

I understand why you are asking for this capability, but it is a 
tremendous change to the spec at this late hour, and I think there are 
other ways to achieve your goal.

I'll also point out that the approach you describe is hard to make work 
securely. It introduces an attack whereby an observer can watch the 
allocate message, learn the allocated port and associated cookie/token 
used to correlate the requests, and inject a faked request from their 
own port. This attack would require something akin to a shared secret 
request over TLS for each call. It also adds a lot of machinery to the 
spec. We considered an approach like this waaaayyyy back in the early 
days of TURN.

The easiest thing, IMHO, is for the firewall to just discard anything 
which is not a STUN message until authorization, and require the UA to 
set an active destination within a few seconds of the allocate request 
(the latter would be enforced on the stun relay). The authorization that 
gets installed then would be to allow non-stun messages. This requires 
the firewall function to peer a bit deeper than ports, but stun was 
designed to be easily recognizable by intermediate boxes.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 16 Jan 2007 16:42:54 -0600

This approach has a side effect...

If you rely on the client sending a SAD request to the TURN server
'within a few seconds of the allocate request' then you're very likely
going to clip the first few seconds of any early media going back to the
client using the existing mechanism.

If a gate is set by a component in the SIP signaling path, the clipping
can still occur, but should be the minimum interval possible given that
a gate exists in the network at all. I'm not suggesting changes to TURN
in regards to handling clipping other than to point out that we're
essentially requiring the originator to send packets (STUN or otherwise)
on the media path in order to get any media back from far ends, even if
that far end is a trusted network entity.

Should we perhaps state that the relay client should be prepared to
receive media from the relay server in the absence of any permissions
that the client may have created on the allocation via SAD/SI messages?
That would allow local network policy to stream early media to the relay
client without waiting for the client to interact with the relay server
outside of requesting the allocation (presumably as part of a candidate
address gathering exercise).

Regards,
Brian

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, January 16, 2007 3:09 PM
> To: Kevin Johns
> Cc: Dan Wing; Stucker, Brian (RICH1:AR00); [email-masked]
> Subject: Re: [BEHAVE] STUN Relay
> 
> I understand why you are asking for this capability, but it 
> is a tremendous change to the spec at this late hour, and I 
> think there are other ways to achieve your goal.
> 
> I'll also point out that the approach you describe is hard to 
> make work securely. It introduces an attack whereby an 
> observer can watch the allocate message, learn the allocated 
> port and associated cookie/token used to correlate the 
> requests, and inject a faked request from their own port. 
> This attack would require something akin to a shared secret 
> request over TLS for each call. It also adds a lot of 
> machinery to the spec. We considered an approach like this 
> waaaayyyy back in the early days of TURN.
> 
> The easiest thing, IMHO, is for the firewall to just discard 
> anything which is not a STUN message until authorization, and 
> require the UA to set an active destination within a few 
> seconds of the allocate request (the latter would be enforced 
> on the stun relay). The authorization that gets installed 
> then would be to allow non-stun messages. This requires the 
> firewall function to peer a bit deeper than ports, but stun 
> was designed to be easily recognizable by intermediate boxes.
> 
> Thanks,
> Jonathan R.
> 
> 
> Kevin Johns wrote:
> 
> > Dan,
> > 
> > requires the firewall to implement it. Given the vast number of 
> > consumer NAT/Firewall devices this seems to have limited 
> applicability.
> > 
> > Having not thought through all the details, I was expecting 
> that the 
> > UA could send a STUN allocate request and upon getting a response, 
> > send a binding request to the IP/Port assigned to the UA to 
> associate 
> > the STUN Relay with the UAs address and to open the NAT/Firewall 
> > binding. This would then allow the ICE connectivity checks.
> > 
> > Implementing additional functionality in the TURN server, 
> akin to what 
> > I described in draft-wing-session-auth-00, should provide the hooks 
> > necessary to block or detect attempts to use a TURN server without 
> > first signaling via SIP.
> > 
> > -d
> > 
> > 
> >

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 16 Jan 2007 15:10:17 -0800

(Assuming I understood your proposal correctly:)

One of TURN's design goals was to _not_ allow TURN to be used
to create a server on the 'far' side of a firewall.  If we
allow a TURN server to relay IP packets from arbitrary hosts
on the Internet to the STUN client, it seems to break that
design goal.

-d

> Sent: Tuesday, January 16, 2007 2:43 PM
> To: Jonathan Rosenberg; Kevin Johns
> Cc: Dan Wing; [email-masked]