Subject: Re: [BEHAVE] Transport of ICMP errors in TURN

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 Dec 2007 18:07:51 -0500

Presumably this requires the TURN server to parse the ICMP to find the 
specific allocation, and thus client, to which the indication is sent, 
right?

Given that ICMP are frequently blocked by NAT and firewall anyway, I 
don't know how much this would get used.

Also this would really primarily be an optimization, since ICE works 
without getting the ICMP error. Indeed if you are getting ICMP errors on 
your TURN connectivity checks, ICE is likely to fail completely anyway 
in this case.

Generally I am in favor of keeping TURN as minimal as we can, and I 
don't see a compelling use case for this, so I'm inclined to say that we 
shouldn't do this. Can you give some example use cases where this would 
really improve things?

Thanks,
Jonathan R.

Marc Petit-Huguenin wrote:
> draft-ietf-mmusic-ice-17 section 7.1.2.1 says that "[a]gents MAY support
> receipt of ICMP errors for connectivity check."  Unfortunately there is
> no way to receive a ICMP error when the connectivity check is carried
> over TURN.  Here's an example:
> 
> +------ Client -----+
> ICE       Turn client                         Turn Server       Peer
>  | Binding Req |                                  |               |
>  |------------>| 0 Send(123, peer, Binding Req)   |               |
>  |             |--------------------------------->| Binding Req   |
>  |             |  0 Channel Confirmation Ind(123) |-------------->|
>  |             |<---------------------------------|        ICMP 3 |
>  |             |                                  |<--------------|
>  | Binding Req |                                  |               |
>  |------------>| 123 Binding Req                  |               |
>  |             |--------------------------------->| Binding Req   |
>  |             |                                  |-------------->|
>  |             |                                  |        ICMP 3 |
>  |             |                                  |<--------------|
>  :             :                                  :               :
> 
> 
> I suggest to add a new indication that will carry the ICMP content to
> the TURN client so the Binding transaction can fail earlier:
> 
> +------ Client -----+
> ICE       Turn client                         Turn Server       Peer
>  | Binding Req |                                  |               |
>  |------------>| 0 Send(123, peer, Binding Req)   |               |
>  |             |--------------------------------->| Binding Req   |
>  |             |  0 Channel Confirmation Ind(123) |-------------->|
>  |             |<---------------------------------|        ICMP 3 |
>  |             |  0 Icmp Ind(source, data)        |<--------------|
>  |      ICMP 3 |<---------------------------------|               |
>  |<------------|                                  |               |
> 
> 
> The new indication contains a PEER-ADDRESS attribute that contain the
> source IP address/port of the ICMP packet, some other attributes to
> carry the ICMP values (type, code and next-hop MTU) and a DATA attribute
> that contain the data copied from the original UDP packet.  The ICMP
> spec mandates to copy only the IP header and 8 additional bytes, i.e.
> the UDP header, which should be enough to match the Binding transaction
> if there is only one pending.  Some IP implementations returns even more
> data, so the STUN transaction Id could be available to find the transaction.
> 

-- 
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://www1.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 14 Dec 2007 17:42:14 -0800

> specific allocation, and thus client, to which the indication is sent,

Yes, one way to implement this is to use connected datagram sockets with
the SO_REUSEADDR socket option.  This is how I implemented it.

> shouldn't do this. Can you give some example use cases where this would

The main use case is the one described below, to accelerate the failure
of an ICE connectivity check (100ms instead of 7900ms).

Note that this proposal would be consistent with RFC 4787 section 9.

If there is too much resistance to thi schange, then it can be done as a
future extension of TURN, so clients interested in the ICMP packets can
request this feature from the TURN server.  Perhaps some text should be
added in the TURN I-D to explain what to do when receiving a ICMP errors
from the peer (ignore them).

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 15 Dec 2007 08:36:22 -0500

> of an ICE connectivity check (100ms instead of 7900ms).

My point is that, connectivity checks through TURN servers are not 
likely to fail; such checks are usually the last resort anyway. What I 
was asking for was a network topology and use case where this would 
allow ICE to succeed overall, and do so faster. Also keep in mind that 
subsequent checks may succeed before a previous one times out, and so 
you wouldn't normally go the entire 7900ms anyway.

-Jonathan R.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 15 Dec 2007 12:00:48 -0800

> you wouldn't normally go the entire 7900ms anyway.

No, I do not have such use case.