Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol

From: Oded Cnaan <[email-masked]>
Date: Thu, 23 Aug 2001 16:37:29 +0200

I agree with Joshua K regarding the MESSAGE analysis. It's important to
remember, that leaving IM to end-to-end communications results in a security
hole that allows other users to reveal your IP address.

Several IM services that used to reveal users' IPs (like ICQ) caused deadly
attacks by hackers on user's clients. If you take a look at the leading IM
services, none of them support end-to-end communications (for IM). 

There are two different concepts in IM, that sometimes are perceived as one.
The first is Instant Messaging (IM) which means sending direct and quick
message to someone. The latter is chatting, which means continuous
messaging. Several services converge these concepts into one feature while
other let the user choose between the two.

I think that SIP needs to support both options. MESSAGE should be used to
send a direct IM (through the server, that might redirect it to the client)
and a session for initiating a chat. 

Oded Cna'an
VP, New Technologies
Odigo Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, August 23, 2001 2:12 PM
To: [email-masked]
Subject: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol

Howdy

watching and putting some pieces together and I have this to offer...

There appear to be two significant issues:

1. the IESG wants to tank MESSAGE method for MESSAGE sessions or 'chat' like
conversations between known SIP UAs based on SIP Extension Rules, i.e. looks
like a transport protocol

2. using the MESSAGE method for simple 'paged' instant messages or one-off
instant messages is OK.
	
although one could argue it is still a mis-use of ideal SIP.  This is
because it is still carrying a payload and not necessarily initiating a
'session'  Unless the session is a human-based session, i.e. "come here
watson" or "can I ask you a quick question?" which would then create the
need for a 'session of MESSAGES' or physical appearance, either of which
SHOULD be handled by another protocol.

However, having another protocol for 'sessions of MESSAGEs' leads to the
issues Robert O. brought up, which were then refuted by Jonathon R. on the
basis of internet-drafts and scalability issues.  Moreover, the fact that
the MESSAGE extension was being perceived as a 'transport' violates the use
of SIP extension (ID sip-guidelines-02.txt section 3.1.)

SIP is supposed to act more like Chuck Wollery from 'the love connection' -
to use a colloquialism, i.e. bringing together

Jonathon R. would like to have end-to-end session of MESSAGEs to travel
between the clients directly as this supports the scalability and original
voice use of the SIP server.  On the other hand this doesn't support the
fundamental design requirements of IM as stated in rfc2779 2.4.3/2.4.4.
Which means, prior to supporting that end-to-end communication, the SIP
server would have to determine if 'that was allowed' based on the security
requirements Vasilis and Robert O have been talking about, which is also
required per rfc2779.

Those fundamental services can be easily implemented at the SIP server if
SIP was the method used to send 'sessions of MESSAGES' - problem here, IESG
doesn't like it.  There is a good reason why it is liked it's 'convenient',
but conveniences are not always a value.

So what we have is the need to 'reuse or create security features' adjunct
by the modular/portability needs and requirements of SIP/Signaling

The intermediary/PROXY MUST be created and supported as a basic feature of
the IM 'session of MESSAGEs' design.

In Robert Os case he would want the development of that intermediary to play
off of the domain and security information designed into the SIP server
(thus making it portable across SIP and the IM proxy).

This is easily designed if you have a unified configuration-directory where
the SIP Server and IM Message proxy pull configuration information,
otherwise, it looks like a complex proposition.

Should the protocol used for 'sessions of MESSAGEs' define how the
intermediary would be used? Yes, it has to, if it is to meet the design
requirement of rfc2779 2.4.3/4

In addition, to support end-to-end signaling the SIP server needs to have
logic on whether or not that end-to-end signaling is allowed or whether it's
end-to-end-to-end-to-end :) - this meets the rfc2779 2.4.3/4 requirement,
regardless of natiness.

So in retrospect:

MESSAGE SIP extension can't be used for sessions of IMs other wise it looks
like a transport mechanism and should be implemented separately

You need to design in the ability to use an intermediary per rfc 2779
2.4.3/4 (at a minimum)

We will have to figure out a way to get the bonus of domain/security from
SIP server into an IM intermediary.  A simple solution exists in using SIP
server to determine use of initiating sessions through an intermediary?
That is session initiation.

