Subject: RE: [BEHAVE] STUN Relay

From: "Kevin Johns" <[email-masked]>
Date: Tue, 16 Jan 2007 16:00:08 -0700

Thanks for the history. If this was considered in the past and rejected
I am ok with that, was just wondering if it was considered and if so why
it was not done.

Your suggested approach seems to be along the same lines as Dans. I'll
plan on taking a more detailed review of his draft to better understand
the architecture and potential implications of such an approach.

Kevin

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 2:09 PM
To: Kevin Johns
Cc: Dan Wing; Brian Stucker; [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,
> 
> 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
> 

-- 
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

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