Subject: [tram] Transport of ICMP errors in TURN

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 26 Aug 2015 04:29:19 -0600

During the presentation of the Path MTU Discovery Using STUN draft in Prague, there was some discussion on how ICMP can be received by the client when the PMTUD probes are sent through a TURN server.  Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008.  That was the case, according to my notes, but in fact the idea of tunneling the ICMP packets through the TURN server was proposed the year before, but for a different reason:

https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg

So my proposal is to add this into turnbis.  I can provide text.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Aug 2015 08:29:39 -0400

> So my proposal is to add this into turnbis.  I can provide text.

RFC 5766 section 2.6 <https://tools.ietf.org/html/rfc5766#section-2.6>
explains that ICMP not being relayed was a design decision to make it
possible to run a TURN server as an unprivileged user. That conclusion
is wrong for two reasons:

- With the BSD sockets API, some ICMP errors are translated into recv()
error codes. This means that it is always possible to relay at least
some subset of ICMP errors. (Not sure for TCP or IPv6, I'd need to check.)

- On Linux, which dominates the market of TURN server, one can receive
all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket
option.

So my conclusion is: yes, please. :)

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 27 Aug 2015 10:29:35 +0000

On 26 Aug 2015, at 14:29, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

- With the BSD sockets API, some ICMP errors are translated into recv()
error codes. This means that it is always possible to relay at least
some subset of ICMP errors. (Not sure for TCP or IPv6, I’d
need to check.)

It is possible by creating a new listen socket.

See: https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2

The code described in that ID works well and we have implemented it in most of our hard and soft clients.
Not sure about any performance issues when doing this on the server side though.

The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be AD sponsored, just need to have some more discussion in the security section regarding information leakage. This is particular hard in the intersection network troubleshooting and end user privacy. If you got any concerns or ideas please ping me. (Or maybe we can have chair approval to have the discussion on this list? If any that is..)

+1

But we need to carefully describe the security pitfalls. Some people might already be using a TURN server as mean to hide their “true” IP address. Any changes in the TURN spec that introduces a change in the server behaviour that affects the privacy aspect might potentially be risk to some users.

.-.
Pål-Erik

Simon

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Aug 2015 05:35:59 -0600

On 08/27/2015 04:29 AM, Pal Martinsen (palmarti) wrote:
> 
> On 26 Aug 2015, at 14:29, Simon Perreault
> <[email-masked]<mailto:[email-masked]>> wrote:
> 
> Le 2015-08-26 06:29, Marc Petit-Huguenin a écrit : During the
> presentation of the Path MTU Discovery Using STUN draft in Prague,
> there was some discussion on how ICMP can be received by the client
> when the PMTUD probes are sent through a TURN server.  Which reminded
> me that I worked on that problem when I proposed PMTUD over STUN,
> back in 2008.  That was the case, according to my notes, but in fact
> the idea of tunneling the ICMP packets through the TURN server was
> proposed the year before, but for a different reason:
> 
> RFC 5766 section 2.6
> <https://tools.ietf.org/html/rfc5766#section-2.6> explains that ICMP
> not being relayed was a design decision to make it possible to run a
> TURN server as an unprivileged user. That conclusion is wrong for two
> reasons:
> 
> - With the BSD sockets API, some ICMP errors are translated into
> recv() error codes. This means that it is always possible to relay at
> least some subset of ICMP errors. (Not sure for TCP or IPv6, I’d need
> to check.)
> 
> 
> See:
> https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2
>
>  The code described in that ID works well and we have implemented it
> in most of our hard and soft clients. Not sure about any performance
> issues when doing this on the server side though.
> 
> The STUNTrace ID is not a TRAM draft anymore. We will ask for it to
> be AD sponsored, just need to have some more discussion in the
> security section regarding information leakage. This is particular
> hard in the intersection network troubleshooting and end user
> privacy. If you got any concerns or ideas please ping me. (Or maybe
> we can have chair approval to have the discussion on this list? If
> any that is..)
> 
> 
> - On Linux, which dominates the market of TURN server, one can
> receive all ICMP errors as an unprivileged user with the
> IP(V6)_RECVERR socket option.
> 
> But we need to carefully describe the security pitfalls. Some people
> might already be using a TURN server as mean to hide their “true” IP
> address. Any changes in the TURN spec that introduces a change in the
> server behaviour that affects the privacy aspect might potentially be
> risk to some users.
> 

Can you elaborate on this? The proposed extension is to have the server send to the client an indication message that wraps the information for ICMP packets received by the server with only type 3, and perhaps type 12 for ICMPv4 and 1, 2 and 3 for ICMPv6, and that match a permission and contain an UDP header.