Jonathon R. has some good solutions for the intermediary in other IDs he has
written, but the reality is the communication looks more like 'direct
chatting' than text based audio/video conference, which is why the IESG
probably frowned on using RTP - wasn't there so I can't say for sure.  At a
high level these look the same, but at a low level the solution breaks down,
i.e. no video frames or audio sequencing in the protocol mechanism.  Which
is probably why ID cpim-msgfmt specifies the use of an existing text based
format, RFC822.

As an aside, I would also presume this is why sctp may not be a necessary
choice for the instant message 'signaling', to use a term from voice drafts,
given the sctp's primary use, albeit congestion management at the
intermediary/PROXY.  IMs are only text per node, am I naive to think it's a
moot point or would there be congestion issues at the intermediary???

Lastly, Jonathon R appears convinced that the communication should be
end-to-end.
(http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html),
but over TCP :)!  That works great if you are trying to scale the servers
and you want to put two callers together, but with IM, it's not voice and
it's like email, but more importantly, as stated in rfc2779, the
security/control needs to be built in.  I am just pointing out the
'vision/scope' of rfc2779 that says 'when you are heads down discussing
technical stuff, don't forget these requirements'  Jonathon didn't write
that RFC2779 so he probably isn't thinking with that light bulb on.

I would not want to see the IMsession design based on 'phone-calls' as
that's the 'way SIP has been predominatly used', but instead, to take a
different and assuredly positive approach.

I am not intending to offend anyone and I took some time to listen to the
forum, prior to submitting my points.  TIA

Joshua

--
Joshua L. Konkle
Business Technology Architect
Digital Knowledge
http://www.digitalknowledge.net
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Thu, 23 Aug 2001 09:34:55 -0500

>hole that allows other users to reveal your IP address.

A possible way to avoid this is to use HIP (Host identity payload)
instead of IP addresses to identify the clients. This would give e2e
security between the end points as well as prevent attacks because of
IP address exposure.

>services, none of them support end-to-end communications (for IM). 

According to RFC3041 :
"
   Use of the extension causes nodes to generate global-scope
   addresses from interface identifiers that change over time, even in
   cases where the interface contains an embedded IEEE identifier.
   Changing the interface identifier (and the global-scope addresses
   generated from it) over time makes it more difficult for
   eavesdroppers and other information collectors to identify when
   different addresses used in different transactions actually
   correspond to the same node
"

So in the case of IPv6 clients could possibly use this mechanism to
achieve some degree of privacy and a way to prevent attacks,
especially if the client keeps changing its address on a frequent basis.

>send a direct IM (through the server, that might redirect it to the

Are you suggesting that clients always use the intermediate server for
sending IM? It may make sense in some scenarios, but not always.

>and a session for initiating a chat. 

-Basavaraj

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 24 Aug 2001 09:39:30 -0700

Let's take another try at summarizing our dilemma:

1) Carrying Messages through the proxies works, goes through firewalls,
but has the potential of overloading the signaling infrastructure if
messaging is used for something else than 5 char per sec chat. Also,
Message has a strictly one-to-one semantic, which obliges us to resort
to funny tricks for multi-party chat sessions.

2) Treating IM as just one specific media in a multi-modal session is
fully in line with the SIP architecture; it provides an easy path for
multi-party and other fancy session management extensions. However, we
have not agreed on the transport; also, we know that the transport will
probably have to be over TCP, which means that we will not be able to
re-use the NAT and firewall traversal solutions designed for RTP over
UDP.

The IESG hand us an edict to "not pick alternative 1." It seems to me
that, at this stage, we have to collect transport proposals. The
proposals should define the transport format and the SDP documentation
of the media. They should meet a set of requirements, which I would
basically summarize as "parity with RTP" when it comes to security,
multiparty, and ease of proxying; the CPIM requirement of, essentially,
carrying MIME types messages; and the additional requirement is to
implement AIMD congestion control, e.g. by running over TCP. So far, I
see two alternatives:

1) Jonathan's proposal of using MESSAGE in an "end-to-end" fashion. I
see how we can do MIME and proxying, but I don't have a clear
understanding of security and multiparty. Can we reuse carry keys
through SDP in the same way as we carry keys for audio and video?

