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

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

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Tuesday, December 02, 2003 11:41 AM
> To: Andrew Allen
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Re: MS(r)P: Reconnect issue
> 
> 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
> >--------------------------
> >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

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

---

From: Michael Hammer <[email-masked]>
Date: Thu, 04 Dec 2003 18:46:21 -0500

Andrew,

I may have misunderstood your previous posting.  This thread seemed to 
imply that sending an UPDATE if the transaction fails due to temporary 
disconnect, would result in failure of the UPDATE only.  Whereas, the 
failure of a re-INVITE would cause the network to send a BYE and release 
all resources down through the radio links.  But, I had the impression that 
you were saying that in either case all resources would be freed assuming 
the user won't reappear.

But, from a user's perspective, he would likely re-attempt the dialog or 
this may be automatic if he did not explicitly terminate it.  Thus, the 
INVITE triggers lower level connection setup including perhaps the TCP that 
you don't want to be burdened with and at the GPRS and link layers this 
appears to be a new contention for resources, not a re-establishment of 
resources as in a handoff.

So, in summary, the discussion went from how to resync the dialog due to 
connection interrupts, to using dialog layer to cause connection breaks, 
but not wanting re-TCP connections to be a burden.  All I was suggesting 
was that using higher layer functions to cause break and reconnects would 
lead to the burdens you wanted to avoid, plus have the side effect of 
putting you at the end of the line for resource requests where contention 
might occur.

Pardon the tangential nature of this sub-thread.

Mike

---

From: Michael Hammer <[email-masked]>
Date: Thu, 04 Dec 2003 18:46:21 -0500

Andrew,

Mike