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

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 01 Dec 2003 21:40:06 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 01 Dec 2003 21:40:06 -0600