Project

General

Profile

Feature #2422

Validate source IP address as sent by MS/SGSN

Added by laforge 9 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
08/02/2017
Due date:
% Done:

100%

Spec Reference:

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.

icmpv4-not-forwarded-after-tun.pcapng (2.49 KB) pespin, 01/30/2018 11:41 AM

History

#1 Updated by laforge 8 months ago

  • Subject changed from Validate source address as sent by MS/SGSN to Validate source IP address as sent by MS/SGSN

#2 Updated by laforge 8 months ago

  • Assignee set to laforge

#3 Updated by laforge 3 months ago

  • Assignee changed from laforge to pespin

#4 Updated by pespin 3 months ago

  • Status changed from New to In Progress

I already have a patch for this one, I'll test and submit tomorrow morning.

#5 Updated by pespin 3 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Implemented and merged in osmo-ggsn 5b1ef9589ccb2507af06f6a65c341fe0f7564ab4

#6 Updated by laforge 3 months ago

  • 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

#7 Updated by pespin 3 months ago

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.

#8 Updated by laforge 3 months ago

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.

#9 Updated by pespin 3 months ago

  • 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.

#10 Updated by pespin 3 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Merged, closing.

Also available in: Atom PDF