TURN: Send indication when no permission exists

[Philip Matthews]

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Jonathan Rosenberg]

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:
> 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
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

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

[Matthew Kaufman]

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

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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




_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Matthew Kaufman]

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.

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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

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
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Matthew Kaufman]

Meanwhile...

Philip Matthews wrote:

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

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

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Matthew Kaufman]

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

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


_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

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

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Jonathan Rosenberg]

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:

>  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."
>>
>>> 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.
>>>
>> 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 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
>>
>>
>>
>
> _______________________________________________
> Behave mailing list
> Behave@...
> https://www.ietf.org/mailman/listinfo/behave
>

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

[Marc Petit-Huguenin-2]

Jonathan Rosenberg wrote:

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

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: marc@... [RFC1855-compliant space for rent ]
Work: marc@...            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Philip Matthews]

On Thu, 16-Oct-08, at 12:36 , Marc Petit-Huguenin wrote:

> Jonathan Rosenberg wrote:
>> 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?
>
> 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.

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






_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Jonathan Rosenberg]

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:

>
> On Thu, 16-Oct-08, at 12:36 , Marc Petit-Huguenin wrote:
>
>> Jonathan Rosenberg wrote:
>>> 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?
>>
>> 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.
>
> 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
>
>
>
>
>
>
>

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