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

["Mcconnochie, William (Nokia - CA/Ottawa)" <[e-mail]>]

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:

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.

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


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

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 <[e-mail]><mailto:[e-mail]>
Sent: Monday, September 16, 2019 9:24 PM
To: Warren Kumari <[e-mail]><mailto:[e-mail]>; Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]><mailto:[e-mail]>
Cc: Joe Touch <[e-mail]><mailto:[e-mail]>; James A. (Jim) Stevens <james.a.stevens=[e-mail]><mailto:james.a.stevens=[e-mail]>; MBONED WG <[e-mail]><mailto:[e-mail]>
Subject: Re: [MBONED] mboned: UDP port conflict mtrace/traceroute

Hooman,

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

Regards,

Hitoshi





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

[ 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

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


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 <[e-mail]><mailto:[e-mail]> wrote:


Hi, Warren,

On 2019-09-11 08:27, Warren Kumari wrote:

On Mon, Jul 29, 2019 at 1:36 PM Joe Touch <[e-mail]><mailto:[e-mail]> 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 ([e-mail]<mailto:[e-mail]>) - 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

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*).



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.


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...


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




--
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




--
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