Subject: Re: [tram] STUNTrace Draft

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 2 Mar 2015 12:35:28 +0000

On 27 Feb 2015, at 17:02, Benjamin Schwartz <[email-masked]<mailto:[email-masked]>> wrote:

How widely deployed (and enabled) is this kind of ICMP error reporting (e.g. TTL exceeded)?  My impression, consistent with your security section, is that many network administrators disable this functionality.

That is very good question.

From my perspective most ISPs respond back with a proper ICMP message. Once the packets start to hit the “cloud boundaries” off google, amazon, akamai and so on you are likely to get no answers.

Our main motivation for writing this up is to have a nice troubleshooting tool for your own internal network and out to your ISP. Combining information from RTP/RTCP regarding latency and packet drop with the path information given by STUNTrace enables a network administrator a pretty nice view of potential problems in the network.

.-.
Pål-Erik

On Fri, Feb 27, 2015 at 10:39 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

We just uploaded a new draft, STUNTrace (http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00). It describes how to du “in-band” tracreoute on the same 5-tuple as you send media using STUN probe packets and ICMP responses.

It aligns with https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00 using STUN as a probe to discover network properties.

We added code examples in the appendix to clarify how ICMP can be received by applications without requiring admin privileges. We still lack Windows examples, so help with that is appreciated. ICMP test code (not implementing this draft) can be found at: https://github.com/palerikm/ICMPTest

Questions and comments are of course welcome.

.-.
Pål-Erik

Begin forwarded message:

A new version of I-D, draft-martinsen-tram-stuntrace-00.txt
has been successfully submitted by Paal-Erik Martinsen and posted to the
IETF repository.

Name: draft-martinsen-tram-stuntrace
Revision: 00
Title: STUN Traceroute
Document date: 2015-02-27
Group: Individual Submission
Pages: 12
URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntrace-00.txt
Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00

Abstract:
  After a UDP protocol such as RTP determines a network path is
  experiencing problems, a traceroute is often useful to determine
  which router or which link is contributing to the problem.  However,
  operating system traceroute commands follow a different path than the
  actual UDP flow which complicates troubleshooting.  A superior method
  is shown which is absolutely path-congruent with the UDP protocol
  itself, works on IPv4 and IPv6, and does not require administrative
  privileges on most operating systems.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

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

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 9 Mar 2015 09:59:19 -0700

On 02-Mar-2015 04:35 AM, Pal Martinsen (palmarti) <[email-masked]> wrote: 
> 
>> On 27 Feb 2015, at 17:02, Benjamin Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Nothing else will work inside those networks, either.  They are blocking network diagnostic packets on purpose, for business reasons and to discourage learning the network topology.  *shrug*.   But traceroute works for me at airports, hotels, coffee shops, enterprises, and home networks; users and network administrators expect traceroute to work.

> Our main motivation for writing this up is to have a nice troubleshooting tool for your own internal network and out to your ISP. Combining information from RTP/RTCP regarding latency and packet dr…

Yeah, just like we all use traceroute to diagnose problems all the time, this provides the same sort of information, except STUNTrace has the advantage of being path-congruent with the RTP media (unlike standalone traceroute utilities).

-d

> 
> .-.
> Pål-Erik
> 
>> On Fri, Feb 27, 2015 at 10:39 AM, Pal Martinsen (palmarti) <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi,
>> 
>> We just uploaded a new draft, STUNTrace (http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00 <http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00>). It describes how to du “in-band” tracreoute on the same 5-tuple as you send media using STUN probe packets and ICMP responses. 
>> 
>> It aligns with https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00 <https://tools.ietf.org/html/draft-petithuguenin-tram-stun-pmtud-00> using STUN as a probe to discover network properties.
>> 
>> We added code examples in the appendix to clarify how ICMP can be received by applications without requiring admin privileges. We still lack Windows examples, so help with that is appreciated. ICMP test code (not implementing this draft) can be found at: https://github.com/palerikm/ICMPTest <https://github.com/palerikm/ICMPTest>
>> 
>>> URL:            http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntrace-00.txt <http://www.ietf.org/internet-drafts/draft-martinsen-tram-stuntrace-00.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/ <https://datatracker.ietf.org/doc/draft-martinsen-tram-stuntrace/>
>>> Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00 <http://tools.ietf.org/html/draft-martinsen-tram-stuntrace-00>
>>> 
>>> 
>>> Abstract:
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tram <https://www.ietf.org/mailman/listinfo/tram>
>> 
>> 
> 
> [email-masked]