Subject: Re: more sip phone feature emulations...

From: John Hearty <[email-masked]>
Date: Thu, 22 Apr 1999 08:56 -0500 (CDT)

This looks like a good solution.  If the IP endpoint did understand
the new parameter it could be smart enough to present "Anonymous" instead
of the encrypted address.  A terminating ISUP gateway would un-encrypt
the number and set the presentation parameter accordingly to satisfy
PSTN requirements.  Since this covers both IP and PSTN endpoints I
don't see the need to lump it in with PSTN interworking solutions.
Thanks for all your great work.

John Hearty
MCI Worldcom

Date: Thu, 22 Apr 1999 01:26 -0500 (CDT)
From: Jonathan Rosenberg <[email-masked]>
Organization: Bell Laboratories
To: [email-masked]
Sender: [email-masked]
Subject: more sip phone feature emulations...

This time, its caller-ID.

SIP easily does caller ID. In fact, since requests can be signed by the
caller or third parties, it can provide cryptographically strong caller
ID. Anonymous calling is also easily done.

Whats harder is when you're doing POTS to POTS, with SIP in the middle.
Caller ID blocking in the phone network actually has the caller's name
carried in the ISUP all the way, but just not presented to the called
party. When using SIP in the middle, the calling name and number would
need to be carried in SIP in the From field, but an indication that it
shouldn't be presented would also need to be there. Currently, there is
no such indication; I would argue it doesn't make much sense for IP to
IP.

The question is: how to do it in SIP? There are several ways:

1. treat it as yet-another-ISUP-parameter which is only used for phone
to phone, and handle it with the rest of them.

2. add a parameter to the From field which says, "don't present".

(2) is easy and general, but security wise is bad. Nothing stops a UAS
(gateway or PC) from presenting the name anyway, and nothing prevents
people from reading the field on the wire. So, how to add strong crypto
support here to make this service *better* than on the PSTN? One could
just encrypt SIP using the PGP mechanisms. But, the From field needs to
be in the clear. You could do ipsec or ssl, but this is just from proxy
to proxy and doesn't buy you good security between gateways.

So, Henning and I discussed and came up with an interesting possibility.
We allow the From URI and display name to be encrypted, but still follow
the BNF defined in RFC2543. We also add a few parameters to indicate its
encrypted. So:

From: "asd098yasdnasbyuy8" <sip:ojasd08yasdb>;enc=pgp;present=no

would be an encrypted version of the From field. Since its still a
completely valid From field, intermediate proxies don't know the better
even if they don't understand this encryption tag. Only the terminating
gateway would be able to decode it, and then it would also know not to
present it based on the tag. This would also work for calls to IP
endpoints. An endpoint receiving this, but not knowing about this
extension (and if there is no Require header), would still do an OK
thing, which is to present a name which makes no sense (i.e., looks like
anonymous anyway). This is reasonable behavior.

Thoughts on this? Does this fall into the "only useful for PSTN
interworking, so do it with the rest of the ISUP parameters" model?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen