[reSIProcate] ACK relay question

[Robert Sparks]

I'm not sure I follow you on the changing behavior part - we might  
have gotten lost on the distinction between topmost route of the ACK  
we received or the ACK we sent. I was talking about the topmost Route  
hfv in the ACK we received.

This is what I would consider "right":

We should only forward and ACK if the topmost Route header field  
value in the ACK we received is a value we believe we might have put  
in a record-route some other time or, if there is not route header  
field, the RURI identifies a resource we are responsible for.

In a universe that was closer to perfect, we'd stop there.

But we need to add the "from" hack below (or something like it) to  
deal with those UAs that still have a notion of "default outbound  
proxy" without using preloaded routes.

RjS

On Feb 1, 2007, at 11:00 AM, Scott Godin wrote:

> 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
>
> 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/e75e5e6e/attachment.htm>