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