Subject: [BEHAVE] TURN: Send indication when no permission exists

From: Philip Matthews <[email-masked]>
Date: Fri, 3 Oct 2008 16:55:34 -0400

TURN-10 introduces the CreatePermission request for creating or  
updating a permission. With this new request comes the question of  
what to do if the server receives a Send indication when no permission  
is installed towards the peer. There are two options:
a) Send the UDP datagram towards the peer anyway, or
b) Drop the Send indication

In TURN-10, we opted for (a) because there didn't seem to be any good  
reason to do (b).  However, Cullen has now found an example where  
option (a) seems to be a problem.

Consider a TURN server operated by an organization O and located in  
the organization's DMZ. Consider a laptop owned by user Fred (who  
works for the organization). Fred's laptop is configured to use the  
organization's TURN server. Now consider what happens if Fred goes off  
to an IETF meeting.

Fred's laptop will still try to use O's TURN server, except now the  
TURN server is being accessed from the Internet. At the IETF meeting,  
an attacker can sniff the wireless network and see the TURN packets  
Fred's laptop is exchanging with the TURN server. The attacker can  
then use TURN to attack the other servers in the O's DMZ by sending a  
Send indication to the TURN server with a PEER-ADDRESS attribute of  
the other server. The attacker can do this because Send indications  
are not authenticated. In this way, the attacker has bypassed any  
rules that the Outer Firewall has installed about who may access the  
other servers in the DMZ.

                                                    +---------------+
                                                    | Fred's laptop |
            +----------------+                      +---------------+
    +-------| Outer Firewall |----------+
    |       +----------------+          |
    |                                   |
    | +-------------+   +------------+  |
    | | TURN server |   | Web Server |  |
    | +-------------+   +------------+  |
    |                                   |
    |       +-----------------+         |
    +-------| Inner Firewall  |---------+
    |       +-----------------+         |
    |                                   |
    |     Organization's network        |
    |                                   |
    +-----------------------------------+

Given this example, I am proposing to change to option (b). In other  
words, the Server will drop an incoming Send indication unless there  
is an active permission towards the IP address in the PEER-ADDRESS.

Comments?
Does anyone think that we should address Cullen's example in another  
way? Does anyone think that there are reasons a client would like the  
behavior that option (a) offers?

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Oct 2008 10:47:19 -0400

I agree with Cullen's concern and think the proposed remedy - requiring 
a CreatePermission first - is the right approach.

-Jonathan R.

Philip Matthews wrote:
> TURN-10 introduces the CreatePermission request for creating or updating 
> a permission. With this new request comes the question of what to do if 
> the server receives a Send indication when no permission is installed 
> towards the peer. There are two options:
> reason to do (b).  However, Cullen has now found an example where option 
> (a) seems to be a problem.
> 
> Consider a TURN server operated by an organization O and located in the 
> organization's DMZ. Consider a laptop owned by user Fred (who works for 
> the organization). Fred's laptop is configured to use the organization's 
> TURN server. Now consider what happens if Fred goes off to an IETF meeting.
> 
> Fred's laptop will still try to use O's TURN server, except now the TURN 
> server is being accessed from the Internet. At the IETF meeting, an 
> attacker can sniff the wireless network and see the TURN packets Fred's 
> laptop is exchanging with the TURN server. The attacker can then use 
> TURN to attack the other servers in the O's DMZ by sending a Send 
> indication to the TURN server with a PEER-ADDRESS attribute of the other 
> server. The attacker can do this because Send indications are not 
> authenticated. In this way, the attacker has bypassed any rules that the 
> Outer Firewall has installed about who may access the other servers in 
> the DMZ.
> 
>                                                    +---------------+
>                                                    | Fred's laptop |
> words, the Server will drop an incoming Send indication unless there is 
> an active permission towards the IP address in the PEER-ADDRESS.
> 
> Comments?

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 06 Oct 2008 10:27:35 -0700

> other servers in the DMZ.
I read TURN-10 again, and I don't see why the attacker can't simply send 
a CreatePermission before every Send, since there's nothing in 9.1 that 
says that CreatePermission requests must be authenticated.

