Subject: [Sip] Next steps on RFC 4474 issues

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 09:18:29 +0100

After a longer delay than planned, I want to try to kick off discussions
on RFC 4474 issues again.
After much activity during IETF71, this is where I think we are, roughly
speaking:

There would seem to be 3 main issues:
1) Use of E.164-based SIP URIs within a SIP environment.
2) Use of E.164-based SIP URIs for numbers received from PSTN.
3) The SBC problem.

Item 1)(use of E.164-based SIP URI within SIP environment)
In fact, there are two angles on this item:

1a) the accuracy of the E.164 number, as characterised by questions such
as "is that number assigned to the originator of this request?" This is
independent of DTLS-SRTP;

1b) the meaning of the domain part, which does have a bearing on
DTLS-SRTP. It means the media are secured as far as that domain, so that
if that domain is an organisation you want to talk to, fine, but if it
is some intermediary, then you may be concerned.

I think there is a certain consensus that we can't do much more than
document this problem, but on the other hand we can try to avoid it to
some extent by encouraging the use of "email-style" SIP URIs.
E.164-based URIs will still be needed, particularly for interworking
with PSTN but also in those SIP environments where E.164 numbers are
more easily handled (e.g., phones with number-based user interfaces).
But perhaps we can explore more the possibility of using the two forms
in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style
in From. I know Dan has an interesting straw man on this topic. I will
call this topic "Migration from E.164 to email-style SIP URIs" and start
a new thread.

Item 2) (E.164-based SIP URIs from PSTN)
There seems to be some interest in adding some indicator to the URI or
to the header field to warn of the limited guarantee of authenticity. I
will start a new thread with the title "RFC 4474 and PSTN".

Item 3) (SBC traversal)
This received relatively little discussion during IETF 71 and on the
mailing list. I will start a new thread "RFC 4474 and SBC traversal".

There is of course interaction between 1) and 3), in that SBC
intervention can lead to re-signing, thereby solving 3) but introducing
1b).

As I said above, I will start 3 separate threads to further discuss
these three topics. The objective is to have a proposed way forward on
the separate topics by the next meeting, in terms of I-Ds, BoF proposals
or whatever.

So if you want to address those problems, please respond to the
appropriate thread. Respond to this email only if you have comments on
my interpretation of the set of problems or on the proposed process.

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