Feature #5814
opentunmap: more concisely match on GTP-U packets
0%
Description
For tunmap, we have a netfilter rule that so far matches on UDP traffic with the octets [4..7] matching the GTP TEID.
To avoid non-GTP-U packets to match this rule inadvertently, consider:
(1) add to the rule a match on the local GTP-U port 2152 -- this port number is fixed in the GTP specification.
(2) add matches on distinct GTP-U packet header traits. Some ideas, in pseudocode, from looking at a trace in wireshark:
- GTP v1:
udp[0] & 0b11100000 == 0b00100000
- protocol = GTP:
udp[0] & 0b00010000 == 0b00010000
- length:
uint16(udp[2..3]) == udp.payload_len - 8
(1) probably suffices to eliminate all possible false positives. The GTP port number is fixed, and it is reasonable to assume that all traffic arriving on it is at least intended to be GTP-U.
(2) is probably more of a way to discard invalid packets -- not sure if we want to do that at all, it would probably be better to leave classification of packets to the remote receiver. It is unlikely for an admin to notice sporadic invalid GTP when these packets are silently dropped halfway. Seems much better to get an error log on the receiving side.
Updated by laforge over 1 year ago
On Tue, Dec 06, 2022 at 07:09:47PM +0000, neels wrote:
(1) add to the rule a match on the local GTP-U port 2152 -- this port number is fixed in the GTP specification.
IMHO, in general the entire tunmap chain should only be called for packets with the GTP destination port number.
So that kind of match is executed once, and if it matches, the tunmap chain is called.
(2) add matches on distinct GTP-U packet header traits. Some ideas, in pseudocode, from looking at a trace in wireshark:
I'm not sure if it's worth doing that. I think it's reasonably safe to assume traffic for UDP port 2152
arriving on an UPF is GTP.
