[BEHAVE] Transport of ICMP errors in TURN

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.

-- 
Marc Petit-Huguenin           [                                 ]
Home: marc@petit-huguenin.org [RFC1855-compliant space for rent ]
Work: marc@8x8.com            [                                 ]
[                                                               ]

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