Re: [cnit] CNIT Charter bashing..

[Richard Shockey <[e-mail]>]

Yes Tim.  Thank you very very much. You cut to the chase of the problem
here.  Its not technology its policy and no matter how you end up looking
at this its National Policy.

KISS I just want to define the CNIT object and SIP headers and NOTHING
ELSE.  IF this should progress in the IETF that needs to be understood.

That said and this is not the carrier business case mailing list.  We all
know the problem has advanced to the point of degrading the value
proposition of the realtime communications service in North America. I’ve
argued endlessly in talks that “Protect what you have” makes sense and as
Henning correctly points out there is a business case for adding value
here to SIP based realtime communications across all the access platforms
including VoLTE and definitely enterprise and there is a real and
important Public Safety component here as well.

We know how this should work.  My Doctor wants to talk to me ASAP about my
medical test results. She wants to display to me that she is exactly who
she says she is and that should be possible so I don’t instantly drop the
call to voice mail or worse.  Her office is served by VZ my mobile is
served by ATT. My ATT VoLTE CUA should be able to trust…by multiple means
(including big yellow optical cable) that the INVITE is actually coming
from VZ.  I see some data on my phone etc I run out of what ever room I’m
in and take the call because I trust the SIP session.

BTW this is equally relevant if the call is initiated by Fairfax County
Public safety.

<begin non relevant rant>

We are trying to protect a 150+ Billion dollar business for SP’s which
represents voice across all the access platforms. I’m not going to support
third party business issues. We all want point to point video and it can
work if we can display who the heck is calling.

OTT is not a issue. Believe me. Get the Telegeography data on OTT
penetration in NA and its stunning once N America went to near flat rate
on voice the threat subsided. OK margins got shot but so did OPEX on
transport.  Our European friends are totally insane.  They are still
addicted to the drug of calling party pays and insane translation costs
then whine to the EU Commission about WhatsAPP etc. They need rehab.

That said our Congresscritter friends are one bunch of pissed off puppies
and at some point they will do some really really stupid if we don’t come
up with a plan. 




On 6/12/15, 4:42 PM, "Dwight, Timothy M (Tim)"
<[e-mail]> wrote:

>Yes, it's a business issue.  Brian wants the protocols to allow him to
>insert an unverifiable advertisement that his data is "good".
>
>If allowing this moves us forward, fine.  There's always some noise in
>the system.  But if this becomes a big topic of debate we need to take it
>out.  It's clearly not essential, and probably not even useful.
>
>Tim
>
>
>-----Original Message-----
>From: Richard Shockey [mailto:[e-mail]]
>Sent: Friday, June 12, 2015 3:01 PM
>To: Dwight, Timothy M (Tim)
>Subject: Re: [cnit] CNIT Charter bashing..
>
>
>
>On 6/12/15, 12:56 PM, "Dwight, Timothy M (Tim)"
><[e-mail]> wrote:
>
>>Who would assign the confidence value?
>
>Tinker bellŠ.the tooth fairy. :-)
>
>This could get really ugly and spawn endless lawsuits but its a
>reasonable idea if someone has a appropriate bayesian algorithm to apply
>to this at the terminating SBC.
>
>
>>If it's assigned by the entity that operates the calling name database,
>>why would it ever be less than the highest possible value?  If it's set
>>by some other entity, on what basis do they determine the value they
>>assign?  It seems like we're going to stumble over business issues.
>>
>>Tim
>>
>>
>>-----Original Message-----
>>From: cnit [mailto:[e-mail]] On Behalf Of Brian Rosen
>>Sent: Friday, June 12, 2015 11:28 AM
>>To: Richard Shockey
>>Cc: [e-mail]; Henning Schulzrinne; [e-mail];
>>Stephen Farrell
>>Subject: Re: [cnit] CNIT Charter bashing..
>>
>>One possible extra bit is that we need to know WHO signed.  That could
>>be easy (identity in a cert for the signature), but it¹s a requirement.
>>
>>I still want an optional confidence value, because the source is often
>>not authoritative.
>>
>>If we¹re thinking we¹re using the existing display name, and coming up
>>with a way to sign it, then, like stir, the termination side can decide
>>what it wants to do if it gets a display name but no signature.  The
>>sender has the option to provide the name or not, and provide the
>>signature or not.
>>
>>We COULD consider a new header that would contain the name encrypted
>>for a destination TN (To:).  That would afford privacy to the name to
>>middle boxes that we would not have today with display name.  I would
>>not be opposed to that.  This would work like the offline stir
>>proposal, where the sender obtains the public key of the recipient and
>>encrypts the name for the recipient.
>>
>>Brian
>>
>>> On Jun 12, 2015, at 8:49 AM, Richard Shockey <[e-mail]>
>>>wrote:
>>> 
>>> 
>>> Henning is right. No one is forcing anything. Existing anonymous
>>> calling protections still apply.
>>> 
>>> 
>>> Again my point is that is a great many cases Interconnected SIP
>>> between NA carriers are covered by other security mechanisms.
>>> 
>>> Right now your Facetime session is totally in the clear. My concern
>>> is we end up going down the rat hole of trying to create perfect end
>>> to end security nothing will get done.
>>> 
>>> 
>>> 
>>> On 6/12/15, 10:17 AM, "Stephen Farrell" <[e-mail]>
>>>wrote:
>>> 
>>>> 
>>>> 
>>>> On 12/06/15 15:13, Henning Schulzrinne wrote:
>>>>> In almost all cases of interest, the calling party *wants* to
>>>>> disclose accurate information to the called party, so the privacy
>>>>> issues don't seem to arise. They would only arise if there was
>>>>> forced disclosure; I don't think anybody is proposing that.
>>>> 
>>>> Privacy issues could also arise if a middlebox could now see
>>>> sensitive information that it previously could not see. I think that
>>>> is independent of whether disclosure is desired by either of the
>>>> endpoints.
>>>> 
>>>> S.
>>>> 
>>>> _______________________________________________
>>>> cnit mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cnit
>>> 
>>> 
>>> _______________________________________________
>>> cnit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/cnit
>>
>>_______________________________________________
>>cnit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/cnit
>>_______________________________________________
>>cnit mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/cnit
>
>