2) A yet to be defined protocol running over TCP -- but whoever thinks
this is a good idea should write a draft that we can analyze.

RTP-text is not an alternative; even if we somehow added AIMD congestion
control, it does not meet the CPIM requirements.

-- Christian Huitema

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Aug 2001 00:52:18 -0400

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 12:40 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Subject: RE: [Simple] 'Sessions of MESSAGEs' or IM Signaling Protocol
> 
> 

Actually, I think we can get some reuse. The scenario is identical to the
case where you are behind a symmetric NAT. I posted a note previously on the
list describing a tcp variant of the reflector protocol. Basically, if you
learn you are behind a nat (based on the documented udp mechanisms in
draft-rosenberg-sip-entfw-02), and want to do an IM session, you initiate a
TCP connection to a "tcp reflector" in the service provider network. Once
you connect, the provider sends data over that connection (or to another
connection thats been established for this purpose) with the binding of this
new connection. The binding is an IP/port such that if a host does a TCP
connect to it, the "reflector" will join the two connections, shuffling data
between them. Then, you just include that binding, a public address, as the
port to receive IM on.

Since this is a connection oriented media transport, we use
draft-ietf-mmusic-comedia. The direction attributes are sent as described in
entfw, as if this were symmetric RTP. The result is that you still get a
direct TCP connection if only one side is behind a nat, but use the
intermediary if both are behind it. The logic that makes this happen is
identical to the symmetric RTP case from entfw.

So, there is good reuse of the nat stuff, I think. 

> 
> The IESG hand us an edict to "not pick alternative 1." 

No, thats not the edit actuallly. In the "page model", which is what I think
you mean by alternative 1 (there is  no INVITE), we will use mESSAGE through
the proxy networks. The edict is that when we use INVITE to set it up
(session model), the transport is not SIP, whether it be end to end or
through proxies.

> It seems to me
> implement AIMD congestion control, e.g. by running over TCP.

Right. I sent out a list of requirements in a previous note. Let me add
another for people to noodle over: eventual support for multicast IM.
Ouchies! That would be desirable in the long run, but I don't know that a
single transport can satisfy the congestion control and multicast
requirements, at least not today. If I had to choose, I'd drop multicast.

 So far, I
> through SDP in the same way as we carry keys for audio and video?

Well, this proposal has been dismissed as a result of the edict from IESG.
e2e or through proxies, it aint sip.

> this is a good idea should write a draft that we can analyze.

We assigned someone at last IETF to look it over and come up with some
ideas. I am leaning towards something that resembles MIME over TCP (or
possibly CPIM over TCP).

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: [email-masked]
Date: Sun, 26 Aug 2001 00:47:47 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 1:03 AM
> To: Spatial Location; [email-masked]
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Thursday, August 23, 2001 8:12 AM
> Perhaps you should take a look at SIP, which defines several 
<snip>
> So, let us put these irritating statements about "don't use 
> SIP for IM at
> all", which appear to be in vogue on this list these days, to 
> rest. The
> point is moot.

I agree with you 100%.  The difference between paging and sessions is the
use of INVITE.  So, SIP is great for paging, but once the INVITE flys, then
it's session time.

> My preference is e2e. That doesn't mean its not possible to use
> intermediaries, no matter what the transport. I'll note that 
> the same exact
> issues arise for voice and video.

I also don't mean to imply you don't see those options.  I also see your
claim with the issues in voice/video.

The choice made for the protocol needs to make it possible for the e2e
security mechanism to be reused/forwarded by PROXY/intermediaries.

I liken the intermediary to a PBX at companies today - there is a value to
screen certain calls, where others you just let through.  The reality is,
there needs to be a way to provide an intermediary solution between the
endpoints as necessary with interoperability.

> > SIP was the method used to send 'sessions of MESSAGES' - 
> 
> False. It is easy to do this independent of the transport. 
> Processing-wise,
> it is more intensive to do this with SIP, since SIP message 
> processing is
> far more intensive than the the TCP byte shuffling I have described in
> previous posts.

I agree with you and so did the IESG, which is why they/we are pushing
'sessions of MESSAGEs' to another protocol and transport, i.e. cpim/tcp or
cpim/sctp.  Easy above is relative, to continue to process the IMsessions as
MESSAGEs appears, on the surfuce, simpler.  As you note and I agree with, it
is doesn't scale well in very large peer2peer environemnts, i.e mobile
phones.

> I agree it is a requirement that such a thing be possible. I 
> think it is
> easy to show that it is doable for any transport protocol.
> 

I understand that and would ask the same question of vasilis - would you
write that?

>I will comment separately on Robert's inter-enterprise-with-firewalls case.
>But, I'll note that you've got a general problem here for all session
>oriented protocols. If you put IM on the proxy path, well, that might be
>easy, but voice will never work that way. Neither will video. Neither will
>games. Neither will the new communications medium of next year. So, you can
>solve this with a one-off solution that works for ONE, and ONLY ONE form of
>communications (IM), or you can solve it in a more general way that enables
>this domain security to be applied to all media types. The SIP view is to
>solve these for all media types with a generic mechanism. I think that is
>the right approach.

I don't advocate all IMsessions over the proxy, but only when necessary for
security.  A method needs to be considered on how do this so existing
companies/carriers/etc can remain interoperable.

The question is how do you build in the 'necessity for security' into the
IMSession protocol or SIP for Instant Messaging.  If the SIP server provides
the IMclient with an IMProxy that seems most probable.  This, then, uses sip
to solve the problem.  I believe these mechanisms are already in place for
voice?

> > probably frowned on using RTP
> 
> No such thing happened. You might even want to take a look at 
> RFC2793, "RTP
> Payload format for text conversation". RTP is not a fit for 
> IM for other
> reasons.

Thanks for pointing this out - I'll follow your lead on this method.

<snip>
> > IMs are only text per node, am I naive 
> > to think it's a
<snip>
>I don't want my proxies in the path of 120Meg IM 
> transfers. Let routers
> do bit shuffling. Let proxies do rendezvous.

I agree with you as this is a good argument to avoid putting a 'proxy' in
between users.  Although, in a corporation one would specify policy on the
intermediary/PROXY to avoid that large TX, thus it is irrespective of the
base protocol.  however, that's implementation and restrictions not needed
to be defined by the protocol itself.

In a carrier network or ISP a proxy may not be possible (reasonable).  The
SIP server wouldn't hand the user off to an intermediary IMProxy, but
provide e2e solutions.
> >security/control needs to be built in. 
> 
> Ultimately, the best security is afforded by a pure, session 
> oriented end to
> end model. I find it frightening that people associate 
> privacy with sending
> all of their messages to MSN/Yahoo/AOL/whomever for archival and
> who-knows-what-else. The security community has long 
> recognized the power of
> e2e security vs. transitive chains of trust.

My thought doesn't consider specific companies, but it does consider a need
to use an intermediary at a network boundary when necessary.  e2e is one
solution, but an intermediary is still necessary and the SIP server provies
the capability to hand the user off to an IMProxy or an actual IM user
agent.

The intermediary starts to look like PSTN2PBX in a company, but some
organizations have found a PBX valuable: scoping calls, screening, no-direct
dial to inside phones etc.

> 
> 
> 
>  I am just pointing out the
> I take personal offense at this. 

I agree and I should have just made the point.  It was intended to be 'lite'
as it is obvious you enjoy or have some fun with the IDs.  And as it's been
said 'if you don't want to WORK do something you like'  I extend an apology
to you as sincere as I can given the newness of our association.

> I could not disagree more. This group was formed because 
> there is a large
> community that believes that the right technical approach is to view
> communications in the more general multi-modal (IM, voice, 
> video, gaming,
> etc.) context, rather than point solutions for each mode. 
> Absolutely NONE of
> the issues you raise applies to IM alone or voice alone, and 
> I have pointed
> these cases out explicitly above.

'This group was formed' - simple or sip?  I presume you mean SIP.  If you
mean SIP then it's primary goal is to provide rendevous mechanisms between
zero-time communictions UAs.

If you mean SIMPLe, then I may have to re-read the the WG description, but
it looks like the role is define SIP and IMP relationships when necessary,
where as, in this case there is an argument for the use and creation of an
IMsession mechanism.

