Subject: [BEHAVE] TURN Issue: Interaction between ChannelBind and permissions

From: Philip Matthews <[email-masked]>
Date: Fri, 4 Jan 2008 19:34:47 -0500

One small point with EKR's proposed channel allocation mechanism is  
the interaction with permissions.

Consider the following message flow

        Client         TURN Server         Peer1             Peer2
           |                |                |                |
           |                |                |                |
           |                |                |                |
           |(1) Allocate    |                |                |
           |--------------->|                |                |
           |                |                |                |
           |                |                |                |
           |(2)    AllocOK  |                |                |
           |<---------------|                |                |
           |                |                |                |
           |                |                |                |
           |                |                |                |
           |(3) ChannelBind(0x4000)          |                |
           |--------------->|                |                |
           |                |                |                |
           |(4) BindOK      |                |                |
           |<---------------|                |                |
           |                |                |                |
           |                |(5) UDP Packet  |                |
           |                |<---------------|                |
           |                |                |                |
           |                |(6) UDP Packet  |                |
           |                |<--------------------------------|
           |                |                |                |
           |                |                |                |

At step (3), the client allocated channel 0x4000 to Peer1.
At step (5), a packet arrives from Peer1 before the client has sent  
any data to Peer1 or otherwise opened a permission. Is that packet  
dropped?
At step (6), a packet arrives from Peer2. Is that packet dropped?

I have the following proposal:
    Binding a channel to a remote address and port opens up a  
permission for that address.

Thus packet (5) is accepted, and packet (6) is accepted provided that  
it comes from the same address as packet (5).

Comments?

- Philip

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 7 Jan 2008 09:35:16 +0200

> it comes from the same address as packet (5).

I am not sure what you are asking. I surely agree that binding a channel 
should automatically add the relevant permission.

I am mixed as to whether the permission should be toward the address, or 
toward the address and port combination. But I thought we had rough consensus 
to go for address-only permissions. What I forgot is, how is a packet that 
matches a permission but does not match any channel framed by the TURN server 
to the TURN client?

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Tue, 8 Jan 2008 04:06:44 -0500

> matches a permission but does not match any channel framed by the  

A UDP packet arriving at the server at an allocated relayed transport  
address can have one of three things happen:
* It is dropped because there is no permission entry currently for  
the IP address of the UDP packet,
* It is forwarded on a channel if a channel has been bound to the  
source transport address (= IP address and port of the peer sending  
the packet),
* If it forwarded in a Data Indication otherwise.

What I suggested is that binding a channel to a given (IP address,  
port) would automatically add a permission for that IP address. This  
permission would last the usual interval (a recommended 60 seconds  
currently, which I now realize should match what we said in RFC 4787  
- whoops!).

Thinking about this more, I guess I am now neutral about this  
proposal. On the one hand, it makes sense. On the other hand, it  
mixes a control operation with permissions, which is something we do  
not currently have.

- Philip