[reSIProcate] ACK relay question

Thu Feb 1 12:58:52 CST 2007

I'm worried we might still be off (because you felt it important to  
include that Note).

In the behavior I'm describing, we will STILL route to whatever the  
topmost route header says
if there's still one there, and in that case we will not look at RURI  
or From.

The checks against RURI and From that I've described happen only if  
there were no Route header
field values in the ACK we received. If there was one, and it pointed  
to us, we're not going to make that check
(though we would look at RURI to figure out where to send the message  
next).

RjS

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

> I was just referring to received ACKs.  I think what you propose  
> makes sense.  I just wanted to warn that there are situations when  
> we would have previously (existing code) forwarded the ACK, that we  
> will now not be doing (after I make these changes).  Note:   
> Previously 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 with checking Request uri or From header.
>
>
>
> Thanks for your help on this.
>
>
>
> Scott
>
>
>
> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> Sent: Thursday, February 01, 2007 12:18 PM
> To: Scott Godin
> Cc: Byron Campen; resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] ACK relay question
>
>
>
> 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/5d2fb409/attachment.htm>