I also have an example of a UDP network protocol that is becoming less 
and less TURN-friendly with the addition of CreatePermission and the 
stateful client behavior required to ensure that permissions are 
actually created first.

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Mon, 6 Oct 2008 15:00:24 -0400

On Mon, 6-Oct-08, at 13:27 , Matthew Kaufman wrote:

> I read TURN-10 again, and I don't see why the attacker can't simply  
> send a CreatePermission before every Send, since there's nothing in  
> 9.1 that says that CreatePermission requests must be authenticated.

TURN-10 says (section 4) that the server SHOULD require that all  
requests be authenticated, and that all clients MUST be prepared to  
authenticate requests if required. This language has been in the draft  
for a few versions now.

>
> I also have an example of a UDP network protocol that is becoming  
> less and less TURN-friendly with the addition of CreatePermission  
> and the stateful client behavior required to ensure that permissions  
> are actually created first.
>

I don't know your application protocol, but do you have an alternative  
suggestion for how to proceed? Is there something we can do to TURN to  
make things better?

- Philip

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 06 Oct 2008 12:52:50 -0700

> suggestion for how to proceed? Is there something we can do to TURN to 
What I need is a way to establish a channel between my application and 
the proxy (auto-discovery of the proxy via DHCP would be nice for the 
corporate IT-provided proxy case), optionally authenticate with the 
proxy (optionally, because some IT organizations might be sufficiently 
comfortable with the idea of allowing everyone on the "inside" net to 
use the proxy without authentication), and then once that channel is 
open to use it to send traffic to any UDP address+port while ensuring 
that return traffic comes back over the same channel as well. Once the 
channel is established and authenticated to the proxy, I'd like to see 
there be nothing but encapsulation required as far as client logic goes, 
as the more heavy-weight the communication and/or logic needs to be, 
especially on a per-destination basis, the less suitable the proxy 
protocol becomes.

My application establishes the proxy connection at startup, but does not 
use its UDP network protocol stack to open network sessions with far 
endpoints until later (sometimes a very short time later, sometimes 
longer), and when creating those network sessions it sends UDP packets 
to several candidate endpoint addresses in parallel, then sticking with 
the one that actually worked. It does this work in parallel in order to 
reduce the latency between a request to open a session and the time the 
session is up, which is the same reason that the session establishment 
is fine-tuned to bring up an encrypted network session in just 2 RTTs. 
The longer it takes to establish a session to a new endpoint, the worse 
the user experience is.

Requiring that each possible candidate address have a permission 
installed beforehand means that either there's extra RTTs (and traffic) 
between the proxy server and the application in order to wait for the 
permissions to be verified, or even more traffic generated by the 
asynchronous implementation of sending a permission request before every 
send that is to an address for which a permission grant hasn't (yet) 
been received. RTT to the proxy matters in cases where a company has an 
office in India but proxies all their external Internet via the US, a 
not-uncommon situation.

TURN has slowly moved from being almost exactly the right proxy protocol 
for this application to one which is now very close to being inferior 
enough that we'd switch to a proprietary proxy protocol instead, which 
has disadvantages for both the TURN effort (because our application 
would no longer be a driver for TURN deployment) and our users (because 
they'd be more limited in their choice of proxies).

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Mon, 6 Oct 2008 16:29:39 -0400

On Mon, 6-Oct-08, at 15:52 , Matthew Kaufman wrote:

> Philip Matthews wrote:
>> I don't know your application protocol, but do you have an  
>> alternative suggestion for how to proceed? Is there something we  
>> can do to TURN to make things better?
>>
> What I need is a way to establish a channel between my application  
> and the proxy (auto-discovery of the proxy via DHCP would be nice  
> for the corporate IT-provided proxy case), optionally authenticate  
> with the proxy (optionally, because some IT organizations might be  
> sufficiently comfortable with the idea of allowing everyone on the  
> "inside" net to use the proxy without authentication), and then once  
> that channel is open to use it to send traffic to any UDP address 
> +port while ensuring that return traffic comes back over the same  
> channel as well. Once the channel is established and authenticated  
> to the proxy, I'd like to see there be nothing but encapsulation  
> required as far as client logic goes, as the more heavy-weight the  
> communication and/or logic needs to be, especially on a per- 
> destination basis, the less suitable the proxy protocol becomes.
>
> My application establishes the proxy connection at startup, but does  
> not use its UDP network protocol stack to open network sessions with  
> far endpoints until later (sometimes a very short time later,  
> sometimes longer), and when creating those network sessions it sends  
> UDP packets to several candidate endpoint addresses in parallel,  
> then sticking with the one that actually worked. It does this work  
> in parallel in order to reduce the latency between a request to open  
> a session and the time the session is up, which is the same reason  
> that the session establishment is fine-tuned to bring up an  
> encrypted network session in just 2 RTTs. The longer it takes to  
> establish a session to a new endpoint, the worse the user experience  
> is.
>
> installed beforehand means that either there's extra RTTs (and  
> traffic) between the proxy server and the application in order to  
> wait for the permissions to be verified, or even more traffic  
> generated by the asynchronous implementation of sending a permission  
> request before every send that is to an address for which a  
> permission grant hasn't (yet) been received. RTT to the proxy  
> matters in cases where a company has an office in India but proxies  
> all their external Internet via the US, a not-uncommon situation.
>
> TURN has slowly moved from being almost exactly the right proxy  
> protocol for this application to one which is now very close to  
> being inferior enough that we'd switch to a proprietary proxy  
> protocol instead, which has disadvantages for both the TURN effort  
> (because our application would no longer be a driver for TURN  
> deployment) and our users (because they'd be more limited in their  
> choice of proxies).

