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

From: "James A. (Jim) Stevens" <[email-masked]>
Date: Fri, 26 Jul 2019 14:11:40 -0500

On 2019-07-25 16:33, Joe Touch wrote:

! On 2019-07-25 15:05, Toerless Eckert wrote:
!
!  > so the destination port number is the safest identifier to
!  > rely on.
!
!   Why wouldn't the IP ID be equally "safe"? (you can set this even for
!   IPv6 that aren't fragments). You're supposed to get the Internet header
!   back...
!
!   > Ultimately, we should ask for IANA to put for the 254 port numbers
!   > following the traceroute assigned port number something like
!   > "reserved for tracroute", and maybe someone who wants an easy RFC
!   > number could write a one-pager outlining this scheme informationally
;-)]
!

RFC 6864 specifically mentions this use in 3.1 and recommends against it.
In particular, the RFC deprecates all uses of the IP ID field other than
for reassembly.

Jim

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Jul 2019 13:26:16 -0700

> On Jul 26, 2019, at 12:11 PM, James A. (Jim) Stevens <james.a.stevens=[email-masked]> wrote:
> 
> !   > number could write a one-pager outlining this scheme informationally ;-)]
> !
> 
> RFC 6864 specifically mentions this use in 3.1 and recommends against it.  In particular, the RFC deprecates all uses of the IP ID field other than for reassembly.

At the network layer, yes. But this would be at other layers AND only when the value could be set. 

Regardless, the rest of the returned packet ought to be enough. It’s 8 bytes after IP, which means things like multiple source ports or even different UDP checksums provide sufficient differences for multiple concurrent probes. 

Joe

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jul 2019 13:09:22 -0400

> !   > number could write a one-pager outlining this scheme informationally ;-)]

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.

W

> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

--
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: Mon, 29 Jul 2019 10:35:54 -0700

On 2019-07-29 10:09, Warren Kumari wrote: 

...

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

Joe

---

From: John Kristoff <[email-masked]>
Date: Mon, 29 Jul 2019 13:03:04 -0500

On Mon, 29 Jul 2019 17:09:22 +0000

> "standard" traceroutes use up to 100 ports.

The starting port may be 33434 now, but in my reading of history, it
wasn't always.  If you look at Van Jacobson's original code he has this:

  u_short port = 32768 + 666;

Which indeed does add to 33434.  However, when the probes start it
begins with this:

  send_probe(++seq, ttl, &t1);

and in that routine there is:

  outudp->uh_dport = htons(port + seq);

seq was initialized to zero, but it becomes one before the first probe
is sent, which means the first destination port in the original
traceroute was actually 32768 + 666 + 1 or 33435.

Now all modern traceroute implementations just seem to set the default
port to 33434 and start there.  I don't know that any of this really
matters a whit, but I guess it demonstrates bit errors can
happen.  :-)

The only explanation I've heard for the high numbered port is that it
was choosen as one that would likely, and hopefully not be in use.
I'm not sure if Van intended the 666 part as a joke or not.  Probably a
good question for Internet historians on the [ih] list.

Sorry for veering a bit off topic.

John