Subject: Re: [Simple] Re: MS(r)P: Reconnect issue

From: "Andrew Allen" <[email-masked]>
Date: Tue, 2 Dec 2003 08:47:00 -0500

Ben

Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec instead of TLS for security between itself and the mobile UA mandating TLS for SIP/SDP will not help in the 3GPP situation either unless a radical change is made to the current 3GPP security architecture.

If some people want to attempt reconnections without re-signaling is it possible to use the VISIT 200 OK exchange to initially negotiate support for reconnections and to exchange the necessary keys/certificates for validation that the reconnect attempt came from the same endpoint as the initial VISIT? 

I am not a security expert but if this is feasable then it would make reconnections possible but optional based on mutual negotiations between endpoints. If such a scheme requires TLS on the MS(r)P connection then TLS or TCP could also be part of the SDP negotiation in the initial offer.

For the wireless case I think we will want to use a renegotiation using SIP as it is most likely that one of the mobiles went out of radio coverage or that the battery died. In this case we want to detect using signaling as soon as possible that the mobile is unreachable so that the session can be released and the radio resources freed up. So I think you can place me in the re-signaling camp.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
European Mobile    +358 50 467 5870
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: Ben Campbell <[email-masked]>
To: Andrew Allen <[email-masked]>
CC: Simple WG <[email-masked]>
Sent: Mon Dec 01 22:40:06 2003
Subject: Re: [Simple] Re: MS(r)P: Reconnect issue

Andrew Allen wrote:

> Ben 
> 
> Ben,
> 
> If Option 2 requires end-to-end encryption of the SDP to protect the URL
> then it is not going to be suitable for use by 3GPP for message sessions
> at the present time. The 3GPP network currently needs to examine the SDP
> to perform authorization and allocation of radio resources for the
> session.

A possible alternative is the use of the SIPS scheme, where the device 
that must inspect the SDP is a participant in one of the TLS 
handshakes--and therefore can see the contents. But I must admit that 
approach feels a little spooky.

> 
> In the wireless case the chances of dropped connections are probably a
> lot higher with the mobile potentially moving in and out of coverage
> (especially if going through tunnels on a train) so this is likely to be
> a more common scenario in wireless.
> 
> What were the main objections to re-invitation as a solution?
> 

The objection was that such TCP drops happen alot, and people wanted the 
lightest weight recovery possible. If a simple TCP reconnect would work, 
it would be nice--but I don't think it will work.

> Why not use UPDATE to attempt to re-establish connections in the case
> when the dialog still exists? UPDATE is less expensive in terms of SIP
> messages to re-establish (no ACK required). In the 3GPP case the sending
> of a SIP request is likely to trigger a network initiated termination of
> the session (a BYE) if the mobile is still out of coverage, which I
> expect is what is desired in the wireless case to release the network
> resources.

If we establish that we must use a new SDP exchange, then I expect 
UPDATE and reinvites to both be applicable, depending on the particular 
circumstance.

