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

From: Cullen Jennings <[email-masked]>
Date: Sun, 2 Jul 2006 12:55:17 -0700

This looks good - a few comments - all very trivial

Does this update 3261? If so, nice if header on first page had that

Section 3 - Long lived definition. I'm really not sure what it means  
to say that a GRUU has a long life than any of the registrations or  
that it is viable for every. I'm not sure it changes behavior of  
anything. Is the important property that if the same AOR/Instance  
registers two different times it gets the same AOR? Anyways, I can  
live with the text exactly as is but I was not getting why it was  
important.

Figure 1: On the diagonal arrow between GRUU and contact, I think the  
end near contact should have "0..1" and the end near the GRUU should  
have "0..n" - right now this is swapped.

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.

Section 6, last para before section 7. I'm not sure I get how  
anything behaves differently from an unbound GRUU that exists vs the  
GRUU does not exist. Again, i don't have some huge problem with  
current text but when I read it, it makes me wonder if there is some  
difference which I should understand.

Section 7.1.1.1 - There has been some problems with the way 3261  
allowed a user to install forwarding rules using a REGISTER request.  
Part of the problem is that it allows an amplification attack on  
someone else that did not provide any consent. It makes me wonder if  
now that we have the consent framework moving forward, do we really  
want to continue down this path. I realize this is pretty orthogonal  
problem to GRUU.

Section 8.1.1 - 2nd para. You have "However, that AOR will be  
rewritten ..." - I found this hard to follow. Is it the request URI?  
I'm not sure how to fix but you might want to have a read of the end  
of that para and see if it is all clear to you.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Jul 2006 23:34:57 -0400

Thanks for the comments, Cullen. Responses below.

> Does this update 3261? If so, nice if header on first page had that

I got asked that privately by others as well. I don't think it does. It 
uses the defined extension behaviors in RFC 3261 to add new 
functionality. Its not required functionality either; if a client can 
construct a contact that has the gruu property this spec is not needed 
(and indeed in a world without nat and firewalls, it could construct one).

> 
> Section 3 - Long lived definition. I'm really not sure what it means  to 
> say that a GRUU has a long life than any of the registrations or  that 
> it is viable for every. I'm not sure it changes behavior of  anything. 
> Is the important property that if the same AOR/Instance  registers two 
> different times it gets the same AOR? Anyways, I can  live with the text 
> exactly as is but I was not getting why it was  important.

Its important so implementors know that they shouldn't hand out a 
different gruu on each registration. If I turn on my softphone today, 
register, and then log out, and tomorrow do the same thing, I should get 
back the same gruu. This property is important in applications where 
people store the contact and use it later for a callback or something.

> have "0..n" - right now this is swapped.

Hmm, I think it is correct as written. A GRUU has 0..n contacts and a 
contact is bound to a single gruu.

> 
> 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>

> 
> Section 6, last para before section 7. I'm not sure I get how  anything 
> behaves differently from an unbound GRUU that exists vs the  GRUU does 
> not exist. Again, i don't have some huge problem with  current text but 
> when I read it, it makes me wonder if there is some  difference which I 
> should understand.

404 vs. 480. 404 if the GRUU simply doesn't exist; 480 if no contacts 
are bound to it. This is described later on.

> want to continue down this path. I realize this is pretty orthogonal  

Yes, it is. I tend to agree that third party registrations are generally 
a bad idea these days. However, they exist in rfc3261 and we've not 
outlawed them. Thus I don't think this is an issue for GRUU to tackle. 
GRUU merely specifies how they interact.

> 
> Section 8.1.1 - 2nd para. You have "However, that AOR will be  rewritten 
> ..." - I found this hard to follow. Is it the request URI?  I'm not sure 
> how to fix but you might want to have a read of the end  of that para 
> and see if it is all clear to you.

Yes. The text is confusing. Hopefully this is clearer:

<t>If the UA instance has obtained multiple GRUUs for different AORs
as a result of a registration, it SHOULD use one corresponding to the
AOR used to send or receive the request. For sending a request, this
means that the GRUU corresponds to the AOR present in the From header
field. Furthermore, this means that the credentials used for
authentication of the request correspond to the ones associated with
that AOR. When a peer sends a request to a UA, that request will
arrive at the home proxy, and be forwarded to the UA. The GRUU placed
into the Contact header field of the response SHOULD correspond to the
AOR to which the request was targeted by the peer. Unfortunately, this
AOR is not directly present in the request when it is received by the
UA. It would have been placed into the Request-URI of the request when
sent by the peer. However, upon reaching the home proxy of the UA, the
Request-URI is rewritten with the registered contact. It is for this
reason that different contacts are needed for each AOR that an
instance registers against. When an incoming request
arrives, the Request URI can be examined. It will be equal to a
registered contact. That contact can be used to map directly to the
AOR, and from there, the correct GRUU can be selected.  </t>

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 27 Jul 2006 09:31:58 +0300

