Subject: [sipcore] Inconsistency in RFC 3325?

From: "Elwell, John" <[email-masked]>
Date: Wed, 13 May 2009 07:24:00 +0100

What looks like an inconsistency in RFC 3325 has been identified.

The table in 9.2 states that PPI can be added ("a") by a proxy:
"      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG
      ------------         -----   -----   ---  ---  ---  ---  ---  ---
      P-Preferred-Identity          adr     -    o    -    o    o    -

                                           SUB  NOT  REF  INF  UPD  PRA
                                           ---  ---  ---  ---  ---  ---
                                            o    o    o    -    -    -"

However, earlier in 9.2 it states:
"The P-Preferred-Identity header field is used from a user agent to a
   trusted proxy to carry the identity the user sending the SIP message
   wishes to be used for the P-Asserted-Header field value that the
   trusted element will insert."
i.e., no mention of being sent from a proxy.

Moreover, in 6 it states:
"The proxy MUST remove the user-provided P-Preferred-
   Identity header from any message it forwards."
i.e., quite explicit about not forwarding, which one might also
interpret as not being allowed to insert.

So can PPI be added by a proxy, and if so what is its meaning? Has there
been any earlier discussion on this topic?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 May 2009 09:07:19 -0400

John,

I don't know if the proxy usage was intended or not.
But neither do I see harm in permitting a proxy to insert the header.
Perhaps there is a *really dumb* UA, with a proxy in front of it 
providing some smarts, before reaching the trusted (and secured) device 
that acts on the PPI.

	Thanks,
	Paul

Elwell, John wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Dean Willis <[email-masked]>
Date: Wed, 13 May 2009 09:42:13 -0500

> providing some smarts, before reaching the trusted (and secured) device

I seem to recall discussing just exactly that use case. IIRC, somebody
in 3GPP proposed that the P-CSCF should be able to insert the default
preferred identity if the mobile terminal failed to insert one.

>> "      Header field         where   proxy   ACK  BYE  CAN  INV  OPT  REG

There's that benighted table again. It confuses most people. It must be
replaced.

--
Dean

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 13 May 2009 20:45:21 +0200

Seems off topic to discuss 3GPP behaviour here, but just to correct: the 
P-CSCF inserts a P-Asserted-Identity based or not on a 
P-Preferred-Identity, it will remove the latter. In case there is no 
P-Preferred-Identity it will insert the default identity in a 
P-Asserted-Identity.
BR,
/Hans Erik

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 13 May 2009 20:58:09 +0200

Hi John,

If you cite the complete paragraph:
"6. Hints for Multiple Identities

   If a P-Preferred-Identity header field is present in the message that
   a proxy receives from an entity that it does not trust, the proxy MAY
   use this information as a hint suggesting which of multiple valid
   identities for the authenticated user should be asserted.  If such a
   hint does not correspond to any valid identity known to the proxy for
   that user, the proxy can add a P-Asserted-Identity header of its own
   construction, or it can reject the request (for example, with a 403
   Forbidden).  The proxy MUST remove the user-provided P-Preferred-
   Identity header from any message it forwards."

then it is clear that "The proxy" is not just any proxy, but the "proxy 
that received the P-Preferred-Identity from an entity that it does not 
trust".

It does therefore not say that any proxy shall in all circumstances 
remove P-Preferred-Identity.

Hence, there is no conflict between the table and this text. but makes 
me wonder about the usefullness of these tables as they don't even say 
anything about what UA's are allowed to do or not...

/Hans Erik

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 17 May 2009 10:19:01 -0600

On May 13, 2009, at 12:58 PM, Hans Erik van Elburg wrote:

> then it is clear that "The proxy" is not just any proxy, but the  
> "proxy that received the P-Preferred-Identity from an entity that it  
> does not trust".

> remove P-Preferred-Identity.

Agree with Hans.

>
>
> Hence, there is no conflict between the table and this text. but  
> makes me wonder about the usefullness of these tables as they don't  
> even say anything about what UA's are allowed to do or not...
INHO these tables have turned out to be pretty much useless (in this  
RFC, in 3261, and all the rest) but that's just my 2 cents

The idea was to allow a proxy in front of a UA that did not support  
3325 to add the PPI on behalf of the phone. Folks were imaging  
something like an little proxy on a box in my house adding it before  
it sent the call up to the service provider proxy. Clearly that idea  
did not get specified in this draft but the "a" got left in the proxy  
field. Keep that in this case, the proxy in the house trusts the  
service provider proxy but the service provider proxy does not trust  
the proxy in the house.

Cullen < in my individual contributor roll >

>>                                           SUB  NOT  REF  INF  UPD   
>> PRA
>>                                           ---  ---  ---  ---  ---   
>> ---
>>                                            o    o    o    -    -     
>> -"