Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp messages on t he same TCP connection

From: [email-masked]
Date: Fri, 12 Dec 2003 19:53:32 -0500

Hi,

Unfortunately, I couldn't spend time on this issue and will be
on vacation starting next Monday until after new year. This has
been a quite good discussion since it revealed things we really 
haven't had chance to elaborate.

Just a quick summary of what we agreed (or seemed so):

1) RFC 3320 does NOT allow multiplexing of SigComp and non-SigComp
messages over the same TCP connection. Period.

2) The question is whether multiplexing is needed.

3) The mechanics of doing the multiplexing is clear.

4) Multiplexing is a new requirement, as the receiving SigComp
endpoint has to behave differently.

5) A very simple stateless bytecode can be used to carry an
uncompressed SIP message in a SigComp message. This can recover
SigComp failures due to loss of sync on states.

The rest is still more or less in debate, or unclear: single TCP
connection, 64KB upper limit of UDVM output, UDVM failure itself, 
security, etc. I'd encourage more pointed discussions from both
sides so that we can reach a conclusion.

Have a good holiday season!

Zhigang

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 18 Dec 2003 14:21:52 -0000

Hi all,

Slightly belatedly, a response about continuous mode.  The main question is
what is the consensus about what 'continuous mode' actually means?  I think
there are at least two interpretations.  (I also suggest that when we reach
consensus, it should be put into the implementer's guide.) 

3320 says that you can use SigComp for stream data in one of two ways:

"1) The dispatcher collects a complete SigComp message and then
       invokes the UDVM.  The advantage is that, even in implementations
       that have multiple incoming compressed streams, only one instance
       of the UDVM is ever required.
 2) The dispatcher collects the SigComp header (see Section 7) and
       invokes the UDVM; the UDVM stays active while the rest of the
       message arrives.  The advantage is that there is no need to buffer
       up the rest of the message; the message can be decompressed as it
       arrives, and any decompressed output can be relayed to the
       application immediately."

    In general, which of the strategies is used is an implementation
    choice."

I believe that in any event 2) is continuous mode.  Because the UDVM
persists it requires greater security than TCP alone provides.  As stated in
3320 agreement is required between the two endpoints to use continuous mode.

Interpretation 1:

An endpoint can open a UDVM on receipt of part of a SigComp message over TCP
and leave it open until the rest of the message is received.  Consequently,
the endpoint has to be able to cope with multiple UDVMs running, but other
than that everything works in the same way as normal.  In what way is the
security risk any greater when using this interpretation of continuous mode
than when buffering the message first?

Interpretation 2:

Because the dispatcher can pass the decompressed output straight to the
application, more than one SIP message can be put into one SigComp message.
In fact, the whole SIP flow could be compressed in one SigComp message as
long as there is some way to flush the last few bytes of a SIP message
through the connection.

Because the UDVM, and consequently its circular buffer persist, there is no
need to store and look up state (another reason why greater security is
required) and there is no need for the SIP stack to 'authenticate' each
message.  In fact, SigComp no longer has any concept of an application layer
message so authentication of a message no longer has any meaning.

To the SIP stack, SigComp looks exactly like TCP.

If synchronisation is lost (e.g. decompression failure occurs) then the
connection would have to be restarted but this is the same as if
synchronisation is lost by the SIP stack.  The likelihood of decompression
failure occurring is greatly decreased by the fact that there are no state
look ups (there's no risk of the state not being present).

The 64k uncompressed message limit is to provide security against
"generating huge messages to muck up the SIP stack" attacks.  If the extra
security mechanisms that make continuous mode safe to use can also prevent
this attack, then isn't it safe to drop the message limit?  

Then the whole SIP flow can be compressed by one SigComp message and
delivered in small chunks without a message limit size problem.  

Which (if either) interpretation have other people assumed, or is there
another interpretation we haven't considered?

On the issue of whether or not use of continuous mode could solve the issue
of multiplexing on a TCP connection, I think that if interpretation 1 is the
consensus, then as Jan said there are still problems and continuous mode is
not the solution.  However, if interpretation 2 is the consensus, then as
Mark suggested continuous mode could be used (allowable because of the
security provided by IPsec) and then there is no need for multiplexing.

Best regards,

Abbie

> -----Original Message-----
> From: Jan Christoffersson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Monday, November 24, 2003 10:13 AM
> To: West, Mark; [email-masked]
> Cc: [email-masked]; Lars-Erik Jonsson (LU/EAB); [email-masked]
> Subject: RE: [rohc] Re: multiplexing SigComp and non-SigComp 
> messages on t he same TCP connection
> 
> 
> Hi Mark,
> 
> I have some concerns about this too...
> Comments inline.
> 
> /Jan
> 
> > Considering (2), something that has not yet been raised is 
> > the use of what
> > is sometimes referred to as 'continuous mode'.  The state 
> model in RFC
> > 3320 exists for 2 reasons: lack of security between end-points; and
> > (potential) lack of reliability.  The IPsec SA and use of TCP 
> > renders both
> > of these non-issues.  So, why not have a persistent UDVM..?
> > 
> > This is perfectly reasonable within RFC 3320 -- there is no need for
> > state-storage, as the UDVM is simply kept running.
> 
> In order to use the continuous mode and compress messages 
> relative to previous messages, the byte codes need to be 
> tailored for this. This means that we need to know that the 
> receiving endpoint is using continuous mode and this means 
> negotiations. How to do this has not been defined.
>  
> > Since, in this model, there is no need to align SIP messages 
> > with SigComp
> > boundaries, the 64kbyte limit need not apply: SigComp ends up simply
> > providing a compressed TCP stream...
> > ... so connection close semantics are preserved...
> 
> Quoting from the RFC 3320: 
> 
> "Decompression failure occurs if the cumulative number of 
> bytes provided to the dispatcher exceeds 65536 bytes."
> 
> I think that the word cumulative means that you cannot break 
> a large message into little pieces and output them one by 
> one. As soon as the total size is 65 K a decompression 
> failure occurs. I even think that continuous mode could 
> worsen the situation: If several SIP messages are 
> decompressed by the same instance of the UDVM (which could be 
> done in continuous mode)it could happen that decompression 
> failure occurs even if no single message is above the 
> individual limit.
>