Atlas Sagan library and UDP tarceroute results: bug or feature?
Hello, I've just found that using Sagan library for analyzing UDP traceroute measurement results may produce incorrect results: 'target_responded' variable is not be set to 'True' if the source address of the traceroute reply is not the target address of the traceroute, but any other address that belongs to the node. (From the traceroute.py code: def target_responded(self): if self._target_responded is not None: return self._target_responded self._target_responded = False if self.hops and self.hops[-1].packets: destination_address = IP(self.destination_address) for packet in self.hops[-1].packets: if packet.origin and destination_address == IP(packet.origin): self._target_responded = True return self.target_responded ) I don't think that's a valid assumption that a target node is *always* choosing the probe packet's destination address as a reply source. In particular, in case of UDP packets addressed to anycast, it might fail because the node can reply from another address. In particular, rfc4443 (ICMP for IPv6) says: 2.2. Message Source Address Determination A node that originates an ICMPv6 message has to determine both the Source and Destination IPv6 Addresses in the IPv6 header before calculating the checksum. If the node has more than one unicast address, it MUST choose the Source Address of the message as follows: (a) If the message is a response to a message sent to one of the node's unicast addresses, the Source Address of the reply MUST be that same address. (b) If the message is a response to a message sent to any other address, such as - a multicast group address, - an anycast address implemented by the node, or - a unicast address that does not belong to the node the Source Address of the ICMPv6 packet MUST be a unicast address belonging to the node. == and in the same RFC source address selection for ICMP echo reply messages is defined: The source address of an Echo Reply sent in response to a unicast Echo Request message MUST be the same as the destination address of that Echo Request message. An Echo Reply SHOULD be sent in response to an Echo Request message sent to an IPv6 multicast or anycast address. In this case, the source address of the reply MUST be a unicast address belonging to the interface on which the Echo Request message was received. ==== So, I'm sending this email, first, to warn those of you who is using Sagan to analyze UDP traceroute results, and, secondly, to discuss, if Sagan behavior is a bug (I believe it is) or a feature ;) -- SY, Jen Linkova aka Furry
On 31/10/14 15:15, Jen Linkova wrote: I’ve just found that using Sagan library for analyzing UDP traceroute measurement results may produce incorrect results: ‘target_responded’ variable is not be set to ‘True’ if the source address of the traceroute reply is not the target address of the traceroute, but any other address that belongs to the node. Hi there, and sorry about the late reply on this. I’m the primary author on Sagan and I’ve been on vacation for the past couple weeks. This email was the topic of some debate in the office and we’ve arrived at a few suggestions that I’d like some community feedback on if anyone has two cents to throw this way: The proposal is to remove |target_responded| and introduce two new properties: * A boolean named |destination_ip_responded| to reflect the current behaviour of |target_responded| * A boolean named something like |last_hop_responded| or just |target_responded| representing whether the last hop was a response at all. What do you (and the others on this list) think of this? Making the change to Sagan is trivial, but I’d rather only do something like this once. I’d also happily audit and accept pull requests <https://github.com/RIPE-NCC/ripe.atlas.sagan> on GitHub if anyone fancies writing a patch themselves.
Hi Daniel, Thanks a lot for your response! On Mon, Nov 17, 2014 at 5:56 PM, Daniel Quinn <dquinn@ripe.net> wrote:
On 31/10/14 15:15, Jen Linkova wrote: The proposal is to remove target_responded and introduce two new properties:
A boolean named destination_ip_responded to reflect the current behaviour of target_responded
It's nice to have but IMHO it's optional as it's easy to compare destination_ip with the last responded hop ip if last_hop_responded is set to True.
A boolean named something like last_hop_responded or just target_responded representing whether the last hop was a response at all.
IMHO it would be very useful. BTW a feature request: would it be possible to have a way to distinguish between 'target did not respond/maxhops exceeded' and 'traceroute stopped because ICMP error message (but not Port Unreachable in case of UDP traceroute) received)?
What do you (and the others on this list) think of this? Making the change to Sagan is trivial, but I’d rather only do something like this once.
I’d also happily audit and accept pull requests on GitHub if anyone fancies writing a patch themselves.
-- SY, Jen Linkova aka Furry
participants (2)
-
Daniel Quinn -
Jen Linkova