Add Traceroute Visualization Feature for Mini-Internet

[FuhrmannMartin]

As discussed with Tobias Bühler via email, I’m submitting this pull request to contribute the new traceroute visualization feature to the Mini-Internet project.

A description of the implementation is available at:
platform/docker_images/webserver/docs/

I’m happy to adjust or refine anything if needed and look forward to your feedback!

[buehlert]

Thank you, will have a look at it in the coming days.

[buehlert]

@FuhrmannMartin did not forget about this PR, hope to have time over the coming long weekend.

[buehlert]

Some high-level observations:

• Using the code in its current form, I was not able to get it to run
  • The traceroute page on the webserver loads nicely but running any traceroute cmd just leads to an empty response, i.e., just a small gray box without any content (under "Show raw output"). Would be good to show some error message instead.
  • If I understand it correctly, you run the traceroute cmd via docker exec from within the webserver container. However, at the moment, the webserver container has no access to the host docker socket and can therefore not execute the docker exec cmd. Did it work for you?
  • One fix would be to add something like -v /var/run/docker.sock:/var/run/docker.sock to the docker run cmd that starts the webserver (e.g., in website_setup.sh). However, it could be risky to give the webserver these capabilities. Assuming a student would be able to somehow run an arbitrary docker cmd on the server, they could crash the entire mini-Internet.
• To test a bit more, I added the "fix" from the previous point. Now I was able to run traceroute cmds and they were displayed as expected.
• At the moment, you run the traceroute cmds between routers and not between hosts. In general, we always advise to run traceroutes from the host containers. The explanation is a bit difficult but basically you can end up in the following situation:
  • Given that the IP subnet, used on an interface that conntects two ASes (normally something like 179.X.Y.Z/24), is not distributed into OSPF (a setup that also happens in the real Internet), routers/hosts that are not directly connected to this interface will not be able to reach the 179.X.Y.Z address. Assuming you start a traceroute on a router that has at least one external connection, it could happen that it selects the source IP address for the traceroute as the 179.X.Y.Z one (often the source IP is chosen randomly). As a result, traceroute packets will normally be able to reach the destination but the corresponding ICMP replies (once the TTL reaches zero) will be sent towards the 179.X.Y.Z address. As this address is normally not reachable, you will see a lot of * traceroute hops. I was able to observe this behavior with your tool.
  • Perhaps it would be better to start the traceroutes from a host instead (with this setup it is impossible to use a 179.X.Y.Z address as source IP).
• I did not yet test if a policy validation is correctly displayed on the webserver. I wonder if it would need a dedicated entry in the "Legend" box that is shown at the bottom of the page.

Would be good if you could improve these points.

[buehlert]

Is this change needed? Normally, we do not want to define the specific host IP address that should be used between two ASes that belong to student groups (hence e.g., an entry such as 179.3.4.0/24). In the lecture, we normally ask the students to discuss with their neighboring ASes to figure out which IPs they should use (similar to peering discussions in the real Internet).

[FuhrmannMartin]

In my opinion it is needed, yes.
The default setup in the master branch has all inter-AS connections already configured as defined in the aslevel_links_students text-file.
While developing the traceroute feature I was using the auto-configuration function to configure the student's ASes. Only after fixing this lines the inter AS-routing was working correctly for me.

3 LUGA Peer 4 LUGA Peer 179.3.4.0/24
4 LUGA Peer 3 LUGA Peer 179.3.4.0/24

Before the change both sides were assigned the same IP address as can be seen above, which was causing the problem I guess.

[buehlert]

Will look into that, thanks

[buehlert]

@FuhrmannMartin finally, I had some time for a more detailed look. Sorry for the delays. A lot is going on at the moment. See review above for feedback.

[FuhrmannMartin]

@buehlert thank you for your review!

• When creating a clean branch for the pull-request somehow the mounting of the Docker socket got lost in website_setup.sh. Just added the missing line.
  I will also run it without the fix and check if an error message can be displayed instead.
  Your concerns regarding this socket are understandable. That is why in the current implementation, the web-server only executes the docker exec command with fixed arguments. The inputs to the endpoint are controlled... there is white-list of allowed origin containers and also whether the target IP address is syntactically valid. With this validations I was considering it safe enough for a student environment. That said, I'm open to further hardening if needed.

• Regarding the dedicated entry in the "Legend" box:
  Currently, the user is notified when a policy violation is detected, see policy_violation.png. I will also add feedback for the case where no policy violation is detected, so users always some form of feedback, not only when a violation occurs.

• Ok, I can see the problem regarding the origin router. Currently only the routers are parsed from the configuration files... I will change it in a way so that only hosts can be selected as the origin of a traceroute and update the above mentioned white-list accordingly. In that case it will be easy to also add them to the destination drop-down menu.

I will come back to you once I find the time for implementation.

[buehlert]

@FuhrmannMartin some immediate reactions:

• Yes, I saw your whitelist approach. Perhaps it is good enough. Would prabably make most sense to quickly take into account some feedback from the PhD student who currently is responsible for the setup in our lecture. Will ping him once everything else is stable. I was mostly concerned that the webserver now has additional capabilities in general. Not sure how secure all our API calls are (not only in your traceroute part).
• Regarding the policy violation. Looks very nice, I think that is perfect this way.
• Looking forward to see how it works with hosts.

Thanks again for all your contributions.

[FuhrmannMartin]

@buehlert

Hello Tobias,

I just pushed the changes based on your feedback. Aside from the minor points we discussed earlier, traceroutes now originate from and target the hosts connected to the selected routers.

Two additional notes:

• The traceroute command currently limits the number of hops to 10. With the default setup, this seems sufficient, as I haven't encountered any routes exceeding this number yet. However, if the topology grows, the limit needs to be increased.

• I tested the backend by sending multiple requests simultaneously. With the current PID limit of 100, this allows for approximately 15 concurrent traceroute jobs. Depending on the expected request volume, it might be necessary to increase this PID limit when starting the web container via website_setup.sh. I guess at the end of the semester this could maybe not be enough :)

Best regards,
Martin

[buehlert]

Thank you, will have a look