Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Sep 2019 11:27:31 -0400

On Mon, Jul 29, 2019 at 1:36 PM Joe Touch <[email-masked]> wrote:
>
> On 2019-07-29 10:09, Warren Kumari wrote:
>
> ...
>
> Just FYI, I sent email to IANA letting them know that ports 33435 -
> 33534 should probably be listed it as "Known Unauthorized Use".
> From some archaeology, 33434 is apparently 2^15 + 666, and the
> "standard" traceroutes use up to 100 ports.
> I based this on the Van Jacobson ([email-masked]) - 1988 which he
> "stole" (credited) from Steve Deering -- easiest location of code is:
> https://github.com/freebsd/freebsd/blob/master/contrib/traceroute/traceroute.c
>
> I don't much like referring to it as "Known Unauthorized Use" but
> that's technically what it is -- the important bit to me seems to be
> that we make in some way so they don't get handed out, exactly what
> they should be called is a less pressing problem.
>
>
> Although that's helpful to those seeing traffic on those ports, it does not prevent IANA from assigning those values when requested.
>
> The only way to do that would be to make them ASSIGNED. That happens by the process indicated in RFCs 6335 and 7605 and notably is not driven by this sort of "squatting".
>
> NOTE: at the time that code was originally developed (1988), that range was OK for such uses without registration, but times changed in 1992.
>
> That code ought to be fixed.

Yes, that is true -- that code ought to be fixed; however, it doesn't
change the fact that mtrace cannot realistically be deployed using
this port -- enabling it on a router breaks traceroutes through that
router, leading to asterisks (I'd thought that we'd agreed on that,
but while looking back through my mail on this topic, it's possible
I'd misunderstood, and you don't actually agree that this port isn't
fit *for this particular purpose*).

Just wanting to make sure we are all on the same page, and they MBONED
will be publishing a -bis, deprecating this RFC and publishing a new
one with a different port...

W
> Joe

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Sep 2019 09:28:59 -0700

Hi, Warren, 

> fit *for this particular purpose*).

No, I don't. I don't understand the issue. On machines where traceroute
is deployed, I would assume it is already possible to acquire those
ports (bind to them) as needed, at which point the only components that
don't play nice are those where mtrace isn't deployed yet. 

Now if you are saying you don't WANT to do that because you WANT to
support traceroute's use of squatted ports, that's not IANA's business
IMO - and, more importantly, it's not justification for changing a port.
IANA's policies on this are that squatter's use of ports are simply not
a factor at all. They can't be, otherwise there's no point in having an
assignment process. 

> one with a different port...

At best, that would requires releasing the current assignment, which
requires a statement as to the extent of the current deployment using
that assignment since 2012 and a plan for changing that codebase - all
this is described in RFC 6335. 

Joe

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Sep 2019 16:04:23 -0400

Hitoshi / MBONED,

Can you please explain in baby words (small enough that even I can
understand!) how the failures actually occur.

I keep going through it step by step, and it all makes sense... and
then suddenly I confuse myself and it all escapes... <insert confused
baby meme here>

Let's use this as the scenario (I'm using RFC1918 space because the
documentation prefix isn't really big enough for this).

I'm 10.0.0.1, and I'm running traceroute (from Linux / BSD box) to a
destination machine of 10.0.4.1. There are routers numbered 10.0.1.1,
10.0.2.1 and 10.0.3.1

Step 1: I send 3 packets with TTL=1, Dst 10.0.5.1, ports 33435,33436,33437.
The first hop router, 10.0.1.1 decrements the TTL, realizes that the
packet has now expired, and sends me back (Src 10.0.1.1, Dst 10.0.0.1)
3 ICMP TTL expired messages.
Traceroute draws:
traceroute to 10.0.4.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  2 ms  1 ms  0.8 ms

2: I now send 3 packets, with TTL=2,  Dst 10.0.5.1, ports 33438,33439,33440.
Router1 decrements the TTL and forwards it to Router2, which
decrements the TTL and sends back  (Src 10.0.2.1, Dst 10.0.0.1) 3 ICMP
TTL expired messages.
I see:
traceroute to 10.0.4.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  2 ms  1 ms  0.8 ms
 2  10.0.2.1 (10.0.2.1)  3ms  2 ms 5ms