Note that TURN does not REQUIRE that the server use authentication --  
there may be situations where authentication is not required. However,  
the security of TURN without authentication is poor.

I don't know how much data your client sends to each peer, but if  
there is a fair amount of data, then you will probably want to bind a  
channel to each peer to reduce overhead (from 36 bytes to 4 bytes).  
Two notes when using channels. First, a ChannelBind creates both a  
channel and a permission. Second, there is nothing that stops your  
application from sending ChannelData messages immediately after  
sending the ChannelBind request. In most cases, everything will work  
fine. It is only if the ChannelBind fails that you will have to recover.

Do you have a suggestion for another way to do things? What would you  
do in a proprietary protocol that is different from the way TURN works?

- Philip

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 06 Oct 2008 13:29:39 -0700

Meanwhile...

> other servers in the DMZ.

1. Fred's laptop shouldn't be able to reach O's TURN server, because if 
O wants their TURN server in their DMZ to be only used by members of 
their organization, they should have either set up the TURN server to 
only talk TURN to/from the inside net and/or set up the DMZ-Outside 
firewall to block inbound TURN traffic from the outside from even 
reaching the TURN server.

2. If Fred still needs to use his organization's TURN server, he should 
VPN in to work and then he'd be on the inside net and able to use the 
TURN server.

3. Perhaps send indications shouldn't be allowed for clients that have 
not successfully Allocated, rather than for clients that have not 
successfully CreatePermissioned. If the attacker cannot forge source 
addresses, then the behavior is the same as proposed. If the attacker 
can forge source addresses, then even in the proposed change they can 
still generate packets for any host that Fred has already done a 
CreatePermission for (which is potentially just as bad) *or* that Fred 
can be convinced by some means to do a CreatePermission for (e.g., DNS 
spoofing) (which leads us right back to where we were before).

Given the relatively low security of TURN, I think that an organization 
that lets outside users talk to a TURN server in their DMZ is going to 
have to protect the TURN server from talking to other things in the DMZ 
that it isn't supposed to reach anyway, no matter which proposal is adopted.

Since the proposal makes my client have to do more work for questionable 
benefit, I'm not in favor of it.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 06 Oct 2008 13:40:13 -0700

> the security of TURN without authentication is poor.
For the IT-organization-provided-proxy case, it needs to be as good as 
the HTTP proxy is. Which is to say "anyone who can speak port 80 from an 
inside address on the inside network interface is A-OK."

