Project

General

Profile

Actions

Feature #2422

closed

Validate source IP address as sent by MS/SGSN

Added by laforge over 6 years ago. Updated about 6 years 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.


Files

Actions #1

Updated by laforge over 6 years ago

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

Updated by laforge over 6 years ago

  • Assignee set to laforge
Actions #3

Updated by laforge about 6 years ago

  • Assignee changed from laforge to pespin
Actions #4

Updated by pespin about 6 years ago

  • Status changed from New to In Progress

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

Actions #5

Updated by pespin about 6 years ago

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

Implemented and merged in osmo-ggsn 5b1ef9589ccb2507af06f6a65c341fe0f7564ab4

Actions #6

Updated by laforge about 6 years 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

Actions #7

Updated by pespin about 6 years 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.

Actions #8

Updated by laforge about 6 years 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.

Actions #9

Updated by pespin about 6 years 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.

Actions #10

Updated by pespin about 6 years ago

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

Merged, closing.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)