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: Ben Campbell <[email-masked]>
Date: Mon, 01 Dec 2003 13:53:39 -0600

Oops, got my options mixed up. See clarification below.

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

---

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 01 Dec 2003 16:32:56 -0800

Requiring S/MIME is definitely not the right path.

I lean towards using a reinvite.

Cullen

PS. I think temporary loss of 802.1x while walking down the hallway will
occur more often than the saber tooth tigers eating my fiber :-)

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 01 Dec 2003 16:32:56 -0800

Cullen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2003 11:50:00 -0500

I am also in the resignal (reinvite/update) camp. The problems of 
reconnecting without seem hard and not worth the effort of trying to solve.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Dec 2003 11:50:00 -0500

Paul