3: I send 3 packets with TTL3, Dst 10.0.5.1, ports 33441,33442,33443
Router1 and router2 forward the packet, router3 expires it, I get a
TTL expired from 10.0.3.1, and now I see:
traceroute to 10.0.4.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  2 ms  1 ms  0.8 ms
 2  10.0.2.1 (10.0.2.1)  3ms  2 ms 5ms
 3  10.0.3.1 (10.0.3.1)  4 ms 5ms 3ms.

4: I send 3 packets with TTL=43, Dst 10.0.5.1, ports 33444,33445,33446.
The TTL is now high enough that it makes it to the end host. There is
nothing listening on the end host on ports 33444, 33445, 33446, and so
I get back (from 10.0.4.1) ICMP port unreachables for 33444, 33445,
33446. I know I've reached my destination, and I'm happy.
traceroute to 10.0.4.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  2 ms  1 ms  0.8 ms
 2  10.0.2.1 (10.0.2.1)  3ms  2 ms 5ms
 3  10.0.3.1 (10.0.3.1)  4 ms 5ms 3ms
 4  10.0.4.1 (10.0.4.1) 5ms 3ms 4ms

In all of the above steps the destination address of the traceroute
packet is the target of the traceroute.
A transit router decrements the TTL, and if is cannot forward the
packet it generates an ICMP unreachable -- but it doesn't care about
the destination port or IP. When the TTL is high enough that it
reaches the end host, the port number *is* important, because we don't
want the end host to actually accept the packet, we want it to instead
return an ICMP Port Unreachable (or admin prohibited, or something
else useful).

As far as I can see then, the only case where there might be an issue is:
1: the router running mtrace2 is the target of the traceroute (so it
is actually listening on the port) and
2: the router is the very first hop (that's the only case where the
port number will be 33435).

In this case, we would get an output showing:
traceroute to 10.0.1.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  *  1 ms  0.8 ms

(the first packet (port 33435) gets eaten by the mtrace2 process, but
the 2nd and 3rd packets will have ports 33436, 33437).

It was reported that enabling this protocol on routers where the
traffic ransites (e.g router1) breaks traceroute, but I've
sufficiently managed to confuse myself that I'm having a hard time
understanding *why* -- the packet isn't destined to the router, it is
destined for the target of the traceroute...

I'm sure I'm missing something obvious here, so, again, slowly and in
baby words please...

W

On Wed, Sep 11, 2019 at 12:29 PM Joe Touch <[email-masked]> wrote:
> No, I don't. I don't understand the issue. On machines where traceroute is deployed, I would assume it is already possible to acquire those ports (bind to them) as needed, at which point the only components that don't play nice are those where mtrace isn't deployed yet.
>
> Now if you are saying you don't WANT to do that because you WANT to support traceroute's use of squatted ports, that's not IANA's business IMO - and, more importantly, it's not justification for changing a port. IANA's policies on this are that squatter's use of ports are simply not a factor at all. They can't be, otherwise there's no point in having an assignment process.
>
>
> At best, that would requires releasing the current assignment, which requires a statement as to the extent of the current deployment using that assignment since 2012 and a plan for changing that codebase - all this is described in RFC 6335.
>
> Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 Sep 2019 16:13:07 -0400

[ TOP-POST]

Aaaaarggh! As Leonard pointed out (offlist, to save me the
embarrassment of being an idiot) I have a typo throughout this -- the
Dst is 10.0.4.1, not 10.0.5.1 (I'd initially had 2 and hosts, and 4
routers, but that was overly verbose, and so I removed the last
router, and forgot to renumber). Also, in Step 4, the TTL should
clearly be 4, not 43.
That'll larn me to try type long emails on a phone...

w

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 17 Sep 2019 10:23:40 +0900

Hooman,

Could you follow up this Warren's discussion?
Thanks.

Regards,

Hitoshi

> On Sep 14, 2019, at 5:13, Warren Kumari <[email-masked]> wrote:
> 
> [ TOP-POST]
> 
>

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 17 Sep 2019 16:48:20 +0000

Hi Hitoshi

Sorry for delay. Adding two of the Nokia engineers.

