This is definitely not my area of expertise. But consider a related
situation:
- there is a proxy between the UAC and UAS
- the proxy crashes before forwarding the 180 response
to the initial INVITE
- the UAC then tries an alternative proxy and
retransmits the INVITE to it
- this gets to the UAS from a different address
The difference here is that when the second invite reaches the UAS, it
is a different transaction, because it has a different branch address.
So perhaps in the cases you are considering, even if there is no proxy,
when the retransmission is via a different address there should be a new
branch address, making it a different transaction.
Does that make any sense?
Thanks,
Paul
Iñaki Baz Castillo wrote:
> El Lunes, 14 de Julio de 2008, Anders Kristensen escribió:
>
>>> But I'm not speaking about autorization decisions, I'm just suggesting
>>> the case in which a retransmission arrives to the UAS from a different
>>> address so, where to send future responses in this transaction? to the
>>> original request source address? to the new request (retransmission)
>>> source address? just it.
>> I understand what you're saying. The point I was trying to make is just
>> that *if* your SIP node were making policy decisions based on source IP
>> then an attacker might find it useful to exploit the fact that you
>> modify the destination of response. He'd do this by spoofing a source
>> address of A:a in the first request to get your node to process the
>> request using policy X and then he'd send a retransmission with source
>> address B:b to get you to send the response to where he can easily get
>> to it, e.g. the actual sending node. I think this would make that kind
>> of spoofing attacks much easier to mount.
>
> Good point. In fact, I suppose that policies based on source IP are done at
> application/core layer, so the transaction layer shouldn't allow a
> retransmission from a different source IP that would be rejected by the core
> layer.
>
> So, then I'll drop/ignore any retransmission from a different address.
>
> Thanks a lot for your explanation.
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