> fine. It is only if the ChannelBind fails that you will have to recover.
The amount of data the client sends to each peer is very small 
(potentially just a single packet) when doing session establishment. I 
don't want to pay for either the ChannelBind or CreatePermission cost to 
get set up to send a single packet to a candidate address that is quite 
likely to fail. Once I have a session established then yes, there's an 
overhead reduction to be had by doing ChannelBind at the cost of 
additional client logic that isn't needed for the native UDP case. Since 
in the IT-provided-proxy case we usually care more about PPS than BPS, 
the extra 32 bytes aren't actually that big a deal except when the proxy 
is on a different continent. But again, until I've done my initial round 
of packets to potential candidate addresses, received a response, and 
completed my 2nd pair of handshake, I need a lightweight way of talking 
to lots more addresses than I want to do ChannelBind for.
> do in a proprietary protocol that is different from the way TURN works?
If we did our own protocol we would make the permission mechanism be an 
up-front authentication followed by the ability to send to any address 
(and get the return traffic), and once we moved away from TURN we'd 
probably also use proxy-session-identifying tags so that the proxy could 
do the same kind of IP address mobility our transport protocol supports. 
(It would mean that the proxy could identify that this packet was from 
someone who had already allocated/authenticated but who has moved to a 
new IP address (perhaps plugged in at a podium ethernet jack after being 
on wireless) and then after a challenge/response switch the proxy 
permission to be associated with the new address). Right now, if a 
client is forced by IT to go through a TURN proxy, they lose the IP 
address mobility they would have had if they could talk native UDP to 
the outside.

Matthew Kaufman

---

From: Philip Matthews <[email-masked]>
Date: Thu, 9 Oct 2008 11:50:54 -0400

From your comments below, it seems that you want to not only send a  
packet to the peer, but also install a permission, so that a  
connectivity check packet can be received back from the peer. Thus it  
seems that your concern is not so much with the topic on this thread  
(whether a Send indication can be used when no permission exists), but  
rather with the decision to go with the CreatePermission approach  
rather than the Send request approach.

The concern Jonathan and I had with the SendRequest approach was that  
the STUN state machine inside the TURN client might retransmit the  
Send request if the Send response was lost. This could result in  
multiple copies of the data being sent to the peer.

I am guessing that, in your application, sending multiple copies of  
the data to the peer is not a problem, and you prefer the efficiency  
of using a single Send request rather than needing both a  
CreatePermission and a Send indication.

Am I correct?

- Philip

On Mon, 6-Oct-08, at 16:40 , Matthew Kaufman wrote:

> Philip Matthews wrote:
>>
>> Note that TURN does not REQUIRE that the server use authentication  
>> -- there may be situations where authentication is not required.  
>> However, the security of TURN without authentication is poor.
>>
> For the IT-organization-provided-proxy case, it needs to be as good  
> as the HTTP proxy is. Which is to say "anyone who can speak port 80  
> from an inside address on the inside network interface is A-OK."
>
>> there is a fair amount of data, then you will probably want to bind  
>> a channel to each peer to reduce overhead (from 36 bytes to 4  
>> bytes). Two notes when using channels. First, a ChannelBind creates  
>> both a channel and a permission. Second, there is nothing that  
>> stops your application from sending ChannelData messages  
>> immediately after sending the ChannelBind request. In most cases,  
>> everything will work fine. It is only if the ChannelBind fails that  
>> you will have to recover.
>>
> (potentially just a single packet) when doing session establishment.  
> I don't want to pay for either the ChannelBind or CreatePermission  
> cost to get set up to send a single packet to a candidate address  
> that is quite likely to fail. Once I have a session established then  
> yes, there's an overhead reduction to be had by doing ChannelBind at  
> the cost of additional client logic that isn't needed for the native  
> UDP case. Since in the IT-provided-proxy case we usually care more  
> about PPS than BPS, the extra 32 bytes aren't actually that big a  
> deal except when the proxy is on a different continent. But again,  
> until I've done my initial round of packets to potential candidate  
> addresses, received a response, and completed my 2nd pair of  
> handshake, I need a lightweight way of talking to lots more  
> addresses than I want to do ChannelBind for.
>> Do you have a suggestion for another way to do things? What would  
>> you do in a proprietary protocol that is different from the way  
>> TURN works?
> If we did our own protocol we would make the permission mechanism be  
> an up-front authentication followed by the ability to send to any  
> address (and get the return traffic), and once we moved away from  
> TURN we'd probably also use proxy-session-identifying tags so that  
> the proxy could do the same kind of IP address mobility our  
> transport protocol supports. (It would mean that the proxy could  
> identify that this packet was from someone who had already allocated/ 
> authenticated but who has moved to a new IP address (perhaps plugged  
> in at a podium ethernet jack after being on wireless) and then after  
> a challenge/response switch the proxy permission to be associated  
> with the new address). Right now, if a client is forced by IT to go  
> through a TURN proxy, they lose the IP address mobility they would  
> have had if they could talk native UDP to the outside.
>
> Matthew Kaufman
>
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Oct 2008 10:14:42 -0400

