Hi Ron,to your first point: in reality, it is actually slightly more complicated than this. If I run e.g. traceroute on my Mac, it will per default use UDP (Windows tracert e.g. would use ICMP Echo Requests) and it will have a little bit of payload (12 bytes all 0). It will use the same source port for all packets and _start_ at destination port _33435_ and increment the destination port number for every outgoing UDP packet. It will do this, to match every incoming Time Exceeded message with the outgoing UDP packet to correctly compute the RTT. Now, in the IANA registry, those ports are currently unassigned but in reality it is slighlty more complicated than having a single reserved port.
Now to your second point. For ICMP this is a non issue and I believe we agree on this. For TCP and UDP, what we suggest at the moment in the document is to reserve a port number for reverse traceroute (called the probe identifier, see section 4 and the IANA considerations section). As of now, it sits in the source port field, which we could move to the destination port field without losing any functionality. The good thing is, that we do not need to change that port for every outgoing packet, as does traceroute today. Moving it to the destination port however opens up another discussion point, as in principle, this could allow somebody to perform UDP hole punching. So chosing the source port was actually a conscious decision on our part, but this is a good discussion to have in the group. We already have suggestions what we could do, e.g. restrict the value ranges for the flow identier (as of now what's in the destination port) but I would gladly open up the discussion.
Now, for UDP, as a socket is identified by the 2-tuple, this is something we can discuss. But for TCP I believe it is not an issue, as the socket is identified by the 4-tuple and reserving a port should do the trick.
Best, Rolf Am 07.06.24 um 14:30 schrieb Ron Bonica:
Rolf,I don't believe that this is true. According to Section 3.4 of RFC 2151, Traceroute is aways directed towards an *invalid* port on the destination node. TCP and UDP ports 33434 are reserved for this purpose.I don't see any such restriction in your draft. Did I miss something?Ron------------------------------------------------------------------------ Hi Ron, you raise a valid point, which however is not specific to reverse traceroute but applies to regular traceroute just as well, since we perform the exact same operation. One way to deal with this is assign a port for this purpose just as for regular traceroute: https://urldefense.com/v3/__https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=131__;!!NEt6yMaO-gk!E-ykEBNpR2rNjoOUkPjIxU5n8mSBgySkexROpP52eUYXDgXVGu88eOOvzuXvb6MivXawy_Ckbv_6ea_QpuQg0GOaqLQ$ <https://urldefense.com/v3/__https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=131__;!!NEt6yMaO-gk!E-ykEBNpR2rNjoOUkPjIxU5n8mSBgySkexROpP52eUYXDgXVGu88eOOvzuXvb6MivXawy_Ckbv_6ea_QpuQg0GOaqLQ$> which is what we suggest in the document. For ICMP probes, this issue does not apply. Best, Rolf Am 06.06.24 um 16:32 schrieb Ron Bonica: > > Authors, > > Just a reminder regarding the one significant issue that was raised > during our phone call.... > > When a reverse traceroute messages reaches its destination (i.e., the> initiating node), what prevents it from being delivered to an application?> > > Ron > > > Juniper Business Use Only > > Juniper Business Use Only _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
