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

[Warren Kumari <[e-mail]>]

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