So I just got off the phone with Philip, we were talking about this, and 
here is an interesting idea.

As Philip points out, the CreatePermission is required if you want the 
far end to be able to send you a response to a message delivered via a 
Send indication. So, regardless of the question about whether you can do 
a Send prior to CreatePermission, there *will* need to be a 
CreatePermission for each unique IP address you want to send to, even if 
there will be just a single packet and response from that IP address.

The concern raised by Matthew applies to ICE as well; that for cases 
where there are a lot of candidates, you'll end up sending a 
connectivity check and a CreatePermission, thus increasing the number of 
packets sent for connectivity checks.

The solution we came up with for this is very simple. We allow 
CreatePermission to carry *multiple* XOR-PEER-ADDRESS attributes, which 
opens permissions to many IP addresses with one transaction. In the case 
of ICE, after the O/A exchange is done, each agent knows the full set of 
IP addresses it might eventually do a check to. Thus, it would do a 
single CreatePermission to all of them, and then proceed with the checks 
using Send indications. Once ICE completes, if a TURN candidate is 
selected, the client would do a CHannelBind for high volume 
transcations. With this solution, the CreatePermission mechanism imposes 
only a single packet overhead, independent of the number of candidates. 
It can be paralellized with the connectivity checks themselves, and thus 
has no impact on the latency of ICE.

This would work well in conjunction with the proposal that you cannot do 
a Send to a destination without previously doing a CreatePermission.

What do folks think of this solution?

-Jonathan R.

Philip Matthews wrote:
> rather with the decision to go with the CreatePermission approach rather 
> than the Send request approach.
> 
> the STUN state machine inside the TURN client might retransmit the Send 
> request if the Send response was lost. This could result in multiple 
> copies of the data being sent to the peer.
> 
> I am guessing that, in your application, sending multiple copies of the 
> data to the peer is not a problem, and you prefer the efficiency of 
> using a single Send request rather than needing both a CreatePermission 
> and a Send indication.
> 
> Am I correct?
> 
> - Philip
> 
>>> there may be situations where authentication is not required. 
>> the HTTP proxy is. Which is to say "anyone who can speak port 80 from 
>> an inside address on the inside network interface is A-OK."
>>
>> don't want to pay for either the ChannelBind or CreatePermission cost 
>> to get set up to send a single packet to a candidate address that is 
>> quite likely to fail. Once I have a session established then yes, 
>> there's an overhead reduction to be had by doing ChannelBind at the 
>> cost of additional client logic that isn't needed for the native UDP 
>> case. Since in the IT-provided-proxy case we usually care more about 
>> PPS than BPS, the extra 32 bytes aren't actually that big a deal 
>> except when the proxy is on a different continent. But again, until 
>> I've done my initial round of packets to potential candidate 
>> handshake, I need a lightweight way of talking to lots more addresses 
>> than I want to do ChannelBind for.
>> address (and get the return traffic), and once we moved away from TURN 
>> we'd probably also use proxy-session-identifying tags so that the 
>> proxy could do the same kind of IP address mobility our transport 
>> protocol supports. (It would mean that the proxy could identify that 
>> this packet was from someone who had already allocated/authenticated 
>> but who has moved to a new IP address (perhaps plugged in at a podium 
>> ethernet jack after being on wireless) and then after a 
>> challenge/response switch the proxy permission to be associated with 
>> the new address). Right now, if a client is forced by IT to go through 
>> a TURN proxy, they lose the IP address mobility they would have had if 
>> they could talk native UDP to the outside.
>>
>> Matthew Kaufman
>>
>>
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 16 Oct 2008 09:36:50 -0700

> What do folks think of this solution?