This indication message will contain a XOR-MAPPED-ADDRESS attribute that contains the same IP address/port that was in the CreatePermission/Send messages sent by the client (or in the CHANNEL-BIND request if channels are used).  There is no additional information leaked here.

Then the indication message should also contain a new attribute that contains the ICMP error.  That also does not reveal anything about the identity of the sender of the packet that triggered this ICMP packet.

- -- 
Marc Petit-Huguenin

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 27 Aug 2015 12:18:49 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit-
> Huguenin
> Sent: Wednesday, August 26, 2015 3:59 PM
> To: [email-masked]
> Subject: [tram] Transport of ICMP errors in TURN
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> During the presentation of the Path MTU Discovery Using STUN draft in
> Prague, there was some discussion on how ICMP can be received by the
> client when the PMTUD probes are sent through a TURN server.  Which
> reminded me that I worked on that problem when I proposed PMTUD over
> STUN, back in 2008.  That was the case, according to my notes, but in fact the
> idea of tunneling the ICMP packets through the TURN server was proposed
> the year before, but for a different reason:
> 
> So my proposal is to add this into turnbis.  

The proposal looks good to me.

> I can provide text.

Thanks, will update the draft.

-Tiru
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJV3ZT+AAoJECnERZXWan7E0JoQAILKCgPBsAbm5YbcIGnQW
> tC8
> xfi5j0lFXNtJvtVSKpC9MypTsusP7se2b/TDLzVMk02plduxmtIGw5LAlNhnosK8
> AhL2O3vJ1oZ7Nxyw10OXARbsY04XsWu9dLPxHpA+gs7r/IZFBMtMOJtGXZH3M
> GdQ
> lKvU30wSpVOTf6Fi5mTQePBPi1rDQd6tK++1jSehl1iqVgsAOTAGOwgN8jZTqGpi
> azFJzbAEqjd8q8Zj+PtGkQlK1A2YxRpLRaRVWChzef89iMwQiAktG7SsgYCbsYor
> GMdkpQCKZ/NEeDeVKld3OUyFh+MzQ5sUniqbQa3+LRIJ1p2/+QU9nti3kjLuvm
> b8
> jYnmOQKNS/jXkdZBvmmLtdZvg2ytYhjYZMEDQR5bVHhHNOQBZcCmnLtotoBO
> NaUs
> yyMOh/m7+ub0GFrfyF1oRZm9Jy5/4Z45GLGEZla4YmSxkUDPiVkyEPXz3LFdJdz
> o
> YXDYSzt+ryrG8ZSZIlNUTO0vK0NDwe5n7zApXlL5L6JnLLr3Eg3984SCNnJG6l8e
> nTdvL8aBg0ixsny0rmjOzwKRTrXXut/QrIuW5MLiQLWIDxuaFRuQlkoNxnVR2+V
> U
> UVbf2JoFLXFTskgf6kL4+LwVE/Z1mbf5v4Xj2upWWvG6KnFEVgsswwkxsgnlslAo
> AsZutBz1M7gIvw8UbJem
> =1Ku/
> -----END PGP SIGNATURE-----
> 
> [email-masked]

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 27 Aug 2015 12:20:59 +0000

I don't see a privacy problem with the proposal of Marc.

-Tiru
From: tram [mailto:[email-masked]] On Behalf Of Pal Martinsen (palmarti)
Sent: Thursday, August 27, 2015 4:00 PM
To: Simon Perreault
Cc: Marc Petit-Huguenin; [email-masked]
Subject: Re: [tram] Transport of ICMP errors in TURN

- With the BSD sockets API, some ICMP errors are translated into recv()
error codes. This means that it is always possible to relay at least
some subset of ICMP errors. (Not sure for TCP or IPv6, I'd
need to check.)

But we need to carefully describe the security pitfalls. Some people might already be using a TURN server as mean to hide their "true" IP address. Any changes in the TURN spec that introduces a change in the server behaviour that affects the privacy aspect might potentially be risk to some users.

.-.
Pål-Erik

Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 27 Aug 2015 13:01:02 +0000

> On 27 Aug 2015, at 13:35, Marc Petit-Huguenin <[email-masked]> wrote:
> 

If we limit this to deal with host unreachable and related problems I am fine with this. Having the argumentation you just did in the spec is useful. 

My main concern was if we wanted to turn the TURN server into some sort of ICMP gateway and allow the client to trigger all sort of network weirdness on the public side. 

