Paul Kyzivat wrote: > 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?
Yes, but I think chances that things work out the way we'd want them to are slim. In the case where the request is out-of-dialog the retransmitted request will be treated by the UAS as a merged request and thus is rejected with a 482 response [3261, 8.2.2.2] while the original request gets the "real" response. If it's a mid-dialog request it would look like a new transaction and so would likely be rejected because the CSeq is not incremented. Anders > > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
