Subject: Re: [Simple] MSRP: Implications of removing connection sharing

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 May 2003 04:49:04 -0400

inline.

Ben Campbell wrote:
> We seem to have a consensus to remove connection sharing from the spec,
> at least for TCP connections. I think we have not yet converged on
> whether SCTP offers a solution for multiplexing multiple sessions over
> the same connection between relays or not.
> 
> Ignoring the SCTP discussions for the moment, removing connection
> sharing has a few implications. These are probably good implications,
> where good is defined as simplifying the protocol. But they may suggest
> some fundemental changes to the way MSRP works.
> 
> 1) Without connection sharing, it becomes easier to treat relays as
> connection tunneling devices rather than message switchers. Several
> people have suggested a desire to do this or something similar. I use an
> HTTPS proxy as an example, where once the session is established across
> the proxy, the proxy just forwards packets back and forth. This has some
> nice properties. You can have e2e TLS handshakes in spite of the
> existance of relays.

This is a bit more complicated than in the HTTP case. Thats because you 
will have two user agents, both of which could be clients for TCP (that 
is, both open TCP connections to a relay), but one of which will act as 
a server for the TLS handshake. The normal HTTPS case is that the TCP 
client is also the TLS client, and the TCP server is the TLS server. We 
would first need to figure out who acts as the TLS client (not hard), 
but my concern is that TLS libraries wouldn't support this mode.

Furthermore, since clients are not going to have certs, I don't see this 
being useful.

I also recall discussing this model of just doing byte switching based 
on tcp connections a long time back. One of the concerns raised was that 
people wanted these relays to do logging of messages, and this wouldn't 
work in a relay that is not message oriented. In fact, I recall having a 
requirement to this effect in my original email on requirements.

A slightly different model is that the stream switching is limited to 
the case where a user basically does a visit through a relay. In other 
words, in the two relay case, if user A does a BIND to its relay, that 
relay becomes the termination point of a TLS connection. When the other 
client does a visit, is TLS connection is tunneled through its relay, 
but terminates on the one where the BIND took place.

This has the benefit of making the TLS usage resemble the web model. It 
doesn't help the logging problem since the relay on the visiting side 
still won't see messages.

I dont recall if there were other problems with this byte-switching 
approach beyond the logging.

  You can simplify flow control--if a relay is
> blocked sending on a downstream connection, it just stops receiving on
> an upstream connection. If a downstream connection drops, the relay can
> just drop the upstream connection and let the prior hop deal with it at
> the transport level.

You don't need this byte-switching approach to achieve that. You can get 
it with message oriented too.

> 
> 2) Their is no longer a need for a MSRP to contain headers to identify
> the session it belongs to. The session is fully determined by the
> connection on which it arrives. This is interesting because it seems to
> make generalization of MSRP sessions to allow more than two participants
> an easy extension. If more than 2 connections are associated with a
> session, you simply send data received for a session to all connections
> except the one it arrived on.

Actually, it occurs to me that if we go for this kind of byte-forwarding 
approach, MSRP basically turns into TURN plus some message framing. That 
is, we would more or less be back to designing a protocol for the 
no-relay case, and to deal with fw/nat, be using something like TURN. 
Its not quite TURN since TURN doesn't have this notion of the HTTP 
CONNECT type of tactic, though I must admit I have been considering 
adding that to TURN, in which case it would be exactly equivalent.

TURN was one of the proposals on the table for dealing with relays for 
message sessions way back when... feels like we are going in circles :(

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 30 Apr 2003 20:08:58 -0700

My goal in the original posting was to get some discussion on topic because
I felt it was needed - I certainly can't complain about the lack of
discussion. 

I'm ok with a SHOULD for SCTP between relays and I do understand what
Henning pointed out - I'm fairly doubtful SCTP would be implemented but it's
worth a try. Designing our own mux scheme that works seems both hard and a
bad idea. I notice there has not been much discussion on the BEEP
possibility. A few of my own back of the envelope calculation indicate that
two separate TLS connection for every session at every relay might scale OK
but I don't see how we can decide this with absolutely no statements or
assumptions about the scale of the systems we are trying to design a
solution for. 

I suspect there are a few more people that have been watching the
conversation are going to think about all of it and, when they get a chance,
post a few opinions. Given the lack of a concrete proposal, of what the
requirements are or how to solve them, I'd think it's a bit early to claim
consensus on this topic yet. I agree we need to move quick on this.

Cullen

PS. I notice the argument on this topic has taken a very strange form: It
now looks something like - We have proved that X will not work. So we are
treating that as consensus to go do (not X) with little discussion of if
(not X) will work or not.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 May 2003 08:59:01 -0400

> requirement to this effect in my original email on requirements.

I don't see why byte-streaming interferes with logging. This is just

while not end-of-message {
   read block from input socket
   if (header) {
     stick in header buffer
     if header done
       parse header
       set up logging information
       dump header into output socket
   } else {
     write block to output socket
     write block to logging device (socket, file, ...)
   }
}

---

From: Ben Campbell <[email-masked]>
Date: 01 May 2003 08:50:05 -0500

> but my concern is that TLS libraries wouldn't support this mode.

In both cases, you would build an e2e "virtual" connection, then execute
a starttls. While I have not _proven_ this is supported by common TLS
libraries, but I would be surprised if it was not. I agree, we would
have to add some complexity to determine who is the server.

> Furthermore, since clients are not going to have certs, I don't see this 

Do we have a requirement to support e2e protection for clients with no
certs?

I have to point out that almost _any_ security scheme we have discussed
eventually requires client certs. For example, assume we use s/mime with
session keys negotiated in the sdp. We would then have to protect the
_sdp_ exchange with s/mime, which would require s/mime certs at the
clients.

> requirement to this effect in my original email on requirements.

You _could_ just log the byte-stream, then parse out messages after the
fact. (This of course interacts with any encryption scheme, but I think
that is ok.)

> approach beyond the logging.

I believe that the _biggest_ reason was the connection sharing issue.

> it with message oriented too.

But you get better granularity with byte or chunk switching. If you
don't start sending a message downstream until you fully receive it from
upstream, you end up having to buffer a lot more if you have large
messages.

> message sessions way back when... feels like we are going in circles :(

Hopefully, we have enough participants in this dicussion that we can end
the circle now.

---

From: Ben Campbell <[email-masked]>
Date: 01 May 2003 10:40:31 -0500

On Wed, 2003-04-30 at 22:08, Cullen Jennings wrote:

[...]

> (not X) will work or not.

Hmm. I was interpreting two parts to the argument:

1) The feature of session multiplexing over TCP connections is proving
hard. Consensus seems to be to remove the feature.

2) It _might_ be possible to add the feature back for SCTP. Consensus is
not clear on this point.

So, is your point that for argument 1 we have failed to consider if MSRP
is workable at all without the feature?

I think that for the peer-to-peer scenario, the answer to that is
trivially identical to any other e2e messaging protocol that uses
typical IETF conventions (text based, MIME, etc.) So the question
becomes are _relays_ workable without session multiplexing. Before we
delve too deep into that, remember why relays are there in the first
place: NAT and firewall traversal. The need for multiplexing in the 2
relay case is at least somewhat affected by the percentage of sessions
that actually use 2 relays.

While I recognize that NATs and restrictive firewalls are not going away
very soon, I think that we should strongly discourage the 2 relay
scenario except in very specific cases. We _definitely_ should not
encumber the protocol with an assumption that the 2 relay scenario is
the default deployment.

(Yes, I realize there is a lot of wishful thinking in that assertion.)

I think the course forward is to assume no session multiplexing. Session
multiplexing between relays_can_ be added as a future extension, but
such a solution must be completely transparent to the endpoints. SCTP
_might_ be a solution, but I doubt it is a _complete_ solution. 

To make this statement more concrete, consider the discussion in a
separate thread on the potential of using e2e TLS across relays. If we
commit to that feature, (and I am not trying to judge that in _this_
particular argument) then a follow on connection sharing solution will
need to preserve that capability. That won't be a trivial requirement,
but is probably not impossible.