2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Franz,
>
> IMO, the proxy need first replace the req-uri with target, and forward
> the request to next hop based top route.
>
> The reason is as per RFC3261
>
> 1)Proxy first Determining Request Targets based on req-uri
> 2)then forward the req
> 2.1) update the req-uri with target(16.6 Request Forwarding item 2)
> 2.2) forward the req based on top route or req-uri (16.6 Request
> Forwarding item 7)
Well, I couldn't believe this but after re-read that section it seems
to be the expected behaviour (behaviour expected just for people
writting RFC's in other planets, not for any common user/implementor
in this real world).
IMHO it makes no sense at all that the UAC decides how the proxy
responsible for the AoR must forward the request to the destination
contact. It's supposed that the proxy knows that info better than any
other element since the proxy can ask the location service.
Maybe there is a hyper-exotic case in which this behaviour makes sense
(defined probably in a not implemented draft), but IMHO this is a
security risk. Imagine the following case:
- User A (a bad user) sends an INVITE to proxy P:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Route: <sip:[EMAIL PROTECTED];user=phone>
- The INVITE arrives to proxy P who is responsible for that domain so
asks the location service and finds the target
"sip:[EMAIL PROTECTED]".
- But there is a Route header, and note that is a STRICT ROUTER since
there is no "lr" parameter.
- Then the proxy must send the request to gateway_pstn in strict route
mode so it generates the following request and sends it to
gateway_pstn:
INVITE sip:[EMAIL PROTECTED];user=phone SIP/2.0
Route: <sip:[EMAIL PROTECTED]>
- The INVITE arrives to gateway_pstn who is simpler (it will not
perform those strage and exotic operations) and probably will ignore
the "Route" header.
- So we have a call to the PSTN, probably not properly accounted by
the proxy P since it thought it was a call to a local SIP user.
Well, this is the reason that requests with RURI domain matching proxy
domains and a Route header should be forbidden in the proxy. But it's
RFC3261 who permits so dangerous issues like this.
--
Iñaki Baz Castillo
<[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
