[Kamailio-Devel] [ openser-Feature Requests-2726791 ] check r-r header of reply
Juha Heinanen
jh at tutpro.com
Thu Apr 2 18:35:10 CEST 2009
Iñaki Baz Castillo writes:
> a) UAC behind NAT (so it can receive SIP traffic from the proxy):
> In this case the 200 from the UAS contains spoofed RR pointing to target.
>
> UAC Proxy UAS (malicious) target
>
> ------ INVITE -------------> ------ INVITE + RR --------->
> <---- 200 (maicious RR) ---- <---- 200 (maicious RR) -----
> ------------------in-dialog-requests------------------------------------>
proxy should detect that.
> b) UAC behind NAT (so it can receive SIP traffic from the proxy):
> In this case the 200 from the UAS doesn NOT contain RR but a Contact
> pointing to target.
>
> UAC Proxy UAS (malicious) target
>
> ------ INVITE ----------> ------ INVITE + RR -------->
> <---- 200 (no RR) ------ <----- 200 (no RR) ---------
> ------------------------in-dialog-requests----------------------------->
same here.
> c) UAC with public IP (so it can receive SIP traffic from anywhere):
> In this case the 200 from the UAS doesn NOT contain RR but a Contact
> pointing to target, and the 200 is sent directly to the UAC.
>
> UAC Proxy UAS (malicious) target
>
> ------ INVITE ----------> ------ INVITE + RR -------->
> <---------------------- 200 (no RR) ----------------------
> ------------------------in-dialog-requests------------------------------>
> In case a), the proxy could check the RR as you suggest and convert
> the 200 into 4XX.
>
> In case b), the proxy coud check if RR does exist and drop the reply
> if there aren't (since the proxy knows that it added it in the
> request).
>
> In case c), there is nothing to do.
uac could check that 200 ok came from the same address where it send
the invite.
my point is that IF uac receives a reply from its proxy, it must be able
to trust its r-r header.
now proxy does not do any checking and as result, uac_replace_from
function, for example, is totally useless.
-- juha
More information about the Devel
mailing list