< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
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@xxxxxxxxxxx] 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 |