Subject: RE: [BEHAVE] STUN Relay

From: "Kevin Johns" <[email-masked]>
Date: Tue, 16 Jan 2007 12:05:57 -0700

Dan,

Thanks for the clarification on your draft. I will re-read with that in
mind.

Kevin 

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Tuesday, January 16, 2007 11:19 AM
To: Kevin Johns; 'Brian Stucker'; [email-masked]
Subject: RE: [BEHAVE] STUN Relay

> I took a quick look at your draft. The main drawback I see is that it 
> 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
> NAT/Firewall devices this seems to have limited applicability.

That isn't what I suggested.

> 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

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

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

-d

> 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