Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 11 Aug 2009 12:38:54 -0400

We should put UUI in H-I. 

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Elwell, John <[email-masked]>; Francois Audet <[email-masked]>; Christer Holmberg <[email-masked]>; Dean Willis <[email-masked]>
Cc: SIPCORE <[email-masked]>; Hadriel Kaplan <[email-masked]>
Sent: Tue Aug 11 11:11:50 2009
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery

All,

Sorry that I am a bit late in this thread but I am catching up.

The UUI may only be applicable to B but there is no way of knowing if it
may also be applicable to C following retargeting. This will depend upon
the content of the UUI, its purpose and the capabilities of C.

The key issue with trying to pass the UUI as a parameter in H-I is
Privacy. If A sets Privacy to value 'header' then the H-I entry included
by the retargeting to the registered terminal address will be removed
and will not even be received by B let alone C as the H-I will be
removed.

You need to place the UUI in a separate header to ensure that it is not
removed when the URI is protected by Privacy.

Ian Elz

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 05 August 2009 09:27
To: Francois Audet; Christer Holmberg; Dean Willis
Cc: SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

It think we need to ask the question whether, for a given class of
information included by the UAC in the original request (e.g., UUI),
that information should be preserved if the request is retargeted.
Clearly most classes of information should be preserved when the
Request-URI changes because of rerouting, but when retargeting occurs
the answer might not be so clear.

So taking UUI, if A sends a request with UUI to B and the request is
retargeted to C, is the UUI relevant to C too, or only to B? If the UUI
has implicit semantics, it is not at all clear to me that it is equally
applicable to C.

If the information is equally applicable to B and C, this would argue in
favour of a separate header field for UUI.

If the information is specifically targeted at B, this would argue for a
URI parameter. In that case, although C might receive the information
via H-I, it will at least know that the UUI was targeted at B and it can
take it or leave it, depending on application. The problem with a
separate header field in this case is that C would need to trawl through
H-I to find out whether the UUI really was targeted at C, and if H-I is
not available (e.g., because of privacy or lack of support) or somehow
obfuscated, then C might interpret the UUI wrongly.

Having said this, the cc-uui draft states:
"REQ-4: The mechanism will allow UUI to be able to survive proxy
   retargeting."
This seems to suggest that UUI should have semantics of being equally
applicable to B and C, and this would indeed suggest a separate header
field. However, I am not sure I have interpreted that requirement
correctly or the motivation for that requirement.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: 04 August 2009 22:53
> To: Christer Holmberg; Dean Willis
> Cc: SIPCORE; Hadriel Kaplan
> Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter 
> delivery
> 
> I completely agree with Christer on this point.
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Christer Holmberg
> > Sent: Monday, August 03, 2009 13:13
> > To: Dean Willis
> > Cc: SIPCORE; Hadriel Kaplan
> > Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter

> > delivery
> > 
> > Hi,
> >  
> > > As we know, the R-URI value is not end-to-end. It may
> change in the
> > > path, due to normal SIP procedures. That is the reason we have
> > > History-Info: to record what has happened, for applications
> > etc which
> > > needs that information.
> > >
> > > But, in my opinion History-Info is not a generic mechanism of 
> > > transporting parameters transparently end-to-end, however,
> > and UUI is
> > > a parameter which is supposed to be transported end-to-end. 
> > Therefor I
> > > think it would fit better in a separate header.
> > 
> > 
> > >Once again: The reason I lobbied for and requested the
> milestone for
> > >end-to-end delivery of request URI AND parameters was SO THAT 
> > >PARAMETERS COULD BE DELIVERED END TO END. That was also
> the initial
> > >goal of Jonathan's ua-loose-route draft, although in that
> > process, we
> > >discovered that the non-parameter part of the target URI was also 
> > >needed for some applications.
> > 
> > The initial goal of Jonathan's draft was NOT to transport 
> > transparent parameters end-to-end.
> >  
> > The initial goal was to make sure that the initial R-URI reaches the

> > other end.
> > 
> > >If we don't think that History-Info is a generic mechanism of 
> > >transporting parameters transparently end-to-end, then it is NOT 
> > >meeting the goal of the charter deliverable.
> > 
> > 
> > The purpose of H-I is to make sure that certain parameters, which 
> > may change in the path, are transported end-to-end.
> > 
> > That is not the same as transporting transparant parameters 
> > end-to-end, in my opinion.
> > 
> > 
> > >Do we, or do we not, have consensus on whether or not
> > History-Info is an adequate solution to the problem?
> > 
> > I certainly think that that History-Info is a solution to the 
> > initial goal of Jonathan's draft.
> > 
> > Sending transparant parameters end-to-end is, in my opinion, a 
> > completly separate issue.
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> >  
> > 
> > 
> > 
> > --
> > Dean
> > 
> > 
> > 
> > _______________________________________________
> > sipcore mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sipcore
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
> 

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 11 Aug 2009 14:37:49 -0400

Sorry. We should NOT put UUI in H-I

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DOLLY, MARTIN C, ATTLABS
Sent: Tuesday, August 11, 2009 12:39 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Elwell, John <[email-masked]>; Francois Audet
<[email-masked]>; Christer Holmberg <[email-masked]>;
Dean Willis <[email-masked]>
Cc: SIPCORE <[email-masked]>; Hadriel Kaplan <[email-masked]>
Sent: Tue Aug 11 11:11:50 2009
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

All,

Ian Elz

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 05 August 2009 09:27
To: Francois Audet; Christer Holmberg; Dean Willis
Cc: SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

John

---

From: <[email-masked]>
Date: Wed, 12 Aug 2009 09:55:06 +0200

H-I is frequently removed by B2BUAs at the network border so the UUI may
not reach it's destination. For UUI, we need a new parameter which is
not removed by intermediaries. 

Kind regards
Laura     

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of DOLLY, MARTIN C, ATTLABS
Sent: Tuesday, August 11, 2009 8:38 PM
To: DOLLY, MARTIN C, ATTLABS; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Elwell, John <[email-masked]>; Francois Audet

All,

Ian Elz

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 05 August 2009 09:27
To: Francois Audet; Christer Holmberg; Dean Willis
Cc: SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Aug 2009 08:46:58 -0400

> not removed by intermediaries. 

When talking about a new thing added to a message, you can have no 
guarantees of whether it will survive B2BUAs or not. If the B2BUA 
removes anything it doesn't understand then this new thing may will not 
survive. Or it might remove it even when it does understand it if it 
thinks this might contain sensitive information.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Aug 2009 08:06:34 -0500

Hi, Paul,

> guarantees of whether it will survive B2BUAs or not. If the B2BUA removes 
> anything it doesn't understand then this new thing may will not survive. 
> Or it might remove it even when it does understand it if it thinks this 
> might contain sensitive information.
>
> Thanks,
> Paul
>
>> Kind regards
>> Laura

If I understood Laura's concern, it's that people are already making the 
policy decision to drop H-I entries at network edges to do topology hiding.

I agree with what you're saying ("no guarantees" about a new header field), 
but if a new header field is used, it would be possible for B2BUAs that 
remove anything they don't understand to stop removing the new header field. 
If History-Info is (re-)used, the B2BUA can't do topology hiding and still 
pass UUI, can it?

(I'm not talking about whether topology hiding should happen - just trying 
to help with the discussion)

Thanks,

Spencer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 12 Aug 2009 17:50:51 +0200

Hi,
 
It is true that we don't know what a B2BUA may do.
 
However, for H-I we have specified privacy procedures, when something will get removed.
 
Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Paul Kyzivat
Sent: Wed 12/08/2009 14:46
To: [email-masked]
Cc: [email-masked]
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery

        Thanks,
        Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Aug 2009 11:31:51 -0500

> not removed by intermediaries. 

Again, this argues that we need some other mechanism for general
parameter passing from UAC to UAS. RFC 4244bis just doesn't get this
specific job done.

Of course, no matter where we put it, some SBC is going to come along
and remove it. That's what they do.

--
dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Aug 2009 15:01:40 -0500

Hi, Dean,

> and remove it. That's what they do.

Totally agree - I think your point argues that reusing a header field that's 
already removed for policy reasons in some situations is unwise.

You can tell your own SBC to stop removing a single-purposed header field if 
that's what you think should happen, but you can't tell your own SBC to pass 
H-I for parameter passing from UAC to UAS AND remove H-I for privacy or 
topology hiding at the same time ...

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Aug 2009 22:48:55 -0500

On Aug 12, 2009, at 3:01 PM, Spencer Dawkins wrote:

> Totally agree - I think your point argues that reusing a header  
> field that's already removed for policy reasons in some situations  
> is unwise.

Right.

> You can tell your own SBC to stop removing a single-purposed header  
> field if that's what you think should happen, but you can't tell  
> your own SBC to pass H-I for parameter passing from UAC to UAS AND  
> remove H-I for privacy or topology hiding at the same time ...

Bingo -- conflicted requirements.

--
Dean

---

From: <[email-masked]>
Date: Thu, 13 Aug 2009 11:00:44 +0200

Paul,

As Spencer already wrote, carriers do topology hiding at the network
border.  
They have done it with SS7 and will do it for SIP too. So, H-I is
removed and we need another way to pass UUI. 

Thanks a lot
Laura

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 3:07 PM
To: Paul Kyzivat
Cc: [email-masked]; Liess, Laura
Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter
delivery

Hi, Paul,

> guarantees of whether it will survive B2BUAs or not. If the B2BUA
removes 

policy decision to drop H-I entries at network edges to do topology
hiding.

I agree with what you're saying ("no guarantees" about a new header
field), 
but if a new header field is used, it would be possible for B2BUAs that 
remove anything they don't understand to stop removing the new header
field. 
If History-Info is (re-)used, the B2BUA can't do topology hiding and
still 
pass UUI, can it?

(I'm not talking about whether topology hiding should happen - just
trying 
to help with the discussion)

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Aug 2009 09:22:46 -0400

> removed and we need another way to pass UUI. 

I certainly know that and AFAIK didn't imply otherwise.
Carriers try to find a way to hide lots of things.
The question is: will there also be reasons for carriers to censor 
parameters as well?