Sorry about wearing the paranoia hat, just wanted to make sure this was understood and discussed.

.-.
Pål-Erik

> iQIcBAEBCAAGBQJV3vYaAAoJECnERZXWan7E+3MQAJiJa8dF1LLFw9edwiGE6jX6
> EIDiXOcTQIc6UBB9t+JTJcKPaSFD28khEenOY6fMCG9b3VDKuFWxEKi6d8yWTUp5
> Ijhr50sugfmLiS53+jAQEM5RiffJD+3pCcktRJn2Hjy2TNOu1ouPOhXtq/+EQXlX
> PC3j+qFoIYK1OM0cJiRH3DkGPgjNjgy0mQzOfoaSVC2AbCz8swbgj2rwuywyRy42
> cfIuqmUhD5lfp52Gt7pRI8aKlKeN3CKGQOf4LViO0JT+pi9Z50QKI/0hwOmF0Pz1
> I79iT1wt6V4JP7lCatdUk0r5zteXJIO/sUJXWvgmUtv/ginI1i9sV3GwcSBrYBP9
> O0NhEhRho/RIK+v4HvbHoUWn9Wr606rh44gVgDyoIYv04Yvte0i/wt/6UPSh5XeZ
> pMhBKcs8vsdhT6Q4fFE45IFtRDCVrhCT/hC6CRDvSCGkw0VW+98eZdsOJGuLTKan
> e6DWcHFV7tB1/aOr8jDsIyDjNnY4FGN1BfYtF7LqGdE+jNkSkCiDDV7Hd9QeG9vu
> VUlm5D9z6LBuHGbmuNHOmrZP8zi858XQa9Ta/3UKbotO8XErgEGv+dzRKXp/KpaI
> pTf2xry4tWNBdpiar3L9uG1qaUQRW47lk22N/XQvQJAGIPAuPxoAWSiGIMNp2jPu
> 803fI2FWofeSyGmPpUN9
> =OkNS

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 27 Aug 2015 13:49:28 +0000

A key part of TURN design was that it was not usable for running general purpose server that accepted traffic from anyone without first identifying who it is that you want to get the traffic from. So the client has to tell the TURN server which external hosts can send it traffic. 

Receiving ICMP violates this because you would need to accept stuff from sources you had not given permission to send you stuff. That allows TURN to be used to build generic servers which allows it to circumvent firewall policy. One of the reasons we invented TURN instead of using one of the other tunnel protocols was to not have this problem. 

> On Aug 27, 2015, at 6:20 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> I don’t see a privacy problem with the proposal of Marc.
>  
> -Tiru
> On 26 Aug 2015, at 14:29, Simon Perreault <[email-masked]> wrote:
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 27 Aug 2015 10:23:09 -0400

Le 2015-08-27 09:49, Cullen Jennings (fluffy) a écrit :
> 
> A key part of TURN design was that it was not usable for running
> general purpose server that accepted traffic from anyone without
> first identifying who it is that you want to get the traffic from. So
> the client has to tell the TURN server which external hosts can send
> it traffic.
> 
> Receiving ICMP violates this because you would need to accept stuff
> from sources you had not given permission to send you stuff. That
> allows TURN to be used to build generic servers which allows it to
> circumvent firewall policy. One of the reasons we invented TURN
> instead of using one of the other tunnel protocols was to not have
> this problem.

Good point.

That is easily solved by having the TURN server enforce permissions on
the 5-tuple of the ICMP error's encapsulated original packet. Exactly
the same way stateful firewalls do it.

Simon

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 27 Aug 2015 14:33:47 +0000

> On Aug 27, 2015, at 8:23 AM, Simon Perreault <[email-masked]> wrote:
> 

Yep, with that change it would be OK.

I find that many networks block ICMP for one reason or another thus one can not count on it working most of the time so it has really limited value for applications as they end up using a method that works all the time.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Aug 2015 08:38:56 -0600

>> Thanks, will update the draft.

First patch attached.  There is more modifications needed in section 12, but that's a good start to discuss that feature.

Thanks.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
From 7c6f26be7ca8740ae3bc9f9a87a8e201f0985917 Mon Sep 17 00:00:00 2001
From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Aug 2015 08:34:43 -0600
Subject: [PATCH] Add support for ICMP packets.

Change-Id: Ib55e6fe8e42ea53677281c1f3e2bd75dc80f488e
---
 turnbis/turnbis.xml | 115 +++++++++++++++++++++++++++++++++++++++++++++-------
 1 file changed, 100 insertions(+), 15 deletions(-)

