Subject: RE: [BEHAVE] STUN Relay

From: "Kevin Johns" <[email-masked]>
Date: Mon, 15 Jan 2007 10:26:22 -0700

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: Mon, 15 Jan 2007 22:27:34 -0800

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-----
> Sent: Monday, January 15, 2007 9:26 AM
> To: Brian Stucker; [email-masked]
> 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 
> 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
> 
> ________________________________
> 
> 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
> 
> 
> ________________________________
> 
> 	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
> 
>