> 
> Andrew
> 
> 
>  
> 
>>-----Original Message-----
>>From: Ben Campbell [mailto:[email-masked]]
>>Sent: Monday, December 01, 2003 2:54 PM
>>To: Ben Campbell
>>Cc: Simple WG
>>Subject: [Simple] Re: MS(r)P: Reconnect issue
>>
>>Oops, got my options mixed up. See clarification below.
>>
>>Ben Campbell wrote:
>>
>>
>>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending
>>>rename) should allow reconnection of dropped TCP connections without
>>>requiring a new offer/answer. In that meeting, I mentioned that
> 
> there
> 
>>>was a reason we had originally chose not to allow that, but I could
> 
> not
> 
>>>remember the details at the time. Having slept since then, I now
>>
>>remember:
>>
>>>Consider a visitor V has a TCP connection to a host H, with an
> 
> active
> 
>>>session. That TCP connection is then dropped due to something in the
>>>network. I don't know why, maybe a stateful firewall dropped state,
> 
> or a
> 
>>>length of fiber was accidentally eaten by a sabre-tooth tiger. In
> 
> any
> 
>>>case, the connection is dropped without a proper FIN handshake at
> 
> the
> 
>>>endpoints.
>>>
>>>It may take each endpoint sometime to actually notice that this has
>>>occurred. Using common TCP state machine defaults, it will typically
>>>take just under 10 minutes. It is also likely that the participants
> 
> will
> 
>>>not figure it out at the same time.
>>>
>>>If H figures it out first, then things are reasonable ok. It just
> 
> waits
> 
>>>some period of time for V to notice, reconnect, and send a VISIT
> 
> with
> 
>>>the session URI.
>>>
>>>But if V figures it out first, we have a problem. V will reconnect,
> 
> and
> 
>>>attempt a VISIT with the session URI. The problem is, H thinks it
>>>already has a perfectly good connection for that session. It has two
>>>possible choices: 1) Fail the new VISIT, and assume the old one is
> 
> still
> 
>>>good, or 2) Disconnect the old connection, and accept the VISIT
> 
> request
> 
>>>on the new connection.
>>>
>>>Option 1 is the currently defined behavior. It seems pretty obvious
> 
> that
> 
>>>this pretty much prevents reconnections. Option 2 would allow
>>>reconnections, but it allows a really nasty session hijacking attack
> 
> if
> 
>>>an attacker happens to learn the session URI.
>>>
>>>I discussed this with several people a while back, and the consensus
>>>seemed to be that option 2 was not feasible, so we had to require a
> 
> new
> 
>>>sdp exchange with a new session URI in order to reconnect.
>>
>> >
>>
>>>Option 1 _might_ be acceptable if we could guarantee the
> 
> confidentiality
> 
>>>of the session URI. If we were to accept option 1, we would then
> 
> have a
> 
>>>strong reason to _require_ the sdp exchange be protected by using
> 
> either
> 
>>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1
> 
> also
> 
>>>requires the host to listen for new connections pretty much forever,
>>>which is not particularly pleasant.
>>>
>>
>>For the above paragraph, I meant option 2. My apologies if anyone hurt
>>their brain trying to figure out how that paragraph applied to option
> 
> 1.
> 
>>
>>>Thoughts? Have I missed an option?
>>>
>>
>>
>>
>>_______________________________________________
>>Simple mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Dec 2003 11:41:10 -0500

Andrew,

Is it not true that for hand-offs in mobile networks that existing "calls" 
being handed-off into new cells get precedence over new calls?

It seems that if you use the INVITE versus UPDATE methods, that you lose 
this advantage and the dropped call rate will increase.  However, if you do 
not feel that there is a resource contention issue, then this may not be a 
problem.

Mike

At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote:

>Ben
>
>Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec 
>instead of TLS for security between itself and the mobile UA mandating TLS 
>for SIP/SDP will not help in the 3GPP situation either unless a radical 
>change is made to the current 3GPP security architecture.
>
>If some people want to attempt reconnections without re-signaling is it 
>possible to use the VISIT 200 OK exchange to initially negotiate support 
>for reconnections and to exchange the necessary keys/certificates for 
>validation that the reconnect attempt came from the same endpoint as the 
>initial VISIT?
>
>I am not a security expert but if this is feasable then it would make 
>reconnections possible but optional based on mutual negotiations between 
>endpoints. If such a scheme requires TLS on the MS(r)P connection then TLS 
>or TCP could also be part of the SDP negotiation in the initial offer.
>
>For the wireless case I think we will want to use a renegotiation using 
>SIP as it is most likely that one of the mobiles went out of radio 
>coverage or that the battery died. In this case we want to detect using 
>signaling as soon as possible that the mobile is unreachable so that the 
>session can be released and the radio resources freed up. So I think you 
>can place me in the re-signaling camp.
>
>Andrew

---

From: Michael Hammer <[email-masked]>
Date: Tue, 02 Dec 2003 11:41:10 -0500

Andrew,

Mike