Validate source IP address as sent by MS/SGSN
Right now, OpenGGSN simply decapsulates the GTP packet and injects it into the tun device, whether or not the IP source address matches the address it has provided to the MS during PDP context creation.
While this kind of verification is not required anywhre by the spec, it is of course good security practice to verify the IP source address and reject any packets that are spoofed, i.e. that have a source address that is not equal the PDP EUA (end user address) of that PDP context.
- File icmpv4-not-forwarded-after-tun.pcapng added
I added several validation tests in https://gerrit.osmocom.org/#/c/6158/.
However, I am having some issues having my setup forwarding the crafted ICMPv4 echo messages. They are seen in the tun4 interface but it seems kernel routing is dropping them before sending them to my eth device. ICMPv6 seems fine as far as I could notice.
I attach a small pcap file showing the problematic packets. It was done running only test GGSN_Tests.TC_pdp4_act_deact_gtpu_access with capture interface=any and further filtered in wireshark with "gtp || icmp || icmpv6".
- Frame 1 and 2: are the pdpd cntx create + response, all fine.
- Frame 3: the problematic ICMPv4 packet created by ttcn3 test is sent over GTP.
- Frame 4: As expected, osmo-ggsn unpacks it out of GTP and forwards it to the TUN interface (I see it if capturing only in tun4 iface, but I don't see it if I capture on my eth device).
- Frame 5 (and 10 to 21): Being sent by the kernel from my tun6 and tun46 ifaces (?).
- Frame 6: Test attemps to send an ipv4 icmp with wrong src addr (not equal to the one of the pdp context). We see osmo-ggsn drops it correctly (it's not forwarded out of GTP).
- Frame 7: Same as for frame 6, but this time we try to send an IPV6 ICMP RA over the pdp4 context, which osmo-ggsn drops too as expected.
So, the problem here is that I'm not seeing more packets after frame 4 showing the ICMPv4 being sent through eth and coming back from the server.