Re: [Sip] Re: draft-ietf-sip-gruu-09

[Jonathan Rosenberg <[e-mail]>]

inline.

Paul Kyzivat wrote:

> 
> 
> Jonathan Rosenberg wrote:
> 
>> Cullen Jennings wrote:
> 
> 
>>> Section 6, page 12, 4th para or so ... you are talking about mid- 
>>> dialog requests. Might be nice to mention how a transaction stateful  
>>> proxy knows if something is a middialog request or not.
>>
>>
>> These days I recommend topmost route URI over tags, since its easy to 
>> fool a proxy into thinking something is a mid-dialog request by faking 
>> a tag. Its harder to fake a route URI.
>>
>> Text now reads:
>>
>> <t> Mid-dialog requests will also be sent to GRUUs, as they are
>> included as the remote-target in dialog-forming and target refresh
>> requests and responses. However, in those cases, a proxy SHOULD only
>> apply services that are meaningful for mid-dialog requests, generally
>> speaking. This excludes screening functions, as well as forwarding
>> ones. A proxy can determine that a request is a mid-dialog request
>> based on the Route header field in the request it receives. If the
>> topmost URI matches one that the proxy placed into the Record-Route
>> header field of a dialog-forming request, then the request is a
>> mid-dialog request. </t>
> 
> 
> Is it really harder to fake?

If the objective is to fool a *proxy* into thinking a request is a 
mid-dialog request, then yes.

If a proxy uses the mere presence of the To tag as the indicator of a 
mid-dialog request, then a UA can simply send an initial request with 
any arbitrary tag in the To header field.

If a proxy uses the value of Route header field, then the UA has to 
construct a Route header field value which the proxy will accept. If the 
proxy is halfway intelligent in construction of record-routes, it'll use 
random numbers, hashes, and otherwise proprietary techniques to 
construct the URI. The odds are pretty good that the UA would not be 
able to construct a Route URI that the proxy would recognize as one that 
it would have inserted into a Record-Route.

Now, a request that contains a tag not matching any dialog at the UAS is 
rejected anyway. However, you might be able to work with a cooperating 
UAS to make something useful happen. For example if a proxy is 
generating call start and stop records based on *initial* INVITE and 
BYE, respectively, cooperating UA might be able to get free calls.

> 
> Suppose Alice is permitted to call Bob, but not to subscribe to the reg 
> event package. So Alice first calls Bob, and notes the Record-Route that 
> results. Then in a separate dialog, Alice sends a SUBSCRIBE to the reg 
> event package, including a Route header with a URI of Bob's home proxy 
> extracted from the old R-R.

If the RR is constructed using hashes of the tags this won't work.

> 
> Seems like this strategy also requires some protection against a "replay 
> attack" like this.
> 
> But that isn't really an issue for this draft.

No; but it makes for interesting list discussion ;)

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip