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

From: Ben Campbell <[email-masked]>
Date: Mon, 01 Dec 2003 13:12:26 -0600

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.

Thoughts? Have I missed an option?

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

---

From: "Andrew Allen" <[email-masked]>
Date: Mon, 1 Dec 2003 15:39:02 -0500

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.

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?

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.

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:
> 
> 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.

---

From: [email-masked]
Date: Tue, 2 Dec 2003 11:13:02 +0200

Here is another reason I gave in an earlier discussion:

One endpoint might crash and reboot. Ports might change so you need to re-signal.

BTW, I don't believe we had consensus in Minneapolis. In any case, I think re-signalling is needed.

/Hisham

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Ben Campbell
> Sent: 01.December.2003 21:12
> To: Simple WG
> Subject: [Simple] MS(r)P: Reconnect issue
> 
>

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 2 Dec 2003 10:11:41 -0000

I'm also in the re-signaling camp.  It seems a far more elegant solution
compared to TCP socket negotiation BUT with the obvious SIP traffic
trade off (which is probably why UPDATE should be encouraged).  The text
will need to explicitly force the Hosting endpoint to dispose of the
current session (which it might still think is OK) and then prepare for
the new VISIT.  

Chris.

>From: [email-masked] [mailto:[email-masked]]
>Sent: 02 December 2003 09:13
>To: [email-masked]; [email-masked]
>Subject: RE: [Simple] MS(r)P: Reconnect issue
>
>One endpoint might crash and reboot. Ports might change so you need to
re-
>signal.
>
>BTW, I don't believe we had consensus in Minneapolis. In any case, I
think
>re-signalling is needed.
>_______________________________________________________________________
_
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>_______________________________________________________________________
_

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 2 Dec 2003 10:11:41 -0000

Chris.

re-
think
_
_

---

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

> to perform authorization and allocation of radio resources for the

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.

> 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.

> expect is what is desired in the wireless case to release the network

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.

>>>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
> 
>>>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.
>>>
>>>take just under 10 minutes. It is also likely that the participants
> 
> will
> 
>>>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
> 
>>>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
> 
>>>reconnections, but it allows a really nasty session hijacking attack
> 
> if
> 
>>>seemed to be that option 2 was not feasible, so we had to require a
> 
> new
> 
>>>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
>

---

From: "Andrew Allen" <[email-masked]>
Date: Thu, 4 Dec 2003 17:41:09 -0500

Mike,

Being a packet guy I am not sure what the relative priorities are for
all networks during a circuit switched cellular handover however what
you suggest makes sense.

I am not sure what your point is though related to the MS(r)P reconnect
issue. In GPRS the IP packet tunnel should be maintained during
cell-cell handovers so the MS(r)P connection should not drop during
handover.

My main concern is that MS(r)P not have mandates (such as SDP
encryption, use of TLS for SIP etc) put on it that make it incompatible
with the cellular SIP infrastructure just because of this reconnection
issue and that the wireless endpoints do not continually attempt to
reconnect at the TCP layer consuming scarce radio resources when the far
endpoint is either out of radio coverage or the battery is dead. 

If an Invite or Update is sent as part of an existing dialog then this
will not be seen as a "new call attempt" if that is your concern.

Andrew

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 11:41 AM
> To: Andrew Allen
> Cc: [email-masked]; [email-masked]
> 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
> > > If Option 2 requires end-to-end encryption of the SDP to protect
the
> URL
> > > at the present time. The 3GPP network currently needs to examine
the
> SDP
> > > (especially if going through tunnels on a train) so this is likely
to
> be
> > > of a SIP request is likely to trigger a network initiated
termination
> of