I am OK with this, but I am not sure that having multiple
XOR-PEER-ADDRESS attributes would work, because of this sentence in
rfc3489bis:

"Any attribute type MAY appear more than once in a STUN message.
Unless specified otherwise, the order of appearance is significant:
only the first occurance needs to be processed by a receiver, and any
duplicates MAY be ignored by a receiver."

I would suggest to allow XOR-PEER-ADDRESS (perhaps renamed to
XOR-PEER-ADDRESSES) to contain multiple addresses, simply repeating the
family, port and address field for each address.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 16 Oct 2008 13:27:10 -0400

> family, port and address field for each address.

Well, our idea was to take advantage of the "Unless specified  
otherwise ..." clause and specify that, for the XOR-PEER-ADDRESS  
attribute in the CreatePermission request, multiple occurrences _are_  
significant. [Option 1]

However, there are two other options:
2) Allow the XOR-PEER-ADDRESS attribute to contain multiple addresses  
for CreatePermission, but not for Send indication, Data indication, or  
ChannelBind, OR
3) Define a new attribute XOR-PEER-ADDRESSES, which is used only in  
CreatePermission, that allows multiple addresses. The existing XOR- 
PEER-ADDRESS would be used in Send indication, Data indication, and  
ChannelBind.

My personal preference is for 1. However, if implementors say "My  
stack won't allow option 1, because it assumes that only the first  
occurrence of an attribute is significant", then we could do option 3  
instead.

- Philip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Oct 2008 13:36:14 -0400

I'd suggest option 3 so that we don't violate existing rfc3489bis rules 
and don't introduce additional error cases when XOR-PEER-ADDRESS is used 
in other places.

-Jonathan R.

Philip Matthews wrote:
> Well, our idea was to take advantage of the "Unless specified otherwise 
> ..." clause and specify that, for the XOR-PEER-ADDRESS attribute in the 
> CreatePermission request, multiple occurrences _are_ significant. 
> [Option 1]
> 
> CreatePermission, that allows multiple addresses. The existing 
> XOR-PEER-ADDRESS would be used in Send indication, Data indication, and 
> ChannelBind.
> 
> My personal preference is for 1. However, if implementors say "My stack 
> won't allow option 1, because it assumes that only the first occurrence 
> of an attribute is significant", then we could do option 3 instead.
> 
> - Philip
> 
> 
> 
> 
> 
> 
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 16 Oct 2008 11:08:51 -0700

> and don't introduce additional error cases when XOR-PEER-ADDRESS is used

OK for me.

>> XOR-PEER-ADDRESS would be used in Send indication, Data indication,
>> and ChannelBind.
>>

---

From: Richard Aas <[email-masked]>
Date: Thu, 16 Oct 2008 21:13:28 +0200

> of an attribute is significant", then we could do option 3 instead.

I vote for option 1. From an implementors perspective, this option is
best aligned with encoding/decoding of existing address/port type of
attributes and thus easier to implement. Additionally I don't buy the
rfc3489bis violation argument as long as we have an "Unless specified
otherwise..." clause.

	Richard

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Oct 2008 16:11:30 -0400

Richard Aas wrote:
> attributes and thus easier to implement.

Also from an implementor's perspective, I vote for option 1.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Thu, 23 Oct 2008 19:28:08 -0400

On Thu, 16-Oct-08, at 13:27 , Philip Matthews wrote:

> attribute in the CreatePermission request, multiple occurrences  
> _are_ significant. [Option 1]
>
> 2) Allow the XOR-PEER-ADDRESS attribute to contain multiple  
> addresses for CreatePermission, but not for Send indication, Data  
> indication, or ChannelBind, OR
> occurrence of an attribute is significant", then we could do option  
> 3 instead.

I have seen two responses (from Simon and Richard) asking for option  
1. Marc said that is is OK with option 1, and Jonathan has told me  
privately that he is also ok with option 1. So unless someone raises a  
strong objection, TURN-11 will use option 1.

As Jonathan points out, this also works well with the proposal that  
you cannot do a Send to a destination without previously doing a  
CreatePermission, which was the original subject of this thread. Since  
we seem to have addressed the only concern with this second proposal,  
TURN-11 will also document this restriction.

Hopefully, these two issues are now closed.

- Philip