Subject: multiplexing SigComp and non-SigComp messages on the same TCP connection (was RE: [rohc] Old issue - multiplexing compressed and uncompressed messages in the same TCP connection - long)

From: [email-masked]
Date: Wed, 12 Nov 2003 18:50:28 -0500

Hi Mark,

I'm glad that my "threat" in my last sentence achieved its purpose. :-)
And thanks for the commetns. I feel discussions are really needed to 
clear this subject.

Please see my comments in line.

Zhigang

> But first of all, can I be *really* pedantic about terminology..?  We
> should differentiate between:
> - SigComp message; and
> - non-SigComp message

You're absolutely right. I was too busy to correct this, but this
is important. I changed the subject line to reflect this.

> If you were allowed to have multiple TCP connections or to 
> re-open a new connection easily, why would you want to do 
> multiplexing on a single connection..?

This is the key question. Actually that is one of the questions 
I've asked Robert during our offline discussion. The answers were 
(if I understood correctly):

- Re-opening a new TCP connection means extra delay. I tend
to agree, since the establishment and tear-down of a TCP connection 
require quite some procedures in the state machine. 

- In certain cases, we are not allowed to have multiple TCP connections.
I learned that this is the case for 3GPP, in particular, due to security
policy as Robert described earlier. However, it is unclear to
me if it is simply a bad choice made by 3GPP, or it is due to some 
technical reasons that are more generic than 3GPP. This is something
I would like to figure out during this discussion.

> This implementation suggestion:
> 
> > > A possible implementation could be:
> > > -	Transport looks at the first byte of the message, and
> > > cheks whether it starts with 11111.
> > > -	If yes, the stream is passed to SigComp that reads it
> > > till 0xFFFF and returns
> > > -	If no, the stream is passed to SIP that reads it as
> > > long as indicated by Content-Length
> > > -	Rinse, Repeat
> 
> makes it sound easy, but the throw-away 'is passed to' seems to me to
> conceal all of the complexity / layering problems / tricky stuff...

I do agree this doesn't look nice in the layering diagram. However,
I don't think it is complex or tricky to implement. SigComp already 
requires quite interactions with SIP layer anyway. Or, perhaps I
missed something here?

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 13 Nov 2003 13:57:24 +0000 (GMT Standard Time)

Hi Zhigang,

I agree -- you can't beat a good threat... ;-)

Comments, as ever, in-line.

Cheers,

Mark.

> require quite some procedures in the state machine.

This is true: there's a 3-way handshake to establish a new TCP connection.
I'm not sure how much of a big deal this is, since most of the conditions
for sending a non-SigComp message involve significant latency
(retransmission; message > 64kbyte; ...)

However, from my reading of RFC 3261 (I am not now, nor have ever claimed
to be any kind of SIP expert; so if anyone wishes to correct this, feel
free..!) you could have a SigComp & non-SigComp TCP connection open...

> I would like to figure out during this discussion.

My personal opinion is that this security model is broken.  It is usual to
have ephemeral source ports and I can't see how it helps to nail down the
source port.  RFC 3261 section 18 says that the source port is 'often
ephemeral'.  Moreoever, 3261 describes having a 'dwell time' for a
connection to allow a transaction to complete within a single connection.
After this time, the connection is/can be closed.  The 'fixed port' model
means that you can't re-open a connection within the time-wait time...

... also all the text in section 18 about error conditions and re-opening
connections seems to be rendered unusable in this scenario...

> requires quite interactions with SIP layer anyway. Or, perhaps I

I agree that there are significant interactions between SIP and SigComp.
However, these are all defined in RFC 3320.  The point is that SigComp
should (from a transport perspective) be able to look (mostly) like an
alternative transport for SIP.  Multiplexing really breaks that model.

I think my point is that *not* allowing multiplexing means that you can
separate the implementation details.  (You don't have to if you don't want
to, but you *can*).  If you insist on allowing multiplexing, then a
receiving endpoint *must* support it, and that's going to put a bunch of
constraints and requirements on the implementation.  I don't think that
those constraints need to be there, and so I'd prefer not to have them...

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 14 Nov 2003 20:38:25 +0200

>I would like to figure out during this discussion.

	I'd hazard to say that this is simply a series of bad choices
	made by MMUSIC, IPSEC, 3GPP and this working group. ;)

	In any case, SigComp relies on external protocol to provide it
	with security. The SIP does not provide such protection, so it
	is up to lower layers. 3GPP chose IPSEC because SIP uses UDP, so
	they could not use TLS. IPSEC does not naturally provide
	security at application layer like that SIP requires here, so
	3GPP made an IPSEC hack that secures only one UDP and TCP
	connection at a time.

	Personally I'd like to blame ITU-T, because they specified
	horribly complex H.323 so that it simply had to be destroyed by
	SIP, and only selling argument SIP had back then was that it was
	simple and used UDP.

	In any case, I don't think 3GPP is going to change their rel5
	security solution any more (it has been tried many time before
	and now they are almost complete with next release).

>requires quite interactions with SIP layer anyway. Or, perhaps I

	Speaking from SIP point-of-view: SigComp sits on one layer above
	SIP parser (at transport layer), so this kind of solution fits
	nicely in the SIP layering. ;-)
<
					Pekka

---

From: Pekka Pessi <[email-masked]>
Date: Fri, 14 Nov 2003 21:47:18 +0200

West, Mark <[email-masked]> writes:
>...Moreoever, 3261 describes having a 'dwell time' for a
>After this time, the connection is/can be closed.  

	In general, the connection should be kept around for 64*T1 or 32
	seconds (or longer, if the client has longer T1 than 500 ms). 
	Because only the client knows its T1 value, it should close the
	connection, not the server.

	If the client is a SIP UA behind a NAT box, it wants to keep the
	connection open for the duration of its registration. If it
	wants to open another connection, in most cases it has to do a
	REGISTER request in order to get the new connection
	authenticated. Because the TCP connections are expensive for the
	server, it wants to ditch the old one after the new connection
	has been authenticated.

	The same happens with a 3GPP UE: if it wants to open a new TCP
	connection, it has to first re-authenticate itself. The IPSEC
	protection is given to the new connection using the keys derived
	from the authentication procedure. The old connection is closed.

>The 'fixed port' model

>connections seems to be rendered unusable in this scenario...

	They are not unusable, they just have the added penalty of
	re-running the authentication procedures.

	BTW, how is the SigComp for TLS? If people are not happy with
	3GPP handling security with IPSEC (I'm not saying that they are
	alone here), they should provide 3GPP with an alternative.

>alternative transport for SIP.  Multiplexing really breaks that model.

	Well, from SIP transport point of view SigComp looks like just
	alternative parser for SIP. Transport takes packets (in case of
	UDP) or streams of bytes (in case of TCP), stuffs them into the
	parser and gets SIP messages out of it. The combined SIP/SigComp
	parser can look inside SIP message and give compartment
	identifier back to SigComp.

>separate the implementation details. (You don't have to if you don't
>want to, but you *can*). If you insist on allowing multiplexing, then a
>receiving endpoint *must* support it, and that's going to put a bunch
>of constraints and requirements on the implementation. I don't think
>that those constraints need to be there, and so I'd prefer not to have
>them...

	SigComp has lot of things that break assumptions about
	transport, especially TCP transport. TCP is a stream of bytes,
	SigComp provides messages, etc.

						Pekka