I suppose one could argue that if we were to provide the means to 
classify and identify parameters for particular purposes we would make 
it easier for middle boxes to make policy decisions about whether to let 
them pass or not.

Personally I just want the providers to keep their hands off my data.

I'm largely in agreement with what Dean and Spencer have been saying.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 13 Aug 2009 11:18:01 +0200

-----Original Message-----
	From: Dean Willis [mailto:[email-masked]] 

	Again, this argues that we need some other mechanism for general
	parameter passing from UAC to UAS. RFC 4244bis just doesn't get
this
	specific job done.

I think we are now back to the discussion on Alan's UUI draft
/WG-proposal. 
Maybe we should wait Alan's new proposal? I am not sure, but my
understanding was 
that Alan agreed to look at this. 

	Of course, no matter where we put it, some SBC is going to come
along
	and remove it. That's what they do.

--
dean

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 14:35:19 +0200

Paul, 

		-----Original Message-----
		From: Paul Kyzivat [mailto:[email-masked]] 
		Sent: Thursday, August 13, 2009 3:23 PM
		To: Liess, Laura
		Cc: [email-masked]; [email-masked]
		Subject: Re: [sipcore] RFC 4244 bis use cases and
UAC->UAS parameter delivery

		I certainly know that and AFAIK didn't imply otherwise.
		Carriers try to find a way to hide lots of things.
		The question is: will there also be reasons for carriers
to censor 
		parameters as well?

B2BUAs in carrier networks already do it. 

I think it is is OK when it is for hiding the own network
infrastructure. 
 
Another example is the caller's IP-address. I learned from the security
guys that carriers have to do this because they must
be able to hide caller's data. And most of our customers seem to like
it, they feel more secure. 
We have regulatory requirements to be able to hide the caller phone
number. IP-address hiding is in a way the same, 
at least for VoIP.     

There are realy ugly B2BUAs in the field which have white lists and drop
everything they do not understand.   
We had one of them in the past and asked the vendor to change it, but I
am sure there are still a lot of them elsewere.  

The B2BUAs at the network borders (the 3GPP  IBCF) has a profile about
which headers to pass and which 
headers to drop towards networks which are considered untrusted. The H-I
will not be passed towards untrusted networks.       

A dedicated UUI-header will probably have good chances to cross the
network borders. 

And I am fine with a more general header which is used for other
applications as well. 

Thanks a lot
Laura

		I suppose one could argue that if we were to provide the
means to 
		classify and identify parameters for particular purposes
we would make 
		it easier for middle boxes to make policy decisions
about whether to let 
		them pass or not.

		Personally I just want the providers to keep their hands
off my data.

		I'm largely in agreement with what Dean and Spencer have
been saying.

			Thanks,
			Paul

		>>> H-I is frequently removed by B2BUAs at the network
border so the UUI
		> may
		>> anything it doesn't understand then this new thing
may will not
		> survive. 
		>> Or it might remove it even when it does understand it
if it thinks

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Aug 2009 09:03:26 -0400

Laura,

As far as the intended subject of this thread, I think there is some 
convergence that putting parameters into the R-URI and getting them to 
the recipient via H-I is not workable, so we need a different solution 
than that. Another header seems to be the current thinking, and I'm ok 
with that, as long as it is general purpose.

Beyond that we start to get into controversial territory regarding 
censoring of data by providers. I'm ok with providers censoring *their 
own* data as long as done in such a way that everyone knows how to make 
things work when that is going on. I'm even ok with providers censoring 
their customers' data as part of a terms-of-service agreement, as long 
as that part is *optional*, that a customer may opt in/out of. I'm *not* 
ok with providers censoring customer data that customers don't want 
censored.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 15:56:03 +0200

Paul,

I think we have full agreement, in both issues.   

> Another header seems to be the current thinking, 
> and I'm ok 

I am fine with it. I also hope DT will be able to do more with SIP, not
just
reinventing PSTN. Then, a general header UUI may be very usefull. 

> I'm *not* 

I agree. 
Also if carriers would like to, it never worked on a long term. 
I don't see any value in it. A better service is worth a lot more. 
   
Thanks a lot
Laura     

> Sent: Friday, August 14, 2009 3:03 PM
> To: Liess, Laura

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 14 Aug 2009 08:31:00 -0700

>I'm *not* ok with providers censoring customer data that customers don't want
>censored.

Correct. I also believe it is illegal in many countries, such as in Germany, the EU at large and in the US and Canada.

Henry

On 8/14/09 8:03 AM, "Paul Kyzivat" <[email-masked]> wrote:

Laura,

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Aug 2009 15:43:09 -0400

Henry Sinnreich wrote:
> Correct. I also believe it is illegal in many countries, such as in 
> Germany, the EU at large and in the US and Canada.

Well, if I want to put something in the H-I of a request I send, and I 
don't want it removed, I expect some B2BUAs (and perhaps proxies) of 
intermediaries may well remove that based on policy of those operating 
the B2BUA, regardless of the customer's desire.

But it will probably be argued that it *is* customer desire as expressed 
by agreement to some terms of service.

	Paul