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

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

> -----Original Message-----
> 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
> 
> 
> 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
> 

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 02 Dec 2003 07:58:27 -0600

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

Certainly, there are situations where an endpoint looses state an the 
session cannot be resumed without re-signaling. In your example, it is 
likely they are starting over from scratch.

I think the discussion in Minneapolis was targeted towards disconnects 
happening in the network, rather than at the edges.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 02 Dec 2003 07:58:27 -0600