[reSIProcate] ACK relay question

[Scott Godin]

The way is works right now, is that if there are any route headers
present (after we have removed ourselves from Top route, if present) -
we forward the ACK on to this destination, without checking if
RequestUri or from are ours.  If I implement what you are suggesting we
change this behaviour.  Just to be clear:  we only forward ACKS if we
are in top route or the requesturi or from are ours?

 

Scott

 

From: Robert Sparks [mailto:rjsparks at nostrum.com] 
Sent: Thursday, February 01, 2007 11:51 AM
To: Scott Godin
Cc: Byron Campen; resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] ACK relay question

 

Add that Route header pointed to this proxy and I think you're ok.

 

RjS

 

On Feb 1, 2007, at 10:45 AM, Scott Godin wrote:





Thanks Robert.  Actually we are record routing - but by the time the
code checks if there is a Route header (in RequestContext)- we have
already called RemoveTopRouteIfSelf.  Maybe I just need to fix it, so
that it allows the ACK forwarding as long as there was a Route header,
when we received the ACK.  Sound good?

 

Scott

 

From: Robert Sparks [mailto:rjsparks at nostrum.com] 
Sent: Thursday, February 01, 2007 11:02 AM
To: Scott Godin
Cc: Byron Campen; resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] ACK relay question

 

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
<mailto:resiprocate-devel at list.resiprocate.org> 

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
<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/41138b55/attachment.htm>