> 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 :stuck_out_tongue_closed_eyes: ... 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 or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3891#issuecomment-2186543809
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3891/c2186543...@github.com>_______________________________________________
Kamailio (SER) - Development Mailing List
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
