Differences
This shows you the differences between two versions of the page.
|
ep:labs:061:contents:tasks:ex4 [2025/04/08 11:18] radu.mantu |
ep:labs:061:contents:tasks:ex4 [2025/04/08 13:02] (current) cezar.craciunoiu [04. [10p] Bonus - Protocol Options] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ==== 04. [10p] Bonus - Protocol Options ==== | ==== 04. [10p] Bonus - Protocol Options ==== | ||
| + | <spoiler> | ||
| As you've probably already seen in the previous exercise, TCP uses protocol extensions (called options) in order to negotiate session parameters and improve overall performance. Note that this mechanism has existed since the very inception of the protocol approx. 30 years ago ([[https://datatracker.ietf.org/doc/html/rfc793#section-3.1|RFC793 - Transmission Control Protocol]]), with many being added post-factum. | As you've probably already seen in the previous exercise, TCP uses protocol extensions (called options) in order to negotiate session parameters and improve overall performance. Note that this mechanism has existed since the very inception of the protocol approx. 30 years ago ([[https://datatracker.ietf.org/doc/html/rfc793#section-3.1|RFC793 - Transmission Control Protocol]]), with many being added post-factum. | ||
| Line 16: | Line 17: | ||
| </html> | </html> | ||
| - | == Overarching Goal == | + | **Overarching Goal** |
| The first task is to modify outgoing traffic and include a Record Route option in an ICMP Echo Request. Check its description in [[https://datatracker.ietf.org/doc/html/rfc791|RFC791]] to understand what it does (and no, not "Loose/Strict Source and Record Route"... keep hitting that Find key). The packet structure will resemble that in the picture above. Don't worry; for this step, we'll give you a little help ;) | The first task is to modify outgoing traffic and include a Record Route option in an ICMP Echo Request. Check its description in [[https://datatracker.ietf.org/doc/html/rfc791|RFC791]] to understand what it does (and no, not "Loose/Strict Source and Record Route"... keep hitting that Find key). The packet structure will resemble that in the picture above. Don't worry; for this step, we'll give you a little help ;) | ||
| Line 24: | Line 25: | ||
| But let's take it step-by-step. | But let's take it step-by-step. | ||
| - | === Task A - Injecting IP Options === | + | **Task A - Injecting IP Options** |
| Remember talking about **iptables** extensions earlier? **Netfilter Queue** is one of them and will be relevant for this task. What it is, is an **iptables** target. What it does, it redirects each matched packet to a userspace process for evaluation and optionally, //modification//. | Remember talking about **iptables** extensions earlier? **Netfilter Queue** is one of them and will be relevant for this task. What it is, is an **iptables** target. What it does, it redirects each matched packet to a userspace process for evaluation and optionally, //modification//. | ||
| - | The userspace process receives each packet by polling a [[https://man7.org/linux/man-pages/man7/unix.7.html|Unix Domain Socket]]. After obtaining one, it can perform any type of analysis that it wants (e.g.: [[https://dl.acm.org/doi/pdf/10.1145/1151659.1159952|deep packet inspection]]) in order to reach a verdict. The verdict can be the already known built-ins (i.e.: //ACCEPT, DROP,// etc.) or it can redirect the packet to another queue, with another process listening. When setting the verdict, a modified packet can be provided to replace the original on its datapath through the kernel's network stack. | + | The userspace process receives each packet by polling a [[https://www.man7.org/linux/man-pages/man7/netlink.7.html|Netlink Socket]]. After obtaining one, it can perform any type of analysis that it wants (e.g.: [[https://dl.acm.org/doi/pdf/10.1145/1151659.1159952|deep packet inspection]]) in order to reach a verdict. The verdict can be the already known built-ins (i.e.: //ACCEPT, DROP,// etc.) or it can redirect the packet to another queue, with another process listening. When setting the verdict, a modified packet can be provided to replace the original on its datapath through the kernel's network stack. |
| Enter [[https://github.com/RaduMantu/ops-inject|ops-inject]]. This is a tool (that's still under development, mind you) that allows the annotation of matched packets with IP/TCP/UDP options. Why is this tool simple to use: all you have to do is provide a sequence of bytes representing the [[https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml|codepoints]] of the options that you want to append. This byte stream is passed to an internal decoder that //expands// each byte into a fully-fledged option, albeit in accordance to an arbitrary implementation. Once you clone the repo, you should look over two sources in particular: | Enter [[https://github.com/RaduMantu/ops-inject|ops-inject]]. This is a tool (that's still under development, mind you) that allows the annotation of matched packets with IP/TCP/UDP options. Why is this tool simple to use: all you have to do is provide a sequence of bytes representing the [[https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml|codepoints]] of the options that you want to append. This byte stream is passed to an internal decoder that //expands// each byte into a fully-fledged option, albeit in accordance to an arbitrary implementation. Once you clone the repo, you should look over two sources in particular: | ||
| Line 99: | Line 100: | ||
| From this point onward, it's all you! :) | From this point onward, it's all you! :) | ||
| - | === Task B - Traffic capture === | + | **Task B - Traffic capture** |
| Run the same experiment with ICMP Echo Request again, but this time capture the traffic using **tcpdump** and write it to a //pcap capture file//. | Run the same experiment with ICMP Echo Request again, but this time capture the traffic using **tcpdump** and write it to a //pcap capture file//. | ||
| Line 119: | Line 120: | ||
| </solution> | </solution> | ||
| - | === Task C - Route extraction === | + | **Task C - Route extraction** |
| Use **tshark** to extract the Record Route payload of ICMP Echo Replies from the created //pcap//. \\ | Use **tshark** to extract the Record Route payload of ICMP Echo Replies from the created //pcap//. \\ | ||
| Line 136: | Line 137: | ||
| </solution> | </solution> | ||
| - | === Task D - AS lookup === | + | **Task D - AS lookup** |
| Write a //bash script// starting from your **tshark** command. The script must perform an AS lookup and display information about each registered hop (e.g.: IP, AS name, etc.), for all packets in the //pcap//. Run the script. What do you notice? | Write a //bash script// starting from your **tshark** command. The script must perform an AS lookup and display information about each registered hop (e.g.: IP, AS name, etc.), for all packets in the //pcap//. Run the script. What do you notice? | ||
| Line 263: | Line 264: | ||
| </solution> | </solution> | ||
| - | === Task E - AS lookup (part II) === | + | **Task E - AS lookup (part II)** |
| As you might have noticed during the previous task, even DigitalOcean uses CloudFlare. | As you might have noticed during the previous task, even DigitalOcean uses CloudFlare. | ||
| Line 276: | Line 277: | ||
| UPB (localhost) 10.5.0.1 | UPB (localhost) 10.5.0.1 | ||
| </code> | </code> | ||
| + | |||
| + | </spoiler> | ||
