Subject: [Sip] Review of draft-ietf-sip-connected-identity-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Jul 2006 20:39:12 -0700

BACKGROUND
SIP allows "retargeting" in which the endpoints (on either end) of
a call can change. So, for instance, Alice might be calling Bob
but actually get forwarded to Charlie. This draft describes a
mechanism for the new endpoint to notify their peer that their
identity is not the same as the peer expected.

BASIC MESSAGE FLOW
The basic message flow without this draft looks something like this:

Alice                         Proxy                       Carol
-----                         -----                       -----
INVITE (To=Bob) -> 
                                INVITE (To=Bob) ->     
                                                 <- OK (To=Bob)
                   <- OK (To=Bob)                
ACK (To=Bob) ->                
                                ACK (To=Bob) ->

This draft adds a new set of messages for Carol to tell Alice about
the retargeting. Like this:

Alice                         Proxy                       Carol
-----                         -----                       -----
INVITE (To=Bob) -> 
                                INVITE (To=Bob) ->     
                                                 <- OK (To=Bob)
                   <- OK (To=Bob)                
ACK (To=Bob) ->                
                                ACK (To=Bob) ->

                                         <- UPDATE (From=Carol)
            <- UPDATE (From=Carol)
ACK (From=Carol) ->                
                                ACK (From=Carol) ->

SECURITY ISSUES
This draft relies on the ordinary SIP authentication mechanisms
(primarily Identity, I would imagine) in order to validate the update
message. Unfortunately, this just tells the other side that they're
now talking to someone new securely. They have no way of determining
whether the retargeting was authorized or not. This is explicitly
acknowledged in the Security Considerations section. Clearly 
something along these lines is needed. Perhaps it could
go in a different draft, but this does seem like the obvious one.

EDITORIAL
1. I found this document fairly hard to read until I figured out what was
going on, perhaps due to my lack of familiarity with SIP. ISTM that a
diagram like the one above would be appropriate here--some diagram
definitely seems advisable.

2. It would be helpful to have unique and distinctive terms for the
UA that isn't being retargeted (Alice above) and the one that is
(Bob/Carol). I found myself trying to figure that out. These
terms should be called out explicitly early on.

S 3. 
You should explicitly state that To doesn't change during retargeting.
That is an unobvious behavior of SIP.

I think some diagrams of these scenarios would help.

The following paragraph is a good example of what I mean above about
distinctive terms:

   However, call re-arrangements are not always carried out using a new
   INVITE request.  Sometimes a B2BUA performs call re-arrangements
   using third party call control (3PCC) techniques.  With such
   techniques the UA involved in the original call and still involved in
   the re-arranged call receives only a re-INVITE or UPDATE request in
   the context of the original dialog between that UA and the B2BUA.
   This forces the UA to re-negotiate the session with the new remote
   party, but introduces a need to convey the identity of the new remote
   party to the UA.  Because there is no new INVITE request (outside the
   context of the existing dialog), techniques applicable to new calls
   do not apply.

"the UA involved in the original call and still involved in
the re-arranged call" is too long to process as one chunk.

S 4.
It should be made clear that this is background material that
will be used later. It's not an alternative to the current
approach, which I kind of got the impression from "Existing".

It would probably halp to name these mechanisms in some easy
to remember way. I'm sure they already have names....

S 6.2.
Just for clarity, you don't need to send an UPDATE/re-INVITEif you
don't support id-change. So, the peers already need to be able to deal
with a non-UPDATE-sending situation, right? So, I'm not sure
I understandw hy you need to send the UPDATE/re-INVITE if nothing
has changed...

7.2.
There is a very bad break in this table. The headers need to be on
the same page as the columns.

_______________________________________________
Sip mailing list  https://www1.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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Jul 2006 11:59:47 +0100

Eric,

Thanks for reading this draft. See my responses below.

John 

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: 04 July 2006 04:39
> To: [email-masked]
> Subject: [Sip] Review of draft-ietf-sip-connected-identity-00
> 
> BACKGROUND
[JRE] There has been a lot of discussion on this point in the past, and it
is proving quite hard to come up with a solution for determining whether
retargeting was authorised or not. Whilst there are some people still
looking into this (e.g., draft-cao-sip-response-identity-00 and
draft-cao-sip-response-auth-01), the SIP group felt that it would be
appropriate to proceed with the connected-identity work, since this is well
understood and easily achievable. This does not prevent continued
investigations into authorised retargeting, but any mechanism to achieve
that will be in a separate document.

> definitely seems advisable.
[JRE] We do have this in the examples section.

> terms should be called out explicitly early on.
[JRE] I get your point - the use of the terms UAC and UAS are not helpful,
since roles are reversed when the UPDATE request is sent. I will think about
it further when I work on the next draft after the meeting.

> That is an unobvious behavior of SIP.
[JRE] OK

> the re-arranged call" is too long to process as one chunk.
[JRE] I will write instead: "For example, when call transfer is carried out
by a B2BUA the transferred UA With such techniques the UA involved in the
original call and still involved in the re-arranged call receives only a
re-INVITE or UPDATE request in the context of the original dialog between
that UA and the B2BUA."

> approach, which I kind of got the impression from "Existing".
[JRE] OK
> to remember way. I'm sure they already have names....
[JRE] OK

> I understandw hy you need to send the UPDATE/re-INVITE if nothing
[JRE] In order to an Authentication Service to insert an Identity header
field, to provide authentication of the fact that nothing has changed. The
source XML has this explanation, but due to an error in the XML tags it got
dropped by xmlToRfc.

> the same page as the columns.
[JRE] I will investigate whether xmlToRfc allows me to correct this.