diff --git a/turnbis/turnbis.xml b/turnbis/turnbis.xml
index af1a504..435c0ca 100644
--- a/turnbis/turnbis.xml
+++ b/turnbis/turnbis.xml
@@ -548,6 +548,13 @@ client                               server          A             B
         transport address uniquely identified the allocation, the server knows
         which client should receive the data.</t>
 
+        <t>Some ICMP packets arriving at the relayed transport address on the
+        TURN server may be converted into SendError indications and sent to
+        the client, with the transport address of the peer included in an
+        XOR-PEER-ADDRESS attribute and the ICMP type and subtype in a ICMP
+        attribute.  SendError indications are also send when using the channel
+        machanism.</t>
+
         <t>Send and Data indications cannot be authenticated, since the
         long-term credential mechanism of STUN does not support authenticating
         indications. This is not as big an issue as it might first appear,
@@ -758,23 +765,25 @@ client                               server          A             B
         the maximum amount of application data that can be sent without
         fragmentation.</t>
 
-        <t>Unfortunately, because servers implementing this version of TURN do
-        not relay ICMP messages, the classic path MTU discovery algorithm
-        defined in <xref target="RFC1191"></xref> is not able to discover the
-        MTU of the transmission path between the client and the peer. (Even if
-        they did relay ICMP messages, the algorithm would not always work
-        since ICMP messages are often filtered out by combined NAT/firewall
-        devices).</t>
+        <t>Unfortunately, because servers implementing this version of TURN
+        are not required to relay ICMP messages, the classic path MTU discovery
+        algorithm defined in <xref target="RFC1191"></xref> is not able to
+        always discover the MTU of the transmission path between the client and
+        the peer.</t>
 
         <t>So the client and server need to use a path MTU discovery algorithm
         that does not require ICMP messages. The Packetized Path MTU Discovery
         algorithm defined in <xref target="RFC4821"></xref> is one such
-        algorithm.</t>
-
-        <t>The details of how to use the algorithm of <xref
-        target="RFC4821"></xref> with TURN are still under investigation.
-        However, as a step towards this goal, this version of TURN supports a
-        DONT-FRAGMENT attribute. When the client includes this attribute in a
+        algorithm. <xref target="I-D.petithuguenin-tram-stun-pmtud"></xref>
+        is an implementation of RFC4821 that is using STUN to discover the
+        PMTUD, and so may be a suitable approach to be used in conjunction
+        with a TURN server.</t>
+
+        <t><xref target="I-D.petithuguenin-tram-stun-pmtud"></xref>
+        is an implementation of RFC4821 that is using STUN to discover the
+        PMTUD, and so may be a suitable approach to be used in conjunction
+        with a TURN server, together with the DONT-FRAGMENT attribute.  When
+        the client includes this attribute in a
         Send indication, this tells the server to set the DF bit in the
         resulting UDP datagram that it sends to the peer. Since some servers
         may be unable to set the DF bit, the client should also include this
@@ -1759,7 +1768,7 @@ client                               server          A             B
       </section>
     </section>
 
-    <section anchor="sec-sendanddata" title="Send and Data Methods">
+    <section anchor="sec-sendanddata" title="Send, Data and SendError Methods">
       <t>TURN supports two mechanisms for sending and receiving data from
       peers. This section describes the use of the Send and Data mechanisms,
       while <xref target="sec-channels"></xref> describes the use of the
@@ -1875,6 +1884,48 @@ client                               server          A             B
         with an indication that they were received from the peer whose
         transport address is given by the XOR-PEER-ADDRESS attribute.</t>
       </section>
+
+      <section anchor="sec-sending-senderror-indication"
+               title="Receiving an ICMP Packet">
+        <t>When the server receives an ICMP packet at a currently allocated
+        relayed transport address, the server verifies that the type
+        are either 3, 11 or 12 for an ICMPv4 packet or either 1, 2, or 3 for
+        an ICMPv6 packet. It also verifies that the IP packet in the ICMP
+        packet payload contain an UDP header.  If one of these conditions
+        fails, then the ICMP packet is slently dropped.</t>
+
+        <t>The server looks up the allocation associated with the relayed
+        transport address. The server then checks to see whether the set of
+        permissions for the allocation allow the relaying of the ICMP packet
+        as described in <xref target="sec-permissions"></xref>.</t>
+
+        <t>If relaying is permitted then the server forms and sends a
+        SendError indication. The SendError indication MUST contain both an
+        XOR-PEER-ADDRESS and an ICMP attribute. The ICMP attribute is set to
+        the value of type and code fields from the ICMP packet, and the
+        XOR-PEER-ADDRESS attribute is set to the IP address in the IP header
+        and to the ports in the UDP header, both found in the ICMP packet
+        payload. The SendError indication is then sent on the 5-tuple
+        associated with the allocation.</t>
+      </section>
+
+      <section title="Receiving a SendError Indication">
+        <t>When the client receives a SendError indication, it checks that
+        the SendError indication contains both an XOR-PEER-ADDRESS and an
+        ICMP attribute, and discards the indication if it does not. The client
+        SHOULD also check that the XOR-PEER-ADDRESS attribute value contains
+        an IP address with which the client believes there is an active
+        permission, and discard the SendError indication otherwise.</t>
+
+        <t>If the SendError indication passes the above checks, the client
+        signals the application of the error condition, along
+        with an indication that twas received from the peer whose
+        transport address is given by the XOR-PEER-ADDRESS attribute.</t>
+
+        <t>The application can make sense of the meaning of the  type and code
+        values in the ICMP attribute by using the family field in the
+        XOR-PEER-ADDRESS attributes,</t>
+      </section>
     </section>
 
     <!-- Sending and Receiving Data -->
@@ -2459,6 +2510,7 @@ client                               server          A             B
   0x007  :  Data              (only indication semantics defined)
   0x008  :  CreatePermission  (only request/response semantics defined
   0x009  :  ChannelBind       (only request/response semantics defined)
+  TBD    :  SendError         (only indication semantics defined)
 
 ]]></artwork>
       </figure>
@@ -2483,7 +2535,8 @@ client                               server          A             B
   0x0021: Reserved (was TIMER-VAL)
   0x0022: RESERVATION-TOKEN  
   TBD-CA: ADDITIONAL-ADDRESS-FAMILY  
-  TBD-CA: ADDRESS-ERROR-CODE]]></artwork>
+  TBD-CA: ADDRESS-ERROR-CODE
+  TBD   : ICMP]]></artwork>
 
         <postamble></postamble>
       </figure>
@@ -2727,6 +2780,34 @@ client                               server          A             B
         <t>The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate
         responses.</t>
       </section>
+
+      <section anchor="sec-icmp"
+               title="ICMP Attribute">
+        <t>This attribute is used by servers to signal the reason an UDP packet
+        was dropped. The following is the format of the ICMP attribute.</t>
+
+        <figure>
+          <artwork><![CDATA[       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Reserved                     |  Type       |  Code           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+]]></artwork>
+        </figure>
+
+        <t><list style="hanging">
+            <t hangText="Reserved:">This field MUST be set to 0 when sent,
+                and MUST be ignored when received.</t>
+
+            <t hangText="Type:">The field contains the value in the ICMP type.
+                Its interpretation depends wether the ICMP was received over IPv4
+                or IPv6</t>
+
+            <t hangText="Code:">The field contains the value in the ICMP code.
+                Its interpretation depends wether the ICMP was received over IPv4
+                or IPv6</t>
+        </list></t>
+      </section>
     </section>
 
     <section anchor="sec-stun-errors" title="New STUN Error Response Codes">
@@ -3612,6 +3693,8 @@ client                               server          A             B
           <t>DTLS support.</t>
 
           <t>More detail on packet translations.</t>
+
+          <t>Add support for receiving ICMP packets.</t>
         </list></t>
     </section>
 
@@ -3691,6 +3774,8 @@ client                               server          A             B
 
       <?rfc include='reference.RFC.5928'?>
 
+      <?rfc include="reference.I-D.petithuguenin-tram-stun-pmtud"?>
+
       <reference anchor="Port-Numbers"
                  target="http://www.iana.org/assignments/port-numbers">
         <front>
-- 
2.5.0

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Aug 2015 08:45:02 -0600

>> If we limit this to deal with host unreachable and related problems I am fine with this. Having the argumentation you just did in the spec is useful. 

OK, I'll propose text for the security consideration section

>> My main concern was if we wanted to turn the TURN server into some sort of ICMP gateway and allow the client to trigger all sort of network weirdness on the public side. 

No.  Only error ICMP are to be translated.  See the patch I just sent.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 27 Aug 2015 08:49:50 -0600

> Yep, with that change it would be OK.

I believe that the text in the patch I just sent does that.

> I find that many networks block ICMP for one reason or another thus one can not count on it working most of the time so it has really limited value for applications as they end up using a method th…

Yes, and that's OK - both ICE and PMTUD are designed to work without receiving ICMP, but work better if they do.

- -- 
Marc Petit-Huguenin