Let's look at the requirements for the IMsessions:

Jonathon R.
1. reliable, sequenced delivery of messages
2. support for messages of arbitrary size, from 1 byte to megabytes (think
aimster)
3. congestion control
4. framing
5. content typing (text/html, text/plain, etc.)
6. support for e2e privacy, authentication, integrity
7. natability (i.e., can be made to work through nats without major
headaches)
8. rapid delivery (one the order of hundreds of milliseconds to a second)
9. relatively lightweight (will need to be implemented in phones and other
smaller devices)

Paul K
10. provision for IM conferences.

Joshua K etc (not claiming ownership just adding a point)
11. In my opinion the protocol needs to 'work' with/between
PROXY/intermediaries in a standarized format.  This facilitates
internet/extranet quality and level of use.

This kinda looks like IM conferences, but the basis is security not group
sessions.  My point is simply this, the 'method' (not server) used to hand
multiple IMs off to a conference server could be used to support
intermediary network perimeter security.  If one claims that IM conferences
should occur e2e then I can tell you that's not stable in most environments
and becomes unstable if the primary UA doing the mixing drops out.

I believe the use of CPIM would still be necessary, albeit the superfluous
use of to/from in a strict e2e scenario, but in an e2p2e, e2p2p2e or
Hop-by-hop scenarios I believe it it is still useful.

> 
> >I am not intending to offend anyone 
> 
> In that case, I would recommend that you refrain from 
> personal insults, as
> you have done above, as those usual cause people as myself to 
> take offense.

Noted

Lastly, I agree with Jonathon R on getting some requirments down so you get
into the tasking of an actual protocol.  So with that said, I think the
point 11 above looks suspiciously like 10 - the need for 'conference' type
IM services.

Joshua

---

From: [email-masked]
Date: Sun, 26 Aug 2001 00:56:21 -0500

> From: Patil Basavaraj (NET/Dallas) [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 9:35 AM
> To: 'ext Oded Cnaan'; [email-masked]

This makes sense and could be considered by the architects of the IM Session
based protocol, which needs to be defined.  However, it should be noted that
the primary starting point should be with requirements (per JR earlier) and
not existing solutions.  Please understand this is not an attempt to degrade
your suggestion as it holds merit given the current needs.

I am not to familiar with HIP, maybe you could expound on how that works or
just suggest a read to me. (just trying to get your perspective)

> >attacks by hackers on user's clients. If you take a look at 
> the leading
> IM

This is 'relatively' secure given the dynamic nature of IP use,
none-the-less, there will be enterprises that will want to restrict direct
communications with internal IM clients.  In short, it's a good point on how
end-to-end communications can be somewhat safeguarded!

> >There are two different concepts in IM, that sometimes are 
> perceived as
> one.
> >I think that SIP needs to support both options. MESSAGE 
> should be used
> to

Professionally I would not advocate *always* using the intermediary,
however, the logic should be built into the SIP establishment for IM to use
an intermediary in the event a secure network perimeter is being traveresed
and e2e is not allowed.  This of course is defined by the enterprise hosting
the purported "secure network".

In the case of a service provider, like AT&T wireless they could implement
IM in an direct end-to-end (e2e) fashion as suggested by Jonathon R.
However, the e2e solution may not work 100% for the enterprises or between
AOL networks and DigitalKnowledge.NET, for example.

In the case of an enterprise which is accepting communications from a client
on the AT&T wireless network, it's necessary to define rules by which the
SIP server would hand off the session to the enterprise client directly or
to an intermediary to support network/domain security - no nating at issue
here, strictly perimiter protection.  In these cases the IMsession protocl
would need to handle proxying the messages in an e2p2e scenario or in
somecases an e2p2p2e scenario.

So it's probably best to focus on the requirments as suggested by JR in
earlier messages.  As noted in my last response to JR, I believe we should
consider situations where E2E is not allowed and messages do need to be
proxied.  So that makes it 11 requirements, albeit that fresh one jonathon
brougt up 'multicast IM?'

Joshua
Requirments as of 8/26/01
Let's look at the requirements for the IMsessions:

Jonathon R.

Paul K

Jonathon R.
12. Multicast IM