Re: [reSIProcate] ACK relay question

[Byron Campen <bcampen@xxxxxxxxxxxx>]

Well, we need to take care that we do not forward ACK with no Route headers, and a Req-Uri that points at us, or else we'll loop. Other than that, this should be okay. Just be forewarned, forwarding an ACK with no Route headers is risky, because if someone sets up a rogue DNS server, they can get us to loop (they set up a phony domain name and either alias it to one of ours, or point it directly to our server).

Best regards,

Byron Campen

Hi Byron,

 

You made the following comment RequestContext:

// !bwc! Someone is using us to relay an ACK, but host in

// From isn't ours, host in request-uri isn't ours, and no

// Route headers. Refusing to do so.

 

I’m curious why we have this code in repro – is this supposed to protect us from some sort of attack, or some security issues?

 

We have a case where we are modifying the From headers of requests sent through repro, in order to get the display on end UA’s the way we want it.  This chunk of code ends up dropping our ACKS if the domain in the from is not “owned” by repro.  Note:  it is common for the request uri to not match our domain, when routing using a mid-dialog request by using the contact header – since it is quite common to contain the ip address of the UA not the registered AOR.

 

I’m thinking of providing a command line option – something like “forward all ACKs”, in order to disable this checking.  Any concerns?

 

Scott

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel@xxxxxxxxxxxxxxxxxxxx

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature