Subject: [Simple] MSRP Comments

From: Cullen Jennings <[email-masked]>
Date: Sun, 09 Nov 2003 21:16:14 -0800

The draft does not say much about if the forming a separate TCP connection
for each session between two relays. Some people have said this will use
less bandwidth than a single connection. I think it will consume much more.
The question is if this is trashing the commons or not -  I don't know.
Given one of the major reasons for not just using Page mode for everything
revolves around concession control, I think it needs a little discussion.
Not that we are doing this but ... Setting up a new TCP connection for every
UDP packet you want to send completely defeats the congestion control
properties of TCP.

I would prefer if it said you MUST implement both passive and active. I
think it is unacceptable that two clients could be fully compliant with the
RFC and not be able to send message to each other. I'm fine with them be
configured such that they can't.

I don't see the need to support switching to TLS after the first message has
been received. This just introduces to many weird things to figure out on
authorization. Why would you switch?

TLS is way underspecified - what do the certs need to say - how does mutual
TLS work - can two relays use self signed certs  - how would that work. I
know I have threatened to send text before - hopefully I will at some point
:-)

It's not really clear how you switch to a TLS session. I'm very suspicious
that the look ahead scheme to switch to TLS is going to be very hard to
integrate with existing libraries -  I'm fairly confident that STARTLS will
work so why not use it?

I still think the draft should explicitly discuss more than two relays.
There are many needs to relays and saying put a full B2BUA in to meet all
these other needs is bogus. I expect this comment to be ignored :-)

I like the resolution of new sessions for large messages or separate
conversation threads.

Cullen

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

---

From: Adam Roach <[email-masked]>
Date: Mon, 10 Nov 2003 13:46:07 -0600

Cullen Jennings writes:

> I'm very suspicious that the look ahead scheme to switch to
> TLS is going to be very hard to integrate with existing
> libraries

Like OpenSSL?

int Msrp::read(char *buffer, int maxLen)
{
  int len;
  int magic;

  if (!usingSsl)
  {
    len = recv(s, &magic, 4, MSG_PEEK);

    if ((htonl(magic) >> 8) == 0x160301)
    {
      SSL_set_fd(ssl, s);
      usingSsl = true;
    }
    else
    {
      len = read(s, buffer, maxLen);
    }
  }

  if (usingSsl)
  {
    len = SSL_read(ssl, buffer, maxLen);
  }

  return len;
}

(modulo error checking)

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Nov 2003 09:39:14 -0600

Cullen Jennings [mailto:[email-masked]] wrote:

> How do you do this on an OS that only supports a single byte 
> peek?

As long as you're doing framing the obvious way (i.e.,
read the leader line to get the message size, and then
blindly read that many bytes), then you can simply check
whether the first byte is 0x16 (not valid in an MSRP
leader line).

> I do love when you send code, it always makes my day, but my 
> question was not could you do this but why would you not do
> it the other way.

No, you expressed a concern that a switch to TLS would not
be easy to integrate with existing libraries. I included code
to show how easy it is, since that seems more compelling than
just saying, "no, you're wrong."

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 14 Nov 2003 09:39:14 -0600

/a