Feature #2422
closed
Validate source IP address as sent by MS/SGSN
Added by laforge over 6 years ago.
Updated about 6 years ago.
Description
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.
Files
- Subject changed from Validate source address as sent by MS/SGSN to Validate source IP address as sent by MS/SGSN
- Assignee changed from laforge to pespin
- Status changed from New to In Progress
I already have a patch for this one, I'll test and submit tomorrow morning.
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Implemented and merged in osmo-ggsn 5b1ef9589ccb2507af06f6a65c341fe0f7564ab4
- Status changed from Resolved to In Progress
- % Done changed from 100 to 90
I just noticed we don't have a ttcn3 test for this yet. Should be super easy to add and helps us to ensure this kind of bug doesn't reappear
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.
your ICMPv4 packet in frame 3/4 doesn't have a header checksum set. it's 0x0000 which of course the kernel IP stack will discard. ICMP checksums are not optional, unlike UDP.
- Status changed from In Progress to Feedback
Thanks, that was the issue. I submitted a new version. This one can be closed as soon as we merge it.
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Also available in: Atom
PDF