Jonathan Rosenberg writes:

 > If the
 > mid-dialog request.

jonathan,

how can proxy tell apart a pre-loaded Route header from proxy placed?

-- juha

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 27 Jul 2006 10:26:21 +0200

At 05:34 27/07/2006, Jonathan Rosenberg 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.

Faking tags is easy, but is there a way to exploit that? I mean a UAS that received
a request with to-tag which matches no dialog just discards it.

Faking Routes may not be that difficult either, unless implementors choose to append
some cryptographically secured "this-was-me" tags to it.

Anyway, I think there can be quite some ways to do the same thing (some folks I am sure
will prefer a dialog state silo too), and if we show a way to do this test, it should
be properly labeled as an example. 

[...]

>Yes, it is. I tend to agree that third party registrations are generally a bad idea these days. 

I think there are actually three orthogonal things:

a) uploading forwarding rules using REGISTER. (which is not IMO 3rd-party registration, as long
   as identity of the registering party equals that of URI owner). I don't know if this is worth
   documenting. IMO, this is an aspect to be addressed by registrar's policy. A registrar may
   for example decide to deny domain names in contacts, it may deny contact addresses that are
   IP-wise different from transport addresses from which REGISTER came from, etc. It could also
   accept contacts in REGISTER that includes P-ISwearThisIsNotForwarding: Yes :-)) There are
   subscribers and consequently provides who consider this a feature. We specify protocols and 
   not policies, don't we. 

b) 3rd-party registration, which is IMO the case, when the identity of registering party (i.e.,
   username as in digest) is not the same as owner of URI. E.g., if [email-masked] with valid
   credentials puts [email-masked] in From/To. This is IMO a policy issue too, and thus I think 
   it is appropriate to leave it as is. Already the fact that there is no SIP data model as part
   of the standard would make possible fixes kind of difficult; i.e., there is actually no clear 
   definition for 3rd party registration without precise notion of URI ownership. 

c) GRUU. (no particular comments on this other than it is different from a and b)

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 27 Jul 2006 12:57:33 +0200

>how can proxy tell apart a pre-loaded Route header from proxy placed?

I would say there are far too many ways to do it. One of those is the
proxy puts in the Record-Route header-fields its signature "I put it here".
This can have many various forms, up to proxy vendor or configurator to choose
one. We typically configure what we call "avp-cookies" in Record-route header field 
to capture some fragments of dialog state. If such a piece of information 
appears later in Route, we know it is our "own" route. If not, it is not
(or there is a crappy UA which strips some parts of the HF :-))

This is more robust than looking at hostname/IP, because that may be too
amibguous (it is hard to differentiate between preloaded/record-routed,
if IP address is used in multidomain environments it is difficult to
assigne the request to a domain, etc.) Sometimes for similar cases,
you don't actually the signature to be an IP address -- you may have 
a server farm, and all you want to know is whether any of farm members 
did record-route or not.

The record-routing information may include various things to provide
better value: name of initially "dialed" domain, cryptographic checksum
to avoid forged record-routing information, and once that begins to bee
all too much, just index referring to database full of call state.

-jiri

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jul 2006 09:14:23 -0400

> header field of a dialog-forming request, then the request is a

Is it really harder to fake?

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.

Seems like this strategy also requires some protection against a "replay 
attack" like this.

But that isn't really an issue for this draft.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jul 2006 23:15:01 -0400

inline.

Paul Kyzivat wrote:

>> 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:
>>

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.

> extracted from the old R-R.

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

> But that isn't really an issue for this draft.

No; but it makes for interesting list discussion ;)

-Jonathan R.

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 28 Jul 2006 11:13:27 +0200

At 05:15 28/07/2006, Jonathan Rosenberg wrote:
> 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.

Well, in terms of interesting list discussion: I think this can be actually used to replace the
hostname-based "is it myself" test in processing route header fields. That appears to me more
robust because it removes ambiguities around multiple IP addresses, many names in hosted
environments, having to configure all of that, failover scenarios with backup having 
different IP from primary servers, etc.

>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.
>
>>Seems like this strategy also requires some protection against a "replay attack" like this.

:)

Replay attack protection is not easy for protocols which rely on notion of piggy-backing
without any more support from client than just mirroring a value from server. We would
have to touch the client to provide for message integrity. 

-jiri