I didnt understand what you mean by offloading the IPsec work to an external entity. You mean IPSec creation is done by other entity (other than ims_ipsec_pcscf module)?

Yup. That whole thing through the kernel is not giving me enough flexibility for the scenario that I'm going after, so I had to do another one.

Also, the naming "trust-the-bottom-Via" doesnt go well in my opinion ("bottom-via" part I mean). While handling SIP REQUEST the first Via needs to be considered and in case SIP REPLY I think last Via needs to be considered

The existing functions use "first" and "last". "Top"/"bottom" seemed better to me, since "last" could mean last added, which would be the "top" one. Or "first" could be interpreted as first added, which would be "top". My version seems to be less controversial maybe?

Naming things it's hard 😝 ... let's just pick whatever we'd agree is less confusing for everyone.

I get the argument for first (a.i. top) Via on requests. Yet from the perspective of 3GPP security, there should be a single Via in any requests originating from the UE. Otherwise there is something spying between the UE and the security gateway of the P-CSCF. So I'd argue that the last (a.i. bottom) would be sufficient for all cases, with an extra check, based on local policy, to reject requests from the UE with more than 1 Via. Anyway, this is an ideal case, IRL one could argue that the P-CSCF has multiple parts and could merge Vias internally, etc, so I'd keep it flexible.

tl;dr - if you look from the UE's perspective, a P-CSCF using the bottom Via is protecting you better than one which uses the top one and as such might let someone do a man-in-the-middle attack on you. Makes sense?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.