So I think you are seeing what we are pointing out, a packet to the port 33435 is lost. Even that this is a single packet still it would create confusion.

Larry and William from Nokia can comment in more details

Regards

Hooman

-----Original Message-----
From: Hitoshi Asaeda <[email-masked]> 
Sent: Monday, September 16, 2019 9:24 PM
To: Warren Kumari <[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>
Cc: Joe Touch <[email-masked]>; James A. (Jim) Stevens <james.a.stevens=[email-masked]>; MBONED WG <[email-masked]>
Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

Hooman,

Regards,

Hitoshi

>> decrements the TTL and sends back  (Src 10.0.2.1, Dst 10.0.0.1) 3 
>> ICMP TTL expired messages.
>> I see:
>> nothing listening on the end host on ports 33444, 33445, 33446, and 
>> so I get back (from 10.0.4.1) ICMP port unreachables for 33444, 
>> 33445, 33446. I know I've reached my destination, and I'm happy.
>> reaches the end host, the port number *is* important, because we 
>> don't want the end host to actually accept the packet, we want it to 
>> instead return an ICMP Port Unreachable (or admin prohibited, or 
>> something else useful).
>> 
>>> Yes, that is true -- that code ought to be fixed; however, it 
>>> doesn't change the fact that mtrace cannot realistically be deployed 
>>> using this port -- enabling it on a router breaks traceroutes 
>>> through that router, leading to asterisks (I'd thought that we'd 
>>> agreed on that, but while looking back through my mail on this 
>>> topic, it's possible I'd misunderstood, and you don't actually agree 
>>> that this port isn't fit *for this particular purpose*).
>>> 
>>> 
>>> 
>>> Just wanting to make sure we are all on the same page, and they 
>>> MBONED will be publishing a -bis, deprecating this RFC and 
>>> publishing a new one with a different port...
>>> 
>>> 
>> This is like putting rabid weasels in your pants, and later 
>> expressing regret at having chosen those particular rabid weasels and 
>> that pair of pants.
>>   ---maf
> 
> 
> 
> --

---

From: "Mcconnochie, William (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 17 Sep 2019 18:45:00 +0000

As per "It was reported that enabling this protocol on routers where the traffic ransites (e.g router1) breaks traceroute, but I've sufficiently managed to confuse myself that I'm having a hard time understanding *why* -- the packet isn't destined to the router, it is destined for the target of the traceroute..."

When the ttl expires but the destination address is not for the router the ttl expired on, then a time exceeded message is generated.
If the ttl expires and the destination address is for the router the ttl expires on then that is when a destination unreachable message is generated, however, if something else is listening on that port then you have an application conflict which is the problem at have with mtrace/traceroute and port 33435.

William

On 09/17/2019 12:48 PM, Bidgoli, Hooman (Nokia - CA/Ottawa) wrote:

Hi Hitoshi

Regards

Hooman

-----Original Message-----
From: Hitoshi Asaeda <[email-masked]><mailto:[email-masked]>
Sent: Monday, September 16, 2019 9:24 PM
To: Warren Kumari <[email-masked]><mailto:[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>
Cc: Joe Touch <[email-masked]><mailto:[email-masked]>; James A. (Jim) Stevens <james.a.stevens=[email-masked]><mailto:james.a.stevens=[email-masked]>; MBONED WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

Hooman,

Regards,

Hitoshi

On Sep 14, 2019, at 5:13, Warren Kumari <[email-masked]><mailto:[email-masked]> wrote:

[ TOP-POST]

w

On Thu, Sep 12, 2019 at 4:04 PM Warren Kumari <[email-masked]><mailto:[email-masked]> wrote:

Hitoshi / MBONED,

packet has now expired, and sends me back (Src 10.0.1.1, Dst
10.0.0.1)

W

On Wed, Sep 11, 2019 at 12:29 PM Joe Touch <[email-masked]><mailto:[email-masked]> wrote:

Hi, Warren,

On Mon, Jul 29, 2019 at 1:36 PM Joe Touch <[email-masked]><mailto:[email-masked]> wrote:

...

Just FYI, I sent email to IANA letting them know that ports 33435 -
33534 should probably be listed it as "Known Unauthorized Use".
From some archaeology, 33434 is apparently 2^15 + 666, and the
"standard" traceroutes use up to 100 ports.
I based this on the Van Jacobson ([email-masked]<mailto:[email-masked]>) - 1988 which he
"stole" (credited) from Steve Deering -- easiest location of code is:
https://github.com/freebsd/freebsd/blob/master/contrib/traceroute/tr
aceroute.c

Joe

---

From: "Mcconnochie, William (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 17 Sep 2019 19:55:58 +0000

Ignoring our internal processing :-)...you are correct.

Bottom line is that if you reach the destination then a destination unreachable message is generated with the icmp type set to 'port unreachable' but this will not occur if another application is listening on that port as the port is now reachable, i.e. in use.

William

On 09/17/2019 03:23 PM, Stojc, Stephane (Nokia - CA/Ottawa) wrote:
I think there might be a typo here:

Packets don't age out on the nodes they're destined to. The CPM code only decrements TTL when attempting to forward a packet. The final packet of a traceroute probe is expected to generate a "port unreachable", not a TTL expiry, since the packet is extracted under a generic "PKT_COPY_CODE_IP_EXP_CANT_HANDLE" copy code due to having a local IP. As the error type implies, the port must be unreachable on that final node (i.e. not in use) for this error to be generated.

Stephane

________________________________
From: Mcconnochie, William (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, September 17, 2019 2:45 PM
To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>; Hitoshi Asaeda <[email-masked]><mailto:[email-masked]>; Warren Kumari <[email-masked]><mailto:[email-masked]>; Boone, Larry (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>
Cc: Joe Touch <[email-masked]><mailto:[email-masked]>; James A. (Jim) Stevens <james.a.stevens=[email-masked]><mailto:james.a.stevens=[email-masked]>; MBONED WG <[email-masked]><mailto:[email-masked]>; Stojc, Stephane (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>
Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

William

Hi Hitoshi

Regards

Hooman

-----Original Message-----
From: Hitoshi Asaeda <[email-masked]><mailto:[email-masked]>
Sent: Monday, September 16, 2019 9:24 PM
To: Warren Kumari <[email-masked]><mailto:[email-masked]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]><mailto:[email-masked]>
Cc: Joe Touch <[email-masked]><mailto:[email-masked]>; James A. (Jim) Stevens <james.a.stevens=[email-masked]><mailto:james.a.stevens=[email-masked]>; MBONED WG <[email-masked]><mailto:[email-masked]>
Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

Hooman,

Regards,

Hitoshi

[ TOP-POST]

w

Hitoshi / MBONED,

W

Hi, Warren,

...

Joe

---

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Sep 2019 17:53:20 -0700

On Tue, Sep 17, 2019 at 12:56 PM Mcconnochie, William (Nokia -
> Bottom line is that if you reach the destination then a destination unreachable message is generated with the icmp type set to 'port unreachable' but this will not occur if another application is l…

Yes, that is what I also said in my explanation, but:
"As far as I can see then, the only case where there might be an issue is:
1: the router running mtrace2 is the target of the traceroute (so it
is actually listening on the port) and
2: the router is the very first hop (that's the only case where the
port number will be 33435).

In this case, we would get an output showing:
traceroute to 10.0.1.1, 64 hops max, 52 byte packets
 1  10.0.1.1 (10.0.1.1)  *  1 ms  0.8 ms"

This seems a *little* sad, and definitely suboptimal, but it is much
less concerning than what I'd initially understood. If this occurred a
few more hops out I'd actually view it as a larger issue...

W

> From: Mcconnochie, William (Nokia - CA/Ottawa) <[email-masked]>
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]>; Hitoshi Asaeda <[email-masked]>; Warren Kumari <[email-masked]>; Boone, Larry (Nokia - CA/Ottawa) <[email-masked]>
> Cc: Joe Touch <[email-masked]>; James A. (Jim) Stevens <james.a.stevens=[email-masked]>; MBONED WG <[email-masked]>; Stojc, Stephane (Nokia - CA/Ottawa) <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Sep 2019 20:29:26 -0700

FWIW, this is my understanding - i.e., at best, the conflict would only
indicate that a given hop hadn't been updated to support your code.
Which it won't do anyway, regardless of the assignment of a new port. A
new port thus doesn't aid in deployment.

Joe