Subject: [Sipping] comments on http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-02.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Feb 2008 21:08:13 -0500

Since this doc is intended as p-header and informational my comments are 
strictly in the context of RFC 3427.

* the document is still overly focused on syntax and there is very 
little on semantics. I think it is important to discuss HOW a proxy or 
gateway determines what identity to put in here. It would be good to 
give some examples. Also really important to give concrete use cases 
where it differs from P-A-I

* you should mention that the field should be stripped on ingress from 
untrusted peers, and removed on egress to untrusted peers.

* security considerations is not strong enough, and it needs to be 
stronger. You need to talk about the security between trusted elements - 
presumably this will require tls at some level of strength, especially 
between domains, or is subject to massive fraud. Your security 
considerations section needs to discuss issues around intermediaries 
modifying this, inspecting it (reconstructing call history information), 
and so on

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sipping mailing list  http://www.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: Dan York <[email-masked]>
Date: Tue, 26 Feb 2008 17:45:42 -0500

Jonathan,

Thanks for the comments.  I'll reply inline below.

On Feb 25, 2008, at 9:08 PM, Jonathan Rosenberg wrote:

> give some examples.

DY> I'm not sure I understand what semantics you would want to see  
here.  The P-Charge-Info P-Header is really just designed to provide  
billing information between two entities that decide to use it. So if  
I am a customer and I want to use this to work with my service  
provider - and they agree - I then configure my SIP proxy or gateway  
to send that header up to the service provider with an appropriate  
SIP URI to be billed.

DY> The actual SIP URI to be inserted there may vary based on the  
particular systems being used, so I wasn't planning on getting into  
that. More saying "here's a container into which you can stick a SIP  
URL if you want to pass along a billing identifier to a connected  
system".

> Also really important to give concrete use cases

DY> Hmmm... I hadn't considered doing that as I considered P-A-I to  
be solving a different problem - but perhaps that's the point.  A  
mention of how it differs from P-A-I might be useful.

> untrusted peers, and removed on egress to untrusted peers.

DY> We debated about that and ultimately chose to leave it out as a  
detail of implementation, but it could certainly be added.

> modifying this, inspecting it (reconstructing call history  

DY> I chose not to get into specific security recommendations (such  
as TLS-encrypted SIP) but again was intending to highlight the  
potential problem and leave it open to implementations as to how to  
specifically address the problem.  However, I could certainly expand  
that section to provide better guidance.

Thanks for the feedback,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Feb 2008 20:59:18 -0500

Dan,

As a meta-comment, there are two possible reasons you are asking to 
publish this document:

1. you want to 'reserve' the p-header so no one else uses the name,
2. you want to document the protocol extension so others can implement it

Some of your comments below make me think you desire #1, and my comments 
are really about #2. This document does not contain enough information 
for a vendor to go and implement it and sell that to a provider that is 
using this header. Frankly I see little point in proceeding with this 
document if your intent is #1 alone, since the odds of header name 
collisions are pretty low. The RFC3427 process is not about a registry 
for header names, its about private extensions which are documented as 
protocol extensions.

So assuming the objective is an actual spec, comments below:

Dan York wrote:
> DY> I'm not sure I understand what semantics you would want to see here. 

WHat logic should a proxy use in inserting this header? Is it based on 
the TLS identity of the upstream connection? Is it based on a 
transformation of the calling number? Is it a configured property of the 
peer? Is it determined by digest authentication? etc.

>  The P-Charge-Info P-Header is really just designed to provide billing 
> information between two entities that decide to use it. So if I am a 
> customer and I want to use this to work with my service provider - and 
> they agree - I then configure my SIP proxy or gateway to send that 
> header up to the service provider with an appropriate SIP URI to be billed.

OK so this is meant for an enterprse->SP boundary then? That use case is 
not called out in the draft. Should the receiving proxy verify against 
the cert? WHat if they don't match? Is there a possibility for fraud here?

Furthermore you have stated a particular implementation requirement in 
your comment: proxies SHOULD have the ability to insert a configured 
value, which is a function of the SIP next hop. Presumably this identity 
would vary if I communicate with different next hops?

Can this contain numbers or user@domain values? WHat about a tel URI?

> that.

Well, that is what is required to implement this. See my meta-comment above.

> More saying "here's a container into which you can stick a SIP URL 
> if you want to pass along a billing identifier to a connected system".

Well, by this logic, the SIP spec can be reduced to something like, 
"there are 10 headers that you put stuff into, here is the syntax, the 
rest is just implementation detail". Specs are about SEMANTICS and not 
SYNTAX!

> DY> Hmmm... I hadn't considered doing that as I considered P-A-I to be 
> solving a different problem - but perhaps that's the point.  A mention 
> of how it differs from P-A-I might be useful.

Indeed.

> detail of implementation, but it could certainly be added.

See meta-comment above.

> DY> I chose not to get into specific security recommendations (such as 
> TLS-encrypted SIP) but again was intending to highlight the potential 
> problem and leave it open to implementations as to how to specifically 
> address the problem.  However, I could certainly expand that section to 
> provide better guidance.

See meta-comment above.

-Jonathan R.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 27 Feb 2008 12:28:44 +0100

My reading of RFC 3427 is that #1 does not exist.

The authors of that document, and subsequently the IETF itself, do not
acknowledge that it is possible to extend SIP with headers outside the
IETF. Therefore there can be no preexisting implementation.

Therefore if you went the route of #1, then you are responsible for any
duplicate use.

#2 is the only route, and RFC 3427 puts the document through expert
review and IESG last call, and the normal rules on comments made during
those processes apply to a P-header as to any other RFC, i.e. if they
are valid comments they are expected to be taken into account.

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, February 27, 2008 1:59 AM
> To: Dan York
> Cc: IETF Sipping List
> Subject: Re: [Sipping] comments 
> onhttp://www.ietf.org/internet-drafts/draft-york-sipping-p-cha
> rge-info-02.txt
> 
> Dan,
> 
> As a meta-comment, there are two possible reasons you are 
> asking to publish this document:
> 
> 1. you want to 'reserve' the p-header so no one else uses the 
> name, 2. you want to document the protocol extension so 
> others can implement it
> 
> Some of your comments below make me think you desire #1, and 
> my comments are really about #2. This document does not 
> contain enough information for a vendor to go and implement 
> it and sell that to a provider that is using this header. 
> Frankly I see little point in proceeding with this document 
> if your intent is #1 alone, since the odds of header name 
> collisions are pretty low. The RFC3427 process is not about a 
> registry for header names, its about private extensions which 
> are documented as protocol extensions.
> 
> >> Since this doc is intended as p-header and informational 
> my comments 
> >> are strictly in the context of RFC 3427.
> >>
> >> little on semantics. I think it is important to discuss 
> HOW a proxy 
> >> or gateway determines what identity to put in here. It 
> would be good 
> >> to give some examples.
> > 
> WHat logic should a proxy use in inserting this header? Is it 
> based on the TLS identity of the upstream connection? Is it 
> based on a transformation of the calling number? Is it a 
> configured property of the peer? Is it determined by digest 
> authentication? etc.
> 
> 
> OK so this is meant for an enterprse->SP boundary then? That 
> use case is not called out in the draft. Should the receiving 
> proxy verify against the cert? WHat if they don't match? Is 
> there a possibility for fraud here?
> 
> Furthermore you have stated a particular implementation 
> requirement in your comment: proxies SHOULD have the ability 
> to insert a configured value, which is a function of the SIP 
> next hop. Presumably this identity would vary if I 
> communicate with different next hops?
> 
> > More saying "here's a container into which you can stick a 
> SIP URL if 
> > you want to pass along a billing identifier to a connected system".
> 
> Well, by this logic, the SIP spec can be reduced to something 
> like, "there are 10 headers that you put stuff into, here is 
> the syntax, the rest is just implementation detail". Specs 
> are about SEMANTICS and not SYNTAX!
> 
> 
> > 
> >> Also really important to give concrete use cases where it differs 
> >> from P-A-I
> > 
> >> * you should mention that the field should be stripped on ingress 
> >> from untrusted peers, and removed on egress to untrusted peers.
> > 
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping

---

From: Dan York <[email-masked]>
Date: Wed, 27 Feb 2008 07:37:13 -0500

Jonathan,

On Feb 26, 2008, at 8:59 PM, Jonathan Rosenberg wrote:

> Some of your comments below make me think you desire #1, and my  
> comments are really about #2.

Fair point - to which there are really three answers that can be  
summarized as:

  1. Your #2 above
  2. Prevention of P-Header proliferation
  3. Because RFC 3427 says we *have to* register the P-Header (see  
below), which is a variation on your #1

To expand upon each of those...

First, as a Voxeo employee my interest is essentially #2.  We are  
already realizing substantial cost savings by using the P-Charge-Info  
header to pass a billing identifier to multiple carriers.  This  
naturally pleases our CFO and contracts team and in our discussions  
now with new carriers, the usage of the P-Charge-Info header is  
communicated very strongly by our CFO/contracts team as a desired (or  
even required) feature.  (Because we are a very large consumer of SIP  
trunks/connections for our application platform, such that our needs  
are frequently outstripping the capacity of the North American  
carriers with whom we work, we are always in discussions with other  
carriers about obtaining more SIP trunk capacity.)

So in that aspect we do want to document the P-header so that others  
can potentially implement it.  With that in mind, I'll look to  
incorporate the answers to the feedback you provided in the next  
version of the draft. I agree that some areas could use more definition.

Second, on a personal level as a strong supporter/promoter of open  
standards (as I know basically all of us on this list are), I see  
this reason:

  - prevention of P-header proliferation

Right now, if a developer out there is tasked with figuring out a way  
to pass billing information to an upstream SIP provider that is  
separate from the FROM or P-A-I headers, the developer needs to  
figure out what SIP header to use.  If he or she has a clue about  
SIP, he/she will look at the IANA list SIP parameters available at:

    http://www.iana.org/assignments/sip-parameters

The developer may then look at RFC 3455 and see if P-Charging-Vector  
works for them.  If it does, great... they'll use that.  If not,  
they'll invent yet another P-header to send along billing  
information.  Over time we'll wind up with even more out there in  
deployed usage.  So I'd like to add P-Charge-Info to that IANA list  
so that perhaps some developers looking for headers to use might NOT  
wind up creating yet more P-headers that do similar things, albeit  
with variations.  (Having said that, I'm sure there will be someone  
out there who doesn't like P-Charging-Vector *or* P-Charge-Info and  
goes off and creates another one... but perhaps we can limit that to  
a degree.)

As Miguel Garcia indicated in one of his notes, at some point in time  
these various networks may want to interoperate and exchange billing  
information and I think it is in our interest to have as few  
variations as possible out there.

Third and finally, as someone trying to do things in the "correct  
IETF way", I would add the reason:

   - RFC 3427 very clearly states that I MUST register this P-Header

Section 4.2 of RFC 3427 is very clear on this ( http://tools.ietf.org/ 
rfcmarkup?doc=rfc3427 ):
------
    4.2 Preventing Identity Conflicts Between P-Extensions:

    In order to prevent identity conflicts between P-headers, this
    document provides an IANA process (See: "IANA Considerations" below)
    to register the P-headers.  The handling of unknown P-headers is to
    ignore them, however, section 4.1 is to be taken seriously, and  
users
    of P-headers will have best results with adherence.  All implemented
    P-headers SHOULD meet the P-Header requirements in 4.1.  Any P- 
header
    used outside of a very restricted research or teaching environment
    (such as a student lab on implementing extensions) MUST meet those
    requirements and MUST be documented in an RFC and be IANA  
registered.
    IANA registration is permitted when the IESG approves the internet-
    draft.
------
When I read this:

       Any P-header used outside of a very restricted research or  
teaching
       environment MUST meet those requirements and MUST be documented
       in an RFC and be IANA registered.

I interpret that as saying that if I want to "play by the rules"  
established by the IETF, then I MUST document and register a P-header  
used in deployments today.

So back to your #1....  it's not that I want to register it to  
protect the name as much as it is that RFC 3427 says that I MUST  
register the usage. So that's what I'm trying to do.

If we (IETF) want to change RFC 3427 to NOT require registration of P- 
headers, I can certainly withdraw my draft (I have plenty of other  
things to work on).  We (Voxeo) can continue to use P-Charge-Info  
privately with the carriers with whom we interoperate and give them  
our specification for how we want to communicate with them - our CFO/ 
contracts team can still be happy.  However, as I mention above, I  
actually do think it is in our (IETF) interest to *encourage* P- 
header registration to potentially limit excessive P-header  
proliferation.

I hope this helps explain the reasons I submitted this draft.

Regards,
Dan

P.S. I realize that some of the authors of RFC 3427 are on this list  
and any comments on my third point about the requirements in section  
4.2 are definitely welcome.

---

From: Dan York <[email-masked]>
Date: Wed, 27 Feb 2008 08:20:30 -0500

Keith,

That is also my reading (and why I started down this path in the  
first place).  As I just noted in my own response to Jonathan (with a  
changed subject line), section 4.2 of RFC 3427 very clearly states:

       Any P-header used outside of a very restricted research or  
teaching
       environment (such as a student lab on implementing extensions)
       MUST meet those requirements and MUST be documented in an
       RFC and be IANA registered.

(where "those requirements" refers to section 4.1 which outlines the  
process you note below).

Regards,
Dan

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 28 Feb 2008 13:38:35 +0200

Hi,

 > This document does not contain enough information
> using this header. 

the authors of this draft need to address this comment if they want to 
be able to publish this P-header as an RFC at some point.

Cheers,

Gonzalo