[reSIProcate] ACK relay question

[Robert Sparks]

This is a security question - it is not unlike forwarding "stray"  
responses.

The risk protected against is primarily avoiding exhaustion of local  
resources (particularly TCP connections) with the extra spice of  
avoiding being used to anonymize traffic (example, circumvent  
firewall protection by appearing to come from a different source  
address) used in a DoS attack against someone else.

In your scenario, it appears you aren't record-routing, but the ACK  
is still showing up at repro? Do you have a need to not record-route?

If you want to enable building with different policies about such  
things, I think I'd rather have it involve a code change that selects  
the policy rather than a command-line option.

RjS

On Feb 1, 2007, at 9:23 AM, Scott Godin wrote:

> 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 at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070201/926f08cc/attachment.htm>