-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Monday, September 08, 2008 5:20 PM
Cc: [email protected]
Subject: Re: [Sip-implementors] Question on proxy routing
2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Inaki,
>
> Actually, I think this the essence of SIP proxy, have you ever imagined why
> mid-dialog req get passed through proxy?
> IMO, after proxy populates the target(s) (usually, proxy would not
> responsible for the uri,since it's remote peer's contact uri, the target is
> just the same as req-uri), so proxy would just forward the req based on top
> route if any, or req-uri.
Yes, of course, but in that case the proxy is not responsible for the domain of
RURI as you said.
[RL] I think the main concern is why proxy must forward-on-top-route, change
req-uri or not is same.
> The forwarding-on-top-route policy ensure the routeset get traversed
> one-by-one.
>
> Most of proxies would have no idea of dialog, it just follow the steps to
> handle mid-dialog/out-of-dialog requests.
But they are full capable of knowing if a request is in-dialog by examining if
it has "To tag".
AFAIK, to avoid security risks a proxy usually forbids in-dialog requests ("To
tag") with a Route URI different of the proxy itself.
[RL] Yes, I think you can differentiate reqeust based on to tag.
But even you do this, there're still much risks left.
Suppose some bad guy change the whole Route header in mid-dialog req,
Does proxy need to remember all dialog state to ensure they are not
modified?
I think RFC3261's main/original intention is put most of complexity into
UAs, and just some dumb proxies sitting in the middle.
> And normally, there would no route header left when out-of-dialog
> arrives at proxy, the preloaded routeset is just a recommended way of
> RFC3261 to specify outbound proxy.
Well, but however it is a risk, isn't it?
Does make sense that a UAC or proxy adds a Route header but instead of routing
based on it, routes to a different host?
[RL] Yes, there're risks here.
So in real world, few implementations follow those sections
exactly/strctly,
IMO, proxy would better to check if the req is authorized to access
next-hop.
Thanks.
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors