Subject: [Sipping] RE: Comments to draft-vanelburg-sipping-served-user-01.txt

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Fri, 3 Aug 2007 09:52:13 +0200

Hi Miguel,

1) Yes well spotted, I realise now that the current text suggests this.
This was not the intention. Adding a parameter to control further iFC
processing sounds like a good idea. I will make a proposal along these
lines in the new version of the draft. I propose that in absence of this
parameter the default behaviour is the current behaviour which is to
terminate the iFC processing when the Request URI is changed.

2) Yes. But it should be allowed to modify the parameter discussed in 1)
above. Further the AS should be allowed to insert it on sessions that it
originates. 

3) In section "6 Applicability" it is stated that "The S-CSCF or the AS
inserts the P-Served-User header field into a SIP request and the S-CSCF
removes it before routing the request further." Consequently an I-CSCF
will never see the header. Does this resolve your concern or do you
think additional text is required?

/Hans Erik

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Thursday, July 19, 2007 12:50 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: Sipping
Subject: Comments to draft-vanelburg-sipping-served-user-01.txt

Hi:

Some comments to draft-vanelburg-sipipng-served-user-01.txt

1) Overloading semantics of the P-Served-User header

In section 3.2, the text in 4th paragraph makes me thing that the
P-Served-User header is sometimes used to stop processing of the initial
Filter Criteria in the S-CSCF; and sometimes not. Can you clarify if
this is then intention?

In principle, if the draft defines a new header to avoid overloading in
semantics of existing headers, then I would propose to not overload the
semantics if the new header. You may need to define a new parameter that
indicates whether to continue processing the filter criteria. I guess
application servers should have the logic to provide such indication.

2) Can AS modify the value of the P-Served-User header?

I assume that S-CSCFs will insert the header and the AS will just read
it, but never modifies it. Is this correct? I would suggest to have some
text with the intended behavior.

3) Security considerations

The second paragraph in the security considerations is a bit soft when
it puts a burden on "operators", when they "need to ensure that the
P-Served-User header field is always removed from requests before these
are sent outside the trust domain."

If the intention of the header is to be visible in the S-CSCF AS
interface, then then burden of removing the header should be imposed to
both nodes, where applicable. Otherwise, existing border nodes, such as
a I-CSCFs behaving as proxies, will not understand the header and
blindly forward it.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 03 Aug 2007 16:28:00 +0300

Hans Erik:

With respect the 3rd point, my comment refers to the Security 
Considerations section. The current text reads:

    There is a security risk if a P-Served-User header field is allowed
    to propagate out of the trust domain where it was generated.  In that
    case user-sensitive information would be revealed by such a breach.
    Consequently, operators need to ensure that the P-Served-User header
    field is always removed from requests before these are sent outside
    the trust domain.

The text seems to imply that a node at the edge of the trust domain is 
responsible for removing the header. I am saying that this is not 
possible to be done, because existing deployments will not understand 
this header and will forward it outside the trust domain.

You are saying that the S-CSCF removes the header, and the I-CSCF (node 
at the edge of the trust domain) never receives the header. If that is 
the case, then the text contradicts the quoted text in the security 
considerations.

/Miguel

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Fri, 3 Aug 2007 16:14:44 +0200

Miguel,

That text was more targeted at the ISC interface, do you assume then
that all AS's are trusted?

/Hans Erik 

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 3:28 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: Sipping
Subject: Re: Comments to draft-vanelburg-sipping-served-user-01.txt

Hans Erik:

    to propagate out of the trust domain where it was generated.  In
that

/Miguel

> lines in the new version of the draft. I propose that in absence of 
> this parameter the default behaviour is the current behaviour which is

> to terminate the iFC processing when the Request URI is changed.
> 
> 2) Yes. But it should be allowed to modify the parameter discussed in 
> 1) above. Further the AS should be allowed to insert it on sessions 
> that it originates.
> 
> 3) In section "6 Applicability" it is stated that "The S-CSCF or the 
> AS inserts the P-Served-User header field into a SIP request and the 
> S-CSCF removes it before routing the request further." Consequently an

> I-CSCF will never see the header. Does this resolve your concern or do

> you think additional text is required?
> 
> /Hans Erik
> 
> P-Served-User header is sometimes used to stop processing of the 
> initial Filter Criteria in the S-CSCF; and sometimes not. Can you 
> clarify if this is then intention?
> 
> In principle, if the draft defines a new header to avoid overloading 
> in semantics of existing headers, then I would propose to not overload

> the semantics if the new header. You may need to define a new 
> parameter that indicates whether to continue processing the filter 
> criteria. I guess application servers should have the logic to provide
such indication.

> it, but never modifies it. Is this correct? I would suggest to have 
> some text with the intended behavior.
> 

> P-Served-User header field is always removed from requests before 
> these are sent outside the trust domain."
> 
> interface, then then burden of removing the header should be imposed 
> to both nodes, where applicable. Otherwise, existing border nodes, 
> such as a I-CSCFs behaving as proxies, will not understand the header 
> and blindly forward it.
> 
> /Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Aug 2007 08:52:59 +0300

Hans Erik:

It is not a matter of whether the AS's are trusted or not. I think both 
models fit (at least on the paper, current deployments are another story).

My point is that there is a lack of synchronization between the text in 
the Security Considerations section and the earlier text.

I think that text should say something around these lines:
- Proxies MAY insert the header when forwarding requests to other 
trusted nodes if the route set includes another proxy that understands 
the header, such as the own proxy. [Basically, this is to avoid that the 
S-CSCF forwards the request with the header to an edge I-CSCF that does 
not understand it and leaks it outside]. There are no automatic 
mechanism to learn the support for this specification.
- Proxies MUST remove the header when forwarding request to untrusted 
nodes or when the proxy does not have knowledge of any other proxy in 
the route set that is able to understand the header.

I think these two paragraphs cover all possible cases.

/Miguel

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Mon, 6 Aug 2007 13:55:49 +0200

Thanks Miguel, 

That clarifies your point, I changed the last paragraph of section 8 to
read:

"There is a security risk if a P-Served-User header field is
allowed to propagate out of the trust domain where it was
generated. In that case user-sensitive information would be revealed by
such a
breach. To prevent that such a breach will happen: Proxies MAY insert
the header when forwarding requests to other trusted nodes if the route
set includes another proxy that understands the header, such as the own
proxy. There is no automatic mechanism to learn the support for this
specification. Proxies MUST remove the header when forwarding requests
to untrusted nodes or when the proxy does not have knowledge of any
other proxy in the 
route set that is able to understand the header." 

If no more comments on this, then this is the text that will be in the
next version of the draft.

Best Regards,

/Hans Erik

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, August 06, 2007 7:53 AM
To: Hans Erik van Elburg (RY/ETM)
Cc: Sipping
Subject: Re: Comments to draft-vanelburg-sipping-served-user-01.txt

Hans Erik:

It is not a matter of whether the AS's are trusted or not. I think both
models fit (at least on the paper, current deployments are another
story).

/Miguel

> You are saying that the S-CSCF removes the header, and the I-CSCF 
> (node at the edge of the trust domain) never receives the header. If 
> that is the case, then the text contradicts the quoted text in the 
> security considerations.
> 
> /Miguel
> 
>

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Aug 2007 21:27:07 +0300

Hans Erik:

Reading the text once more, I got the impression that what we need to 
turn it into a negative sentence and say when proxies should not insert 
the header. What about if you replace:

"To prevent that such a breach will happen: Proxies MAY insert the 
header when forwarding requests... There is no automatic mechanism..."

with

"To prevent that such a breach will happen: Proxies MUST NOT insert the 
header when they forward requests to a next hop located outside the 
trust domain. When forwarding the request to a trust node, proxies MUST 
NOT insert the header unless they have sufficient knowledge that the 
route set includes another proxy in the trust domain that understands 
the header, such as the own proxy. There is no automatic mechanism ..."

Keep the rest as is, including the "MUST remove" sentence, which is a 
bit different from "MUST NOT insert".

BR,

       Miguel

---

From: "Hans Erik van Elburg (RY/ETM)" <[email-masked]>
Date: Tue, 7 Aug 2007 09:43:03 +0200

Yes I agree to this change as it is even more clear and to the point.
Thanks,
/Hans Erik 

-----Original Message-----
From: Miguel Garcia [mailto:[email-masked]] 
Sent: Monday, August 06, 2007 8:27 PM
To: Hans Erik van Elburg (RY/ETM)
Cc: Sipping
Subject: Re: Comments to draft-vanelburg-sipping-served-user-01.txt

Hans Erik:

with

BR,

       Miguel

Hans Erik van Elburg (RY/ETM) wrote:
> "There is a security risk if a P-Served-User header field is allowed 
> case user-sensitive information would be revealed by such a breach. To

> prevent that such a breach will happen: Proxies MAY insert the header 
> when forwarding requests to other trusted nodes if the route set 
> includes another proxy that understands the header, such as the own 

> other proxy in the route set that is able to understand the header."
> 

> It is not a matter of whether the AS's are trusted or not. I think 
> both models fit (at least on the paper, current deployments are 
> another story).
> 
> My point is that there is a lack of synchronization between the text 
> in the Security Considerations section and the earlier text.
> 

> the header, such as the own proxy. [Basically, this is to avoid that 
> the S-CSCF forwards the request with the header to an edge I-CSCF that

> does not understand it and leaks it outside]. There are no automatic 

>>> processing sounds like a good idea. I will make a proposal along 
>>> these lines in the new version of the draft. I propose that in 
>>> absence of this parameter the default behaviour is the current 
>>> behaviour which is to terminate the iFC processing when the Request 
>>> URI is changed.
>>>

>>> S-CSCF removes it before routing the request further." Consequently 
>>> an I-CSCF will never see the header. Does this resolve your concern 
>>> or do you think additional text is required?
>>>
>>> /Hans Erik
>>>

>>> in semantics of existing headers, then I would propose to not 
>>> overload the semantics if the new header. You may need to define a 
>>> new parameter that indicates whether to continue processing the 
>>> filter criteria. I guess application servers should have the logic 
>>> to provide
>> such indication.
>>> I assume that S-CSCFs will insert the header and the AS will just 
>>> read it, but never modifies it. Is this correct? I would suggest to 
>>> have some text with the intended behavior.
>>>
>>> The second paragraph in the security considerations is a bit soft 
>>> when it puts a burden on "operators", when they "need to ensure that

>>> the P-Served-User header field is always removed from requests 
>>> before these are sent outside the trust domain."
>>>